Preflight-Prüfungen

Preflight-Prüfungen sind eine vorbeugende Maßnahme zur Identifizierung von Problemen, 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 den Clustern vorgenommen, es sei denn, der Preflight prüft alle bestanden. Sie können auch bei Bedarf Preflight-Prüfungen ausführen.

In diesem Dokument wird jede Prüfung beschrieben. Außerdem wird erläutert, unter welchen Umständen sie automatisch ausgeführt wird, wie und wann sie manuell ausgeführt wird und wie die Ergebnisse zu interpretieren sind.

In Google Distributed Cloud können Sie Preflight-Prüfungen in verschiedenen Situationen ausführen:

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

  • Google Distributed Cloud führt auch interne Preflight-Prüfungen aus, wenn ein Administrator- oder Hybridcluster Kubernetes-Ressourcen auf 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 stellen einen Datensatz der Preflight-Prüfungsaktivitäten und -ergebnisse bereit.

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 in allen Namespaces ausführen, um eine umfassende Liste zu erhalten. Die Antwort zeigt für jede Ressource das Alter der Ressource an und ob die Preflight-Prüfungen bestanden sind. Das folgende Antwortbeispiel enthält 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.

    Die folgende 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 Ressource PreflightCheck enthält der Abschnitt Status die folgenden Informationen:

    • Im Abschnitt Checks sind einzelne Preflight-Prüfungen aufgeführt, 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-Verbindungsprüfung (Zugriff auf Container Registry und Google API) für Maschinen mit den IP-Adressen 192.0.2.53 und 192.0.2.54.
      • Gcp: Google Cloud-Konnektivitätsprüfung für den Cluster.
      • Node - Network: Netzwerkprüfungen (Konnektivität, etcd-Vorgang, VIP-Zugriff und Portbindung) für den Cluster.
      • Pod - Cidr: Pod-IP-Adressprüfung auf sich überschneidende Adressen für den Cluster.
    • Im Abschnitt Cluster Spec wird die Clusterkonfiguration angezeigt.
    • Das Feld Pass zeigt true an, was darauf hinweist, dass die Preflight-Prüfungen gemeinsam 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 generiert und wo:

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

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

    • Protokolldateien 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 Google Cloud-Zugriffsprüfungen des Clusters namens gcp.

    • Logdatei für Knotennetzwerkprüfungen mit dem Namen node-network.

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

Preflight-Prüfungen für Clustererstellung

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

Was wird überprüft?

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

  • Knotencomputerprü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 ist der Paketmanager apt bedienbar und erforderliche Pakete sind verfügbar.

    • Bei Red Hat Enterprise Linux ist der Paketmanager dnf bedienbar und die erforderlichen Pakete sind verfügbar.

    • Bei Red Hat Enterprise Linux ist Podman nicht installiert.

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

    • Knotenmaschinen erfüllen die Mindestanforderungen an den Arbeitsspeicher.

    • 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 zum Routing von Paketen an das Standardgateway ist in Knoten vorhanden.

    • Domain Name System (DNS) funktioniert ordnungsgemäß. Wenn der Cluster so konfiguriert ist, dass er hinter einem Proxy ausgeführt wird, wird diese Prüfung übersprungen.

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

    • Wenn der Cluster für die Verwendung einer Registry-Spiegelung konfiguriert ist, ist der Registry-Mirror erreichbar.

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

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

    • Google APIs sind erreichbar.

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

    • Auf die virtuelle IP-Adresse des Kubernetes API-Servers kann zugegriffen werden.

    • Load-Balancer-VIPs sind zugänglich.

    • Knoten können über erforderliche Ports kommunizieren.

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

Wenn alle Prüfungen bestanden sind, erstellt Google Distributed Cloud den Cluster. Weitere Informationen zu den Anforderungen zum Erstellen von Clustern finden Sie unter Voraussetzungen für die Installation.

On-Demand-Preflight-Prüfungen zum Erstellen von Clustern 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 zeitaufwendig sind. Das separate Erkennen und Beheben von Problemen vor dem Start eines größeren Clustervorgangs kann bei der Planung hilfreich sein.

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 der Konfigurationsdatei zugeordnet ist, die Sie prüfen.

  • Mit diesem Befehl wird geprüft, ob die Maschinen und das Netzwerk für die Erstellung von Clustern 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 Clusterkonfigurationsdatei, versucht aber 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 kubeconfig-Datei des zugehörigen Administratorclusters.

  • Mit dem folgenden Befehl wird geprüft, ob die Maschinen und das Netzwerk bereit für die Erstellung von Clustern 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 Cluster upgraden, führt Google Distributed Cloud automatisch Preflight-Prüfungen aus, bevor Änderungen vorgenommen werden.

Was wird überprüft?

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

  • Knotencomputerprü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 stehen mehr als 20% der CPU-Ressourcen zur Verfügung.

    • Knotenmaschinen erfüllen die Mindestanforderungen an den Arbeitsspeicher.

    • Knotenmaschinen erfüllen die Mindestanforderungen an den Laufwerkspeicher.

    • Die Zeitsynchronisierung wird auf Knotenmaschinen konfiguriert.

    • Die Standardroute zum Routing von Paketen an das Standardgateway ist in Knoten vorhanden.

    • Domain Name System (DNS) funktioniert ordnungsgemäß. Wenn der Cluster so konfiguriert ist, dass er hinter einem Proxy ausgeführt wird, wird diese Prüfung übersprungen.

    • Wenn der Cluster für die Verwendung einer Registry-Spiegelung konfiguriert ist, ist der Registry-Mirror erreichbar.

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

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

    • Container Registry, gcr.io, Erreichbarkeit wurde geprüft. Wenn der Cluster für die Verwendung einer Registry-Spiegelung 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 Zustandsendpunkt des Container Network Interface (CNI) ist fehlerfrei.

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

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

    • Auf die virtuelle IP-Adresse des Kubernetes API-Servers kann zugegriffen werden.

    • Load-Balancer-VIPs sind zugänglich.

    • Knoten können über erforderliche Ports kommunizieren.

    • Die etcd-Ereignisinstanz wurde 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 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. Verwenden Sie den folgenden Befehl, um zu prüfen, 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 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 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 Prüfungen anhand der neuesten Google Distributed Cloud-Patchversion auszuführen. So können Sie bekannte Probleme ermitteln, ohne zuerst den Cluster erstellen oder aktualisieren zu müssen.

  • So verwenden Sie die neueste Liste von Prüfungen, um festzustellen, ob Ihre Maschinen und Ihr Netzwerk für die Erstellung von Clustern 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.

Sie können auch die letzten Systemdiagnosen eines Live-Clusters durchführen, um festzustellen, ob der Cluster 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.

Ergebnisse der automatisierten Preflight-Prüfungen ignorieren

Wenn Sie Preflight-Prüfungen bei Bedarf ausführen, bevor Sie Cluster erstellen oder aktualisieren, können Sie die automatisierten Preflight-Prüfungen umgehen. Verwenden Sie zum Umgehen automatischer Preflight-Prüfungen das optionale Flag --force, wenn Sie bmctl create cluster oder bmctl upgrade cluster ausführen.

Nächste Schritte