This version is under construction, please use an official release version

Installation

KDP mode is part of a regular KubeV installation: you add a kdp section to the same configuration file and run the installer. The section decides which of three modes you get.

Choose a mode

Bring your own KDPSame layerNested cluster
Configurationkdp.externalneither external nor clusterkdp.cluster
Where KDP runsWherever you already run it.On the KubeV cluster, in namespace kdp-system.In its own Kubernetes cluster, on three KubeVirt VMs on the KubeV cluster.
KDP version1.2.1 or newer, yours.1.2.1, installed for you.1.2.1, installed for you.
Who registers the KubeV service in KDPkubermatic-virtualization kdp connect, with a kcp administrator’s kubeconfig.The installer.The installer.
KubeV dashboardYes.Yes.No.
Enabling KubeV in projectsIn the KDP catalog, per project.Automatic, in every project.In the KDP catalog, per project.
StatusSupported.Supported.Experimental. Not for production.
  • Choose Bring your own KDP when your organization already runs KDP, and KubeV should become one more service in it.
  • Choose Same layer for a new platform that runs both. It needs the least work: the installer sets everything up.
  • Use the Nested cluster only to try KDP out, for example in a lab.

What every mode needs

  • A KubeV installation configuration. KDP mode adds to it. Read Declarative Installation first if you haven’t installed KubeV before.
  • The installer, kubermatic-virtualization, from the Kubermatic EE Downloader. The commands in this section assume it is on your PATH.
  • Registry credentials in KUBEV_USERNAME and KUBEV_PASSWORD, in the same layer and nested modes. The KDP charts and images are pulled with them, even when the configuration sets imagePullSecret.
  • An OIDC identity provider that KDP and KubeV share, except in nested mode, which brings its own. KDP, kcp and the KubeV dashboard all sign users in with one OIDC client. kcp identifies users by their email claim, so every user needs an email address in their token.

The installer asks for confirmation before it changes anything. Add -y to skip the question, for example in a pipeline. It logs every step to the terminal, and the details to kubermatic-virtualization.log in the temporary directory, or the file named in --log-file.

The kdp section

FieldModesDefaultDescription
enabledallfalseTurns on KDP mode.
adminall—Email address of the first platform administrator. One of admin and adminGroup is required in the same layer and nested modes. With your own KDP, both are optional, and kdp connect grants the one you set.
adminGroupall—OIDC group whose members are platform administrators. Wins when both are set. Only works when your login method puts groups in the token. system:authenticated, system:unauthenticated and system:masters are refused: at the end of the installation, or by kdp connect before it writes anything.
providerWorkspaceallroot:kubevThe KDP workspace that holds the KubeV service. Must be below root, not root itself. With your own KDP, the workspace kdp connect registers KubeV in, written root:<name>, directly below root.
tenantUnderlayInterfacesallemptyHost network interfaces that projects may use for underlay subnets, as names or globs such as ens[0-9]*. While the list is empty, projects can’t create underlay subnets. See Underlay networks for projects.
domains.baseall—A base domain. The installer derives dashboard.<base>, kcp.<base> and, in nested mode, dex.<base> from it.
domains.dashboardsame layer, nesteddashboard.<base>Public address of the KDP dashboard.
domains.kcpallkcp.<base>Public address of kcp. HTTPS only.
domains.dexnesteddex.<base>Public address of the nested Dex.
dashboardEncryptionKeysame layer, nestedgeneratedKey that encrypts the KDP dashboard’s session cookies. Generated on the first run and kept in the Secret kdp-system/kubev-kdp-dashboard-encryption-key, on the cluster KDP runs in. Set it to use your own, such as the output of openssl rand -hex 32.
dexCASecretNamesame layer—Secret in kdp-system with the CA (key ca.crt) that signs your Dex’s certificate. It makes kcp trust a private CA, but the KDP dashboard and KubeV don’t use it: give Dex a publicly trusted certificate.
kcpCASecretNamesame layercreated for youSecret in kubermatic-virtualization with the CA (key ca.crt) the KubeV API server uses to verify kcp. Leave it empty: the installer creates kubev-kcp-front-proxy-ca. With your own KDP, use external.caSecretName instead.
external.kcpBaseURLbring your ownhttps://<domains.kcp>Address of your kcp’s front-proxy, as the KubeV API server reaches it.
external.caSecretNamebring your own—A Secret you keep in kubermatic-virtualization, with the CA (key ca.crt) that signs your kcp’s certificate. Leave it out, and kdp connect fills kubev-kcp-front-proxy-ca from the kcp kubeconfig.
ca.certificate, ca.privateKeynestedself-signedA CA of your own, in PEM, to sign the nested KDP’s certificates.
clusternested—Selects nested mode: see Nested Cluster.

With the KubeV dashboard enabled, KDP mode also requires:

  • dashboard.auth.oidc. Basic and no authentication are refused.
  • dashboard.dashboardURL, the absolute http:// or https:// address users open KubeV at. KDP’s button links to it, and KubeV uses it after sign-in and to protect VM consoles. When it is https, the session cookie is sent over TLS only.

Also add groups to dashboard.auth.oidc.scopes, so that roles granted to groups in KDP apply in KubeV. Nothing checks it, and the default scopes leave it out:

dashboard:
  auth:
    oidc:
      scopes: ["openid", "email", "profile", "groups"]

Pages