GKE On-Prem-Cheatsheet

Dieses Thema bietet eine Übersicht über Befehle, die bei der Verwendung von GKE On-Prem aufgerufen werden. Es dient zur Vereinfachung und Ergänzung der GKE On-Premise-Dokumentation.

Flags in eckigen Klammern sind optional. Placeholder variables sind änderbar.

kubectl-Befehle

Siehe auch das kubectl-Cheatsheet.

kubeconfig-Standarddatei festlegen

export KUBECONFIG=[KUBECONFIG_PATH]

Cluster aus der kubeconfig-Standarddatei auflisten

kubectl get clusters

Übergeben Sie --kubeconfig [KUBECONFIG_PATH], um Cluster in einer nicht standardmäßigen kubeconfig-Datei aufzurufen.

Knoten im Cluster aus der kubeconfig-Standarddatei auflisten

kubectl get nodes

Übergeben Sie --kubeconfig [KUBECONFIG_PATH], um Cluster in einer nicht standardmäßigen kubeconfig-Datei aufzurufen.

Alle Container in allen Namespaces auflisten

kubectl get pods --all-namespaces -o jsonpath="{..image}" |\
tr -s '[[:space:]]' '\n' |\
sort |\
uniq -c

gkectl-Befehle

Siehe auch gkectl-Referenz.

Clusterprobleme mit gkectl diagnostizieren

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

GKE On-Prem-Konfigurationsdatei generieren

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

Konfigurationsdatei validieren

gkectl check-config --config [PATH]

GKE On-Prem-Images an Docker-Registry übertragen und Knotenbetriebssystem-Image initialisieren

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

Cluster erstellen

gkectl create cluster --config [CONFIG_FILE]

Google Cloud-Dienstkonten

Dienstkonto erstellen

gcloud iam service-accounts create [SERVICE_ACCOUNT_NAME] --project [PROJECT_ID]

Dienstkonto eine IAM-Rolle zuweisen

gcloud projects add-iam-policy-binding \
    [PROJECT_ID] \
    --member="serviceAccount:[SERVICE_ACCOUNT_NAME]@[PROJECT_ID].iam.gserviceaccount.com" \
    --role="[ROLE_NAME]"

Privaten Schlüssel für ein Dienstkonto erstellen

gcloud iam service-accounts keys create [KEY_FILE_NAME] \
--iam-account [SERVICE_ACCOUNT_NAME]@[PROJECT-ID].iam.gserviceaccount.com \
--project [PROJECT_ID]

Dienstkonto aktivieren und gcloud-, gsutil-Befehle als Konto ausführen

gcloud auth activate-service-account --key-file=[SERVICE_ACCOUNT_KEY_FILE]

Administrator-Workstation

SSH-Verbindung zur Administratorworkstation herstellen

Aus dem Verzeichnis, das Ihre Terraform-Konfigurationsdateien enthält:

ssh -i ~/.ssh/vsphere_workstation ubuntu@$(terraform output ip_address)

oder, wenn Sie nur die Adresse verwenden möchten:

ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]

Dateien auf eine Administratorworkstation kopieren

scp -i ~./ssh/vsphere_workstation [SOURCE_PATH] ubuntu@$(terraform output ip_address)

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

Cluster

IP-Adressen der Knoten eines Administratorclusters abrufen

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes --output wide

IP-Adressen der Knoten eines Nutzerclusters abrufen

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes --output wide

SSH-Verbindung zu Clusterknoten herstellen

Siehe SSH-Verbindung zu einem Clusterknoten herstellen.

Nächste Schritte