Version 1.8. Diese Version wird unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Darin sind die neuesten Patches und Updates zu Sicherheitslücken, Kontakten und Problemen mit Anthos-Clustern auf VMware (GKE On-Prem) aufgeführt. Weitere Informationen finden Sie in den Versionshinweisen. Dies ist nicht die neueste Version.

VM der Steuerungsebene des Administratorclusters reparieren

In einer Anthos-Cluster auf VMware-Implementierung (GKE On-Prem) hat die Steuerungsebenen-VM für einen Administratorcluster zwei angehängte Laufwerke:

  • Das Bootlaufwerk hat das Betriebssystem für die VM.

  • Das Datenlaufwerk hat Anmeldedaten und die etcd-Datenbank, die den Status des Administratorclusters speichert. Das heißt, auf dem Datenlaufwerk werden alle Kubernetes-Objekte für den Administratorcluster gespeichert.

Auf dieser Seite wird gezeigt, wie Sie eine Wiederherstellung durchführen können, wenn die VM der Steuerungsebene verloren geht oder das Bootlaufwerk manipuliert wird. Beispiel:

  • Das Bootlaufwerk wird aufgrund von Spam-Journallogs schreibgeschützt.
  • Das Dateisystem des Docker-Overlays wird beschädigt.

Die Wiederherstellung des Datenlaufwerks wird auf dieser Seite nicht behandelt. Eine Anleitung zum Wiederherstellen des Datenlaufwerks finden Sie unter Administratorcluster wiederherstellen.

VM der Steuerungsebene reparieren

So reparieren Sie die VM der Steuerungsebene des Administratorclusters:

gkectl repair admin-master --config ADMIN_CLUSTER_CONFIG --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Ersetzen Sie:

  • ADMIN_CLUSTER_CONFIG durch den Pfad Ihrer Konfigurationsdatei für den Administratorcluster.

  • ADMIN_CLUSTER_KUBECONFIG durch den Pfad der kubeconfig-Datei Ihres Administratorclusters.

Hinweise

Die VM der Steuerungsebene des Administratorclusters wird in eine VM-Vorlage geklont, die über alle Informationen verfügt, die zum erneuten Erstellen der VM erforderlich sind. Der Befehl gkectl repair admin-master verwendet die VM-Vorlage zum Erstellen einer neuen VM. Dann werden ein neues Bootlaufwerk und das vorhandene Datenlaufwerk angehängt.

Wenn Ihre Clusterknoten ihre Adressen von einem DHCP-Server beziehen, hat die neue VM möglicherweise eine andere IP-Adresse als die ursprüngliche VM.