Google Kubernetes Engine (GKE) Enterprise ist die Google Cloud-Plattform zur Modernisierung von Anwendungen. Es basiert auf Kubernetes und kann in Google Cloud, in anderen Clouds und lokal mit Google Distributed Cloud (sowohl auf VMware- als auch auf Bare-Metal-Servern) bereitgestellt werden. Selbst wenn ein von GKE Enterprise verwalteter Cluster lokal ausgeführt wird, ist er 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 passieren wird, 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 Google Distributed Cloud (auf Bare Metal oder 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 Google Distributed Cloud, die von Google Cloud getrennt ist, als Nominalarbeitsmodus verwenden. Denken Sie daran, dass wir GKE Enterprise so gestalten, dass die Skalierbarkeit und Verfügbarkeit von Google Cloud-Diensten genutzt wird. Dieses Dokument berücksichtigt das Design und die Architektur der verschiedenen GKE Enterprise-Komponenten während einer vorübergehenden Unterbrechung. Wir können nicht garantieren, dass dieses Dokument vollständig ist.
In diesem Dokument wird davon ausgegangen, dass Sie mit GKE Enterprise vertraut sind. Wenn dies nicht der Fall ist, empfehlen wir Ihnen, zuerst die technische Übersicht über GKE Enterprise zu lesen.
GKE Enterprise-Lizenzvalidierung und -messung
Wenn Sie GKE Enterprise aktiviert haben, also die Anthos API (anthos.googleapis.com) in Ihrem Google Cloud-Projekt aktiviert ist, generiert der GKE Enterprise-Messwert-Controller, der im Cluster ausgeführt wird, die GKE Enterprise-Berechtigung und aktualisiert sie regelmäßig. Die Toleranz für einen Verbindungsverlust beträgt 12 Stunden. Außerdem werden Messung und Abrechnung über die Verbindung verwaltet.
In dieser Tabelle wird das Verhalten von Features im Zusammenhang mit Lizenzierung und Messung im Falle einer vorübergehenden Trennung von Google Cloud aufgeführt.
| Feature | Verbundenes Verhalten | Verhalten bei vorübergehender Trennung | Maximale Toleranz für Trennung | Problemumgehung für die Verbindungsunterbrechung |
|---|---|---|---|---|
| GKE Enterprise-Lizenzvalidierung | Der GKE Enterprise-Messwert-Controller generiert und aktualisiert die benutzerdefinierte Ressource für die GKE Enterprise-Berechtigung 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. | Derzeit unbegrenzt. Nach Ablauf des Kulanzzeitraums beginnen Komponenten, Fehler zu protokollieren. Sie können Ihren Cluster nicht mehr aktualisieren. | Keine |
| Messung und Abrechnung | Der GKE Enterprise-Messwert-Controller meldet die vCPU-Kapazität des Clusters zu Abrechnungszwecken an die Google Cloud Service Control API. | Es gibt einen clusterinternen Agent, der Abrechnungsdatensätze im Cluster speichert, wenn die Verbindung getrennt ist. Die Datensätze werden abgerufen, sobald der Cluster wieder eine Verbindung zu Google Cloud herstellt. | Unbegrenzt Für die Compliance sind jedoch GKE Enterprise-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 die Google Cloud Console 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 Cloud erforderlich. |
Sie können keine Cluster erstellen. | Null | Keine |
| Cluster-Upgrade | Verwenden Sie die bmctl- oder gkectl-Befehlszeilentools, um Cluster zu aktualisieren. Für diesen Vorgang ist eine Verbindung zu Google Cloud erforderlich. |
Sie können Cluster nicht aktualisieren. | Null | Keine |
| Cluster löschen | Cluster löschen Sie mit den Befehlszeilentools bmctl oder gkectl. Für diesen Vorgang ist keine Verbindung zu Google Cloud erforderlich. |
Sie können Cluster löschen. | Unbegrenzt | - |
| Clusterstatus ansehen | Informationen zu Ihren Clustern finden Sie in der Google Cloud Console in der Liste der Google Kubernetes Engine-Cluster. | In der Google Cloud 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 Cloud besteht. | Die Preflight-Prüfungen, die beim Hinzufügen eines neuen Knotens ausgeführt werden, prüfen, ob eine Verbindung zu Google Cloud besteht. Daher können Sie einem Cluster keinen neuen Knoten hinzufügen, wenn er getrennt ist. | Null | Keine |
Anwendungslebenszyklus
Die Verwaltung von Anwendungen, die in einem lokalen Cluster ausgeführt werden, ist von einer vorübergehenden Trennung von Google Cloud weitgehend nicht betroffen. Sie wirkt sich allerdings auf das Connect Gateway aus. Wenn Sie Container Registry, Artifact Registry, Cloud Build oder Cloud Deploy verwenden, um Container-Images oder CI/CD-Pipelines in Google Cloud zu verwalten, sind diese Elemente während einem Verbindungsverlust nicht 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 | Dies erfolgt 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 verwendet haben, wechseln Sie dazu kubectl lokal zu verwenden. |
| Anwendungen entfernen | Dies erfolgt 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 verwendet haben, wechseln Sie dazu kubectl lokal zu verwenden. |
| Anwendungen horizontal hochskalieren | Dies erfolgt 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 verwendet haben, wechseln Sie dazu kubectl lokal zu verwenden. |
Logging und Monitoring
Die Nachvollziehbarkeit unterstützt Ihre Organisation bei der Einhaltung gesetzlicher Vorschriften und Compliance-Richtlinien. GKE Enterprise 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 GKE Enterprise eine direkte Einbindung in Dienste wie Prometheus, Elastic, Splunk oder Datadog. In diesem Modus hat eine vorübergehende Trennung von Google Cloud keine Auswirkungen auf die Logging- oder Monitoring-Funktionalität.
| Feature | Verbundenes Verhalten | Verhalten bei vorübergehender Trennung | Maximale Toleranz für Trennung | Problemumgehung für die Verbindungsunterbrechung |
|---|---|---|---|---|
| Anwendungs-Logging mithilfe Cloud Logging | Logs werden in Cloud Logging geschrieben. | Messwerte werden auf dem lokalen Laufwerk zwischengespeichert. | 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 | Logs werden in Cloud Logging geschrieben. | Messwerte werden auf dem lokalen Laufwerk zwischengespeichert. | 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 | Logs werden in Cloud Logging geschrieben. | Messwerte werden auf dem lokalen Laufwerk zwischengespeichert. | 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 | Die Messwerte werden in Cloud Monitoring geschrieben. | 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 Google Cloud 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. Benachrichtigungen können über verschiedene Kanäle gesendet werden. | Benachrichtigungen werden nicht ausgelöst, wenn die Verbindung getrennt ist. Benachrichtigungen werden nur durch Messwertdaten ausgelöst, 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 sie werden automatisch mit Ihren Clustern synchronisiert.
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 den Tools gcloud oder kubectl 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 Google Cloud-Befehlszeile oder der Google Cloud Console ändern, werden sie während der Trennung nicht auf den Cluster angewendet. Sie können sie vorübergehend lokal mit kubectl überschreiben. Alle lokalen Änderungen werden beim erneuten Verbinden ü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 gcloud oder in der Google Cloud Console ändern, werden sie während der Trennung nicht auf den Cluster angewendet. Sie können sie vorübergehend lokal mit kubectl überschreiben. Alle lokalen Änderungen werden beim erneuten Verbinden überschrieben. |
Unbegrenzt | Verwenden Sie niemals die Fleet API für Config Sync. Konfigurieren Sie sie nur mit der 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 Cloud API. | Richtlinienerzwingungen sind davon nicht betroffen. 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. Alle lokalen Änderungen werden beim erneuten Verbinden überschrieben. | Unbegrenzt | Verwenden Sie niemals die Fleet API für Policy Controller und konfigurieren Sie sie nur mit der Kubernetes API. |
| Config Sync mit der Google Cloud API 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 gcloud oder die Google Cloud 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 mit der Kubernetes API. |
| System- oder Synchronisierungsstatus in der Google Cloud Console ansehen | Sie können den Status und den Synchronisierungsstatus clusterinterner Agents mit einer Google Cloud API oder der Google Cloud Console ansehen. | Statusinformationen in der Google Cloud API oder der Google Cloud 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
Identität, Authentifizierung und Autorisierung
GKE Enterprise 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. Im Falle einer Trennung von Google Cloud wird gleichzeitig die Verbindung zu Cloud Identity auch getrennt. Dessen Features sind dann nicht mehr verfügbar. Für Arbeitslasten, die während einer vorübergehende 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.
| Feature | 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 Gateway | Sie können auf GKE Enterprise-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-Befehlszeile für die erste Anmeldung. Für OIDC-Anbieter können Sie sich mit der Google Cloud 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 Google Cloud Console anmelden. Sie können die OIDC- oder LDAP-Konfiguration Ihrer Cluster nur lokal aktualisieren, nicht die Google Cloud Console verwenden. | Unbegrenzt | - |
| Autorisierung | GKE Enterprise unterstützt die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC). Rollen können Nutzern, Gruppen oder Dienstkonten zugeordnet werden. Nutzeridentitäten und Gruppen können vom Identitätsanbieter abgerufen werden. | 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 GKE Enterprise bei einer Trennung von Google Cloud hängt davon ab, welchen Dienst Sie für diese Features verwenden.
| Feature | 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 Anthos-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
Load-Balancing
Wenn Sie Kubernetes-Services, die in einem lokalen Cluster gehostet werden, für Nutzer verfügbar machen möchten, können Sie den bereitgestellten gebündelten Load-Balancer (MetalLB auf Bare-Metal, Seesaw oder MetalLB auf VMware) oder Ihren Load-Balancer außerhalb von GKE Enterprise verwenden. Beide Optionen funktionieren auch, wenn die Verbindung zu Google Cloud getrennt wurde.
| Feature | 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 von Google 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 in Google Distributed Cloud unterstützt. Weitere Informationen finden Sie in der Liste der unterstützten Funktionen.
| Feature | 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 Google Cloud 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 für 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 GKE Enterprise-Cluster konfiguriert haben. | Hängt davon ab, wie Sie das Logging für Ihren GKE Enterprise-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
| Feature | 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 GKE Enterprise für die Verwendung eines Proxys für ausgehende Verbindungen konfigurieren. | Wird Ihr Proxy lokal ausgeführt, kann GKE Enterprise ihn während eines temporären Verbindungsverlusts weiterhin verwenden. Wenn der Proxy die Verbindung zu Google Cloud verliert, gelten weiterhin alle Szenarien aus diesem Dokument. | Unbegrenzt | - |
Google Cloud Marketplace
| Feature | 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 Google Cloud 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.
| Feature | 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 | - |