Konfiguration von Legacy-Clustern mit ytt

In diesem Thema wird beschrieben, wie Sie mit ytt-Overlays Legacy-TKC- und planbasierte Arbeitslastcluster konfigurieren, die von Tanzu Kubernetes Grid (TKG) bereitgestellt wurden, um diejenigen Eigenschaften der Cluster und der zugrunde liegenden Objekte festzulegen, die nicht über Konfigurationsvariablen in einer Clusterkonfigurationsdatei konfiguriert werden können. Diese sind unter den folgenden Themen aufgeführt: Konfigurieren eines vom Supervisor bereitgestellten Clusters mit einer Konfigurationsdatei (TKC-Cluster) bzw. Variablenreferenz für Konfigurationsdatei (planbasierte Cluster).

ytt-Overlays werden für klassenbasierte Cluster nicht benötigt und nicht unterstützt. Für diese Cluster können konfigurierbaren Eigenschaften allgemein innerhalb des vereinfachten Cluster-Objekts selbst festgelegt werden. Wenn die Tanzu CLI bei der Ausführung von tanzu cluster create für einen klassenbasierten Cluster ytt auf Ihrem Computer erkennt, wird ein Fehler It seems like you have done some customizations to the template overlays. ausgegeben.

Überblick

Für die erweiterte Konfiguration von TKC- und planbasierten Arbeitslastclustern können Sie zum Konfigurieren von Objekteigenschaften, die nicht durch Clusterkonfigurationsvariablen festgelegt werden können, TKC-, planbasierte Cluster- und Clusterplankonfigurationsdateien im lokalen ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere-Verzeichnis einer beliebigen Bootstrap-Maschine anpassen.

Sie können diese Konfigurationen anpassen, indem Sie Konfigurationsdateien direkt hinzufügen oder ändern oder ytt-Overlays verwenden.

Die direkte Anpassung von Konfigurationsdateien ist einfacher, aber wenn Sie mit ytt-Overlays vertraut sind, können Sie Konfigurationen in verschiedenen Geltungsbereichen anpassen und mehrere modulare Konfigurationsdateien verwalten, ohne die übernommenen und Upstream-Konfigurationswerte destruktiv zu bearbeiten. ytt-Overlays gelten nur für neue TKC- und planbasierte Arbeitslastcluster, die über die Tanzu CLI erstellt werden.

Weitere Informationen dazu, wie verschiedene Formen der Clusterkonfiguration funktionieren und welchen Vorrang sie haben, finden Sie in den Informationen zu Tanzu Kubernetes Grid unter Informationen zur Konfiguration von TKC- und planbasierten Legacy-Clustern.

`ytt`-Verhaltensweisen und -Konventionen

Zu den Verhaltensweisen und Konventionen für die Verarbeitung von ytt gehören:

Vorrang: ytt durchläuft Verzeichnisse der Tiefe nach zuerst in alphabetischer Reihenfolge der Dateinamen und überschreibt im Verlauf doppelte Einstellungen. Wenn doppelte Definitionen vorhanden sind, hat die von ytt zuletzt verarbeitete Definition Vorrang.

Overlay-Typen: Verschiedene ytt-Overlay-Typen ändern oder legen verschiedene Elemente fest:

Datenwertdateien legen Konfigurationswerte fest oder ändern diese, ohne die Strukturen von Objekten zu ändern. Dazu gehören Stücklistendateien (BoM-Dateien) und nach Konvention Dateien mit data in den Dateinamen.
Overlay-Dateien nehmen Änderungen an Objektstrukturdefinitionen vor. Der Konvention gemäß weisen diese Dateien overlay in ihren Dateinamen auf.

Weitere Informationen zu ytt, einschließlich Overlay-Beispielen und einem interaktiven Validator-Tool, finden Sie unter:

Carvel Tools> ytt > Interactive Playground
The IT Hollow: Using YTT to Customize TKG Deployments

Cluster und Clusterpläne

Für TKC- und planbasierte Cluster enthält das ~/.config/tanzu/tkg/providers/-Verzeichnis der Bootstrap-Maschine ytt-Verzeichnisse und overlay.yaml-Dateien auf verschiedenen Ebenen, mit denen Sie den Geltungsbereich von Konfigurationseinstellungen auf jeder Ebene festlegen können.

Anbieter- und versionsspezifische ytt-Verzeichnisse. Beispiel: ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/v1.1.0.
- Spezifische Konfigurationen für die Anbieter-API-Version.
- Die Datei base-template.yaml enthält Platzhalter in Großbuchstaben wie "${CLUSTER_NAME}" und darf nicht bearbeitet werden.
- Die Datei overlay.yaml ist auf Overlay-Werte in base-template.yaml zugeschnitten.
Anbieterweite ytt-Verzeichnisse. Beispiel: ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt.
- Anbieterweite Konfigurationen, die für alle Versionen gelten.
ytt-Verzeichnis auf der obersten Ebene, ~/.config/tanzu/tkg/providers/infrastructure-tkg-service-vsphere/ytt.
- Anbieterübergreifende Konfigurationen.
- In nummerierten Verzeichnissen organisiert und in numerischer Reihenfolge verarbeitet.
- Sie können ein Unterverzeichnis /04_user_customizations für Konfigurationen erstellen, die Vorrang vor allen ytt-Unterverzeichnissen mit niedrigeren Nummern haben.

`ytt`-Overlays

Dieser Abschnitt enthält Overlays zum Anpassen von planbasierten Arbeitslastclustern, die von einem eigenständigen Verwaltungscluster bereitgestellt wurden, und zum Erstellen neuer Clusterpläne.

Beschränkungen:

Zum Ändern von Arbeitslastclustern können Sie nur ytt-Overlays verwenden. Die Verwendung von ytt-Overlays zum Ändern eigenständiger Verwaltungscluster wird nicht unterstützt.
Overlays von Arbeitslastclustern werden nur bei der Clustererstellung angewendet und ändern vorhandene Cluster nicht. Informationen zum Ändern vorhandener Cluster finden Sie unter Ändern von Ressourcen in vorhandenen Clustern.

Die folgenden Beispiele zeigen, wie Sie Overlay-Konfigurationsdateien verwenden, um Arbeitslastcluster anzupassen und einen neuen Clusterplan zu erstellen.

Informationen zu einem Overlay, das die vertrauenswürdigen Zertifikate in einem Cluster angepasst, finden Sie unter Konfigurieren von Clustern mit mehreren vertrauenswürdigen Registrierungen im Thema Verwalten von geheimen Schlüsseln und Zertifikaten für Cluster.

Namenserver auf vSphere

In diesem Beispiel werden ein oder mehrere benutzerdefinierte Namenserver zu Worker-Knoten und Knoten der Steuerungsebene in legac7 Tanzu Kubernetes Grid-Clustern auf vSphere hinzugefügt. Die DNS-Auflösung über DHCP wird deaktiviert, sodass die benutzerdefinierten Namenserver Vorrang haben.

Um benutzerdefinierte Namenserver in einem klassenbasierten Cluster zu konfigurieren, verwenden Sie die Konfigurationsvariablen CONTROL_PLANE_NODE_NAMESERVERS und WORKER_NODE_NAMESERVERS.

Zwei Overlay-Dateien gelten für Knoten der Steuerungsebene, die anderen beiden für Worker-Knoten. Sie fügen alle vier Dateien zu Ihrem Verzeichnis ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ hinzu.

Overlay-Dateien unterscheiden sich je nachdem, ob die Knoten auf Ubuntu- oder Photon Maschine-Images basieren, und für Ubuntu benötigen Sie keine DHCP-Overlay-Dateien.

Eine Zeile in jeder overlay-dns-Datei legt die Nameserver-Adressen fest. Der folgende Code zeigt einen einzelnen Namenserver an, aber Sie können mehrere Namenserver als Liste angeben, z. B. nameservers: ["1.2.3.4","5.6.7.8"].

Datei vsphere-overlay-dns-control-plane.yaml:

Ubuntu:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          #@overlay/match missing_ok=True
          dhcp4Overrides:
            useDNS: false

Photon:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]

Datei vsphere-overlay-dns-workers.yaml:

Ubuntu:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          #@overlay/match missing_ok=True
          dhcp4Overrides:
            useDNS: false

Photon:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]

Datei vsphere-overlay-dhcp-control-plane.yaml (nur Photon):

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    preKubeadmCommands:
    #! disable dns from being emitted by dhcp client
    #@overlay/append
    - echo '[DHCPv4]' >> /etc/systemd/network/10-cloud-init-eth0.network
    #@overlay/append
    - echo 'UseDNS=false' >> /etc/systemd/network/10-cloud-init-eth0.network
    #@overlay/append
    - '/usr/bin/systemctl restart systemd-networkd 2>/dev/null'

Datei vsphere-overlay-dhcp-workers.yaml (nur Photon):

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      preKubeadmCommands:
      #! disable dns from being emitted by dhcp client
      #@overlay/append
      - echo '[DHCPv4]' >> /etc/systemd/network/10-cloud-init-eth0.network
      #@overlay/append
      - echo 'UseDNS=false' >> /etc/systemd/network/10-cloud-init-eth0.network
      #@overlay/append
      - '/usr/bin/systemctl restart systemd-networkd 2>/dev/null'

FQDN-Steuerungsebenen-Endpoint mit NSX ALB

Um Arbeitslastcluster unter vSphere mit NSX Advanced Load Balancer zu erstellen, die mit VSPHERE_CONTROL_PLANE_ENDPOINT konfiguriert sind, der statt auf eine IP-Adresse auf einen FQDN festgelegt ist, erstellen Sie eine Overlay-Datei im Verzeichnis .config/tanzu/tkg/providers/infrastructure-vsphere/ytt/, wie z. B. fqdn-cert-api.yaml, mit folgendem Inhalt:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"}), expects="1+"
#@overlay/match-child-defaults missing_ok=True
---

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: #@ "{}-control-plane".format(data.values.CLUSTER_NAME)
spec:
  kubeadmConfigSpec:
    clusterConfiguration:
      apiServer:
        certSANs:
        - CONTROLPLANE-FQDN

Dabei ist CONTROLPLANE-FQDN der FQDN für die Steuerungsebene des Arbeitslastclusters.

Erstellen Sie den Cluster, wenn das Overlay vorhanden ist.

Führen Sie nach dem Erstellen des Clusters das Verfahren unter Konfigurieren von DHCP-Reservierungen für Knoten und DNS-Datensätzen für Endpoints (nur vSphere) aus, um einen DNS-Datensatz zu erstellen.

Ändern Sie vor dem Erstellen jedes zusätzlichen Clusters mit einem FQDN-Endpoint die Einstellung CONTROLPLANE-FQDN im Overlay nach Bedarf.

Auflösen der Domäne .local

In modernen Linux-Systemen können Versuche, Hostnamen aufzulösen, deren Domänensuffix auf .local endet, fehlschlagen. Dieses Problem tritt auf, weil systemd-networkd, der DNS-Auflöser in den meisten Linux-Distributionen, versucht, die Domäne .local über Multicast-DNS (mDNS) und nicht über Standard-DNS-Server aufzulösen.

Verwenden Sie zum Konfigurieren der Domänenauflösung .local in einem klassenbasierten Cluster die Konfigurationsvariablen CONTROL_PLANE_NODE_SEARCH_DOMAINS und WORKER_NODE_SEARCH_DOMAINS.

Um dieses bekannte Problem in Legacy-Clustern vorübergehend zu beheben, fügen Sie eine Zeile searchDomains mit Ihrem lokalen Domänensuffix am Ende der Dateien vsphere-overlay-dns-control-plane.yaml und vsphere-overlay-dns-workers.yaml im Verzeichnis ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ hinzu.

Beispiel für die Datei vsphere-overlay-dns-control-plane.yaml:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-control-plane"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          searchDomains: ["corp.local"]

Beispiel für die Datei vsphere-overlay-dns-workers.yaml:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"VSphereMachineTemplate", "metadata": {"name": data.values.CLUSTER_NAME+"-worker"}})
---
spec:
  template:
    spec:
      network:
        devices:
        #@overlay/match by=overlay.all, expects="1+"
        -
          #@overlay/match missing_ok=True
          nameservers: ["8.8.8.8"]
          searchDomains: ["corp.local"]

Konfigurieren von NTP ohne DHCP-Option 42 (vSphere)

Die TLS-Authentifizierung innerhalb von Tanzu Kubernetes Grid-Clustern erfordert eine präzise Uhrzeitsynchronisierung. In den meisten DHCP-basierten Umgebungen können Sie die Synchronisierung mithilfe der DHCP-Option 42 konfigurieren.

Wenn Sie Legacy-Cluster in einer vSphere-Umgebung ohne DHCP-Option 42 bereitstellen, verwenden Sie den Overlay-Code wie folgt, damit Tanzu Kubernetes Grid Cluster mit NTP-Servern erstellt, die die Synchronisierung aufrechterhalten

Um NTP in einem klassenbasierten Cluster zu konfigurieren, verwenden Sie die Konfigurationsvariable NTP_SERVERS.

Erstellen Sie im Verzeichnis ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ eine neue .yaml-Datei oder vergrößern Sie eine vorhandene Overlay-Datei mit dem folgenden Code, indem Sie das Beispiel time.google.com in den gewünschten NTP-Server ändern:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    #@overlay/match missing_ok=True
    ntp:
      #@overlay/match missing_ok=True
      enabled: true
      #@overlay/match missing_ok=True
      servers:
        - time.google.com

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      #@overlay/match missing_ok=True
      ntp:
        #@overlay/match missing_ok=True
        enabled: true
        #@overlay/match missing_ok=True
        servers:
          - time.google.com

Benutzerdefinierte Knotenbezeichnungen

Dieses Overlay weist den Clusterknoten dauerhafte Bezeichnungen zu, wenn der Legacy-Cluster erstellt wird. Dies ist nützlich, da Bezeichnungen, die manuell über kubectl angewendet werden, bei einer Knotenersetzung nicht beibehalten werden.

Weitere Informationen finden Sie unter Zusätzliche Variablen in ytt-Overlays.

Um benutzerdefinierte Knotenbezeichnungen für Knoten der Steuerungsebene in einem klassenbasierten Cluster zu konfigurieren, verwenden Sie die Konfigurationsvariable CONTROL_PLANE_NODE_LABELS.

Erstellen Sie im Verzeichnis ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ eine neue .yaml-Datei oder erweitern Sie eine vorhandene Overlay-Datei mit dem folgenden Code.

Konfigurieren Sie für Bezeichnungen von Knoten der Steuerungsebene sowohl den Abschnitt initConfiguration als auch den Abschnitt joinConfiguration, sodass Bezeichnungen auf den ersten erstellten Knoten und alle anschließend hinzugefügten Knoten angewendet werden:
```
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
  kubeadmConfigSpec:
    initConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          #@overlay/match missing_ok=True
          node-labels: NODE-LABELS
    joinConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          #@overlay/match missing_ok=True
          node-labels: NODE-LABELS
```
Dabei ist NODE-LABELS eine kommagetrennte Liste von Schlüssel-/Wertzeichenfolgen der Bezeichnungen, die node-type=control-plane enthält, z. B. "examplekey1=labelvalue1,examplekey2=labelvalue2".

Für Worker-Knotenbezeichnungen:
```
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            #@overlay/match missing_ok=True
            node-labels: NODE-LABELS
```
Dabei ist NODE-LABELS eine kommagetrennte Liste von Schlüssel-/Wertzeichenfolgen der Bezeichnungen, die node-type=worker enthält, z. B. "examplekey1=labelvalue1,examplekey2=labelvalue2".

Deaktivieren des Bastion-Hosts unter AWS

Ein Beispiel für ein Overlay, das den Bastion-Host für Arbeitslastcluster unter AWS deaktiviert, finden Sie unter Deaktivieren des Bastion-Servers unter AWS im TKG Lab-Repository.

Neuer Plan `nginx`

In diesem Beispiel wird ein neuer Arbeitslastclusterplan nginx hinzugefügt und konfiguriert, der einen nginx-Server ausführt. Er verwendet den Cluster Resource Set (CRS) zum Bereitstellen des nginx-Servers auf vSphere-Clustern, die mit der vSphere-Cluster-API-Anbieterversion v0.7.6 erstellt wurden.

Fügen Sie in .tkg/providers/infrastructure-vsphere/v0.7.6/ eine neue Datei cluster-template-definition-nginx.yaml mit Inhalten hinzu, die mit den Dateien cluster-template-definition-dev.yaml und cluster-template-definition-prod.yaml identisch sind:
```
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TemplateDefinition
spec:
  paths:
    - path: providers/infrastructure-vsphere/v0.7.6/ytt
    - path: providers/infrastructure-vsphere/ytt
    - path: providers/ytt
    - path: bom
      filemark: text-plain
    - path: providers/config_default.yaml
```
Wenn diese Datei vorhanden ist, wird ein neuer Plan erstellt, und die tanzu-CLI analysiert den Dateinamen, um die Option nginx zu erstellen, die an tanzu cluster create --plan übergeben wird.

Erstellen Sie in ~/.config/tanzu/tkg/providers/ytt/04_user_customizations/ eine neue Datei deploy_service.yaml, die Folgendes enthält:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#@ load("@ytt:yaml", "yaml")

#@ def nginx_deployment():
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
#@ end

#@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx":

---
apiVersion: addons.cluster.x-k8s.io/v1beta1
kind: ClusterResourceSet
metadata:
  name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
  labels:
    cluster.x-k8s.io/cluster-name: #@ data.values.CLUSTER_NAME
spec:
  strategy: "ApplyOnce"
  clusterSelector:
    matchLabels:
      tkg.tanzu.vmware.com/cluster-name: #@ data.values.CLUSTER_NAME
  resources:
  - name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
    kind: ConfigMap
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: #@ "{}-nginx-deployment".format(data.values.CLUSTER_NAME)
type: addons.cluster.x-k8s.io/resource-set
stringData:
  value: #@ yaml.encode(nginx_deployment())

#@ end

In dieser Datei wendet das bedingte #@ if data.values.TKG_CLUSTER_ROLE == "workload" and data.values.CLUSTER_PLAN == "nginx": das nachfolgende Overlay auf Arbeitslastcluster mit dem Plan nginx an.

Wenn das Verzeichnis 04_user_customizations noch nicht unter dem ytt-Verzeichnis auf der obersten Ebene vorhanden ist, erstellen Sie es.

Zusätzliche Variablen in `ytt`-Overlays

Overlays wenden ihre Konfigurationen auf alle neu erstellten Cluster an. Um Cluster einzeln mit unterschiedlichen Overlay-Einstellungen anzupassen, können Sie Overlays mit benutzerdefinierten Variablen kombinieren, die Sie zur Clusterkonfiguration hinzufügen.

Dieses Beispiel zeigt, wie Sie zusätzliche Clusterkonfigurationsvariablen verwenden, um benutzerdefinierte Knotenbezeichnungen für verschiedene Cluster festzulegen.

Hinweis
Nach dem Upgrade der Tanzu CLI müssen Sie diese Änderungen erneut auf das neue Verzeichnis ~/.config/tanzu/tkg/providers anwenden. Die vorherige Version wird als Sicherung mit Zeitstempel umbenannt.

Knotenbezeichnungen über Konfigurationsvariable

Durch das Hinzufügen einer WORKER_NODE_LABELS-Variablen zu den Standardkonfigurations- und Clusterkonfigurationsdateien können neue Cluster mit unterschiedlichen Worker-Knotenbezeichnungen erstellt werden.

Bearbeiten Sie ~/.config/tanzu/tkg/providers/config_default.yaml und fügen Sie unten den benutzerdefinierte Variablenstandard hinzu:
```
#! ---------------------------------------------------------------------
#! Custom variables
#! ---------------------------------------------------------------------

WORKER_NODE_LABELS: ""
```
Wenn Sie diese Standardeinstellung festlegen, wird verhindert, dass unerwünschte Bezeichnungen zu einem Cluster hinzugefügt werden, wenn diese Variable in der Konfigurationsdatei nicht vorhanden ist.
Fügen Sie eine Zeile am Ende von ~/.config/tanzu/tkg/providers/ytt/lib/config_variable_association.star oberhalb der abschließenden Klammer hinzu, die die neue Variable einem Anbietertyp zuweist.
```
"WORKER_NODE_LABELS": ["vsphere", "aws", "azure"],
}

end
```

Erstellen Sie im Verzeichnis ~/.config/tanzu/tkg/providers/infrastructure-vsphere/ytt/ eine neue .yaml-Datei oder erweitern Sie eine vorhandene Overlay-Datei mit dem folgenden Code, der die Variable WORKER_NODE_LABELS als Datenwert hinzufügt:

#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")

#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}),expects="1+"
---
spec:
  template:
    spec:
      joinConfiguration:
        nodeRegistration:
          kubeletExtraArgs:
            #@overlay/match missing_ok=True
            node-labels: #@ data.values.WORKER_NODE_LABELS

Für jeden neuen Arbeitslastcluster können Sie jetzt WORKER_NODE_LABEL in dessen Clusterkonfigurationsvariablendatei festlegen, um den zugehörigen Wert als Bezeichnung auf jeden Clusterknoten anzuwenden.
```
WORKER_NODE_LABELS: "workload-classification=production"
```

Ändern von Ressourcen in vorhandenen Clustern

ytt-Overlays gelten nur für neue planbasierte Arbeitslastcluster, die Sie mithilfe der bei einem eigenständigen Verwaltungscluster angemeldeten Tanzu CLI bereitstellen. Um die Ressourcen eines bereits vorhandenen Clusters zu ändern, müssen Sie sie im eigenständigen Verwaltungscluster ändern und an den Arbeitslastcluster weitergeben, wie unten beschrieben.

Ändern von NTP ohne DHCP-Option 42 (vSphere)

In diesem Vorgang erhalten vorhandene Cluster dieselbe Änderung, die das Overlay Konfigurieren von NTP ohne DHCP-Option 42 (vSphere) auf neue Cluster anwendet.

Für das Ändern der NTP-Einstellungen auf einem vorhandenen Cluster ist Folgendes erforderlich:

Erstellen einer neuen KubeadmConfigTemplate-Ressource, um die neuen Einstellungen widerzuspiegeln
Aktualisieren der MachineDeployment, damit die Worker-Knoten auf die neue Ressource verweisen
Aktualisieren der Ressource KubeadmControlPlane zum Aktualisieren der Knoten der Steuerungsebene
- Das Aktualisieren von NTP auf Knoten der Steuerungsebene ist in Tanzu Kubernetes Grid-Versionen vor v1.5 nicht möglich.

Um NTP-Einstellungen auf einem vorhandenen Cluster zu ändern, führen Sie Folgendes in dem Verwaltungscluster und in dem Namespace aus, die den zu ändernden Cluster enthalten (in diesem Beispiel cluster1):

Erstellen Sie eine neue Ressource KubeadmConfigTemplate und aktualisieren Sie die MachineDeployment für jedes KubeadmConfigTemplate/MachineDeployment-Paar. Für einen prod-Plancluster führen Sie dies drei Mal aus:
1. Erstellen Sie die neue Ressource KubeadmConfigTemplate für die Worker-Knoten.
  - Suchen Sie die vorhandene KubeadmConfigTemplate und exportieren Sie sie zur Bearbeitung in eine yaml-Datei.
```
kubectl get KubeadmConfigTemplate
kubectl get KubeadmConfigTemplate cluster1-md-0 -o yaml > cluster1-md-0.yaml
```
  - Bearbeiten Sie die exportierte Datei, indem Sie einen Abschnitt ntp unterhalb des vorhandenen Abschnitts spec.template.spec hinzufügen und -v1 an das Feld name unter metadata anhängen, vorausgesetzt, dies ist das erste Update:
```
metadata:
...
  name: cluster1-md-0-v1  # from cluster1-md-0
...
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
```
  - Wenden Sie die aktualisierte yaml-Datei an, um die neue Ressource zu erstellen.
```
kubectl apply -f cluster1-md-0.yaml
```
2. Aktualisieren Sie die Ressource MachineDeployment so, dass sie auf die neu erstellte Ressource KubeadmConfigTemplate verweist.
  1. Suchen und bearbeiten Sie die vorhandene Ressource MachineDeployment für den Cluster.
```
kubectl get MachineDeployment
kubectl edit MachineDeployment cluster1-md-0
```
  2. Bearbeiten Sie den Wert für spec.template.spec.bootstrap.configRef.name, um den neuen Namen der Ressource KubeadmConfigTemplate festzulegen.
```
spec:
  template:
      ...
      spec:
        bootstrap:
          configRef:
            apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
            kind: KubeadmConfigTemplate
            name: cluster1-md-0-v1 # from cluster1-md-0
```
  3. Speichern und beenden Sie die Datei, wodurch die erneute Erstellung der Worker-Knoten ausgelöst wird.
Bearbeiten Sie die Ressource KubeadmControlPlane für die Knoten der Steuerungsebene, um die NTP-Server einzubeziehen.
1. Suchen und bearbeiten Sie die vorhandene Ressource KubeadmControlPlane für den Cluster.
```
kubectl get KubeadmControlPlane
kubectl edit KubeadmControlPlane cluster1-control-plane
```
2. Bearbeiten Sie den Abschnitt spec.kubeadmConfigSpec, indem Sie darunter einen neuen Abschnitt ntp hinzufügen. Speichern und schließen Sie die Datei.
```
kubeadmConfigSpec:
  ntp:
    enabled: true
    servers:
      - time.google.com
```