Auf dieser Seite wird beschrieben, wie Google Distributed Cloud funktioniert. Dazu gehören Informationen zur Infrastruktur, Hardware, Speicherung und Netzwerkfunktionen.
Google Distributed Cloud besteht aus den folgenden Komponenten:
- Die Distributed Cloud-Infrastruktur. Google stellt die Distributed Cloud-Hardware bereit, stellt sie bereit und wartet sie. Dazu gehört auch die Remote-Verwaltung durch ein spezielles Google-Team.
- Der Distributed Cloud-Dienst. Mit diesem Dienst können Sie Ihre Distributed Cloud-Cluster und Knotenpools über die Google Cloud CLI und die Distributed Cloud Edge Container API verwalten.
Die Distributed Cloud-Cluster sind in Ihrer Flotte registriert und Sie können mit dem Kubernetes-CLI-Tool
kubectlmit ihnen interagieren.
Distributed Cloud-Infrastruktur
Google stellt ein Rack mit dedizierter Hardware bereit, stellt es bereit, betreibt es und wartet es, auf dem Ihre Distributed Cloud-Zone ausgeführt wird. Diese Hardware besteht aus in Racks montierten Servern und zwei ToR-Switches (Top-of-Rack), die die Server mit Ihrem lokalen Netzwerk verbinden. Die Distributed Cloud-Knoten, auf denen Ihre Arbeitslasten ausgeführt werden, werden ausschließlich auf dieser Hardware ausgeführt.
Auf der Hardware werden mehrere Knoten ausgeführt, die in Knotenpools gruppiert sind. Sie können diese Knotenpools Clustern in Ihrer Distributed Cloud-Zone zuweisen. Sie können Ihr Netzwerk so konfigurieren, dass Arbeitslasten, die in Distributed Cloud-Clustern ausgeführt werden, nur für Ihre lokalen Nutzer verfügbar oder über das Internet zugänglich sind. Sie können Ihr Netzwerk auch so konfigurieren, dass nur Distributed Cloud-Knoten lokale Ressourcen verwenden oder mit Arbeitslasten wie Compute Engine-VM-Instanzen und Kubernetes-Pods kommunizieren dürfen, die in einem VPC-Netzwerk (Virtual Private Cloud) über eine sichere Cloud VPN-Netzwerkverbindung zu einem VPC-Netzwerk ausgeführt werden.
Verwaltung der Distributed Cloud
Distributed Cloud-Knoten sind keine eigenständigen Ressourcen und müssen zur Verwaltung und Überwachung der Steuerungsebene mit Google Cloud verbunden bleiben. Die Knoten der Distributed Cloud-Steuerungsebene werden in der angegebenen Google Cloud -Region gehostet. Die lokalen Distributed Cloud-Knoten erfordern eine ständige Netzwerkverbindung zu Google Cloud.
Google verwaltet die physischen Maschinen und ToR-Switches, aus denen Ihre Distributed Cloud-Installation besteht, per Fernzugriff. Dazu gehören die Installation von Softwareupdates und Sicherheitspatches sowie die Behebung von Konfigurationsproblemen. Ihr Netzwerkadministrator kann auch den Zustand und die Leistung von Distributed Cloud-Clustern und ‑Knoten überwachen und mit Google zusammenarbeiten, um Probleme zu beheben.
Nachdem Google die Distributed Cloud-Hardware an Ihrem angegebenen Standort bereitgestellt hat, kann Ihr Clusteradministrator mit der Konfiguration des Distributed Cloud-Clusters beginnen. Das ist ähnlich wie bei einem herkömmlichen Kubernetes-Cluster. Sie können Maschinen Knotenpools und Knotenpools Clustern zuweisen und Anwendungsinhabern Zugriff gewähren, wie es für ihre Rollen erforderlich ist. Der Clusteradministrator muss jedoch die Verarbeitungs- und Speicherbeschränkungen der Maschinen in Ihrem Distributed Cloud-Rack berücksichtigen und die Cluster- und Arbeitslastkonfiguration entsprechend planen.
Distributed Cloud bietet eine API zum Konfigurieren von Clustern und Knotenpools.
Zugriff auf die Distributed Cloud-Zone
Sie können Ihr Netzwerk so konfigurieren, dass der gewünschte Zugriff auf Ihre Distributed Cloud-Zone sowohl von Ihrem lokalen Netzwerk als auch über das Internet möglich ist.
Sie können Ihrer Distributed Cloud-Zone auch Zugriff aufGoogle Cloud -Dienste gewähren, indem Sie sie mit Ihrem VPC-Netzwerk verbinden. Distributed Cloud verwendet Cloud VPN, um eine Verbindung zu Google-Dienstendpunkten herzustellen. Ihr Netzwerkadministrator muss Ihr Netzwerk so konfigurieren, dass dies möglich ist.
Distributed Cloud-Rollen
Die folgenden Rollen sind an der Bereitstellung und dem Betrieb Ihrer Distributed Cloud-Zone beteiligt:
Google-Außendiensttechniker Liefert, installiert und aktiviert die Distributed Cloud-Hardware an Ihrem angegebenen Standort. Ihr Netzwerkadministrator arbeitet mit den Google-Technikern zusammen, um die Hardware an Ihre Stromquelle und Ihr Netzwerk anzuschließen.
Google Site Reliability Engineer (SRE) Überwacht und verwaltet die Distributed Cloud-Hardware. Dazu gehören das Beheben von Konfigurationsproblemen, das Installieren von Patches und Updates sowie die Aufrechterhaltung der Sicherheit.
Netzwerkadministrator: Konfiguriert und verwaltet die Netzwerkverbindung und Zugriffssteuerung zwischen der Distributed Cloud-Hardware und Ihrem lokalen Netzwerk. Dazu gehört die Konfiguration Ihrer Routing- und Firewallregeln, um sicherzustellen, dass alle erforderlichen Arten von Netzwerkverkehr frei zwischen der Distributed Cloud-Hardware, Google Cloud, den Clients, die Ihre Distributed Cloud-Arbeitslasten nutzen, internen und externen Daten-Repositories usw. fließen können. Der Netzwerkadministrator muss Zugriff auf die Google Cloud Console haben, um den Status Ihrer Distributed Cloud-Maschinen zu überwachen. Der Netzwerkadministrator konfiguriert auch Distributed Cloud-Netzwerkfunktionen.
Clusteradministrator. Stellt Distributed Cloud-Cluster in Ihrer Organisation bereit und verwaltet sie. Dazu gehört das Konfigurieren von Berechtigungen, Logging und Bereitstellen von Arbeitslasten für jeden Cluster. Der Clusteradministrator weist Knoten Knotenpools und Knotenpools Distributed Cloud-Clustern zu. Der Clusteradministrator muss die betrieblichen Unterschiede zwischen dem Distributed Cloud-Cluster und einem herkömmlichen Kubernetes-Cluster kennen, z. B. die Verarbeitungs- und Speicherfunktionen der Distributed Cloud-Hardware, um Ihre Arbeitslasten richtig zu konfigurieren und bereitzustellen.
Anwendungsinhaber: Ein Softwareentwickler, der für die Entwicklung und/oder Bereitstellung und Überwachung einer Anwendung verantwortlich ist, die in einem Distributed Cloud-Cluster ausgeführt wird. Anwendungsbesitzer, die Anwendungen in einem Distributed Cloud-Cluster besitzen, müssen die Einschränkungen hinsichtlich der Größe und des Standorts der Cluster sowie die Auswirkungen der Bereitstellung einer Anwendung am Edge, z. B. Leistung und Latenz, kennen.
Distributed Cloud-Hardware
Abbildung 1 zeigt eine typische Distributed Cloud-Konfiguration.
Die Komponenten einer Distributed Cloud-Installation sind:
Google Cloud: Der Traffic zwischen Ihrer Distributed Cloud-Installation und Google Cloud umfasst Hardwareverwaltungs-Traffic, Traffic der Steuerungsebene und Cloud VPN-Traffic zu Google Cloud-Diensten und allen Arbeitslasten, die Sie dort ausführen. Bei Bedarf kann auch VPC-Traffic enthalten sein.
Internet Verschlüsselter Management- und Steuerungsebenen-Traffic zwischen Ihrer Distributed Cloud-Installation und Google Cloud, der über das Internet übertragen wird. Proxied-Internetverbindungen werden von Distributed Cloud nicht unterstützt.
Lokales Netzwerk: Das lokale Netzwerk außerhalb des Distributed Cloud-Racks, das die Peering-Edge-Router mit dem Internet verbindet.
Peering-Edge-Router Ihre lokalen Netzwerkrouter, die mit den ToR-Switches von Distributed Cloud verbunden sind. Je nach dem physischen Standort, den Sie für Ihre Distributed Cloud-Installation auswählen, können die Peering-Edge-Router Ihrer Organisation oder Ihrem Colocation-Anbieter gehören und von diesen gewartet werden. Sie müssen diese Router so konfigurieren, dass sie das Border Gateway Protocol (BGP) für das Peering mit den ToR-Switches verwenden und eine Standardroute für Ihre Distributed Cloud-Hardware bewerben. Sie müssen diese Router sowie alle entsprechenden Firewalls so konfigurieren, dass der Traffic für die Geräteverwaltung von Google, der Traffic für die Distributed Cloud-Steuerungsebene und gegebenenfalls der Cloud VPN-Traffic zugelassen werden.
Je nach Ihren geschäftlichen Anforderungen können Sie diese Router so konfigurieren:
- Ermöglichen Sie den Zugriff Ihrer Distributed Cloud-Knoten auf das Internet über öffentliches NAT (Network Address Translation) oder die direkte Bereitstellung öffentlicher IP-Adressen.
- Erlauben Sie eine VPN-Verbindung zu Ihrem VPC-Netzwerk und allen gewünschtenGoogle Cloud -Diensten.
Top-of-Rack-Switches (ToR-Switches): Die Layer-3-Switches, die die Maschinen im Rack verbinden und eine Schnittstelle zu Ihrem lokalen Netzwerk bilden. Diese Switches sind BGP-Speaker und verarbeiten den Netzwerkverkehr zwischen dem Distributed Cloud-Rack und Ihrer lokalen Netzwerkausrüstung. Sie stellen über LACP-Bundles (Link Aggregation Control Protocol) eine Verbindung zu Peering-Edge-Routern her.
Maschinen: Die physischen Maschinen, auf denen Distributed Cloud-Software ausgeführt wird und auf denen Ihre Arbeitslasten ausgeführt werden. Jede physische Maschine ist ein Knoten im Distributed Cloud-Cluster.
Distributed Cloud-Dienst
Der Distributed Cloud-Dienst wird auf Google Cloud ausgeführt und dient als Steuerungsebene für die Knoten und Cluster, die auf Ihrer Distributed Cloud-Hardware ausgeführt werden. Distributed Cloud muss jederzeit eine Verbindung zuGoogle Cloud herstellen können und kann ohne diese Verbindung nicht funktionieren.
Diese Steuerungsebene instanziiert und konfiguriert Ihre Distributed Cloud-Zone. Das spezifische Google-Rechenzentrum, mit dem Ihre Distributed Cloud-Hardware zur Verwaltung verbunden wird, wird entsprechend seiner Nähe zu Ihrer Distributed Cloud-Installation ausgewählt.
Eine Distributed Cloud-Zone besteht aus mehreren Maschinen, die der Anzahl der physischen Maschinen entsprechen, die in Ihrem Distributed Cloud-Rack installiert sind. Sie können diese als Kubernetes-Knoten instanziierten Maschinen einem Knotenpool und den Knotenpool einem Distributed Cloud-Cluster zuweisen.
Abbildung 2 zeigt die logische Organisation von Distributed Cloud-Entitäten.
Die Entitäten sind:
Google Cloud region Die Google Cloud -Region für Ihre Distributed Cloud-Zone wird durch den Standort des Google-Rechenzentrums bestimmt, das Ihrer Distributed Cloud-Installation am nächsten ist.
Kubernetes-Cloud-Steuerungsebene: Die Kubernetes-Steuerungsebene für jeden Distributed Cloud-Cluster wird standardmäßig remote in einem Google-Rechenzentrum in der Google Cloud -Region ausgeführt, der Ihr Distributed Cloud-Cluster zugewiesen ist. So kann Distributed Cloud von einer sicheren und hochverfügbaren Steuerungsebene profitieren, ohne dass Verarbeitungskapazität auf den physischen Distributed Cloud-Maschinen beansprucht wird.
Lokale Kubernetes-Steuerungsebene: Ab Google Distributed Cloud-Version 1.5.0 können Sie einen Distributed Cloud-Cluster so konfigurieren, dass er eine lokale Steuerungsebene anstelle der standardmäßigen Cloud-Steuerungsebene verwendet. Ein lokaler Steuerungsebenencluster kann in den Notfallbetrieb wechseln, wenn die Verbindung zuGoogle Cloud vorübergehend unterbrochen wird. So können Ihre Arbeitslasten weiter ausgeführt werden, bis die Verbindung wiederhergestellt ist. Weitere Informationen finden Sie unter Überlebensmodus.
Distributed Cloud-Zone: Eine logische Abstraktion, die die in Ihrem Distributed Cloud-Rack installierte Distributed Cloud-Hardware darstellt. Eine Distributed Cloud-Zone umfasst ein einzelnes Rack mit Distributed Cloud-Hardware. Die physischen Maschinen in der Zone werden als Distributed Cloud-Maschinen in der Google Cloud Console instanziiert. Die Geräte in einer Distributed Cloud-Zone nutzen dieselbe Netzwerkstruktur oder Fehlerdomain. Google erstellt Ihre Maschinen, bevor die Distributed Cloud-Hardware geliefert wird. Sie können keine Distributed Cloud-Maschinen erstellen, löschen oder ändern.
angezeigt.Knoten: Ein Knoten ist eine Kubernetes-Ressource, die eine physische Maschine von Distributed Cloud in der Kubernetes-Umgebung instanziiert, wenn Sie einen Knotenpool erstellen. Dadurch wird sie für die Ausführung von Arbeitslasten verfügbar, indem Sie den Knotenpool einem Distributed Cloud-Cluster zuweisen. Die Kubernetes-Steuerungsebene für jeden Knoten wird auf Google Cloudausgeführt.
Knotenpool Eine logische Gruppierung von Distributed Cloud-Knoten in einer einzelnen Distributed Cloud-Zone, mit der Sie Distributed Cloud-Knoten Distributed Cloud-Clustern zuweisen können.
Cluster: Ein Distributed Cloud-Cluster, der aus einer Steuerungsebene und einem oder mehreren Knotenpools besteht.
VPN-Verbindung Ein VPN-Tunnel zu einem VPC-Netzwerk, das in einemGoogle Cloud -Projekt ausgeführt wird. Über diesen Tunnel können Ihre Distributed Cloud-Arbeitslasten auf Compute Engine-Ressourcen zugreifen, die mit diesem VPC-Netzwerk verbunden sind. Sie müssen mindestens einen Knotenpool in Ihrer Zone erstellen, bevor Sie eine VPN-Verbindung erstellen können.
Speicher
Distributed Cloud bietet 3,3 TiB Speicherplatz pro physischer Maschine im Distributed Cloud-Rack. Dieser Speicher ist als logische Linux-Volumes konfiguriert. Wenn Sie einen Cluster erstellen, erstellt Distributed Cloud ein oder mehrere PersistentVolumes und stellt sie als Block-Volumes zur Verfügung, die Sie einer Arbeitslast mithilfe von PersistentVolumeClaims zuweisen können. Beachten Sie, dass diese PersistentVolumes keine Datenbeständigkeit bieten und nur für kurzlebige Daten geeignet sind. Informationen zum Arbeiten mit Block-Volumes finden Sie unter PersistentVolumeClaim, der ein Raw Block Volume anfordert.
Storage-Sicherheit
Distributed Cloud verwendet LUKS, um den lokalen Maschinenspeicher zu verschlüsseln, und unterstützt kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK). Weitere Informationen finden Sie unter Best Practices für Sicherheit.
Symcloud Storage-Integration
Sie können Distributed Cloud so konfigurieren, dass Rakuten Symcloud Storage verwendet wird. Diese Funktion dient als lokale Speicherabstraktionsebene auf jedem Distributed Cloud-Knoten und stellt den lokalen Speicher für Arbeitslasten zur Verfügung, die auf anderen Distributed Cloud-Knoten ausgeführt werden.
Weitere Informationen finden Sie unter Distributed Cloud für Symcloud Storage konfigurieren.
Netzwerk
In diesem Abschnitt werden die Anforderungen an die Netzwerkverbindung und die Funktionen von Distributed Cloud beschrieben.
Google konfiguriert einige der virtuellen Netzwerkkomponenten von Distributed Cloud für Ihre Installation vor, bevor die Distributed Cloud-Hardware an Sie versendet wird. Sie können die vorkonfigurierten Einstellungen nach der Lieferung der Hardware nicht mehr ändern.
Abbildung 3 zeigt die Topologie des virtuellen Distributed Cloud-Netzwerks.
Die Komponenten des virtuellen Netzwerks von Distributed Cloud sind:
Netzwerk: Ein virtuelles Netzwerk mit einem privaten Adressbereich in Ihrer Distributed Cloud-Zone. Ein Netzwerk ist auf Ebene 3 von anderen virtuellen Netzwerken in der Zone isoliert und kann ein oder mehrere Subnetzwerke enthalten. Das virtuelle Netzwerk umfasst alle physischen Maschinen im Distributed Cloud-Rack. Eine einzelne Distributed Cloud-Zone unterstützt maximal 20 Netzwerke.
Subnetzwerk Ein Layer 2- und Layer 3-VLAN-Subnetzwerk in einem Distributed Cloud-Netzwerk. Ein Subnetz hat eine eigene Broadcast-Domäne und einen oder mehrere IPv4-Adressbereiche Ihrer Wahl. Subnetzwerke innerhalb desselben Netzwerks sind auf Ebene 2 isoliert, können aber über Ebene 3 miteinander kommunizieren. Knoten in verschiedenen Subnetzwerken innerhalb desselben Netzwerks können über ihre IP-Adressen miteinander kommunizieren. Knoten in Subnetzwerken in verschiedenen Netzwerken können jedoch nicht miteinander kommunizieren.
Router: Eine virtuelle Routerinstanz, die den Traffic in einem Distributed Cloud-Netzwerk steuert. Ihr Netzwerkadministrator verwendet einen Router, um eine BGP-Peering-Sitzung über eine Interconnect-Verbindung zwischen einem Distributed Cloud-Netzwerk und Ihrem lokalen Netzwerk zu konfigurieren, damit Distributed Cloud-Pods ihre Netzwerkpräfixe in Ihrem lokalen Netzwerk ankündigen können. Standardmäßig bieten Router die von Distributed Cloud-Subnetzwerken empfangenen Routen noch einmal an. Distributed Cloud unterstützt einen Router pro Netzwerk.
Interconnect Eine gebündelte logische Verbindung zwischen einem Distributed Cloud-Netzwerk und Ihrem lokalen Netzwerk. Eine Interconnect-Verbindung besteht aus einer oder mehreren physischen Verbindungen. Beim ersten Start erstellt Google die Interconnects, die Sie bei der Bestellung von Distributed Cloud angefordert haben. Interconnect-Verbindungen können nicht erstellt, geändert oder entfernt werden, nachdem das Distributed Cloud-Rack in Betrieb ist. Standardmäßig erstellt Google vier Interconnects, um eine hohe Verfügbarkeit für Ihre Installation zu gewährleisten.
Interconnect-Anhang Eine virtuelle Verbindung zwischen einer Interconnect-Verbindung und einem Router, die das entsprechende Distributed Cloud-Netzwerk von Ihrem lokalen Netzwerk isoliert. Traffic, der über einen Interconnect-Anhang übertragen wird, kann entweder ohne Tagging oder mit einer VLAN-ID Ihrer Wahl getaggt werden. Sie erstellen Interconnect-Anhänge basierend auf Ihren Geschäftsanforderungen.
Die Netzwerkkomponenten von Distributed Cloud ähneln ihren Google Cloud Entsprechungen, weisen jedoch die folgenden Unterschiede auf:
Distributed Cloud-Netzwerkkomponenten sind lokal für die Distributed Cloud-Zone, in der sie instanziiert werden.
Ein Distributed Cloud-Netzwerk hat keine direkte Verbindung zu einem VPC-Netzwerk.
Standardmäßig haben Distributed Cloud-Netzwerke keine Verbindung zueinander über verschiedene Distributed Cloud-Zonen hinweg. Sie haben die Möglichkeit, die zonenübergreifende Vernetzung explizit zu konfigurieren.
Ihr Netzwerkadministrator konfiguriert die Distributed Cloud-Netzwerkkomponenten, mit Ausnahme der Interconnects, die von Google konfiguriert werden, bevor die Distributed Cloud-Hardware an Sie versendet wird.
Ihr Netzwerkadministrator muss die Edge Network Admin-Rolle (roles/edgenetwork.admin) für das Zielprojekt Google Cloud haben, während Anwendungsentwickler, die Arbeitslasten in Distributed Cloud bereitstellen, die Edge Network Viewer-Rolle (roles/edgenetwork.viewer) für das Zielprojekt Google Cloud haben müssen.
Verbindung zu Ihrem lokalen Netzwerk
Für ausgehenden Traffic zu Ressourcen in Ihrem lokalen Netzwerk verwenden Pods in einem Distributed Cloud-Cluster die Standardrouten, die von Ihren Peering-Edge-Routern beworben werden. Distributed Cloud verwendet das integrierte NAT, um Pods mit diesen Ressourcen zu verbinden.
Für eingehenden Traffic von Ressourcen in Ihrem lokalen Netzwerk muss Ihr Netzwerkadministrator Routingrichtlinien konfigurieren, die Ihren Geschäftsanforderungen entsprechen, um den Zugriff auf Pods in den einzelnen Distributed Cloud-Clustern zu steuern. Das bedeutet, dass Sie mindestens die Schritte unter Firewallkonfiguration ausführen und zusätzliche Richtlinien konfigurieren müssen, die für Ihre Arbeitslasten erforderlich sind. Sie können beispielsweise Richtlinien zum Zulassen/Verweigern für einzelne Knotensubnetzwerke oder virtuelle IP-Adressen einrichten, die vom integrierten Load Balancer in Distributed Cloud bereitgestellt werden. Die CIDR-Blöcke für Distributed Cloud Pod und Distributed Cloud Service sind nicht direkt zugänglich.
Internetverbindung
Für ausgehenden Traffic zu Ressourcen im Internet verwenden Pods in einem Distributed Cloud-Cluster die Standardroute, die von Ihren Routern an die Distributed Cloud-ToR-Switches (Top-of-Rack) angekündigt wird. Das bedeutet, dass Sie mindestens die Schritte unter Firewallkonfiguration ausführen und zusätzliche Richtlinien konfigurieren müssen, die für Ihre Arbeitslasten erforderlich sind. Distributed Cloud verwendet das integrierte NAT, um Pods mit diesen Ressourcen zu verbinden. Optional können Sie eine eigene NAT-Ebene zusätzlich zur integrierten Ebene in Distributed Cloud konfigurieren.
Für eingehenden Traffic müssen Sie Ihre WAN-Router entsprechend Ihren geschäftlichen Anforderungen konfigurieren. Diese Anforderungen legen fest, welche Zugriffsebene Sie vom öffentlichen Internet auf die Pods in Ihren Distributed Cloud-Clustern bereitstellen müssen. Distributed Cloud verwendet die integrierte NAT für Pod-CIDR-Blöcke und CIDR-Blöcke für die Dienstverwaltung. Diese CIDR-Blöcke sind also nicht über das Internet zugänglich.
Verbindung zu einem VPC-Netzwerk
Distributed Cloud enthält eine integrierte VPN-Lösung, mit der Sie einen Distributed Cloud-Cluster direkt mit einer VPC-Instanz verbinden können, wenn sich diese Instanz im selbenGoogle Cloud -Projekt wie der Distributed Cloud-Cluster befindet.
Wenn Sie Cloud Interconnect verwenden, um Ihr lokales Netzwerk mit einer VPC-Instanz zu verbinden, können Ihre Distributed Cloud-Cluster diese Instanz über das standardmäßige eBGP-Peering in Richtung Norden erreichen. Ihre Peering-Edge-Router müssen die entsprechenden VPC-Präfixe erreichen können und Ihre Cloud Interconnect-Router müssen Ihre Distributed Cloud-Präfixe, z. B. Distributed Cloud-Load-Balancer-, Verwaltungs- und Systemsubnetzwerke, korrekt ankündigen.
Nachdem Sie eine VPN-Verbindung zwischen Ihrem Distributed Cloud-Cluster und Ihrem VPC-Netzwerk hergestellt haben, gelten standardmäßig die folgenden Konnektivitätsregeln:
- Ihr VPC-Netzwerk kann auf alle Pods im Distributed Cloud-Cluster zugreifen.
- Alle Pods im Distributed Cloud-Cluster können auf alle Pods in Ihren VPC-nativen Clustern zugreifen. Bei routenbasierten Clustern müssen Sie benutzerdefinierte beworbene Routen manuell konfigurieren.
- Alle Pods im Distributed Cloud-Cluster können auf VM-Subnetzwerke in Ihrem VPC-Netzwerk zugreifen.
Verbindung zu Google Cloud APIs und ‑Diensten
Nachdem Sie eine VPN-Verbindung zu Ihrem VPC-Netzwerk konfiguriert haben, können auf Ihrer Distributed Cloud-Installation ausgeführte Arbeitslasten auf Google Cloud APIs und -Dienste zugreifen.
Sie können zusätzlich die folgenden Funktionen konfigurieren, wenn dies für Ihr Unternehmen erforderlich ist:
- Privaten Google-Zugriff für den Zugriff auf Google Cloud APIs und -Dienste
- Private Service Connect, um über private Dienstendpunkte auf Google Cloud APIs zuzugreifen
Netzwerksicherheit
Die Schritte, die zum Sichern des Netzwerk-Traffics erforderlich sind, der in Ihre Distributed Cloud-Installation ein- und ausgeht, werden durch Ihre geschäftlichen Anforderungen und die Netzwerksicherheitsrichtlinie Ihrer Organisation bestimmt. Weitere Informationen finden Sie unter Best Practices für Sicherheit.
Weitere Netzwerkfunktionen
Distributed Cloud unterstützt die folgenden Netzwerkfunktionen:
Unterstützung für Hochleistungsnetzwerke
Distributed Cloud unterstützt die Ausführung von Arbeitslasten, die die bestmögliche Netzwerkleistung erfordern. Dazu wird Distributed Cloud mit einem speziellen Network Function-Operator und einer Reihe von Kubernetes-CustomResourceDefinitions (CRDs) ausgeliefert, die die für die Ausführung von Hochleistungsarbeitslasten erforderlichen Funktionen implementieren.
Distributed Cloud unterstützt auch die Virtualisierung von Netzwerkschnittstellen mit SR-IOV.
Unterstützung von VM-Arbeitslasten
In Distributed Cloud können Arbeitslasten nicht nur in Containern, sondern auch in virtuellen Maschinen ausgeführt werden. Weitere Informationen finden Sie unter VMs verwalten.
Informationen dazu, wie virtuelle Maschinen als wesentliche Komponente der Google Distributed Cloud-Plattform dienen, finden Sie unter GKE Enterprise erweitern, um lokale Edge-VMs zu verwalten.
Unterstützung von GPU-Arbeitslasten
In Distributed Cloud können GPU-basierte Arbeitslasten auf NVIDIA Tesla T4-GPUs ausgeführt werden. Sie müssen diese Anforderung bei der Bestellung Ihrer Distributed Cloud-Hardware angeben. Weitere Informationen finden Sie unter GPU-Arbeitslasten verwalten.