Vorbereitung der Bereitstellung von Verwaltungsclustern für Microsoft Azure

In diesem Thema wird erläutert, wie Sie Microsoft Azure für die Ausführung von Tanzu Kubernetes Grid vorbereiten.

Wenn Sie Tanzu Kubernetes Grid in Azure VMware Solution (AVS) installieren, führen Sie die Installation in einer vSphere-Umgebung durch. Unter Vorbereitung von Azure VMware Solution in Microsoft Azure in Vorbereiten der Bereitstellung von Verwaltungsclustern in einer VMware Cloud-Umgebung finden Sie Informationen zur Vorbereitung Ihrer Umgebung, und unter Vorbereitung der Bereitstellung von Verwaltungsclustern für vSphere zur Bereitstellung von Verwaltungsclustern.

Am Ende dieser Seite finden Sie eine Checkliste für die Vorbereitung, um sicherzustellen, dass Sie auf die Bereitstellung eines Tanzu Kubernetes Grid-Verwaltungsclusters für Azure vorbereitet sind.

Wichtig

Tanzu Kubernetes Grid v2.4.x ist die letzte Version von TKG, die die Erstellung eigenständiger TKG-Verwaltungscluster in Azure unterstützt. Die Möglichkeit, eigenständige TKG-Verwaltungscluster auf Azure zu erstellen, wird in Tanzu Kubernetes Grid v2.5 entfernt.

Ab sofort empfiehlt VMware, dass Sie Tanzu Mission Control verwenden, um native Azure AKS-Cluster zu erstellen, anstatt neue TKG-Verwaltungscluster in Azure zu erstellen. Informationen zum Erstellen nativer Azure AKS-Cluster mit Tanzu Mission Control finden Sie unter Verwalten des Lebenszyklus von Azure AKS-Clustern in der Dokumentation zu Tanzu Mission Control.

Weitere Informationen finden Sie unter Veraltete TKG-Verwaltungs- und -Arbeitslastcluster in AWS und Azure in den Versionshinweisen zu VMware Tanzu Kubernetes Grid v2.4.

Allgemeine Anforderungen

  • Die Tanzu CLI ist lokal installiert. Weitere Informationen finden Sie unter Installieren der Tanzu CLI und Kubernetes-CLI für die Verwendung mit eigenständigen Verwaltungsclustern.
  • Ein Microsoft Azure-Konto mit den folgenden Optionen:

    • Berechtigungen, die zum Erstellen eines Dienstprinzipals und zum Zuweisen der Rolle Owner erforderlich sind.
      Weitere Informationen zu den Rollen finden Sie unter In Azure integrierte Rollen.
    • Ausreichende VM-Kernkontingente (vCPU) für Ihre Cluster. Ein Azure-Standardkonto verfügt über ein Kontingent von 10 vCPU pro Region. Die vCPU-Anforderungen hängen davon ab, ob Sie einen prod- oder dev-Plan verwenden. Weitere Informationen zu den Plänen finden Sie unter Arbeitslastclusterpläne.
      Tanzu Kubernetes Grid-Cluster benötigen 2 vCPU pro Knoten. Dies bedeutet:
    • Verwaltungscluster:
      • dev-Plan: 4 vCPU (1 Haupt, 1 Worker)
      • prod-Plan: 8 vCPU (3 Haupt, 1 Worker)
    • Jeder Arbeitslastcluster:
      • dev-Plan: 4 vCPU (1 Haupt, 1 Worker)
      • prod-Plan: 12 vCPU (3 Haupt, 3 Worker)
    • Angenommen, es gibt einen einzigen Verwaltungscluster, und für alle Cluster gilt derselbe Plan:

      Plan Arbeitslastcluster vCPU für Arbeitslast vCPU für Verwaltung vCPU insgesamt
      Dev 1 4 4 8
      5 20 24
      Prod 1 12 8 20
      5 60 68

    • Ausreichende Kontingente öffentlicher IP-Adressen für Ihre Cluster, einschließlich des Kontingents für Öffentliche IP-Adressen – Standard (Public IP Addresses - Standard), Öffentliche IP-Adressen – Basis (Public IP Addresses - Basic) und Statische öffentliche IP-Adressen (Static Public IP Addresses). Ein Azure-Standardkonto verfügt über ein Kontingent von 10 öffentlichen IP-Adressen pro Region. Jeder Tanzu Kubernetes Grid-Cluster benötigt 2 öffentliche IP-Adressen, unabhängig davon, wie viele Steuerungsebenenknoten und Worker-Knoten er hat. Für jedes Kubernetes-Dienstobjekt vom Typ LoadBalancer ist 1 öffentliche IP-Adresse erforderlich.

  • Der Datenverkehr ist zwischen Ihrer lokalen Bootstrap-Maschine und den Image-Repositorys, die in der BoM-Datei (Bill of Materials) des Verwaltungsclusters aufgeführt sind, über Port 443 für TCP zulässig.*
    • Die BoM-Datei befindet sich unter ~/.config/tanzu/tkg/bom/, und ihr Name enthält die Tanzu Kubernetes Grid-Version. Beispiel: tkg-bom-v2.3.1+vmware.1 .yaml.
    • Führen Sie ein DNS-Lookup für alle imageRepository-Werte aus, um deren CNAMEs zu finden.
  • (Optional) OpenSSL wurde lokal installiert, um ein neues Schlüsselpaar zu erstellen oder den Fingerabdruck des Downloadpakets zu validieren. Weitere Informationen finden Sie unter OpenSSL.
  • (Optional) Ein virtuelles Netzwerk (VNet) mit:

    • Ein Subnetz für den Steuerungsebenenknoten des Verwaltungsclusters
    • Eine Netzwerksicherheitsgruppe (NSG) in der VNet-Ressourcengruppe des Clusters, die sich im Subnetz der Steuerungsebene befindet und über die folgenden eingehenden Sicherheitsregeln verfügt, um SSH- und Kubernetes-API-Serververbindungen zu aktivieren:
      • TCP über Port 22 für alle Quellen und Ziele zulassen
      • TCP über Port 6443 für alle Quell- und Zielinstanzen zulassen. Port 6443 ist der Port, auf dem die Kubernetes-API auf VMs in den von Ihnen erstellten Clustern verfügbar ist. Um diesen Port für einen Verwaltungs- oder Arbeitslastcluster zu ändern, legen Sie bei der Bereitstellung des Clusters die Variable CLUSTER_API_SERVER_PORT fest.
    • Ein Subnetz für die Worker-Knoten des Verwaltungsclusters
    • Eine NSG für die Worker-Knoten des Verwaltungsclusters, die sich in der VNet-Ressourcengruppe des Clusters und im Worker-Knotensubnetz des Clusters befindet

    Wenn Sie kein vorhandenes VNet verwenden, wird beim Installationsvorgang ein neues erstellt.

  • Die lokal installierte Azure-CLI. Weitere Informationen finden Sie unter Installieren der Azure CLI in der Microsoft Azure-Dokumentation.

  • Wenn Sie Dienste des Typs LoadBalancer auf klassenbasierten Arbeitslastclustern bereitstellen, konfigurieren Sie ein NAT-Gateway oder ein anderes Frontend, wie in LoadBalancer-Dienste für klassenbasierte Arbeitslastcluster in Azure benötigen eine manuelle Gateway- oder Frontendkonfiguration beschrieben.

Informationen zur Installation ohne Zugriff auf externe Netzwerke finden Sie unter Vorbereitung einer Umgebung mit Internetbeschränkung.

Beispiele für die Dimensionierung des Verwaltungsclusters

In der folgenden Tabelle werden Beispiele für die Dimensionierung von Verwaltungsclustern in Azure beschrieben. Verwenden Sie diese Daten als Richtlinie, um sicherzustellen, dass Ihr Verwaltungscluster für die Anzahl der Arbeitslastcluster skaliert ist, die Sie bereitstellen möchten. In der Spalte Größe der Arbeitslastcluster-VMwerden die VM-Größen aufgelistet, die für die Beispiele in der Spalte Kann verwalten… verwendet wurden.

Verwaltungscluster Plan Größe der Verwaltungscluster-VM Kann verwalten … Größe der Arbeitslastcluster-VM
3 Knoten der Steuerungsebene und 3 Worker-Knoten
  • Knoten der Steuerungsebene: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)
  • Worker-Knoten: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)
Beispiele:
  • 5 Arbeitslastcluster, wobei jeder Cluster mit 3 Steuerungsebenen- und 200 Worker-Knoten bereitgestellt wird; Oder
  • 10 Arbeitslastcluster, wobei jeder Cluster mit 3 Steuerungsebenen- und 50 Worker-Knoten bereitgestellt wird
  • Knoten der Steuerungsebene: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)
  • Worker-Knoten: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)
3 Knoten der Steuerungsebene und 3 Worker-Knoten
  • Knoten der Steuerungsebene: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)
  • Worker-Knoten: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)
Beispiel: Ein Arbeitslastcluster, der mit 3 Steuerungsebenen- und 250 Worker-Knoten bereitgestellt wird
  • Knoten der Steuerungsebene: Standard_D4s_v3 (CPU: 4; Arbeitsspeicher: 16 GB; SSD: 32 GB)
  • Worker-Knoten: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)
3 Knoten der Steuerungsebene und 3 Worker-Knoten
  • Knoten der Steuerungsebene: Standard_D4s_v3 (CPU: 4; Arbeitsspeicher: 16 GB; SSD: 32 GB)
  • Worker-Knoten: Standard_D4s_v3 (CPU: 4; Arbeitsspeicher: 16 GB; SSD: 32 GB)
Beispiel: 199 Arbeitslastcluster, die jeweils mit 3 Steuerungsebenen- und 3 Worker-Knoten bereitgestellt werden
  • Knoten der Steuerungsebene: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)
  • Worker-Knoten: Standard_D2s_v3 (CPU: 2; Arbeitsspeicher: 8 GB; SSD: 16 GB)

Erstellen von Azure-NSGs für vorhandenes VNet

Tanzu Kubernetes Grid-Verwaltungs- und Arbeitslastcluster in Azure benötigen zwei Netzwerksicherheitsgruppen (NSGs), die in ihrem VNet und in ihrer VNet-Ressourcengruppe definiert werden:

  • Eine NSG mit dem Namen CLUSTER-NAME-controlplane-nsg, die dem Subnetz der Steuerungsebene des Clusters zugeordnet ist
  • Eine NSG mit dem Namen CLUSTER-NAME-node-nsg, die dem Subnetz des Worker-Knotens des Clusters zugeordnet ist

    Dabei gilt: CLUSTER-NAME ist der Name des Clusters.

    Vorsicht

    Die Vergabe von Namen für NSGs, die nicht dem obigen Format entsprechen, kann die Bereitstellung verhindern.

Wenn Sie ein vorhandenes VNet für den Verwaltungscluster angeben, müssen Sie diese NSGs erstellen, wie oben unter Allgemeine Anforderungen beschrieben. Ein bestehendes VNet für einen Verwaltungscluster wird mit Vorhandenes VNet auswählen (Select an existing VNet) in der Installationsprogramm-Schnittstelle oder mit AZURE_VNET_NAME in der Konfigurationsdatei angegeben.

Wenn Sie kein vorhandenes VNet für den Cluster angeben, erstellt der Bereitstellungsprozess ein neues VNet und die erforderlichen NSGs.

Informationen zum Konfigurieren des VNet, der Ressourcengruppen und der Subnetze des Clusters finden Sie in der Microsoft Azure-Tabelle in der Variablenreferenz für Konfigurationsdatei.

Registrieren von Tanzu Kubernetes Grid als Azure-Client-App

Tanzu Kubernetes Grid verwaltet Azure-Ressourcen als registrierte Clientanwendung, die über einen Dienstprinzipal auf Azure zugreift. Um den Dienstprinzipal zu erstellen und seinen Zugriff auf Azure-Ressourcen zu konfigurieren, können Sie den Befehl az ad sp create-for-rbac verwenden.

  1. Melden Sie sich bei der Azure-CLI an, indem Sie az login ausführen.

  2. Erstellen Sie einen Dienstprinzipal und weisen Sie ihm die Rolle Owner zu:

    az ad sp create-for-rbac --role "Owner" --name "APP-NAME" --scopes /subscriptions/SUBSCRIPTION-ID/resourceGroups/RESOURCE-GROUP
    az role assignment create --assignee APP-ID --role "Owner"
    

    Dabei gilt:

    • APP-NAME ist ein beliebiger Name für Ihren Dienstprinzipal
    • SUBSCRIPTION-ID und RESOURCE-GROUP sind Ihre Azure-Abonnement-ID und VNet-Ressourcengruppe
    • APP-ID ist der appId-Wert, der von az ad sp create-for-rbac zurückgegeben wird

    So können Sie beispielsweise die Rolle Owner erstellen und einem Dienstprinzipal namens tkg zuweisen:

    $ az ad sp create-for-rbac --role "Owner" --name "tkg" --scopes /subscriptions/c789uce3-aaaa-bbbb-cccc-a51b6b0gb405/resourceGroups/myrg
    Creating 'Owner' role assignment under scope '/subscriptions/c789uce3-aaaa-bbbb-cccc-a51b6b0gb405'
    The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
    'name' property in the output is deprecated and will be removed in the future. Use 'appId' instead.
    {
     "appId": "c407cfd4-aaaa-bbbb-cccc-80af703eb0ed",
     "displayName": "tkg",
     "name": "c407cfd4-aaaa-bbbb-cccc-80af703eb0ed",
     "password": "R6yM_.aaaabbbbccccdddd111122223333",
     "tenant": "9c117323-aaaa-bbbb-cccc-9ee430723ba3"
    }
    $ az role assignment create --assignee c407cfd4-aaaa-bbbb-cccc-80af703eb0ed --role "Owner"
    

    Notieren Sie sich die Ausgabe. Sie verwenden diese Informationen in den folgenden Schritten unter Akzeptieren der Basisimage-Lizenz und später, wenn Sie einen Verwaltungscluster bereitstellen. Eine vollständige Liste der Optionen, die von az ad sp create-for-rbac unterstützt werden, finden Sie unter az ad sp create-for-rbac in der Azure-Dokumentation.

Akzeptieren der Basisimage-Lizenz

Um Verwaltungscluster-VMs in Azure auszuführen, akzeptieren Sie die Lizenz für ihre Kubernetes-Basisversion und das Maschinenbetriebssystem.

Führen Sie den Befehl az vm image terms accept aus und geben Sie den --plan und Ihre Abonnement-ID an.

In Tanzu Kubernetes Grid v2.3.1 lautet für das Cluster-Image --plan der Standardwert k8s-1dot26dot8-ubuntu-2004, basierend auf Kubernetes-Version 1.26.8 und dem Betriebssystem Ubuntu 20.04. Führen Sie den folgenden Befehl aus:

az vm image terms accept --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot26dot8-ubuntu-2004 --subscription AZURE_SUBSCRIPTION_ID

Dabei ist AZURE_SUBSCRIPTION_ID Ihre Azure-Abonnement-ID.

Sie müssen dies wiederholen, um die Lizenz für das Basisimage für jede Version von Kubernetes oder des Betriebssystems zu akzeptieren, die Sie bei der Bereitstellung von Clustern verwenden möchten, und jedes Mal, wenn Sie ein Upgrade auf eine neue Version von Tanzu Kubernetes Grid durchführen.

Erstellen eines SSH-Schlüsselpaars (optional)

Sie stellen Verwaltungscluster von einer als Bootstrap-Maschine bezeichneten Maschine mithilfe der Tanzu CLI bereit. Um eine Verbindung mit Azure herzustellen, muss die Bootstrap-Maschine den öffentlichen Schlüssel eines SSH-Schlüsselpaars bereitstellen. Wenn Ihre Bootstrap-Maschine nicht bereits über ein SSH-Schlüsselpaar verfügt, können Sie ein Tool wie ssh-keygen verwenden, um eines zu generieren.

  1. Führen Sie auf Ihrer Bootstrap-Maschine den folgenden Befehl ssh-keygen aus.

    ssh-keygen -t rsa -b 4096 -C "[email protected]"
    
  2. An der Eingabeaufforderung: Enter file in which to save the key (/root/.ssh/id_rsa): Drücken Sie die Eingabetaste, um die Vorgabe zu akzeptieren.

  3. Geben Sie ein Kennwort für das Schlüsselpaar ein und wiederholen Sie es.
  4. Fügen Sie den privaten Schlüssel zum SSH-Agenten hinzu, der auf Ihrem Computer ausgeführt wird, und geben Sie das im vorherigen Schritt erstellte Kennwort ein.

    ssh-add ~/.ssh/id_rsa
    
  5. Öffnen Sie die Datei .ssh/id_rsa.pub in einem Texteditor, sodass Sie sie bei der Bereitstellung eines Verwaltungsclusters problemlos kopieren und einfügen können.

Checkliste für die Vorbereitung

Verwenden Sie diese Checkliste, um sicherzustellen, dass Sie auf die Bereitstellung eines Tanzu Kubernetes Grid-Verwaltungsclusters in Azure vorbereitet sind:

  • Tanzu CLI installiert

    • Führen Sie tanzu version aus. Eine Liste der CLI-Versionen, die mit Tanzu Kubernetes Grid v2.3 kompatibel sind, finden Sie unter Produkt-Interoperabilitätsmatrix.
  • Azure-Konto

    • Melden Sie sich beim Azure-Webportal auf https://portal.azure.com an.
  • Azure CLI installiert

    • Führen Sie az version aus. In der Ausgabe sollte die aktuelle Version der Azure CLI aufgelistet werden, wie unter Installieren der Azure CLI in der Microsoft Azure-Dokumentation erläutert.
  • Registrierte tkg-App

    • Wählen Sie im Azure-Portal Active Directory > App-Registrierungen (App Registrations) > In Besitz befindliche Anwendungen (Owned Applications) aus und bestätigen Sie, dass Ihre tkg-App wie unter Registrieren von Tanzu Kubernetes Grid als Azure-Client-App konfiguriert und mit einem aktuellen geheimen Schlüssel aufgelistet ist.
    • Führen Sie alternativ in der Azure CLI den folgenden Befehl aus: az ad sp show --id.
  • Basis-VM-Image-Lizenz akzeptiert

    • Führen Sie az vm image terms show --publisher vmware-inc --offer tkg-capi-2022-06-24 --plan k8s-1dot26dot8-ubuntu-2004 aus. Die Ausgabe sollte "accepted": true enthalten.

Nächste Schritte

Für Produktionsbereitstellungen wird dringend empfohlen, die Identitätsverwaltung für Ihre Cluster zu aktivieren: * Informationen zu den vorbereitenden Schritten, die vor der Bereitstellung eines Verwaltungsclusters durchgeführt werden müssen, finden Sie unter Abrufen der Details Ihres Identitätsanbieters im Abschnitt Konfigurieren der Identitätsverwaltung. * Konzeptionelle Informationen zur Identitätsverwaltung und Zugriffssteuerung in Tanzu Kubernetes Grid finden Sie unter Informationen zur Identitäts- und Zugriffsverwaltung.

Wenn Sie Tanzu Kubernetes Grid in einer Umgebung mit einer externen Internetverbindung verwenden, können Sie nach der Einrichtung der Identitätsverwaltung Verwaltungscluster in Azure bereitstellen.

check-circle-line exclamation-circle-line close-line
Scroll to top icon