Wenn Sie vSphere IaaS control plane auf vSphere-Clustern aktivieren und diese zu Supervisoren werden, wird eine Kubernetes-Steuerungsebene innerhalb der Hypervisor-Schicht erstellt. Diese Schicht enthält bestimmte Objekte, die das Ausführen von Kubernetes-Arbeitslasten innerhalb von ESXi ermöglichen.

Abbildung 1. Allgemeine Supervisor-Architektur

Das Diagramm zeigt die allgemeine vSphere IaaS control plane-Architektur von an – mit dem Tanzu Kubernetes Grid oben, dem Supervisor in der Mitte, dann ESXi, Netzwerk und Speicher im unteren Bereich. Alle Komponenten werden vom vCenter Server verwaltet.

Architektur mit dem Tanzu Kubernetes Grid oben, dem Supervisor in der Mitte und ESXi, Netzwerk sowie Speicher unten. Diese werden vom vCenter Server verwaltet.

Ein Supervisor wird oberhalb einer SDDC-Schicht ausgeführt, die aus ESXi für Computing, NSX oder VDS-Netzwerke und vSAN oder einer anderen Lösung für freigegebenen Speicher besteht. Freigegebener Speicher wird für persistente Volumes bei vSphere-Pods, für im Supervisor ausgeführte VMs und für Pods in einem Tanzu Kubernetes Grid-Cluster verwendet. Nachdem ein Supervisor erstellt wurde, können Sie als vSphere-Administrator vSphere-Namespaces innerhalb des Supervisor erstellen. Als DevOps-Ingenieur können Sie Arbeitslasten ausführen, die aus Containern bestehen, die innerhalb von vSphere-Pods ausgeführt werden, Vms durch den VM-Dienst bereitstellen und Tanzu Kubernetes Grid-Cluster erstellen.

Sie können einen Supervisor in drei vSphere-Zonen bereitstellen, um Hochverfügbarkeit auf Clusterebene bereitzustellen, die Ihre Kubernetes-Arbeitslasten vor Ausfällen auf Clusterebene schützt. Eine vSphere-Zone wird einem vSphere-Cluster zugeordnet, den Sie als unabhängige Ausfalldomäne einrichten können. Bei einer Bereitstellung mit drei Zonen werden alle drei vSphere-Cluster zu einem Supervisor. Sie haben auch die Möglichkeit, einen Supervisor auf einem vSphere-Cluster bereitzustellen, der automatisch eine vSphere-Zone erstellt und dem Cluster zuweist, sofern Sie nicht einen vSphere-Cluster verwenden, der bereits einer Zone zugeordnet ist. Bei einer Bereitstellung mit einem einzelnen Cluster verfügt der Supervisor nur über Hochverfügbarkeit auf Hostebene, bereitgestellt von vSphere HA.

Abbildung 2. Supervisor-Architektur mit drei Zonen

Architektur mit drei Zonen, in denen TKG-Cluster auf vSphere-Namespace ausgeführt werden, die sich auf einem Supervisor befinden und auf drei vSphere-Zonen bereitgestellt werden.

Bei einem Supervisor mit drei Zonen können Sie Kubernetes-Arbeitslasten auf Tanzu Kubernetes Grid-Clustern und ‑VMs ausführen, die mit dem VM-Dienst erstellt wurden. Ein Supervisor mit drei Zonen hat die folgenden Komponenten:

  • Supervisor-Steuerungsebenen-VM. Auf dem Supervisor werden insgesamt drei Supervisor-Steuerungsebenen-VMs erstellt. Bei einer Bereitstellung mit drei Zonen befindet sich in jeder Zone eine Steuerungsebenen-VM. Die drei Supervisor-Steuerungsebenen-VMs verfügen über Lastausgleich, da jede eine eigene IP-Adresse hat. Darüber hinaus wird einer der VMs eine dynamische IP-Adresse zugewiesen, und eine 5. IP-Adresse wird für Patchzwecke reserviert. vSphere DRS bestimmt die exakte Platzierung der Steuerungsebenen-VMs auf den ESXi-Hosts des Supervisors und migriert sie bei Bedarf.
  • Tanzu Kubernetes Grid und Cluster-API. Dies sind Module, die im Supervisor ausgeführt werden und die Bereitstellung und Verwaltung von Tanzu Kubernetes Grid-Clustern ermöglichen.
  • VM-Dienst. Dieses Modul ist zuständig für die Bereitstellung und Ausführung von eigenständigen VMs sowie von VMs, die die Tanzu Kubernetes Grid-Cluster bilden.

In einem Supervisor mit drei Zonen wird ein Namespace-Ressourcenpool auf jedem vSphere-Cluster erstellt, der einer Zone zugeordnet ist. Der Namespace verteilt sich auf alle drei vSphere-Cluster in jeder Zone. Die für einen Namespace auf einem Supervisor mit drei Zonen verwendeten Ressourcen werden zu gleichen Teilen aus allen drei zugrunde liegenden vSphere-Clustern bezogen. Wenn Sie beispielsweise 300 MHz an CPU zuweisen, kommen von jedem vSphere-Cluster 100 MHz.

Abbildung 3. Supervisor-Architektur mit einem einzelnen Cluster

Ein Supervisor für eine Zone, der über den VM-Operator, die Cluster-API, Tanzu Kubernetes Grid, Steuerungsebenen-VMs und Spherelet-Module verfügt.

Ein Supervisor, der auf einem einzelnen vSphere-Cluster bereitgestellt wird, verfügt auch über drei Steuerungsebenen-VMs, die sich auf den ESXi-Hosts des Clusters befinden. Auf einem Supervisor mit einem einzelnen Cluster können Sie vSphere-Pods zusätzlich zu Tanzu Kubernetes Grid-Clustern und VMs ausführen. vSphere DRS ist mit dem Kubernetes Scheduler in den Supervisor-Steuerungsebenen-VMs vernetzt, sodass DRS die Platzierung von vSphere-Pods bestimmt. Wenn Sie als DevOps-Ingenieur einen vSphere Pod planen, wird die Anforderung über den regulären Kubernetes-Workflow an DRS übertragen, wodurch die endgültige Platzierungsentscheidung getroffen wird.

Durch die vSphere Pod-Unterstützung verfügt ein Supervisor mit einem einzelnen Cluster über die folgenden zusätzlichen Komponenten:

  • Spherelet. Ein zusätzlicher Prozess namens Spherelet wird auf jedem Host erstellt. Es handelt sich um ein Kubelet, das nativ auf ESXi portiert wird und dem ESXi-Host ermöglicht, Teil des Kubernetes-Clusters zu werden.
  • CRX-Komponente (Container Runtime Executive). Hinsichtlich Hostd und vCenter Server ist CRX mit einer VM vergleichbar. CRX umfasst einen paravirtualisierten Linux-Kernel, der mit dem Hypervisor zusammenarbeitet. CRX verwendet die gleichen Hardwarevirtualisierungstechniken wie VMs und ist von einer VM-Begrenzung umgeben. Es wird eine Direktstarttechnik verwendet, mit der der Linux-Gast von CRX den Hauptinitialisierungsprozess initiieren kann, ohne die Kernel-Initialisierung durchlaufen zu müssen. Auf diese Weise können vSphere-Pods fast so schnell wie Container starten.