Admincluster erstellen

Auf dieser Seite wird gezeigt, wie Sie einen Administratorcluster für Anthos-Cluster auf VMware (GKE On-Prem) erstellen.

Diese Anleitung ist vollständig. Eine kürzere Einführung zum Erstellen eines Administratorclusters finden Sie unter Administratorcluster erstellen (Kurzanleitung).

Hinweis

Erstellen Sie eine Administrator-Workstation.

SSH-Verbindung zu Ihrer Administrator-Workstation abrufen

SSH-Verbindung zu Ihrer Administrator-Workstation abrufen.

Denken Sie daran, dass gkeadm Ihr Dienstkonto für den Komponentenzugriff auf der Administrator-Workstation aktiviert hat.

Führen Sie alle verbleibenden Schritte in diesem Thema auf Ihrer Administrator-Workstation im Basisverzeichnis aus.

Konfigurationsdatei für Anmeldedaten

Wenn Sie gkeadm zum Erstellen Ihrer Administrator-Workstation verwendet haben, haben Sie die Anmeldedaten-Konfigurationsdatei namens credential.yaml ausgefüllt. Diese Datei enthält den Nutzernamen und das Passwort für Ihren vCenter-Server.

Konfigurationsdatei für den Admincluster

Als gkeadm die Administrator-Workstation erstellt hat, wurde eine zweite Konfigurationsdatei mit dem Namen admin-cluster.yaml erzeugt. Diese Konfigurationsdatei dient zum Erstellen Ihres Administratorclusters.

Konfigurationsdatei ausfüllen

bundlePath

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

vCenter

Die meisten Felder hierin sind bereits mit Werten gefüllt, die Sie beim Erstellen der Administrator-Workstation eingegeben haben. Die Ausnahme ist das Feld dataDisk, das Sie jetzt ausfüllen müssen.

network

Legen Sie fest, wie die Clusterknoten ihre IP-Adressen abrufen sollen. Folgende Optionen sind verfügbar:

  • Von einem DHCP-Server. Setzen Sie network.ipMode.type auf "dhcp".

  • Aus einer Liste der von Ihnen angegebenen statischen IP-Adressen. Legen Sie network.ipMode.type auf "static" fest und erstellen Sie eine IP-Blockdatei, die die statischen IP-Adressen bereitstellt.

Geben Sie Werte für die verbleibenden Felder im Abschnitt network an.

Unabhängig davon, ob Sie einen DHCP-Server verwenden oder eine Liste statischer IP-Adressen angeben, benötigen Sie genügend IP-Adressen, um Folgendes abzudecken:

  • Drei Knoten im Administratorcluster, um die Steuerungsebene und Add-ons des Administratorclusters auszuführen.

  • Einen zusätzlichen Knoten im Administratorcluster, der während Upgrades vorübergehend verwendet wird.

  • Für jeden Nutzercluster, den Sie erstellen möchten, einen oder drei Knoten im Administratorcluster, um die Komponenten der Steuerungsebene für den Nutzercluster auszuführen. Wenn die Steuerungsebene für einen Nutzercluster hochverfügbar sein soll, benötigen Sie im Administratorcluster drei Knoten für die Steuerungsebene des Nutzerclusters. Andernfalls benötigen Sie nur einen Knoten im Administratorcluster für die Steuerungsebene des Nutzerclusters.

Angenommen, Sie möchten zwei Nutzercluster erstellen: einen mit einer HA-Steuerungsebene und einen mit einer Nicht-HA-Steuerungsebene. Dann benötigen Sie acht IP-Adressen für die folgenden Knoten im Administratorcluster:

  • Drei Knoten für die Steuerungsebene und Add-ons des Administratorclusters
  • Einen temporären Knoten
  • Drei Knoten für die HA-Nutzercluster-Steuerungsebene
  • Einen Knoten für die Nicht-HA-Nutzercluster-Steuerungsebene

Wie bereits erwähnt, müssen Sie eine IP-Blockdatei angeben, wenn Sie statische IP-Adressen verwenden möchten. Hier ein Beispiel für eine IP-Blockdatei mit acht Hosts:

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
    - ip: 172.16.20.17
      hostname: admin-host8

loadBalancer

Legen Sie eine VIP für den Kubernetes API-Server Ihres Administratorclusters fest. Legen Sie eine andere VIP für den Add-on-Server fest. Geben Sie Ihre VIPs als Werte für loadBalancer.vips.controlPlaneVIP und loadBalancer.vips.addonsVIP an.

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

  • Gebündeltes Seesaw-Load-Balancing. Legen Sie loadBalancer.kind auf "Seesaw" fest und füllen Sie den Abschnitt loadBalancer.seesaw aus.

  • Integriertes Load-Balancing mit F5 BIG-IP. Legen Sie loadBalancer.kind auf "F5BigIP" fest und füllen Sie den Abschnitt f5BigIP aus.

  • Manuelles Load-Balancing. Legen Sie loadBalancer.kind auf "ManualLB" fest und füllen Sie den Abschnitt manualLB aus.

antiAffinityGroups

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

proxy

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

privateRegistry

Entscheiden Sie, wo Sie Container-Images für die Anthos-Cluster auf VMware-Komponenten beibehalten möchten. Folgende Optionen sind verfügbar:

  • gcr.io. Füllen Sie den Abschnitt privateRegistry nicht aus.

  • Ihre eigene private Docker-Registry. Füllen Sie den Abschnitt privateRegistry aus.

gcrKeyPath

Legen Sie für gcrKeyPath den Pfad der JSON-Schlüsseldatei für Ihr Dienstkonto für den Komponentenzugriff fest.

stackdriver

Füllen Sie den Abschnitt stackdriver aus.

cloudAuditLogging

Wenn Kubernetes-Audit-Logs in Cloud-Audit-Logging integriert werden sollen, füllen Sie den Abschnitt cloudAuditLogging aus.

autoRepair

Wenn Sie die automatische Knotenreparatur aktivieren möchten, setzen Sie autoRepair.enabled auf true. Setzen Sie es andernfalls auf false.

adminMaster

Wenn Sie die CPUs und den Arbeitsspeicher für den Knoten der Administrator-Steuerungsebene manuell konfigurieren möchten, füllen Sie den Abschnitt adminMaster aus.

Konfigurationsdatei validieren

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

gkectl check-config --config [CONFIG_PATH]

Dabei ist [CONFIG_PATH] der Pfad Ihrer Administratorcluster-Konfigurationsdatei.

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

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

gkectl prepare ausführen

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

gkectl prepare --config [CONFIG_PATH]

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

  • Importiert die Betriebssystem-Images in vSphere und markiert sie als VM-Vorlagen.

  • Wenn Sie eine private Docker-Registry verwenden, überträgt dieser Befehl die Docker-Container-Images an Ihre Registry.

  • Optional validiert dieser Befehl die Build-Attestierungen des Container-Images. Dadurch wird sichergestellt, dass die Images von Google erstellt und signiert wurden und bereit für die Bereitstellung sind.

Seesaw-Load-Balancer für Ihren Administratorcluster erstellen

Wenn Sie den gebündelten Seesaw-Load-Balancer verwenden möchten, führen Sie den Schritt in diesem Abschnitt aus. Andernfalls können Sie diesen Abschnitt überspringen.

Erstellen und konfigurieren Sie die VMs für den Seesaw-Load-Balancer:

gkectl create loadbalancer --config [CONFIG_PATH]

Administratorcluster erstellen

Erstellen Sie den Administratorcluster:

gkectl create admin --config [CONFIG_PATH]

Dabei ist [CONFIG_PATH] der Pfad Ihrer Administratorcluster-Konfigurationsdatei.

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

Ausführung des Administratorclusters prüfen

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

kubectl get nodes --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

wobei [ADMIN_CLUSTER_KUBECONFIG] der Pfad Ihrer kubeconfig-Datei ist.

Die Ausgabe zeigt die Knoten des Administratorclusters.

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 Datei logs/gkectl-$(date).log im lokalen Verzeichnis verknüpft, in dem Sie gkectl ausführen.
    • Für gkeadm ist die Standard-Logdatei logs/gkeadm-$(date).log im lokalen Verzeichnis, in dem Sie gkeadm ausführen.
  • Alle Logeinträge werden in der Logdatei gespeichert, auch wenn sie nicht im Terminal ausgegeben werden (wenn --alsologtostderr auf false gesetzt ist).
  • Die Ausführlichkeitsstufe -v5 (Standard) deckt alle Logeinträge ab, die vom Support-Team benötigt werden.
  • Die Logdatei enthält auch den ausgeführten Befehl und die Fehlermeldung.

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

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

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

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

Cluster-API-Logs im Administratorcluster suchen

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

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

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. Öffnen Sie die Logs des Pods, wobei [POD_NAME] der Name des Pods ist. Verwenden Sie optional für die Fehlersuche grep oder ein ähnliches Tool:

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

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

Nach der Installation generiert Anthos-Cluster auf VMware eine kubeconfig-Datei im Basisverzeichnis der Administrator-Workstation 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 Anthos-Cluster auf VMware einen temporären Bootstrap-Cluster. Nach einer erfolgreichen Installation löscht Anthos-Cluster auf VMware den Bootstrap-Cluster. Es verbleiben dann Ihr Administratorcluster und Ihr Nutzercluster. 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 finden Sie unter Fehlerbehebung.

Weitere Informationen

Nutzercluster erstellen