Auf dieser Seite finden Sie eine Übersicht über Google Distributed Cloud, einschließlich Informationen dazu, wann es verwendet werden sollte, sowie zu den Einschränkungen und bekannten Problemen.
Mit Distributed Cloud können Sie Google Kubernetes Engine-Cluster (GKE) auf dedizierter Hardware ausführen, die von Google bereitgestellt und gewartet wird und die vom herkömmlichen Google Cloud Rechenzentrum getrennt ist. Google liefert und installiert die Distributed Cloud-Hardware in Ihren Räumlichkeiten.
Das Bereitstellen von Arbeitslasten in einer Distributed Cloud-Installation funktioniert ähnlich wie das Bereitstellen von Arbeitslasten in cloudbasierten GKE-Clustern. Nachdem die Hardware bereitgestellt wurde, stellt der Clusteradministrator Distributed Cloud-Cluster über die Google Cloud Console oder die Google Cloud CLI bereit. Außerdem konfiguriert Ihr Netzwerkadministrator die Distributed Cloud-Netzwerkkomponenten so, dass Ihre Arbeitslasten mit Ihrem lokalen Netzwerk und untereinander kommunizieren können. Die Anwendungsbesitzer können dann Arbeitslasten in diesen Clustern bereitstellen. Distributed Cloud unterstützt die Ausführung von Arbeitslasten in Kubernetes-Containern und auf virtuellen Maschinen, einschließlich GPU-basierter Arbeitslasten, die auf NVIDIA Tesla T4-GPUs ausgeführt werden.
Google überwacht und wartet Ihre Distributed Cloud-Installation aus der Ferne. Dazu gehören die Installation von Softwareupdates und Sicherheitspatches, die Behebung von Konfigurationsproblemen und die Diagnose der Distributed Cloud-Hardware. Wenn ein Problem nicht remote behoben werden kann, müssen Sie autorisierten Google-Mitarbeitern physischen Zugriff auf die Distributed Cloud-Hardware gewähren.
Für Ihre Distributed Cloud-Bereitstellung wird eine sichere Cloud VPN-Verbindung verwendet, um auf Google Cloud Dienste und Ihre Anwendungen zuzugreifen, die in Google Cloud und Ihrem VPC-Netzwerk (Virtual Private Cloud) ausgeführt werden.
Eine technische Übersicht über Distributed Cloud finden Sie unter Funktionsweise von Distributed Cloud.
Wann sollte Distributed Cloud verwendet werden?
Distributed Cloud wurde speziell für die folgenden Szenarien entwickelt, in denen herkömmliche Google Cloud Bereitstellungen möglicherweise nicht ausreichen:
- Ihre Anwendungen benötigen eine sehr stabile Netzwerkverbindung und können potenzielle Verkehrsunterbrechungen, die häufig bei der Datenübertragung über das Internet auftreten, nicht tolerieren.
Ihre Anwendungen erfordern die niedrigstmögliche Netzwerklatenz und reagieren empfindlich auf Latenzspitzen oder Jitter. Distributed Cloud unterstützt auch leistungsstarke Netzwerktechnologien wie Single Root Input/Output Virtualization (SR-IOV) und das Data Plane Development Kit (DPDK) für noch komplexere Szenarien, die den Network Function Operator verwenden.
Ihre Anwendungen generieren große Datenmengen, deren Übertragung zu und vonGoogle Cloudaus Leistungs- oder Kostengründen nicht möglich wäre.
Ihre lokalen Gesetze oder Verordnungen schreiben vor, dass Ihre Daten lokal gespeichert werden müssen und nicht außerhalb Ihres Unternehmens oder außerhalb einer bestimmten geografischen Gerichtsbarkeit gespeichert werden dürfen.
Einschränkungen von Distributed Cloud
Für eine Distributed Cloud-Zone gelten im Vergleich zu einer herkömmlichen cloudbasierten GKE-Zone die folgenden Einschränkungen:
- Verarbeitungskapazität: Im Gegensatz zu einer herkömmlichen cloudbasierten Zone hat Ihre Distributed Cloud-Installation eine begrenzte Verarbeitungskapazität. Berücksichtigen Sie diese Einschränkung bei der Planung und Bereitstellung Ihrer Arbeitslasten.
- Einschränkungen für Arbeitslasten. Distributed Cloud unterliegt mehreren Einschränkungen für Ihre Arbeitslasten.
- GKE Enterprise-Funktionen Distributed Cloud unterstützt keine GKE Enterprise-Funktionen wie Cloud Service Mesh, mit Ausnahme der ConfigSync-Funktion von Config Management.
Bekannte Probleme in dieser Version von Distributed Cloud
Diese Version von Distributed Cloud hat die folgenden bekannten Probleme:
- Eine große Anzahl von Webhook-Aufrufen kann dazu führen, dass der Konnectivity-Proxy vorübergehend ausfällt.
- Die Messwert-Agents, die auf Distributed Cloud-Knoten ausgeführt werden, können einen Rückstand an Ereignissen ansammeln und zum Stillstand kommen, wodurch die Erfassung weiterer Messwerte verhindert wird.
- Die automatische Speicherbereinigung kann beendete Pods nicht immer bereinigen.
- BGP-Sitzungen werden nicht wiederhergestellt, wenn die entsprechende Netzwerkschnittstelle ausfällt und dann wieder aktiv wird.