Version 1.8. Diese Version wird unterstützt, wie in der Supportrichtlinie für Anthos-Versionen beschrieben. Darin sind die neuesten Patches und Updates zu Sicherheitslücken, Kontakten und Problemen mit Anthos-Clustern auf Bare-Metal aufgeführt. Weitere Informationen finden Sie in den Versionshinweisen 1.8. Eine vollständige Liste der einzelnen Neben- und Patchversionen in chronologischer Reihenfolge finden Sie in den kombinierten Versionshinweisen.

Verfügbare Versionen: 1.9  |   1.8  |   1.7

Deployment-Modelle auswählen

Anthos-Cluster on Bare Metal unterstützt mehrere Bereitstellungsmodelle, um unterschiedliche Anforderungen hinsichtlich Verfügbarkeit, Isolation und Ressourcenbedarf zu erfüllen. Auf dieser Seite werden die Konzepte beschrieben, die alle Bereitstellungsmodelle gemeinsam verwenden, und es wird jedes Modell beschrieben.

Nutzercluster

Ein Nutzercluster ist ein Kubernetes-Cluster, auf dem Ihre containerisierten Arbeitslasten ausgeführt werden. Die Instanz besteht aus Knoten der Steuerungsebene und Worker-Knoten. Anthos-Cluster on Bare Metal unterstützt einen oder mehrere Nutzercluster. Nutzercluster müssen einen oder mehrere Worker-Knoten enthalten, mit denen Nutzerarbeitslasten ausgeführt werden.

Administratorcluster

Ein Administratorcluster ist ein Kubernetes-Cluster, der einen oder mehrere Nutzercluster verwaltet. Ihr Administratorcluster kann folgende Aufgaben ausführen:

  • Nutzercluster erstellen
  • Nutzercluster aktualisieren
  • Nutzercluster aktualisieren
  • Nutzercluster löschen

Um einen Nutzer-Cluster zu erstellen, richtet Ihr Admin-Cluster die Anthos auf Bare-Metal-Komponenten auf der Steuerebene und den Worker-Knoten des Nutzer-Clusters ein. Der Administratorcluster hat nur Knoten auf Steuerungsebene, da die "Anthos-Cluster on Bare Metal"-Komponenten auf den Knoten der Steuerungsebene ausgeführt werden.

Ihr Administratorcluster enthält die folgenden Arten von sensiblen Daten:

  • SSH-Anmeldedaten: Wird für die Remote-Installation verwendet
  • Google Cloud-Dienstkontoschlüssel: wird für den Zugriff auf Features wie Container Registry verwendet

Beschränken Sie den Zugriff auf Ihren Administratorcluster, um sensible Daten zu schützen.

Hochverfügbarkeit

Sie können Administrator- oder Nutzercluster im Modus Hochverfügbarkeit (HA) ausführen. Für diesen Modus sind mindestens drei (ungerade Anzahl) Knoten der Steuerungsebene in Ihrem Cluster erforderlich. Wenn Sie einen Cluster außerhalb des Hochverfügbarkeitsmodus ausführen, benötigt der Cluster nur einen Knoten der Steuerungsebene. Verwenden Sie den HA-Modus für Produktionsbereitstellungen, um einen Single Point of Failure zu vermeiden. Verwenden Sie den Nicht-HA-Modus für nicht dringende Umgebungen, z. B. eine Testumgebung, in der Sie den Cluster neu erstellen können, wenn der Knoten der Steuerungsebene ausfällt. Ein HA-Nutzercluster muss mindestens zwei Worker-Knoten haben, falls ein Worker-Knoten ausfällt.

Bereitstellungsmodelle

Anthos-Cluster on Bare Metal unterstützt die folgenden Bereitstellungsmodelle, die unterschiedliche Anforderungen erfüllen:

  • Bereitstellung von eigenständigen Clustern
  • Multi-Cluster-Bereitstellung
  • Bereitstellung von Hybridclustern

Bereitstellung von eigenständigen Clustern

Dieses Bereitstellungsmodell hat einen einzelnen Cluster, der als Nutzercluster und als Administratorcluster dient.

Dieses Modell bietet folgende Vorteile:

  • Es ist kein separater Administratorcluster erforderlich.
  • Speichert drei Knoten in einer HA-Einrichtung.

Dieses Modell hat die folgenden Sicherheitsvorkehrungen, da Arbeitslasten auf einem Cluster mit den folgenden sensiblen Daten ausgeführt werden:

  • SSH-Anmeldedaten
  • Google Cloud-Dienstkontoschlüssel

Verwenden Sie dieses Modell, wenn eine der folgenden Bedingungen erfüllt ist:

  • Sie verwalten jeden Cluster unabhängig.
  • Die Anzahl der Worker-Knoten ist gering.
  • Sie unterstützen ein einzelnes Team.
  • Sie führen einen einzigen Arbeitslasttyp aus.

Dieses Modell funktioniert in folgenden Situationen gut:

  • Jeder Cluster wird separat mit unterschiedlichen SSH-Schlüsseln und Google Cloud-Anmeldedaten verwaltet
  • Cluster werden in netzwerk-partitionierten Partitionen wie denormalisierten Zonen (DMZs) ausgeführt.
  • Cluster werden an Edge-Standorten ausgeführt.

Footprint

Für die Bereitstellung eines eigenständigen Clusters sind folgende Knoten erforderlich:

  • Knoten der Steuerungsebene:

    • Ein Knoten der Steuerungsebene für Nicht-HA
    • Drei oder mehr Knoten der Steuerungsebene für HA
  • Worker-Knoten:

    • Einen oder mehrere Worker-Knoten für Nicht-HA
    • Mindestens zwei Worker-Knoten für HA

Multi-Cluster-Bereitstellung

Verwenden Sie dieses Bereitstellungsmodell, wenn Sie eine Reihe von Clustern im selben Rechenzentrum haben, die Sie von einem zentralen Ort aus verwalten möchten, sowie für größere Bereitstellungen, die zwischen verschiedenen Teams oder zwischen Entwicklungs- und Produktionsarbeitslasten isoliert werden müssen.

Dieses Bereitstellungsmodell besteht aus den folgenden Clustern:

  • Ein Administratorcluster: Der zentrale Verwaltungspunkt, der eine API zum Verwalten von Nutzerclustern bereitstellt. Ihr Administratorcluster führt nur Verwaltungskomponenten aus.
  • Einen oder mehrere Nutzercluster: Enthält die Knoten der Steuerungsebene und die Worker-Knoten, auf denen Nutzerarbeitslasten ausgeführt werden.

Dieses Modell erfüllt folgende Anforderungen:

  • Stellt eine zentralisierte Steuerungsebene und API zur Verwaltung der Lebenszyklus Ihrer Nutzercluster bereit.
  • Bietet Isolation zwischen verschiedenen Teams.
  • Bietet Isolation zwischen Entwicklungs- und Produktionsarbeitslasten.
  • Sie müssen keine SSH-Anmeldedaten und Dienstkontoschlüssel für Clusterinhaber freigeben.
  • Sie können Ihre Bereitstellung in Ihre eigenen Steuerungsebenen integrieren

Footprint

Für eine Multi-Cluster-Bereitstellung sind folgende Knoten erforderlich:

  • Administratorcluster

    • Ein Knoten der Steuerungsebene für Nicht-HA
    • Drei oder mehr Knoten der Steuerungsebene für HA
  • Nutzercluster: Sie können HA für jeden Nutzercluster unabhängig konfigurieren.

    • Knoten der Steuerungsebene:

      • Ein Knoten der Steuerungsebene für Nicht-HA
      • Drei oder mehr Knoten der Steuerungsebene für HA
    • Worker-Knoten:

      • Einen oder mehrere Worker-Knoten für Nicht-HA
      • Mindestens zwei Worker-Knoten für HA

Bereitstellung von Hybridclustern

Dieses Bereitstellungsmodell ist eine spezialisierte Bereitstellung mit mehreren Clustern. Verwenden Sie dieses Modell, um Nutzerarbeitslasten auf Ihrem Administratorcluster auszuführen. Ihr Administratorcluster verwaltet weiterhin zusätzliche Nutzercluster. Sie können eine hybride Cluster-Bereitstellung aus einer eigenständigen Cluster-Bereitstellung erstellen, indem Sie weitere Nutzercluster hinzufügen, um mehrere Teams oder Arbeitslasttypen zu unterstützen.

Dieses Modell erfüllt folgende Anforderungen:

  • Ermöglicht die Wiederverwendung der Steuerungsebenenknoten für Nutzerarbeitslasten.
  • Es gibt keine Sicherheitsbedenken in Bezug auf die Ausführung von Nutzerarbeitslasten in Ihrem Administratorcluster, die vertrauliche Daten enthalten.

Footprint

Für die Bereitstellung eines hybriden Clusters sind folgende Knoten erforderlich:

  • Hybrid-Cluster

    • Knoten der Steuerungsebene:

      • Ein Knoten der Steuerungsebene für Nicht-HA
      • Drei oder mehr Knoten der Steuerungsebene für HA
    • Worker-Knoten:

      • Einen oder mehrere Worker-Knoten für Nicht-HA
      • Mindestens zwei Worker-Knoten für HA und je nach Arbeitslasttyp
  • Nutzercluster: Sie können HA für jeden Nutzercluster unabhängig konfigurieren.

    • Knoten der Steuerungsebene:

      • Ein Knoten der Steuerungsebene für Nicht-HA
      • Drei oder mehr Knoten der Steuerungsebene für HA
    • Worker-Knoten:

      • Einen oder mehrere Worker-Knoten für Nicht-HA
      • Mindestens zwei Worker-Knoten für HA