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.

Diese Seite richtet sich an Administratoren, Architekten und Betreiber, die Cloud-Infrastrukturen einrichten, überwachen und verwalten möchten. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Google Cloud -Inhalten verweisen, finden Sie unter Häufig verwendete GKE Enterprise-Nutzerrollen und -Aufgaben.

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 bei der Verwaltung 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 angeben, die für Pods und Dienste verwendet werden sollen.

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, um Ihren Cluster problemlos zu vergrößern.

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 routingfähig sein. 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 einGoogle 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 automatisch bei einer Flotte, wenn der Cluster erstellt wird.

Wenn Sie einen Cluster erstellen, geben Sie ein Flottemhostprojekt an, über das der Cluster verwaltet wird. Da GKE on AWS den Clusternamen als Flottenmitgliedschaftsnamen 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: dasGoogle Cloud -Projekt Ihres Flotten-Hostprojekts
    • CLUSTER_PROJECT_NUMBER: 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 Ihren 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"

Dabei gilt:

  • CLUSTER_NAME: der von Ihnen ausgewählte Clustername
  • AWS_REGION: die AWS-Region, in der der Cluster erstellt werden soll
  • GOOGLE_CLOUD_LOCATION: der Name des Google Cloud Standorts, von dem aus 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 anderenGoogle Cloud Projekt aus verwalten möchten, lesen Sie die 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: der 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“. Standardmäßig der Nutzer, der den Cluster erstellt

Wenn 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 Speicherort aufzurufen.

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

Cloud Logging/Cloud Monitoring autorisieren

Damit GKE on AWS Systemprotokolle und Messwerte erstellen und inGoogle Cloudhochladen kann, muss dies 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 Projekt Google Cloud , 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 in Ihrem Google Cloud -Projekt mindestens ein Cluster erstellt wurde. Dies liegt daran, dass der Workload Identity-Pool, auf den es sich bezieht (GOOGLE_PROJECT_ID.svc.id.goog), erst beim Erstellen des Clusters bereitgestellt wird.

Nächste Schritte