Auf dieser Seite wird die Installation von GKE On-Prem in vSphere beschrieben. In der Anleitung auf dieser Seite erfahren Sie, wie Sie einen Administrator- und einen Nutzercluster erstellen. Nachdem Sie den Administratorcluster und den ersten Nutzercluster erstellt haben, können Sie zusätzliche Nutzercluster erstellen.
Hinweis
Richten Sie Ihre lokale Umgebung wie unter vSphere-Anforderungen beschrieben ein.
Führen Sie die Schritte unter Erste Schritte aus.
Erstellen Sie eine Admin-Workstation in vSphere.
Erstellen Sie eine private Docker-Registry, wenn Sie eine verwenden möchten.
Erfahren Sie, wie Sie das manuelle Load-Balancing aktivieren, wenn Sie es verwenden möchten.
Konfigurieren Sie statische IP-Adressen, wenn Sie sie verwenden möchten.
Stellen Sie eine SSH-Verbindung zu Ihrer Administratorworkstation her:
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
Autorisieren Sie
gcloud
zum Zugriff auf Google Cloud:gcloud auth login
Registrieren Sie
gcloud
als Credential Helper für Docker. (Weitere Informationen zu diesem Befehl):gcloud auth configure-docker
Legen Sie ein Standardprojekt fest. Wenn Sie eine Standard-Google Cloud festlegen, werden alle gcloud CLI-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 Google Cloud Console oder durch Ausführen vongcloud config get-value project
ermitteln.
Private Schlüssel für Dienstkonten auf Ihrer Administratorworkstation erstellen
Unter Erste Schritte 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-file \ --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 \ --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 \ --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 \ --iam-account [STACKDRIVER_SERVICE_ACCOUNT_EMAIL]
Dabei ist [STACKDRIVER_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse des Cloud Monitoring-Dienstkontos.
Aktivieren des Zugriffsdienstkontos für das Google Cloud CLI
Wenn Sie Ihr Zugriffsdienstkonto für die gcloud CLI aktivieren, werden alle gcloud
- und gsutil
-Befehle im Namen dieses Dienstkontos 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 die gcloud CLI 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
Ein GKE On-Prem-Bundle besteht aus einer Reihe von YAML-Dateien. Gemeinsam beschreiben die YAML-Dateien alle Komponenten in einem bestimmten Release von GKE On-Prem.
Wenn Sie eine Administratorworkstation erstellen, ist ein Bundle von /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION]-full.tgz
eingebunden.
Legen Sie den Wert von bundlepath
auf den Pfad Ihrer Bundle-Datei 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.
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.
gkeplatformversion
Das Feld gkeplatformversion
enthält die Kubernetes-Version des GKE On-Prem-Release, den Sie installieren. Sie hat folgendes Format:
[KUBERNETES_VERSION]-[GKE_PATCH]
Ein Beispiel für die Kubernetes-Version ist 1.12.7-gke.19.
Wenn Sie gkectl create-config
ausführen, wird dieses Feld automatisch ausgefüllt.
Die Versionierungsschemas für bundlepath
und gkeplatformversion
sind unterschiedlich. Eine bestimmte Bundle-Version hat jedoch eine entsprechende GKE-Plattformversion. Wenn die Bundle-Version beispielsweise 1.0.10 ist, muss die GKE-Plattformversion 1.12.7-gke.19 sein.
Falls Sie mehr über die Übereinstimmung zwischen einer Bundle-Version und der GKE-Plattformversion erfahren möchten, extrahieren Sie die Bundle-Datei, und sehen Sie sich die YAML-Dateien an.
Öffnen Sie insbesondere gke-onprem-vsphere-[VERSION]-images.yaml
und betrachten Sie das Feld osImages
. Sie können die GKE-Plattformversion dem Namen der Betriebssystem-Image-Datei entnehmen. Im folgenden Betriebssystem-Image sehen Sie beispielsweise, dass die GKE-Plattformversion 1.12.7-gke.19 ist.
osImages: admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"
vcenter
In diesem Feld deklarieren Sie globale Einstellungen für Ihren vCenter Server.
GKE On-Prem muss die IP-Adresse, den Nutzernamen und das Passwort Ihrer vCenter Server-Instanz kennen. Legen Sie die Werte unter vcenter
fest, um diese Informationen bereitzustellen. Beispiel:
vcenter: credentials: address: "203.0.113.1" username: "my-name" password: "my-password"
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" resourcepool: "my-pool"
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"
Wenn GKE On-Prem das VMDK in einem Verzeichnis speichern soll, müssen Sie das Verzeichnis vorab manuell erstellen. Sie könnten zum Beispiel govc
verwenden, um ein Verzeichnis zu erstellen:
govc datastore.mkdir my-gke-on-prem-directory
Fügen Sie das Verzeichnis dann in das Feld vcenter.datadisk
ein:
vcenter: ... datadisk: "my-gke-on-prem-directory/my-disk.vmdk"
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-directory/altostrat.crt"
Informationen zum Herunterladen des Zertifikats der Zertifizierungsstelle finden Sie unter vCenter Server-Stammzertifikate herunterladen und installieren.
Wenn Ihr vCenter-Server ein selbst signiertes Zertifikat verwendet, können Sie das Zertifikat extrahieren. Stellen Sie dazu eine Verbindung zu vCenter mit openssl
von der Admin-Workstation aus her:
true | openssl s_client -connect [VCENTER_IP]:443 -showcerts 2>/dev/null | sed -ne '/-BEGIN/,/-END/p' > vcenter.pem
gcrkeypath
Legen Sie den Wert von gcrkeypath
auf den Pfad der JSON-Schlüsseldatei für Ihr Zugangsdienstkonto fest.
Beispiel:
gcrkeypath: "/my-key-directory/access-key.json"
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
Das Feld gkeconnect
enthält Informationen, die GKE On-Prem zum Einrichten der Verwaltung Ihrer lokalen Cluster über die Google Cloud Console benötigt.
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-directory/register-key.json" agentserviceaccountkeypath: "/my-key-directory/connect-key.json" proxy: https://203.0.113.20
stackdriver
Das Feld stackdriver
enthält Informationen, die GKE On-Prem zum Speichern von Log-Einträ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.
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" proxyconfigsecretname: "" enablevpc: false serviceaccountkeypath: "/my-key-directory/logging-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-directory/registry-ca.crt
admincluster
Das Feld admincluster
enthält Informationen, die GKE On-Prem zum Erstellen des Administratorclusters benötigt.
vCenter-Netzwerk – Administratorcluster
In admincluster.vcenter.network
können Sie ein anderes vCenter-Netzwerk für Ihren Administratorcluster auswählen. Beachten Sie, dass dadurch die globale Einstellung überschrieben wird, die Sie in vcenter
angegeben haben. Beispiel:
admincluster: vcenter: network: MY-ADMIN-CLUSTER-NETWORK
DHCP- oder statische IP-Adressen – Administratorcluster
Entscheiden Sie, ob Sie das Dynamic Host Configuration Protocol (DHCP) verwenden möchten, um Ihren Administratorclusterknoten IP-Adressen zuzuweisen. Alternativ können Sie statische IP-Adressen für Ihre Clusterknoten verwenden. Wenn Sie den manuellen Load-Balancing-Modus verwenden, müssen Sie für Ihre Clusterknoten statische IP-Adressen verwenden.
Wenn Sie sich für die Verwendung von DHCP entscheiden, lassen Sie das Feld admincluster.ipblockfilepath
auskommentiert.
Wenn Sie statische IP-Adressen verwenden möchten, benötigen Sie eine Hostkonfigurationsdatei, wie unter Statische IP-Adressen konfigurieren.
Geben Sie im Feld admincluster.ipblockfilepath
den Pfad zu Ihrer Hostkonfigurationsdatei ein. Beispiel:
admincluster: ipblockfilepath: "/my-config-directory/my-admin-hostconfig.yaml"
Integriertes Load-Balancing – Administratorcluster
Wenn Sie den integrierten Load-Balancing-Modus verwenden, muss GKE On-Prem die IP-Adresse, den Nutzernamen und das Passwort Ihres BIG-IP-Load-Balancers kennen. Legen Sie die Werte unter admincluster.bigip
fest, um diese Informationen bereitzustellen. Beispiel:
admincluster: ... bigip: credentials: address: "203.0.113.2" username: "my-admin-f5-name" password: "rJDlm^%7aOzw"
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"
Manuelles Load-Balancing – Administratorcluster
Wenn Sie den manuellen Load-Balancing-Modus verwenden, müssen Sie statische IP-Adressen für Ihre Clusterknoten verwenden. Stellen Sie fest, ob Sie einen Wert für admincluster.ipblockfilepath
festgelegt haben. Beispiel:
admincluster: ipblockfilepath: "/my-config-directory/my-admin-hostconfig.yaml"
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
vips – Administratorcluster
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
serviceiprange und podiprange – Administratorcluster
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. Informationen zum Auswählen von IP-Bereichen für Dienste und Pods finden Sie unter IP-Adresszuweisung optimieren.
Die Dienst- und Pod-Bereiche dürfen sich nicht überschneiden. Außerdem dürfen sich die Dienst- und Pod-Bereiche, die Sie für den Administratorcluster ausgewählt haben, nicht mit den Dienst- und Pod-Bereichen überschneiden, die Sie für den Nutzercluster auswählen.
Beispiel:
admincluster: ... serviceiprange: 10.96.232.0/24 podiprange: 192.168.0.0/16
usercluster
Das Feld usercluster
enthält Informationen, die GKE On-Prem zum Erstellen des ersten Nutzerclusters benötigt.
vCenter-Netzwerk – Administratorcluster
In admincluster.vcenter.network
können Sie ein anderes vCenter-Netzwerk für Ihre Nutzercluster auswählen. Beachten Sie, dass dadurch die globale Einstellung überschrieben wird, die Sie in vcenter
angegeben haben. Beispiel:
usercluster: vcenter: network: MY-USER-CLUSTER-NETWORK
DHCP- oder statische IP-Adressen – Nutzercluster
Entscheiden Sie, ob Sie den Nutzerclusterknoten IP-Adressen mithilfe von DHCP zuweisen möchten. Alternativ können Sie statische IP-Adressen für Ihre Clusterknoten verwenden. Wenn Sie den manuellen Load-Balancing-Modus gewählt haben, müssen Sie statische IP-Adressen für Ihre Clusterknoten verwenden.
Wenn Sie sich für die Verwendung von DHCP entscheiden, lassen Sie das Feld usercluster.ipblockfilepath
auskommentiert.
Wenn Sie statische IP-Adressen verwenden möchten, benötigen Sie eine Hostkonfigurationsdatei, wie unter Statische IP-Adressen konfigurieren.
Geben Sie im Feld usercluster.ipblockfilepath
den Pfad zu Ihrer Hostkonfigurationsdatei ein. Beispiel:
usercluster: ipblockfilepath: "/my-config-directory/my-user-hostconfig.yaml"
Integriertes Load-Balancing – Nutzercluster
Wenn Sie den integrierten Load-BalancingModus verwenden, benötigt GKE On-Prem die IP-Adresse, den Nutzernamen und das Passwort des BIG-IP-Load-Balancers, den Sie für den Nutzercluster verwenden möchten. Legen Sie die Werte unter usercluster.bigip
fest, um diese Informationen bereitzustellen. Beispiel:
usercluster: ... bigip: credentials: address: "203.0.113.5" username: "my-user-f5-name" password: "8%jfQATKO$#z" ...
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" ...
Manuelles Load-Balancing – Nutzercluster
Wenn Sie den manuellen Load-Balancing-Modus verwenden, müssen Sie statische IP-Adressen für Ihre Clusterknoten verwenden. Stellen Sie fest, ob Sie einen Wert für usercluster.ipblockfilepath
festgelegt haben. Beispiel:
usercluster: ipblockfilepath: "/my-config-directory/my-user-hostconfig.yaml" ...
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
vips – Nutzercluster
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
serviceiprange und podiprange – Nutzercluster
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. Informationen zum Auswählen von IP-Bereichen für Dienste und Pods finden Sie unter IP-Adresszuweisung optimieren.
Die Dienst- und Pod-Bereiche dürfen sich nicht überschneiden. Außerdem dürfen sich die von Ihnen für den Nutzercluster ausgewählten Dienst- und Pod-Bereiche nicht mit den Dienst- und Pod-Bereichen überschneiden, die Sie für den Administratorcluster ausgewählt haben.
Beispiel:
usercluster: ... serviceiprange: 10.96.233.0/24 podiprange: 172.16.0.0/12
Clustername
Setzen Sie den Wert von usercluster.clustername
auf einen Namen Ihrer Wahl. Beispiel:
usercluster: ... clustername: "my-user-cluster-1"
masternode
Das Feld usercluster.masternode.replicas
gibt an, wie viele Knoten der Cluster für die Steuerungsebene haben soll. Die Knoten der Steuerungsebene für den Nutzercluster führen die Komponenten der Steuerungsebene für den Nutzercluster aus. 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 haben möchten. Es werden drei Steuerungsebenen für Nutzer erstellt.
Durch die Felder usercluster.masternode.cpus
und usercluster.masternode.memorymb
wird angegeben, 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
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.
In Version 1.0.2-gke.3 wurden die folgenden Pflichtfelder hinzugefügt. Mit diesen Feldern können Sie sich von der Google Cloud Console aus in einem Cluster anmelden:
- usercluster.oidc.kubectlredirecturl
- usercluster.oidc.clientsecret
- usercluster.oidc.usehttpproxy
Wenn Sie sich nicht über die Google Cloud Console in einem Cluster anmelden wollen, aber OIDC verwenden möchten, können Sie für diese Felder Platzhalterwerte übergeben:
oidc: kubectlredirecturl: "redirect.invalid" clientsecret: "secret" usehttpproxy: "false"
Weitere Informationen finden Sie unter Mit OIDC authentifizieren.
sni
Wenn Sie ein zusätzliches Bereitstellungszertifikat für den Kubernetes API-Server des Nutzerclusters bereitstellen möchten, geben Sie Werte für usercluster.sni.certpath
und usercluster.sni.keypath
an. Beispiel:
usercluster: ... sni: certpath: "/my-cert-directory/my-second-cert.crt" keypath: "/my-cert-directory/my-second-cert.key"
Workerknoten
Das Feld usercluster.workernode.replicas
gibt an, wie viele Worker-Knoten der Nutzercluster haben soll. Die Clusterarbeitslasten werden von den Worker-Knoten ausgeführt.
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
Konfigurationsdatei validieren
Nachdem Sie die Konfigurationsdatei geändert haben, führen Sie gkectl check-config
aus, um zu prüfen, 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.
Cluster mit Google verbinden
Wenn Sie einen Nutzercluster erstellen, wird dieser automatisch in Google Cloud registriert. Sie können einen registrierten GKE On-Prem-Cluster im Menü Kubernetes-Cluster der Google Cloud Console aufrufen. Von dort aus können Sie sich beim Cluster anmelden, um dessen Arbeitslasten anzuzeigen.
Wenn der Cluster nicht innerhalb einer Stunde nach der Erstellung in der Google Cloud Console angezeigt wird, lesen Sie den Abschnitt Fehlerbehebung bei der Verbindung.
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:
- Erstellen Sie ein Secret mit Ihrem Zertifikat und Ihrem Schlüssel.
- 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.
Problembehebung
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
. Die Datei ist per Symlink mit der Dateilogs/gkectl-$(date).log
im lokalen Verzeichnis verknüpft, in dem Siegkectl
ausführen. -
Für
gkeadm
ist die Standard-Logdateilogs/gkeadm-$(date).log
im lokalen Verzeichnis, in dem Siegkeadm
ausführen.
-
Für
- Alle Logeinträge werden in der Logdatei gespeichert, auch wenn sie nicht im Terminal ausgegeben werden (wenn
--alsologtostderr
auffalse
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:
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
Ö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]
Weitere Informationen
- Zusätzliche Nutzercluster erstellen
- Cluster in der Google Cloud Console ansehen
- Bei Clustern anmelden