Größe eines Nutzerclusters anpassen

Auf dieser Seite wird beschrieben, wie Sie die Größe eines GKE On-Prem-Nutzerclusters anpassen. Die Größenanpassung eines Nutzerclusters bedeutet das Hinzufügen oder Entfernen von Knoten aus diesem Cluster. Wenn Sie Knoten aus einem Cluster entfernen, sollten Sie die IP-Adressen dieses Clusters freigeben, damit sie von anderen Knoten verwendet werden können. Für das Hinzufügen von Knoten müssen IP-Adressen für diese Knoten verfügbar sein.

Sie passen die Größe eines Nutzerclusters an, indem Sie die replicas-Felder im Abschnitt nodePools der Konfigurationsdatei ändern und diese Änderungen mit dem Befehl gkectl update cluster auf Ihren vorhandenen Cluster anwenden.

Informationen zu Maximal- und Minimallimits für Nutzercluster finden Sie unter Kontingente und Limits.

Weitere Informationen zum Verwalten von Knotenpools mit gkectl update cluster finden Sie unter Knotenpools erstellen und verwalten.

Prüfen, ob genügend IP-Adressen verfügbar sind

Wenn Sie einem Cluster weitere Knoten hinzufügen, achten Sie darauf, dass der Cluster genügend IP-Adressen hat. Das Prüfen der Verfügbarkeit von genügend IP-Adressen hängt davon ab, ob der Cluster einen DHCP-Server oder statische IP-Adressen verwendet.

DHCP

Wenn der Cluster DHCP verwendet, prüfen Sie, ob der DHCP-Server in dem Netzwerk, in dem die Knoten erstellt werden, über genügend IP-Adressen verfügt. Es sollten mehr IP-Adressen vorhanden sein, als Knoten im Nutzercluster ausgeführt werden.

Statische IP-Adressen

Wenn der Cluster statische IP-Adressen verwendet, überprüft gkectl update cluster zuerst, ob Sie genügend IP-Adressen im Cluster zugewiesen haben. Wenn nicht, finden Sie in der Fehlermeldung die Anzahl der zusätzlichen IP-Adressen, die für den Aktualisierungsvorgang benötigt werden.

Wenn Sie dem Nutzercluster weitere IP-Adressen hinzufügen müssen, führen Sie die folgenden Schritte aus:

  1. Öffnen Sie die hostconfig-Datei des Nutzerclusters zur Bearbeitung.

  2. So zeigen Sie die für einen Nutzercluster reservierten Adressen an: 

    kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] 
    
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

wobei

  • [ADMIN_CLUSTER_KUBECONFIG] weist kubectl an, die kubeconfig-Datei des Administratorclusters zu verwenden, mit der Nutzerclusterkonfigurationen aufgerufen und/oder geändert werden.
  • -n [USER_CLUSTER_NAME] weist kubectl an, in einem Namespace zu suchen, der nach dem Nutzercluster benannt ist.
  • [USER_CLUSTER_NAME] -o yaml teilt kubectl mit, für welchen Nutzercluster Sie den Befehl ausführen. -o yaml zeigt die Konfiguration des Nutzerclusters an.

  1. Wenn eine der für einen Nutzercluster reservierten Adressen in der hostconfig-Datei enthalten ist, fügen Sie sie zum entsprechenden Block basierend auf netmask und gateway hinzu.

  2. Fügen Sie dem entsprechenden Block nach Bedarf weitere statische IP-Adressen hinzu und führen Sie dann gkectl update cluster aus.

Hier sehen Sie eine hostconfig-Datei mit vier hervorgehobenen statischen IP-Blöcken:

hostconfig:
  dns: 172.16.255.1
  tod: 216.239.35.0
blocks:
- netmask: 255.255.248.0
  gateway: 21.0.135.254
  ips:
    - ip: 21.0.133.41
      hostname: user-node-1
    - ip: 21.0.133.50
      hostname: user-node-2
    - ip: 21.0.133.56
      hostname: user-node-3
    - ip: 21.0.133.47
      hostname: user-node-4

Größe eines Nutzerclusters anpassen

Ab 1.5.0 ändern Sie die Größe eines Clusters, indem Sie die Felder replicas im Abschnitt nodePools der Konfigurationsdatei ändern und diese Änderungen auf Ihren vorhandenen Cluster mit dem Befehl gkectl update cluster anwenden.

Größenanpassung prüfen

Führen Sie folgenden Befehl aus, um zu prüfen, ob die Größenanpassung erfolgreich war:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] describe machinedeployments [NODE_POOL_NAME] | grep Replicas

Dabei ist [USER_CLUSTER_KUBECONFIG] die kubeconfig-Datei des Nutzerclusters. Die Anzahl der ausgewählten Knoten sollte in der Ausgabe dieser Befehle angegeben werden.

Fehlerbehebung

Weitere Informationen finden Sie unter Fehlerbehebung.

Anpassen der Größe eines Nutzerclusters schlägt fehl

Symptome

Ein Vorgang zum Anpassen der Größe eines Nutzerclusters schlägt fehl.

Mögliche Ursachen

Mehrere Faktoren können dazu führen, dass die Größenanpassung fehlschlägt.

Lösung

Wenn die Größenanpassung fehlschlägt, führen Sie die folgenden Schritte aus:

  1. Prüfen Sie den MachineDeployment-Status des Clusters, um festzustellen, ob Ereignisse oder Fehlermeldungen vorliegen:

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

  2. Prüfen Sie, ob auf den neu erstellten Maschinen Fehler vorliegen:

    kubectl describe machine [MACHINE_NAME]

Fehler: "no addresses can be allocated"

Symptome

Nach der Anpassung der Größe eines Nutzerclusters zeigt kubectl describe machine [MACHINE_NAME] den folgenden Fehler an:

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
Mögliche Ursachen

Für den Nutzercluster sind nicht genügend IP-Adressen verfügbar.

Lösung

Weisen Sie weitere IP-Adressen für den Cluster zu. Löschen Sie dann die betroffene Maschine:

kubectl delete machine [MACHINE_NAME]

Wenn der Cluster richtig konfiguriert ist, wird eine Ersatzmaschine mit einer IP-Adresse erstellt.

Ausreichende Anzahl von zugewiesenen IP-Adressen, aber Maschine kann sich nicht beim Cluster registrieren

Symptome

Dem Netzwerk wurden genügend Adressen zugewiesen, aber die Maschine kann sich trotzdem nicht beim Nutzercluster registrieren.

Mögliche Ursachen:

Möglicherweise liegt ein IP-Adresskonflikt vor. Die IP-Adresse wird eventuell bereits von einer anderen Maschine oder Ihrem Load-Balancer verwendet.

Lösung

Prüfen Sie, ob die IP-Adresse der betroffenen Maschine nicht schon verwendet wird. Wenn eine Konflikt vorliegt, müssen Sie diesen in Ihrer Umgebung lösen.

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 mit der Datei logs/gkectl-$(date).log in dem 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

Aktualisierungsbefehl schlägt fehl

Wenn Sie gkectl update zum Aktualisieren eines Clusters ausführen, wird möglicherweise die folgende Fehlermeldung angezeigt: 
Failed to update the cluster: failed to begin updating user cluster "CLUSTER_NAME": timed out waiting for the condition
Führen Sie den folgenden Befehl aus, um diese Fehlermeldung genauer zu untersuchen: 
kubectl get --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] onpremusercluster
Wenn die folgende Ausgabe angezeigt wird und das Update wirksam wird, kann die Fehlermeldung ignoriert werden: 
cluster [CLUSTER_NAME] is READY=true