Auf dieser Seite wird erläutert, wie Sie GKE On-Prem in einer VMware vSphere in der Version 6.5 oder 6.7 Update 3 mit statischen IP-Adressen installieren. Sie können auch mithilfe eines einem DHCP-Servers 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
Richten Sie Ihre Umgebung wie in den folgenden Themen beschrieben ein:
Erstellen Sie eine Admin-Workstation in vSphere.
Erfahren Sie, wie Sie das manuelle Load-Balancing aktivieren, wenn Sie es verwenden möchten.
Stellen Sie eine SSH-Verbindung zu Ihrer Administratorworkstation her:
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
-
Wenn sich Ihre Umgebung hinter einem Proxy befindet, verwenden alle
gkectl
-Befehle automatisch den gleichen Proxy, der inconfig.yaml
für Internetanfragen von der Administrator-Workstation festgelegt ist. Dies ist die empfohlene Umgebung, in der Ihre Administrator-Workstation und alle Ihre Cluster denselben Proxy verwenden. In diesem Anwendungsfall müssen Sie keine Proxyumgebungsvariablen festlegen.Manuelle Proxy-Optionen: Wenn sich Ihre Administrator-Workstation nicht hinter demselben Proxy befindet, müssen Sie Ihre Umgebung manuell konfigurieren, damit sie auf das Internet zugreifen kann. Sie können die Umgebungsvariable
HTTPS_PROXY
so einstellen, dass alleHTTPS
-Anfragen einschließlich dergkectl
-Befehle via Proxy versendet werden. Sie müssen aber auch die UmgebungsvariableNO_PROXY
für alle Anfragen konfigurieren, die vom Proxy ausgeschlossen werden sollen.Wenn Sie die Befehle
gcloud
undgsutil
auch einzeln ausführen müssen, können Sie Google Cloud CLI so konfigurieren, dass immer ein bestimmter Proxy verwendet wird. Eine Anleitung finden Sie unter gcloud CLI zur Verwendung hinter einem Proxy bzw. einer Firewall konfigurieren.Mit den folgenden Optionen können Sie manuell einen Proxy für Ihre
gkectl
-Befehle festlegen:- Alle
gkectl
-Befehle:Mit der Umgebungsvariable
HTTPS_PROXY
undNO_PROXY
können Sie manuell festlegen, wie allegkectl
-Befehle per Proxy festgelegt werden:- Legen Sie einen anderen Proxy für Ihre
gkectl
-Befehle fest. Beispiel:HTTPS_PROXY="http://my.other.proxy" NO_PROXY="10.0.1.0/24,private-registry.example,10.0.2.1"
- Schließen Sie Ihre
gkectl
-Befehle von der Proxyfunktion aus. Beispiel:HTTPS_PROXY=""
export HTTP_PROXY="http://[PROXY_ADDRESS]" export HTTPS_PROXY="http://[PROXY_ADDRESS]" export NO_PROXY="[NO_PROXY_ADDRESSES]"
Dabei gilt:
- [PROXY_ADDRESS] kann leer (
""
), eine Proxy-IP-Adresse oder der Hostname des Proxys sein. - [NO_PROXY_ADDRESSES] kann eine durch Kommas getrennte Liste von URLs, IP-Adressen oder Hostnamen sein, die vom Proxy ausgeschlossen werden sollen. Leerzeichen oder Tabs dürfen dabei nicht verwendet werden.
- Legen Sie einen anderen Proxy für Ihre
- Einzelne
gkectl
-Befehle:Sie können die Umgebungsvariable auch vor einen einzelnen
gkectl
-Befehl stellen, um einen angegebenen Proxy nur für diesen Aufruf zu verwenden.Beispiele:
Zum Weiterleiten Ihrer
gkectl
-Befehle über einen Proxy, der sich von den Angaben in Ihrer Konfigurationsdatei (config.yaml
) unterscheidet, verwenden Sie die UmgebungsvariableHTTPS_PROXY
:- So verwenden Sie den
http://my.other.proxy
-Proxy:-
HTTPS_PROXY="http://my.other.proxy" gkectl create cluster --config config.yaml
-
HTTPS_PROXY="http://my.other.proxy" gkectl prepare --config config.yaml
-
- Verwenden Sie einen leeren Wert, um einen Proxy auszuschließen:
HTTPS_PROXY="" gkectl create cluster --config config.yaml
HTTPS_PROXY="" gkectl check-config --config config.yaml
- So verwenden Sie den
- Alle
Melden Sie sich mit den Anmeldedaten Ihres Google Cloud-Nutzerkontos in Google Cloud an. Das Nutzerkonto muss mindestens die Viewer IAM-Rolle haben:
gcloud auth login
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.
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 Container-Image-Registry im Eigentum von Google, 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 die Docker-Registry. Legen Sie das Feld privateregistryconfig
fest, um eine private Docker-Registry anzugeben.
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.
Nachdem Sie die Registrierung 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 Administrator-Workstation-VM der Zertifizierungsstelle vertrauen, die Ihr Zertifikat signiert hat. GKE On-Prem unterstützt keine unsicheren 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:
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.
Kopieren Sie die Zertifikatsdatei in
/etc/docker/certs.d/[REGISTRY_SERVER]/ca.crt
. Sie müssen die Dateica.crt
nennen, auch wenn sie ursprünglich einen anderen Namen hatte.Starten Sie den Docker-Dienst neu:
sudo service docker restart
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
Wenn Sie statische IP-Adressen verwenden möchten, müssen Sie zwei IP-Blockdateien erstellen: eine für Ihren Administratorcluster und eine für Ihren Nutzercluster. Die IP-Blockdateien teilen GKE On-Prem mit, welche IP-Adressen und Hostnamen Ihren Clusterknoten zugewiesen werden sollen.
Statische IP-Adressen für den Administratorcluster
Der Administratorcluster benötigt Adressen für die folgenden Knoten:
- Einen Knoten für die Steuerungsebene des Administratorclusters
- Zwei Knoten für Add-ons im Administratorcluster
- Einen temporären Knoten während eines Upgrades des Administratorclusters
- Für jeden zugeordneten Nutzercluster einen oder drei Knoten
Bei einem hochverfügbaren Nutzercluster hat der Administratorcluster drei Knoten, auf denen Komponenten der Steuerungsebene für den Nutzercluster ausgeführt werden. Bei einem nicht hochverfügbaren Nutzercluster verfügt der Administratorcluster über einen Knoten, auf dem Komponenten der Steuerungsebene für den Nutzercluster ausgeführt werden.
Angenommen, N ist die Anzahl der nicht hochverfügbaren Nutzercluster, die Sie erstellen möchten, und H ist die Anzahl der hochverfügbaren Nutzercluster, die Sie erstellen möchten. In der IP-Blockdatei für Ihren Administratorcluster müssen Sie mindestens so viele IP-Adressen angeben:
4 + N + 3 x H
Beispiel: Sie möchten einen Administratorcluster und einen hochverfügbaren Nutzercluster erstellen. Dann müssen Sie sieben IP-Adressen für Ihren Administratorcluster reservieren. Hier ein Beispiel für eine IP-Blockdatei, die sieben IP-Adressen angibt:
blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.10 hostname: admin-host1 - ip: 172.16.20.11 hostname: admin-host2 - ip: 172.16.20.12 hostname: admin-host3 - ip: 172.16.20.13 hostname: admin-host4 - ip: 172.16.20.14 hostname: admin-host5 - ip: 172.16.20.15 hostname: admin-host6 - ip: 172.16.20.16 hostname: admin-host7
Wie im vorherigen Beispiel dargestellt, enthält eine IP-Blockdatei eine YAML-Datenstruktur.
Das Feld ips
enthält ein Array von IP-Adressen und Hostnamen. Dies sind die IP-Adressen und Hostnamen, die GKE On-Prem den Knoten Ihres Administratorclusters zuweist.
In der IP-Blockdatei können Sie auch die Adressen der DNS-Server, Zeitserver und des Standardgateway angeben, die von den Administratorclusterknoten verwendet werden.
Statische IP-Adressen für einen Nutzercluster
Ein Nutzercluster benötigt eine IP-Adresse für jeden Knoten und eine zusätzliche IP-Adresse, die während eines Upgrades des Nutzerclusters für einen temporären Knoten verwendet wird.
Beispiel: Sie möchten einen Nutzercluster mit fünf Knoten erstellen. In diesem Fall müssen Sie sechs IP-Adressen für Ihren User-Cluster reservieren. Hier ein Beispiel für eine IP-Blockdatei, in der sechs IP- und Hostname-Paare angegeben sind.
blocks: - netmask: 255.255.252.0 gateway: 172.16.23.254 ips: - ip: 172.16.20.17 hostname: user-host1 - ip: 172.16.20.18 hostname: user-host2 - ip: 172.16.20.19 hostname: user-host3 - ip: 172.16.20.20 hostname: user-host4 - ip: 172.16.20.21 hostname: user-host5 - ip: 172.16.20.22 hostname: user-host6
Jeder hostname
wird als lokaler Hostname ohne eigene Domain interpretiert. Wenn Sie einen vollständig qualifizierten Domainnamen angeben, wird die Domain gekürzt. Aus host1.enterprise.net
wird beispielsweise host1
. Der Wert eines hostname
-Felds muss kleingeschrieben werden.
Private Schlüssel für Dienstkonten auf Ihrer Administratorworkstation erstellen
Wenn Sie noch keine JSON-Schlüssel für Ihre Dienstkonten erstellt haben, erstellen Sie sie jetzt.
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 ... EMAIL component-accesss-sa@my-gcp-project.iam.gserviceaccount.com connect-register-sa@my-gcp-project.iam.gserviceaccount.com connect-agent-sa@my-gcp-project.iam.gserviceaccount.com log-mon-sa@my-gcp-project.iam.gserviceaccount.com
Notieren Sie sich die E-Mail-Adressen der einzelnen Konten. Geben Sie für alle folgenden Abschnitte das E-Mail-Konto des entsprechenden Kontos an.
Dienstkonto für den Zugriff auf Komponenten
gcloud iam service-accounts keys create component-access-key.json \ --iam-account [COMPONENT_ACCESS_SERVICE_ACCOUNT_EMAIL]
Dabei ist [COMPOONENT_ACCESS_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse des Komponenten-Zugriff-Dienstkontos.
Connect-Register-Dienstkonto
gcloud iam service-accounts keys create connect-register-key.json \ --iam-account [REGISTER_SERVICE_ACCOUNT_EMAIL]
Dabei ist [CONECT_REGISTER_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse Ihres Connect-Register-Dienstkontos.
Connect-Agent-Dienstkonto
gcloud iam service-accounts keys create connect-agent-key.json \ --iam-account [CONNECT_AGENT_SERVICE_ACCOUNT_EMAIL]
Dabei ist [CONNECT_AGENT_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse Ihres Connect-Agent-Dienstkontos.
Logging-Monitoring-Dienstkonto
gcloud iam service-accounts keys create logging-monitoring-key.json \ --iam-account [LOGGING_MONITORING_SERVICE_ACCOUNT_EMAIL]
Dabei ist [LOGGING_MONITORINGH_SERVICE_ACCOUNT_EMAIL] die E-Mail-Adresse Ihres Logging-Monitoring-Dienstkontos.
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.
In diesem Abschnitt erfahren Sie, wie Sie mit einem einzigen Befehl einen Administrator- und einen Nutzercluster erstellen. Ab Version 1.2 können Sie Ihre Administrator- und Nutzercluster separat erstellen.
bundlepath
Die GKE On-Prem-Bundle-Datei enthält alle Komponenten in einem bestimmten GKE On-Prem-Release.
Wenn Sie eine Administrator-Workstation 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.5.2-gke.3.
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 dazu die Werte unter vcenter
fest.
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 -namespace=true my-gke-on-prem-folder
Legen Sie dann
vcenter.datadisk
auf den Pfad des VMDK einschließlich des Ordners fest. Beispiel:vcenter: ... datadisk: "my-gke-on-prem-folder/my-disk.vmdk"
In Version 1.1.1 und früheren Versionen muss aufgrund eines bekannten Problems der UUID-Pfad (Universally Unique Identifier) des Ordners und nicht den Dateipfad für
vcenter.datadisk
angegeben werden. Kopieren Sie dies aus der Ausgabe des obigengovc
-Befehls.Geben Sie dann die UUID des Ordners in das Feld
vcenter.datadisk
ein. Fügen Sie keinen Schrägstrich vor der UUID ein. Beispiel:vcenter: ... datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
Dieses Problem wurde ab der Version 1.1.2 behoben.
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 oder eines Zertifikatpakets bestätigen. Zum Prüfen des Zertifikats oder Pakets muss GKE On-Prem das Root-Zertifikat in der Vertrauenskette haben.
Legen Sie für vcenter.cacertpath
den Pfad des Root-Zertifikats fest. Beispiel:
vcenter: ... cacertpath: "/my-cert-folder/the-root.crt"
Ihre VM-Installation hat eine Zertifizierungsstelle (Certificate Authority, CA), die ein Zertifikat für Ihren vCenter-Server ausstellt. Das Root-Zertifikat in der Vertrauenskette ist ein selbst signiertes Zertifikat, das von VMware erstellt wurde.
Wenn Sie nicht die VMware-Standardzertifizierungsstelle verwenden möchten, können Sie VMware so konfigurieren, dass eine andere Zertifizierungsstelle genutzt wird.
Sollte Ihr vCenter-Server ein von der VMware-Standardzertifizierungsstelle ausgestelltes Zertifikat verwenden, gibt es mehrere Möglichkeiten, das Root-Zertifikat abzurufen:
curl -k "https://[SERVER_ADDRESS]/certs/download.zip" > download.zip
Dabei ist [SERVER_ADDRESS] die Adresse Ihres vCenter-Servers.
Geben Sie in einem Browser die Adresse Ihres vCenter-Servers ein. Klicken Sie im grauen Feld rechts auf Vertrauenswürdige Root-CA-Zertifikate herunterladen.
Geben Sie den folgenden Befehl ein, um das bereitgestellte Zertifikat abzurufen:
true | openssl s_client -connect [SERVER_ADDRESS]:443 -showcerts
Suchen Sie in der Ausgabe nach einer URL wie dieser: https://[SERVER_ADDRESS]/afd/vecs/ca. Geben Sie die URL in einen Browser ein. Dadurch wird das Root-Zertifikat heruntergeladen.
Die heruntergeladene Datei heißt downloads.zip
.
Entpacken Sie die Datei:
unzip downloads.zip
Wenn der Befehl zum Entpacken beim ersten Mal nicht funktioniert, geben Sie ihn noch einmal ein.
Suchen Sie die Zertifikatsdatei in certs/lin
.
Proxy-Spezifikation
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://username:password@domain" noproxy: "10.0.1.0/24,private-registry.example,10.0.2.1"
proxy.url
ist die URL des HTTPS-Proxys.proxy.noproxy
enthält die CIDR-Bereiche, IP-Adressen, Domains und Hostnamen, die nicht weitergeleitet werden sollten. Beispielsweise sollten Aufrufe von IP-Adressen von Clusterknoten nicht weitergeleitet werden. Wenn Sie also ein Subnetz haben, das nur Clusterknoten enthält, können Sie den CIDR-Bereich des Subnetzes im Feldnoproxy
auflisten. Achten Sie auf Folgendes: Wennprivateregistryconfig
angegeben ist, wird diese Adresse automatisch hinzugefügt, um Aufrufe Ihrer privaten Registry zu verhindern.
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 IP-Blockdatei, wie unter Statische IP-Adressen konfigurieren beschrieben. Geben Sie den Pfad zu Ihrer IP-Blockdatei im Feld admincluster.ipblockfilepath
ein. Beispiel:
admincluster: ipblockfilepath: "/my-config-folder/my-admin-ipblock.yaml"
admincluster.manuallbspec (manueller Load-Balancing-Modus)
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 integrierte Load-Balancing nicht verwenden, lassen Sie admincluster.bigip
auskommentiert.
Wenn Sie das eingebundene Load-Balancing 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 Services und einen Bereich von IP-Adressen für Pods haben. Diese Bereiche werden durch die Felder admincluster.serviceiprange
und admincluster.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:
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)
GKE On-Prem erstellt automatisch die DRS-Anti-Affinitätsregeln (Distributed Resource Scheduler) für die Knoten Ihres Nutzerclusters, wodurch sie auf mindestens drei physische Hosts in Ihrem Rechenzentrum verteilt werden.
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 BerechtigungHost.Inventory.EditCluster
. - Es sind mindestens drei physische Hosts verfügbar.
Wenn Sie eine vSphere Standard-Lizenz haben, können Sie VMware DRS nicht aktivieren.
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
Weitere Informationen finden Sie in den Versionshinweisen für Version 1.1.0-gke.6.
- 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 IP-Blockdatei, wie unter Statische IP-Adressen konfigurieren beschrieben.
Geben Sie den Pfad zu Ihrer IP-Blockdatei im Feld usercluster.ipblockfilepath
ein. Beispiel:
usercluster: ipblockfilepath: "/my-config-folder/my-user-ipblock.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 das eingebundene Load-Balancing 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 Services 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 Google 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 Google Cloud Console bei einem Cluster anmelden möchten. In diesem Fall können Sie einen Platzhalterwert fürclientsecret
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.
Um SNI für den Kubernetes API-Server des Nutzerclusters zu konfigurieren, 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.
Beispiel:
gkeconnect: projectid: "my-project" registerserviceaccountkeypath: "/my-key-folder/register-key.json" agentserviceaccountkeypath: "/my-key-folder/connect-key.json"
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 username
und password
auf den Nutzernamen sowie das Passwort Ihrer privaten Docker-Registry fest. Der Wert, den Sie für address
festlegen, wird automatisch proxy.noproxy
hinzugefügt.
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 Dienstkonto für den Zugriff auf Komponenten fest.
Beispiel:
gcrkeypath: "/my-key-folder/component-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 Google Cloud 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 Google Cloud 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] --fast
Wenn der Befehl FAILURE
-Meldungen zurückgibt, beheben Sie die Probleme und validieren Sie die Datei noch einmal. Verwenden Sie das Flag --fast
, um Prüfungen zu überspringen, bei der Test-VMs erstellt werden. Dies hängt davon ab, welches Knoten-Betriebssystem-Image von gkectl prepare
von der Administratorworkstation in vCenter hochgeladen wird.
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
.
Konfigurationsdatei noch einmal prüfen
Nachdem Sie das Knoten-Betriebssystem-Image durch Ausführen von gkectl prepare
hochgeladen haben, führen Sie gkectl check-config
ohne das Flag --fast
aus. Damit können zusätzliche Prüfungen, die Test-VMs erstellen, ausgeführt werden.
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.
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.
Erstellen Sie zum Installieren von GKE On-Prem die Administrator- und Nutzercluster. Mit den folgenden Schritten werden sowohl der Administratorcluster als auch der Nutzercluster im selben Vorgang erstellt. Wenn Sie jeden Cluster separat erstellen möchten, lesen Sie Administrator- und Nutzercluster separat erstellen.
So erstellen Sie die Administrator- und Nutzercluster:
Erstellen Sie den Administratorcluster und den Nutzercluster mit dem Befehl
gkectl create cluster
.gkectl create cluster --config [CONFIG_FILE]
Dabei ist [CONFIG_FILE] die zuvor erstellte Konfigurationsdatei.
Der Befehl
gkectl create cluster
erstelltkubeconfig
-Dateien mit dem Namen[CLUSTER_NAME]-kubeconfig
im aktuellen Verzeichnis, wobei [CLUSTER_NAME] der Name ist, den Sie fürcluster
festgelegt haben. Beispiel:MY-VSPHERE-CLUSTER-kubeconfig
Die GKE-On-Prem-Dokumentation verwendet die folgenden Platzhalter, um auf diese
kubeconfig
-Dateien zu verweisen:- Administratorcluster: [ADMIN_CLUSTER_KUBECONFIG]
- Nutzercluster: [USER_CLUSTER_KUBECONFIG]
Prüfen Sie, ob der Cluster erstellt und ausgeführt wird:
Führen Sie den folgenden Befehl aus, um den Administratorcluster zu prüfen:
kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
Die Ausgabe listet die Knoten des Administratorclusters auf.
Führen Sie den folgenden Befehl aus, um den Nutzercluster zu prüfen:
kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]
Die Ausgabe listet die Knoten des Nutzerclusters auf. Beispiel:
NAME STATUS ROLES AGE VERSION xxxxxx-1234-ipam-15008527 Ready <none> 12m v1.14.7-gke.24 xxxxxx-1234-ipam-1500852a Ready <none> 12m v1.14.7-gke.24 xxxxxx-1234-ipam-15008536 Ready <none> 12m v1.14.7-gke.24
So verwenden Sie die Konfigurationsdatei wieder, um zusätzliche Nutzercluster zu erstellen.
Installation fortsetzen
Wenn Ihre Installation unterbrochen wird, nachdem der Administratorcluster erstellt wurde, können Sie die Installation mit den folgenden Schritten fortsetzen:
- Entfernen Sie die
admincluster
-Spezifikation aus der Konfigurationsdatei. Führen Sie
gkectl create cluster
mit den Flags--kubeconfig
und--skip-validation-all
aus, um die kubeconfig-Datei des Administratorclusters zu übergeben, und überspringen Sie die Preflight-Prüfungen:gkectl create cluster \ --config [CONFIG_FILE] \ --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \ --skip-validation-all
Dabei ist [ADMIN_CLUSTER_NAME] die kubeconfig-Datei des Administratorclusters, die beim Starten der Installation im Arbeitsverzeichnis erstellt wurde.
Cluster mit Google verbinden
Wenn Sie die Spezifikation
gkeconnect
ausfüllen, wird Ihr Nutzercluster automatisch in der Google Cloud Console 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.
Administrator- und Nutzercluster separat erstellen
Ab der GKE On-Prem-Version 1.2 können Sie Ihre Administrator- und Nutzercluster separat erstellen. Das heißt, Sie können zuerst nur einen Administratorcluster erstellen. Anschließend können Sie nach Bedarf einen oder mehrere Nutzercluster erstellen.
Vor Version 1.2:
Ihr erster Nutzercluster hat immer den Datenspeicher der Administratorcluster verwendet. Später erstellte Nutzercluster könnten einen Datenspeicher verwenden, der vom Datenspeicher des Administratorclusters getrennt ist.
Wenn Sie einen separaten Datenspeicher für einen Nutzercluster angegeben haben, haben die Worker-Knoten des Nutzerclusters und die PersistentVolumes (PVs) für die Worker-Knoten den separaten Datenspeicher verwendet. Die Nutzersteuerungsebenen-VMs und die zugehörigen PVs verwendeten jedoch den Datenspeicher des Administratorclusters.
Ab Version 1.2:
Jeder Nutzercluster, auch Ihr erster Cluster, kann einen Datenspeicher verwenden, der vom Datenspeicher des Administratorclusters getrennt ist.
Wenn Sie einen separaten Datenspeicher für einen Nutzercluster angeben, verwenden die Nutzercluster-Worker-Knoten, PVs für die Nutzercluster-Worker-Knoten, Nutzersteuerungsebenen-VMs und PVs für die Nutzersteuerungsebenen-VMs den separaten Datenspeicher.
Um nur einen Administratorcluster zu erstellen, entfernen Sie den gesamten Abschnitt usercluster
aus der Cluster-Konfigurationsdatei. Geben Sie dann den Befehl gkectl create
ein:
gkectl create --config [ADMIN_CONFIG_FILE]
Dabei ist [ADMIN_CONFIG_FILE] der Pfad Ihrer Konfigurationsdatei, aus der der Abschnitt usercluster
entfernt wurde.
Erstellen Sie als Nächstes eine Konfigurationsdatei, in der der gesamte Abschnitt admincluster
entfernt ist. In dieser Datei können Sie einen vSphere-Datenspeicher angeben, der sich vom Datenspeicher des Administratorclusters unterscheidet. Um einen Datenspeicher anzugeben, geben Sie einen Wert für vcenter.credentials.datastore
ein. Beispiel:
vcenter: credentials: ... ... datastore: "my-user-cluster-datastore"
Geben Sie folgenden Befehl ein, um einen Nutzercluster zu erstellen:
gkectl create --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG]
Dabei gilt:
- [ADMIN_CLUSTER_KUBECONFIG] ist die kubeconfig-Datei Ihres Administrator-Clusters.
- [USER_CLUSTER_CONFIG] ist die Konfigurationsdatei für Ihren Nutzercluster.
Beschrä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. |
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.
Fehlerbehebung 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