|
Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar. |
GKE-Cluster-Konfigurationsreferenz
Clusterstandort
| Wert | Beschreibung |
|---|---|
Standorttyp |
Zonal oder Regional. Mit GKE können Sie einen Cluster erstellen, der auf die Verfügbarkeitsanforderungen Ihrer Arbeitslast und Ihr Budget zugeschnitten ist. Standardmäßig laufen die Knoten eines Clusters in einer einzelnen Compute-Zone. Wenn mehrere Zonen ausgewählt sind, erstrecken sich die Knoten des Clusters über mehrere Compute-Zonen, während der Controlplane in einer einzelnen Zone lokalisiert ist. Regionale Cluster erhöhen auch die Verfügbarkeit des Controlplanes. Weitere Hilfe zur Auswahl des Typs der Clusterverfügbarkeit finden Sie in dieser Dokumentation. |
Zone |
Jede Region in der Compute Engine enthält eine Anzahl von Zonen. Für weitere Informationen über verfügbare Regionen und Zonen siehe diese Dokumentation. |
Zusätzliche Zonen |
Für zonale Cluster können Sie zusätzliche Zonen auswählen, um einen Multi-Zonen-Cluster zu erstellen. |
Region |
Für regionale Cluster, können Sie eine Region auswählen. Für weitere Informationen über verfügbare Regionen und Zonen, siehe diesen Abschnitt. Der erste Teil jedes Zonennamens ist der Name der Region. |
Clusteroptionen
Kubernetes Version
Veränderlich: ja
Weitere Informationen zu GKE Kubernetes-Versionen finden Sie unter dieser Dokumentation.
Container-Adressbereich
Veränderlich: nein
Der IP-Adressbereich für Pods im Cluster. Muss ein gültiger CIDR-Bereich sein, z. B. 10.42.0.0/16. Wenn nicht angegeben, wird automatisch ein zufälliger Bereich aus 10.0.0.0/8 gewählt, der bereits zu VMs, anderen Clustern oder Routen zugewiesene Bereiche ausschließt. Automatisch gewählte Bereiche können mit reservierten IP-Adressen, dynamischen Routen oder Routen innerhalb von VPCs, die mit dem Cluster verbunden sind, in Konflikt stehen.
Netzwerk
Veränderlich: nein
Das Compute Engine-Netzwerk, mit dem der Cluster verbunden ist. Routen und Firewalls werden mit diesem Netzwerk erstellt. Wenn Shared VPCs verwendet wird, erscheinen hier die VPC-Netzwerke, die Ihrem Projekt zugewiesen sind. Sie werden in diesem Feld zur Auswahl verfügbar sein. Für weitere Informationen siehe diese Seite.
Knoten-Subnetz / Subnetz
Veränderlich: nein
Das Compute Engine-Subnetz, mit dem der Cluster verbunden ist. Dieses Subnetz muss zu dem im Feld Netzwerk angegebenen Netzwerk gehören. Wählen Sie ein vorhandenes Subnetz aus oder wählen Sie "Subnetz automatisch erstellen", um eines automatisch zu erstellen. Wenn kein vorhandenes Netzwerk verwendet wird, ist Subnetzname erforderlich, um eines zu erstellen. Wenn Shared VPCs verwendet wird, erscheinen hier die VPC-Subnetze, die Ihrem Projekt zugewiesen sind. Wenn ein Shared VPC-Netzwerk verwendet wird, können Sie "Subnetz automatisch erstellen" nicht auswählen. Weitere Informationen finden Sie auf dieser Seite.
Subnetzname
Veränderlich: nein
Erstellen Sie automatisch ein Subnetz mit dem angegebenen Namen. Erforderlich, wenn "Subnetz automatisch erstellen" für Node Subnet oder Subnetz ausgewählt ist. Weitere Informationen zu Subnetzen finden Sie auf dieser Seite.
IP-Aliase
Veränderlich: nein
Aktivieren Sie Alias-IPs. Dies aktiviert das VPC-native Verkehrsrouting. Erforderlich, wenn Shared VPCs verwendet werden.
Netzwerkrichtlinie
Veränderlich: ja
Aktivieren Sie die Durchsetzung von Netzwerkrichtlinien im Cluster. Eine Netzwerkrichtlinie definiert das Kommunikationsniveau, das zwischen Pods und Diensten im Cluster stattfinden kann. Weitere Informationen finden Sie auf dieser Seite.
Projekt-Netzwerkisolierung
Veränderlich: ja
Wählen Sie aus, ob die interprojektliche Kommunikation aktiviert oder deaktiviert werden soll.
Importierte Cluster
Für importierte Cluster erfordert die Projekt-Netzwerkisolierung (PNI), dass die Kubernetes-Netzwerkrichtlinie zuvor im Cluster aktiviert ist. Für von Rancher erstellte Cluster aktiviert Rancher automatisch die Kubernetes-Netzwerkrichtlinie.
-
Aktivieren Sie in GKE die Netzwerkrichtlinie auf Clusterebene. Verweisen Sie auf den offiziellen GKE-Leitfaden für Anweisungen.
-
Nach der Aktivierung der Netzwerkrichtlinie importieren Sie den Cluster in Rancher und aktivieren Sie PNI für die projektbezogene Isolation.
Node IPv4 CIDR-Block
Veränderlich: nein
Der IP-Adressbereich der Instanz-IP-Adressen in diesem Cluster. Kann gesetzt werden, wenn "Subnetz automatisch erstellen" für Node Subnet oder Subnetz ausgewählt ist. Muss ein gültiger CIDR-Bereich sein, z. B. 10.96.0.0/14. Für weitere Informationen zur Bestimmung des IP-Adressbereichs siehe diese Seite.
Name des sekundären Clusterbereichs
Veränderlich: nein
Der Name eines vorhandenen sekundären Bereichs für Pod-IP-Adressen. Wenn ausgewählt, wird Cluster Pod Address Range automatisch ausgefüllt. Erforderlich, wenn ein Shared VPC-Netzwerk verwendet wird.
Cluster-Pod-Adressbereich
Veränderlich: nein
Der IP-Adressbereich, der Pods im Cluster zugewiesen ist. Muss ein gültiger CIDR-Bereich sein, z. B. 10.96.0.0/11. Wenn nicht angegeben, wird er automatisch erstellt. Muss angegeben werden, wenn ein Shared VPC-Netzwerk verwendet wird. Für weitere Informationen zur Bestimmung des IP-Adressbereichs für Ihre Pods siehe dieser Abschnitt.
Name des sekundären Dienstbereichs
Veränderlich: nein
Der Name eines vorhandenen sekundären Bereichs für Dienst-IP-Adressen. Wenn ausgewählt, wird Service Address Range automatisch ausgefüllt. Erforderlich, wenn ein Shared VPC-Netzwerk verwendet wird.
Dienst-Adressbereich
Veränderlich: nein
Der Adressbereich, der den Diensten im Cluster zugewiesen ist. Muss ein gültiger CIDR-Bereich sein, z. B. 10.94.0.0/18. Wenn nicht angegeben, wird er automatisch erstellt. Muss angegeben werden, wenn ein Shared VPC-Netzwerk verwendet wird. Für weitere Informationen zur Bestimmung des IP-Adressbereichs für Ihre Dienste siehe diesen Abschnitt
Privater Cluster
Veränderlich: nein
|
Private Cluster erfordern zusätzliche Planung und Konfiguration außerhalb von Rancher. Verweisen Sie auf den Private Cluster Guide. |
Weisen Sie Knoten nur interne IP-Adressen zu. Knoten in privaten Clustern können nicht auf das öffentliche Internet zugreifen, es sei denn, es werden zusätzliche Netzwerkmaßnahmen in GCP ergriffen.
Aktivieren Sie den privaten Endpunkt
|
Private Cluster erfordern zusätzliche Planung und Konfiguration außerhalb von Rancher. Verweisen Sie auf den Private Cluster Guide. |
Veränderlich: nein
Sperrt den externen Zugriff auf den Endpunkt der Controlplane. Nur verfügbar, wenn Private Cluster ebenfalls ausgewählt ist. Wenn ausgewählt und wenn Rancher keinen direkten Zugriff auf das Virtual Private Cloud-Netzwerk hat, in dem der Cluster läuft, wird Rancher einen Registrierungsbefehl bereitstellen, der im Cluster ausgeführt werden muss, um Rancher die Verbindung zu ermöglichen.
Master Autorisierte Netzwerke
Veränderlich: ja
Aktivieren Sie autorisierte Netzwerke für die Controlplane, um nicht vertrauenswürdigen, nicht-GCP-Quell-IP-Adressen den Zugriff auf den Kubernetes-Master über HTTPS zu verwehren. Wenn ausgewählt, können zusätzliche autorisierte Netzwerke hinzugefügt werden. Wenn der Cluster mit einem öffentlichen Endpunkt erstellt wird, ist diese Option nützlich, um den Zugriff auf den öffentlichen Endpunkt nur auf bestimmte Netzwerke zu beschränken, z. B. das Netzwerk, in dem Ihr Rancher-Dienst läuft. Wenn der Cluster nur einen privaten Endpunkt hat, ist diese Einstellung erforderlich.
Zusatzoptionen
Cluster-Addons
Zusätzliche Kubernetes-Clusterkomponenten. Weitere Informationen finden Sie auf dieser Seite.
Horizontaler Pod-Autoscaler
Veränderlich: ja
Der Horizontal Pod Autoscaler ändert die Form Ihrer Kubernetes-Arbeitslast, indem er automatisch die Anzahl der Pods in Reaktion auf den CPU- oder Speicherverbrauch der Arbeitslast oder in Reaktion auf benutzerdefinierte Metriken, die innerhalb von Kubernetes oder von externen Quellen außerhalb Ihres Clusters gemeldet werden, erhöht oder verringert. Weitere Informationen finden Sie auf dieser Seite.
HTTP (L7) Lastausgleich
Veränderlich: ja
Der HTTP (L7) Lastausgleich verteilt HTTP- und HTTPS-Verkehr auf Backends, die auf GKE gehostet werden. Weitere Informationen finden Sie auf dieser Seite.
Clusterfunktionen (Alpha-Funktionen)
Veränderlich: nein
Aktiviert alle Kubernetes Alpha-API-Gruppen und -Funktionen für den Cluster. Wenn aktiviert, kann der Cluster nicht upgegradet werden und wird nach 30 Tagen automatisch gelöscht. Alpha-Cluster werden nicht für den produktiven Einsatz empfohlen, da sie nicht durch die GKE SLA abgedeckt sind. Weitere Informationen finden Sie auf dieser Seite.
Protokollierungsdienst
Veränderlich: ja
Der Protokollierungsdienst, den der Cluster verwendet, um Protokolle zu schreiben. Verwenden Sie entweder Cloud Logging oder keinen Protokollierungsdienst, in diesem Fall werden keine Protokolle aus dem Cluster exportiert.
Überwachungsdienst
Veränderlich: ja
Der Überwachungsdienst, den der Cluster verwendet, um Metriken zu schreiben. Verwenden Sie entweder Cloud Monitoring oder den Überwachungsdienst, in diesem Fall werden keine Metriken aus dem Cluster exportiert.
Wartungsfenster
Veränderlich: ja
Legen Sie die Startzeit für ein 4-stündiges Wartungsfenster fest. Die Zeit wird in der UTC-Zeitzone im HH:MM-Format angegeben. Weitere Informationen finden Sie auf dieser Seite.
Knotenpools
Geben Sie in diesem Abschnitt Details zur Konfiguration jedes Knotens im Knotenpool ein.
Kubernetes Version
Veränderlich: ja
Die Kubernetes-Version für jeden Knoten im Knotenpool. Für weitere Informationen zu GKE Kubernetes-Versionen, siehe diese Dokumente.
Image-Typ
Veränderlich: ja
Das Betriebssystem-Image des Knotens. Für weitere Informationen zu den Knoten-Image-Optionen, die GKE für jedes Betriebssystem anbietet, siehe diese Seite.
|
Die Standardoption ist "Container-Optimiertes OS mit Docker". Das schreibgeschützte Dateisystem auf dem Container-Optimierten OS von GCP ist nicht mit der xref:[veralteten Protokollierung] Implementierung in Rancher kompatibel. Wenn Sie die veraltete Protokollierungsfunktion verwenden müssen, wählen Sie "Ubuntu mit Docker" oder "Ubuntu mit Containerd". Die aktuelle Protokollierungsfunktion ist mit dem Container-optimierten OS-Image kompatibel. |
|
Wenn Sie "Windows Long Term Service Channel" oder "Windows Semi-Annual Channel" für den Knotenpool-Image-Typ auswählen, müssen Sie auch mindestens einen Container-optimierten OS- oder Ubuntu-Knotenpool hinzufügen. |
Computertyp
Veränderlich: nein
Die virtualisierten Hardware-Ressourcen, die den Knoteninstanzen zur Verfügung stehen. Für weitere Informationen zu Google Cloud-Maschinenarten, siehe diese Seite.
Root-Disk-Typ
Veränderlich: nein
Standardpersistente Festplatten werden von herkömmlichen Festplatten (HDD) unterstützt, während SSD-persistente Festplatten von Solid State Drives (SSD) unterstützt werden. Für weitere Informationen siehe diesen Abschnitt.
Lokale SSDs
Veränderlich: nein
Konfigurieren Sie den lokalen SSD-Speicher jedes Knotens in GB. Lokale SSDs sind physisch an den Server angeschlossen, der Ihre VM-Instanz hostet. Lokale SSDs haben eine höhere Durchsatzrate und eine geringere Latenz als standardpersistente Festplatten oder SSD-persistente Festplatten. Die Daten, die Sie auf einer lokalen SSD speichern, bleiben nur bis zur Beendigung oder Löschung der Instanz erhalten. Weitere Informationen finden Sie in diesen Abschnitt.
Preemptible Knoten (Beta)
Veränderlich: nein
Preemptible Knoten, auch als preemptible VMs bezeichnet, sind Compute Engine VM-Instanzen, die im Allgemeinen maximal 24 Stunden dauern und keine Verfügbarkeitsgarantien bieten. Weitere Informationen finden Sie auf dieser Seite.
Taints
Veränderlich: nein
Wenn Sie einen Taint auf einen Knoten anwenden, dürfen nur Pods, die den Taint tolerieren, auf dem Knoten ausgeführt werden. In einem GKE-Cluster können Sie einen Taint auf einen Knotenpool anwenden, wodurch der Taint auf alle Knoten im Pool angewendet wird.
Knoten-Labels
Veränderlich: nein
Sie können Labels auf den Knotenpool anwenden, wodurch die Labels auf alle Knoten im Pool angewendet werden.
Ungültige Labels können Upgrades verhindern oder dazu führen, dass Rancher nicht gestartet werden kann. Für Details zu den Anforderungen an die Labelsyntax siehe die Kubernetes-Dokumentation.
Netzwerk-Tags
Veränderlich: nein
Sie können Netzwerk-Tags zum Knotenpool hinzufügen, um Firewall-Regeln und Routen zwischen Subnetzen zu erstellen. Tags gelten für alle Knoten im Pool.
Für Details zu den Anforderungen an die Tagsyntax siehe die Kubernetes-Dokumentation.
Gruppendetails
Geben Sie in diesem Abschnitt Details an, die den Knotenpool beschreiben.
Maximale Pods pro Knoten
Veränderlich: nein
GKE hat eine harte Grenze von 110 Pods pro Knoten. Für weitere Informationen zu den Kubernetes-Grenzen siehe dieser Abschnitt.
Autoskalierung
Veränderlich: ja
Die Autoskalierung des Knotenpools erstellt oder löscht dynamisch Knoten basierend auf den Anforderungen Ihrer Arbeitslast. Weitere Informationen finden Sie auf dieser Seite.
Automatische Reparatur
Veränderlich: ja
Die automatische Reparaturfunktion von GKE hilft Ihnen, die Knoten in Ihrem Cluster in einem gesunden, laufenden Zustand zu halten. Wenn aktiviert, führt GKE regelmäßige Überprüfungen des Gesundheitszustands jedes Knotens in Ihrem Cluster durch. Wenn ein Knoten über einen längeren Zeitraum hinweg aufeinanderfolgende Gesundheitsprüfungen nicht besteht, initiiert GKE einen Reparaturprozess für diesen Knoten. Für weitere Informationen siehe den Abschnitt über automatische Reparatur von Knoten.
Automatisches Upgrade
Veränderlich: ja
Wenn aktiviert, hält die automatische Upgrade-Funktion die Knoten in Ihrem Cluster auf dem neuesten Stand mit der Version des Cluster-Kontrollplanes (Master), wenn Ihr Kontrollplane in Ihrem Namen aktualisiert wird. Für weitere Informationen über das automatische Upgrade von Knoten siehe diese Seite.
Zugriffsbereiche
Veränderlich: nein
Zugriffsbereiche sind die veraltete Methode zur Spezifizierung von Berechtigungen für Ihre Knoten.
-
Standardzugriff erlauben: Der Standardzugriff für neue Cluster ist das Standarddienstkonto von Compute Engine.
-
Vollzugriff auf alle Cloud-APIs erlauben: Im Allgemeinen können Sie einfach den Zugriffsbereich für die Cloud-Plattform festlegen, um vollen Zugriff auf alle Cloud-APIs zu gewähren, und dann dem Dienstkonto nur relevante IAM-Rollen zuweisen. Die Kombination der Zugriffsbereiche, die der virtuellen Maschineninstanz gewährt werden, und der IAM-Rollen, die dem Dienstkonto gewährt werden, bestimmt den Zugriff, den das Dienstkonto für diese Instanz hat.
-
Zugriff für jede API festlegen: Alternativ können Sie spezifische Bereiche festlegen, die den Zugriff auf die bestimmten API-Methoden erlauben, die der Dienst aufruft.
Für weitere Informationen siehe den Abschnitt über die Aktivierung von Dienstkonten für eine VM.
Konfiguration der Bildwiederholrate
Die Bildwiederholrate kann über die Einstellung "gke-refresh" konfiguriert werden, die eine Ganzzahl in Sekunden darstellt.
Der Standardwert ist 300 Sekunden.
Das Synchronisierungsintervall kann durch Ausführen von kubectl edit setting gke-refresh geändert werden.
Je kürzer das Bildwiederholfenster, desto unwahrscheinlicher treten Rennbedingungen auf, aber es erhöht die Wahrscheinlichkeit, auf Anforderungsgrenzen zu stoßen, die für GCP-APIs gelten können.