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:
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:
make build-node-ova-vsphere-ubuntu-1804
, make build-node-ova-vsphere-photon-3
und make build-node-ova-vsphere-rhel-7
erstellt wurden.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:
govc
. Installationsanweisungen finden Sie im Repository govmomi auf GitHub.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
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.
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:
k8s-region
und k8s-zone
.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 |
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.
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.
HinweisDiese 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:
Datastore
als zuweisbaren Objekttyp aufweist.Erstellen Sie eine Tag-basierte Speicherrichtlinie (siehe unter Erstellen einer VM-Speicherrichtlinie für die Tag-basierte Platzierung).
In der Clusterkonfigurationsdatei:
VSPHERE_STORAGE_POLICY_ID
den Namen der im vorherigen Schritt erstellten Speicherrichtlinie fest.VSPHERE_DATASTORE
nicht festgelegt ist. Eine VSPHERE_DATASTORE
-Einstellung würde die Einstellung für die Speicherrichtlinie außer Kraft setzen.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 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.27.5---vmware.2-tkg.1-windows
spec:
image:
ref:
template: /dc0/vm/windows-2019-kube-v1.27.5
version: v1.27.5+vmware.2-tkg.1-windows
type: ova
kubernetesVersion: v1.27.5+vmware.2
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 das neue OSImage- und tkg-windows
-Paket zu der TKR hinzu, die Sie für Ihren MultiOS-Cluster verwenden möchten, damit die TKR-Auflösung und die Webhook-Validierung erfolgreich verlaufen und die Windows-Komponenten installiert werden können.
Verwenden Sie den folgenden Befehl, um die TKR zu bearbeiten und das OSImage als neues Element in spec.osImages
und das tkg-windows
-Paket als neues Element in spec.bootstrapPackages
hinzuzufügen.
$ kubectl edit tkr v1.27.5---vmware.2-tkg.1
Das tkg-windows
-Paket befindet sich im offiziellen Repository mit tanzu package available list tkg-windows.tanzu.vmware.com
. Es folgt ein Beispiel für ein funktionierendes TKr:
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesRelease
metadata:
name: v1.27.5---vmware.2-tkg.1
spec:
bootstrapPackages:
# Add the tkg-windows package to this list AND keep the other packages already listed here under bootstrapPackages.
- name: tkg-windows.tanzu.vmware.com.0.31.0+vmware.1
osImages:
# Add the Windows OSImage name to this list AND kKeep the other images already listed here under osImages.
- name: v1.27.5---vmware.2-tkg.1-windows
HinweisDiese Änderung der TKR wird vom TKR-Controller-Manager nicht überschrieben, auch wenn der TKR-Controller-Manager ständig TKR aus dem TKG-Repository mit Ihrem internen Repository abgleicht, führt dieser Abgleich nicht zu Änderungen, sondern nur zur Erstellung neuer, fehlender TKR
Stellen Sie sicher, dass Ihre MultiOS-Clusterkonfigurationsdatei die folgenden Parameter enthält:
IS_WINDOWS_WORKLOAD_CLUSTER: "true"
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.
HinweisDas Sichern und Wiederherstellen von Arbeitslastclustern mit mehreren Betriebssystemen wird nicht unterstützt.
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: