Administratorcluster mit „gkectl“ erstellen

Erstellen Sie mit gkectl einen Administratorcluster für Google Distributed Cloud (nur Software) für VMware. Verwenden Sie gkectl, wenn Sie den gesamten Lebenszyklus Ihres Administratorclusters lokal in Ihrer lokalen Umgebung verwalten müssen, um strenge Sicherheits-, Compliance- oder Air-Gap-Anforderungen zu erfüllen. Sie können einen Administratorcluster auch mit Terraform oder der Google Cloud Console erstellen.

Hinweis

  • Prüfen Sie, ob Sie Ihre Administrator-Workstation eingerichtet haben und sich bei ihr anmelden können, wie unter Administrator-Workstation erstellen beschrieben.

  • Die JSON-Schlüsseldateien für die Dienstkonten müssen sich auf Ihrer Administrator-Workstation befinden.

  • Lesen Sie das Dokument zur Planung der IP-Adressen. Achten Sie darauf, dass genügend IP-Adressen für die drei Knoten der Steuerungsebene und eine VIP der Steuerungsebene verfügbar sind. Wenn Sie beabsichtigen, kubeception-Nutzer-Cluster zu erstellen, müssen Sie genügend IP-Adressen für die Knoten auf der Steuerungsebene dieser Nutzer-Cluster zur Verfügung haben.

  • Lesen Sie die Übersicht über das Load-Balancing und prüfen Sie noch einmal Ihre Entscheidung, welche Art von Load-Balancer Sie verwenden möchten. Bei manuellen Load-Balancern müssen Sie den Load-Balancer einrichten, bevor Sie Ihren Administratorcluster erstellen.

  • Wenn Sie gkectl zum Erstellen des Administratorclusters verwenden, entscheiden Sie, ob Sie eine öffentliche oder private Registry für Google Distributed Cloud-Komponenten verwenden möchten. Informationen zur Verwendung einer privaten Docker-Registry finden Sie unter privateRegistry. Weder Terraform noch die Google Cloud Console unterstützen die Verwendung einer privaten Docker-Registry für Systemkomponenten.

  • Entscheiden Sie, welche Art von Betriebssystem Sie auf Ihren Administratorclusterknoten ausführen möchten.

  • Wenn in Ihrem Unternehmen der ausgehende Traffic über einen Proxy-Server geleitet werden muss, sollten Sie eine Zulassungsliste für die erforderlichen APIs und die Artifact Registry-Adresse erstellen.

  • In Version 1.29 und höher sind serverseitige Preflight-Prüfungen standardmäßig aktiviert. Für serverseitige Preflight-Prüfungen sind zusätzliche Firewallregeln erforderlich. Suchen Sie in den Firewallregeln für Administratorcluster nach „Preflight-Prüfungen“ und achten Sie darauf, dass alle erforderlichen Firewallregeln konfiguriert sind. Serverseitige Preflight-Prüfungen werden auf dem Bootstrap-Cluster und nicht lokal auf der Administrator-Workstation ausgeführt.

Verfahrensübersicht

Dies sind die primären Schritte zum Erstellen eines Administratorclusters:

  1. Füllen Sie Ihre Konfigurationsdateien aus. Geben Sie die Details für die Konfigurationsdatei für die Anmeldedaten des neuen Administrators und möglicherweise eine IP-Blockdatei an.

  2. Importieren Sie Betriebssystem-Images in vSphere und übertragen Sie gegebenenfalls Container-Images in die private Registry. Führen Sie gkectl prepare aus.

  3. Erstellen Sie einen Administratorcluster. Erstellen Sie mit gkectl einen neuen Administratorcluster, wie in den ausgefüllten Konfigurationsdateien angegeben. Wenn Google Distributed Cloud einen Administratorcluster erstellt, wird ein Kubernetes in Docker-Cluster (Art) bereitgestellt, der vorübergehend die Kubernetes-Controller hostet, die zur Erstellung des Administratorclusters benötigt werden. Dieser vorübergehende Cluster wird als Bootstrap-Cluster bezeichnet. Nutzercluster werden von ihrem verwaltenden Administrator ohne Verwendung eines Bootstrap-Clusters erstellt und aktualisiert.

  4. Prüfen Sie, ob der Administratorcluster ausgeführt wird. Rufen Sie mit kubectl die Clusterknoten auf.

Am Ende dieses Verfahrens haben Sie einen laufenden Administratorcluster, mit dem Sie Nutzercluster erstellen und verwalten können.

Wenn Sie VPC Service Controls verwenden, werden beim Ausführen einiger gkectl-Befehle möglicherweise Fehler angezeigt, z. B. "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Fügen Sie Ihren Befehlen den Parameter --skip-validation-gcp hinzu, um diese Fehler zu vermeiden.

Konfigurationsdatei ausfüllen

  • Prüfen Sie, ob auf Ihrer Administrator-Workstation die erforderliche Version von gkectl installiert ist. In der Regel verwenden Sie dieselbe Version von gkectl, die auch beim Erstellen des Clusters verwendet wird. Die Clusterversion geben Sie im Feld gkeOnPremVersion in der Clusterkonfigurationsdatei an. Die folgenden Versionsregeln werden bei der Clustererstellung erzwungen:

    • Die Nebenversion von gkectl darf nicht niedriger als die Nebenversion des Clusters sein. Beispielsweise ist das Erstellen eines 1.30-Clusters mit gkectl Version 1.29 nicht zulässig. Patchversionen spielen keine Rolle. Sie können beispielsweise die gkectl-Version 1.29.0-gke.1456 verwenden, um einen Cluster mit einer höheren Patch-Version wie 1.29.1000-gke.94 zu erstellen.

    • Die Nebenversion gkectl darf nicht mehr als zwei Nebenversionen höher als die Clusterversion sein. Wenn Sie beispielsweise einen Cluster der Version 1.28 erstellen, kann die gkectl-Version 1.29 oder 1.30 sein. Sie können jedoch nicht die gkectl-Version 1.31 verwenden, da diese drei Nebenversionen höher ist als die Clusterversion.

    Falls erforderlich, finden Sie unter gkectl herunterladen eine unterstützte Version von gkectl.

Wenn Sie Ihre Administratorworkstation mit gkeadm erstellt haben, wurde eine Konfigurationsdatei mit dem Namen admin-cluster.yaml generiert.

Wenn Sie Ihre Administrator-Workstation nicht mit gkeadm erstellt haben, generieren Sie admin-cluster.yaml durch Ausführen des folgenden Befehls auf der Administratorworkstation:

gkectl create-config admin

Diese Konfigurationsdatei dient zum Erstellen Ihres Administratorclusters.

Machen Sie sich mit der Konfigurationsdatei vertraut, indem Sie sich das Dokument zur Administratorcluster-Konfigurationsdatei ansehen. Möglicherweise möchten Sie dieses Dokument in einem separaten Tab oder Fenster geöffnet lassen, da Sie sich beim Ausführen der folgenden Schritte darauf beziehen.

name

Wenn Sie einen Namen für den Administratorcluster angeben möchten, füllen Sie das Feld name aus.

bundlePath

Das Bundle ist eine ZIP-Datei, die Clusterkomponenten enthält. Es ist in der Administrator-Workstation enthalten. Dieses Feld ist bereits für Sie ausgefüllt.

vCenter

Die meisten Felder in diesem Abschnitt sind bereits mit den Werten gefüllt, die Sie beim Erstellen der Administrator-Workstation eingegeben haben.

enableAdvancedCluster

Wenn Sie in Version 1.31 das erweiterte Cluster-Feature aktivieren möchten, legen Sie enableAdvancedCluster auf true fest.

Beachten Sie die folgenden Unterschiede zwischen den Versionen:

  • In Version 1.31 befindet sich das erweiterte Cluster-Feature in der Vorabversion:

    • Sie können die erweiterte Clusterverwaltung nur beim Erstellen von neuen 1.31-Clustern aktivieren.

    • Nachdem der erweiterte Cluster aktiviert wurde, können Sie den Cluster nicht mehr auf 1.32 aktualisieren. Aktivieren Sie den erweiterten Cluster nur in einer Testumgebung.

  • In Version 1.32 ist die erweiterte Clusterfunktion allgemein verfügbar.

    • Standardmäßig werden Administratorcluster als erweiterte Cluster erstellt. Sie müssen enableAdvancedCluster explizit auf false festlegen, wenn Sie einen nicht erweiterten Cluster erstellen möchten.

    • Für Cluster, für die das Feature „Erweiterte Cluster“ aktiviert ist, werden Clusterupgrades unterstützt.

  • In Version 1.33 und höher werden alle Cluster als erweiterte Cluster erstellt. Wenn Sie enableAdvancedCluster auf false setzen, schlägt die Clustererstellung fehl.

network

Füllen Sie die Abschnitte network.controlPlaneIPBlock und network.hostConfig. Legen Sie außerdem adminMaster.replicas auf 3 fest.

Die Felder network.podCIDR und network.serviceCIDR haben bereits ausgefüllte Werte, die Sie unverändert lassen können, sofern sie nicht mit Adressen in Konflikt stehen, die bereits in Ihrem Netzwerk verwendet werden. Kubernetes verwendet diese Bereiche, um den Pods und Services in Ihrem Cluster IP-Adressen zuzuweisen.

Füllen Sie nach Bedarf die restlichen Felder im Netzwerkabschnitt der Konfigurationsdatei aus.

loadBalancer

Legen Sie eine VIP für den Kubernetes API-Server Ihres Administratorclusters fest. Stellen Sie die VIP als Wert für loadBalancer.vips.controlPlaneVIP bereit.

Weitere Informationen finden Sie unter VIPs im Subnetz des Administratorclusters.

Entscheiden Sie, welche Art von Load-Balancing Sie verwenden möchten. Folgende Optionen sind verfügbar:

  • Gebündeltes MetalLB-Load-Balancing. Legen Sie loadBalancer.kind auf "MetalLB" fest.

  • Manuelles Load-Balancing. Legen Sie loadBalancer.kind auf "ManualLB" fest und entfernen Sie den Abschnitt manualLB.

Weitere Informationen zu den Load-Balancing-Optionen finden Sie unter Load-Balancing – Übersicht.

antiAffinityGroups

Legen Sie antiAffinityGroups.enabled entsprechend Ihren Anforderungen auf true oder false fest.

Verwenden Sie dieses Feld, um anzugeben, ob Google Distributed Cloud Anti-Affinitätsregeln für VMware Distributed Resource Scheduler (DRS) für Ihre Administratorcluster-Knoten erstellen soll, sodass diese auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden.

adminMaster

Wenn Sie CPU und Arbeitsspeicher für die Knoten der Steuerungsebene des Administratorclusters angeben möchten, füllen Sie die Felder cpus und memoryMB im Abschnitt adminMaster aus.

Administratorcluster müssen drei Knoten der Steuerungsebene haben. Setzen Sie das Feld replicas im Abschnitt adminMaster auf 3.

proxy

Wenn sich das Netzwerk mit den Knoten des Administratorclusters hinter einem Proxyserver befindet, füllen Sie den Abschnitt proxy aus.

privateRegistry

Entscheiden Sie, wo Sie die Container-Images für die Google Distributed Cloud-Komponenten speichern möchten. Folgende Optionen sind verfügbar:

  • Artifact Registry

  • Ihre eigene private Docker-Registry.

    Wenn Sie Ihre eigene private Registry verwenden möchten, füllen Sie den Abschnitt privateRegistry aus.

Weitere Informationen zur Verwendung einer privaten Registry, einschließlich der Unterschiede zwischen normalen und erweiterten Clustern, finden Sie unter Private Container Registry konfigurieren.

componentAccessServiceAccountKeyPath

Google Distributed Cloud verwendet Ihr Dienstkonto für den Komponentenzugriff, um Clusterkomponenten aus Artifact Registry herunterzuladen. Dieses Feld enthält den Pfad einer JSON-Schlüsseldatei für Ihr Dienstkonto für den Komponentenzugriff.

Dieses Feld ist bereits für Sie ausgefüllt.

gkeConnect

Registrieren Sie Ihren Administratorcluster in einer Google Cloud -Flotte, indem Sie den Abschnitt gkeConnect hinzufügen. Wenn Sie die Abschnitte stackdriver und cloudAuditLogging in der Konfigurationsdatei angeben, muss die ID in gkeConnect.projectID mit der ID übereinstimmen, die in stackdriver.projectID und cloudAuditLogging.projectID festgelegt ist. Wenn die Projekt-IDs nicht identisch sind, schlägt die Clustererstellung fehl.

In Version 1.28 und höher können Sie optional eine Region angeben, in der die Flotten- und Connect-Dienste in gkeConnect.location ausgeführt werden. Wenn Sie dieses Feld nicht angeben, verwendet der Cluster die globalen Instanzen dieser Dienste.

Wenn Sie gkeConnect.location angeben, muss die von Ihnen angegebene Region mit der in cloudAuditLogging.clusterLocation, stackdriver.clusterLocation und gkeOnPremAPI.location konfigurierten Region übereinstimmen. Wenn die Regionen nicht identisch sind, schlägt die Cluster-Erstellung fehl.

gkeOnPremAPI

Wenn die GKE On-Prem API in IhremGoogle Cloud -Projekt aktiviert ist, werden alle Cluster im Projekt automatisch in der GKE On-Prem API in der Region angemeldet, die in stackdriver.clusterLocation konfiguriert wurde. Die Region gkeOnPremAPI.location muss mit der Region übereinstimmen, die in cloudAuditLogging.clusterLocation, gkeConnect.location und stackdriver.clusterLocation angegeben ist. Wenn die Regionen nicht identisch sind, schlägt die Cluster-Erstellung fehl.

  • Wenn Sie alle Cluster im Projekt für die GKE On-Prem API registrieren möchten, müssen Sie die Schritte unter Vorbereitung zur Aktivierung und Verwendung der GKE On-Prem API im Projekt ausführen.

  • Wenn Sie den Cluster nicht in der GKE On-Prem API registrieren möchten, fügen Sie diesen Abschnitt hinzu und setzen Sie gkeOnPremAPI.enabled auf false. Wenn Sie keine Cluster in dem Projekt registrieren möchten, deaktivieren Sie gkeonprem.googleapis.com (der Dienstname für die GKE On-Prem API) in dem Projekt. Eine Anleitung finden Sie unter Dienste deaktivieren.

stackdriver

Wenn Sie Cloud Logging und Cloud Monitoring für Ihren Cluster aktivieren möchten, füllen Sie den Abschnitt stackdriver aus.

Dieser Abschnitt ist standardmäßig erforderlich. Das heißt, wenn Sie diesen Abschnitt nicht füllen, müssen Sie das Flag --skip-validation-stackdriver einfügen, wenn Sie gkectl create admin ausführen.

Beachten Sie folgende Anforderungen:

  • Wenn Sie erweiterte Cluster aktivieren, müssen Sie in cloudAuditLogging.serviceAccountKeyPath und stackdriver.serviceAccountKeyPath denselben Pfad angeben.

  • Die ID in stackdriver.projectID muss mit der ID in gkeConnect.projectID und cloudAuditLogging.projectID übereinstimmen.

  • Die in stackdriver.clusterLocation festgelegte Google Cloud -Region muss der in cloudAuditLogging.clusterLocation und gkeConnect.location entsprechen. Wenn außerdem gkeOnPremAPI.enabled true ist, muss dieselbe Region in gkeOnPremAPI.location festgelegt werden.

Wenn die Projekt-IDs und Regionen nicht identisch sind, schlägt die Clustererstellung fehl.

cloudAuditLogging

Wenn Sie die Audit-Logs des Kubernetes API-Servers Ihres Clusters in Cloud-Audit-Logs einbinden möchten, füllen Sie den Abschnitt cloudAuditLogging aus.

Beachten Sie folgende Anforderungen:

  • Wenn Sie den erweiterten Cluster aktivieren, müssen Sie in cloudAuditLogging.serviceAccountKeyPath und stackdriver.serviceAccountKeyPath denselben Pfad angeben.

  • Die ID in cloudAuditLogging.projectID muss mit der ID in gkeConnect.projectID und stackdriver.projectID übereinstimmen.

  • Die in cloudAuditLogging.clusterLocation festgelegte Google Cloud -Region muss der in stackdriver.clusterLocation und gkeConnect.location entsprechen (wenn das Feld in Ihrer Konfigurationsdatei enthalten ist). Wenn außerdem gkeOnPremAPI.enabled true ist, muss dieselbe Region in gkeOnPremAPI.location festgelegt werden.

Wenn die Projekt-IDs und Regionen nicht identisch sind, schlägt die Clustererstellung fehl.

clusterBackup

Wenn Sie die Sicherung des Administratorclusters aktivieren möchten, legen Sie clusterBackup.datastore auf den vSphere-Datenspeicher fest, in dem Sie Clustersicherungen speichern möchten.

Wenn Sie den erweiterten Cluster aktivieren, entfernen Sie diesen Abschnitt. Das Sichern des Administratorclusters in einem vSphere-Datenspeicher wird nicht unterstützt.

autoRepair

Wenn Sie die automatische Knotenreparatur für Ihren Administratorcluster aktivieren möchten, legen Sie autoRepair.enabled auf true fest.

secretsEncryption

Wenn Sie die immer aktive Secret-Verschlüsselung aktivieren möchten, füllen Sie den Abschnitt secretsEncryption aus.

Wenn Sie den erweiterten Cluster aktivieren, setzen Sie secretsEncryption.enabled auf false. Die Always-On-Secrets-Verschlüsselung wird nicht unterstützt.

osImageType

Wählen Sie aus, welche Art von Betriebssystem-Image Sie für die Administratorclusterknoten verwenden möchten, und füllen Sie den Abschnitt osImageType entsprechend aus.

Wenn Sie den erweiterten Cluster aktivieren, legen Sie osImageType entweder auf ubuntu_cgroupv2 oder ubuntu_containerd fest.

Beispiel für ausgefüllte Konfigurationsdateien

Hier ist ein Beispiel für eine ausgefüllte Konfigurationsdatei für einen Administratorcluster. Die Konfiguration aktiviert einige, aber nicht alle verfügbaren Features.

vc-01-admin-cluster.yaml

apiVersion: v1
kind: AdminCluster
name: "gke-admin-01"
bundlePath: "/var/lib/gke/bundles/gke-onprem-vsphere-1.28.0-gke.1-full.tgz"
enableAdvancedCluster: true
vCenter:
  address: "vc01.example"
  datacenter: "vc-01"
  cluster: "vc01-workloads-1"
  resourcePool: "vc-01-pool-1"
  datastore: "vc01-datastore-1"
  caCertPath: "/usr/local/google/home/me/certs/vc01-cert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter"
  folder: "vc01-folder-1"
network:
  hostConfig:
    dnsServers:
    - "203.0.113.1"
    - "198.51.100.1"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: static
    ipBlockFilePath: network.hostconfig
  serviceCIDR: "10.96.232.0/24"
  podCIDR: "192.168.0.0/16"
  vCenter:
    networkName: "vc01-net-1"
  controlPlaneIPBlock:
    netmask: "255.255.248.0"
    gateway: "21.0.143.254"
    ips:
    - ip: "21.0.140.226"
      hostname: "admin-cp-vm-1"
    - ip: "21.0.141.48"
      hostname: "admin-cp-vm-2"
    - ip: "21.0.141.65"
      hostname: "admin-cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.59"
  kind: "MetalLB"
antiAffinityGroups:
  enabled: true
adminMaster:
  cpus: 4
  memoryMB: 16384
  replicas: 3
componentAccessServiceAccountKeyPath: "sa-key.json"
gkeConnect:
  projectID: "my-project-123"
  registerServiceAccountKeyPath: "connect-register-sa-2203040617.json"
stackdriver:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
  disableVsphereResourceMetrics: false
cloudAuditLogging:
  projectID: "my-project-123"
  clusterLocation: "us-central1"
  serviceAccountKeyPath: "log-mon-sa-2203040617.json"
autoRepair:
  enabled: true
osImageType: "ubuntu_cgv2"

Konfigurationsdatei validieren

Nachdem Sie die Konfigurationsdatei des Administratorclusters ausgefüllt haben, führen Sie gkectl check-config aus, um zu prüfen, ob die Datei gültig ist:

gkectl check-config --config ADMIN_CLUSTER_CONFIG

Ersetzen Sie ADMIN_CLUSTER_CONFIG durch den Pfad Ihrer Konfigurationsdatei für den Administratorcluster.

Wenn der Befehl Fehlermeldungen zurückgibt, beheben Sie die Probleme und validieren Sie die Datei noch einmal.

Wenn Sie die zeitaufwendigeren Validierungen überspringen möchten, übergeben Sie das Flag --fast. Verwenden Sie die Flags --skip-validation-yyy, um einzelne Validierungen zu überspringen. Weitere Informationen zum Befehl check-config finden Sie unter Vorabprüfungen ausführen.

Betriebssystem-Images abrufen

Führen Sie gkectl prepare aus, um Ihre vSphere-Umgebung zu initialisieren:

gkectl prepare --config ADMIN_CLUSTER_CONFIG

Mit dem Befehl gkectl prepare werden folgende vorbereitende Aufgaben ausgeführt:

  • Die Betriebssystem-Images werden in vSphere importiert und als VM-Vorlagen markiert.

  • Wenn Sie eine private Docker-Registry verwenden, werden die Container-Images in Ihre Registry übertragen.

  • Optional werden die Build-Attestierungen der Container-Images validiert, um sicherzustellen, dass die Images von Google erstellt und signiert wurden und bereit für die Bereitstellung sind.

Wenn Sie Ihr bundlePath für die Verwendung eines vollständigen Bundles konfiguriert haben, verwendet gkectl prepare die im Bundle enthaltenen Betriebssystem- und Container-Images, sodass sie nicht aus externen Netzwerken heruntergeladen werden müssen. Dies wird für Umgebungen hinter einem langsamen Proxy oder mit eingeschränktem Internetzugriff empfohlen. Weitere Informationen finden Sie unter Informationen zu Google Distributed Cloud-Bundles.

Erstellen Sie den Administratorcluster.

Erstellen Sie den Administratorcluster:

gkectl create admin --config ADMIN_CLUSTER_CONFIG

Wenn Sie VPC Service Controls verwenden, werden beim Ausführen einiger gkectl-Befehle möglicherweise Fehler angezeigt, z. B. "Validation Category: GCP - [UNKNOWN] GCP service: [Stackdriver] could not get GCP services". Fügen Sie Ihren Befehlen den Parameter --skip-validation-gcp hinzu, um diese Fehler zu vermeiden.

Erstellung des Administratorclusters nach einem Fehler fortsetzen

Wenn die Erstellung des Administratorclusters fehlschlägt oder abgebrochen wird, können Sie den Befehl create noch einmal ausführen:

gkectl create admin --config ADMIN_CLUSTER_CONFIG

Suchen Sie die kubeconfig-Datei des Administratorclusters

Mit dem Befehl gkectl create admin wird im aktuellen Verzeichnis die kubeconfig-Datei kubeconfig erstellt. Sie benötigen diese kubeconfig-Datei später, um mit Ihrem Administratorcluster zu interagieren.

Die kubeconfig-Datei enthält den Namen Ihres Administratorclusters. Um den Clusternamen anzuzeigen, können Sie Folgendes ausführen:

kubectl config get-clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

In der Ausgabe wird der Name des Clusters angezeigt. Beispiele:

NAME
gke-admin-tqk8x

Wenn Sie möchten, können Sie den Namen und den Speicherort der kubeconfig-Datei ändern.

Verwalten Sie die Datei checkpoint.yaml:

Dieser Abschnitt gilt nur für nicht hochverfügbare Administratorcluster. Die Datei checkpoint.yaml wird nicht für die Erstellung von HA-Administratorclustern verwendet.

Wenn Sie den Befehl gkectl create admin zum Erstellen des Administratorclusters ausgeführt haben, wird eine Prüfpunktdatei im selben Datenspeicherordner wie das Datenlaufwerk des Administratorclusters erstellt. Standardmäßig hat diese Datei den Namen DATA_DISK_NAME‑checkpoint.yaml. Wenn die Länge von DATA_DISK_NAME größer oder gleich 245 Zeichen ist, lautet der Name aufgrund des vSphere-Limits für die Dateinamenlänge DATA_DISK_NAME.yaml.

Diese Datei enthält den Status des Administratorclusters und die Anmeldedaten. Sie wird für zukünftige Upgrades verwendet. Löschen Sie diese Datei nur, wenn Sie die Schritte zum Löschen eines Administratorclusters ausführen.

Wenn Sie die VM-Verschlüsselung in Ihrer Instanz von vCenter Server aktiviert haben, benötigen Sie die Berechtigung Kryptografische Vorgänge.Direktzugriff, bevor Sie Ihren Administratorcluster erstellen oder aktualisieren. Andernfalls wird der Prüfpunkt nicht hochgeladen. Wenn Sie diese Berechtigung nicht erhalten, können Sie das Hochladen der Prüfpunktdatei mithilfe des ausgeblendeten Flags --disable-checkpoint deaktivieren, wenn Sie einen relevanten Befehl ausführen.

Die Datei checkpoint.yaml wird automatisch aktualisiert, wenn Sie den Befehl gkectl upgrade admin ausführen oder wenn Sie einen gkectl update-Befehl ausführen, der sich auf den Administratorcluster auswirkt.

Prüfen Sie, ob der Administratorcluster ausgeführt wird

Prüfen Sie, ob der Administratorcluster ausgeführt wird:

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Ersetzen Sie ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei des Administratorclusters.

Die Ausgabe zeigt die Knoten des Administratorclusters. Beispiel:

admin-cp-vm-1   Ready    control-plane,master   ...
admin-cp-vm-2   Ready    control-plane,master   ...
admin-cp-vm-3   Ready    control-plane,master   ...

Dateien sichern

Wir empfehlen, die kubeconfig-Datei des Administratorclusters zu sichern. Kopieren Sie also die kubeconfig-Datei von Ihrer Administrator-Workstation an einen anderen Speicherort. Wenn Sie dann den Zugriff auf die Administrator-Workstation verlieren oder die kubeconfig-Datei auf Ihrer Administrator-Workstation versehentlich gelöscht wird, haben Sie weiterhin Zugriff auf den Administratorcluster.

Wir empfehlen außerdem, den privaten SSH-Schlüssel für Ihren Administratorcluster zu sichern. Wenn Sie dann den Zugriff auf den Administratorcluster verlieren, können Sie weiterhin über SSH eine Verbindung zu den Administratorclusterknoten herstellen. So können Sie Probleme mit der Verbindung zum Administratorcluster beheben und untersuchen.

Extrahieren Sie den SSH-Schlüssel aus dem Administratorcluster in eine Datei mit dem Namen admin-cluster-ssh-key:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secrets -n kube-system sshkeys \
    -o jsonpath='{.data.vsphere_tmp}' | base64 -d > admin-cluster-ssh-key

Jetzt können Sie admin-cluster-ssh-key an einem anderen Speicherort Ihrer Wahl sichern.

RBAC-Richtlinien

Wenn Sie den Abschnitt gkeConnect in die Konfigurationsdatei des Administratorclusters ausfüllen, wird der Cluster während der Erstellung oder Aktualisierung in Ihrer Flotte registriert. Zum Aktivieren der Flottenverwaltungsfunktionen stellt Google Cloud den Connect-Agenten bereit und erstellt ein Google-Dienstkonto, das das Projekt darstellt, für das der Cluster registriert ist. Der Connect-Agent stellt eine Verbindung mit dem Dienstkonto her, um Anfragen an den Kubernetes API-Server des Clusters zu verarbeiten. Dies ermöglicht den Zugriff auf Features zur Cluster- und Arbeitslastverwaltung in Google Cloud, einschließlich des Zugriffs auf die Google Cloud Console, mit der Sie mit Ihrem Cluster interagieren können.

Der Kubernetes API-Server des Administratorclusters muss in der Lage sein, Anfragen vom Connect-Agent zu autorisieren. Um dies zu gewährleisten, werden für das Dienstkonto die folgenden rollenbasierten Zugriffssteuerungsrichtlinien (RBAC) konfiguriert:

  • Eine Identitätsrichtlinie, die den Connect-Agent autorisiert, Anfragen im Namen des Dienstkontos an den Kubernetes API-Server zu senden.

  • Eine Berechtigungsrichtlinie, die die Vorgänge angibt, die in anderen Kubernetes-Ressourcen zulässig sind.

Das Dienstkonto und die RBAC-Richtlinien sind erforderlich, damit Sie den Lebenszyklus Ihrer Nutzercluster in der Google Cloud Console verwalten können.