Diese Seite wurde von der Cloud Translation API übersetzt.

Systemdiagnosen konfigurieren

Google Distributed Cloud (GDC) Air-Gapped bietet Mechanismen zur Systemdiagnose, die feststellen, ob Backend-Instanzen angemessen auf Traffic reagieren. In diesem Dokument wird beschrieben, wie Sie Systemdiagnosen für Load-Balancer erstellen und verwenden.

Sofern nicht anders angegeben, werden Google Cloud Systemdiagnosen durch dedizierte Softwareaufgaben implementiert, die gemäß den in einer Systemdiagnoseressource angegebenen Parametern eine Verbindung zu Back-Ends herstellen. Jeder Verbindungsversuch wird als Prüfung bezeichnet. Google Cloud zeichnet den Erfolg oder Misserfolg jeder Prüfung auf.

Der Systemzustand jedes Back-Ends wird durch eine konfigurierbare Anzahl von aufeinanderfolgenden erfolgreichen oder fehlgeschlagenen Prüfungen bestimmt. Sie konfigurieren also die Anzahl der aufeinanderfolgenden erfolgreichen Tests, die erforderlich sind, um ein Back-End als fehlerfrei zu markieren, und die Anzahl der aufeinanderfolgenden Fehler, die erforderlich sind, um es als fehlerhaft zu markieren.

Dieser Systemzustand bestimmt, ob ein Back-End berechtigt ist, neue Anfragen oder Verbindungen zu erhalten. Ein fehlerhaftes Backend, das durch die Systemdiagnose erkannt wurde, empfängt keinen Traffic über den Load-Balancer. Sie definieren die Kriterien für eine erfolgreiche Prüfung. Weitere Informationen finden Sie im Abschnitt Funktionsweise von Systemdiagnosen.

Systemdiagnoseprotokolle

Systemdiagnosen unterstützen die folgenden Protokolle:

TCP
HTTP
HTTPS

Systemdiagnose auswählen

Systemdiagnosen müssen mit dem Typ des Load-Balancers und den Back-End-Typen kompatibel sein. Berücksichtigen Sie bei der Auswahl einer Systemdiagnose die folgenden Faktoren:

Protokoll:Das Protokoll, mit dem GDC die Back-Ends prüft. Die unterstützten Protokolle sind TCP, HTTP und HTTPS. Das TCP-Protokoll ist nützlich für grundlegende Systemdiagnosen, mit denen die Verbindung zu einem Back-End überprüft wird. Die HTTP- und HTTPS-Protokolle bieten dagegen detailliertere Systemdiagnosemechanismen für VMs, auf denen bereits HTTP- oder HTTPS-Arbeitslasten ausgeführt werden.
Portspezifikation:Der Port, den GDC mit dem Protokoll verwendet, um den Status eines Back-Ends zu prüfen. Sie müssen einen Port für die Systemdiagnose angeben.
Kategorie:Systemdiagnosen können global oder zonal sein. Globale Systemdiagnosen erstrecken sich über alle Zonen einer GDC-Bereitstellung, während zonale Systemdiagnosen einer Zone entsprechen.

Funktionsweise von Systemdiagnosen

In den folgenden Abschnitten wird beschrieben, wie Systemdiagnosen funktionieren.

Prüfungen

Wenn Sie eine Systemdiagnose einrichten, definieren Sie Einstellungen oder akzeptieren Standardeinstellungen, die festlegen, wie oft jede Prüfung den Zustand der zugehörigen Endpunkte bewertet. Diese Einstellungen sind entscheidend, da der Load-Balancer keine Anfragen mehr an ein Backend weiterleitet, das anhand der von Ihnen konfigurierten Kriterien als fehlerhaft eingestuft wird. Die Probe wird ihre Auswertungen fortsetzen und wieder Traffic an das Back-End senden, sobald es wieder als fehlerfrei gilt.

Die Einstellungen für Systemdiagnosen gelten einheitlich für alle Back-Ends in einem Back-End-Dienst oder Zielpool und können nicht pro Back-End konfiguriert werden.

Konfigurations-Flag	Erklärung	Standardwert
Überprüfungsintervall `check-interval`	Die Zeit (in Sekunden) vom Start einer Prüfung bis zum Start der nächsten Prüfung durch denselben Prober.	`5s` (5 Sekunden)
timeoutSec `timeoutSec`	Die Zeit in Sekunden, die auf eine Probe gewartet wird, bevor ein Fehler gemeldet wird.	`5s` (5 Sekunden)
healthyThreshold `healthyThreshold`	Die Anzahl der aufeinanderfolgenden Prüfungen, die bestanden werden müssen, damit der Endpunkt als fehlerfrei gilt.	2
unhealthyThreshold `unhealthyThreshold`	Die Anzahl der sequenziellen Prüfungen, die fehlschlagen müssen, damit der Endpunkt als fehlerhaft gilt.	2

Erfolgskriterien für HTTP- und HTTPS-Systemdiagnosen

Bei HTTP- und HTTPS-Systemdiagnosen ist ein HTTP-Statuscode 200 (OK) für eine erfolgreiche Antwort erforderlich, bevor das Zeitlimit der Systemdiagnose abläuft. Andere HTTP-Antwortcodes, einschließlich Weiterleitungen (z. B. 301, 302), gelten als fehlerhaft.

Neben der Anforderung eines HTTP-200 (OK)-Antwortcodes können Sie Folgendes tun:

Konfigurieren Sie jeden Systemdiagnose-Prober so,dass HTTP-Anfragen an einen bestimmten Anfragepfad anstelle des Standardanfragepfads / gesendet werden.
Konfigurieren Sie jeden Systemdiagnose-Prober so, dass er im HTTP-Antworttext nach dem Vorhandensein eines erwarteten Antwortstrings sucht. Der erwartete Antwortstring darf nur aus druckbaren ASCII-Zeichen mit einem Byte bestehen und muss sich innerhalb der ersten 1.024 Byte des HTTP-Antworttexts befinden.

In der folgenden Tabelle sind gültige Kombinationen der Felder requestPath und response aufgeführt, die für HTTP- und HTTPS-Systemdiagnosen verfügbar sind.

Konfigurations-Flags	Prober-Verhalten	Erfolgskriterien
Weder RequestPath noch Response angegeben	Der Prober verwendet `/` als Anfragepfad.	Nur HTTP-Antwortcode `200 (OK)`.
Sowohl RequestPath als auch Response angegeben	Der Prober verwendet den konfigurierten Anfragepfad.	Der HTTP-Antwortcode `200 (OK)` und die ersten 1.024 ASCII-Zeichen des HTTP-Antworttexts müssen mit dem erwarteten Antwortstring übereinstimmen.
Nur Antwort angegeben	Der Prober verwendet `/` als Anfragepfad.	Der HTTP-Antwortcode `200 (OK)` und die ersten 1.024 ASCII-Zeichen des HTTP-Antworttexts müssen mit dem erwarteten Antwortstring übereinstimmen.
Nur RequestPath angegeben	Der Prober verwendet den konfigurierten Anfragepfad.	Nur HTTP-Antwortcode `200 (OK)`.

Erfolgskriterien für TCP-Systemdiagnosen

Für TCP-Systemdiagnosen gelten die folgenden grundlegenden Erfolgskriterien:

Bei TCP-Systemdiagnosen muss ein Prober für die Systemdiagnose vor Ablauf des Zeitlimits für die Systemdiagnose eine TCP-Verbindung zum Backend öffnen.
Bei TCP-Systemdiagnosen muss die TCP-Verbindung auf eine der folgenden Arten geschlossen werden:
- Der Prober für die Systemdiagnose sendet entweder ein FIN- oder ein RST-Paket (Reset, Zurücksetzen).
- Indem das Backend ein FIN-Paket sendet.
- Wenn ein Backend ein TCP-RST-Paket sendet, kann die Prüfung als nicht erfolgreich eingestuft werden, wenn der Prober für die Systemdiagnose bereits ein FIN-Paket gesendet hat.

Hinweise

Zum Konfigurieren von Systemdiagnoseprüfungen benötigen Sie Folgendes:

Sie sind Inhaber des Projekts, für das Sie den Load Balancer konfigurieren. Weitere Informationen finden Sie unter Projekt erstellen.
Die erforderlichen Identitäts- und Zugriffsrollen:
- Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Load Balancer Admin“ (load-balancer-admin) zuzuweisen.
- Bitten Sie bei globalen internen Load Balancern Ihren IAM-Administrator der Organisation, Ihnen die Rolle „Global Load Balancer Admin“ (global-load-balancer-admin) zuzuweisen. Weitere Informationen finden Sie unter Beschreibungen vordefinierter Rollen.

Systemdiagnosen erstellen und verwalten

GDC unterstützt globale und zonale Systemdiagnosen.

HealthCheck API

Sie können ein HealthCheck-Objekt als global oder zonal konfigurieren. Globale HealthCheck-Objekte werden für globale Load-Balancer-Konfigurationen verwendet, zonale HealthCheck-Objekte für zonale Load-Balancer-Konfigurationen. Beide Typen haben denselben Namen und dieselbe Spezifikation. Sie verwenden jedoch unterschiedliche apiVersion-Werte und API-Server:

Zonale apiVersion: networking.gdc.goog
Globale apiVersion: networking.global.gdc.goog

Sie können auch die gcloud-Befehlszeile verwenden, um Systemdiagnosen zu erstellen und zu verwalten.

Globale `HealthCheck` erstellen

Das folgende Beispiel zeigt, wie Sie mit der API eine Systemdiagnose erstellen:

  kubectl --kubeconfig GLOBAL_ORG_ADMIN_CLUSTER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.global.gdc.goog/v1 
  kind: HealthCheck 
  metadata: 
    namespace: PROJECT 
    name: my-hc 
  spec: 
    httpHealthCheck: 
      port: PORT 
      host: HOST 
      requestPath: requestPath 
      response: responseT 
  EOF

Zonale `HealthCheck` erstellen

Das folgende Beispiel zeigt, wie Sie mit der API eine Systemdiagnose erstellen:

  kubectl --kubeconfig MANAGEMENT_API_SERVER_KUBECONFIG apply -f - <<EOF 
  apiVersion: networking.gdc.goog/v1
  kind: HealthCheck
  metadata:
    namespace: PROJECT
    name: my-hc
  spec:
    httpHealthCheck:
      port: PORT
      host: HOST
      requestPath: requestPath 
      response: response 
  EOF

Informationen zum Verknüpfen einer Systemdiagnose mit einem Load Balancer finden Sie unter:

Konfigurationsprüfung

Prüfen Sie den Ready-Zustand des HealthCheck-Objekts, um sicherzustellen, dass die Konfiguration korrekt ist. Diese Bedingung weist auf Konfigurationsfehler hin. Prüfen Sie außerdem, ob die Felder die erforderlichen HealthCheck-Einstellungen korrekt widerspiegeln.

Weitere Nutzungshinweise

In den folgenden Abschnitten finden Sie zusätzliche Hinweise zur Verwendung von Systemdiagnosen auf Google Cloud.

Zertifikate und Systemdiagnosen

Bei Protokollen wie HTTPS, die Zertifikate für Ihre Back-Ends erfordern,

Zertifikate können selbst signiert sein oder von einer beliebigen Zertifizierungsstelle stammen.
Abgelaufene oder zukünftige Zertifikate sind zulässig.

Header

Wenn Sie Systemdiagnosen für HTTP- oder HTTPS-Protokolle konfigurieren, können Sie mit dem Flag --host einen HTTP-Host-Header angeben.

Wichtig: Der Load Balancer fügt die von Ihnen konfigurierten benutzerdefinierten Anfrageheader nur Clientanfragen hinzu, nicht Systemdiagnoseprüfungen. Wenn Ihr Backend einen bestimmten Header für die Autorisierung erfordert, der im Systemdiagnosepaket fehlt, schlägt die Systemdiagnose möglicherweise fehl.

Beispiel für eine Systemdiagnose

Wenn eine Systemdiagnose mit den folgenden Parametern konfiguriert ist:

Intervall: 30 Sekunden
Zeitlimit: 5 Sekunden
Protokoll: HTTP
Fehlerschwellenwert: 2 (Standard)
Schwellenwert für Intaktheit: 2 (Standard)

Die Systemdiagnose funktioniert so:

Jeder Systemdiagnose-Prober führt Folgendes aus:
1. Initiiert alle 30 Sekunden eine HTTP-Verbindung von einer Quell-IP-Adresse zur Backend-Instanz.
2. Warten Sie bis zu fünf Sekunden auf die Rückgabe eines HTTP-Statuscodes 200 (OK) (das festgelegte Erfolgskriterium für HTTP- und HTTPS-Protokolle).
Ein Back-End gilt als fehlerhaft, wenn mindestens ein System für die Systemdiagnoseprüfung folgende Voraussetzungen erfüllt:
1. Es erhält keinen HTTP-200 (OK)-Antwortcode für zwei aufeinanderfolgende Prüfungen aufgrund einer abgelehnten Verbindung, einer Verbindungszeitüberschreitung oder einer Socket-Zeitüberschreitung.
2. Es erhält zwei aufeinanderfolgende Antworten, die nicht den protokollspezifischen Erfolgskriterien entsprechen.
Ein Backend gilt als fehlerfrei, wenn mindestens ein System für die Systemdiagnoseprüfung zwei aufeinanderfolgende Antworten empfängt, die den protokollspezifischen Erfolgskriterien entsprechen.

In diesem Beispiel initiiert jeder Prober alle 30 Sekunden eine Verbindung. Zwischen den Verbindungsversuchen eines Probers liegen 30 Sekunden, unabhängig von der Dauer des Zeitlimits (ganz gleich, ob es eine Zeitüberschreitung der Verbindung gab oder nicht). Mit anderen Worten: Das Zeitlimit muss immer kleiner oder gleich dem Intervall sein und das Zeitlimit verlängert das Intervall nicht.

Beschränkungen

GDC-Systemdiagnosen werden nur für VM-Endpunkte ausgeführt.
Load Balancer mit Systemdiagnosen können nicht mit Pods und VMs als gemischte Back-Ends konfiguriert werden. Ein Load-Balancer darf nur aus Pods oder nur aus VMs als Endpunkten bestehen. Derzeit darf ein Load Balancer nur aus Pods oder nur aus VMs als Endpunkten bestehen.
Die Änderbarkeit des Load-Balancers und der zugehörigen Systemdiagnose wird noch nicht unterstützt.