Preflight-Prüfungen

Preflight-Prüfungen sind eine vorbeugende Maßnahme, mit der Sie Probleme erkennen können, bevor Sie einen größeren Clustervorgang wie das Erstellen oder Aktualisieren von Clustern starten. 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 alle erfolgreich. Sie können bei Bedarf auch Preflight-Prüfungen ausführen.

In diesem Dokument wird die jeweilige Prüfung beschrieben, unter welchen Umständen sie automatisch ausgeführt wird, wie und wann sie manuell ausgeführt werden muss und wie die Ergebnisse interpretiert werden.

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

  • Google Distributed Cloud führt Preflight-Prüfungen aus, wenn Sie Cluster und Knotenpoolressourcen mit bmctl erstellen oder upgraden. Wenn die Prüfungen fehlschlagen, werden keine Änderungen vorgenommen. Sie können diese Prüfungen auch umgehen oder sie explizit ausführen.

  • Google Distributed Cloud führt auch interne Preflight-Prüfungen aus, 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.

PreflightCheck benutzerdefinierte Ressourcen

Wenn eine Preflight-Prüfung ausgeführt wird, erstellt Google Distributed Cloud eine benutzerdefinierte PreflightCheck-Ressource. Benutzerdefinierte PreflightCheck-Ressourcen sind persistent und bieten eine 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. In der Antwort wird für jede Ressource das Alter der Ressource angezeigt und es wird angegeben, ob die Preflight-Prüfungen bestanden wurden. Das folgende Antwortbeispiel zeigt PreflightCheck-Ressourcen für den Namespace cluster-test-admin001.

    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:

    • Im Abschnitt Checks werden die einzelnen Preflight-Prüfungen aufgelistet, die ausgeführt wurden und ob sie bestanden wurden. 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-Konnektivitätsprüfungen (Container 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 (Konnektivität, etcd-Vorgang, VIP-Zugriff und Portbindung) für den Cluster.
      • Pod - Cidr: Pod-IP-Adressenprüfungen für den Cluster auf sich überschneidende Adressen.
    • Der Bereich Cluster Spec zeigt die Clusterkonfiguration.
    • Im Feld Pass wird true angezeigt, was bedeutet, dass die Preflight-Prüfungen kollektiv bestanden wurden.

Preflight-Prüflogs

Wenn Preflight-Prüfungen als Ergebnis eines bmctl-Befehls wie bmctl check preflight ausgeführt werden, erstellt Google Distributed Cloud Logdateien. Folgendes wird wo generiert:

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

  • Dieses Preflight-Verzeichnis wird im Verzeichnis log für den Cluster im Arbeitsbereich bmctl erstellt. Standardmäßig lautet der Verzeichnispfad log 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 nach der IP-Adresse des Knotens benannt. Ein Dateiname könnte beispielsweise 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. Ein Dateiname könnte beispielsweise 192.0.2.53-gcp sein.

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

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

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

Preflight-Prüfungen für die Clustererstellung

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

Was wird überprüft?

Prüfen Sie bei Preflight-Prüfungen für die Installation 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.

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

    • Für Red Hat Enterprise Linux kann der Paketmanager dnf verwendet werden und die erforderlichen Pakete sind verfügbar.

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

    • Knotenmaschinen erfüllen die CPU-Mindestanforderungen.

    • Knotenmaschinen erfüllen die Mindestarbeitsspeicheranforderungen.

    • Knotenmaschinen erfüllen die Mindestanforderungen an den Laufwerkspeicher.

    • Die Zeitsynchronisierung wird auf Knotenmaschinen 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 er erreichbar.

  • Google Cloud prüft für jeden Knoten und für 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 (variiert je nach Load-Balancing-Konfiguration):

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

    • Zugriff auf Load-Balancer-VIPs.

    • Knoten können über erforderliche Ports kommunizieren.

    • Die Ereignisinstanz etcd wurde 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 Übersicht der Installationsvoraussetzungen.

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

Sie können Preflight-Prüfungen auch unabhängig ausführen, bevor Sie einen Cluster erstellen. Dies kann vorteilhaft sein, da größere Clustervorgänge wie die Clustererstellung zeitaufwändig sind. Es kann Ihnen bei der Planung helfen, Probleme separat zu identifizieren und zu beheben, bevor Sie einen größeren Clustervorgang starten.

Selbstverwaltete Cluster

  • Der folgende Befehl validiert die angegebene Clusterkonfigurationsdatei, versucht aber 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 möchten.

Nutzercluster

  • Der folgende Befehl validiert die angegebene Clusterkonfigurationsdatei, 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 zugehörigen 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 auf Clusterupgrades

Beim Upgrade von Clustern führt Google Distributed Cloud automatisch Preflight-Prüfungen aus, bevor Änderungen vorgenommen werden.

Was wird überprüft?

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

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

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

    • Knotenmaschinen erfüllen die Mindestarbeitsspeicheranforderungen.

    • Knotenmaschinen erfüllen die Mindestanforderungen an den Laufwerkspeicher.

    • Die Zeitsynchronisierung wird auf Knotenmaschinen 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 er 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:

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

    • CNI-Systemstatus (Container Network Interface) ist fehlerfrei.

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

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

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

    • Zugriff auf Load-Balancer-VIPs.

    • Knoten können über erforderliche Ports kommunizieren.

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

Wenn alle Prüfungen bestanden wurden, aktualisiert Google Distributed Cloud den Cluster. Weitere Informationen zum Upgraden von Clustern finden Sie unter Best Practices für Clusterupgrades in Google Distributed Cloud 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 Sie den Cluster upgraden. Sie können prüfen, ob die Cluster für ein Upgrade bereit sind, indem Sie den folgenden Preflight-Prüfungsbefehl ausführen, bevor Sie das Upgrade starten:

  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 zum Testen eines Clusterupgrades erstellen, 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, müssen Sie in der Clusterkonfigurationsdatei das Feld BypassPreflightCheck auf true setzen.

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

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.29.100-gke.251
...

Neueste Preflight-Prüfungen und Systemdiagnosen ausführen

Wenn Sie bmctl zum Ausführen von Preflight- oder Systemdiagnosen verwenden, können Sie dem Befehl das Flag --check-image-version latest hinzufügen, um die Prüfungen der neuesten Patchversion von Google Distributed Cloud auszuführen. So können Sie bekannte Probleme identifizieren, ohne zuerst den Cluster erstellen oder aktualisieren zu müssen.

  • So ermitteln Sie mit der neuesten Liste von Prüfungen, ob Ihre Maschinen und Ihr Netzwerk für die Clustererstellung bereit sind:

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

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

Sie können auch die letzten Systemdiagnosen eines Live-Clusters durchführen, um festzustellen, ob er fehlerfrei ist.

  • So führen Sie die neuesten Systemdiagnosen für einen Live-Cluster aus:

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

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

Ergebnisse der automatisierten Preflight-Prüfungen ignorieren

Wenn Sie Preflight-Prüfungen bei Bedarf ausführen, bevor Sie Cluster erstellen oder upgraden, können Sie die automatischen Preflight-Prüfungen umgehen. Verwenden Sie das optionale Flag --force, wenn Sie bmctl create cluster oder bmctl upgrade cluster ausführen, um automatisierte Preflight-Prüfungen zu umgehen.

Nächste Schritte