Version 1.1. Diese Version wird nicht mehr unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Führen Sie ein Upgrade auf eine unterstützte Version durch, um die neuesten Patches und Updates für Sicherheitslücken, Kontakte und Probleme bei Anthos-Clustern in VMware (GKE On-Prem) zu erhalten. Die neueste Version finden Sie hier.

Installation mit statischen IP-Adressen

Auf dieser Seite wird erläutert, wie Sie GKE On-Prem in einer VMware vSphere 6.5-Umgebung mit statischen IP-Adressen installieren. Sie können die Anwendung auch über einen DHCP-Server installieren.

Übersicht

Die Anleitung auf dieser Seite zeigt, wie Sie ein Administratorcluster und ein Nutzercluster mit drei Knoten erstellen.

Nachdem Sie die Cluster erstellt haben, können Sie zusätzliche Nutzercluster erstellen und Knoten in einem Nutzercluster hinzufügen oder daraus entfernen.

Hinweis

  1. Richten Sie Ihre lokale Umgebung wie unter vSphere-Anforderungen beschrieben ein.

  2. Führen Sie die Schritte unter Installation vorbereiten aus.

  3. Erstellen Sie eine Admin-Workstation in vSphere.

  4. Erfahren Sie, wie Sie das manuelle Load-Balancing aktivieren, wenn Sie es verwenden möchten.

  5. Stellen Sie eine SSH-Verbindung zu Ihrer Administratorworkstation her:

    ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
    
  6. Wenn Sie einen Proxy verwenden, müssen Sie das Cloud SDK für den Proxy konfigurieren, damit Sie die Befehle gcloud und gsutil ausführen können. Eine Anleitung dazu finden Sie unter Cloud SDK für die Verwendung hinter einem Proxy bzw. einer Firewall konfigurieren.

  7. Melden Sie sich mit Ihren Kontoanmeldedaten in Google Cloud an:

    gcloud auth login
  8. Registrieren Sie gcloud als Credential Helper für Docker. (Weitere Informationen zu diesem Befehl):

    gcloud auth configure-docker
  9. Legen Sie ein Standardprojekt fest. Wenn Sie eine Standard-Google Cloud festlegen, werden alle Cloud SDK-Befehle für das Projekt ausgeführt, sodass Sie Ihr Projekt nicht für jeden Befehl angeben müssen:

    gcloud config set project [PROJECT_ID]
    

    Ersetzen Sie dabei [PROJECT_ID] durch Ihre Projekt-ID. Sie können Ihre Projekt-ID in der Cloud Console oder durch Ausführen von gcloud config get-value project ermitteln.

Container-Image-Registry für die Installation auswählen

Für die Installation muss GKE On-Prem wissen, wo seine Container-Clusterkomponenten abgerufen werden sollen. Es stehen zwei Optionen zur Verfügung:

Container Registry

Standardmäßig verwendet GKE On-Prem eine bestehende Google-eigene Container-Image-Registry, die von Container Registry gehostet wird. Abgesehen von der Einrichtung Ihres Proxys, um Zugriffe von gcr.io zuzulassen, ist keine weitere Einrichtung erforderlich.

Private Docker-Registry

Sie können für die Installation eine private Docker-Registry verwenden. GKE On-Prem überträgt seine Clusterkomponenten in diese Docker-Registry.

Vor der Installation müssen Sie die Registry konfigurieren. Während der Installation müssen Sie Informationen zur Registry in die GKE On-Prem-Konfigurationsdatei einfügen.

Private Docker-Registry für die Installation konfigurieren (optional)

In diesem Abschnitt wird erläutert, wie Sie eine vorhandene Docker-Registry für die Installation von GKE On-Prem konfigurieren. Informationen zum Erstellen einer Docker-Registry finden Sie unter Extern zugängliche Registry ausführen. Wenn Sie die Registry konfiguriert haben, füllen Sie das Feld privateregistryconfig der GKE On-Prem-Konfigurationsdatei aus.

Wenn Sie Ihre private Docker-Registry für die Installation verwenden möchten, muss Ihre Administratorworkstation-VM der Zertifizierungsstelle vertrauen, die Ihr Zertifikat signiert hat. GKE On-Prem unterstützt keine ungesicherten Docker-Registries. Wenn Sie Ihre Docker-Registry starten, müssen Sie ein Zertifikat und einen Schlüssel angeben. Das Zertifikat kann von einer öffentlichen Zertifizierungsstelle signiert werden oder es kann selbst signiert sein.

Führen Sie die folgenden Schritte von Ihrer VM für die Administratorworkstation aus, um diese Sicherheit zu schaffen:

  1. Erstellen Sie einen Ordner für das Zertifikat:

    sudo mkdir -p /etc/docker/certs.d/[REGISTRY_SERVER]
    

    Dabei ist [REGISTRY_SERVER] die IP-Adresse oder der Hostname der VM, die Ihre Docker-Registry ausführt.

  2. Kopieren Sie die Zertifikatsdatei in /etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt. Sie müssen die Datei ca.crt nennen, auch wenn sie ursprünglich einen anderen Namen hatte.

  3. Starten Sie den Docker-Dienst neu:

    sudo service docker restart
  4. Bestätigen Sie, dass Sie sich in Docker anmelden können:

    docker login -u [USERNAME] -p [PASSWORD] [REGISTRY_SERVER]

    Dabei sind [USERNAME] und [PASSWORD] die Anmeldedaten für die Anmeldung in der Docker-Registry.

Wenn Sie nun während der Installation gkectl prepare ausführen, werden die für die Installation benötigten Images in Ihre Docker-Registry übertragen.

Fehlerbehebung bei der Registry-Konfiguration

  • GET https://[REGISTRY_SERVER]/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers): Bestätigen Sie, dass Sie die richtige IP-Adresse für die VM haben, auf der die Docker-Registry ausgeführt wird.

  • login attempt to https://[REGISTRY_SERVER]/v2/ failed with status: 401 Unauthorized: Bestätigen Sie, dass Ihr Nutzername und Ihr Passwort korrekt sind.

  • GET https://[REGISTRY_SERVER]/v1/users/: x509: certificate signed by unknown authority: Ihre Administratorworkstation-VM traut dem Zertifikat nicht.

Statische IP-Adressen konfigurieren

Während der Installation generieren Sie eine GKE On-Prem-Konfigurationsdatei. Die von Ihnen generierte Konfigurationsdatei enthält zwei ipblockfilepath-Felder:

  • admincluster.ipblockfilepath
  • usercluster.ipblockfilepath.

Mit ipblockfilepath wird der Pfad zu einer YAML-Datei akzeptiert, die eine Datei mit der Hostkonfiguration (oder hostconfig) enthält, wie unten beschrieben.

Wenn Sie statische IPs verwenden möchten, müssen Sie in Ihrer Administratorworkstation zwei YAML-Dateien erstellen. Eine davon mit einer Datei hostconfig, die von Ihrem Administratorcluster verwendet wird, und eine weitere, die von Ihrem Nutzercluster verwendet wird.

Sie benötigen mindestens N + 4 IP-/Hostname-Paare in der Administratorcluster-IP-Konfiguration, wobei N die Anzahl der Nutzercluster ist, die Sie erstellen möchten.

Sie können einen Nutzercluster mit Hochverfügbarkeit erstellen. Ein Nutzercluster mit Hochverfügbarkeit verwendet drei Nutzersteuerungsebenen. Jede VM, auf der eine Nutzersteuerungsebene ausgeführt wird, benötigt eine eigene statische IP-Adresse. Da die Nutzersteuerungsebenen vom Administratorcluster verwaltet werden, müssen diese Werte in der Datei hostconfig des Administratorclusters bereitgestellt werden.

Beispiel

Das folgende Beispiel zeigt eine hostconfig-Datei mit drei Hosts. Ihre Datei kann je nach Umgebung unterschiedlich aussehen. Sie können beispielsweise das Array ips um weitere ip/hostname-Paare erweitern:

hostconfig:
  dns: 172.16.255.1
  tod: 192.138.210.214
  otherdns:
  - 8.8.8.8
  - 8.8.4.4
  othertod:
  - ntp.ubuntu.com
blocks:
  - netmask: 255.255.252.0
    gateway: 110.116.232.1
    ips:
    - ip: 10.116.232.23
      hostname: host1.enterprise.net  # will be trimmed to host1
    - ip: 10.116.232.65
      hostname: host2.enterprise.net  # will be trimmed to host2
    - ip: 10.116.232.66
      hostname: host3.enterprise.net  # will be trimmed to host3

Die YAML-Datei enthält zwei Abschnitte: hostconfig und blocks.

hostconfig

hostconfig enthält Netzwerkparameter, die statisch auf alle Knoten eines Clusters angewendet werden. hostconfig konfiguriert die folgenden Werte:

  • dns: IP-Adresse des DNS-Servers, der für Knoten verwendet werden soll.
  • tod: IP-Adresse des Zeitservers, der für Knoten verwendet werden soll.
  • otherdns: Alternative DNS-Server für Knoten.
  • othertod: Alternative Zeitserver für Knoten.

blocks

blocks enthält ein Array statischer IP-Adressblöcke. Derzeit berücksichtigt GKE On-Prem nur den ersten Block für die IP-Zuweisung. Jeder Block stellt ein Netzwerk und dessen IP-Adressen dar.

netmask und gateway

netmask und gateway stellen die Netzwerkmaske und das Standardgateway für Knoten dar.

blocks:
  - netmask: 255.255.252.0
    gateway: 110.116.232.1

ips

Ein ips-Array listet die von Ihnen zugewiesenen IP-Adressen auf. Jedes Objekt im Array enthält eine IPv4-Adresse und den zugehörigen Hostnamen:

blocks:
...
  ips:
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
  - ip: [IPV4_ADDRESS]
    hostname: [HOSTNAME]
...

GKE On-Prem erfasst freie und zugewiesene IP-Adressen in diesem Block und weist jedem Knoten in einem Cluster eine verfügbare IP-Adresse zu. Achten Sie darauf, dass die Anzahl der IP-Adressen im Array strikt größer als die Anzahl der Knoten im Cluster ist und dass jede IP-Adresse für das Netzwerk Ihrer Umgebung eindeutig ist.

hostname wird als lokaler Hostname ohne zugehörige Domain interpretiert. Wenn Sie einen vollqualifizierten Domainnamen (FQDN) angeben, wird der Domainname gekürzt. Aus host1.enterprise.net wird beispielsweise host1. hostname-Werte müssen Kleinbuchstaben sein.

hostconfig-Datei erstellen

Das folgende Beispiel zeigt eine hostconfig-Datei für einen Nutzercluster mit drei Knoten:

  1. Kopieren Sie die folgende Vorlage in eine YAML-Datei:

    hostconfig:
      dns:
      tod:
    blocks:
      - netmask:
        gateway:
        ips:
        - ip:
          hostname:
        - ip:
          hostname:
        - ip:
          hostname:
    
  2. Speichern Sie die Dateien unter anderen Namen, z. B. admin-cluster-hostconfig.yaml und user-cluster-hostconfig.yaml.

  3. Ändern Sie während der Installation die Felder admincluster.ipblockfilepath und usercluster.ipblockfilepath der Konfigurationsdatei mit den entsprechenden Dateien.

Private Schlüssel für Dienstkonten auf Ihrer Administratorworkstation erstellen

Unter Vorbereitung zur Installation haben Sie vier Dienstkonten erstellt. Jetzt müssen Sie eine private JSON-Schlüsseldatei für jedes dieser Dienstkonten erstellen. Diese Schlüssel geben Sie während der Installation an.

E-Mail-Adressen der Dienstkonten auflisten

Listen Sie zuerst die Dienstkonten in Ihrem Google Cloud-Projekt auf:

gcloud iam service-accounts list

Für ein Google Cloud-Projekt namens my-gcp-project sieht die Ausgabe dieses Befehls so aus:

gcloud iam service-accounts list
NAME                                    EMAIL
                                        access-service-account@my-gcp-project.iam.gserviceaccount.com
                                        register-service-account@my-gcp-project.iam.gserviceaccount.com
                                        connect-service-account@my-gcp-project.iam.gserviceaccount.com
                                        stackdriver-service-account@my-gcp-project.iam.gserviceaccount.com

Notieren Sie sich die E-Mail-Adressen der einzelnen Konten. Geben Sie für jeden der folgenden Abschnitte das E-Mail-Konto des entsprechenden Kontos an.

Zugriffsdienstkonto

gcloud iam service-accounts keys create access-key.json \
--iam-account [ACCESS_SERVICE_ACCOUNT_EMAIL]

Dabei ist [ACCESS_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse des Zugriffsdienstkontos.

Registrierungsdienstkonto

gcloud iam service-accounts keys create register-key.json \
--iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]

Dabei ist [REGISTER_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse des Registrierungsdienstkontos.

Verbindungsdienstkonto

gcloud iam service-accounts keys create connect-key.json \
--iam-account [CONNECT_SERVICE_ACCOUNT_EMAIL]

Dabei ist [CONNECT_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse des Verbindungsdienstkontos.

Cloud Monitoring-Dienstkonto

gcloud iam service-accounts keys create stackdriver-key.json \
--iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]

Dabei ist [STACKDRIVER_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse des Cloud Monitoring-Dienstkontos.

Zugriffsdienstkonto für Cloud SDK aktivieren

Wenn Sie Ihr Zugriffsdienstkonto für das Cloud SDK aktivieren, werden alle gcloud- und gsutil-Befehle als dieses Dienstkonto ausgeführt. Da Ihr Zugriffsdienstkonto für den Zugriff auf die GKE On-Prem-Binärdateien auf der Zulassungsliste steht, erhalten Sie durch die Aktivierung des Kontos für das Cloud SDK die Berechtigung, die GKE On-Prem-Binärdateien aus Cloud Storage herunterzuladen.

Führen Sie den folgenden Befehl aus, um Ihr Zugriffsdienstkonto zu aktivieren. Geben Sie den Pfad zur Schlüsseldatei des Kontos an, falls sich diese nicht im aktuellen Arbeitsverzeichnis befindet:

gcloud auth activate-service-account --key-file=access-key.json

Konfigurationsdatei generieren

Zum Starten einer Installation führen Sie gkectl create-config aus, um eine Konfigurationsdatei zu generieren. Sie ändern die Datei mit den Spezifikationen Ihrer Umgebung und den gewünschten Clusterspezifikationen.

Führen Sie zum Generieren der Datei den folgenden Befehl aus. Dabei ist --config [PATH] optional und akzeptiert einen Pfad und einen Namen für die Konfigurationsdatei. Wenn Sie --config weglassen, wird config.yaml im aktuellen Arbeitsverzeichnis erstellt:

gkectl create-config [--config [PATH]]

Konfigurationsdatei ändern

Nachdem Sie die Konfigurationsdatei generiert haben, müssen Sie sie anpassen, damit sie für Ihre Umgebung geeignet ist und Ihre Erwartungen hinsichtlich der Cluster erfüllt werden. In den folgenden Abschnitten werden die einzelnen Felder und die erwarteten Werte erläutert und es wird erklärt, wo Sie die Informationen finden können. Einige Felder sind standardmäßig auskommentiert. Wenn eines dieser Felder für Ihre Installation relevant ist, entfernen Sie die Kommentarzeichen und geben Sie Werte an.

bundlepath

Die GKE On-Prem-Bundle-Datei enthält alle Komponenten in einem bestimmten GKE On-Prem-Release. Wenn Sie eine Administratorworkstation erstellen, erhalten Sie ein vollständiges Bundle unter /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz. Die Version dieses Bundles entspricht der Version der OVA, die Sie zum Erstellen der Administratorworkstation importiert haben.

Legen Sie den Wert von bundlepath auf den Pfad der Bundle-Datei Ihrer Administratorworkstation fest. Setzen Sie also bundlepath auf:

/var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz

Dabei ist [VERSION] die Version von GKE On-Prem, die Sie installieren. Die neueste Version ist 1.1.2-gke.0.

Sie können Ihre Bundle-Datei an einem anderen Speicherort oder unter einem anderen Namen speichern. Achten Sie aber darauf, dass in Ihrer Konfigurationsdatei der Wert von bundlepath dem Pfad zu Ihrer Bundle-Datei entspricht.

vCenter-Spezifikation

Die vcenter-Spezifikation enthält Informationen zu Ihrer vCenter Server-Instanz. GKE On-Prem benötigt diese Informationen, um mit Ihrem vCenter Server zu kommunizieren.

vcenter.credentials.address

Das Feld vcenter.credentials.address enthält die IP-Adresse oder den Hostnamen Ihres vCenter-Servers.

Bevor Sie das Feld vsphere.credentials.address field ausfüllen, laden Sie das bereitgestellte Zertifikat Ihres vCenter-Servers herunter und prüfen Sie es. Geben Sie den folgenden Befehl ein, um das Zertifikat herunterzuladen und in einer Datei namens vcenter.pem zu speichern:

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

Öffnen Sie die Zertifikatsdatei, um den "Subject Common Name" und den "Subject Alternative Name" zu ermitteln:

openssl x509 -in vcenter.pem -text -noout

Die Ausgabe enthält den Subject Common Name (CN). Dies kann eine IP-Adresse oder ein Hostname sein. Beispiel:

Subject: ... CN = 203.0.113.100
Subject: ... CN = my-host.my-domain.example

Die Ausgabe kann auch unter Subject Alternative Name einen oder mehrere DNS-Namen enthalten:

X509v3 Subject Alternative Name:
    DNS:vcenter.my-domain.example

Wählen Sie den Common Name Subject oder einen der DNS-Namen unter Subject Alternative Name als Wert für vcenter.credentials.address in Ihrer Konfigurationsdatei aus. Beispiel:

vcenter:
  credentials:
    address: "203.0.113.1"
    ...
vcenter:
  credentials:
    address: "my-host.my-domain.example"
    ...

Sie müssen einen Wert auswählen, der im Zertifikat angezeigt wird. Wenn die IP-Adresse beispielsweise nicht im Zertifikat enthalten ist, können Sie sie nicht für vcenter.credentials.address verwenden.

vcenter.credentials

GKE On-Prem muss den Nutzernamen und das Passwort Ihres vCenter-Servers kennen. Legen Sie dazu die Werte username und password unter vcenter.credentials fest. Beispiel:

vcenter:
  credentials:
    ...
    username: "my-name"
    password: "my-password"

vcenter.datacenter, .datastore, .cluster, .network

GKE On-Prem benötigt einige Informationen zur Struktur Ihrer vSphere-Umgebung. Legen Sie die Werte unter vcenter fest, um diese Informationen anzugeben. Beispiel:

vcenter:
  ...
  datacenter: "MY-DATACENTER"
  datastore: "MY-DATASTORE"
  cluster: "MY-VSPHERE-CLUSTER"
  network: "MY-VIRTUAL-NETWORK"

vcenter.resourcepool

Ein vSphere-Ressourcenpool ist eine logische Gruppierung von vSphere-VMs in Ihrem vSphere-Cluster. Wenn Sie einen anderen Ressourcenpool als den Standardpool verwenden, geben Sie seinen Namen in vcenter.resourcepool an. Beispiel:

vcenter:
  ...
  resourcepool: "my-pool"

Wenn Sie möchten, dass GKE On-Prem seine Knoten im Standardressourcenpool des vSphere-Clusters bereitstellt, geben Sie für vcenter.resourcepool einen leeren String an. Beispiel:

vcenter:
  ...
  resourcepool: ""

vcenter.datadisk

GKE On-Prem erstellt ein VM-Laufwerk (VMDK), das die Kubernetes-Objektdaten für den Administratorcluster enthält. Das Installationsprogramm erstellt das VMDK für Sie, aber Sie müssen im Feld vcenter.datadisk einen Namen für das VMDK angeben. Beispiel:

vcenter:
  ...
  datadisk: "my-disk.vmdk"
vSAN-Datenspeicher: Ordner für das VMDK erstellen

Wenn Sie einen vSAN-Datenspeicher verwenden, müssen Sie das VMDK in einem Ordner ablegen. Sie müssen den Ordner im Voraus manuell erstellen. Erstellen Sie dazu mit govc einen Ordner:

govc datastore.mkdir my-gke-on-prem-folder

Derzeit ist es für ein bekanntes Problem erforderlich, dass Sie vcenter.datadisk den UUID-Pfad (Universally Unique Identifier) des Ordners und nicht den Dateipfad angeben. Wenn Sie die UUID des Ordners feststellen möchten, öffnen Sie den vCenter-Client. Wählen Sie dann Ihren Datenspeicher und den Ordner aus. Kopieren Sie die UUID des Ordners. Sie können auch den folgenden Befehl ausführen, wobei [ADMIN_CONTROL_PLANE_VM] die vSphere-VM ist, auf der die Administratorsteuerungsebene ausgeführt wird:

govc vm.info -json ./vm/[ADMIN_CONTROL_PLANE_VM] | jq '.VirtualMachines[0].Config.Hardware.Device[] | select(.Backing | has("FileName")) | .Backing.FileName'

Geben Sie dann die UUID des Ordners in das Feld vcenter.datadisk ein. Beispiel:

vcenter:
...
datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"

vcenter.cacertpath

Wenn ein Client wie GKE On-Prem eine Anfrage an vCenter Server sendet, muss der Server seine Identität gegenüber dem Client durch Vorlage eines Zertifikats bestätigen. Das Zertifikat ist von einer Zertifizierungsstelle signiert. Der Client prüft das Zertifikat des Servers mithilfe des Zertifikats der Zertifizierungsstelle.

Setzen Sie vcenter.cacertpath auf den Pfad des Zertifikats der Zertifizierungsstelle. Beispiel:

vcenter:
  ...
  cacertpath: "/my-cert-folder/altostrat.crt"

Unabhängig davon, ob Ihr vCenter-Server ein selbst signiertes Zertifikat oder ein von einer öffentlichen Zertifizierungsstelle signiertes Zertifikat verwendet, können Sie das Zertifikat der Zertifizierungsstelle abrufen. Dazu führen Sie diesen Befehl auf Ihrer Administrator-Workstation aus:

true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem

Dabei ist [VCENTER_IP] die IP-Adresse Ihres vCenter-Servers.

Proxyspezifikation

Wenn sich Ihr Netzwerk hinter einem Proxyserver befindet, füllen Sie das Feld proxy mit dem HTTPS-Proxy und den Adressen, die vom Proxy ausgeschlossen werden sollen. Beispiel:

proxy:
  url: "https://password:username@domain"
  noproxy: "100.151.222.0/24,corp.domain,100.151.2.1"
  • proxy.url ist die URL des HTTPS-Proxys.
  • proxy.noproxy enthält die CIDR, Domains und IP-Adressen, die den Proxy nicht verwenden sollen. Wenn Sie eine private Docker-Registry verwenden, umfasst dies in der Regel das vSphere-Subnetz und die private Registry-Adresse.

Spezifikation des Administratorclusters

Das Feld admincluster enthält Informationen, die GKE On-Prem zum Erstellen des Administratorclusters benötigt.

admincluster.vcenter.network

In admincluster.vcenter.network können Sie ein vCenter-Netzwerk für Ihre Administratorclusterknoten angeben. Dadurch wird die globale Einstellung überschrieben, die Sie in vcenter angegeben haben. Beispiel:

admincluster:
  vcenter:
    network: MY-ADMIN-CLUSTER-NETWORK

admincluster.ipblockfilepath

Da Sie statische IP-Adressen verwenden, benötigen Sie eine Hostkonfigurationsdatei, wie unter Statische IP-Adressen konfigurieren beschrieben. Geben Sie im Feld admincluster.ipblockfilepath den Pfad zu Ihrer Hostkonfigurationsdatei ein. Beispiel:

admincluster:
  ipblockfilepath: "/my-config-folder/my-admin-hostconfig.yaml"

admincluster.manuallbspec (manueller Load-Balancing-Modus)

Der Ingress-Controller im Administratorcluster ist als Dienst vom Typ NodePort implementiert. Der Dienst hat einen ServicePort für HTTP und einen weiteren ServicePort für HTTPS. Wenn Sie den manuellen Load-Balancing-Modus verwenden, müssen Sie nodePort-Werte für diese ServicePorts auswählen. Geben Sie die nodePort-Werte in ingresshttpnodeport und ingresshttpsnodeport an. Beispiel:

admincluster:
  ...
  manuallbspec:
    ingresshttpnodeport: 32527
    ingresshttpsnodeport: 30139

Der Kubernetes API-Server im Administratorcluster ist als Dienst vom Typ NodePort implementiert. Wenn Sie das manuelle Load-Balancing verwenden, müssen Sie einen Wert von nodePort für den Dienst auswählen. Geben Sie den nodePort-Wert in controlplanenodeport an. Beispiel:

admincluster:
  ...
  manuallbspec:
    ...
    controlplanenodeport: 30968

Der Add-on-Server im Administratorcluster ist als Dienst vom Typ NodePort implementiert. Wenn Sie das manuelle Load-Balancing verwenden, müssen Sie einen Wert von nodePort für den Dienst auswählen. Geben Sie den nodePort-Wert in controlplanenodeport an. Beispiel:

admincluster:
  manuallbspec:
    ...
    addonsnodeport: 30562

admincluster.bigip.credentials (integrierter Load-Balancing-Modus)

Wenn Sie das eingebundene Load-Balancing nicht verwenden, lassen Sie admincluster.bigip auskommentiert.

Wenn Sie den eingebundenen Load-Balancing-Modus verwenden, muss GKE On-Prem die IP-Adresse oder den Hostnamen, den Nutzernamen und das Passwort Ihres F5 BIG-IP-Load-Balancers kennen. Legen Sie dazu die Werte unter admincluster.bigip fest. Beispiel:

admincluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.2"
      username: "my-admin-f5-name"
      password: "rJDlm^%7aOzw"

admincluster.bigip.partition (integrierter Load-Balancing-Modus)

Wenn Sie den eingebundenen Load-Balancing-Modus verwenden, müssen Sie eine BIG-IP-Partition für Ihren Administratorcluster erstellen. Setzen Sie admincluster.bigip.partition auf den Namen Ihrer Partition. Beispiel:

admincluster:
  ...
  bigip:
    partition: "my-admin-f5-partition"

admincluster.vips

Unabhängig davon, ob Sie eingebundenes oder manuelles Load-Balancing für den Administratorcluster verwenden, müssen Sie das Feld admincluster.vips ausfüllen.

Setzen Sie den Wert von admincluster.vips.controlplanevip auf die IP-Adresse, die Sie für den Load-Balancer für den Kubernetes API-Server des Administratorclusters konfiguriert haben. Setzen Sie den Wert von ingressvip auf die IP-Adresse, die Sie für den Load-Balancer für den Ingress-Controller des Administratorclusters konfiguriert haben. Beispiel:

admincluster:
  ...
  vips:
    controlplanevip: 203.0.113.3
    ingressvip: 203.0.113.4

admincluster.serviceiprange und admincluster.podiprange

Der Administratorcluster muss einen Bereich von IP-Adressen für Dienste und einen Bereich von IP-Adressen für Pods haben. Diese Bereiche werden durch die Felder admincluster.serviceiprange und admincluster.podiprange festgelegt. Diese Felder werden ausgefüllt, wenn Sie gkectl create-config ausführen. Sie können die Werte auch ändern.

Die Bereich für Dienste und Pods dürfen sich nicht überschneiden. Außerdem dürfen sich diese beiden Bereiche nicht mit IP-Adressen überschneiden, die für Knoten in einem Cluster verwendet werden.

Beispiel:

admincluster:
  ...
  serviceiprange: 10.96.232.0/24
  podiprange: 192.168.0.0/16

Nutzercluster-Spezifikation

Die Nutzercluster-Spezifikation usercluster enthält Informationen, die GKE On-Prem zum Erstellen des ersten Nutzerclusters benötigt.

VMware DRS-Anti-Affinitätsregeln deaktivieren (optional)

Ab Version 1.1.0-gke.6 erstellt GKE On-Prem für die Knoten Ihres Nutzerclusters automatisch VMware-Anti-Affinitätsregeln vom Typ Distributed Resource Scheduler (DRS). Die Knoten werden damit auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt. Ab Version 1.1.0-gke.6 wird diese Funktion automatisch für neue und vorhandene Cluster aktiviert.

Für diese Funktion muss die vSphere-Umgebung die folgenden Bedingungen erfüllen:

  • VMware DRS ist aktiviert. Für VMware DRS ist die vSphere Enterprise Plus-Lizenzversion erforderlich. Informationen zum Aktivieren von DRS finden Sie unter Enabling VMware DRS in a cluster.
  • Das im Feld vcenter angegebene vSphere-Nutzerkonto hat die Berechtigung Host.Inventory.EditCluster.
  • Es sind mindestens drei physische Hosts verfügbar.

Wenn Sie DRS nicht aktiviert haben oder nicht mindestens drei Hosts haben, für die vSphere-VMs geplant werden können, fügen Sie Ihrer Konfigurationsdatei usercluster.antiaffinitygroups.enabled: false hinzu. Beispiel:

usercluster:
  ...
  antiaffinitygroups:
    enabled: false
Für Cluster mit mehr als drei Knoten
Wenn vSphere vMotion einen Knoten auf einen anderen Host verschiebt, müssen die Arbeitslasten des Knotens neu gestartet werden, bevor sie wieder auf die Hosts verteilt werden.

usercluster.vcenter.network

In usercluster.vcenter.network können Sie ein vCenter-Netzwerk für Ihre Nutzercluster-Knoten angeben. Dadurch wird die globale Einstellung überschrieben, die Sie in vcenter angegeben haben. Beispiel:

usercluster:
  vcenter:
    network: MY-USER-CLUSTER-NETWORK

usercluster.ipblockfilepath

Da Sie statische IP-Adressen verwenden, benötigen Sie eine Hostkonfigurationsdatei, wie unter Statische IP-Adressen konfigurieren beschrieben. Geben Sie im Feld usercluster.ipblockfilepath den Pfad zu Ihrer Hostkonfigurationsdatei ein. Beispiel:

usercluster:
  ipblockfilepath: "/my-config-folder/my-user-hostconfig.yaml"

usercluster.manuallbspec (manueller Load-Balancing-Modus)

Der Ingress-Controller im Nutzercluster ist als Dienst vom Typ NodePort implementiert. Der Dienst hat einen ServicePort für HTTP und einen weiteren ServicePort für HTTPS. Wenn Sie den manuellen Load-Balancing-Modus verwenden, müssen Sie nodePort-Werte für diese ServicePorts auswählen. Geben Sie die nodePort-Werte in ingresshttpnodeport und ingresshttpsnodeport an. Beispiel:

usercluster:
  manuallbspec:
    ingresshttpnodeport: 30243
    ingresshttpsnodeport: 30879

Der Kubernetes API-Server im Nutzercluster ist als Dienst vom Typ NodePort implementiert. Wenn Sie das manuelle Load-Balancing verwenden, müssen Sie einen Wert von nodePort für den Dienst auswählen. Geben Sie den nodePort-Wert in controlplanenodeport an. Beispiel:

usercluster:
  ...
  manuallbspec:
    ...
    controlplanenodeport: 30562

usercluster.bigip.credentials (eingebundener Load-Balancing-Modus)

Wenn Sie den eingebundenen Load-Balancing-Modus verwenden, benötigt GKE On-Prem die IP-Adresse, den Nutzernamen und das Passwort des F5 BIG-IP-Load-Balancers, den Sie für den Nutzercluster verwenden möchten. Legen Sie dazu die Werte unter usercluster.bigip fest. Beispiel:

usercluster:
  ...
  bigip:
    credentials:
      address: "203.0.113.5"
      username: "my-user-f5-name"
      password: "8%jfQATKO$#z"
  ...

usercluster.bigip.partition (eingebundener Load-Balancing-Modus)

Wenn Sie den eingebundenen Load-Balancing-Modus verwenden, müssen Sie für Ihren Nutzercluster eine BIG-IP-Partition erstellen. Setzen Sie usercluster.bigip.partition auf den Namen Ihrer Partition. Beispiel:

usercluster:
  ...
  bigip:
    partition: "my-user-f5-partition"
  ...

usercluster.vips

Unabhängig davon, ob Sie eingebundenes oder manuelles Load-Balancing für den Nutzercluster verwenden, müssen Sie das Feld usercluster.vips ausfüllen.

Setzen Sie den Wert von usercluster.vips.controlplanevip auf die IP-Adresse, die Sie für den Load-Balancer für den Kubernetes API-Server des Nutzerclusters konfiguriert haben. Setzen Sie den Wert von ingressvip auf die IP-Adresse, die Sie für den Load-Balancer für den Ingress-Controller des Nutzerclusters konfiguriert haben. Beispiel:

usercluster:
  ...
  vips:
    controlplanevip: 203.0.113.6
    ingressvip: 203.0.113.7

usercluster.serviceiprange und usercluster.podiprange

Der Nutzercluster muss einen IP-Adressbereich für Dienste und einen für Pods haben. Diese Bereiche werden durch die Felder usercluster.serviceiprange und usercluster.podiprange angegeben. Diese Felder werden ausgefüllt, wenn Sie gkectl create-config ausführen. Sie können die Werte auch ändern.

Die Bereich für Dienste und Pods dürfen sich nicht überschneiden. Außerdem dürfen sich diese beiden Bereiche nicht mit IP-Adressen überschneiden, die für Knoten in einem Cluster verwendet werden.

Beispiel:

usercluster:
  ...
  serviceiprange: 10.96.233.0/24
  podiprange: 172.16.0.0/12

usercluster.clustername

Setzen Sie den Wert von usercluster.clustername auf einen Namen Ihrer Wahl. Wählen Sie einen Namen aus, der aus höchstens 40 Zeichen besteht. Beispiel:

usercluster:
  ...
  clustername: "my-user-cluster-1"

usercluster.masternode.replicas

Das Feld usercluster.masternode.replicas legt fest, wie viele Knoten der Steuerungsebene der Nutzercluster haben soll. Ein Knoten der Steuerungsebene eines Nutzerclusters führt die Nutzersteuerungsebene aus, die Komponenten der Kubernetes-Steuerungsebene. Dieser Wert muss 1 oder 3 sein.

  • Legen Sie für dieses Feld 1 fest, um eine Nutzersteuerungsebene auszuführen.
  • Legen Sie dieses Feld auf 3 fest, wenn Sie eine hochverfügbare Nutzersteuerungsebene aus drei Knoten für die Steuerungsebene haben möchten, die jeweils eine Nutzersteuerungsebene ausführen.

usercluster.masternode.cpus und usercluster.masternode.memorymb

Durch die Felder usercluster.masternode.cpus und usercluster.masternode.memorymb wird festgelegt, wie viele CPUs und wie viel Arbeitsspeicher (in Megabyte) jedem Knoten für die Steuerungsebene des Nutzerclusters zugewiesen werden. Beispiel:

usercluster:
  ...
  masternode:
    cpus: 4
    memorymb: 8192

usercluster.workernode.replicas

Das Feld usercluster.workernode.replicas gibt an, wie viele Worker-Knoten der Nutzercluster haben soll. Die Clusterarbeitslasten werden von den Worker-Knoten ausgeführt.

usercluster.workernode.cpus und usercluster.workernode.memorymb

Durch die Felder usercluster.masternode.cpus und usercluster.masternode.memorymb wird angegeben, wie viele CPUs und wie viel Arbeitsspeicher (in Megabyte) jedem Worker-Knoten des Nutzerclusters zugewiesen werden. Beispiel:

usercluster:
  ...
  workernode:
    cpus: 4
    memorymb: 8192
    replicas: 3

usercluster.oidc

Wenn Sie möchten, dass Clients des Nutzerclusters die OIDC-Authentifizierung verwenden, legen Sie Werte für die Felder unter usercluster.oidc fest. Die Konfiguration von OIDC ist optional.

Informationen zum Konfigurieren von OIDC finden Sie unter Mit OIDC authentifizieren.

Informationen zur Installation von Version 1.0.2-gke.3

In Version 1.0.2-gke.3 werden die folgenden OIDC-Felder (usercluster.oidc) eingeführt. Mit diesen Feldern können Sie sich von der Cloud Console aus in einem Cluster anmelden:

  • usercluster.oidc.kubectlredirecturl
  • usercluster.oidc.clientsecret
  • usercluster.oidc.usehttpproxy

Wenn Sie in Version 1.0.2-gke.3 OIDC verwenden möchten, ist das Feld clientsecret erforderlich, auch wenn Sie sich nicht über die Cloud Console bei einem Cluster anmelden möchten. In diesem Fall können Sie einen Platzhalterwert für clientsecret angeben:

oidc:
clientsecret: "secret"

usercluster.sni

Server Name Indication (SNI), eine Erweiterung von Transport Layer Security (TLS), ermöglicht es Servern, je nach vom Client angegebenen Hostnamen mehrere Zertifikate an einer einzigen IP-Adresse und einem TCP-Port zu zeigen.

Wenn Ihre Zertifizierungsstelle bereits als vertrauenswürdige Zertifizierungsstelle an Clients außerhalb Ihres Nutzerclusters verteilt ist und Sie diese Kette zur Identifizierung vertrauenswürdiger Cluster verwenden möchten, können Sie den Kubernetes API-Server mit einem zusätzlichen Zertifikat konfigurieren, das externen Clients der Load Balancer-IP-Adresse angezeigt wird.

Wenn Sie SNI mit Ihren Nutzerclustern verwenden möchten, benötigen Sie eine eigene Zertifizierungsstelle und eine Public-Key-Infrastruktur (PKI). Sie stellen ein separates aktiv bereitgestelltes Zertifikat für jeden Nutzercluster bereit und GKE On-Prem fügt jedes zusätzliche aktiv bereitgestellte Zertifikat dem entsprechenden Nutzercluster hinzu.

Wenn Sie SNI für den Kubernetes API-Server des Nutzerclusters konfigurieren möchten, geben Sie Werte für usercluster.sni.certpath (Pfad zum externen Zertifikat) und usercluster.sni.keypath (Pfad zur Datei des privaten Schlüssels des externen Zertifikats) an. Beispiel:

usercluster:
  ...
  sni:
    certpath: "/my-cert-folder/example.com.crt"
    keypath: "/my-cert-folder/example.com.key"

lbmode

Sie können das eingebundene oder das manuelle Load-Balancing verwenden. Der ausgewählte Load-Balancing-Modus gilt für Ihren Administratorcluster und Ihren ersten Nutzercluster. Er gilt auch für alle zusätzlichen Nutzercluster, die Sie in Zukunft erstellen.

Geben Sie das gewünschte Load-Balancing an. Setzen Sie dazu den Wert von lbmode auf Integrated oder Manual. Beispiel:

lbmode: Integrated

gkeconnect

Die gkeconnect-Spezifikation enthält Informationen, die GKE On-Prem benötigt, um die Verwaltung Ihrer lokalen Cluster über die Google Cloud Console einzurichten.

Legen Sie für gkeconnect.projectid die Projekt-ID des Google Cloud-Projekts fest, in dem Sie Ihre lokalen Cluster verwalten möchten.

Legen Sie den Wert von gkeconnect.registerserviceaccountkeypath auf den Pfad der JSON-Schlüsseldatei für Ihr Registrierungsdienstkonto fest. Legen Sie den Wert von gkeconnect.agentserviceaccountkeypath auf den Pfad der JSON-Schlüsseldatei für Ihr Verbindungsdienstkonto fest.

Wenn der Connect Agent einen Proxy für die Kommunikation mit Google Cloud verwenden soll, legen Sie den Wert von gkeconnect.proxy auf die URL des Proxys fest. Verwenden Sie das Format http(s)://[PROXY_ADDRESS].

Beispiel:

gkeconnect:
  projectid: "my-project"
  registerserviceaccountkeypath: "/my-key-folder/register-key.json"
  agentserviceaccountkeypath: "/my-key-folder/connect-key.json"
  proxy: https://203.0.113.20

stackdriver

Die stackdriver-Spezifikation enthält Informationen, die GKE On-Prem zum Speichern von Logeinträgen benötigt, die von Ihren lokalen Clustern generiert wurden.

Legen Sie für stackdriver.projectid die Projekt-ID des Google Cloud-Projekts fest, in dem Sie Stackdriver-Logs zu Ihren lokalen Clustern aufrufen möchten.

Legen Sie stackdriver.clusterlocation für eine Google Cloud-Region fest, in der Sie Stackdriver-Logs speichern möchten. Es empfiehlt sich, eine Region in der Nähe Ihres lokalen Rechenzentrums auszuwählen.

Setzen Sie stackdriver.enablevpc auf true, wenn das Netzwerk Ihres Clusters durch eine VPC gesteuert wird. So wird gewährleistet, dass alle Telemetriedaten über die eingeschränkten IP-Adressen von Google übertragen werden.

Legen Sie stackdriver.serviceaccountkeypath auf den Pfad der JSON-Schlüsseldatei für Ihr Stackdriver Logging-Dienstkonto fest.

Beispiel:

stackdriver:
  projectid: "my-project"
  clusterlocation: "us-west1"
  enablevpc: false
  serviceaccountkeypath: "/my-key-folder/stackdriver-key.json"

privateregistryconfig

Wenn Sie eine private Docker-Registry haben, enthält das Feld privateregistryconfig Informationen, mit denen GKE On-Prem Images in Ihre private Registry überträgt. Wenn Sie keine private Registry angeben, ruft gkectl während der Installation das Container-Image für GKE On-Prem aus seinem Container Registry-Repository gcr.io/gke-on-prem-release ab.

Legen Sie unter privatedockerregistry.credentials address auf die IP-Adresse des Computers fest, auf dem Ihre private Docker-Registry ausgeführt wird. Legen Sie für username und password den Nutzernamen und das Passwort Ihrer privaten Docker-Registry fest.

Wenn Docker ein Image aus Ihrer privaten Registry abruft, muss die Registry ihre Identität anhand eines Zertifikats nachweisen. Das Zertifikat der Registry wird von einer Zertifizierungsstelle signiert. Docker verwendet das Zertifikat der Zertifizierungsstelle, um das Zertifikat der Registry zu validieren.

Setzen Sie privateregistryconfig.cacertpath auf den Pfad des Zertifikats der Zertifizierungsstelle. Beispiel:

privateregistryconfig
  ...
  cacertpath: /my-cert-folder/registry-ca.crt

gcrkeypath

Legen Sie den Wert von gcrkeypath auf den Pfad der JSON-Schlüsseldatei für Ihr Zugangsdienstkonto fest. Beispiel:

gcrkeypath: "/my-key-folder/access-key.json"

cloudauditlogging

Wenn Sie Ihre Kubernetes-Audit-Logs an Ihr Google Cloud-Projekt senden möchten, füllen Sie die cloudauditlogging-Spezifikation aus. Beispiel:

cloudauditlogging:
  projectid: "my-project"
  # A GCP region where you would like to store audit logs for this cluster.
  clusterlocation: "us-west1"
  # The absolute or relative path to the key file for a GCP service account used to
  # send audit logs from the cluster
  serviceaccountkeypath: "/my-key-folder/audit-logging-key.json"

Weitere Informationen zur Verwendung von Audit-Logs

Konfigurationsdatei validieren

Führen Sie diesen Schritt auf Ihrer Administratorworkstation aus.

Nachdem Sie die Konfigurationsdatei geändert haben, führen Sie gkectl check-config aus, um zu verifizieren, ob die Datei gültig ist und für die Installation verwendet werden kann:

gkectl check-config --config [PATH_TO_CONFIG]

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

Validierungen überspringen

Mit den folgenden gkectl-Befehlen wird Ihre Konfigurationsdatei automatisch validiert:

  • gkectl prepare
  • gkectl create cluster
  • gkectl upgrade

Übergeben Sie --skip-validation-all, um die Validierungen eines Befehls zu überspringen. So können Sie beispielsweise alle Validierungen für gkectl prepare überspringen:

gkectl prepare --config [PATH_TO_CONFIG] --skip-validation-all

So zeigen Sie alle verfügbaren Flags für das Überspringen bestimmter Validierungen an:

gkectl check-config --help

gkectl prepare ausführen

Vor der Installation müssen Sie gkectl prepare auf Ihrer Administratorworkstation ausführen, um Ihre vSphere-Umgebung zu initialisieren. Mit gkectl prepare werden die folgenden Aufgaben ausgeführt:

  • Importieren Sie das Knoten-Betriebssystem-Image in vSphere und markieren Sie es als Vorlage.

  • Wenn Sie eine private Docker-Registry verwenden, übertragen Sie GKE On-Prem-Images in Ihre Registry.

  • Optional können Sie die Build-Attestierungen der Container-Images validieren, um sicherzustellen, dass die Images von Google erstellt und signiert wurden und bereit für die Bereitstellung sind.

Führen Sie gkectl prepare mit der GKE On-Prem-Konfigurationsdatei aus, wobei --validate-attestations optional ist:

gkectl prepare --config [CONFIG_FILE] --validate-attestations

Die positive Ausgabe von --validate-attestations ist Image [IMAGE_NAME] validated.

GKE On-Prem installieren

Sie haben eine Konfigurationsdatei erstellt, die angibt, wie Ihre Umgebung aussieht und wie Ihre Cluster aussehen sollen, und Sie haben die Datei validiert. Sie haben gkectl prepare ausgeführt, um Ihre Umgebung mit der GKE On-Prem-Software zu initialisieren. Jetzt können Sie eine Neuinstallation von GKE On-Prem starten.

Führen Sie den folgenden Befehl aus, um GKE On-Prem zu installieren:

gkectl create cluster --config [CONFIG_FILE]

Dabei ist [CONFIG_FILE] die Konfigurationsdatei, die Sie generiert und geändert haben.

Sie können die Konfigurationsdatei wiederverwenden, um zusätzliche Nutzercluster zu erstellen.

Installation fortsetzen

Falls die Installation nach der Erstellung des Administratorclusters unterbrochen wird, können Sie die Installation folgendermaßen fortsetzen:

  • Die admincluster-Spezifikation wird aus der Konfigurationsdatei entfernt.
  • gkectl create cluster noch einmal ausführen und die kubeconfig-Datei des Administratorclusters übergeben
gkectl create cluster --config [CONFIG_FILE] \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

Dabei ist [ADMIN_CLUSTER_NAME] die kubeconfig-Datei des Administratorclusters, die beim Starten der Installation im Arbeitsverzeichnis erstellt wurde.

Bekannte Probleme

Derzeit können Sie eine Installation nicht fortsetzen, wenn Sie einen HA-Nutzercluster erstellen. Dieses Problem wird in einer zukünftigen Version behoben.

Cluster mit Google verbinden

Ingress aktivieren

Nachdem Ihr Nutzercluster ausgeführt wurde, müssen Sie Ingress durch Erstellen eines Gatewayobjekts aktivieren. Der erste Teil des Gateway-Manifests lautet immer:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system

Sie können den Rest des Manifests an Ihre Anforderungen anpassen. In diesem Manifest wird beispielsweise angegeben, dass Clients Anfragen mit dem HTTP/2-Protokoll und einem beliebigen Hostnamen an Port 80 senden können:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"

Wenn Sie HTTPS-Anfragen annehmen möchten, müssen Sie ein oder mehrere Zertifikate bereitstellen, die Ihr Ingress-Controller für Clients angeben kann.

So stellen Sie ein Zertifikat bereit:

  1. Erstellen Sie ein Secret mit Ihrem Zertifikat und Ihrem Schlüssel.
  2. Erstellen Sie ein Gateway-Objekt oder ändern Sie ein vorhandenes Gateway-Objekt, das auf Ihr Secret verweist. Der Name des Gateway-Objekts muss istio-autogenerated-k8s-ingress lauten.

Angenommen, Sie haben bereits eine Zertifikatsdatei ingress-wildcard.crt und die Schlüsseldatei ingress-wildcard.key erstellt.

Erstellen Sie ein Secret mit dem Namen ingressgateway-wildcard-certs:

kubectl create secret tls \
    --namespace gke-system \
    ingressgateway-wildcard-certs \
    --cert ./ingress-wildcard.crt \
    --key ./ingress-wildcard.key

Hier ist ein Manifest für ein Gateway, das sich auf Ihr Secret bezieht. Clients können Port 443 über das HTTPS-Protokoll und einen beliebigen Hostnamen aufrufen, der *.example.com entspricht. Beachten Sie, dass der Hostname im Zertifikat mit dem Hostnamen im Manifest übereinstimmen muss (in diesem Beispiel *.example.com):

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-autogenerated-k8s-ingress
  namespace: gke-system
spec:
  selector:
    istio: ingress-gke-system
  servers:
  - port:
      number: 80
      protocol: HTTP2
      name: http
    hosts:
    - "*"
  - hosts:
    - "*.example.com"
    port:
      name: https-demo-wildcard
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: ingressgateway-wildcard-certs

Sie können mehrere TLS-Zertifikate für verschiedene Hosts durch Ändern Ihres Gatewaymanifests erstellen.

Speichern Sie Ihr Manifest in einer Datei namens my-gateway.yaml und erstellen Sie das Gateway:

kubectl apply -f my-gateway.yaml

Jetzt können Sie Kubernetes Ingress-Objekte wie gewohnt verwenden.

Einschränkungen bei GKE On-Prem

Beschränkung Beschreibung
Höchst- und Mindestwerte für Cluster und Knoten

Siehe Kontingente und Limits. Die Leistung Ihrer Umgebung kann sich auf diese Einschränkungen auswirken.

Eindeutigkeit für Nutzerclusternamen

Alle im selben Google Cloud-Projekt registrierten Nutzercluster müssen eindeutige Namen haben.

Kann nicht in mehr als einem vCenter und/oder vSphere-Rechenzentrum bereitgestellt werden

Derzeit können Sie einen Administratorcluster und eine Reihe von verknüpften Nutzerclustern nur in einem einzelnen vCenter und/oder vSphere Rechenzentrum bereitstellen. Sie können dieselben Administrator- und Nutzercluster nicht in mehr als einem vCenter und/oder vSphere-Rechenzentrum bereitstellen.

Clusterkonfigurationen können nach der Erstellung nicht deklarativ geändert werden Sie können zusätzliche Cluster erstellen und die Größe vorhandener Cluster ändern. Sie können einen vorhandenen Cluster jedoch nicht über seine Konfigurationsdatei ändern.

Fehlerbehebung

Weitere Informationen finden Sie unter Fehlerbehebung.

Clusterprobleme mit gkectl diagnostizieren

Verwenden Sie gkectl diagnose-Befehle, um Clusterprobleme zu identifizieren und Clusterinformationen an Google zu senden. Siehe Clusterprobleme diagnostizieren.

Standard-Logging-Verhalten

Für gkectl und gkeadm reicht es aus, die Standard-Logging-Einstellungen zu verwenden:

  • Standardmäßig werden Logeinträge so gespeichert:

    • Für gkectl ist die Standard-Logdatei /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log per Symlink mit der Datei logs/gkectl-$(date).log im lokalen Verzeichnis verknüpft, in dem Sie gkectl ausführen.
    • Für gkeadm befindet sich die Standard-Logdatei logs/gkeadm-$(date).log im lokalen Verzeichnis, in dem Sie gkeadm ausführen.
  • Alle Logeinträge werden in der Logdatei gespeichert, auch wenn sie nicht im Terminal ausgegeben werden (wenn --alsologtostderr auf false gesetzt ist).
  • Die Ausführlichkeitsstufe -v5 (Standard) deckt alle Logeinträge ab, die vom Support-Team benötigt werden.
  • Die Logdatei enthält auch den ausgeführten Befehl und die Fehlermeldung.

Wir empfehlen Ihnen, die Logdatei an das Supportteam zu senden, wenn Sie Hilfe benötigen.

Nicht standardmäßigen Speicherort für die Logdatei angeben

Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkectl angeben möchten, verwenden Sie das Flag --log_file. Die von Ihnen angegebene Logdatei wird nicht per Symlink mit dem lokalen Verzeichnis verknüpft.

Wenn Sie einen nicht standardmäßigen Speicherort für die Logdatei gkeadm angeben möchten, verwenden Sie das Flag --log_file.

Cluster-API-Logs im Administratorcluster suchen

Wenn eine VM nach dem Start der Administrator-Steuerungsebene nicht gestartet wird, versuchen Sie, dies durch Untersuchen der Logs der Cluster-API-Controller im Administratorcluster zu beheben:

  1. Suchen Sie im Namespace kube-system den Namen des Cluster-API-Controller-Pods, wobei [ADMIN_CLUSTER_KUBECONFIG] der Pfad zur kubeconfig-Datei des Administratorclusters ist:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
  2. Öffnen Sie die Logs des Pods, wobei [POD_NAME] der Name des Pods ist. Verwenden Sie optional für die Fehlersuche grep oder ein ähnliches Tool:

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

F5 BIG-IP-Probleme mit der kubeconfig-Datei des Knotens für die Steuerungsebene des Administratorclusters beheben

Nach der Installation generiert GKE On-Prem eine kubeconfig-Datei im Basisverzeichnis Ihrer Administratorworkstation mit dem Namen internal-cluster-kubeconfig-debug. Diese kubeconfig-Datei ist mit der kubeconfig-Datei Ihres Administratorclusters identisch, mit der Ausnahme, dass sie direkt auf den Knoten der Steuerungsebene des Administratorclusters verweist, auf dem die Administratorsteuerungsebene ausgeführt wird. Sie können die Datei internal-cluster-kubeconfig-debug verwenden, um F5 BIG-IP-Probleme zu beheben.

gkectl check-config-Validierung schlägt fehl: F5 BIG-IP-Partitionen können nicht gefunden werden

Symptome

Die Validierung schlägt fehl, weil F5 BIG-IP-Partitionen nicht gefunden werden können, obwohl sie vorhanden sind.

Mögliche Ursachen

Ein Problem mit der F5 BIG-IP API kann dazu führen, dass die Validierung fehlschlägt.

Lösung

Versuchen Sie, gkectl check-config noch einmal auszuführen.

gkectl prepare --validate-attestations schlägt fehl: Build-Attestierung konnte nicht validiert werden

Symptome

Die Ausführung von gkectl prepare mit dem optionalen Flag --validate-attestations gibt den folgenden Fehler zurück:

could not validate build attestation for gcr.io/gke-on-prem-release/.../...: VIOLATES_POLICY
Mögliche Ursachen

Für die betroffenen Images ist möglicherweise keine Attestierung vorhanden.

Lösung

Versuchen Sie, die OVA der Administratorworkstation noch einmal herunterzuladen und bereitzustellen, wie in Administrator-Workstation erstellen beschrieben. Wenn das Problem weiterhin besteht, wenden Sie sich an Google.

Debugging mit den Logs des Bootstrap-Clusters

Während der Installation erstellt GKE On-Prem einen temporären Bootstrap-Cluster. Nach einer erfolgreichen Installation löscht GKE On-Prem den Bootstrap-Cluster, sodass Sie Ihren Administratorcluster und Ihren Nutzercluster erhalten. Normalerweise sollten Sie keinen Grund haben, mit diesem Cluster zu interagieren.

Wenn während einer Installation ein Fehler auftritt und Sie --cleanup-external-cluster=false an gkectl create cluster übergeben haben, ist es möglicherweise hilfreich, das Debugging mit den Logs des Bootstrap-Clusters durchzuführen. Sie können nach dem Pod suchen und seine Logs abrufen:

kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system
kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs [POD_NAME]

Nächste Schritte