Preflight-Prüfungen

Preflight-Prüfungen sind eine vorbeugende Maßnahme, um Probleme zu identifizieren, bevor Sie einen großen Clustervorgang starten, z. B. das Erstellen oder Aktualisieren von Clustern. Wenn diese Prüfungen automatisch vor einem Vorgang ausgeführt werden, werden keine Änderungen an Ihren Clustern vorgenommen, es sei denn, die Preflight-Prüfungen sind erfolgreich. Sie können auch Preflight-Prüfungen 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 PreflightCheck benutzerdefinierte 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. 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 IP-Adressen 192.0.2.53 und 192.0.2.54.
      • 192.0.2.53-gpc und 192.0.2.54-gcp: Google Cloud-Konnektivitätsprüfungen (Container Registry und Google API-Zugriff) für Computer 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 (Konnektivität, etcd-Vorgang, VIP-Zugriff und Portbindung) für den Cluster.
      • Pod - Cidr: Pod-IP-Adresse prüft auf überlappende Adressen für den Cluster.
    • Der Bereich Cluster Spec zeigt die Clusterkonfiguration.
    • Im Feld Pass wird true angezeigt. Das bedeutet, dass die Preflight-Prüfungen insgesamt bestanden wurden.

Preflight-Prüfungslogs

Wenn Preflight-Prüfungen als Ergebnis 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 Verzeichnispfad log ist standardmäßig bmctl-workspace/CLUSTER_NAME/log.

  • Die Preflight-Logs bestehen aus den folgenden Dateien:

    • Protokolldateien für Knotenmaschinenprüfungen, eine für jeden Clusterknoten. Diese Logdateien werden anhand 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 Protokolldateien werden nach der IP-Adresse des Knotens benannt. Beispiel: Ein Dateiname könnte 192.0.2.53-gcp sein.

    • Logdatei für die Google Cloud-Zugriffsprüfungen des Clusters mit dem Namen gcp.

    • Protokolldatei für Knotennetzwerkprüfungen namens node-network.

Wenn eine Preflight-Prüfung fehlschlägt, können diese Logdateien Ihnen bei der Identifizierung und Fehlerbehebung helfen.

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 überprüft?

Preflight-Prüfungen für die Installation prüfen Folgendes:

  • Knotenmaschinenprüfungen:

    • Clustermaschinen verwenden ein unterstütztes Betriebssystem.

    • Betriebssystemversion wird unterstützt.

    • Das Betriebssystem verwendet eine unterstützte Kernel-Version.

    • 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.

    • Für Red Hat Enterprise Linux ist Podman nicht installiert.

    • Knotenmaschinen erfüllen die Mindest-CPU-Anforderungen.

    • Knotenmaschinen erfüllen die Mindestspeicheranforderungen.

    • Knotenmaschinen erfüllen die Mindestanforderungen an den Laufwerkspeicher.

    • Die Zeitsynchronisierung wird auf Knotenrechnern konfiguriert.

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

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

    • Die Standardroute für das Routing von Paketen an das Standardgateway ist in 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 IP-Adressen von Knotenmaschinen.

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

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

    • Container Registry, gcr.io, Erreichbarkeit ist 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):

    • VIP für den Kubernetes API-Server ist zugänglich.

    • Load-Balancer-VIPs sind zugänglich.

    • Knoten können über erforderliche Ports kommunizieren.

    • Die Ereignisinstanz etcd wird bereitgestellt und die Portanforderungen sind 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.

  • Mit dem folgenden Befehl wird geprü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 überprüft?

Preflight-Prüfungen für Clusterupgrades prüfen Folgendes:

  • Knotenmaschinenprüfungen:

    • Clustermaschinen verwenden ein unterstütztes Betriebssystem.

    • Betriebssystemversion wird unterstützt.

    • Das Betriebssystem verwendet eine unterstützte Kernel-Version.

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

    • Knotenmaschinen erfüllen die Mindest-CPU-Anforderungen.

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

    • Knotenmaschinen erfüllen die Mindestspeicheranforderungen.

    • Knotenmaschinen erfüllen die Mindestanforderungen an den Laufwerkspeicher.

    • Die Zeitsynchronisierung wird auf Knotenrechnern konfiguriert.

    • Die Standardroute für das Routing von Paketen an das Standardgateway ist in 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 Steuerungsebenenknoten oder Load-Balancer-Knoten befinden sich im Wartungsmodus.

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

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

    • Google APIs sind erreichbar.

  • Computerprüfungen:

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

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

    • Der CNI-Endpunktstatus des Container Network Interface ist fehlerfrei.

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

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

    • VIP für den Kubernetes API-Server ist zugänglich.

    • Load-Balancer-VIPs sind zugänglich.

    • Knoten können über erforderliche Ports kommunizieren.

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

Wenn alle Prüfungen bestanden wurden, aktualisiert Google Distributed Cloud den Cluster. Weitere Informationen zum Upgrade von Clustern finden Sie unter Best Practices für Google Distributed Cloud-Clusterupgrades und Lebenszyklus und Phasen von Clusterupgrades.

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. Prüfen Sie mit dem folgenden Befehl, ob die Cluster für ein Upgrade bereit sind, und führen Sie eine Preflight-Prüfung aus:

    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 Clusterupgrade zu testen, wird im Administratorcluster eine benutzerdefinierte PreflightCheck-Ressource 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 Prüfungen fehlschlagen, ändert Google Distributed Cloud keinen der zugehörigen Knoten, 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.30.100-gke.96
...

Aktuelle 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 aus dem neuesten Patch-Image 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 erstellen oder aktualisieren zu müssen.

Sie können auch die neuesten Systemdiagnosen eines Liveclusters ausführen, um festzustellen, ob er ordnungsgemäß funktioniert. Weitere Informationen finden Sie unter Neueste 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