Preflight-Prüfungen

Preflight-Prüfungen sind eine präventive Maßnahme, mit der Probleme erkannt werden können, bevor Sie einen wichtigen Clustervorgang starten, z. B. das Erstellen oder Upgraden von Clustern. Wenn diese Prüfungen automatisch vor einem Vorgang ausgeführt werden, werden an Ihren Clustern nur dann Änderungen vorgenommen, wenn alle Preflight-Prüfungen erfolgreich sind. Sie können Preflight-Prüfungen auch nach Bedarf ausführen.

In diesem Dokument wird jede Prüfung beschrieben, unter welchen Bedingungen sie automatisch ausgeführt wird, wie und wann sie manuell ausgeführt und wie die Ergebnisse interpretiert werden sollten.

In Google Distributed Cloud können Sie Preflight-Prüfungen für verschiedene Situationen ausführen:

  • Google Distributed Cloud führt beim Erstellen oder Upgrade von Clustern und Knotenpoolressourcen mit bmctl Preflight-Prüfungen aus. Wenn die Prüfungen fehlschlagen, werden keine Änderungen vorgenommen. Sie können diese Prüfungen auch umgehen oder explizit ausführen.

  • Google Distributed Cloud führt auch interne Preflight-Prüfungen durch, wenn ein Administrator- oder Hybridcluster Kubernetes-Ressourcen in Nutzerclustern erstellt oder aktualisiert. Die Prüfungen werden ausgeführt, bevor die Änderungen auf die betroffenen Nutzercluster angewendet werden. Wenn die Prüfungen fehlschlagen, werden keine Änderungen vorgenommen.

Benutzerdefinierte PreflightCheck-Ressourcen

Wenn eine Preflight-Prüfung ausgeführt wird, erstellt Google Distributed Cloud eine benutzerdefinierte Ressource PreflightCheck. Benutzerdefinierte PreflightCheck-Ressourcen sind persistent und bieten ein Aufzeichnung der Aktivitäten und Ergebnisse der Preflight-Prüfung.

So rufen Sie benutzerdefinierte PreflightCheck-Ressourcen ab:

  1. Rufen Sie eine Liste der Preflight-Prüfungen ab, die für einen bestimmten Cluster ausgeführt wurden:

    kubectl get preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

    Ersetzen Sie Folgendes:

    • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
    • CLUSTER_NAMESPACE: den Namespace des Clusters.

    In der Antwort werden die Ressourcen nach Namespace aufgelistet. Sie können kubectl get preflightchecks für alle Namespaces ausführen, um eine umfassende Liste zu erhalten. Für jede Ressource zeigt die Antwort das Alter der Ressource und ob die Preflight-Prüfungen bestanden wurden oder nicht. Die folgende Beispielantwort zeigt PreflightCheck-Ressourcen für den cluster-test-admin001-Namespace.

    NAMESPACE              NAME                                PASS    AGE
cluster-test-admin001   test-admin001                      true    52d
cluster-test-admin001   test-admin001jkm4q                 true    52d
cluster-test-admin001   test-admin001k79t7                 true    6d20h
cluster-test-admin001   upgrade-cluster-20231106-222746    true    6d20h

  2. So rufen Sie die Details für eine bestimmte benutzerdefinierte PreflightCheck-Ressource ab:

    kubectl describe preflightchecks --kubeconfig ADMIN_KUBECONFIG --namespace CLUSTER_NAMESPACE

    Ersetzen Sie Folgendes:

    • ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei des Administratorclusters
    • CLUSTER_NAMESPACE: den Namespace des Clusters.

    Das folgende Beispiel für eine Befehlsantwort zeigt eine PreflightCheck-Ressource für eine erfolgreiche Preflight-Prüfung, die im Rahmen der Clustererstellung ausgeführt wurde:

    Name:         create-cluster-20230922-175006
Namespace:    cluster-test-user001
Labels:       <none>
Annotations:  <none>
API Version:  baremetal.cluster.gke.io/v1
Kind:         PreflightCheck
Metadata:
  Creation Timestamp:  2023-09-22T17:50:11Z
  Generation:          1
  Resource Version:    6502800
  UID:                 917daf64-963d-44b4-a1f9-c54972a39191
Spec:
  Check Image Version:  latest
  Config YAML:          ---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-test-user
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: test-user001
  namespace: cluster-test-user001
spec:
  type: user
  profile: default
  anthosBareMetalVersion: 1.16.0
  gkeConnect:
    projectID: clusters-project
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: 192.0.2.53
  ...
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-test-user001
spec:
  clusterName: test-user001
  nodes:
  - address: 192.0.2.54
  ...
Status:
  Checks:
    192.0.2.53:
      Job UID:  d0b5dc1f-9d39-4cc8-b3d2-0841212f7f8c
      Message:  
      Pass:     true
    192.0.2.53-gcp:
      Job UID:  b4d96ce5-0d4e-4e3c-97db-6317e0c15fc8
      Message:  
      Pass:     true
    192.0.2.54:
      Job UID:  b67cf195-3951-46ad-b91c-0d79025cfc0a
      Message:  
      Pass:     true
    192.0.2.54-gcp:
      Job UID:  aed509e2-4bf7-44c4-bfa0-8147ef8ea74e
      Message:  
      Pass:     true
    Gcp:
      Job UID:  ac479ac4-e1c4-4681-9f2b-5773069bf6ae
      Message:  
      Pass:     true
    Node - Network:
      Job UID:  8a57c4ee-ad17-4560-8809-b117c871ad5d
      Message:  
      Pass:     true
    Pod - Cidr:
      Message:  
      Pass:     true
  Cluster Spec:
    Anthos Bare Metal Version:  1.16.0
    Bypass Preflight Check:     false
    Cluster Network:
      Bundled Ingress:  true
      Pods:
        Cidr Blocks:
          10.0.0.0/16
      Services:
        Cidr Blocks:
          10.96.0.0/20
  ...
  Completion Time:                 2023-09-22T17:51:22Z
  Conditions:
    Last Transition Time:  2023-10-02T23:59:06Z
    Observed Generation:   1
    Reason:                Reconciling
    Status:                True
    Type:                  Reconciling
  Node Pool Specs:
    node-pool-1:
      Cluster Name:  test-user001
      Nodes:
        Address:         192.0.2.54
    ...
  Pass:                  true
  Start Time:            2023-09-22T17:50:32Z
Events:                  <none>

    In der vorherigen benutzerdefinierten PreflightCheck-Ressource enthält der Abschnitt Status die folgenden Informationen:

    • Der Abschnitt Checks listet die einzelnen Preflight-Prüfungen auf, die durchgeführt wurden und ob sie bestanden wurden oder nicht. In diesem Beispiel wurden die folgenden Prüfungen ausgeführt:
      • 192.0.2.53 und 192.0.2.54: Knotenprüfungen (Betriebssystemkonfiguration, Ressourcen und Softwareeinstellungen) für Maschinen mit den IP-Adressen 192.0.2.53 und 192.0.2.54.
      • 192.0.2.53-gpc und 192.0.2.54-gcp: Google Cloud Verbindungsprüfungen (Artifact Registry- und Google API-Zugriff) für Maschinen mit den IP-Adressen 192.0.2.53 und 192.0.2.54.
      • Gcp: Google Cloud Konnektivitätsprüfungen für den Cluster.
      • Node - Network: Netzwerkprüfungen (Verbindung, etcd-Vorgang, VIP-Zugriff und Portbindung) für den Cluster.
      • Pod - Cidr: Pod-IP-Adresse prüft auf überlappende Adressen für den Cluster.
    • Im Abschnitt Cluster Spec wird die Clusterkonfiguration angezeigt.
    • Im Feld Pass wird true angezeigt. Das bedeutet, dass die Preflight-Prüfungen insgesamt bestanden wurden.

Logs der Preflight-Prüfung

Wenn Preflight-Prüfungen aufgrund eines bmctl-Befehls wie bmctl check preflight ausgeführt werden, erstellt Google Distributed Cloud Logdateien. Hier sehen Sie, was und wo generiert wird:

  • Preflight-Prüfungslogs werden in einem Verzeichnis mit dem folgenden Namensmuster preflight-TIMESTAMP generiert.

  • Dieses Preflight-Verzeichnis wird im Verzeichnis log für den Cluster im bmctl-Arbeitsbereich erstellt. Der Standardpfad für das Verzeichnis log ist bmctl-workspace/CLUSTER_NAME/log.

  • Die Preflight-Logs bestehen aus den folgenden Dateien:

    • Logdateien für die Prüfungen der Knotenmaschinen, eine für jeden Clusterknoten. Diese Logdateien werden nach der IP-Adresse des Knotens benannt. Ein Beispiel: Der Dateiname könnte 192.0.2.53 sein.

    • Logdateien für Google Cloud -Zugriffsprüfungen, eine für jeden Clusterknoten. Diese Logdateien werden mit der IP-Adresse des Knotens benannt. Beispiel: Ein Dateiname könnte 192.0.2.53-gcp sein.

    • Logdatei für Cluster Google Cloud -Zugriffsprüfungen mit dem Namen gcp.

    • Logdatei für die Überprüfung der Knotenvernetzung mit dem Namen node-network.

Wenn eine Preflight-Prüfung fehlschlägt, können Sie anhand dieser Logdateien das Problem identifizieren und beheben.

Preflight-Prüfungen für die Clustererstellung

Wenn Sie Cluster erstellen, führt Google Distributed Cloud vor Änderungen automatisch Preflight-Prüfungen aus.

Was wird geprüft?

Bei der Preflight-Prüfung für die Installation wird Folgendes geprüft:

  • Prüfungen von Knotenrechnern:

    • Auf den Clustermaschinen wird ein unterstütztes Betriebssystem verwendet.

    • Die Betriebssystemversion wird unterstützt.

    • Das Betriebssystem verwendet eine unterstützte Kernelversion.

    • Für Ubuntu ist Uncomplicated Firewall (UFW) deaktiviert.

    • Unter Ubuntu kann der Paketmanager apt verwendet werden und erforderliche Pakete sind verfügbar.

    • Unter Red Hat Enterprise Linux kann der Paketmanager dnf verwendet werden und erforderliche Pakete sind verfügbar sind.

    • Unter Red Hat Enterprise Linux ist Podman nicht installiert.

    • Die Knotencomputer erfüllen die Mindestanforderungen an die CPU.

    • Die Knotenmaschinen erfüllen die Mindestanforderungen an den Arbeitsspeicher.

    • Die Knotenmaschinen erfüllen die Mindestanforderungen an den Festplattenspeicher.

    • Die Zeitsynchronisierung wird auf Knotenmaschinen konfiguriert.

    • kubelet ist aktiv und wird auf Knotencomputern ausgeführt.

    • containerd ist aktiv und wird auf Knotencomputern ausgeführt.

    • Die Standardroute zum Weiterleiten von Paketen an das Standardgateway ist auf den Knoten vorhanden.

    • Das Domain Name System (DNS) funktioniert ordnungsgemäß. Wenn der Cluster für die Ausführung hinter einem Proxy konfiguriert ist, wird diese Prüfung übersprungen.

    • Pod-CIDRs überschneiden sich nicht mit den IP-Adressen der Knotenmaschinen.

    • Wenn der Cluster für die Verwendung eines Registrierungsspiegels konfiguriert ist, ist der Spiegel erreichbar.

  • Google Cloud prüft für jeden Knoten und für den Cluster:

    • Artifact Registry, gcr.io, Erreichbarkeit wird geprüft. Wenn der Cluster für die Verwendung eines Registrierungsspiegels konfiguriert ist, wird diese Prüfung übersprungen.

    • Google APIs sind erreichbar.

  • Knotennetzwerkprüfungen (variieren je nach Load-Balancing-Konfiguration):

    • Die VIP für den Kubernetes API-Server ist erreichbar.

    • Auf Load-Balancer-VIPs kann zugegriffen werden.

    • Knoten können über die erforderlichen Ports kommunizieren.

    • Die etcd-Ereignisinstanz wird bereitgestellt und die Portanforderungen werden erfüllt.

Wenn alle Prüfungen bestanden wurden, erstellt Google Distributed Cloud den Cluster. Weitere Informationen zu den Anforderungen zum Erstellen von Clustern finden Sie unter Installationsvoraussetzungen – Übersicht.

On-Demand-Preflight-Prüfungen für die Clustererstellung ausführen

Sie können Preflight-Prüfungen auch unabhängig durchführen, bevor Sie einen Cluster erstellen. Dies kann von Vorteil sein, da größere Cluster-Operationen, wie die Erstellung von Clustern, zeitaufwändig sind. Die Erkennung und Lösung von Problemen vor dem Start eines größeren Clustervorgangs kann Ihnen bei der Planung helfen.

Selbstverwaltete Cluster

  • Der folgende Befehl validiert die angegebene Cluster-Konfigurationsdatei, versucht jedoch nicht, den Cluster selbst zu erstellen:

    bmctl check config --cluster CLUSTER_NAME

    Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, der mit der zu prüfenden Konfigurationsdatei verknüpft ist.

  • Dieser Befehl prüft, ob die Maschinen und das Netzwerk für die Clustererstellung bereit sind:

    bmctl check preflight --cluster CLUSTER_NAME

    Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie prüfen.

Nutzercluster

  • Der folgende Befehl validiert die angegebene Cluster-Konfigurationsdatei, versucht jedoch nicht, den Cluster selbst zu erstellen:

    bmctl check config --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name des Nutzerclusters, den Sie prüfen.
    • ADMIN_KUBECONFIG: der Pfad der verknüpften kubeconfig-Datei des Administratorclusters.

  • Der folgende Befehl prüft, ob die Maschinen und das Netzwerk für die Clustererstellung bereit sind:

    bmctl check preflight --cluster CLUSTER_NAME --admin-kubeconfig ADMIN_KUBECONFIG

bmctl unterstützt die Verwendung von --kubeconfig als Alias für das Flag --admin-kubeconfig.

Preflight-Prüfungen für Clusterupgrades

Wenn Sie für einen Cluster ein Upgrade durchführen, führt Google Distributed Cloud vor Änderungen automatisch Preflight-Prüfungen aus.

Was wird geprüft?

Bei Preflight-Prüfungen für Clusterupgrades wird Folgendes geprüft:

  • Prüfungen von Knotenrechnern:

    • Auf den Clustermaschinen wird ein unterstütztes Betriebssystem verwendet.

    • Die Betriebssystemversion wird unterstützt.

    • Das Betriebssystem verwendet eine unterstützte Kernelversion.

    • Für Ubuntu ist Uncomplicated Firewall (UFW) deaktiviert.

    • Die Knotencomputer erfüllen die Mindestanforderungen an die CPU.

    • Auf den Knotenmaschinen sind mehr als 20% der CPU-Ressourcen verfügbar.

    • Die Knotenmaschinen erfüllen die Mindestanforderungen an den Arbeitsspeicher.

    • Die Knotenmaschinen erfüllen die Mindestanforderungen an den Festplattenspeicher.

    • Die Zeitsynchronisierung wird auf Knotenmaschinen konfiguriert.

    • Die Standardroute zum Weiterleiten von Paketen an das Standardgateway ist auf den Knoten vorhanden.

    • Das Domain Name System (DNS) funktioniert ordnungsgemäß. Wenn der Cluster für die Ausführung hinter einem Proxy konfiguriert ist, wird diese Prüfung übersprungen.

    • Wenn der Cluster für die Verwendung eines Registrierungsspiegels konfiguriert ist, ist der Spiegel erreichbar.

    • Keine Knoten der Steuerungsebene oder Load-Balancer-Knoten befinden sich im Wartungsmodus.

  • Google Cloud prüft für jeden Knoten und für den Cluster:

    • Artifact Registry, gcr.io, Erreichbarkeit wird geprüft. Wenn der Cluster für die Verwendung eines Registrierungsspiegels konfiguriert ist, wird diese Prüfung übersprungen.

    • Google APIs sind erreichbar.

  • Maschinenprüfungen:

    • kubelet ist aktiv und wird auf Knotencomputern ausgeführt.

    • containerd ist aktiv und wird auf Knotencomputern ausgeführt.

    • Der Systemstatus des CNI-Endpunkts (Container Network Interface) ist „Fehlerfrei“.

    • Pod-CIDRs überschneiden sich nicht mit den IP-Adressen der Knotenmaschinen.

    • Die kubeadm-Zertifikate sind nicht abgelaufen.

  • Knotennetzwerkprüfungen (variieren je nach Load-Balancing-Konfiguration):

    • Die VIP für den Kubernetes API-Server ist erreichbar.

    • Auf Load-Balancer-VIPs kann zugegriffen werden.

    • Knoten können über die erforderlichen Ports kommunizieren.

    • Die etcd-Ereignisinstanz wird bereitgestellt und die Portanforderungen werden erfüllt.

Wenn alle Prüfungen bestanden wurden, führt Google Distributed Cloud ein Upgrade des Clusters durch. Weitere Informationen zum Upgrade von Clustern finden Sie unter Best Practices für Cluster-Upgrades in Google Distributed Cloud und Lebenszyklus und Phasen von Cluster-Upgrades.

On-Demand-Preflight-Prüfungen für Clusterupgrades ausführen

Mit dem Befehl bmctl check preflight können Sie eine Preflight-Prüfung ausführen, bevor ein Clusterupgrade ausführen. Sie können prüfen, ob die Cluster für ein Upgrade bereit sind, indem Sie vor Beginn des Upgrades den folgenden Befehl für die Preflight-Prüfung ausführen:

  1. Aktualisieren Sie die Clusterversion (anthosBareMetalVersion) in der Clusterkonfigurationsdatei.

  2. Mit dem folgenden Befehl können Sie prüfen, ob die Cluster für ein Upgrade bereit sind, und eine Preflight-Prüfung ausführen:

    bmctl check preflight --cluster CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

    Ersetzen Sie Folgendes:

    • CLUSTER_NAME: der Name des Clusters, der aktualisiert werden soll.
    • ADMIN_KUBECONFIG: der Pfad zur kubeconfig-Datei des Administratorclusters.

    Wenn Sie die Preflight-Prüfung mit diesem Befehl erstellen, um ein Cluster-Upgrade zu testen, wird im Administratorcluster eine benutzerdefinierte Ressource PreflightCheck erstellt.

Interne Preflight-Prüfungen für vorhandene Cluster

Google Distributed Cloud führt automatisch interne Preflight-Prüfungen durch, wenn Sie Kubernetes-Ressourcen auf einen vorhandenen Cluster anwenden. Wenn eine Prüfung fehlschlägt, nimmt Google Distributed Cloud keine Änderungen an den zugehörigen Knoten vor, es sei denn, Sie umgehen die Prüfungen explizit.

Preflight-Prüfungen beim Anwenden von Kubernetes-Ressourcen umgehen

Wenn Sie die internen Preflight-Prüfungen beim Anwenden von Ressourcen auf vorhandene Cluster ignorieren möchten, legen Sie in der Konfigurationsdatei des Clusters das Feld BypassPreflightCheck auf true fest.

Hier ist ein Teil einer Clusterkonfigurationsdatei, in der das Feld bypassPreflightCheck auf true festgelegt wurde:

apiVersion: v1
kind: Namespace
metadata:
  name: cluster-user1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: user1
  namespace: cluster-user1
spec:
  type: user
  bypassPreflightCheck: true
  # Anthos cluster version.
  anthosBareMetalVersion: 1.33.100-gke.89
...

Neueste Preflight-Prüfungen ausführen

Preflight-Prüfungen (und Systemdiagnosen) werden aktualisiert, sobald bekannte Probleme erkannt werden. Wenn Sie bmctl anweisen möchten, die Prüfungen anhand des neuesten Patch-Images Ihrer installierten Nebenversion auszuführen, verwenden Sie das Optionsflag --check-image-version latest:

bmctl check preflight --cluster CLUSTER_NAME --check-image-version latest

Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie prüfen.

So können Sie kürzlich erkannte bekannte Probleme erkennen, ohne zuerst Ihren Cluster zu erstellen oder zu aktualisieren.

Sie können auch die neuesten Systemdiagnosen eines aktiven Clusters ausführen, um festzustellen, ob er ordnungsgemäß funktioniert. Weitere Informationen finden Sie unter Aktuelle Systemdiagnosen ausführen.

Ergebnisse der automatisierten Preflight-Prüfungen ignorieren

Wenn Sie Preflight-Prüfungen on demand ausführen, bevor Sie Cluster erstellen oder upgraden, können Sie die automatisierten Preflight-Prüfungen umgehen. Wenn Sie automatisierte Preflight-Prüfungen umgehen möchten, verwenden Sie das optionale Flag --force, wenn Sie bmctl create cluster oder bmctl upgrade cluster ausführen.

Nächste Schritte