Skip to content

KubeVirt cluster template parameters#

ClusterDeployment parameters#

To create a cluster deployment, you must provide a set of parameters to the ClusterDeployment object. The full list of parameters is defined in the corresponding Helm chart for the Cluster Template you use. For built‑in KubeVirt Cluster Templates, refer to the Cluster Templates section of the k0rdent/kcm repository.

The KubeVirt API is documented in the KubeVirt API Reference.

Etcd encryption at rest for hosted and standalone templates#

To enable Kubernetes API encryption at rest, configure these parameters under .spec.config.encryption:

  • automaticReload (boolean): Enables kube-apiserver automatic reload for the encryption provider config (default: true).
  • configSecret.name (string): Name of the Secret containing EncryptionConfiguration.
  • configSecret.key (string): Secret data key with EncryptionConfiguration YAML (default: config).
  • configSecret.hash (string): Optional hash suffix for the mounted file name. If empty, it is calculated automatically from the Secret data using Helm lookup.

The controller configures kube-apiserver with:

  • --encryption-provider-config=<path>
  • --encryption-provider-config-automatic-reload=true (when automaticReload=true)

Hash calculation behavior:

  • If configSecret.hash is set, that value is used.
  • If configSecret.hash is empty, the chart tries to calculate a hash from Secret.data[configSecret.key] in the ClusterDeployment namespace.
  • If lookup cannot read the Secret during rendering, the chart falls back to config.yaml.

Secret placement rules:

  • The Secret must exist in the same namespace as the ClusterDeployment.
  • If Credential.spec.region is not set, create the Secret in the management cluster.
  • If Credential.spec.region is set, create the Secret in the regional cluster.
  • The encryption Secret is not copied automatically between management and regional clusters.

Note

Enabling encryption at rest affects newly written data. Existing etcd objects are not re-encrypted automatically and require a rewrite/migration procedure.

Data Volumes#

If you want to use a DataVolume that references the source data you plan to import into your KubeVirt cluster deployment, configure the dataVolumes section of the ClusterDeployment spec for controlPlane and/or worker nodes. For example:

spec:
  config:
    controlPlane:
      dataVolumes:
      - name: dv0
        accessModes: ReadWriteOnce
        storage: 7Gi
        storageClassName: csi-cinder-sc-delete
        source:
          http:
            url: https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img
    worker:
      dataVolumes:
        - name: dv1
          accessModes: ReadWriteOnce
          storage: 7Gi
          storageClassName: csi-cinder-sc-delete
          source:
            http:
              url: https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img

Supported parameters for each DataVolume are:

  • name (string): Name of the DataVolume.
  • accessModes (array): Desired access modes for the volume. Valid values are ReadOnlyMany, ReadWriteMany, ReadWriteOnce, ReadWriteOncePod. More information: Access Modes.
  • storage (string): Requested storage size for the corresponding PVC (example: 10Gi).
  • volumeMode (string): Type of volume required by the claim: Block, Filesystem or FromStorageProfile.
  • storageClassName (string): Name of the StorageClass required by the claim. More information: Storage Class).
  • source (object): The source of the DataVolume. See supported volumes sources for more details.

For more information, see DataVolumes in the official KubeVirt documentation.

Networking configuration#

For the KubeVirt cluster to function properly, networking must be properly configured. k0rdent supports configuring the network of a KubeVirt ClusterDeployment through the devices and networks sections for the controlPlane and worker nodes. For example, to configure networking for the control plane VMs:

spec:
  config:
    controlPlane:
      devices:
        interfaces:
        - name: default
          bridge: {}
      networks:
      - name: default
        pod: {}

By default, the bridge network interface type is used for both control plane and worker nodes. For more information about KubeVirt networking, see the official KubeVirt documentation: Interfaces and Networks.