Übersicht über Distributed Cloud (nur Software) für Bare Metal

Google Distributed Cloud ist eine vollständig verwaltete Software- und Hardwarelösung, mit der Sie die Infrastruktur und Dienste vonGoogle Cloud auf Ihr Rechenzentrum ausweiten können. Google Distributed Cloud ist auch als reine Softwarelösung verfügbar, die auf Ihrer eigenen Hardware ausgeführt wird. Die Google Distributed Cloud-Software kann entweder auf VMware oder auf Bare Metal installiert werden. Dieser Leitfaden gilt für Google Distributed Cloud-Software, die direkt auf Ihren Bare-Metal-Maschinen ausgeführt wird.

Die Software von Google Distributed Cloud basiert auf der Google Kubernetes Engine (GKE) und hat ein eigenes Kubernetes-Paket, das GKE für die Verwendung in einer lokalen Umgebung erweitert. Mit Google Distributed Cloud können Sie GKE-Cluster lokal erstellen, verwalten und aktualisieren und dabeiGoogle Cloud -Funktionen verwenden. Außerdem können Sie Containeranwendungen mithilfe der Google-Infrastruktur in großem Maßstab auf Ihren Clustern bereitstellen und betreiben.

Warum Distributed Cloud (nur Software) für Bare Metal verwenden?

Wenn Sie Distributed Cloud-Software nur für Bare Metal in Ihrer vorhandenen Unternehmensinfrastruktur ausführen, erhalten Sie direkten Hardwarezugriff, Unternehmenssicherheit und zentrale Verwaltung über Umgebungen hinweg.

Direkte Hardwaresteuerung und Leistung

Wenn Sie direkt auf physischen Servern bereitstellen, haben Sie die direkte Kontrolle über Anwendungsskalierung, Latenz und Leistung und können gleichzeitig die Kosten senken, indem Sie Ihre vorhandene Infrastruktur verwenden. Google Distributed Cloud verwaltet die Bereitstellung und Integrität von Anwendungen über Ihre vorhandenen Unternehmensrechenzentren hinweg – für einen effizienteren Betrieb. Sie können Arbeitslasten für spezielle Hardwaretypen wie GPUs und SSDs optimieren und Anwendungen mit niedriger Latenz am Netzwerkrand ohne Hypervisor-Overhead ausführen.

Sicherheit auf Betriebssystemebene

Da Sie die direkte Kontrolle über die Betriebssysteme und Netzwerkkonfigurationen Ihrer Knoten behalten, können Sie die Sicherheitsrichtlinien an Ihre Compliance-Anforderungen anpassen. Cluster kommunizieren über schlanke, sichere Verbindungen mit Google APIs. Dadurch wird die Komplexität virtueller Maschinen eliminiert, während vorhandene Sicherheitskontrollen beibehalten werden.

Zentralisierte Verwaltung und Monitoring

Cluster über dieGoogle Cloud Console mit Cloud Monitoring und dem Connect-Agent verwalten, überwachen und Fehler beheben. Diese zentrale Sichtbarkeit hilft Ihnen, die Zuverlässigkeit aufrechtzuerhalten und die Anwendungsskalierung über verteilte Rechenzentren hinweg anzupassen.

Zuverlässigkeit und Betrieb für Unternehmen

Google Distributed Cloud umfasst produktionsreife Betriebsfunktionen:

  • Hochverfügbarkeit: Die Unterstützung mehrerer Knoten der Steuerungsebene sorgt dafür, dass Sie Ihre Umgebung auch dann verwalten können, wenn ein Knoten ausfällt.
  • Automatisierte Preflight-Prüfungen: Mit der integrierten Validierung können Sie Ihre Hardware- und Betriebssystemkonfigurationen vor der Installation prüfen.
  • Integriertes Load Balancing: Load-Balancing-Mechanismen mit Layer 4 und 7 werden bei der Clustererstellung automatisch bereitgestellt.
  • Datenbankwartung: Durch die automatische Defragmentierung (etcddefrag) wird Speicherplatz freigegeben, um die Integrität und Stabilität von etcd aufrechtzuerhalten.

Funktionsweise

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 Sie herunterladen und auf Ihren physischen Linux-Servern installieren. Sie verwalten diese lokalen Cluster in Google Cloud zusammen mit cloudbasierten Clustern als Teil einer einheitlichen Flotte.

Das folgende Diagramm zeigt die Architektur einer abgeschlossenen Installation mit einem Administratorcluster und einem Nutzercluster:

Grundlegende Architektur für die Bereitstellung eines Administrator- und Nutzerclusters
Google Distributed Cloud-Architektur auf Bare Metal mit einem Administrator- und einem Nutzercluster

Schlüsselkomponenten

Eine reine Software-Bare-Metal-Bereitstellung besteht aus den folgenden Komponenten:

  • Administratorcluster: Verwaltet den Lebenszyklus von Nutzerclustern mithilfe von Kubernetes Resource Management (KRM). Die Standardbereitstellung besteht aus einem Administratorcluster, der den Lebenszyklus eines oder mehrerer Nutzercluster verwaltet. Ein Administratorcluster besteht aus einer oder mehreren physischen Linux-Maschinen, die als Knoten der Steuerungsebene dienen. Jeder Knotencomputer in der Installation hat eine eigene IP-Adresse.
  • Nutzercluster: Führt Ihre containerisierten Arbeitslasten aus. Jeder Nutzercluster besteht aus mindestens einem Knoten der Steuerungsebene und einem Worker-Knoten.
  • Administrator-Workstation: Eine dedizierte Maschine, auf der Konfigurationsdateien und Verwaltungstools gehostet werden:
    • bmctl: Erstellt, aktualisiert und verwaltet Cluster.
    • kubectl: Interagiert mit Administrator- und Nutzerclustern und verwaltet Arbeitslasten.
  • GKE On-Prem API: Die von Google Cloudgehostete API für die Clusterlebenszyklusverwaltung. Mit Clients wie der Google Cloud Console, der Google Cloud CLI und Terraform können Sie lokale Cluster verwalten, ohne sich auf der Administrator-Workstation anmelden zu müssen.
  • Google Cloud Console: Bietet eine Weboberfläche für Ihr Google Cloud-Projekt, einschließlich lokaler Cluster. In der Google Cloud Console werden wichtige Messwerte zu Ihren Clustern angezeigt, mit denen Sie die Clusterintegrität und den Flottenstatus im Blick behalten können.
  • Virtuelle IP-Adressen (VIPs): Virtuelle IP-Adressen, die während der Installation konfiguriert werden. Clusteradministratoren und ‑entwickler verwenden kubectl, um über VIPs der Steuerungsebene auf die Clustersteuerungsebenen zuzugreifen. Anwendungsnutzer und ‑entwickler verwenden Dienst- und Ingress-VIPs, um jeweils auf Arbeitslasten zuzugreifen und sie bereitzustellen.

Verbindung zur Flotte herstellen

Nutzercluster und optional Administratorcluster werden in einer Flotte registriert. Eine Flotte ist eine logische Gruppierung von Kubernetes-Clustern, die eine einheitliche Verwaltung über Umgebungen hinweg ermöglicht. Mit Flotten können Sie die Verwaltung von einzelnen Clustern bis hin zu ganzen Clustergruppen optimieren und Ihren Teams helfen, ähnliche Best Practices wie bei Google anzuwenden. Sie können Cluster in derGoogle 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 Flottenmitgliedschaft bestimmt auch die Abrechnung für Google Distributed Cloud.

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.

Preisdetails und Kontaktdaten für den Vertrieb finden Sie unter Google Kubernetes Engine-Preise.

Versionen

Weitere Informationen zu Google Distributed Cloud-Versionen finden Sie in der Richtlinie für die Versionsunterstützung.

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. Versionsspezifische Unterschiede bei Anforderungen und 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.

Eine Liste der unterstützten Nebenversionen und verfügbaren Patches finden Sie unter Versionsverwaltung.

Ab Version 1.29 wird für die Dokumentation der vorherigen Nebenversionen kein nummeriertes Verzeichnis mehr erstellt. Archivierte Dokumentationen für Version 1.16 und niedriger finden Sie, indem Sie die Nummer der Nebenversion in die folgende URL einfügen:

https://cloud.google.com/anthos/clusters/docs/bare-metal/VERSION/

Ersetzen Sie VERSION durch eine Nebenversion von 1.0 bis 1.16 und kopieren Sie die URL in die Adressleiste Ihres Browsers.

Distributed Cloud (nur Software) für Bare Metal installieren

Da Cluster, die mit Google Distributed Cloud erstellt wurden, in Ihrer eigenen Infrastruktur ausgeführt werden, sind sie hochgradig konfigurierbar. Nachdem Sie das Bereitstellungsmodell ausgewählt haben, das Ihren spezifischen organisatorischen und Anwendungsfallanforderungen entspricht, können Sie aus einer Reihe unterstützter Load Balancing-Modi, IP-Adressierungsoptionen, Sicherheitsfunktionen und Verbindungsoptionen auswählen. Bei der Einrichtung eines Clusters müssen Sie vor und während der Installation Entscheidungen treffen. Diese Dokumentationsreihe enthält Leitfäden, die Ihrem Team bei der Entscheidung für die richtigen Funktionen und Optionen helfen. Wenden Sie sich an Ihre Netzwerk- und Anwendungsteams, um sicherzustellen, dass Ihre Installation die Anforderungen Ihres Unternehmens erfüllt.

Wo deine Daten gespeichert werden

Wenn Sie die Distributed Cloud-Software nur für Bare Metal 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, lokale Speicher-Back-Ends und die Daten, die Ihre Anwendungen verarbeiten.
  • Die Steuerungsebene (kube-apiserver, kube-scheduler und kube-controller-manager) und die etcd-Datenbank, in der alle Ihre Kubernetes-Objekte gespeichert werden.
  • Private Schlüssel für die Zertifizierungsstellen (CAs), einschließlich der Cluster-CA, der etcd-CA und der Front-Proxy-CA. Im Nutzercluster-Namespace des Administratorclusters werden Nutzercluster-CAs gespeichert.
  • Anwendungs-Secrets, OAuth-Tokens, private SSH-Schlüssel, Anmeldedaten für Container-Registries und Dienstkontoschlüsseldateien werden in etcd oder auf Ihrer Administrator-Workstation gespeichert. Sie werden nicht an die GKE On-Prem API gesendet und der Standard-Diagnose-Snapshot enthält keine Cluster-Anmeldedaten.
  • Ihre Clusterkonfigurationsdatei wird auf Ihrer Administrator-Workstation gespeichert. Wenn ein Cluster in der GKE On-Prem API registriert ist, werden einige Einstellungen gesendet. Weitere Informationen finden Sie unter An Google Cloudgesendete Daten.
  • Audit-Logs werden nur dann auf das Laufwerk geschrieben, wenn Sie Cloud-Audit-Logs auf den Knoten der Steuerungsebene deaktivieren.
  • Wenn Sie ein Dienstkonto für das Hochladen von Diagnose-Snapshots einrichten, wird die Datei in Cloud Storage hochgeladen. Sie können auswählen, ob Sie einen Snapshot für Cloud Customer Care freigeben möchten.

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)
  • Google Cloud -Projekt, Name der Flottenmitgliedschaft, Cluster-UID, öffentliche Schlüssel, Kubernetes-Version, Clustergröße und Konfiguration des Identitätsanbieters.
  • Kubernetes-Daten, die Sie über die Google Cloud Console oder das Connect-Gateway anfordern.
  • Ihr verschlüsseltes Kubernetes-Token, wenn Sie sich über dieGoogle Cloud Console in Ihrem Nutzerprofil anmelden, bis Sie sich abmelden.
 Cluster über dieGoogle Cloud -Konsole, das Connect-Gateway und die Flotte mit dem Connect-Agent verwalten. Erforderlich
Clustereinstellungen und -status
(gkeonprem.googleapis.com)
  • Name, UID, Beschreibung, Annotationen, Version, Lebenszyklusstatus, VIP der Steuerungsebene und Port.
  • Namen von Knotenpools, Knoten-IP-Adressen, Pod- und Dienst-CIDRs, Load-Balancer-VIPs und -Adresspools, BGP-Peer-IP-Adressen und -ASNs, Proxy-URLs, lokale Speicherpfade.
  • E-Mail-Adressen von Clusteradministratoren.
 Ermöglicht die Verwaltung von Clustern mit der Google Cloud Console, der Google Cloud CLI oder Terraform. Wird von der GKE On-Prem API in der Region gespeichert, die in gkeOnPremAPI.location festgelegt ist. Standardmäßig ist dies clusterOperations.location. 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)
  • Messwert: CPU-, Arbeitsspeicher-, Laufwerks- und Netzwerknutzung, kubelet-Messwerte und kube-state-metrics für Knoten und System-Pods.
  • Logs: Containerlogs und Ergebnisse der Systemdiagnose von allen Administratorcluster-Komponenten und von den Namespaces kube-system, gke-system, gke-connect, istio-system, config-management-system, knative-serving, monitoring-system, gatekeeper-system und cnrm-system in Nutzerclustern.
  • Metadaten: Namen und Labels von Knoten, Pods, Deployments und Diensten.
 Wird für Cloud Monitoring, Google Cloud -Konsolenstatusansichten und die Fehlerbehebung durch den Kundenservice verwendet. Wird im Projekt Google Cloud gespeichert, das in clusterOperations.projectID festgelegt ist. Messwerte werden in der in clusterOperations.location festgelegten Region 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 (audit-proxy): Wer hat wann was ü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. In Cloud-Audit-Logs in Ihrem Google Cloud -Projekt im Bucket _Required gespeichert und 400 Tage lang aufbewahrt. An. Wenn Sie die Funktion deaktivieren möchten, setzen Sie clusterOperations.disableCloudAuditLogging auf true. Audit-Logs werden dann nur auf den Laufwerken der Steuerungsebenenknoten gespeichert.

Nächste Schritte

Informationen zu den ersten Schritten mit Google Distributed Cloud finden Sie in den folgenden Leitfäden: