Cluster erstellen

Auf dieser Seite wird erläutert, wie Sie einen Cluster und einen Knotenpool in GKE on Azure in Kubernetes Version 1.28.7-gke.1700 erstellen.

Hinweise

Um die Schritte auf dieser Seite auszuführen, gehen Sie so vor:

  1. Folgen Sie der Anleitung unter Voraussetzungen konfigurieren.

  2. Wählen Sie aus, ob Sie die Steuerungsebene in mehreren Zonen oder einer einzelnen Zone ausführen möchten.

  3. Wählen Sie CIDR-Bereiche (Classless Inter-Domain Routing) aus, die Sie für Ihren Cluster bereitstellen möchten.

Zonale Platzierung der Steuerungsebene

Standardmäßig platziert GKE on Azure separate Replikate der Steuerungsebene im selben Subnetz in drei Zonen der ausgewählten Region. Sie können diese Zonen und Subnetze auswählen.

Wenn Sie die Replikatplatzierung der Standardsteuerungsebene verwenden möchten, fahren Sie mit CIDR-Bereiche für Ihren Cluster auswählen fort.

Azure NAT-Gateway- und Cluster-Steuerungsebenen

Jedes Replikat der Steuerungsebene erfordert außerdem eine Verbindung zum von Google gehosteten Verwaltungsdienst, um in einem normalen Zustand zu arbeiten.

Wenn Sie das Azure NAT-Gateway zur Bereitstellung ausgehender Verbindungen verwenden, müssen Sie berücksichtigen, wie sich ein Zonenausfall auf die Steuerungsebene des Clusters auswirkt. Ein NAT-Gateway-Endpunkt ist auf eine einzelne Zone beschränkt oder ist regional und nicht zonal. Dies stellt einen Single Point of Failure dar.

Wenn Sie Replikate der Steuerungsebene in einer einzelnen Zone platzieren möchten, verwenden Sie ein einzelnes Subnetz und eine einzelne Zone. Wenn Sie das NAT-Gateway für ausgehende Verbindungen verwenden, achten Sie darauf, dass sich der Endpunkt in derselben Zone befindet.

Wenn Sie Replikate in zwei oder drei Zonen platzieren möchten, können Sie beim Erstellen eines Clusters eine Liste von Subnetzen und Zonen übergeben. Wenn Sie zwei Subnetze und Zonen übergeben, platziert GKE on Azure zwei Replikate in der ersten angegebenen Zone. Wenn Sie drei Subnetze und Zonen übergeben, platziert GKE on Azure Replikate in jedem Subnetz. Weitere Informationen finden Sie unter Replikate in einem bestimmten Subnetz platzieren.

Weitere Informationen zum Konfigurieren von Azure-Subnetzen und -Zonen für Hochverfügbarkeit finden Sie in der Azure-Dokumentation unter Zonenisolation mit zonalen Stacks.

Replikate in einem bestimmten Subnetz platzieren

Dieser Abschnitt ist optional.

Wenn Sie steuern möchten, in welchen Zonen Steuerungsebenenreplikate platziert werden, verwenden Sie beim Erstellen des Clusters das Flag --replica-placements und übergeben eine Liste der Subnetz-IDs und Zonen. Sie können bis zu drei Subnetze und Zonen verwenden, in denen die Replikate der Steuerungsebene platziert werden sollen.

Führen Sie die folgenden Schritt e aus, um die Liste der Subnetze zu formatieren.

  1. Rufen Sie Ihre Azure-Subnetz-IDs mit dem az-Befehlszeilentool ab:

    az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name SUBNET_NAME --query "id" -otsv

    Ersetzen Sie Folgendes:

    • CLUSTER_RESOURCE_GROUP_NAME: der Name einer vorhandene Ressourcengruppe, in der Sie Ihren Cluster ausführen möchten
    • VNET_RESOURCE_GROUP_NAME: der Name der Ressourcengruppe, die Ihr VNet enthält
    • VNET_NAME: Ihr VNet-Name
    • SUBNET_NAME: Ihr Subnetzname

    Die Ausgabe ist die ID des Subnetzes. Azure-Subnetz-IDs sehen so aus:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/SUBNET_NAME

    Wiederholen Sie diesen Befehl für jedes Subnetz, in dem Sie ein Replikat der Steuerungsebene erstellen möchten. Kopieren Sie die Subnetz-IDs für den folgenden Schritt in einen Texteditor.

  2. Erstellen Sie eine durch Kommas getrennte Liste von Subnetz-IDs und Azure-Verfügbarkeitszonen, wobei ein Doppelpunkt das Subnetz und die Zone trennt. Wenn Sie beispielsweise Replikate der Steuerungsebene in subnet1 in Zone 1, subnet2 in Zone 2 und subnet3 in Zone 3 erstellen möchten, verwenden Sie den folgenden String:

    /subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet1:1,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet2:2,/subscriptions/SUBSCRIPTION_ID/resourceGroups/RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/VNET_NAME/subnets/subnet3:3

    Kopieren Sie diesen String und verwenden Sie ihn als Wert für das Flag --replica-placements, wenn Sie einen Cluster erstellen.

CIDR-Bereiche für den Cluster auswählen

Wenn Sie einen Cluster in GKE on Azure erstellen, müssen Sie IPv4-Adressbereiche für Pods und Dienste angeben.

Diese IP-Bereiche werden mithilfe der CIDR-Notation (Classless Inter-Domain Routing) angegeben, z. B. 100.64.0.0/16.

Wir empfehlen die folgenden CIDR-Bereiche für Dienste und Pods:

  • Dienste: 100.64.0.0/16
  • Pods: 100.96.0.0/11

Diese Bereiche sind groß genug, sodass Sie Ihren Cluster problemlos erweitern können.

Mehr Informationen dazu finden Sie in den nächsten Abschnitten.

Details zur Auswahl von Bereichen

GKE on Azure verwendet ein Overlay-Netzwerk für Pods und Dienste. Daher müssen die IP-Bereiche für diese Netzwerke innerhalb des VNet nicht routbar sein. Alle verwendeten IP-Bereiche müssen garantiert verfügbar sein. Weitere Informationen finden Sie unter Dataplane V2.

  • Die Pod- und Dienst-IP-Bereiche können sich mit dem VNet-Netzwerk überschneiden, sofern sie entweder keine IP-Bereiche der Steuerungsebene oder des Knotenpools enthalten.

  • Der Pod- und Dienst-IP-Bereich muss in einen der folgenden privaten IP-Bereiche fallen:

    • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — Private IP-Adressen (RFC 1918)
    • 100.64.0.0/10 - Gemeinsamer Adressbereich (RFC 6598)
    • 192.0.0.0/24 - IETF-Protokollzuweisungen (RFC 6890)
    • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — Dokumentation (RFC 5737)
    • 192.88.99.0/24 - IPv6-zu-IPv4-Relay (verworfen) (RFC 7526)
    • 198.18.0.0/15 - Benchmarktests (RFC 2544)

Wir empfehlen IP-Bereiche innerhalb von 100.64.0.0/10 (RFC 6598). Dieser Bereich ist für NAT des Mobilfunkanbieters reserviert, die in Ihrem VNet wahrscheinlich nicht verwendet wird.

Das folgende Beispiel zeigt eine gültige Konfiguration, bei der sich die Pod-, Dienst- und Knotennetzwerke nicht überschneiden. Das VNet verwendet private RFC 1918-IP-Adressen, während die Pod- und Dienstnetzwerke auf privaten RFC 6598-IP-Adressen überlagert sind.

  • VNet-Netzwerk: 10.0.0.0/16, 172.16.1.0/24, 172.16.2.0/24
  • Pod-Netzwerk: 100.65.0.0/16
  • Dienstnetzwerk: 100.66.0.0/16

Die folgende Konfiguration ist auch gültig, obwohl sich die Pod- und Dienstnetzwerke mit dem VNet-Netzwerk überschneiden, da es keine Überschneidung mit den Replikaten der Steuerungsebene gibt.

  • VNet-Netzwerk: 10.0.0.0/16
  • Pod-Netzwerk: 10.0.1.0/24
  • Dienstnetzwerk: 10.0.2.0/24
  • Replikatsubnetze der Steuerungsebene: 10.0.3.0/24, 10.0.4.0/24, 10.0.5.0/24

Die folgende Konfiguration ist ungültig, da sich der Pod-IP-Bereich mit dem Netzwerk der Steuerungsebene überschneidet. Diese Überschneidung kann die Kommunikation von Arbeitslasten mit dem Replikat der Steuerungsebene im VNet-Netzwerk verhindern:

  • VNet-Netzwerk: 10.0.0.0/16
  • Pod-Netzwerk: 10.0.1.0/24
  • Dienstnetzwerk: 10.1.0.0/24
  • Replikatsubnetze der Steuerungsebene: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Details zum Pod-Adressbereich

Kubernetes weist Pod-Objekten Adressen aus dem Pod-Adressbereich zu. Der Pod-Bereich eines Clusters wird für jeden Knoten in kleinere Bereiche unterteilt. Wenn ein Pod auf einem bestimmten Knoten geplant ist, weist Kubernetes eine Pod-IP-Adresse aus dem Bereich des Knotens zu.

Wenn Sie die Größe des Pod-Adressbereichs berechnen möchten, müssen Sie die Anzahl der Knoten, die Sie in Ihrem Cluster wünschen, und die Anzahl der Pods, die Sie auf jedem Knoten ausführen möchten, schätzen.

Die folgende Tabelle enthält Größenempfehlungen für Pod-CIDR-Bereiche, basierend auf der Anzahl der Knoten und Pods, die Sie ausführen möchten.

Tabelle der Pod-Adressbereiche

Pod-Adressbereich Maximale Pod-IP-Adressen Maximale Knotenanzahl Maximale Anzahl von Pods
/24
Kleinstmöglicher Pod-Adressbereich		 256 Adressen 1 Knoten 110 Pods
/23 512 Adressen 2 Knoten 220 Pods
/22 1.024 Adressen 4 Knoten 440 Pods
/21 2.048 Adressen 8 Knoten 880 Pods
/20 4.096 Adressen 16 Knoten 1.760 Pods
/19 8.192 Adressen 32 Knoten 3.520 Pods
/18 16.384 Adressen 64 Knoten 7.040 Pods
/17 32.768 Adressen 128 Knoten 14.080 Pods
/16 65.536 Adressen 256 Knoten 28.160 Pods
/15 131.072 Adressen 512 Knoten 56.320 Pods
/14 262.144 Adressen 1.024 Knoten 112.640 Pods

Details zum Dienstadressbereich

Aus diesem Dienstadressbereich weist Kubernetes den Dienstobjekten, z. B. Load-Balancern, virtuelle IP-Adressen zu.

Wenn Sie die Größe des Dienstadressbereichs berechnen möchten, müssen Sie die Anzahl der gewünschten Dienste in Ihrem Cluster schätzen.

Die folgende Tabelle enthält Größenempfehlungen für Dienst-CIDR-Bereiche basierend auf der Anzahl der Dienste, die Sie ausführen möchten.

Tabelle der Dienstadressbereiche

Dienstadressbereich Maximale Anzahl an Diensten
/27
Kleinstmöglicher Dienstadressbereich		 32 Dienste
/26 64 Dienste
/25 128 Dienste
/24 256 Dienste
/23 512 Dienste
/22 1.024 Dienste
/21 2.048 Dienste
/20 4.096 Dienste
/19 8.192 Dienste
/18 16.384 Dienste
/17 32.768 Dienste
/16
Größtmöglicher Dienstadressbereich		 65.536 Dienste

Bei Azure authentifizieren

GKE on Azure bietet zwei Methoden zur Authentifizierung bei Azure: die Workload Identity-Föderation und das Erstellen eines Clientzertifikats. Die Authentifizierung der Identitätsföderation der Arbeitslast ist die empfohlene Methode, da sie einfacher und sicherer ist.

Identitätsföderation von Arbeitslasten

Eine Föderation von Arbeitslasten ermöglicht es GKE on Azure, sich über ein Google-Dienstkonto bei Azure zu authentifizieren, um anschließend Ressourcen in der Azure AD-Anwendung zu verwalten. Im Vergleich zu AzureClient müssen Sie keine Zertifikate verwalten und keine manuellen Uploads in Azure AD vornehmen.

Führen Sie die folgenden Befehle aus, um Anmeldedaten für föderierte Identitäten in Ihrer Azure AD-Anwendung zu konfigurieren. Sie können jeder Azure AD-Anwendung bis zu 20 Anmeldedaten hinzufügen.

  1. Speichern Sie Ihre Azure-Anwendungs-ID in Umgebungsvariablen:

    APPLICATION_ID=$(az ad app list --all \
  --query "[?displayName=='APPLICATION_NAME'].appId" --output tsv)
PROJECT_ID="$(gcloud config get-value project)"
PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" \
--format "value(projectNumber)")

  2. Erstellen Sie eine JSON-Datei mit dem Namen credential.json.

    {
  "name": "CREDENTIAL_NAME",
  "issuer": "https://accounts.google.com",
  "subject": "service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com",
  "audiences": ["api://AzureADTokenExchange"],
  "description": "Allow GKE on Azure to authenticate to the Azure AD application using a Google service account."
}
    • CREDENTIAL_NAME: der Name des Ausweisdokuments
    • PROJECT_NUMBER: die Nummer des Google Cloud-Projekts, das den Cluster hostet.

  3. Erstellen Sie in der Azure AD-Anwendung Anmeldedaten für eine föderierte Identität:

    az ad app federated-credential create --id "${APPLICATION_ID}" --parameters credential.json

Weitere Informationen finden Sie in der Azure-Dokumentation unter Azure AD-Identitätsföderation von Arbeitslasten mit Google Cloud.

Sie können die Anmeldedaten für die föderierte Azure-Identität auch mithilfe von Terraform bereitstellen. Weitere Informationen finden Sie unter azuread_application_federated_identity_credential.

Nachdem Sie die Anmeldedaten konfiguriert haben, erstellen Sie ein SSH-Schlüsselpaar für den Cluster oder wählen Sie eines aus.

SSH-Schlüsselpaar erstellen

Wenn Sie einen Cluster erstellen, müssen Sie ein SSH-Schlüsselpaar angeben. Wenn Sie bereits ein Schlüsselpaar haben, das Sie verwenden können, überspringen Sie diesen Schritt.

  1. Verwenden Sie zum Erstellen eines neuen Schlüsselpaars das ssh-keygen-Befehlszeilentool:

    ssh-keygen -m PEM -t rsa -b 4096 -f KEY_PATH

    Ersetzen Sie KEY_PATH durch den Pfad zu Ihrem neuen privaten Schlüssel.

  2. Speichern Sie den Schlüssel in einer Umgebungsvariablen:

    SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Führen Sie beispielsweise die folgenden Befehle aus, um unter ~/.ssh/anthos-multicloud-key.pub ein neues Schlüsselpaar zu erstellen und den öffentlichen Schlüssel in einer Umgebungsvariablen zu speichern:

    ssh-keygen -m PEM -t rsa -b 4096 -f ~/.ssh/anthos-multicloud-key
SSH_PUBLIC_KEY=$(cat ~/.ssh/anthos-multicloud-key.pub)

Nachdem Sie den öffentlichen Schlüssel in einer Umgebungsvariablen gespeichert haben, können Sie einen Cluster erstellen.

Flotten-Hostprojekt auswählen

Flotten sind ein Google Cloud-Konzept zum Organisieren von Clustern in größeren Gruppen. Mit Flotten können Sie mehrere Cluster in mehreren Clouds verwalten und konsistente Richtlinien auf sie anwenden. Die GKE Multi-Cloud API registriert Ihre Cluster beim Erstellen des Clusters automatisch bei einer Flotte.

Wenn Sie einen Cluster erstellen, geben Sie ein Flottemhostprojekt an, über das der Cluster verwaltet wird. Da GKE on Azure den Clusternamen als Namen der Flottenmitgliedschaft verwendet, müssen Sie darauf achten, dass die Clusternamen in Ihrer Flotte eindeutig sind.

Projektübergreifende Registrierung

Wenn Sie ein anderes Flottenhostprojekt als das Google Cloud-Projekt verwenden möchten, in dem sich der Cluster befindet, müssen Sie eine zusätzliche IAM-Richtlinienbindung auf das Dienstkonto des Multi-Cloud-Dienst-Agents anwenden. Dadurch kann das Dienstkonto Flotten mit dem Flottenhostprojekt verwalten.

  1. Führen Sie den folgenden Befehl aus, um den Dienst-Agent Ihrem Projekt hinzuzufügen:

    gcloud beta services identity create --service=gkemulticloud.googleapis.com \
  --project=CLUSTER_PROJECT_NUMBER

    Ersetzen Sie CLUSTER_PROJECT_NUMBER durch Ihre Google Cloud-Projektnummer.

  2. Weisen Sie diese Bindung mit dem folgenden Befehl zu:

    gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \
  --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \
  --role="roles/gkemulticloud.serviceAgent"

    Ersetzen Sie Folgendes:

    • FLEET_PROJECT_ID: ist das Google Cloud-Projekt Ihres Flottenhostprojekts
    • CLUSTER_PROJECT_NUMBER: ist Ihre Google Cloud-Projektnummer.

Der Name des Multi-Cloud-Dienst-Agents hat das folgende Format: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

Sie finden Ihre Dienstkonten in der Google Cloud Console auf der Seite Dienstkonto. Weitere Informationen zum Ermitteln der Projektnummer finden Sie unter Projekte identifizieren.

Cluster erstellen

Führen Sie den folgenden Befehl aus, um einen Cluster zu erstellen:

  1. Speichern Sie die Azure-Ressourcengruppen-, VNet- und Subnetz-IDs in Umgebungsvariablen:

    SUBSCRIPTION_ID=$(az account show --query "id" --output tsv)
TENANT_ID=$(az account list \
  --query "[?id=='${SUBSCRIPTION_ID}'].{tenantId:tenantId}" --output tsv)
CLUSTER_RG_ID=$(az group show --resource-group=CLUSTER_RESOURCE_GROUP_NAME \
  --query "id" -otsv)
VNET_ID=$(az network vnet show --resource-group=VNET_RESOURCE_GROUP_NAME \
  --name=VNET_NAME --query "id" -otsv)
SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)

    Ersetzen Sie Folgendes:

    • CLUSTER_RESOURCE_GROUP_NAME: der Name einer vorhandene Ressourcengruppe, in der Sie Ihren Cluster ausführen möchten
    • VNET_RESOURCE_GROUP_NAME: der Name der Ressourcengruppe, die Ihr VNet enthält
    • VNET_NAME: der Name Ihres VNet

  2. Erstellen Sie einen Cluster mit der Google Cloud CLI:

    Identitätsföderation von Arbeitslasten

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --azure-tenant-id "${TENANT_ID}" \
    --azure-application-id "${APPLICATION_ID}" \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.28.7-gke.1700 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Azure-Client

    gcloud container azure clusters create CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --fleet-project FLEET_PROJECT \
    --client CLIENT_NAME \
    --azure-region AZURE_REGION \
    --pod-address-cidr-blocks POD_CIDR \
    --service-address-cidr-blocks SERVICE_CIDR \
    --vm-size VM_SIZE \
    --cluster-version 1.28.7-gke.1700 \
    --ssh-public-key "$SSH_PUBLIC_KEY" \
    --resource-group-id "$CLUSTER_RG_ID" \
    --vnet-id "$VNET_ID" \
    --subnet-id "$SUBNET_ID" # Optional, see following note \
    --tags "control-plane=CLUSTER_NAME" \
    --admin-users ADMIN_USERS_LIST

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name Ihres Clusters
    • GOOGLE_CLOUD_LOCATION: der Google Cloud-Standort, der Ihren Cluster verwaltet
    • FLEET_PROJECT durch das Fleet-Hostprojekt, in dem der Cluster registriert wird. Wenn Sie diesen Cluster von einem anderen Google Cloud-Projekt aus verwalten möchten, finden Sie weitere Informationen unter Projektübergreifende Registrierung.
    • AZURE_REGION: eine unterstützte Azure-Region, die Ihrer Google Cloud-Region zugeordnet ist
    • POD_CIDR: Der Pod-Adressbereich Ihres Clusters, z. B. 10.0.1.0/18
    • SERVICE_CIDR: der Dienstadressbereich Ihres Clusters
    • VM_SIZE: eine unterstützte Azure-VM-Größe
    • ADMIN_USERS_LIST (optional): eine durch Kommas getrennte Liste der E-Mail-Adressen der Nutzer, denen Administratorberechtigungen gewährt werden sollen, z. B. "kai@beispiel.de,hao@beispiel.de,kalani@beispiel.de". Die Standardeinstellung ist der Nutzer, der den Cluster erstellt.
    • CLIENT_NAME: Ihr AzureClient-Name

  3. Prüfen Sie den Clusterstatus:

    gcloud container azure clusters describe CLUSTER_NAME  --location GOOGLE_CLOUD_LOCATION

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME
    • GOOGLE_CLOUD_LOCATION

    Die Ausgabe enthält Informationen zum Status und zur Konfiguration des Clusters.

Cloud Logging/Cloud Monitoring autorisieren

Damit GKE on Azure Systemlogs und -messwerte erstellen und in Google Cloud hochladen kann, muss es autorisiert werden.

Führen Sie den folgenden Befehl aus, um die Kubernetes-Arbeitslastidentität gke-system/gke-telemetry-agent zum Schreiben von Logs in Google Cloud Logging und von Messwerten in Google Cloud Monitoring zu autorisieren:

gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
  --member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
  --role=roles/gkemulticloud.telemetryWriter

Ersetzen Sie GOOGLE_PROJECT_ID durch die Google Cloud-Projekt-ID des Clusters.

Diese IAM-Bindung gewährt Zugriff auf alle Cluster im Google Cloud-Projekt, um Logs und Messwerte hochzuladen. Sie müssen ihn nur ausführen, nachdem Sie den ersten Cluster für das Projekt erstellt haben.

Das Hinzufügen dieser IAM-Bindung schlägt fehl, sofern nicht mindestens ein Cluster in Ihrem Google Cloud-Projekt erstellt wurde. Dies liegt daran, dass der Workload Identity-Pool, auf den er verweist (GOOGLE_PROJECT_ID.svc.id.goog), erst bei der Clustererstellung bereitgestellt wird.

Knotenpool erstellen

Bevor Sie einen Knotenpool erstellen können, benötigen Sie Folgendes:

  • Berechtigungen zum Verwenden des az-Befehlszeilentools zum Abrufen einer Azure-Subnetz-ID.
  • Zugriff auf den öffentlichen SSH-Schlüssel des Clusters.

Zum Erstellen eines Knotenpools führen Sie folgende Befehle aus:

  1. Speichern Sie die Azure VNet-Subnetz-ID und den öffentlichen SSH-Schlüssel in Umgebungsvariablen:

    SUBNET_ID=$(az network vnet subnet show \
  --resource-group=VNET_RESOURCE_GROUP_NAME --vnet-name=VNET_NAME \
  --name default --query "id" -otsv)
SSH_PUBLIC_KEY=$(cat KEY_PATH.pub)

    Ersetzen Sie Folgendes:

    • VNET_RESOURCE_GROUP_NAME: der Name der Ressourcengruppe, die VNet enthält
    • VNET_NAME: der Name Ihres VNet
    • KEY_PATH: der Pfad zu Ihrem Schlüsselpaar

  2. Erstellen Sie mit der Google Cloud CLI einen Knotenpool:

    gcloud container azure node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION \
    --node-version 1.28.7-gke.1700 \
    --vm-size VM_SIZE \
    --max-pods-per-node 110 \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --ssh-public-key "${SSH_PUBLIC_KEY}" \
    --subnet-id "${SUBNET_ID}"

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME: ein eindeutiger Name für Ihren Knotenpool, z. B. node-pool-1
    • CLUSTER_NAME: der Name Ihres GKE on Azure-Clusters
    • GOOGLE_CLOUD_LOCATION: der Google Cloud-Standort, der Ihren Cluster verwaltet
    • VM_SIZE: eine unterstützte Azure-VM-Größe
    • MIN_NODES: Mindestanzahl von Knoten im Knotenpool. Weitere Informationen finden Sie unter Cluster Autoscaling.
    • MAX_NODES: die maximale Anzahl von Knoten im Knotenpool

  3. Prüfen Sie den Status des Knotenpools:

    gcloud container azure node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location GOOGLE_CLOUD_LOCATION

    Ersetzen Sie Folgendes:

    • NODE_POOL_NAME: ein eindeutiger Name für Ihren Knotenpool, z. B. node-pool-1
    • CLUSTER_NAME: der Name Ihres GKE on Azure-Clusters
    • GOOGLE_CLOUD_LOCATION: der Google Cloud-Standort, der Ihren Cluster verwaltet

    Die Ausgabe enthält den Status Ihres Knotenpools, auch wenn er PROVISIONING oder RUNNING lautet.

Nächste Schritte