Cluster erstellen

Auf dieser Seite wird beschrieben, wie Sie einen GKE on AWS-Cluster erstellen. Sie können auch eine VPC und einen Cluster mit Terraform erstellen.

Hinweise

Bevor Sie einen Cluster erstellen, müssen Sie die Voraussetzungen erfüllen. Insbesondere müssen Sie die folgenden Ressourcen bereitstellen:

  • Eine AWS-VPC, in der der Cluster ausgeführt wird.
  • Bis zu drei AWS-Subnetze für die drei Replikate der Steuerungsebene. Jedes Subnetz muss sich in einer anderen AWS-Verfügbarkeitszone befinden.
  • Die AWS-IAM-Rolle, die GKE on AWS beim Verwalten Ihres Clusters übernimmt. Hierfür ist ein bestimmter Satz von IAM-Berechtigungen erforderlich.
  • Symmetrische KMK-Schlüssel in KMS für die Verschlüsselung inaktiver Clusterdaten (etcd) und für die Konfiguration.
  • Das AWS-IAM-Instanzprofil für jedes Replikat der Steuerungsebene. Hierfür ist ein bestimmter Satz von IAM-Berechtigungen erforderlich.
  • Ein EC2-SSH-Schlüsselpaar (optional), wenn Sie SSH-Zugriff auf die EC2-Instanzen benötigen, die jedes Replikat der Steuerungsebene ausführen.

Es liegt in Ihrer Verantwortung, diese Ressourcen zu erstellen und zu verwalten, die von allen GKE-Clustern gemeinsam genutzt werden können. Alle anderen zugrunde liegenden clusterbezogenen AWS-Ressourcen werden von GKE on AWS verwaltet.

CIDR-Bereiche für den Cluster auswählen

Wenn Sie einen Cluster in GKE on AWS 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 AWS verwendet ein Overlay-Netzwerk für Pods und Dienste. Daher müssen die IP-Bereiche für diese Netzwerke innerhalb der VPC nicht weitergeleitet werden. Alle verwendeten IP-Bereiche müssen garantiert verfügbar sein. Weitere Informationen finden Sie unter Dataplane V2.

  • Die Pod- und Service-IP-Bereiche können sich mit dem VPC-Netzwerk überschneiden, sofern keiner der beiden die IP-Bereiche der Steuerungsebene oder des Knotenpool-Subnetzes enthält.

  • 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 auf Ebene des Carriers reserviert, der wahrscheinlich nicht in Ihrer VPC verwendet wird.

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

  • VPC-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

Auch das Folgenden ist eine gültige Konfiguration, obwohl sich die Pod- und Service-Netzwerke mit dem VPC-Netzwerk überschneiden. Sie ist gültig, da es keine Überschneidungen mit den Replikaten der Steuerungsebene gibt.

  • VPC-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 VPC-Netzwerk verhindern:

  • VPC-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

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 AWS den Clusternamen als Namen der Flottenmitgliedschaft verwendet, müssen Sie darauf achten, dass Ihre 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

Verwenden Sie den folgenden Befehl, um den Cluster unter GKE on AWS zu erstellen. Weitere Informationen zu diesem Befehl und den optionalen Parametern finden Sie auf der Referenzseite für gcloud container aws.

gcloud container aws clusters create CLUSTER_NAME \
  --aws-region AWS_REGION \
  --location GOOGLE_CLOUD_LOCATION \
  --cluster-version CLUSTER_VERSION \
  --fleet-project FLEET_PROJECT \
  --vpc-id VPC_ID \
  --subnet-ids CONTROL_PLANE_SUBNET_1,CONTROL_PLANE_SUBNET_2,CONTROL_PLANE_SUBNET_3 \
  --pod-address-cidr-blocks POD_ADDRESS_CIDR_BLOCKS \
  --service-address-cidr-blocks SERVICE_ADDRESS_CIDR_BLOCKS \
  --role-arn API_ROLE_ARN \
  --database-encryption-kms-key-arn DB_KMS_KEY_ARN \
  --admin-users ADMIN_USERS_LIST \
  --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
  --iam-instance-profile CONTROL_PLANE_PROFILE \
  --tags "Name=CLUSTER_NAME-cp"

Ersetzen Sie Folgendes:

  • CLUSTER_NAME: der von Ihnen ausgewählte Clustername
  • AWS_REGION: die AWS-Region, in der der Cluster erstellt werden soll
  • GOOGLE_CLOUD_LOCATION: durch den Namen des Google Cloud-Standorts, von dem dieser Cluster verwaltet werden soll, wie in Google Cloud-Verwaltungsregionen definiert
  • CLUSTER_VERSION: durch die Kubernetes-Version ersetzen, die auf Ihrem Cluster installiert werden soll
  • FLEET_PROJECT: 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.
  • VPC_ID: durch die ID der AWS-VPC für diesen Cluster
  • CONTROL_PLANE_SUBNET_1, CONTROL_PLANE_SUBNET_2, CONTROL_PLANE_SUBNET_3: durch die Subnetz-IDs der drei Instanzen der Steuerungsebene des Clusters
  • POD_ADDRESS_CIDR_BLOCKS: den CIDR-Adressbereich für die Pods Ihres Clusters
  • SERVICE_ADDRESS_CIDR_BLOCKS: der CIDR-Adressbereich für die Dienste des Clusters
  • API_ROLE_ARN: ARN der GKE Multi-Cloud API-Rolle
  • CONTROL_PLANE_PROFILE: das Profil der IAM-Instanz, die dem Cluster zugeordnet ist. Weitere Informationen zum Aktualisieren eines IAM-Instanzprofils finden Sie unter AWS IAM-Instanzprofil aktualisieren.
  • DB_KMS_KEY_ARN: durch den Amazon-Ressourcennamen (ARN) des AWS KMS-Schlüssels zum Verschlüsseln der Secrets des Clusters
  • CONFIG_KMS_KEY_ARN: der Amazon-Ressourcenname (ARN) des AWS KMS-Schlüssels zum Verschlüsseln von Nutzerdaten.
  • 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.

Falls vorhanden, wendet der Parameter --tags das angegebene AWS-Tag auf alle zugrunde liegenden AWS-Ressourcen an, die von GKE on AWS verwaltet werden. In diesem Beispiel werden die Knoten der Steuerungsebene mit dem Namen des Clusters getaggt, zu dem sie gehören.

Sie können nur dann eine SSH-Verbindung zu diesen Steuerungsebenenknoten herstellen, wenn Sie ein SSH-Schlüsselpaar mit dem Flag --ssh-ec2-key-pair angeben.

Führen Sie den folgenden Befehl aus, um alle unterstützten Kubernetes-Versionen an einem bestimmten Google Cloud-Standort aufzurufen.

gcloud container aws get-server-config --location GCP_LOCATION

Cloud Logging/Cloud Monitoring autorisieren

Damit GKE on AWS 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.

Nächste Schritte