Cluster auf vSphere

In den folgenden Abschnitten wird beschrieben, wie Sie Tanzu Kubernetes Grid (TKG)-Arbeitslastcluster (TKG) für die Verwendung von Funktionen konfigurieren, die spezifisch für vSphere mit einem eigenständigen Verwaltungscluster sind. Die Funktionen sind in der flachen Konfigurationsdatei des Clusters oder der Objektspezifikation im Kubernetes-Stil nicht vollständig konfigurierbar.

Informationen zum Konfigurieren von Arbeitslastclustern auf vSphere mithilfe von Konfigurationsdateien und Objektspezifikationen finden Sie unter:

Bereitstellen eines Clusters mit einem benutzerdefinierten OVA-Image

Wenn Sie ein einzelnes benutzerdefiniertes OVA-Image für jede Version von Kubernetes verwenden, um Cluster auf einem Betriebssystem bereitzustellen, importieren Sie die OVA in vSphere und geben Sie sie dann für tanzu cluster create mit der Option --tkr an.

Wenn Sie jedoch mehrere benutzerdefinierte OVA-Images für dieselbe Kubernetes-Version verwenden, ist der Wert --tkr mehrdeutig. Dies geschieht, wenn für die OVAs mit derselben Kubernetes-Version Folgendes gilt:

Sie weisen unterschiedliche Betriebssysteme auf, die beispielsweise durch make build-node-ova-vsphere-ubuntu-1804, make build-node-ova-vsphere-photon-3 und make build-node-ova-vsphere-rhel-7 erstellt wurden.
Sie haben denselben Namen, befinden sich aber in unterschiedlichen vCenter-Ordnern.

Um diese Mehrdeutigkeit zu beseitigen, setzen Sie die Option VSPHERE_TEMPLATE auf das gewünschte OVA-Image fest, bevor Sie tanzu cluster create ausführen:

Wenn der Image-Name der OVA-Vorlage eindeutig ist, legen Sie VSPHERE_TEMPLATE nur auf den Image-Namen fest.
Wenn mehrere Images denselben Namen verwenden, legen Sie VSPHERE_TEMPLATE auf den vollständigen Bestandspfad des Images in vCenter fest. Dieser Pfad folgt dem Format /MY-DC/vm/MY-FOLDER-PATH/MY-IMAGE, wobei gilt:
- MY-DC ist das Datencenter, das das OVA-Vorlagen-Image enthält.
- MY-FOLDER-PATH ist der Pfad zum Image aus dem Datencenter, wie in der vCenter-Ansicht VMs und Vorlagen dargestellt..
- MY-IMAGE ist der Image-Name.
Beispiel:
```
VSPHERE_TEMPLATE: "/TKG_DC/vm/TKG_IMAGES/ubuntu-2004-kube-v1.29.9-vmware.1"
```
Sie können den vollständigen vCenter-Bestandspfad des Images manuell ermitteln oder die govc-CLI verwenden:
1. Installieren Sie govc. Installationsanweisungen finden Sie im Repository govmomi auf GitHub.
2. Legen Sie Umgebungsvariablen für govc fest, um auf Ihr vCenter zuzugreifen:
  - export GOVC_USERNAME=VCENTER-USERNAME
  - export GOVC_PASSWORD=VCENTER-PASSWORD
  - export GOVC_URL=VCENTER-URL
  - export GOVC_INSECURE=1
3. Führen Sie govc find / -type m aus und suchen Sie den Image-Namen in der Ausgabe, in der die Objekte nach ihren vollständigen Bestandspfaden aufgelistet werden.

Weitere Informationen zu benutzerdefinierten OVA-Images finden Sie unter Erstellen von Maschinen-Images.

Bereitstellen eines Clusters mit Regions- und Zonen-Tags für CSI

Sie können eine Region und eine Zone für Ihren Arbeitslastcluster angeben, um ihn in für vSphere CSI (Cloud Storage Interface) konfigurierte Regions- und Zonen-Tags zu integrieren. Für Cluster, die sich über mehrere Zonen erstrecken, können Worker-Knoten gemeinsam genutzten Speicher suchen und verwenden, selbst wenn sie in Zonen ohne Speicher-Pods ausgeführt werden, z. B. in einem Telekommunikations-Radio Access Network (RAN).

So stellen Sie einen Arbeitslastcluster mit Regions- und Zonen-Tags bereit, die gemeinsam genutzten Speicher mit vSphere CSI aktivieren:

Erstellen Sie Tags auf vCenter Server:
1. Erstellen Sie Tag-Kategorien auf vCenter Server entsprechend Erstellen, Bearbeiten oder Löschen einer Tag-Kategorie. Beispiel: k8s-region und k8s-zone.
2. Befolgen Sie Erstellen und Bearbeiten eines vSphere-Tags, um Tags innerhalb der Regions- und Zonenkategorien im Datencenter zu erstellen, wie in dieser Tabelle dargestellt:
  
  Kategorie Tags
  
  k8s-zone zone-a
  zone-b
  zone-c
  
  k8s-region region-1

Kategorie	Tags
`k8s-zone`	`zone-a` `zone-b` `zone-c`
`k8s-region`	`region-1`

Erstellen Sie die entsprechenden Tags auf den Clustern und im Datencenter, indem Sie Zuweisen oder Entfernen eines vSphere-Tags befolgen, wie in der Tabelle angegeben.


vSphere-Objekte	Tags
`datacenter`	`region-1`
`cluster1`	`zone-a`
`cluster2`	`zone-b`
`cluster3`	`zone-c`

Um benutzerdefinierte Regionen und Zonen für den CSI-Treiber eines vSphere-Arbeitslastclusters zu aktivieren, legen Sie die Variablen VSPHERE_REGION und VSPHERE_ZONE in der Clusterkonfigurationsdatei auf die obigen Tags fest. Beispiel:
```
VSPHERE_REGION: region-1
VSPHERE_ZONE: zone-a
```
Wenn die Tanzu CLI einen Arbeitslastcluster erstellt, für den diese Variablen festgelegt sind, wird jeder Clusterknoten mit den Topologieschlüsseln failure-domain.beta.kubernetes.io/zone und failure-domain.beta.kubernetes.io/region bezeichnet.
Führen Sie tanzu cluster create aus, um den Arbeitslastcluster wie in Erstellen eines planbasierten oder eines TKC-Clusters beschrieben zu erstellen.
Nachdem Sie den Cluster erstellt haben und der kubectl-Kontext auf den Cluster festgelegt wurde, können Sie die Regions- und Zonenbezeichnungen überprüfen, indem Sie einen der folgenden Schritte ausführen:
- Führen Sie kubectl get nodes -L failure-domain.beta.kubernetes.io/zone -L failure-domain.beta.kubernetes.io/region aus und bestätigen Sie, dass die Ausgabe die Clusterknoten auflistet.
- Führen Sie kubectl get csinodes -o jsonpath='{range .items\[\*\]}{.metadata.name} {.spec}{"\\n"}{end}' aus und bestätigen Sie, dass die Region und die Zone auf vsphere-csi aktiviert sind.

Weitere Informationen zum Konfigurieren von vSphere CSI finden Sie unter vSphere CSI-Treiber – Bereitstellung mit Topologie.

Cluster in verschiedenen vSphere-Konten

Tanzu Kubernetes Grid kann Arbeitslastcluster auf mehreren Konten der Zielplattform ausführen, um beispielsweise die Cloud-Nutzung auf verschiedene Teams aufzuteilen oder unterschiedliche Sicherheitsprofile auf Produktions-, Staging- und Entwicklungsarbeitslasten anzuwenden.

Gehen Sie wie folgt vor, um Arbeitslastcluster für ein alternatives vSphere-Konto bereitzustellen, das sich von dem für die Bereitstellung des Verwaltungsclusters verwendeten Konto unterscheidet:

Legen Sie den Kontext von kubectl auf Ihren Verwaltungscluster fest:
```
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
```
Dabei ist MY-MGMT-CLUSTER der Name Ihres Verwaltungsclusters.
Erstellen Sie eine secret.yaml-Datei mit den folgenden Inhalten:
```
apiVersion: v1
kind: Secret
metadata:
  name: SECRET-NAME
  namespace: CAPV-MANAGER-NAMESPACE
stringData:
  username: VSPHERE-USERNAME
  password: VSPHERE-PASSWORD
```
Dabei gilt:
- SECRET-NAME ist ein Name, den Sie dem geheimen Clientschlüssel geben.
- CAPV-MANAGER-NAMESPACE ist ein Namespace, in dem der capv-manager-Pod ausgeführt wird. Standard: capv-system.
- VSPHERE-USERNAME und VSPHERE-PASSWORD sind Anmeldedaten, die den Zugriff auf das alternative vSphere-Konto ermöglichen.
Verwenden Sie die Datei, um das Secret-Objekt zu erstellen:
```
kubectl apply -f secret.yaml
```
Erstellen Sie eine identity.yaml-Datei mit den folgenden Inhalten:
```
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereClusterIdentity
metadata:
  name: EXAMPLE-IDENTITY
spec:
  secretName: SECRET-NAME
  allowedNamespaces:
    selector:
      matchLabels: {}
```
Dabei gilt:
- EXAMPLE-IDENTITY ist der Name, der für die neue VSphereClusterIdentity-Objekt verwendet werden soll.
- SECRET-NAME ist der Name, den Sie dem geheimen Clientschlüssel gegeben haben (siehe oben).
Verwenden Sie die Datei, um das VsphereClusterIdentity-Objekt zu erstellen:
```
kubectl apply -f identity.yaml
```

Der Verwaltungscluster kann jetzt Arbeitslastcluster für das alternative Konto bereitstellen.

So stellen Sie einen Arbeitslastcluster für das Konto bereit:

Erstellen Sie ein Cluster-Manifest, indem Sie tanzu cluster create --dry-run ausführen.

Bearbeiten Sie die VSphereCluster-Definition im Manifest, um als spec.identityRef.name-Wert für dessen VSphereClusterIdentity-Objekt die oben erstellte EXAMPLE-IDENTITY festzulegen:

...
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: VSphereCluster
metadata:
 name: new-workload-cluster
spec:
 identityRef:
   kind: VSphereClusterIdentity
   name: EXAMPLE-IDENTITY
...

Führen Sie kubectl apply -f my-cluster-manifest.yaml aus, um den Arbeitslastcluster zu erstellen.

Nachdem Sie den Arbeitslastcluster erstellt haben, melden Sie sich mit den Anmeldedaten für das alternative Konto bei vSphere an. Der Cluster müsste dann ausgeführt werden.

Weitere Informationen finden Sie unter Identitätsverwaltung im vSphere-Repository des Cluster-API-Anbieters.

Bereitstellen eines Clusters, der einen Datenspeicher-Cluster verwendet

Hinweis
Diese Funktion funktioniert nicht wie erwartet. Wenn Sie mehrere Datenspeicher in einem Datenspeicher-Cluster als Basis für die Speicherrichtlinie eines Arbeitslastclusters kennzeichnen, verwendet der Arbeitslastcluster nur einen der Datenspeicher.

Um einem Arbeitslastcluster die Verwendung eines Datenspeicher-Clusters anstelle eines einzelnen Datenspeichers zu ermöglichen, richten Sie wie folgt eine Speicherrichtlinie ein, die auf alle Datenspeicher innerhalb des Datenspeicher-Clusters abzielt:

Erstellen Sie ein Tag und ordnen Sie es den relevanten Datenspeichern zu:
1. Erstellen Sie Tag-Kategorien auf vCenter Server entsprechend Erstellen, Bearbeiten oder Löschen einer Tag-Kategorie. Stellen Sie sicher, dass die Kategorie Datastore als zuweisbaren Objekttyp aufweist.
2. Erstellen Sie innerhalb der im vorherigen Schritt erstellten Kategorie ein Tag, wie unter Erstellen eines Tags beschrieben.
3. Weisen Sie das neue Tag allen Datenspeichern zu, die zum Datenspeicher-Cluster gehören (siehe unter Zuweisen oder Entfernen eines Tags).
Erstellen Sie eine Tag-basierte Speicherrichtlinie (siehe unter Erstellen einer VM-Speicherrichtlinie für die Tag-basierte Platzierung).
In der Clusterkonfigurationsdatei:
- Legen Sie als VSPHERE_STORAGE_POLICY_ID den Namen der im vorherigen Schritt erstellten Speicherrichtlinie fest.
- Achten Sie darauf, dass VSPHERE_DATASTORE nicht festgelegt ist. Eine VSPHERE_DATASTORE-Einstellung würde die Einstellung für die Speicherrichtlinie außer Kraft setzen.

Bereitstellen eines Arbeitslastclusters mit mehreren Betriebssystemen

Um einen Arbeitslastcluster mit mehreren Betriebssystemen bereitzustellen, der sowohl über Windows- als auch über Linux-basierte Worker-Knoten verfügt, erstellen Sie ein benutzerdefiniertes Windows-Systemimage, stellen einen Windows-Arbeitslastcluster bereit und fügen dann eine Linux-MachineDeployment hinzu, um den reinen Windows-Arbeitslastcluster in einen Cluster mit mehreren Betriebssystemen zu konvertieren.

Cluster mit mehreren Betriebssystemen können sowohl Windows- als auch Linux-Arbeitslasten hosten, während Linux-basierte TKG-Komponenten auf Worker-Knoten ausgeführt werden, zu denen sie gehören.

Erstellen Sie ein Windows-Maschinen-Image, indem Sie alle Prozeduren unter Benutzerdefinierte Windows-Maschinen-Images ausführen.
Erstellen Sie eine YAML-Datei, z. B. win-osimage.yaml, um ein OSImage im Verwaltungscluster hinzuzufügen, das auf die Vorlage verweist, wenn Sie ein Windows-Systemimage erstellt haben.

Sie können die folgende YAML-Beispieldatei verwenden. Ändern Sie den Wert spec.image.ref.template in den Speicherort der von Ihnen erstellten Windows-Vorlage. Der Pfad ist spezifisch für Ihre vSphere-Umgebung.
```
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: OSImage
metadata:
 name: v1.24.10---vmware.1-tkg.1-windows
spec:
 image:
   ref:
     template: /dc0/vm/windows-2019-kube-v1.24.10+vmware.1-tkg.1
     version: v1.24.10+vmware.1-tkg.1-windows
   type: ova
 kubernetesVersion: v1.24.10+vmware.1
 os:
   arch: amd64
   name: windows
   type: windows
   version: "2019"
```
Führen Sie kubectl apply -f win-osimage.yaml aus, um das OSImage hinzuzufügen.
Fügen Sie die TKR-Version zu spec.osImages hinzu, damit die TKR-Auflösung und die Webhook-Validierung erfolgreich durchgeführt werden. Verwenden Sie den folgenden Befehl, um die Version des TKr zu spec.osImages hinzuzufügen.
```
$ kubectl edit tkr v1.24.10---vmware.x-tkg.x
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
  name: v1.24.10---vmware.x-tkg.x
spec:
  bootstrapPackages:
  # Keep the other packages listed here.
  - name: tkg-windows.tanzu.vmware.com.0.28.1+vmware.1
  osImages:
  # Keep the other images listed here.
  - name: v1.24.10---vmware.1-tkg.1-windows
```
Aktivieren Sie auf der TKR das Paket tkg-windows, indem Sie ein neues Element in der spec.bootstrapPackages hinzufügen. Das Paket lässt sich im offiziellen Repository mit tanzu package available list tkg-windows.tanzu.vmware.com suchen. Es folgt ein Beispiel für ein funktionierendes TKr:
Erstellen Sie eine klassenbasierte Cluster-Objektspezifikation, indem Sie den folgenden Befehl ausführen:
```
tanzu cluster create my-cluster --file my-cluster-config.yaml --dry-run > my-cluster-spec.yaml
```
Dabei gilt: * WINDOWS-CLUSTER ist der Name des Windows-Clusters. * CLUSTER-CONFIG ist der Name der Konfigurationsdatei.

Fügen Sie dem Clusterobjekt die neue Maschinenbereitstellungsklasse tkg-worker in my-cluster-spec.yaml hinzu. Stellen Sie sicher, dass die Anmerkung korrekt ist, damit TKG nach dem Objekt OSImage suchen kann.

Sie können die neue Spezifikation tkg-worker zu spec.workers.machineDeployments hinzufügen, ähnlich wie im folgenden Beispiel:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: WINDOWS-CLUSTER
spec:
  workers:
    machineDeployments:
    - class: tkg-worker
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=photon
        name: md-0-l
        replicas: 1
    - class: tkg-worker-windows
        metadata:
        annotations:
            run.tanzu.vmware.com/resolve-os-image: image-type=ova,os-name=windows
        name: md-0
        replicas: 1

Stellen Sie den Cluster mit mehreren Betriebssystemen bereit, indem Sie den folgenden Befehl ausführen:

tanzu cluster create my-cluster -f my-cluster-spec.yaml

Die Knoten werden mit den Betriebssysteminformationen in Wohlbekannte Bezeichnungen, Anmerkungen und Mäkel gekennzeichnet und markiert.

Hinweis
Das Sichern und Wiederherstellen von Arbeitslastclustern mit mehreren Betriebssystemen wird nicht unterstützt.

Zuverlässigkeit von Windows Antrea CNI

Das HNS-Netzwerk ist auf Windows nicht persistent. Nach dem Neustart des Windows-Knotens wird das von antrea-agent erstellte HNS-Netzwerk entfernt und die Open vSwitch-Erweiterung ist standardmäßig deaktiviert. Entfernen Sie daher nach dem Neustart des Windows-Knotens die veraltete OVS-Bridge und die veralteten Ports. Sie können das Hilfeskript Clean-AntreaNetwork.ps1 verwenden, um die OVS-Bridge zu bereinigen.

Verwenden Sie eine der folgenden Methoden, um das Hilfeskript zu installieren:

Manuelle Installation
Automatisierte Installation

Manuelle Installation

So installieren Sie das Hilfeskript manuell auf jedem isolierten Arbeitslastknoten:

Laden Sie das Installationsskript Clean-AntreaNetwork.ps1 aus diesem Codebeispiel herunter. Das heruntergeladene Installationsskript snippet.ps1 installiert Clean-AntreaNetwork.ps1.
Melden Sie sich über SSH beim Knoten an und führen Sie den folgenden Befehl aus.
```
powershell snippet.ps1
```

Automatisierte Installation

So erstellen Sie eine benutzerdefinierte ClusterClass die das Hilfeskript automatisch auf jedem neuen Arbeitslastknoten installiert:

Führen Sie die Schritte unter Erstellen einer ClusterClass aus, um Ihr benutzerdefiniertes ClusterClass-Objekt zu erstellen.
Wenden Sie den Patch aus diesen Codebeispiel an mithilfe von YTT an und wenden Sie die Spezifikation auf Ihren Verwaltungscluster an:
```
ytt -f custom-cluster-class.yaml -f snippet.yaml | kubectl apply -f -
```

Hinweise zur Sicherheit der verteilten Portgruppe

Wenn Sie Windows- oder MultiOS-Cluster bereitstellen, müssen Sie sicherstellen, dass für die verteilten Portgruppen bestimmte Sicherheitsrichtlinien auf Reject festgelegt sind. Wenn der Promiscuous-Modus beispielsweise auf Accept festgelegt ist, können Knoten zwischen den Zuständen Ready und NotReady wechseln.

Wählen Sie im vSphere Client das Netzwerk aus, das Sie für die Windows-Knoten verwenden, wechseln Sie zu den Einstellungen Virtual Distributed Switch > Sicherheitsrichtlinie der verteilten Portgruppe (Distributed Portgroup Security Policy) und legen Sie diese Richtlinien auf Reject fest:

Promiscuous-Modus
MAC-Adressänderungen
Gefälschte Übertragungen