Clustertypen

Auf dieser Seite werden die Haupttypen von Clustern erläutert, die Sie in Google Kubernetes Engine (GKE) erstellen können. In der Regel können die hier beschriebenen Auswahlmöglichkeiten nach dem Erstellen eines Clusters nicht mehr geändert werden. Diese Auswahlmöglichkeiten wirken sich auf die Verfügbarkeit eines Clusters, die Versionsstabilität (unabhängig davon, ob der Cluster VPC-nativ oder routenbasiert ist) und die Isolierung der Arbeitslasten aus.

Weitere Informationen zu den verschiedenen Clustertypen finden Sie unter Regionale oder zonale Steuerungsebene auswählen.

Auswahl der Clusterverfügbarkeit

Mit GKE können Sie einen Cluster erstellen, der auf die Verfügbarkeitsanforderungen Ihrer Arbeitslast und Ihres Budgets zugeschnitten ist.

Zu den verfügbaren Clustertypen gehören zonale (einzel- oder multizonale) und regionale Cluster.

Zonale Cluster

Zonale Cluster haben eine einzige Steuerungsebene in einer einzelnen Zone. Je nach Verfügbarkeitsanforderungen können Sie die Knoten für den zonalen Cluster in einer einzigen Zone oder in mehreren Zonen verteilen.

Informationen zum Erstellen eines zonalen Clusters finden Sie unter Zonalen Cluster erstellen.

Einzelzonencluster

Ein Einzelzonencluster hat eine einzige Steuerungsebene, die in einer einzigen Zone ausgeführt wird. Diese Steuerungsebene verwaltet Arbeitslasten auf Knoten, die in derselben Zone ausgeführt werden.

Multizonale Cluster

Ein multizonaler Cluster hat ein einzelnes Replikat der Steuerungsebene, das in einer einzelnen Zone ausgeführt wird, und Knoten, die in mehreren Zonen ausgeführt werden. Während eines Upgrades des Clusters oder wenn die Zone ausfällt, in der die Steuerungsebene ausgeführt wird, werden weiterhin Arbeitslasten ausgeführt. Der Cluster, seine Knoten und seine Arbeitslasten können jedoch erst konfiguriert werden, wenn die Steuerungsebene verfügbar ist. Multizonale Cluster gleichen Verfügbarkeit und Kosten für konsistente Arbeitslasten aus. Wenn Sie die Verfügbarkeit beibehalten möchten und sich die Anzahl Ihrer Knoten und Knotenpools häufig ändert, sollten Sie einen regionalen Cluster verwenden.

Regionale Cluster

Ein regionaler Cluster verfügt über mehrere Replikate der Steuerungsebene, die in mehreren Zonen innerhalb einer bestimmten Region ausgeführt werden. Knoten werden auch in jeder Zone ausgeführt, in der ein Replikat der Steuerungsebene ausgeführt wird. Da ein regionaler Cluster die Steuerungsebene und die Knoten repliziert, verbraucht er mehr Compute Engine-Ressourcen als ein ähnlicher Cluster mit nur einer oder mit mehreren Zonen.

Sie können einen regionalen Cluster erstellen.

Auswahl der Clusterversion

Wenn Sie einen Cluster erstellen, können Sie die spezifische Kubernetes-Version des Clusters auswählen oder eine Auswahl nach den Kriterien Stabilität und Funktionen treffen.

Unabhängig davon, wie Sie die Version Ihres Clusters verwalten, wird empfohlen, die automatische Aktualisierung für den Cluster und seine Knoten zu aktivieren.

Release-Version

Wenn Sie wissen, welche Stabilität Sie für einen bestimmten Cluster benötigen, können Sie den Cluster in einer Release-Version registrieren. Google aktualisiert den Cluster und seine Knoten automatisch, wenn ein Update in dieser Release-Version verfügbar ist. Der Rapid Channel erhält mehrere Updates pro Monat. Beim Stable Channel sind es nur wenige Updates pro Jahr.

Sie können einen Cluster in einer Release-Version registrieren.

Standardversion

Wenn Sie keine Release-Version verwenden oder keine Clusterversion auswählen, wird die aktuelle Standardversion verwendet. Die Standardversion wird anhand von Nutzung und Leistung unter realen Einsatzbedingungen ausgewählt und regelmäßig geändert. Die Standardversion ist die ausgereifteste Version. Andere verfügbare Versionen sind GA-Versionen, die interne Tests und Qualifizierungsprüfungen bestanden haben. Änderungen an der Standardversion werden in einem Versionshinweis angekündigt.

Spezifische Version

Wenn Sie wissen, dass Sie eine bestimmte unterstützte Version von Kubernetes für eine bestimmte Arbeitslast verwenden müssen, können Sie sie beim Erstellen des Clusters angeben.

Wenn Sie die von Ihnen verwendete spezifische Patchversion nicht steuern müssen, sollten Sie Ihren Cluster vielleicht in einer Release-Version registrieren, anstatt die Version direkt zu verwalten.

Sie können einen Cluster mit einer bestimmten Version erstellen.

Alphacluster

In einem Alphacluster sind alle Kubernetes Alpha APIs (manchmal auch als Feature-Gates bezeichnet) aktiviert. Sie können Alphacluster für das frühe Testen und Validieren von Kubernetes-Funktionen verwenden. Alphacluster werden für Produktionsarbeitslasten nicht unterstützt, können nicht geupgradet werden und laufen innerhalb von 30 Tagen ab.

Sie können einen Alphacluster erstellen.

Auswahlmöglichkeiten für Clusternetzwerke

Beim Erstellen eines GKE-Clusters können Sie den Routingmodus für das Netzwerk angeben und festlegen, wie Ihr Clusternetzwerk isoliert werden soll.

VPC-native und routenbasierte Cluster

In Google Kubernetes Engine lassen sich Cluster anhand der Methode unterscheiden, mit der sie Traffic von einem Pod zu einem anderen weiterleiten. Ein Cluster, der auf Alias-IP-Adressen zurückgreift, wird als VPC-nativer Cluster bezeichnet. Ein Cluster, der dazu Google Cloud-Routen verwendet, wird routenbasierter Cluster genannt.

VPC-nativ ist der empfohlene Netzwerkmodus für neue Cluster.

Der Standard-Netzwerkmodus für Cluster hängt davon ab, wie der Cluster erstellt wird. Weitere Informationen finden Sie im Diagramm Standard-Netzwerkmodus für Cluster.

Auswahl der Netzwerkisolation

Standardmäßig können Sie den Zugriff von öffentlichen Netzwerken auf die Arbeitslasten Ihres Clusters konfigurieren. Routen werden nicht automatisch erstellt. Private Cluster weisen Pods und Knoten interne Adressen zu und Arbeitslasten sind vollständig von öffentlichen Netzwerken isoliert.

Sie können einen privaten Cluster erstellen.

Sicherheit der Arbeitslasten-Lieferkette

Die Binärautorisierung ist ein Feature der Anthos-Plattform, das Software-Lieferkettensicherheit für GKE-Arbeitslasten bietet. Es funktioniert mit Images, die Sie von Container Registry oder einer anderen Container-Image-Registry an GKE bereitstellen. Mit der Binärautorisierung werden interne Prozesse, die die Qualität und Integrität Ihrer Software gewährleisten, erfolgreich abgeschlossen, bevor eine Anwendung in Ihrer Produktionsumgebung bereitgestellt wird.

Weitere Informationen finden Sie in der Dokumentation zur Binärautorisierung unter Cluster mit aktivierter Binärautorisierung erstellen.