Mit der Cluster-API v1beta1 können Sie einen Cluster basierend auf einer standardmäßigen ClusterClass-Definition bereitstellen.

ClusterClass API v1beta1

Die Kubernetes Cluster-API ist eine Suite von Tools, die die deklarative Bereitstellung, Upgrades und den Betrieb von Kubernetes-Clustern ermöglichen. ClusterClass ist eine Weiterentwicklung der Cluster-API, mit der Sie Vorlagen zur Verwaltung des Lebenszyklus von Clustergruppen definieren können. TKG-Dienst unterstützt ClusterClass über die v1beta1-API.

TKG-Dienst wird mit einer standardmäßigen ClusterClass-Definition mit dem Namen tanzukubernetescluster ausgeliefert. Die ClusterClass tanzukubernetescluster stellt die Vorlage für die Erstellung von Clustern mithilfe der v1beta-API bereit. Die ClusterClass tanzukubernetescluster ist in allen Benutzer-Namespaces verfügbar. Um einen Cluster auf Basis dieser ClusterClass zu erstellen, verweisen Sie einfach in der Clusterspezifikation auf ihn. Weitere Informationen finden Sie in den v1beta-Beispielen.

Standard-ClusterClass tanzukubernetescluster

Die standardmäßige ClusterClass tanzukubernetescluster ist unveränderlich. Sie kann unter Umständen mit jeder Version des TKG-Diensts aktualisiert werden.

Führen Sie die folgenden Schritte durch, um die Standard-ClusterClass tanzukubernetescluster anzuzeigen, die im Lieferumfang der TKG-Dienstinstanz enthalten ist:

  1. Melden Sie sich bei Supervisor an.
    kubectl vsphere login --server=IP-or-FQDN --vsphere-username [email protected]
  2. Ändern Sie den Kontext in den vSphere-Namespace, in dem ein TKG-Cluster bereitgestellt wird.
    kubeclt config use-context VSPEHRE-NS
  3. Rufen Sie die Standard-ClusterClass tanzukubernetescluster ab.
    kubectl get clusterclass tanzukubernetescluster -o yaml
  4. Sie können die Ausgabe der Standard-ClusterClass optional in eine Datei mit der Bezeichnung tkc-dcc.yaml schreiben.
    kubectl get clusterclass tanzukubernetescluster -o yaml > tkc-dcc.yaml

ClusterClass-Variablen zum Anpassen eines Clusters

Sie passen einen Cluster basierend auf der ClusterClass tanzukubernetescluster mithilfe von Variablen an. Variablen werden mithilfe von Name-Wert-Paaren definiert. Die Syntax muss dem openAPIV3Schema entsprechen.

Für die Bereitstellung eines Clusters mithilfe der v1beta1-API sind zwei Variablen erforderlich:
  • VM-Klasse
  • Speicherklasse
Zusätzliche Variablen sind für die Anpassung eines Clusters verfügbar, wie z. B.:
  • Proxy
  • TLS-Zertifikate
  • SSH-Schlüssel

In den folgenden Abschnitten werden alle Variablen aufgelistet, die mit der Standard-ClusterClass tanzukubernetescluster verfügbar sind.

Wichtig: Ein gültiger Schlüsselname darf nur aus alphanumerischen Zeichen, einem Bindestrich (z. B. key-name), einem Unterstrich (z. B. KEY_NAME) oder einem Punkt (z. B. key.name) bestehen. Leerzeichen können in Schlüsselnamen nicht verwendet werden.

clusterEncryptionConfigYaml

Verwenden Sie die clusterEncryptionConfigYaml-Variable, um die Clusterverschlüsselung zu konfigurieren.

clusterEncryptionConfigYaml
Zeichenfolge, bei der es sich um eine YAML-Datei mit Details zur Verschlüsselungskonfiguration handelt.
Sie können die Verschlüsselung von Daten in der etcd-Datenbank mit dem Paket kube-apiserver Encryption Configuration konfigurieren. Weitere Informationen finden Sie unter Verschlüsseln von geheimen inaktiven Daten in der Kubernetes-Dokumentation. 
...
    variables:
    #clusterEncryptionConfigYaml specifies the base64 encoded 
    #EncryptionConfiguration YAML
    #the YAML contains a base64 encryption configuration for the cluster identity
    #the key is generated randomly
    - name: clusterEncryptionConfigYaml
      value: string which is name of the EncryptionConfiguration YAML

controlPlaneCertificateRotation

Verwenden Sie die controlPlaneCertificateRotation-Variable, um das System so zu konfigurieren, dass die TLS-Zertifikate für Knoten der Steuerungsebene rotiert werden, indem ein Rollout dieser Zertifikate vor deren Ablauf ausgelöst wird. Die Zertifikatrotation der Steuerungsebene ist für alle neuen und vorhandenen Knoten der Steuerungsebene verfügbar.
controlPlaneCertificateRotation
Boolesche Variable zur Aktivierung der Funktion und Anzahl der Tage vor Ablauf für die Rotation der Zertifikate. Weitere Informationen finden Sie unter Automatically rotating certificates using Kubeadm Control Plane provider (Automatische Rotation von Zertifikaten mithilfe des Kubeadm-Steuerungsebenenanbieters). 
...
    variables:
    - name: controlPlaneCertificateRotation
      value: 
        activate: true
        daysBefore: 90

Dabei gilt:

  • activate ist ein boolescher Wert für die Aktivierung der Funktion. Der Standardwert lautet true.
  • daysBefore ist die Dauer in der Anzahl der Tage vor Ablauf. Der Standardwert beträgt 90 Tage. Der Mindestwert beläuft sich auf 7 Tage vor Ablauf.
Hinweis: Diese Variable wurde für vSphere 8 Update 3 ( TKG-Dienst 3.0) aktualisiert.

controlPlaneVolumes

Verwenden Sie die controlPlaneVolumes-Variable, um dauerhafte Volumes für Steuerungsebenenknoten zu konfigurieren.
controlPlaneVolumes
Optionales Array von Objekten, von denen jedes name, storageClass und mountPath enthält, die jeweils Zeichenfolgen sind, und ein optionales capacity-Objekt, das eine storage-Zeichenfolge enthält. 
...
    variables:
      #controlPlaneVolumes is an optional set of PVCs to create and
      #attach to each node
      - name: controlPlaneVolumes
        value:
          #name of the PVC to be used as the suffix (node.name)
          - name: NAME
            #mountPath is the directory where the volume device is mounted
            #takes the form /dir/path
            mountPath: /dir/path
            #storageClass is the storage class to use for the PVC
            storageClass: tkgs-storage-profile
            #capacity is the PVC storage capacity
            capacity:
              #storage sets the capacity for the disk volume
              #if not specified defaults to storageClass capacity
              storage: 4Gi

defaultRegistrySecret

Mit der Variablen defaultRegistrySecret wird die Standard-Containerregistrierung für den Cluster konfiguriert.
Hinweis: Diese Variable ist für die Verwendung mit der eingebetteten Harbor-Registrierung reserviert.
defaultRegistrySecret
Objekt, das einen öffentlichen Schlüssel, einen Zertifikatsnamen und einen Namespace für die Standard-Containerregistrierung enthält.
Wenn Sie die eingebettete Harbor-Registrierung auf Supervisor aktivieren, gibt die Variable defaultRegistrySecret das Registrierungsdienstzertifikat an, dem der Cluster vertraut. Der geheime Zertifikatschlüssel ist mit managed-by: vmware-vRegistry gekennzeichnet. Bei der Clustererstellung wird ein defaultRegistry-Zertifikat in die Variable defaultRegistrySecret eingefügt. Nach der Clustererstellung verwalten Sie die Zertifikatrotation oder ein beliebiges Update, indem Sie die Variable manuell aktualisieren. 
...
    variables:
    - name: defaultRegistrySecret
      value:
        #data holds the base64 encoded data.ca\.crt content
        #data.ca\.crt is already encoded, so raw cert data is encoded twice
        data: LS0tLS1CRUdJTiBDRVJU...S0tRU5EIENFUlRJRklDQVRFL
        #name specifies the name of the registry cert secret 
        name: harbor-ca-key-pair
        #namespace specifies the ns of the registry cert secret
        namespace: svc-harbor-domain-c9

defaultStorageClass

Verwenden Sie die defaultStorageClass-Variable, um eine Standardspeicherklasse für den Cluster zu konfigurieren.

defaultStorageClass
Zeichenfolge, die angibt, welche Speicherklasse als Standardspeicherklasse verwendet werden soll, die häufig von bestimmten Anwendungen wie Helm-Diagrammen und Tanzu-Paketen benötigt wird. 
...
    variables:
    - name: defaultStorageClass
      value: tkg2-storage-profile

extensionCert

Verwenden Sie die extensionCert-Variable, um ein TLS-Zertifikat zu konfigurieren.

extensionCert
Objekt, das ein contentSecret-Objekt mit name- und key-Zeichenfolgen enthält. Das contentSecret-Objekt verweist auf ein geheimes Kubernetes-Objekt, das für ein TLS-Zertifikat erstellt wurde. 
...
    variables:
    #extensionCert specifies the cert and key for Extensions Controller
    #self-signed issuer and certificates must be created in advance
    - name: extensionCert
      value: 
        contentSecret:
          #name specifies the name of secret
          name: string
          #key specifies the content of tls\.crt in the secret's data map
          key: string

kubeAPIServerFQDNs

Verwenden Sie die Variable kubeAPIServerFQDNs, um einen Cluster mit einem FQDN zu konfigurieren.

kubeAPIServerFQDNs
Array aus einem oder mehreren vollqualifizierten Domänennamen (FQDN).
Das erzeugte Kubernetes-API-Zertifikat enthält alle FQDNs, die Sie in der Variable kubeAPIServerFQDNs angegeben haben. Das System befüllt kubeconfig mit dem ersten FQDN in der Liste und geht davon aus, dass dieser aufgelöst werden kann. Wenn Sie einen anderen FQDN in der Liste verwenden möchten, können Sie die erzeugte kubeconfig-Datei mit dem gewünschten FQDN aus der Variablenliste manuell bearbeiten.
Weitere Informationen dazu finden Sie unter v1beta1-Beispiel: Cluster mit FQDN.

nodePoolLabels

Verwenden Sie die nodePoolLabels-Variable, um Bezeichnungen für Worker-Knoten zu konfigurieren.

nodePoolLabels
Array aus einem oder mehreren Objekten, wobei jedes Objekt ein Schlüssel/Wert-Paar enthält, beides Zeichenfolgen.
Mithilfe von Bezeichnungen können Sie Systemobjekte gemäß Ihren Anforderungen organisieren, um die Abfrage und Berichterstellung zu vereinfachen. Informationen zur Nutzung finden Sie in der Dokumentation zu Kubernetes-Bezeichnungen.

nodePoolTaints

Verwenden Sie die nodePoolTaints-Variable, um Taints auf Worker-Knoten anzuwenden.

nodePoolTaints
Array von Objekten. Jedes Objekt enthält ein Merkmal (Taint), das für Worker-Knoten gilt.
Jedes Objekt enthält einen key (Zeichenfolge), einen value (Zeichenfolge) und eine effect (Zeichenfolge). Das Feld timeAdded wird beim Erstellen oder Aktualisieren durch das System aufgefüllt.

nodePoolVolumes

Verwenden Sie die nodePoolVolumes-Variable, um dauerhafte Volumes für Clusterknoten anzugeben.

nodePoolVolumes
Optionales Array von Objekten, von denen jedes name, storageClass und mountPath enthält, die jeweils Zeichenfolgen sind, und ein optionales capacity-Objekt, das eine storage-Zeichenfolge enthält. 
...
    variables:
      #nodePoolVolumes is an optional set of PVCs to create and
      #attach to each node; use for high-churn components like containerd
      - name: nodePoolVolumes
        value: |
          #name of the PVC to be used as the suffix (node.name)
          - name: etcd
            #mountPath is the directory where the volume device is mounted
            #takes the form /dir/path
            mountPath: /var/lib/containerd
            #storageClass is the storage class to use for the PVC
            storageClass: tkgs-storage-profile
            #capacity is the PVC storage capacity
            capacity:
              #storage sets the capacity for the disk volume
              #if not specified defaults to storageClass capacity
              storage: 4Gi

ntp

Verwenden Sie die ntp-Variable, um einen NTP-Server für den Cluster zu konfigurieren.

ntp
Zeichenfolge, die den FQDN oder die IP-Adresse eines NTP-Servers darstellt.
Die NTP-Variable gibt den Domänennamen des NTP-Servers an, wie im Beispiel gezeigt. Der NTP-Server wird bei der Clustererstellung in die Clustervariable eingefügt. Nach der Clustererstellung verwalten Sie die Rotation des Servernamens oder ein beliebiges Update, indem Sie die Clustervariable manuell aktualisieren. 
...
    variables:
    - name: ntp
      value: time1.vmware.com

podSecurityStandard

Verwenden Sie die Variable podSecurityStandard, um clusterweite Pod-Sicherheit zu konfigurieren.
Hinweis: Hierbei handelt es sich um eine neue Variable für vSphere 8 Update 3 ( TKG-Dienst 3.0).
podSecurityStandard

Mit TKr v1.26 und höher werden Pod-Sicherheitseinschränkungen (PSA) auf Namespace-Ebene standardmäßig mithilfe von Anmerkungsbezeichnungen erzwungen. Weitere Informationen hierzu finden Sie unter Konfigurieren von PSA für TKR 1.25 und höher.

Alternativ können Sie mithilfe der Variable podSecurityStandard clusterweite PSA konfigurieren, wenn Sie einen v1beta1-Cluster bereitstellen oder aktualisieren.

Die Variable podSecurityStandard kann folgendermaßen implementiert werden:

...
variables:
- name: podSecurityStandard
  value: 
    deactivated: DEACTIVATED
    audit: AUDIT-PROFILE
    enforce: ENFORCE-PROFILE
    warn: WARN-PROFILE
    auditVersion: AUDIT-VERSION
    enforceVersion: ENFORCE-VERSION
    warnVersion: WARN-VERSION
    exemptions: 
      namespaces: [EXEMPT-NS]
Dabei gilt:
  • Der Wert DEACTIVATED ist auf false (Standardeinstellung) festgelegt, um clusterweite PSA anzuwenden, andernfalls lautet er auf true.
  • Bei dem Wert *-PROFILE handelt es sich um das PSA-Profil für jeden Modus, der auf "privileged", "baseline" oder "restricted" (Standardeinstellung) lauten kann.
  • Der Wert *-VERSION stellt die Kubernetes-Version für jeden Modus dar, wie z. B. "v1.26". Der Wert "latest" ist der Standardwert.
  • Bei dem Wert EXEMPT-NS handelt es sich um eine kommagetrennte Liste von Namespaces, die aus der PSA-Steuerung ausgeschlossen werden sollen.
Hinweis: System-Namespaces werden aus der Pod-Sicherheit ausgeschlossen, einschließlich kube-system, tkg-system und vmware-system-cloud-provider.

Wenn Sie die Variable podSecurityStandard nicht implementieren, wird das PSA-Standardverhalten beibehalten. Wenn Sie die Variable podSecurityStandard in die Clusterspezifikation aufnehmen, übernehmen die Variableneinstellungen die Steuerung, einschließlich der Standardwerte, es sei denn, sie werden überschrieben.

Im folgenden Beispiel werden die Standardwerte angezeigt. 
...
    variables:
      - name: podSecurityStandard
        value:
          enforce: "restricted"
          enforce-version: "latest"
Das folgende Beispiel enthält Überwachungsprotokolle und Warnungen zur Erkennung von Arbeitslasten, die die Best Practices für die Pod-Härtung nicht einhalten, sondern lediglich eine minimal restriktive Richtlinie („Baseline“) erzwingen, die bekannte Berechtigungseskalationen verhindert. 
...
    variables:
      - name: podSecurityStandard
        value:
          audit: "restricted"
          warn: "restricted"
          enforce: "baseline"
Im folgenden Beispiel wird eine eingeschränkte Richtlinie erzwungen. Ein bestimmter Namespace ist jedoch davon ausgenommen. 
...
    variables:
      - name: podSecurityStandard
        value:
          audit: "restricted"
          warn: "restricted"
          enforce: "restricted"
          exemptions:
            namesaces: ["privileged-workload-ns"]
Im folgenden Beispiel beschränkt sich die Erzwingung auf eine bestimmte TKr-Version. 
...
variables:
  - name: podSecurityStandard
    value: 
      audit-version: "v1.26"
      warn-version: "v1.26"
      enforce-version: "v1.26"

Weitere Beispiele finden Sie unter Pod Security Standards in der Kubernetes-Dokumentation.

Proxy

Verwenden Sie die proxy-Variable, um einen Proxyserver für den Cluster zu konfigurieren.

Proxy
Objekt mit Parametern, die auf einen Proxyserver für ausgehende Clusterverbindungen verweisen.
Zu den erforderlichen proxy-Parametern gehören httpProxy, httpsProxy und noProxy. Alle drei Felder sind erforderlich, wenn Sie die Variable proxy in die Clusterdefinition aufnehmen.
Die Felder httpProxy und httpsProxy enthalten Zeichenfolgenwerte, die auf den URI eines Proxyservers verweisen, der für die Verwaltung von ausgehenden HTTP- und HTTPS-Verbindungen vom TKG-Cluster konfiguriert ist. Sie können mithilfe von HTTP eine Verbindung zum Proxy-Server herstellen. HTTPS-Verbindungen werden nicht unterstützt.
Das Feld noProxy ist ein Array von Zeichenfolgen. Rufen Sie die noProxy-Werte über das Supervisor-Arbeitslastnetzwerk ab. Im Feld noProxy müssen Sie das Namespace-Netzwerk sowie die Ingress- und Egress-Subnetze angeben.
Das Dienste-Subnetz müssen Sie nicht in das Feld noProxy eingeben. Der TKG-Cluster interagiert nicht mit diesem Subnetz.
Sie müssen clusterNetwork.services.cidrBlocks und clusterNetwork.pods.cidrBlocks nicht in das Feld noProxy aufnehmen. Diese Endpoints werden nicht automatisch mit einem Proxy verbunden.
Sie müssen localhost und 127.0.0.1 nicht in das Feld noProxy aufnehmen. Diese Endpoints werden nicht automatisch mit einem Proxy verbunden. 
...
    variables:
    #proxy specifies a proxy server to be used for the cluster
    #if omitted no proxy is configured
    - name: proxy
      value:
        #httpProxy is the proxy URI for HTTP connections
        #to endpoints outside the cluster
        httpProxy: http://<user>:<pwd>@<ip>:<port>
        #httpsProxy is the proxy URL for HTTPS connections 
        #to endpoints outside the cluster
        httpsProxy: http://<user>:<pwd>@<ip>:<port>
        #noProxy is the list of destination domain names, domains, 
        #IP addresses, and other network CIDRs to exclude from proxying
        #must include Supervisor Pod, Egress, Ingress CIDRs
        noProxy: [array of strings, comma-separated]

storageClass

Verwenden Sie die storageClass-Variable, um eine Speicherklasse für den Cluster zu konfigurieren.

storageClass
Zeichenfolge, die dem Namen eines vSphere-Speicherprofils entspricht, das dem vSphere-Namespace zugewiesen wurde, in dem der TKG-Cluster bereitgestellt wird. 
...
    variables:
    - name: storageClass
      value: tkgs-storage-profile
Verwenden Sie den folgenden Befehl zum Auflisten verfügbarer Speicherklassen: 
kubectl describe namespace VSPHERE-NAMESPACE-NAME
Oder, wenn Sie über vSphere-Administratorrechte verfügen: 
kubectl describe storageclasses

storageClasses

Verwenden Sie die storageClasses-Variable, um ein Array von Speicherklassen für den Cluster zu konfigurieren.

storageClasses
Array aus einer oder mehreren Zeichenfolgen, wobei jede Zeichenfolge der Name eines vSphere-Speicherprofils ist, das dem vSphere-Namespace zugewiesen wurde, in dem der TKG-Cluster bereitgestellt wird. 
...
    variables:
    - name: storageClasses
      value: [tkg2-storage-profile, tkg2-storage-profile-latebinding]
Verwenden Sie den folgenden Befehl zum Auflisten verfügbarer Speicherklassen: 
kubectl describe namespace VSPHERE-NAMESPACE-NAME
Oder, wenn Sie über vSphere-Administratorrechte verfügen: 
kubectl describe storageclasses

TKR_DATA

Verwenden Sie die TKR_DATA-Variable, um TKR-Informationen anzugeben.

TKR_DATA
Objekt, das Sie zum Angeben der TKR-Version und anderer Details verwenden.
version ist eine Zeichenfolge im TKR NAME-Format, die von Clusterknoten verwendet wird.
Nur TKRs, die nicht über die legacy-tkr-Bezeichnung verfügen, sind mit TKG auf vSphere 9 Supervisor kompatibel. Weitere Informationen hierzu finden Sie unter Verwenden von Kubernetes-Versionen mit TKG-Dienstclustern.
Das Standardbetriebssystem ist PhotonOS. Verwenden Sie Anmerkungen, um die Ubuntu TKR anzugeben.

trust

Verwenden Sie die trust-Variable, um ein oder mehrere vertrauenswürdige CA-Zertifikate für den Cluster anzugeben.

trust
Objekt zum Hinzufügen von TLS-Zertifikaten zum Cluster, entweder zusätzliche Zertifizierungsstellen oder Endzertifikate.
Der Wert lautet additionalTrustedCAs und enthält ein Array von Zeichenfolgen. Beispiel: 
#trust-example
    variables:
      - name: trust
        value:
          additionalTrustedCAs:
          - name: additional-ca-1
          - name: additional-ca-2
          - name: additional-ca-N
Der Wert jeder Zeichenfolge ist der benutzerdefinierte Name für das Datenzuordnungsfeld im geheimen Kubernetes-Schlüssel, der das doppelt Base64-codierte CA-Zertifikat im PEM-Format enthält. Beispiel: 
#secret-example
apiVersion: v1
data:
  additional-ca-1: TFMwdExTMUNSGlSzZ3Jaa...VVNVWkpRMEMwdExTMHRDZz09
kind: Secret
metadata:
  name: cluster01-user-trusted-ca-secret
  namespace: tkgs-cluster-ns
type: Opaque
Ein häufiger Anwendungsfall für die vertrauenswürdige Variable besteht in der Integration eines v1beta1-Clusters in eine private Containerregistrierung. Informationen dazu finden Sie unter Integrieren von TKG-Dienst-Clustern in eine private Containerregistrierung

Benutzer

Verwenden Sie die user-Variable, um die Anmeldedaten für Clusterbenutzer anzugeben.

Benutzer
Objekt, das ein passwordSecret-Objekt mit Namen und Schlüsselzeichenfolgen sowie eine sshAuthorizedKey-Zeichenfolge enthält. Sie können diese Variable verwenden, um den SSH-Schlüssel eines Benutzers zu Clusterknoten für den Remote-SSH-Zugriff hinzuzufügen.
Die Benutzervariable gibt die SSH-Anmeldedaten an, einschließlich Kennwort und autorisierter Schlüssel. Der Benutzername lautet standardmäßig vmware-system-user. Das Kennwort muss gehasht und in einem geheimen Schlüssel im selben Namespace gespeichert werden, in dem der Cluster bereitgestellt wird. Das Objekt passwordSecret verweist auf diesen geheimen Schlüssel. Unter Linux können Sie beispielsweise mit mkpasswd --method=SHA-512 --rounds=4096 einen sicheren Hash generieren. Weitere Informationen finden Sie unter Einschließen von Benutzern und Gruppen. 
...
    variables:
    #user specifies an authorized user and credentials
    - name: user
      value:
        #passwordSecret is an object that contains a Kubernetes secret and key
        passwordSecret:
          #name specifies the secret name
          name: string
          #key specifies the key value pair in the secret's data map
          key: string
        sshAuthorizedKey: string that is the base64-encoded public key

vmClass

Verwenden Sie die vmClass-Variable, um die VM-Klasse für Clusterknoten zu konfigurieren.

vmClass
Erforderliche Zeichenfolge, die dem Namen einer VM-Klasse zugeordnet ist, die an den vSphere-Namespace gebunden ist, in dem der TKG-Cluster bereitgestellt wird.
vmClass ist der Name der VirtualMachineClass, die die für Clusterknoten zu verwendenden virtuellen Hardwareeinstellungen beschreibt. Die VirtualMachineClass steuert die für den Knoten verfügbare CPU und den Arbeitsspeicher sowie die Anforderungen und Grenzwerte für diese Ressourcen. Weitere Informationen finden Sie unter Verwenden von VM-Klassen mit TKG-Dienstclustern.
Sie können nur VM-Klassen verwenden, die mit dem vSphere-Namespace verknüpft sind, in dem der TKG-Cluster bereitgestellt wird. Verwenden Sie den Befehl kubectl get virtualmachineclass, um gebundene Klassen aufzulisten.
Sie können die Variable vmClass in unterschiedlichen Geltungsbereichen definieren, sodass Sie verschiedene VM-Klassen für Steuerungsebenenknoten und Knotenpool-Worker-Knoten verwenden können.
Beispiel: Hier überschreibt ( overrides) eine Inline- vmClass-Variable die primäre Variable vmClass für diese spezifische machineDeployment-Topologie. 
...
    workers:
      machineDeployments:
      - class: tkg-worker
        name: compute
        replicas: 3
        variables:
          overrides:
          - name: vmClass
            value: guaranteed-large