Mit Distributed Cloud (nur Software) für VMware können Sie Google Kubernetes Engine (GKE)-Cluster in einer VMware vSphere-Umgebung bereitstellen und verwalten. Sie können containerisierte Anwendungen in Ihrem Rechenzentrum ausführen und aktualisieren und dabei die Funktionen und die Infrastruktur von Google Cloud nutzen.
Informationen zum Ausführen von reinen Softwareclustern direkt auf physischen Servern finden Sie in der Übersicht über Distributed Cloud (nur Software) für Bare Metal.
Warum Distributed Cloud (nur Software) für VMware verwenden?
Wenn Sie die Distributed Cloud-Software nur für VMware auf Ihrer vorhandenen vSphere-Infrastruktur ausführen, können Sie Anwendungen mit GKE modernisieren und gleichzeitig die Virtualisierungsplattform, den Speicher und die Betriebsprozesse beibehalten, die Ihre Teams bereits verwenden.
Einbindung in Ihre vSphere-Umgebung
Google Distributed Cloud führt Clusterknoten als virtuelle Maschinen in Ihrer vorhandenen vCenter-Umgebung aus. So können Sie containerisierte Arbeitslasten zu den vSphere-Hosts hinzufügen, die Sie bereits betreiben. Cluster speichern Daten in vSphere-Datenspeichern, die von vSAN, VMFS oder NFS unterstützt werden. Sie können einzelnen Knotenpools verschiedene Datenspeicher zuweisen. Der vSphere-CSI-Treiber (Container Storage Interface) stellt nichtflüchtige Volumes für zustandsorientierte Arbeitslasten bereit. Weitere Informationen finden Sie unter Speicher.
Zentrale Verwaltung mit lokalen Daten
Verwalten, überwachen und beheben Sie Fehler in Clustern über die Google Cloud Console, die Google Cloud CLI oder Terraform mithilfe der GKE On-Prem API, ohne sich auf der Administrator-Workstation anzumelden. Ihre Anwendungen und Geschäftsdaten verbleiben in Ihrem Rechenzentrum. Google Cloud erhält nur Clustermetadaten, Informationen zum Zustand und Nutzungsinformationen. Weitere Informationen finden Sie unter Daten, die in Ihrem Rechenzentrum verbleiben.
Zuverlässigkeit und Betrieb für Unternehmen
Google Distributed Cloud umfasst produktionsreife Betriebsfunktionen:
- Hochverfügbarkeit: Hochverfügbare Administratorcluster und Steuerungsebenen von Nutzerclustern verwenden drei Knoten der Steuerungsebene, sodass Sie Ihre Umgebung auch dann verwalten können, wenn ein Knoten ausfällt.
- Automatische Knotenreparatur: Bei regelmäßigen Systemdiagnosen werden fehlerhafte Knoten erkannt und durch die automatische Knotenreparatur automatisch repariert. Dieses Feature ist standardmäßig aktiviert.
- Cluster-Autoscaling: Der Cluster-Autoscaler fügt Knoten in einem Knotenpool hinzu oder entfernt sie, basierend auf den Ressourcenanfragen Ihrer Arbeitslasten.
- Flexibles Load Balancing: Verwenden Sie den gebündelten MetalLB-Load-Balancer, der auf Ihren Clusterknoten ausgeführt wird, oder konfigurieren Sie einen Load Balancer eines Drittanbieters wie F5 BIG-IP oder Citrix. Weitere Informationen finden Sie unter Load Balancing – Übersicht.
Funktionsweise
Google Distributed Cloud erweitert die GKE, sodass Sie Cluster auf physischen Servern in einer vSphere-Umgebung erstellen können. Sie verwalten diese lokalen Cluster in Google Cloud zusammen mit cloudbasierten Clustern als Teil einer einheitlichen Flotte.
In GKE-Clustern, die in Google Cloudausgeführt werden, verwaltet Google die Kubernetes-Steuerungsebene und die Netzwerkinfrastruktur. Für Google Distributed Cloud-Cluster, die in Ihrem Rechenzentrum ausgeführt werden, stellt Google Cloud Administrator- und Steuerungsebenensoftware bereit, die im Rahmen der Installations- und Upgradeprozesse heruntergeladen und auf Ihren vSphere-VMs bereitgestellt wird.
Das folgende Diagramm zeigt die Architektur einer abgeschlossenen Installation mit einem Administratorcluster und einem Nutzercluster:
Schlüsselkomponenten
Die folgenden Komponenten bilden eine reine Softwareinstallation von Distributed Cloud für VMware:
- Administratorcluster: Verwaltet einen oder mehrere Nutzercluster. Administratorcluster bestehen aus einem oder mehreren Knoten der Steuerungsebene, die auf dedizierten virtuellen Maschinen ausgeführt werden.
- Nutzercluster: Führt Ihre containerisierten Arbeitslasten aus. Jeder Nutzercluster besteht aus mindestens einem Knoten der Steuerungsebene und einem oder mehreren Worker-Knoten.
- Administrator-Workstation: Eine dedizierte virtuelle Maschine, die Clusterkonfigurationsdateien und Verwaltungstools enthält:
gkectl: Erstellt, aktualisiert und verwaltet Clusterbereitstellungen.kubectl: Interagiert mit Administrator- und Nutzerclustern, um Arbeitslasten zu verwalten.
- Google Cloud -Console: Eine Weboberfläche in Google Cloud , mit der Sie den Clusterzustand einsehen und Lebenszyklusvorgänge ausführen können, ohne sich bei der Administrator-Workstation anzumelden.
- Virtuelle IP-Adressen (VIPs): Virtuelle IP-Adressen, die während der Installation konfiguriert werden.
Clusteradministratoren und ‑entwickler verwenden
kubectlund VIPs der Steuerungsebene, um auf Steuerungsebenen in Administrator- und Nutzerclustern zuzugreifen. Anwendungsnutzer und ‑entwickler verwenden Dienst- und Ingress-VIPs, um jeweils auf Arbeitslasten zuzugreifen und sie bereitzustellen. Weitere Informationen finden Sie unter IP-Adressen planen.
Verbindung zur Flotte herstellen
Alle Nutzercluster sind Mitglieder einer Flotte, einer logischen Gruppierung von Kubernetes-Clustern, die eine einheitliche Verwaltung über Umgebungen hinweg ermöglicht. Mit Flotten können Sie Cluster in der Google Cloud Console gemeinsam ansehen und flottenfähige Funktionen verwenden, um Arbeitslasten im großen Maßstab zu verwalten, zu steuern und auszuführen.
Jeder Cluster stellt über den Connect-Agent, der automatisch während der Clusterinstallation bereitgestellt wird, eine Verbindung zu Google Cloud her. Die Fleet-Mitgliedschaft bestimmt auch die Abrechnung für Distributed Cloud (nur Software) für VMware.
Preise
Lokale Cluster, die mit Google Distributed Cloud erstellt wurden, werden pro vCPU abgerechnet. Aktivieren Sie die Anthos API in Ihrem Google Cloud-Projekt, um die Abrechnung zu aktivieren.
Ausführliche Preisinformationen, einschließlich Informationen dazu, wie Sie sich an den Vertrieb wenden, finden Sie unter Google Kubernetes Engine-Preise.
Versionen
Diese Dokumentation deckt alle unterstützten Versionen von Google Distributed Cloud ab. Gegebenenfalls finden Sie in dieser Dokumentation auch begrenzte Informationen zu älteren, nicht mehr unterstützten Versionen.
Informationen zu unterstützten Versionen und Release-Richtlinien finden Sie in den folgenden Ressourcen:
- Versionsunterstützungsrichtlinie: Wartungspläne und Supportzeiträume.
- Versionsverwaltung: Unterstützte Nebenversionen und verfügbare Patches.
Ab Version 1.29 wird für die vorherige Nebenversion kein Verzeichnis mehr erstellt. Unterschiede im Verhalten werden in der Dokumentation erwähnt. Wenn eine neue Funktion verfügbar wird, wird auch die unterstützte Version für die Funktion dokumentiert.
Die Dokumentation für Version 1.16 und niedriger ist hier archiviert:
https://cloud.google.com/anthos/clusters/docs/on-prem/VERSION/
Ersetzen Sie VERSION durch eine Nebenversion von 1.0 bis 1.16 und kopieren Sie die URL in die Adressleiste Ihres Browsers.
Wo deine Daten gespeichert werden
Wenn Sie die Distributed Cloud-Software nur für VMware ausführen, bleiben Ihre Cluster, Anwendungen und Geschäftsdaten in Ihrem Rechenzentrum. Standardmäßig sendet Google Distributed Cloud Google Cloud Informationen zu Ihren Clustern, z. B. zu deren Einstellungen, Zustand und Nutzung, aber keine Anwendungsdaten.
Daten, die in Ihrem Rechenzentrum verbleiben
Die folgenden Daten verbleiben in Ihrem Rechenzentrum:
- Container, Pods, PersistentVolumes und die Daten, die Ihre Anwendungen verarbeiten.
- Alle Kubernetes-Objekte werden in der Steuerungsebene und der
etcd-Datenbank gespeichert. - Auf der Steuerungsebene des Administratorclusters werden selbst signierte
etcdprivate Schlüssel, Nutzerclusterschlüssel und Cluster-Zertifizierungsstellen (CAs) gespeichert. - Anwendungs-Secrets, OAuth-Tokens, private SSH-Schlüssel, Container Registry-Anmeldedaten, vCenter- und F5 BIG-IP-Anmeldedaten sowie Dienstkontoschlüsseldateien, die in
etcdoder auf Ihrer Administrator-Workstation gespeichert sind. Sie werden nicht an die GKE On-Prem API gesendet und aus Diagnose-Snapshots entfernt. - Die Konfigurationsdateien für Administratorcluster, Nutzercluster und Anmeldedaten werden auf Ihrer Administrator-Workstation gespeichert.
- Audit-Logs werden auf den Knoten der Steuerungsebene des Administratorclusters und auf Nutzerclustern auf das Laufwerk geschrieben.
- Sie können Diagnosesnapshots in Cloud Storage hochladen.
Daten, die an Google Cloudgesendet werden
In der folgenden Tabelle sehen Sie, was gesendet wird, wie es verwendet und gespeichert wird und ob Sie es deaktivieren können:
| Daten | Welche Daten werden gesendet? | Verwendung und Lagerung | Standard |
|---|---|---|---|
| Verbindung und Flottenregistrierung ( gkehub.googleapis.com,
gkeconnect.googleapis.com) |
|
Cluster über dieGoogle Cloud -Konsole, das Connect-Gateway und die Flotte mit dem Connect-Agent verwalten. Ihr kube-apiserver authentifiziert, autorisiert und protokolliert jede Anfrage. |
Erforderlich |
| Clustereinstellungen und -status ( gkeonprem.googleapis.com) |
|
Ermöglicht die Verwaltung von Clustern mit der Google Cloud Console, der Google Cloud CLI oder Terraform. Die GKE On-Prem API speichert diese Daten in der Region, die in gkeOnPremAPI.location festgelegt ist. |
Ein in Version 1.16 und höher, wenn die GKE On-Prem API in Ihrem Google Cloud -Projekt aktiviert ist. Wenn Sie die Funktion deaktivieren möchten, setzen Sie gkeOnPremAPI.enabled auf false. |
| Abrechnungsnutzung ( anthos.googleapis.com) |
vCPU-Kapazität, Knotenanzahl und Lizenzberechtigungsstatus. | Wird für Messung, Abrechnung und Lizenzprüfungen verwendet. | Erforderlich. Abrechnungsdatensätze werden während eines Ausfalls zwischengespeichert und später gesendet. |
| Systemzustandsdaten ( logging.googleapis.com, monitoring.googleapis.com,
opsconfigmonitoring.googleapis.com) |
|
Wird für Cloud Monitoring, Google Cloud -Konsolenstatusansichten und die Fehlerbehebung durch den Kundenservice verwendet. Wird im Projekt Google Cloud gespeichert, das in stackdriver.projectID festgelegt ist. Messwerte werden in der Region stackdriver.clusterLocation gespeichert und Logs folgen Ihren Logrouter-Einstellungen. |
Ein für Systemprotokolle und -messwerte, die für den vollständigen Customer Care-Support und die SLA-Abdeckung erforderlich sind. Aus für Anwendungslogs und -messwerte, es sei denn, Sie setzen in der Ressource Stackdriver die Option enableCloudLoggingForApplications oder enableGMPForApplications auf true. |
| Audit-Logs ( anthosaudit.googleapis.com) |
Audit-Logs zur Administratoraktivität: Wer hat was wann über die kube-apiserver geändert? Die Einträge enthalten die Uhrzeit, den Cluster, den Host oder die VM, das Nutzer- oder Dienstkonto, die RBAC-Rolle, den Vorgang und das Ergebnis. Leseanfragen werden nicht aufgezeichnet. |
Werden in Cloud-Audit-Logs im Projekt Google Cloud gespeichert, das in cloudAuditLogging.projectID festgelegt ist, im Bucket _Required, und 400 Tage lang aufbewahrt. |
Optional: Füllen Sie zur Aktivierung den Abschnitt cloudAuditLogging aus. Bei Administratorclustern können Sie sie nur beim Erstellen aktivieren. Wenn Sie die Funktion für einen Nutzercluster deaktivieren möchten, löschen Sie den Abschnitt und aktualisieren Sie den Cluster. |
Nächste Schritte
- Informationen zum Starten einer minimalen Proof of Concept-Installation finden Sie unter Minimale Infrastruktur einrichten.
- Informationen zum Planen einer Produktionsbereitstellung finden Sie in der Installationsübersicht.