Skip to content

Latest commit

 

History

History
39 lines (31 loc) · 1.7 KB

README.md

File metadata and controls

39 lines (31 loc) · 1.7 KB
Raw

Introduction

Sometimes one would want to setup CDI development environment on a totally external cluster (not kubevirtci).
We try to support this, with this document aggregating some knowledge around that.

External Kubernetes Provider

This provider works with an existing Kubernetes cluster. You'll want to configure your own Container Image Registry, we tie into the existing Make/Build workflow, but modify things such that:

  1. We build container images and push to the specified registry (instead of registry:5000)
  2. We generate the manifests with the provided DOCKER_PREFIX (uses default port)
  3. Uses your configured kubectl and deploys your build to the existing cluster

Build and push images, create manifests and deploy CDI

We use the same workflow as the ephemeral dev environment, but skip make cluster-up.
A suggested flow:

export KUBEVIRT_PROVIDER=external
export PULL_POLICY=Always
export CDI_NAMESPACE=cdi-rand-ns-name
export KUBECONFIG=/path/to/kubeconfig
# Make CDI repositories public on your registry
export DOCKER_PREFIX=quay.io/username

make cluster-sync

For tests, it is required to have a default storage class defined in the cluster.

Differences vs local

  • A note about kubernetes local-up-cluster.sh
    The external provider isn't quite appropriate for use with the local-up-cluster.sh script used in the Kubernetes source repo. We'll need to add an additional local provider for this to handle some of the specifics.
  • You will be prompted to login to your external registry, so that the credentials could be saved in a path that bazel "expects".
    Bazel push (CDI containers/e2e testing containers) expects external registry creds to be in the docker CRI default path.