Anthos-Cluster auf Bare Metal sind jetzt Google Distributed Cloud (nur Software) für Bare Metal. Weitere Informationen finden Sie in der Produktübersicht.
Auf dieser Seite werden die Felder beschrieben, die in der Clusterkonfigurationsdatei für Google Distributed Cloud (nur Software) auf Bare Metal unterstützt werden. Die folgende Tabelle gibt für jedes Feld an, ob das Feld erforderlich ist. Die Tabelle zeigt auch, welche Felder änderbar sind, also welche Felder nach dem Erstellen eines Clusters geändert werden können. Wie in der Tabelle angegeben, können einige veränderbare Felder nur während eines Cluster-Upgrades geändert werden.
Vorlage für Ihre Clusterkonfigurationsdatei erstellen
Mit dem Befehl bmctl create config können Sie eine Clusterkonfigurationsdatei erstellen. Obwohl einige Felder Standardwerte haben und andere wie metadata.name automatisch ausgefüllt werden können, ist diese Konfigurationsdatei im YAML-Format eine Vorlage zur Angabe von Informationen zu Ihrem Cluster.
Verwenden Sie den folgenden Befehl im Ordner /baremetal, um eine neue Clusterkonfigurationsdatei zu erstellen:
bmctlcreateconfig-cCLUSTER_NAME
Ersetzen Sie CLUSTER_NAME durch den Namen des Clusters, den Sie erstellen möchten. Weitere Informationen zu bmctl finden Sie unter bmctl-Tool.
Ein Beispiel für die generierte Clusterkonfigurationsdatei finden Sie unter Beispiel für die Clusterkonfigurationsdatei.
Konfigurationsdatei ausfüllen
Geben Sie in Ihrer Konfigurationsdatei Feldwerte ein, wie in der folgenden Feldreferenztabelle beschrieben, bevor Sie den Cluster erstellen oder aktualisieren.
Die von bmctl generierte Clusterkonfigurationsdatei enthält Felder zum Angeben von Pfaden zu Anmeldedaten und Schlüsseldateien im lokalen Dateisystem. Diese Anmeldedaten und Schlüssel werden benötigt, um Ihre Cluster miteinander und mit Ihrem Google Cloud-Projekt zu verbinden.
Erforderlich. String. Die Clusterversion. Dieser Wert wird für die Clustererstellung und Clusterupgrades festgelegt.
Veränderbarkeit: Dieser Wert kann für vorhandene Cluster nicht geändert werden.
Die Version kann nur über den Clusterupgrade-Prozess aktualisiert werden.
Dieser Abschnitt enthält Einstellungen, die für die Verwendung von OpenID Connect (OIDC) erforderlich sind.
Mit OIDC können Sie Ihren vorhandenen Identitätsanbieter zur Verwaltung der Nutzer- und Gruppenauthentifizierung in Ihren Clustern verwenden.
Optional. Ein base64-codiertes PEM-codiertes Zertifikat für den OIDC-Anbieter. Codieren Sie das Zertifikat samt Header in base64, um den String zu erstellen. Fügen Sie den resultierenden String in certificateAuthorityData als eine einzelne Zeile ein.
Optional. Boolescher Wert (true|false). Gibt an, ob ein Reverse-Proxy im Cluster bereitgestellt wird, um die Google Cloud Console mit einem lokalen Identitätsanbieter zu verbinden, der nicht über das Internet öffentlich zugänglich ist. Wenn Ihr Identitätsanbieter nicht über das öffentliche Internet erreichbar ist, legen Sie dieses Feld auf true zur Authentifizierung bei der Google Cloud Console fest. Standardmäßig ist dieser Wert auf false festgelegt.
Optional. String. Das Präfix, das Gruppenanforderungen vorangestellt wird, um Konflikte mit vorhandenen Namen zu vermeiden. Ein Beispiel ist oidc:dev für die Gruppe dev und das Präfix oidc:.
Optional. URL-String. Die URL, über die Autorisierungsanfragen an Ihren OpenID-Anbieter gesendet werden, z. B. https://example.com/adfs. Der Kubernetes API-Server nutzt diese URL, um öffentliche Schlüssel zum Verifizieren von Tokens zu ermitteln. Die URL muss HTTPS verwenden.
Optional. URL-String. Die Weiterleitungs-URL, die kubectl für die Autorisierung verwendet. Wenn Sie OIDC aktivieren, müssen Sie einen kubectlRedirectURL-Wert angeben.
Optional. URL-String. Proxyserver, über den der Cluster gegebenenfalls die Verbindung mit Ihrem OIDC-Anbieter herstellen kann. Der Wert sollte einen Hostnamen/eine IP-Adresse und optional einen Port, einen Nutzernamen und ein Passwort enthalten. Beispiel: http://user:password@10.10.10.10:8888.
Optional. Durch Kommas getrennte Liste. Zusätzliche Bereiche, die an den OpenID-Anbieter gesendet werden. Microsoft Azure und Okta benötigen den Bereich offline_access.
Optional. Boolescher Wert (true|false). Wenn dieser Wert auf true gesetzt ist, werden die internen Preflight-Prüfungen ignoriert, wenn Ressourcen auf vorhandene Cluster angewendet werden. Die Standardeinstellung ist false.
Veränderbarkeit: Dieser Wert kann für vorhandene Cluster mit dem Befehl bmctl update geändert werden.
String. Der Pfad zum Dienstkontoschlüssel des Vorgangs
Google Distributed Cloud verwendet das Vorgangsdienstkonto, um sich bei Google Cloud Observability für den Zugriff auf die Logging API und die Monitoring API zu authentifizieren. Mit Ausnahme von Nutzerclustern ist der Dienstkontoschlüssel für den Vorgang erforderlich. Nutzercluster verwenden die Anmeldedaten, die für den verwaltenden Cluster (Administrator- oder Hybridcluster) angegeben wurden.
Sie können Cloud Logging und Cloud Monitoring für Ihre Cluster nicht deaktivieren.
String. Erforderlich. Der Name des Clusters, dem Sie den Knotenpool hinzufügen. Erstellen Sie die Knotenpoolressource im selben Namespace wie der zugehörige Cluster und verweisen Sie in diesem Feld auf den Clusternamen. Weitere Informationen finden Sie unter Knotenpools in einem Cluster hinzufügen und entfernen.
Boolescher Wert. Setzen Sie dieses Feld auf true, um erweiterte Netzwerkfeatures wie gebündeltes Load-Balancing mit BGP oder das NAT-Gateway für ausgehenden Traffic zu aktivieren. Beide Funktionen verwenden das Network Gateway for GDC.
Network Gateway for GDC ist die wichtige Komponente zum Aktivieren erweiterter Netzwerkfeatures in GKE Enterprise und Google Kubernetes Engine (GKE). Einer der Hauptvorteile von Network Gateway für GDC ist, dass es Floating-IP-Adressen dynamisch von einer Reihe von Adressen zuweisen kann, die Sie in einer benutzerdefinierten Ressource vom Typ NetworkGatewayGroup angeben.
Boolescher Wert. Legen Sie in diesem Feld den Wert „false“ fest, um die mit der Google Distributed Cloud-Software gebündelten Ingress-Funktionen zu deaktivieren. Die mit Ihrem Cluster gebündelten Ingress-Funktionen unterstützen nur eingehenden Traffic. Wenn Sie Istio oder Cloud Service Mesh einbinden, um die zusätzlichen Vorteile eines voll funktionsfähigen Service Mesh zu nutzen, empfehlen wir, die gebündelte Ingress-Funktion zu deaktivieren. Dieses Feld ist standardmäßig auf true gesetzt. Dieses Feld ist in der generierten Clusterkonfigurationsdatei nicht vorhanden. Sie können die gebündelte Ingress-Funktion nur für Cluster ab Version 1.13.0 deaktivieren.
Boolescher Wert. Setzen Sie dieses Feld auf true, um das Cluster-Netzwerkmodell im Flatmodus zu aktivieren. Im flachen Modus hat jeder Pod eine eigene, eindeutige IP-Adresse. Pods können direkt miteinander kommunizieren, ohne dass ein Zwischengateway oder eine Network Address Translation (NAT) erforderlich ist.
flatIPv4 ist standardmäßig false. Sie können den flachen Modus nur während der Clustererstellung aktivieren. Nachdem Sie den flachen Modus für Ihren Cluster aktiviert haben, können Sie ihn nicht mehr deaktivieren.
Optional. String. Gibt den Netzwerkmodus für das Dataplane V2-Load Balancing an. Die Quellnetzwerkadressübersetzung (SNAT) ist der Standardnetzwerkmodus. Der DSR-Modus (Direct Server Return) behebt Probleme mit dem SNAT-Load Balancing. Im DSR-Modus (forwardMode: dsr) verwendet der Load Balancer-Knoten IP-Optionen, um die Quelladresse des Clients zu speichern.
Der Netzwerkmodus für das Dataplane V2-Load Balancing kann nur beim Erstellen des Clusters konfiguriert werden.
Erforderlich. Bereich der IPv4-Adressen im CIDR-Blockformat. Geben Sie den Bereich der IP-Adressen an, von denen die virtuelle Dienst-IP-Adressen (VIP-Adressen) zugewiesen werden. Die Bereiche dürfen sich nicht mit Subnetzen überschneiden, die von Ihrem Netzwerk erreichbar sind. Weitere Informationen zur Adresszuweisung für privates Internet finden Sie unter RFC 1918.
Ab der Softwareversion 1.15.0 von Google Distributed Cloud für Bare Metal kann dieses Feld geändert werden. Nach dem Erstellen eines Clusters können Sie bei Bedarf die Anzahl der für Dienste zugewiesenen IP-Adressen erhöhen. Weitere Informationen finden Sie unter Abdeckung des Dienstnetzwerks erhöhen.
Sie können nur den Bereich des IPv4-Dienst-CIDR erhöhen. Der Netzwerkbereich kann nicht reduziert werden. Das bedeutet, dass die Maske (der Wert nach „/“) nicht erhöht werden kann.
Mindest-CIDR-Bereich für Dienste:Maskenwert von /24, was einer Größe von 8 Bit (256 Adressen) entspricht.
Maximaler CIDR-Bereich für Dienste:Maskenwert /12, was einer Größe von 20 Bits (1.048.576 IP-Adressen) entspricht.
Boolescher Wert. Cloud-Audit-Logs sind nützlich, um verdächtige API-Anfragen zu untersuchen und Statistiken zu erfassen. Cloud-Audit-Logs sind standardmäßig aktiviert (disableCloudAuditLogging: false). Legen Sie true fest, um Cloud-Audit-Logs zu deaktivieren.
Dieses Feld wird nicht mehr verwendet und hat keine Auswirkungen. Logging und Monitoring für Anwendungen ist in der benutzerdefinierten Stackdriver-Ressource aktiviert. Weitere Informationen zum Aktivieren von Anwendungs-Logging und -Monitoring finden Sie unter Anwendungs-Logging und -Monitoring aktivieren.
String. Eine Google Cloud Region, in der Sie Monitoring-Messwerte weiterleiten und speichern möchten. Wir empfehlen, eine Region auszuwählen, die sich in der Nähe Ihres lokalen Rechenzentrums befindet. Bei der Clustererstellung wird dieser Wert verwendet, um den Wert clusterLocation in der stackdriver-Ressourcenspezifikation festzulegen.
Der von Ihnen angegebene Wert wird auch von Stackdriver zum Labeln von Messwerten und Protokollen verwendet. Diese Labels können im Metrics Explorer und im Log-Explorer zum Filtern verwendet werden.
Weitere Informationen zu Google Cloud Standorten finden Sie unter Weltweite Standorte. Weitere Informationen zu Routing-Logs und -Messwerten finden Sie unter Routing-Logs und -Messwerte.
String. Die Projekt-ID des Google Cloud-Projekts, in dem Sie Logs und Messwerte aufrufen möchten. Bei der Clustererstellung wird dieser Wert verwendet, um den Wert projectID in der stackdriver-Ressourcenspezifikation festzulegen.
Optional. Im Feld gcpAccounts wird eine Liste der Konten angegeben, denen die Rolle clusterrole/cluster-admin der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) zugewiesen ist. Konten mit dieser Rolle haben vollständigen Zugriff auf alle Ressourcen im Cluster in allen Namespaces. In diesem Feld werden auch die RBAC-Richtlinien konfiguriert, mit denen die angegebenen Konten das Connect-Gateway verwenden können, um kubectl-Befehle für den Cluster auszuführen. Das ist praktisch, wenn Sie mehrere Cluster verwalten müssen, insbesondere in einer Hybridumgebung mit GKE- und On-Premises-Clustern.
In dieses Feld kann ein Array von Kontonamen eingegeben werden. Nutzer- und Dienstkonten werden unterstützt. Geben Sie für Nutzer die E-Mail-Adressen ihrer Google Cloud -Konten an. Geben Sie für Dienstkonten die E-Mail-Adressen im folgenden Format an:
SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com.
Beispiele:
Wenn Sie einen Cluster aktualisieren, um ein Konto hinzuzufügen, müssen Sie alle Konten in die Liste aufnehmen (sowohl bestehende als auch neue Konten). Der Befehl „update“ überschreibt die Liste mit den Angaben in der Aktualisierung.
Dieses Feld gilt nur für Cluster, auf denen Arbeitslasten ausgeführt werden können. Sie können beispielsweise gcpAccounts nicht für Administratorcluster angeben.
Optional. Boolescher Wert (true|false). Aktivieren oder deaktivieren Sie rootlose Bare-Metal-Systemcontainer. Wenn dieses Feld aktiviert ist, werden Bare-Metal-Systemcontainer als Nicht-Root-Nutzer mit einer Nutzer-ID im Bereich 2000–5000 ausgeführt. Wenn diese Option deaktiviert ist, werden Bare-Metal-Systemcontainer als Root-Nutzer ausgeführt. Diese Funktion ist standardmäßig aktiviert. Wir raten dringend davon ab, diese Funktion zu deaktivieren, da das Ausführen von Containern als Root-Nutzer ein Sicherheitsrisiko darstellt. Nach der Clustererstellung kann dieses Feld nur während des Upgrades aktiviert oder deaktiviert werden. Weitere Informationen finden Sie unter Container nicht als Root-Nutzer ausführen.
Optional. Boolesch (true|false). Clusterweite seccomp aktivieren oder deaktivieren. Wenn dieses Feld deaktiviert ist, werden Container ohne seccomp-Profil in der Clusterkonfigurationsdatei uneingeschränkt ausgeführt. Wenn dieses Feld aktiviert ist, werden diese Container mit dem standardmäßigen seccomp-Profil der Containerlaufzeit gesichert. Dieses Feature ist standardmäßig aktiviert.
Nach der Clustererstellung kann dieses Feld nur während des Upgrades aktiviert oder deaktiviert werden.
Weitere Informationen finden Sie unter seccomp zum Einschränken von Containern verwenden.
Optional. Integer. Standardwert: 2000. Systemcontainer in der Google Distributed Cloud-Software helfen bei der Installation und Verwaltung von Clustern.
Die von diesen Containern verwendeten Nutzer-IDs (User IDs, UIDs) und Gruppen-IDs (Group IDs, GIDs) können über das Feld startUIDRangeRootlessContainers in der Clusterspezifikation gesteuert werden. Die Systemcontainer verwenden die UIDs und GIDs im Bereich von startUIDRangeRootlessContainers bis startUIDRangeRootlessContainers + 2999, was standardmäßig einen Bereich von 2000 bis 4999 ergibt. Wählen Sie beim Aktualisieren von startUIDRangeRootlessContainers einen Wert aus, der dafür sorgt, dass sich die von den Systemcontainern verwendeten UID- und GID-Bereiche nicht mit denen überschneiden, die Nutzerarbeitslasten zugewiesen sind. Der Wert startUIDRangeRootlessContainers kann nur während eines Upgrades geändert werden.
Optional. Ein Array von Strings (Domainnamen und IP-Adressen). Ein SAN (Subject Alternative Name) ist eine Funktion von SSL-Zertifikaten, mit der Sie die Domainnamen und Subdomains definieren können, für die ein Zertifikat gültig sein soll. In einem Bare-Metal-Cluster enthalten die SANs für das API-Serverzertifikat standardmäßig die IP- und VIP-Adressen der Knoten der Steuerungsebene und die Kubernetes-DNS-Namen. Verwenden Sie dieses Feld, um dem API-Serverzertifikat für den Cluster zusätzliche SANs hinzuzufügen. Domainnamen müssen RFC 1035 entsprechen.
Weitere Informationen finden Sie unter Domains zum API-Serverzertifikat hinzufügen.
In diesem Abschnitt werden die IP-Adressen für den Knotenpool angegeben, der von der Steuerungsebene und deren Komponenten verwendet wird. Die Knotenpoolspezifikation des Steuerebenen (wie die Spezifikation des Load-Balancer-Knotenpools) ist besonders. In dieser Spezifikation werden kritische Clusterressourcen deklariert und gesteuert. Die kanonische Quelle für diese Ressource ist dieser Abschnitt in der Cluster-Konfigurationsdatei. Ändern Sie nicht die Knotenpoolressourcen der obersten Steuerungsebene. Ändern Sie stattdessen die zugehörigen Abschnitte in der Cluster-Konfigurationsdatei.
Optional. Ganzzahl (nicht negativ). Gibt die maximale Anzahl von Image-Pull-Anfragen an, die der Verarbeitungswarteschlange hinzugefügt werden können, um Spitzen bei Anfragen zu bewältigen. Sobald ein Pull-Vorgang beginnt, kann eine neue Anfrage zur Warteschlange hinzugefügt werden. Der Standardwert ist 10. Dieses Feld entspricht der Option registryBurst für die Kubelet-Konfiguration (v1beta1).
Der Wert für registryPullQPS hat Vorrang vor dieser Einstellung. Bei den Standardeinstellungen sind beispielsweise Bursts von bis zu 10 gleichzeitigen Abfragen zulässig, sie müssen jedoch mit der Standardrate von fünf Abfragen pro Sekunde verarbeitet werden. Dieses Burst-Verhalten wird nur verwendet, wenn registryPullQPS größer als 0 ist.
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Optional. Ganzzahl (nicht negativ). Gibt die Verarbeitungsrate für Abfragen für das Abrufen von Container Registry-Images in Abfragen pro Sekunde an.
Wenn registryPullQPS auf einen Wert größer als 0 gesetzt ist, wird die Abfragerate auf diese Anzahl von Abfragen pro Sekunde beschränkt. Wenn registryPullQPS auf 0 festgelegt ist, gibt es keine Beschränkung der Abfragerate. Der Standardwert ist 5.
Dieses Feld entspricht der Option registryPullQPS für die Kubelet-Konfiguration (v1beta1).
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Optional. Boolesch (true|false). Dieses Feld gibt an, ob Container Registry-Pull-Vorgänge parallel oder einzeln verarbeitet werden. Die Standardeinstellung ist true, was bedeutet, dass Pull-Vorgänge einzeln verarbeitet werden. Wenn dieser Wert auf false gesetzt ist, ruft kubelet Images parallel ab. Dieses Feld entspricht der Option serializeImagePulls für die Kubelet-Konfiguration (v1beta1).
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Erforderlich. Ein Array von IP-Adressen. In der Regel ist dieses Array entweder eine IP-Adresse für eine einzelne Maschine oder IP-Adressen für drei Maschinen für eine Hochverfügbarkeitsbereitstellung.
Erforderlich. String (IPv4-Adresse). Wenn Sie einen Knotenpool angeben, verwenden Sie das Feld address, um die Standard-IPv4-Adresse für den SSH-Zugriff für jeden Knoten anzugeben. Der SSH-Zugriff ist für administrative Clustervorgänge wie Installationen und Upgrades erforderlich. Standardmäßig wird diese IP-Adresse auch für Daten- und Kubernetes-Traffic verwendet. Wenn Sie jedoch die k8sIP-Adresse für einen bestimmten Knoten angeben, wird der Traffic auf die beiden Adressen für den Knoten aufgeteilt, wobei die k8sIP-Adresse ausschließlich für Daten- und Kubernetes-Traffic verwendet wird. “
Optional. String (IPv4-Adresse). Wenn Sie die optionale k8sIP-Adresse für einen Knoten angeben, ist diese für die Verarbeitung von Daten und Kubernetes-Traffic für den Knoten vorgesehen, z. B. Anfragen und Antworten für die Kubernetes API, das Kubelet und Arbeitslasten. “ Wenn Sie k8sIP angeben, wird die Standardknoten-IP-Adresse nodePoolSpec.nodes.address ausschließlich für SSH-Verbindungen zum Knoten verwendet. Wenn Sie keine k8sIP-Adresse angeben, wird der gesamte Traffic für den Knoten über die Standardknoten-IP-Adresse verwaltet.
Optional. String. Standardwert: global.
Die Flottenmitgliedschaft Ihrer Cluster wird vom Flottendienst (gkehub.googleapis.com) und vom Connect-Dienst (gkeconnect.googleapis.com) verwaltet. Die Flottenmitgliedschaft kann global oder regional sein. Optional können Sie mit gkeConnect.location die Region angeben, Google Cloud in der die Flotten- und Connect-Dienste ausgeführt werden, damit der Traffic auf Ihre Region beschränkt wird.
Eine Liste der unterstützten Regionen finden Sie unter Unterstützte Regionen für die GKE On-Prem API.
Wenn keine Angabe erfolgt, werden die globalen Instanzen der Dienste verwendet.
Wichtige Hinweise:
Cluster, die mit einer niedrigeren Version als 1.28 erstellt wurden, werden von den globalen Flotten- und Connect-Diensten verwaltet.
Für neue Cluster, die mit GKE On-Prem API-Clients wie der Google Cloud Console, der Google Cloud CLI oder Terraform erstellt wurden, wird die Region verwendet, die Sie auch für die GKE On-Prem API angeben.
Wenn Sie dieses Feld bei neuen Clustern angeben, muss die von Ihnen angegebene Region mit der in gkeOnPremAPI.location konfigurierten Region übereinstimmen. Wenn die Regionen nicht identisch sind, schlägt die Cluster-Erstellung fehl.
Erforderlich: String. Die ID des Google Cloud-Projekts, das Sie zum Herstellen einer Verbindung Ihres Clusters zu Google Cloudverwenden möchten. Dieses Projekt wird auch als Flotten-Hostprojekt bezeichnet.
String. Der Pfad zum Agent-Dienstkontoschlüssel.
Google Distributed Cloud verwendet dieses Dienstkonto, um eine Verbindung zwischen Ihren On-Premises-Clustern und Google Cloudaufrechtzuerhalten.
String. Der Pfad zum Dienstkontoschlüssel für die Registrierung
Google Distributed Cloud verwendet dieses Dienstkonto, um Ihre Nutzercluster bei Google Cloudzu registrieren.
Wenn ab 1.16 und höher die GKE On-Prem API in Ihrem Google Cloud-Projekt aktiviert ist, werden alle Cluster im Projekt automatisch in der GKE On-Prem API in der Region angemeldet, die in clusterOperations.location konfiguriert wurde.
Wenn Sie alle Cluster im Projekt für die GKE On-Prem API registrieren möchten, müssen Sie die Schritte unter Vorbereitung zur Aktivierung und Verwendung der GKE On-Prem API im Projekt ausführen.
Wenn Sie den Cluster nicht in der GKE On-Prem API registrieren möchten, fügen Sie
diesen Abschnitt hinzu und setzen Sie gkeOnPremAPI.enabled auf false.
Wenn Sie keine Cluster in dem Projekt registrieren möchten, deaktivieren Sie gkeonprem.googleapis.com (der Dienstname für die GKE On-Prem API) in dem Projekt. Eine Anleitung finden Sie unter Dienste deaktivieren.
Wenn Sie alle Cluster im Projekt für die GKE On-Prem API registrieren möchten, müssen Sie die Schritte unter Vorbereitung zur Aktivierung und Verwendung der GKE On-Prem API im Projekt ausführen.
Wenn Sie den Cluster nicht in der GKE On-Prem API registrieren möchten, fügen Sie
diesen Abschnitt hinzu und setzen Sie gkeOnPremAPI.enabled auf false.
Wenn Sie keine Cluster in dem Projekt registrieren möchten, deaktivieren Sie gkeonprem.googleapis.com (der Dienstname für die GKE On-Prem API) in dem Projekt. Eine Anleitung finden Sie unter Dienste deaktivieren.
Wenn Sie Ihren Administrator- oder Nutzercluster in der GKE On-Prem API registrieren, können Sie Standardtools wie die Google Cloud Console, die Google Cloud CLI oder
Terraform verwenden, um Clusterdetails aufzurufen und den Clusterlebenszyklus zu verwalten. Sie können beispielsweise gcloud-Befehle ausführen, um
Informationen zu Ihrem Cluster abzurufen.
Die GKE On-Prem API speichert Metadaten zum Clusterstatus in Google Cloud.
Diese Metadaten ermöglichen der API die Verwaltung des Clusterlebenszyklus. Die Standardtools verwenden die GKE On-Prem API und werden zusammen als GKE On-Prem API-Clients bezeichnet.
Wenn Sie gkeOnPremAPI.enabled auf true festgelegt haben, müssen Sie die Schritte unter Vorbereitung ausführen, um die GKE On-Prem API zu aktivieren und zu initialisieren, bevor Sie den Cluster mit bmctl erstellen oder aktualisieren.
Wenn Sie diesen Abschnitt hinzufügen und den Cluster erstellen oder aktualisieren und ihn dann entfernen und den Cluster aktualisieren, schlägt die Aktualisierung fehl.
Wenn Sie den Cluster lieber mit einem Standardtool als mit bmctl erstellen möchten, lesen Sie Folgendes:
Standardmäßig wird der Cluster in der GKE On-Prem API registriert, wenn die GKE On-Prem API in Ihrem Projekt aktiviert ist. Legen Sie false fest, wenn Sie den Cluster nicht registrieren möchten.
Wenn Sie den Cluster in der GKE On-Prem API registriert haben und die Registrierung aufheben müssen, nehmen Sie die folgende Änderung vor und aktualisieren Sie dann den Cluster:
Die Google Cloud Region, in der die GKE On-Prem API ausgeführt wird und Clustermetadaten speichert. Wählen Sie eine der
unterstützten Regionen aus. Muss ein nicht leerer String sein, wenn gkeOnPremAPI.enabledtrue ist. Wenn gkeOnPremAPI.enabledfalse ist, schließen Sie dieses Feld nicht ein.
Wenn dieser Abschnitt nicht in der Konfigurationsdatei enthalten ist, wird dieses Feld auf clusterOperations.location festgelegt.
Definiert die Konfiguration für den IPv4-CIDR-Bereich. Für die Ressource ClusterCidrConfig muss mindestens eines der Felder ipv4 oder ipv6 angegeben werden.
String. Legt den IPv4-Knoten-CIDR-Block fest. Knoten können nur einen Bereich aus jeder Familie haben. Dieser CIDR-Block muss mit dem in der Cluster-Ressource beschriebenen Pod-CIDR übereinstimmen.
Integer. Definiert die Maskengröße für den IPv4-CIDR-Block des Knotens. Beispiel: Der Wert 24 wird in die Subnetzmaske /24 umgewandelt. Die Netzmaske des CIDR-Blocks des Knotens muss größer sein als die maximale Anzahl von Pods, die der kubelet planen kann. Diese wird im Flag --max-pods des kubelets definiert.
Definiert die Konfiguration für den IPv6-CIDR-Bereich. Für die Ressource ClusterCidrConfig muss mindestens eines der Felder ipv4 oder ipv6 angegeben werden.
Integer. Definiert die Maskengröße für den IPv6-CIDR-Block des Knotens. Beispiel: Der Wert 120 wird in die Subnetzmaske /120 umgewandelt. Die Netzmaske des CIDR-Blocks des Knotens muss größer sein als die maximale Anzahl von Pods, die der kubelet planen kann. Diese wird im Flag --max-pods des kubelets definiert.
Optional. Ganzzahl (nicht negativ). Gibt die maximale Anzahl von Image-Pull-Anfragen an, die der Verarbeitungswarteschlange hinzugefügt werden können, um Spitzen bei Anfragen zu bewältigen. Sobald ein Pull-Vorgang beginnt, kann eine neue Anfrage zur Warteschlange hinzugefügt werden. Der Standardwert ist 10. Dieses Feld entspricht der Option registryBurst für die Kubelet-Konfiguration (v1beta1).
Der Wert für registryPullQPS hat Vorrang vor dieser Einstellung. Bei den Standardeinstellungen sind beispielsweise Bursts von bis zu 10 gleichzeitigen Abfragen zulässig, sie müssen jedoch mit der Standardrate von fünf Abfragen pro Sekunde verarbeitet werden. Dieses Burst-Verhalten wird nur verwendet, wenn registryPullQPS größer als 0 ist.
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Optional. Ganzzahl (nicht negativ). Gibt die Verarbeitungsrate für Abfragen für das Abrufen von Container Registry-Images in Abfragen pro Sekunde an.
Wenn registryPullQPS auf einen Wert größer als 0 gesetzt ist, wird die Abfragerate auf diese Anzahl von Abfragen pro Sekunde beschränkt. Wenn registryPullQPS auf 0 festgelegt ist, gibt es keine Beschränkung der Abfragerate. Der Standardwert ist 5.
Dieses Feld entspricht der Option registryPullQPS für die Kubelet-Konfiguration (v1beta1).
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Optional. Boolesch (true|false). Dieses Feld gibt an, ob Container Registry-Pull-Vorgänge parallel oder einzeln verarbeitet werden. Die Standardeinstellung ist true, was bedeutet, dass Pull-Vorgänge einzeln verarbeitet werden. Wenn dieser Wert auf false gesetzt ist, ruft kubelet Images parallel ab. Dieses Feld entspricht der Option serializeImagePulls für die Kubelet-Konfiguration (v1beta1).
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Veraltet. Ab Release 1.11.2 können Sie die VM-Laufzeit in GDC aktivieren oder deaktivieren, indem Sie nur die benutzerdefinierte Ressource „VMRuntime“ aktualisieren.
Boolescher Wert. Bestimmt, ob die Softwareemulation zum Ausführen virtueller Maschinen verwendet wird. Wenn der Knoten die Hardwarevirtualisierung unterstützt, setzen Sie useEmulation auf false, um eine bessere Leistung zu erzielen. Legen Sie true fest, wenn die Hardwarevirtualisierung nicht unterstützt wird oder Sie sich nicht sicher sind.
Optional. Zuordnung (Schlüssel/Wert-Paare).
Labels werden auf die Knoten des Knotenpools abgeglichen, sofern die Annotation baremetal.cluster.gke.io/label-taint-no-sync nicht auf den Cluster angewendet wird. Weitere Informationen zu Labels finden Sie unter Labels und Selektoren.
Objekt. Der Name und ein Array von IP-Adressen für den Cluster des Load-Balancers. Die Konfiguration des Adresspools ist nur für den Load-Balancer-Modus bundled in Clustern ohne Administrator gültig. Sie können jederzeit neue Adresspools hinzufügen, aber keine vorhandenen Adresspools entfernen.
Ein vorhandener Adresspool kann nur bearbeitet werden, um die Felder avoidBuggyIPs und manualAssign zu ändern.
Array von IP-Adressbereichen. Geben Sie eine Liste der nicht überlappenden IP-Bereiche für den Load-Balancer der Datenebene an. Alle Adressen müssen sich im selben Subnetz wie die Load-Balancer-Knoten befinden.
Optional. Boolescher Wert (true | false). Wenn true, werden die IP-Adressen weggelassen, die auf .0 und .255 enden.
Bestimmte Netzwerkhardware führt zu einem Rückgang des Traffics zu diesen speziellen Adressen. Sie können dieses Feld weglassen. Der Standardwert ist false.
Optional. Boolescher Wert (true | false). Bei true werden Adressen in diesem Pool nicht automatisch Kubernetes-Diensten zugewiesen. Bei true wird eine IP-Adresse in diesem Pool nur verwendet, wenn sie explizit von einem Dienst angegeben wird. Sie können dieses Feld weglassen. Der Standardwert ist false.
Optional. Objekt (Liste der Zuordnungen). In diesem Abschnitt werden ein oder mehrere BGP-Peers (Border Gateway Protocol) von Ihrem lokalen Netzwerk (außerhalb des Clusters) angegeben. Sie geben BGP-Peers an, wenn Sie den Load-Balancing-Teil der Steuerungsebene der gebündelten Load-Balancing-Lösung einrichten, die BGP verwendet. Jeder Peer wird mit einer Zuordnung angegeben, die aus einer IP-Adresse, einer autonomen Systemnummer (ASN) und optional einer Liste mit einer oder mehreren IP-Adressen für Knoten der Steuerungsebene besteht. Die BGP-Peering-Konfiguration für das Load-Balancing der Steuerungsebene kann nach dem Erstellen des Clusters nicht aktualisiert werden.
Optional. String. Die autonome Systemnummer für das Netzwerk, das das externe Peer-Gerät enthält Geben Sie eine ASN für jeden BGP-Peer an, den Sie für das Load-Balancing der Steuerungsebene eingerichtet haben, wenn Sie die gebündelte Load-Balancing-Lösung einrichten, die BGP verwendet.
Weitere Informationen finden Sie unter Gebündelte Load-Balancer mit BGP konfigurieren.
Optional. Array von IP-Adressen (IPv4) Eine oder mehrere IP-Adressen für Knoten der Steuerungsebene, die eine Verbindung zum externen BGP-Peer herstellen, wenn Sie die gebündelte Load-Balancing-Lösung einrichten, die BGP verwendet. Wenn Sie keine Steuerungsebenenknoten angeben, werden alle Steuerungsebenenknoten mit dem externen Peer verbunden. Wenn Sie eine oder mehrere IP-Adressen angeben, nehmen nur die angegebenen Knoten an Peering-Sitzungen teil.
Weitere Informationen finden Sie unter Gebündelte Load-Balancer mit BGP konfigurieren.
Optional. String (IPv4-Adresse) Die IP-Adresse eines externen Peering-Geräts aus Ihrem lokalen Netzwerk
Weitere Informationen finden Sie unter Gebündelte Load-Balancer mit BGP konfigurieren.
Optional. String. Gibt die Nummer des autonomen Systems (Autonomous System Number, ASN) für den zu erstellenden Cluster an. Dieses Feld wird beim Einrichten der gebündelten Load-Balancing-Lösung verwendet, die BGP (Border Gateway Protocol) verwendet.
Weitere Informationen finden Sie unter Gebündelte Load-Balancer mit BGP konfigurieren.
Erforderlich. String. Gibt den Load-Balancing-Modus an. Im bundled-Modus installiert die Google Distributed Cloud-Software während der Clustererstellung einen Load Balancer auf Load Balancer-Knoten. Im manual-Modus benötigt der Cluster einen manuell konfigurierten externen Load-Balancer. Weitere Informationen finden Sie unter Load-Balancer – Übersicht.
Optional. In diesem Abschnitt konfigurieren Sie einen Load-Balancer-Knotenpool. Die von Ihnen angegebenen Knoten sind Teil des Kubernetes-Clusters und führen reguläre Arbeitslasten und Load-Balancer aus. Wenn Sie keinen Knotenpool angeben, werden die Knoten der Steuerungsebene für das Load-Balancing verwendet. Dieser Abschnitt gilt nur, wenn der Load-Balancing-Modus auf bundled gesetzt ist.
Wenn Sie verhindern möchten, dass Arbeitslasten auf einem Knoten im Load Balancer-Knotenpool ausgeführt werden, fügen Sie dem Knoten die folgende Markierung hinzu:
node-role.kubernetes.io/load-balancer:NoSchedule
Die Google Distributed Cloud-Software fügt den Pods, die für das Load Balancing erforderlich sind, Toleranzen für diese Markierung hinzu.
Optional. Ganzzahl (nicht negativ). Gibt die maximale Anzahl von Image-Pull-Anfragen an, die der Verarbeitungswarteschlange hinzugefügt werden können, um Spitzen bei Anfragen zu bewältigen. Sobald ein Pull-Vorgang beginnt, kann eine neue Anfrage zur Warteschlange hinzugefügt werden. Der Standardwert ist 10. Dieses Feld entspricht der Option registryBurst für die Kubelet-Konfiguration (v1beta1).
Der Wert für registryPullQPS hat Vorrang vor dieser Einstellung. Bei den Standardeinstellungen sind beispielsweise Bursts von bis zu 10 gleichzeitigen Abfragen zulässig, sie müssen jedoch mit der Standardrate von fünf Abfragen pro Sekunde verarbeitet werden. Dieses Burst-Verhalten wird nur verwendet, wenn registryPullQPS größer als 0 ist.
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Optional. Ganzzahl (nicht negativ). Gibt die Verarbeitungsrate für Abfragen für das Abrufen von Container Registry-Images in Abfragen pro Sekunde an.
Wenn registryPullQPS auf einen Wert größer als 0 gesetzt ist, wird die Abfragerate auf diese Anzahl von Abfragen pro Sekunde beschränkt. Wenn registryPullQPS auf 0 festgelegt ist, gibt es keine Beschränkung der Abfragerate. Der Standardwert ist 5.
Dieses Feld entspricht der Option registryPullQPS für die Kubelet-Konfiguration (v1beta1).
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Optional. Boolesch (true|false). Dieses Feld gibt an, ob Container Registry-Pull-Vorgänge parallel oder einzeln verarbeitet werden. Die Standardeinstellung ist true, was bedeutet, dass Pull-Vorgänge einzeln verarbeitet werden. Wenn dieser Wert auf false gesetzt ist, ruft kubelet Images parallel ab. Dieses Feld entspricht der Option serializeImagePulls für die Kubelet-Konfiguration (v1beta1).
Dieses Feld kann beim Erstellen, Aktualisieren oder Upgraden eines Clusters festgelegt werden. Die Einstellung bleibt auch nach Cluster-Upgrades erhalten. Weitere Informationen finden Sie unter Kubelet-Image-Pull-Einstellungen konfigurieren.
Dieser Abschnitt enthält ein Array von IP-Adressen für die Knoten im Load-Balancer-Knotenpool.
Alle Knoten im Knotenpool des Load-Balancers müssen sich standardmäßig im selben Layer-2-Subnetz befinden wie die Load-Balancer-VIPs, die im Abschnitt loadBalancer.addressPools der Konfigurationsdatei konfiguriert wurden. Wenn Sie jedoch eine Kubernetes-IP-Adresse k8sIP für einen Knoten angeben, muss sich nur diese Adresse im selben Layer-2-Subnetz befinden wie die anderen Load Balancer-VIPs.
Optional. String (IPv4-Adresse). Wenn Sie einen Knotenpool angeben, verwenden Sie das Feld address, um die Standard-IPv4-Adresse für den SSH-Zugriff für jeden Knoten anzugeben. Der SSH-Zugriff ist für administrative Clustervorgänge wie Installationen und Upgrades erforderlich. Standardmäßig wird diese IP-Adresse auch für Daten- und Kubernetes-Traffic verwendet. Wenn Sie jedoch die k8sIP-Adresse für einen bestimmten Knoten angeben, wird der Traffic auf die beiden Adressen für den Knoten aufgeteilt, wobei die k8sIP-Adresse ausschließlich für Daten- und Kubernetes-Traffic verwendet wird. “
Die Knoten im Load Balancer-Knotenpool können zwar Arbeitslasten ausführen, sind aber von den Knoten in den Worker-Knotenpools getrennt. Sie können einen bestimmten Clusterknoten nicht in mehr als einem Knotenpool angeben. Überlappende Knoten-IP-Adressen blockieren die Clustererstellung und andere Clustervorgänge.
Optional. String (IPv4-Adresse). Wenn Sie die optionale k8sIP-Adresse für einen Knoten angeben, ist diese für die Verarbeitung von Daten und Kubernetes-Traffic für den Knoten vorgesehen, z. B. Anfragen und Antworten für die Kubernetes API, das Kubelet und Arbeitslasten. “ Wenn Sie k8sIP angeben, wird die Standardknoten-IP-Adresse nodePoolSpec.nodes.address ausschließlich für SSH-Verbindungen zum Knoten verwendet. Wenn Sie keine k8sIP-Adresse angeben, wird der gesamte Traffic für den Knoten über die Standardknoten-IP-Adresse verwaltet.
Optional. String. Gibt den Typ des verwendeten gebündelten Load-Balancings, Layer-2 oder Border Gateway Protocol (BGP) an. Setzen Sie type auf layer2, wenn Sie das Standard-Paket-Load-Balancing verwenden. Setzen Sie type auf bgp, wenn Sie das gebündelte Load-Balancing mit BGP verwenden. Wenn Sie type nicht festlegen, wird standardmäßig layer2 verwendet.
Erforderlich. Gibt die virtuelle IP-Adresse (VIP) an, die eine Verbindung zum Kubernetes API-Server herstellen soll. Diese Adresse darf nicht in den Bereich der IP-Adressen loadBalancer.addressPools.addresses fallen, die für Load-Balancer-Adresspools verwendet werden.
Optional. Einzelne IPv4-Adresse oder ein Bereich von IPv4-Adressen. Geben Sie die IP-Adressen der Knotenmaschinen an, die in den Wartungsmodus versetzt werden sollen. Weitere Informationen finden Sie unter Knoten in den Wartungsmodus versetzen.
Beispiel:
maintenanceBlocks:cidrBlocks:-192.168.1.200# Single machine-192.168.1.100-192.168.1.109# Ten machines
Erforderlich. String. In der Regel verwendet der Namespace-Name ein Muster von cluster-CLUSTER_NAME, aber das Präfix cluster- ist seit Google Distributed Cloud-Softwarerelease 1.7.2 nicht zwingend erforderlich.
Dieser Wert kann nicht für vorhandene Cluster geändert werden.
Optional. String. Geben Sie den Nicht-Root-Nutzernamen an, den Sie für den SUDO-Funktionszugriff ohne Passwort auf die Knotenmaschinen in Ihrem Cluster verwenden möchten. Der SSH-Schlüssel sshPrivateKeyPath muss für den angegebenen Nutzer funktionieren. Mit den Vorgängen zum Erstellen und Aktualisieren von Clustern wird geprüft, ob auf Knotencomputer mit dem angegebenen Nutzer und SSH-Schlüssel zugegriffen werden kann.
Verworfen. Ab Version 1.13.0 unterstützt Google Distributed Cloud nur noch containerd als Containerlaufzeit. Das Feld containerRuntime wurde verworfen und aus der generierten Clusterkonfigurationsdatei entfernt. Wenn Ihre Clusterkonfigurationsdatei für die Google Distributed Cloud-Softwareversionen 1.13.0 und höher dieses Feld enthält, muss der Wert containerd sein.
Optional. Integer. Gibt die maximale Anzahl von Pods an, die auf einem einzelnen Knoten ausgeführt werden können. Für selbstverwaltete Cluster sind die zulässigen Werte für maxPodsPerNode32–250 für Hochverfügbarkeitscluster (HA) und 64–250. für Nicht-HA-Cluster. Für Nutzercluster sind zulässige Werte für maxPodsPerNode32–250. Der Standardwert, wenn nicht angegeben, ist 110. Nachdem der Cluster erstellt wurde, kann dieser Wert nicht mehr aktualisiert werden.
Kubernetes weist jedem Knoten einen CIDR-Block (Classless Inter-Domain Routing) zu, sodass jeder Pod eine eindeutige IP-Adresse haben kann. Die Größe des CIDR-Blocks entspricht der maximalen Anzahl von Pods pro Knoten.
Weitere Informationen zum Festlegen der maximalen Anzahl von Pods pro Knoten finden Sie unter Pod-Netzwerke.
In diesem Abschnitt wird eine private Registry-Konfiguration auf Knotenebene für Nutzercluster angegeben. Private Registrierungen auf Knotenebene sind für die Verwendung mit Ihren Arbeitslasten vorgesehen. So haben Sie mehr Kontrolle über das Abrufen von Images und die damit verbundene Sicherheit.
Bei Administratorclustern wird die private Registry auf Knotenebene im Abschnitt „Anmeldedaten“ der Konfigurationsdatei des Administratorclusters angegeben.
Geben Sie in diesem Abschnitt gegebenenfalls den Namen und den Namensbereich des Secrets an, das zum Speichern des CA-Zertifikats (Server-Stamm-CA) für die private Registry erstellt wurde. Wenn Ihre lokale Registry kein privates TLS-Zertifikat erfordert, können Sie diesen Block weglassen.
In der folgenden Liste ist die Einführungsphase pro Version für die Konfiguration einer privaten Registry auf Knotenebene aufgeführt:
String. In diesem Feld werden der Host und der Port für eine einzelne private Registry angegeben. Sie können den Host entweder mit einem Domainnamen oder mit einer IP-Adresse angeben. Geben Sie nicht das Präfix http oder https an.
Das Feld host ist erforderlich, wenn Sie eine private Registry für einen Nutzercluster angeben.
In der folgenden Liste ist die Einführungsphase pro Version für die Konfiguration einer privaten Registry auf Knotenebene aufgeführt:
Geben Sie in diesem Abschnitt gegebenenfalls den Namen und den Namespace des Secrets an, das zum Speichern der Anmeldedaten für die private Registry erstellt wurde.
Verwenden Sie den Block pullCredentialSecretRef, wenn Sie einen Nutzercluster konfigurieren, um Knoten Zugriff auf eine private Registry zu gewähren, für die eine Authentifizierung erforderlich ist.
In der folgenden Liste ist die Einführungsphase pro Version für die Konfiguration einer privaten Registry auf Knotenebene aufgeführt:
Optional. Dieser Abschnitt enthält Einstellungen für die Konfiguration der Upgrade-Strategie für die Worker-Knotenpools in Ihrem Cluster. Weitere Informationen finden Sie unter Parallele Upgrades.
Optional. Boolescher Wert (0 oder 1). Standard: 1.
In diesem Feld wird angegeben, ob alle Worker-Knotenpools für einen Cluster gleichzeitig aktualisiert werden sollen. Führen Sie standardmäßig ein Upgrade (1) nacheinander aus. Wenn Sie concurrentNodePools auf 0 festlegen, wird jeder Worker-Knotenpool im Cluster parallel aktualisiert.
Optional. Boolescher Wert (true oder false). Standard:
false. In diesem Feld wird angegeben, ob ein aktives Clusterupgrade pausiert oder fortgesetzt werden soll.
Optional. Boolescher Wert (true | false). Gibt an, ob anstelle des Standard-Docker-apt-Repositories ein eigener Paket-Repository-Server verwendet werden soll. Wenn Sie stattdessen Ihr eigenes Paket-Repository verwenden möchten, legen Sie addPackageRepo auf false fest. Verwenden Sie diese Funktion, um das Hinzufügen von Paket-Repositories zu jeder Bare-Metal-Maschine in Ihrer Bereitstellung zu überspringen. Weitere Informationen finden Sie unter Privaten Paket-Repository-Server verwenden.
Dieser Abschnitt enthält Konfigurationsinformationen für regelmäßige Systemdiagnosen. In der Clusterressource ist die einzige verfügbare Einstellung für regelmäßige Systemdiagnosen das Feld enable. Weitere Informationen finden Sie unter Regelmäßige Systemdiagnosen.
Optional. Boolescher Wert (true|false). Aktivieren oder deaktivieren Sie regelmäßige Systemdiagnosen für Ihren Cluster. Regelmäßige Systemdiagnosen sind standardmäßig für alle Cluster aktiviert. Sie können regelmäßige Systemdiagnosen für einen Cluster deaktivieren, indem Sie das Feld periodicHealthCheck.enable auf false setzen.
Weitere Informationen finden Sie unter Regelmäßige Systemdiagnosen deaktivieren.
Optional. In diesem Abschnitt können Sie eine private Registry für Arbeitslast-Images angeben. Diese Methode zum Konfigurieren der privaten Registry im Abschnitt „Anmeldedaten“ der Clusterkonfigurationsdatei ist für hybride oder eigenständige Cluster gedacht, die nur Worker-Knotenpools haben.
Optional. String. Pfad der CA-Zertifikatsdatei (Server-Stamm-CA), wenn Ihr Registry-Server ein privates TLS-Zertifikat verwendet. Wenn Ihre lokale Registry kein privates TLS-Zertifikat erfordert, können Sie dieses Feld weglassen.
String. In diesem Feld werden der Host und der Port für eine einzelne private Registry angegeben. Sie können den Host entweder mit einem Domainnamen oder mit einer IP-Adresse angeben. Geben Sie nicht das Präfix http oder https an.
Das Feld host ist erforderlich, wenn Sie eine private Registry für einen Hybrid- oder eigenständigen Cluster angeben.
Optional. String. Pfad zur Docker-Befehlszeilen-Konfigurationsdatei, config.json. Docker speichert die Authentifizierungseinstellungen in der Konfigurationsdatei. Dieses Feld gilt nur für die Verwendung privater Registries auf Knotenebene.
Verwenden Sie das Feld pullCredentialConfigPath, wenn Sie einen hybriden oder eigenständigen Cluster konfigurieren, um Knoten Zugriff auf eine private Registry zu gewähren, für die eine Authentifizierung erforderlich ist.
Optional. String. Wenn profile für einen eigenständigen Cluster auf edge gesetzt ist, wird der Ressourcenverbrauch des Clusters minimiert. Das Edge-Profil ist nur für eigenständige Cluster verfügbar.
Das Edge-Profil hat weniger Systemressourcenanforderungen und wird für Edge-Geräte mit restriktiven Ressourceneinschränkungen empfohlen.
Informationen zu Hardwareanforderungen, die mit dem Edge-Profil verknüpft sind, finden Sie unter Ressourcenanforderungen für eigenständige Cluster mit dem Edge-Profil.
String. Eine durch Kommas getrennte Liste mit IP-Adressen, IP-Adressbereichen, Hostnamen und Domainnamen, die nicht durch den Proxyserver geleitet werden sollen. Wenn Ihr Cluster eine Anfrage an eine dieser Adressen, Hosts oder Domains sendet, wird die Anfrage direkt gesendet.
Optional. In diesem Abschnitt geben Sie anstelle von Container Registry (gcr.io) einen Registry-Spiegel an, der für die Installation von Clustern verwendet werden soll. Weitere Informationen zur Verwendung eines Registry-Spiegels finden Sie unter Registry-Spiegel für Container-Images verwenden.
Optional. String. Pfad der CA-Zertifikatsdatei (Server-Stamm-CA), wenn Ihr Registry-Server ein privates TLS-Zertifikat verwendet. Wenn Ihre lokale Registry kein privates TLS-Zertifikat erfordert, können Sie dieses Feld weglassen.
String. Der Endpunkt des Spiegels, bestehend aus der IP-Adresse und der Portnummer des Registry-Servers. Optional können Sie Ihren eigenen Namespace in Ihrem Registry-Server anstelle des Root-Namespace verwenden. Ohne Namespace ist das Endpunktformat REGISTRY_IP:PORT. Wenn Sie einen Namespace verwenden, hat das Endpunktformat REGISTRY_IP:PORT/v2/NAMESPACE.
/v2 ist erforderlich, wenn ein Namespace angegeben wird.
Das Feld endpoint ist erforderlich, wenn Sie einen Registrierungsspiegel angeben. Sie können mehrere Spiegel/Endpunkte angeben.
Optional. Ein Array von Domainnamen für Hosts, die lokal für den angegebenen Registry-Spiegel (endpoint) gespiegelt werden. Wenn die Containerlaufzeit Pull-Anfragen für Images von einem bestimmten Host erhält, wird zuerst der lokale Registry-Spiegel geprüft. Weitere Informationen finden Sie unter Cluster aus dem Registry-Mirror erstellen.
Optional. String. Pfad zur Docker-Befehlszeilen-Konfigurationsdatei, config.json. Docker speichert die Authentifizierungseinstellungen in der Konfigurationsdatei. Dieses Feld gilt nur für die Verwendung von Registry-Spiegelungen. Wenn Ihr Registry-Server keine Docker-Konfigurationsdatei für die Authentifizierung erfordert, können Sie dieses Feld weglassen.
In diesem Abschnitt wird die Konfiguration (Pfad) für lokale nichtflüchtige Volumes angegeben, die von bereitgestellten Laufwerken unterstützt werden. Sie müssen diese Laufwerke selbst formatieren und bereitstellen. Sie können diese Aufgabe vor oder nach der Clustererstellung ausführen. Weitere Informationen finden Sie unter LVP-Knotenbereitstellungen.
Erforderlich. String. Geben Sie im Feld path den Hostcomputerpfad an, unter dem bereitgestellte Laufwerke erkannt werden können. Für jede Bereitstellung wird ein lokales PersistentVolume (PV) erstellt. Der Standardpfad ist /mnt/localpv-share. Eine Anleitung zum Konfigurieren der Knotenbereitstellungen finden Sie unter LVP-Knotenbereitstellungen konfigurieren.
In diesem Abschnitt wird die Konfiguration für lokale nichtflüchtige Volumes angegeben, die von Unterverzeichnissen in einem freigegebenen Dateisystem unterstützt werden. Diese Unterverzeichnisse werden bei der Clustererstellung automatisch erstellt.
Weitere Informationen finden Sie unter LVP-Freigabe.
Erforderlich. String. Geben Sie die Anzahl der zu erstellenden Unterverzeichnisse unter lvpShare.path an. Der Standardwert ist 5. Eine Anleitung zum Konfigurieren Ihrer LVP-Freigabe finden Sie unter LVP-Freigabe konfigurieren.
Erforderlich. String. Geben Sie im Feld path den Hostcomputerpfad an, in dem Unterverzeichnisse erstellt werden können. Für jedes Unterverzeichnis wird ein lokales PersistentVolume (PV) erstellt. Eine Anleitung zum Konfigurieren Ihrer LVP-Freigabe finden Sie unter LVP-Freigabe konfigurieren.
Erforderlich. String. Geben Sie die StorageClass an, die zum Erstellen nichtflüchtiger Volumes verwendet werden soll. Die StorageClass wird während der Clustererstellung erstellt. Der Standardwert ist local-shared. Anleitungen zum Konfigurieren Ihrer LVP-Freigabe finden Sie unter LVP-Freigabe konfigurieren.
Optional. Objekt. Mit einer Knotenmarkierung können Sie einen Knoten markieren. Dies bewirkt, dass der Planer den Knoten für bestimmte Pods nicht verwendet. Eine Markierung besteht aus einem Schlüssel/Wert-Paar und einem zugehörigen Effekt. Die Werte key und value sind Strings, mit denen Sie die Markierung identifizieren. Der Wert effect gibt an, wie Pods für den Knoten verarbeitet werden. Das Objekt taints kann mehrere Markierungen haben.
Das Label effect kann einen der folgenden Werte haben:
NoSchedule: Ein Pod kann nur dann auf dem Knoten geplant werden, wenn er eine übereinstimmende Toleranz hat.
PreferNoSchedule: Das System vermeidet den Einsatz eines Pods, der die Markierung nicht auf dem Knoten toleriert, aber dies ist nicht erforderlich.
NoExecute: Pods, die die Markierung nicht tolerieren, werden sofort entfernt und Pods, die die Markierung tolerieren, werden nie entfernt.
Bei Google Distributed Cloud-Software werden Markierungen mit den Knoten des Knotenpools abgeglichen, sofern die Annotation baremetal.cluster.gke.io/label-taint-no-sync nicht auf den Cluster angewendet wird. Weitere Informationen zu Markierungen finden Sie unter Markierungen und Toleranzen.
Erforderlich. String. Gibt den Clustertyp an. Das Standardbereitstellungsmodell besteht aus einem einzelnen Administratorcluster und einem oder mehreren Nutzerclustern, die vom Administratorcluster verwaltet werden.
Die Google Distributed Cloud-Software unterstützt die folgenden Clustertypen:
Admin – Ein Cluster, der zum Verwalten von Nutzerclustern verwendet wird.
Nutzer – Ein Cluster zum Ausführen von Arbeitslasten.
Hybrid – Ein einzelner Cluster für Verwaltung und Arbeitslasten, der auch Nutzercluster verwalten kann.
Standalone – Ein einzelner Cluster, der sich zwar selbst verwalten und Arbeitslasten ausführen, jedoch keine anderen Nutzercluster erstellen oder verwalten kann.
Der Clustertyp wird bei der Clustererstellung angegeben und kann für Aktualisierungen oder Upgrades nicht geändert werden. Weitere Informationen zum Erstellen eines Clusters finden Sie unter Cluster erstellen: Übersicht.
Zulässige Werte: admin | user | hybrid | standalone
Dieser Wert kann nicht für vorhandene Cluster geändert werden.
Optional. Dieser Abschnitt enthält Einstellungen für die Konfiguration der Upgradestrategie für die Knoten in einem Worker-Knotenpool. Weitere Informationen finden Sie unter Parallele Upgrades.
Hinweis: Fügen Sie diesen Abschnitt nicht für Knotenpools der Steuerungsebene oder des Load Balancers hinzu.
Optional. Dieser Abschnitt enthält Einstellungen für die Konfiguration paralleler Knotenupgrades für einen Worker-Knotenpool. Bei einem typischen Standard-Cluster-Upgrade wird jeder Clusterknoten nacheinander aktualisiert. Sie können Worker-Knotenpools so konfigurieren, dass beim Upgrade Ihres Clusters mehrere Knoten gleichzeitig aktualisiert werden. Durch das parallele Upgrade von Knoten werden Clusterupgrades erheblich beschleunigt, insbesondere bei Clustern mit Hunderten von Knoten.
Für einen Worker-Knotenpool können Sie die Anzahl der Knoten angeben, die gleichzeitig aktualisiert werden sollen. Außerdem können Sie einen Mindestgrenzwert für die Anzahl der Knoten festlegen, auf denen während des Upgrades Arbeitslasten ausgeführt werden können.
Optional. Ganzzahl (positiv). Standardeinstellung: 1. Max: 15.
Standardmäßig (1) werden Knoten nacheinander aktualisiert. Wenn Sie concurrentNodes auf eine Zahl größer als 1 festlegen, gibt dieses Feld die Anzahl der Knoten an, die parallel aktualisiert werden sollen. Beachten Sie die folgenden Einschränkungen für concurrentNodes:
Der Wert darf nicht höher sein als der kleinere Wert aus 50 % der Anzahl der Knoten im Knotenpool oder der festen Zahl 15. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat, können Sie keinen Wert größer als 10 angeben. Wenn Ihr Knotenpool 100 Knoten hat, ist 15 der maximale Wert, den Sie angeben können.
Wenn Sie dieses Feld zusammen mit dem Feld minimumAvailableNodes verwenden, darf die Summe der Werte die Gesamtzahl der Knoten im Knotenpool nicht überschreiten. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat und minimumAvailableNodes auf 18 festgelegt ist, darf concurrentNodes nicht über 2 liegen.
Bei parallelen Upgrades wird das Budget für Pod-Störungen (Pod Disruption Budget, PDB) nicht berücksichtigt.
Wenn Ihre Arbeitslasten empfindlich auf Unterbrechungen reagieren, empfehlen wir, minimumAvailableNodes anzugeben, damit während des gesamten Upgradeprozesses eine bestimmte Anzahl von Knoten für die Ausführung von Arbeitslasten verfügbar bleibt. Weitere Informationen finden Sie unter Parallele Upgrades.
Optional. Ganzzahl (nicht negativ). Standard: Je nach concurrentNodes. Weitere Informationen zu den Standardwerten für minimumAvailableNodes finden Sie unter Standardwerte für parallele Upgrades. Mit minimumAvailableNodes können Sie die Anzahl der Knoten im Knotenpool angeben, die während des Upgrade-Vorgangs verfügbar bleiben müssen. Ein Knoten gilt als nicht verfügbar, wenn er gerade umgestellt wird. Ein Knoten gilt auch dann als nicht verfügbar, wenn eine der folgenden Bedingungen erfüllt ist:
Knoten befindet sich im Wartungsmodus
Knoten wird abgeglichen
Knoten ist mitten in einem Upgrade ins Stocken geraten
Wenn Sie dieses Feld zusammen mit dem Feld concurrentNodes verwenden, darf die Summe der Werte die Gesamtzahl der Knoten im Knotenpool nicht überschreiten. Wenn Ihr Knotenpool beispielsweise 20 Knoten hat und concurrentNodes auf 10 festgelegt ist, darf minimumAvailableNodes nicht über 10 liegen.
Ein hoher Wert für minimumAvailableNodes minimiert Kapazitätsprobleme beim Planen von Pods und trägt so zum Schutz von Arbeitslasten während eines Cluster-Upgrades bei. Ein hoher Wert für minimumAvailableNodes erhöht jedoch das Risiko, dass ein Upgrade unterbrochen wird, während auf die Verfügbarkeit von Knoten gewartet wird. Weitere Informationen finden Sie unter Parallele Upgrades.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-02-26 (UTC)."],[],[]]
