Auswirkungen einer vorübergehenden Verbindungsunterbrechung zu Google Cloud

Google Distributed Cloud (nur Software) basiert auf Kubernetes und kann lokal auf VMware- oder Bare-Metal-Servern bereitgestellt werden. Obwohl Distributed Cloud lokal ausgeführt wird, ist sie aus verschiedenen Gründen unter anderem zu einer permanenten Verbindung zu Google Cloud konzipiert, darunter für Monitoring und Verwaltung. Sie müssen jedoch möglicherweise wissen, was passiert, wenn die Verbindung zu Google Cloud aus irgendeinem Grund unterbrochen wird(z. B. aufgrund eines technischen Problems). In diesem Dokument werden die Auswirkungen eines Verbindungsverlusts für Cluster in einer reinen Softwarebereitstellung von Distributed Cloud (auf Bare Metal oder auf VMware) beschrieben. Außerdem werden die Problemumgehungen beschrieben, die Sie in diesem Fall verwenden können.

Diese Informationen sind für Architekten hilfreich, die sich auf eine ungeplante oder erzwungene Trennung von Google Cloud vorbereiten müssen und die Auswirkungen ihrer Verwendung verstehen. Sie sollten jedoch nicht eine reine Software-Bereitstellung von Distributed Cloud, die vonGoogle Cloud getrennt ist, als Nominalarbeitsmodus verwenden. Denken Sie daran, dass wir Distributed Cloud so gestalten, dass die Skalierbarkeit und Verfügbarkeit von Google Cloud -Diensten genutzt wird. Dieses Dokument basiert auf dem Design und der Architektur der verschiedenen Google Cloud -Komponenten, die während einer vorübergehenden Unterbrechung mit Distributed Cloud kompatibel sind. Wir können nicht garantieren, dass dieses Dokument vollständig ist.

In diesem Dokument wird davon ausgegangen, dass Sie mit GKE vertraut sind. Wenn dies nicht der Fall ist, empfehlen wir Ihnen, zuerst die GKE-Übersicht zu lesen.

Lizenzvalidierung und Messung

Wenn Sie die Anthos API (anthos.googleapis.com) in Ihrem Google Cloud Projekt aktiviert haben, generiert und aktualisiert der im Cluster ausgeführte Messwert-Controller die Lizenzberechtigung regelmäßig. Die Toleranz für einen Verbindungsverlust beträgt 12 Stunden. Außerdem ist die Verbindung für die Verwaltung von Messung und Abrechnung erforderlich.

In dieser Tabelle wird das Verhalten von Funktionen im Zusammenhang mit Lizenzierung und Messung im Falle einer vorübergehenden Trennung von Google Cloudaufgeführt:

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Lizenzvalidierung Der Abrechnungscontroller generiert und aktualisiert die benutzerdefinierte Ressource für die Lizenzberechtigung regelmäßig, solange anthos.googleapis.com im Google Cloud -Projekt aktiviert ist. Die Komponenten, die die benutzerdefinierte Berechtigungsressource verwenden, unterstützen einen Kulanzzeitraum. Sie funktionieren unterbrechungsfrei, solange die benutzerdefinierte Berechtigungsressource innerhalb des Kulanzzeitraums aktualisiert wird. Unbegrenzt Nach Ablauf des Kulanzzeitraums beginnen Komponenten, Fehler zu protokollieren. Sie können Ihren Cluster nicht mehr aktualisieren. Keine
Messung und Abrechnung Der Messwert-Controller meldet die vCPU-Kapazität des Clusters zu Abrechnungszwecken an die Google Cloud Service Control API. Ein clusterinterner Agent speichert Abrechnungsdatensätze im Cluster, wenn die Verbindung getrennt ist. Die Datensätze werden abgerufen, sobald der Cluster wieder eine Verbindung zu Google Cloudherstellt. Unbegrenzt Für die Compliance sind jedoch Messungsinformationen erforderlich, wie in den dienstspezifischen Nutzungsbedingungen für „Premium Software“ angegeben. Keine

Cluster-Lebenszyklus

In diesem Abschnitt werden Szenarien wie das Erstellen, Aktualisieren, Löschen und Ändern der Größe von Clustern sowie das Monitoring des Status dieser Aktivitäten behandelt.

In den meisten Szenarien können Sie Befehlszeilentools wie bmctl, gkectl und kubectl verwenden, um Vorgänge während einem vorübergehenden Verbindungsverlust auszuführen. Sie können auch den Status dieser Vorgänge mit diesen Tools überwachen. Nach dem erneuten Verbinden wird dieGoogle Cloud -Konsole aktualisiert, um die Ergebnisse der Vorgänge anzuzeigen, die während der Trennung ausgeführt wurden.

Aktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Clustererstellung Cluster erstellen Sie mit den CLI-Tools bmctl oder gkectl. Für diesen Vorgang ist eine Verbindung zu Google Clouderforderlich. Sie können keine Cluster erstellen. Null Keine
Clusterupgrade Verwenden Sie die bmctl- oder gkectl-Befehlszeilentools, um Cluster zu aktualisieren. Für diesen Vorgang ist eine Verbindung zu Google Clouderforderlich. Sie können Cluster nicht aktualisieren. Null Keine
Cluster löschen Cluster löschen Sie mit den CLI-Tools bmctl oder gkectl. Für diesen Vorgang ist keine Verbindung zu Google Clouderforderlich. Sie können Cluster löschen. Unbegrenzt -
Clusterstatus ansehen Informationen zu Ihren Clustern finden Sie in der Console in der Liste der Google Kubernetes Engine-Cluster. In der Console werden keine Clusterinformationen angezeigt. Unbegrenzt Verwenden Sie kubectl, um Ihre Cluster direkt abzufragen und die benötigten Informationen abzurufen.
Knoten aus einem Cluster entfernen Sie benötigen keine Verbindung zu Google Cloud , um Knoten aus einem Cluster zu entfernen. Sie können Knoten aus einem Cluster entfernen. Unbegrenzt -
Knoten zu einem Cluster hinzufügen Der neue Knoten ruft Container-Images aus Container Registry ab, um ordnungsgemäß zu funktionieren. Es wird eine Preflight-Prüfung ausgeführt, um zu bestätigen, dass eine Verbindung zu Google Cloudbesteht. Die Preflight-Prüfungen, die beim Hinzufügen eines neuen Knotens ausgeführt werden, prüfen, ob eine Verbindung zu Google Cloudbesteht. Daher können Sie einem Cluster keinen neuen Knoten hinzufügen, wenn er getrennt ist. Null Keine

Anwendungslebenszyklus

Eine vorübergehende Trennung von Google Cloud wirkt sich meist nicht auf die Verwaltung Ihrer Anwendungen aus, die in einem lokalen Cluster ausgeführt werden. Nur das Connect Gateway ist betroffen. Wenn Sie Container Registry, Artifact Registry, Cloud Build oder Cloud Deploy verwenden, um Ihre Container-Images oder CI/CD-Pipelines inGoogle Cloudzu verwalten, sind diese Elemente bei einem Verbindungsverlust nicht mehr verfügbar. Strategien zum Umgang mit einem Verbindungsverlust für diese Produkte werden in diesem Dokument nicht behandelt.

Aktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Bereitstellung von Anwendungen Sie stellen Anwendungen lokal mit kubectl, durch CI-/CD-Tools oder unter Einsatz des Connect Gateway bereit. Das Connect Gateway ist nicht verfügbar. Alle anderen Bereitstellungsmethoden funktionieren weiterhin, solange sie direkt eine Verbindung zur Kubernetes API herstellen. Unbegrenzt Wenn Sie das Connect Gateway verwenden, wechseln Sie dazu kubectl lokal zu verwenden.
Anwendungen entfernen Sie entfernen Anwendungen lokal mit kubectl, durch CI-/CD-Tools oder unter Einsatz des Connect Gateway. Das Connect Gateway ist nicht verfügbar. Alle anderen Bereitstellungsmethoden funktionieren weiterhin, solange sie direkt eine Verbindung zur Kubernetes API herstellen. Unbegrenzt Wenn Sie das Connect Gateway verwenden, wechseln Sie dazu kubectl lokal zu verwenden.
Anwendungen horizontal hochskalieren Sie skalieren Anwendungen lokal mit kubectl, durch CI-/CD-Tools oder unter Einsatz des Connect Gateway. Das Connect Gateway ist nicht verfügbar. Alle anderen Bereitstellungsmethoden funktionieren weiterhin, solange sie direkt eine Verbindung zur Kubernetes API herstellen. Unbegrenzt Wenn Sie das Connect Gateway verwenden, wechseln Sie dazu kubectl lokal zu verwenden.

Logging und Monitoring

Die Nachvollziehbarkeit unterstützt Ihre Organisation bei der Einhaltung regulatorischer Vorgaben und Compliance-Richtlinien. Distributed Cloud unterstützt die Nachvollziehbarkeit durch Anwendungs-, Kubernetes- und Audit-Logging. Viele Kunden entscheiden sich für die Nutzung von Cloud Logging und Cloud Monitoring von Google, um keine lokale Logging- und Monitoring-Infrastruktur verwalten zu müssen. Andere Kunden bevorzugen es, Logs in einem lokalen System zur Aggregation zusammenzuführen. Zur Unterstützung solcher Kunden bietet Distributed Cloud eine direkte Einbindung in Dienste wie Prometheus. In diesem Modus hat eine vorübergehende Trennung von Google Cloudkeine Auswirkungen auf die Logging- oder Monitoring-Funktionalität.

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Anwendungs-Logging mithilfe Cloud Logging Das System schreibt Logs in Cloud Logging. Das System puffert Logs auf dem lokalen Laufwerk. 4,5 Stunden oder 4 GiB lokaler Zwischenspeicher pro Knoten. Wenn der Zwischenspeicher gefüllt ist oder die Verbindung 4,5 Stunden dauert, werden die ältesten Einträge gelöscht. Verwenden Sie eine lokale Logging-Lösung.
System-/Kubernetes-Logging mithilfe Cloud Logging Das System schreibt Logs in Cloud Logging. Das System puffert Logs auf dem lokalen Laufwerk. 4,5 Stunden oder 4 GiB lokaler Zwischenspeicher pro Knoten. Wenn der Zwischenspeicher gefüllt ist oder die Verbindung 4,5 Stunden dauert, werden die ältesten Einträge gelöscht. Verwenden Sie eine lokale Logging-Lösung.
Audit-Logging mit Cloud-Audit-Logs Das System schreibt Logs in Cloud Logging. Das System puffert Logs auf dem lokalen Laufwerk. 10 GiB lokaler Zwischenspeicher pro Steuerungsebenenknoten. Wenn der Zwischenspeicher gefüllt ist, werden die ältesten Einträge gelöscht. Richten Sie eine Logweiterleitung an eine lokale Logginglösung ein.
Anwendungs-Logging mit einem anderen Anbieter Sie können verschiedene Drittanbieter wie Elastic, Splunk, Datadog oder Loki verwenden. Keine Auswirkungen Unbegrenzt -
System-/Kubernetes-Logging mit einem anderen Anbieter Sie können verschiedene Drittanbieter wie Elastic, Splunk oder Datadog verwenden. Keine Auswirkungen Unbegrenzt -
In Cloud Monitoring geschriebene Anwendungs- und Kubernetes-Messwerte Das System schreibt Messwerte in Cloud Monitoring. Messwerte werden auf dem lokalen Laufwerk zwischengespeichert. 24 Stunden oder 6 GiB lokaler Zwischenspeicher pro Knoten für Systemmesswerte und 1 GiB lokaler Zwischenspeicher pro Knoten für Anwendungsmesswerte. Wenn der Zwischenspeicher gefüllt ist oder die Trennung 24 Stunden dauert, werden die ältesten Einträge gelöscht. Verwenden Sie eine lokale Monitoring-Lösung.
Auf Monitoring-Daten von Kubernetes- und Anwendungsarbeitslasten zugreifen und diese lesen Alle Messwerte sind in der Console und über die Cloud Monitoring API verfügbar. Messwerte werden in Cloud Monitoring während einer Verbindungsunterbrechung nicht aktualisiert. 24 Stunden oder 6 GiB lokaler Zwischenspeicher pro Knoten für Systemmesswerte und 1 GiB lokaler Zwischenspeicher pro Knoten für Anwendungsmesswerte. Wenn der Zwischenspeicher gefüllt ist oder die Trennung 24 Stunden dauert, werden die ältesten Einträge gelöscht. Verwenden Sie eine lokale Monitoring-Lösung.
Benachrichtigungsregeln und Paging für Messwerte Cloud Monitoring unterstützt Benachrichtigungen. Sie können Benachrichtigungen für jeden Messwert erstellen. Das System kann Benachrichtigungen über verschiedene Kanäle senden. Das System löst keine Benachrichtigungen aus, wenn die Verbindung getrennt ist. Das System löst nur Benachrichtigungen aus Messwertdaten aus, die bereits an Cloud Monitoring gesendet wurden. Lokale Monitoring- und Benachrichtigungslösung verwenden.

Konfigurations- und Richtlinienverwaltung

Mit Config Sync und Policy Controller können Sie Konfigurationen und Richtlinien in großem Umfang in allen Ihren Clustern verwalten. Sie speichern Konfigurationen und Richtlinien in einem Git-Repository und das System synchronisiert sie automatisch mit Ihren Clustern.

Config Sync

Config Sync verwendet In-Cluster-Agents, um eine direkte Verbindung zu einem Git-Repository herzustellen. Sie können Änderungen an der Repository-URL oder den Synchronisierungsparametern mit der Google Cloud CLI oder den kubectl-Tools verwalten.

Während der vorübergehenden Trennung ist die Synchronisierung nicht betroffen, wenn die clusterinternen Agents weiterhin das Git-Repository erreichen können. Wenn Sie jedoch die Synchronisierungsparameter mit der gcloud CLI oder der Console ändern, werden sie während der Trennung nicht auf den Cluster angewendet. Sie können sie vorübergehend lokal mit kubectl überschreiben. Beim erneuten Verbinden werden alle lokalen Änderungen überschrieben.

Policy Controller

Policy Controller ermöglicht das Erzwingen vollständig programmierbarer Richtlinien für Ihre Cluster. Diese Richtlinien dienen als „Leitlinien” und verhindern Änderungen, die gegen von Ihnen definierte Sicherheits-, Betriebs- oder Compliancekontrollen verstoßen.

Aktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Konfiguration aus einem Git-Repository synchronisieren Clusterinterne Agents stellen eine direkte Verbindung zum Git-Repository her. Sie können die Repository-URL oder die Synchronisierungsparameter mit einer Google Cloud API ändern. Die Synchronisierung der Konfigurationen ist davon nicht betroffen. Wenn Sie die Synchronisierungsparameter mit der gcloud CLI oder in der Console ändern, werden sie während der Trennung nicht auf den Cluster angewendet. Sie können sie vorübergehend lokal mit kubectl überschreiben. Beim erneuten Verbinden werden alle lokalen Änderungen überschrieben. Unbegrenzt Verwenden Sie niemals die Fleet API für Config Sync. Konfigurieren Sie sie nur über die Kubernetes API.
Richtlinien für Anfragen an die Kubernetes API durchsetzen Durch die Einbindung in die Kubernetes API erzwingt der Cluster-Agent Einschränkungen. Richtlinien verwalten Sie mit der lokalen Kubernetes API. Sie verwalten die Systemkonfiguration von Policy Controller mit einer Google CloudAPI. Die Richtlinienerzwingung bleibt davon unberührt. Richtlinien werden weiterhin mit der lokalen Kubernetes API verwaltet. Änderungen an der Policy Controller-Systemkonfiguration, die die Google Cloud API verwenden, werden nicht an den Cluster weitergegeben, aber Sie können sie vorübergehend lokal überschreiben. Beim erneuten Verbinden werden alle lokalen Änderungen überschrieben. Unbegrenzt Verwenden Sie niemals die Fleet API für Policy Controller und konfigurieren Sie sie nur über die Kubernetes API.
Config Sync mit der Google CloudAPI installieren, konfigurieren oder aktualisieren Mit der Google Cloud API verwalten Sie die Installation und Upgrades von Agents im Cluster. Sie verwenden auch diese API (oder die gcloud CLI oder die Console), um die Konfiguration dieser Agents zu verwalten. Clusterinterne Agents funktionieren weiterhin normal. Sie können Agents im Cluster nicht über die Google Cloud API installieren, aktualisieren oder konfigurieren. Alle ausstehenden Installationen, Upgrades oder Konfigurationen, die mit der API ausgeführt werden, werden bei der erneuten Verbindung fortgesetzt. Null Verwenden Sie niemals die Fleet API für Policy Controller und konfigurieren Sie sie nur über die Kubernetes API.
System- oder Synchronisierungsstatus in der Console ansehen Sie können den Status und den Synchronisierungsstatus clusterinterner Agents mit einer Google Cloud API oder der Console ansehen. Statusinformationen in der Google Cloud API oder Console sind veraltet. Die API zeigt einen Verbindungsfehler an. Alle Informationen bleiben clusterbasiert über die lokale Kubernetes API verfügbar. Null Verwenden Sie die nomos-Befehlszeile oder die lokale Kubernetes API.

Sicherheit

In diesem Abschnitt wird beschrieben, wie sich eine vorübergehende Trennung von Google Cloudauf Sicherheitsfunktionen wie Identität, Authentifizierung, Autorisierung und Secret-Verwaltung auswirkt.

Identität, Authentifizierung und Autorisierung

Distributed Cloud kann für Anwendungs- und Nutzerrollen direkt eine Verbindung zu Cloud Identity herstellen, um Arbeitslasten mit Connect zu verwalten oder die Endpunktauthentifizierung mit OIDC zu nutzen. Wenn die Verbindung zu Google Cloud getrennt wird, wird auch die Verbindung zu Cloud Identity getrennt und die entsprechenden Funktionen sind nicht mehr verfügbar. Für Arbeitslasten, die während einer vorübergehenden Trennung zusätzliche Ausfallsicherheit erfordern, können Sie GKE Identity Service für die Integration in einen LDAP- oder OIDC-Anbieter (einschließlich ADFS) verwenden, um die Endnutzerauthentifizierung zu konfigurieren.

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Cloud Identity als Identitätsanbieter mithilfe des Connect-Gateways Sie können auf Distributed Cloud-Ressourcen mit Cloud Identity als Identitätsanbieter zugreifen und über das Connect-Gateway eine Verbindung herstellen. Das Connect Gateway erfordert eine Verbindung zu Google Cloud. Sie können während des Trennvorgangs keine Verbindung zu Ihren Clustern herstellen. Null Verwenden Sie GKE Identity Service, um eine Föderation mit einem anderen Identitätsanbieter herzustellen.
Identität und Authentifizierung über einen externen Identitätsanbieter Unterstützt OIDC und LDAP. Sie verwenden die gcloud CLI für die erste Anmeldung. Für OIDC-Anbieter können Sie sich mit der Console anmelden. Sie können sich dann normal für die Cluster-API authentifizieren (z. B. mit kubectl). Solange der Identitätsanbieter sowohl für Sie als auch für den Cluster zugänglich ist, können Sie sich weiterhin für die Cluster-API authentifizieren. Sie können sich nicht über die Console anmelden. Sie können die OIDC- oder LDAP-Konfiguration Ihrer Cluster nur lokal aktualisieren, nicht die Console verwenden. Unbegrenzt -
Autorisierung Distributed Cloud unterstützt die rollenbasierte Zugriffssteuerung (RBAC). Rollen können Nutzern, Gruppen oder Dienstkonten zugewiesen werden. Das System ruft Nutzeridentitäten und Gruppen vom Identitätsanbieter ab. Das RBAC-System befindet sich lokal im Kubernetes-Cluster und wird durch die Trennung von Google Cloud nicht beeinträchtigt. Wenn es jedoch auf Identitäten nutzt, die von Cloud Identity stammen, sind diese im Falle eines Verbindungsverlusts nicht verfügbar. Unbegrenzt -

Secret- und Schlüsselverwaltung

Die Secret- und Schlüsselverwaltung ist ein wichtiger Bestandteil Ihres Sicherheitsstatus. Das Verhalten von Distributed Cloud bei einer Trennung vonGoogle Cloud hängt davon ab, welchen Dienst Sie für diese Funktionen verwenden.

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Secret- und Schlüsselverwaltung mit dem Cloud Key Management Service und dem Secret Manager Sie verwenden direkt den Cloud Key Management Service für Ihre kryptografischen Schlüssel und den Secret Manager für Ihre Secrets. Sowohl Cloud Key Management Service als auch Secret Manager sind nicht verfügbar. Null Verwenden Sie stattdessen lokale Systeme.
Secret- und Schlüsselverwaltung mit Hashicorp Vault und Google Cloud -Diensten Sie konfigurieren Hashicorp Vault zur Verwendung von Cloud Storage oder Spanner zum Speichern von Secrets und Cloud Key Management Service zum Verwalten von Schlüsseln. Wenn Hashicorp Vault auf Ihrem lokalen Cluster ausgeführt wird und sich die Verbindungs-Trennung auch auf Hashicorp Vault auswirkt, stehen während der Trennung keine Secret-Speicherung und Schlüsselverwaltung zur Verfügung. Null Verwenden Sie stattdessen lokale Systeme.
Secret- und Schlüsselverwaltung mit Hashicorp Vault und lokalen Diensten Sie konfigurieren Hashicorp Vault so, dass ein lokales Speicher-Backend für Secrets und ein lokales Schlüsselverwaltungssystem (z. B. ein Hardware-Sicherheitsmodul) verwendet werden. Die Trennung von Google Cloud hat keine Auswirkungen. Unbegrenzt -

Netzwerke und Netzwerkdienste

In diesem Abschnitt werden die Netzwerk- und Netzwerkdienste für lokale Cluster behandelt, einschließlich der Auswirkungen einer vorübergehenden Trennung vonGoogle Cloud. Sie enthält Informationen zu Load Balancing, Cloud Service Mesh und anderen Netzwerkdiensten.

Load-Balancing

Wenn Sie Kubernetes-Dienste, die in einem lokalen Cluster gehostet werden, für Nutzer verfügbar machen möchten, haben Sie die folgenden Optionen:

Diese Load-Balancing-Optionen funktionieren auch dann, wenn die Verbindung zuGoogle Cloudgetrennt wurde.

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Gebündelter L4-Load-Balancer Bietet vollständig lokales L4-Load-Balancing, ohne vonGoogle Cloud -APIs oder dem Netzwerk abhängig zu sein. Keine Änderung Unbegrenzt -
Manueller oder integrierter Load-Balancer Unterstützt F5 BIG-IP und andere, ebenfalls lokal gehostete Optionen. Keine Änderung Unbegrenzt -

Cloud Service Mesh

Mit Cloud Service Mesh können Sie die Kommunikation zwischen Ihren Diensten, die in einem lokalen Cluster ausgeführt werden, verwalten, beobachten und schützen. Nicht alle Cloud Service Mesh-Funktionen werden von Distributed Cloud unterstützt. Weitere Informationen finden Sie in der Liste der unterstützten Funktionen.

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Richtlinien bereitstellen oder aktualisieren (Routing, Autorisierung, Sicherheit, Audit usw.) Sie können die Cloud Service Mesh-Richtlinien mithilfe der Console, kubectl, asmcli oder istioctl verwalten. Sie können nur kubectl oder istioctl verwenden, um Cloud Service Mesh-Richtlinien zu verwalten. Unbegrenzt Verwenden Sie kubectl oder istioctl.
Zertifizierungsstelle (Certificate Authority, CA) Sie können entweder die Cluster-interne-CA oder die Cloud Service Mesh-Zertifizierungsstelle verwenden, um die von Cloud Service Mesh verwendeten Zertifikate zu verwalten. Wenn Sie die clusterinterne Zertifizierungsstelle verwenden, hat dies keine Auswirkungen.
Wenn Sie die Cloud Service Mesh-Zertifizierungsstelle verwenden, laufen Zertifikate nach 24 Stunden ab. Neue Dienstinstanzen können keine Zertifikate abrufen.		 Unbegrenzt für Cluster-interne-CA.
Eingeschränkter Dienst für 24 Stunden und kein Dienst nach 24 Stunden für die Cloud Service Mesh-Zertifizierungsstelle.		 Verwenden Sie die clusterinterne Zertifizierungsstelle.
Cloud Monitoring für Cloud Service Mesh Sie können Cloud Monitoring verwenden, um HTTP-bezogene Messwerte aus Cloud Service Mesh zu speichern, zu untersuchen und auszunutzen. Messwerte werden nicht gespeichert. Null Verwenden Sie eine kompatible lokale Monitoringlösung, beispielsweise Prometheus.
Audit-Logging von Cloud Service Mesh Cloud Service Mesh benötigt die lokalen Kubernetes-Logging-Funktionen. Das Verhalten hängt davon ab, wie Sie das Logging für Ihren lokalen Cluster konfiguriert haben. Hängt davon ab, wie Sie das Logging für Ihren On-Premise-Cluster konfiguriert haben. - -
Ingress-Gateway Sie können externe IP-Adressen mit dem Istio Ingress Gateway definieren. Keine Auswirkungen Unbegrenzt -
Istio Container Network Interface (CNI) Sie können Cloud Service Mesh so konfigurieren, dass das Istio-CNI anstelle von iptables zur Verwaltung des Traffics verwendet wird. Keine Auswirkungen Unbegrenzt -
Cloud Service Mesh-Endnutzerauthentifizierung für Webanwendungen Sie können das Cloud Service Mesh-Ingress-Gateway verwenden, um Ihren eigenen Identitätsanbieter (über OIDC) zu integrieren, um Endnutzer bei Webanwendungen, die Teil des Mesh-Netzwerks sind, zu authentifizieren und zu autorisieren. Keine Auswirkungen Unbegrenzt -

Andere Netzwerkdienste

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
DNS Der Kubernetes-DNS-Server wird im Cluster ausgeführt. Der Kubernetes DNS-Dienst funktioniert normal, da er im Cluster selbst ausgeführt wird. Unbegrenzt -
Proxy für ausgehender Traffic Sie können Ihre lokalen Cluster so konfigurieren, dass sie einen Proxy für ausgehende Verbindungen verwenden. Wird Ihr Proxy lokal ausgeführt, kann der Cluster ihn während eines temporären Verbindungsverlusts weiterhin verwenden. Wenn der Proxy die Verbindung zu Google Cloudverliert, gelten weiterhin alle Szenarien aus diesem Dokument. Unbegrenzt -

Google Cloud Marketplace

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Anwendungen und Dienste aus Cloud Marketplace bereitstellen und verwalten Der Cloud Marketplace ist in der Console verfügbar. Sie können damit Lösungen ermitteln, erwerben und bereitstellen. Sie können den Cloud Marketplace nicht verwenden. Einige Lösungen aus dem Cloud Marketplace haben möglicherweise eigene Konnektivitätsanforderungen, die hier nicht dokumentiert sind. Null Keine

Support

In diesem Abschnitt werden die Szenarien beschrieben, die Sie bei der Interaktion mit dem Google Cloud -Support oder Ihrem operativen Partner bei einem Supportfall im Zusammenhang mit Ihren GKE on GDC-Clustern durchlaufen müssen.

Funktion Verbundenes Verhalten Verhalten bei vorübergehender Trennung Maximale Toleranz für Trennung Problemumgehung für die Verbindungsunterbrechung
Cluster-Snapshot für das Supportteam freigeben Mit den Befehlen bmctl check cluster oder gkectl diagnose snapshot können Sie lokal einen Cluster-Snapshot erstellen. Sie teilen diesen Snapshot über den normalen Supportprozess. Der Snapshot kann weiterhin generiert werden, da es ein lokaler Vorgang ist. Wenn Sie keinen Zugriff mehr auf Google Cloud und dessen Support-Weboberflächen haben, können Sie das Supportteam telefonisch kontaktieren, sofern Sie die Supportstufen für den erweiterten oder Premiumsupport abonniert haben. Unbegrenzt -
Relevante Logdaten für das Supportteam freigeben Sie können Logs lokal aus Ihrem Cluster erfassen und über den normalen Supportprozess freigeben. Sie können weiterhin Logs aus Ihrem Cluster erfassen. Wenn Sie keinen Zugriff mehr auf Google Cloud und dessen Support-Weboberflächen haben, können Sie das Supportteam telefonisch kontaktieren, sofern Sie die Supportstufen für den erweiterten oder Premiumsupport abonniert haben. Unbegrenzt -