Auf dieser Seite werden Best Practices zum Erstellen, Konfigurieren und Betreiben von Google Distributed Cloud-Clustern beschrieben, um Arbeitslasten zu berücksichtigen, die sich den Skalierbarkeitslimits von Kubernetes annähern.
Regeln für Clusternamen
Für die einzelnen Google Cloud-Projekte gilt:
- Jeder Nutzercluster muss innerhalb aller Administratorcluster eines Google Cloud-Projekts einen eindeutigen Namen haben.
Skalierbarkeitslimits
Beachten Sie beim Entwerfen Ihrer Anwendungen in GKE on VMware die folgenden Limits:
Jeder Administratorcluster unterstützt bis zu 100 Nutzercluster, einschließlich Hochverfügbarkeits- (HA) und Nicht-HA-Nutzercluster, unter Verwendung des gebündelten Load-Balancing-Modus (Seesaw oder MetalLB) oder des integrierten Load-Balancing-Modus (F5).
Jeder Nutzercluster unterstützt bis zu:
500 Knoten mit gebündeltem Load-Balancing-Modus (Seesaw oder MetalLB) oder 250 Knoten mit integriertem Load-Balancing-Modus (F5)
15.000 Pods
500 LoadBalancer-Dienste im gebündelten Load-Balancing-Modus (Seesaw oder MetalLB) oder 250 Load-Balancer-Dienste mithilfe des integrierten Load-Balancing-Modus (F5).
Für jeden Knoten können Sie maximal 110 Pods erstellen (jeder Pod kann aus 1–2 Containern bestehen). Dazu gehören auch Pods, auf denen Add-on-Systemdienste ausgeführt werden.
Informationen zu Limits
Da GKE on VMware ein komplexes System mit einer großen Integrationsoberfläche ist, umfasst die Skalierbarkeit von Clustern viele zusammengehörige Dimensionen. GKE on VMware kann beispielsweise über die Anzahl der Knoten, Pods oder Dienste skalieren. Das Erweitern mehrerer Dimensionen gleichzeitig kann auch in kleineren Clustern Probleme verursachen. Wenn Sie beispielsweise 110 Pods pro Knoten in einem 500-Knotencluster planen, kann die Anzahl der Pods, Pods pro Knoten und Knoten überlastet werden.
Weitere Informationen finden Sie unter Kubernetes-Skalierbarkeitsschwellenwerte.
Die Skalierbarkeitslimits gelten auch für die vSphere-Konfiguration und -Hardware, auf der Ihr Cluster ausgeführt wird. Diese Limits werden in einer Umgebung geprüft, die sich von Ihrer unterscheidet. Daher werden Sie möglicherweise nicht die genauen Zahlen reproduzieren, wenn die zugrunde liegende Umgebung der begrenzende Faktor ist.
Skalierung vorbereiten
Berücksichtigen Sie bei der Vorbereitung der Skalierung von Administratorclustern oder Nutzerclustern die folgenden Anforderungen und Einschränkungen.
CPU-, Arbeitsspeicher- und Speicheranforderungen
CPU-, RAM- und Speicheranforderungen für jede einzelne VM
Laufwerk-/Netzwerk-E/A-Anforderungen
Datenintensive Arbeitslasten und bestimmte Komponenten der Steuerungsebene sind empfindlich auf Laufwerk-/Netzwerk-E/A-Latenz. Zum Beispiel sind normalerweise 500 sequentielle IOPS (z. B. eine typische lokale SSD oder ein virtualisiertes Blockgerät mit hoher Leistung) erforderlich, um die Leistung und Stabilität von etcd in einem Cluster mit Dutzenden Knoten und Tausenden von Pods zu verbessern, um die Option zu aktivieren.
Knoten-IP-Adresse
Jeder GKE on VMware-Knoten benötigt eine DHCP- oder statisch zugewiesene IP-Adresse.
Beispielsweise sind in einer Einrichtung mit einem Nicht-HA-Nutzercluster mit 50 Knoten und einem Hochverfügbarkeits-Nutzercluster mit 250 Knoten 307 IP-Adressen erforderlich.
In der folgenden Tabelle sind die IP-Adressen aufgeschlüsselt:
Knotentyp | Anzahl der IP-Adressen |
---|---|
VMs der Steuerungsebene des Administratorclusters | 3 |
Steuerungsebene-VM des Nutzercluster 1 (Nicht-HA) | 1 |
VMs von Nutzercluster 1 mit Worker-Knoten | 50 |
Steuerungsebenen-VMs des Nutzer-Cluster 2 (HA) | 3 |
VMs von Nutzercluster 2 mit Worker-Knoten | 250 |
Summe | 307 |
Viele Nutzercluster in einem Administratorcluster ausführen
Wenn Sie viele Nutzercluster in einem Administratorcluster ausführen möchten, führen Sie beim Erstellen des Administratorclusters folgende Schritte aus.
Pod-CIDR-Block im Administratorcluster
Der Pod-CIDR-Block ist der CIDR-Block für alle Pods in einem Administratorcluster. Es wird über das Feld network.podCIDR
in admin-cluster.yaml
konfiguriert.
Aus diesem Bereich werden jedem Knoten kleinere /24-Blöcke zugewiesen. Wenn für alle Nutzercluster die Steuerungsebene V2 aktiviert ist, hat Ihr Administratorcluster nur drei Knoten und es sind viele Pod-IP-Adressen verfügbar. Jedes Mal, wenn Sie jedoch einen Nutzercluster erstellen, der kubeception anstelle von Steuerungsebene V2 verwendet, werden dem Administratorcluster ein oder drei Knoten hinzugefügt:
Jeder kubeception-Nutzercluster mit Hochverfügbarkeit fügt dem Administratorcluster drei Knoten hinzu.
Jeder kubeception-Nutzercluster ohne Hochverfügbarkeit fügt dem Administratorcluster einen Knoten hinzu.
Wenn Sie einen Administratorcluster mit N Knoten benötigen, müssen Sie darauf achten, dass der Pod-CIDR-Block N /24-Blöcke unterstützt.
In der folgenden Tabelle wird die maximale Anzahl an Knoten beschrieben, die von verschiedenen Pod-CIDR-Blockgrößen unterstützt werden:
CIDR-Blockgröße des Pods | Maximale Anzahl der unterstützten Knoten |
---|---|
/18 | 64 |
/17 | 128 |
/16 | 256 |
/15 | 512 |
Der standardmäßige Pod-CIDR-Block eines Administratorclusters ist 192.168.0.0/16, der 256 Knoten unterstützt.
In einem Administratorcluster mit 100 kubeception-Nutzerclustern für Hochverfügbarkeit gibt es 3 Knoten für die Administratorcluster-Steuerungsebene und 300 Knoten für die Nutzercluster-Steuerungsebene. Die Gesamtzahl der Knoten beträgt 303 (mehr als 256). Daher müssen Sie den Pod-CIDR-Block auf /15 aktualisieren, um bis zu 100 HA-kubeception-Nutzercluster zu unterstützen.
Zum Konfigurieren des Pod-CIDR-Blocks legen Sie das Feld network.podCIDR
in der Konfigurationsdatei des Administratorclusters fest.
Dienst-CIDR-Block im Administratorcluster
Der Dienst-CIDR-Block ist der CIDR-Block für alle Dienste in einem Administratorcluster.
Es wird über das Feld network.serviceCIDR
in admin-cluster.yaml
konfiguriert.
In der folgenden Tabelle wird die maximale Anzahl von Diensten erläutert, die von unterschiedlichen Dienst-CIDR-Blockgrößen unterstützt werden:
Dienst-CIDR-Blockgröße | Maximale Anzahl unterstützter Dienste |
---|---|
/24 | 256 |
/23 | 512 |
/22 | 1.024 |
Der Standardwert ist 10.96.232.0/24, welcher 256 Dienste unterstützt.
Jeder kubeception-Nutzercluster verwendet 6 Dienste und die Steuerungsebene des Administratorclusters 14 Dienste. Wenn Sie 100 kubeception-Nutzercluster ausführen möchten, müssen Sie daher den Dienst-CIDR-Block im Administratorcluster so ändern, dass ein /22-Bereich verwendet wird.
Cloud Logging und Cloud Monitoring
Mit Cloud Logging und Cloud Monitoring können Sie Ihre Ressourcen verfolgen.
Die CPU- und Arbeitsspeichernutzung der Logging- und Monitoring-Komponenten, die in einem Administratorcluster bereitgestellt werden, skaliert entsprechend der Anzahl der kubeception-Nutzercluster.
In der folgenden Tabelle werden die CPU- und Arbeitsspeichermenge für Administratorclusterknoten beschrieben, die zum Ausführen einer großen Anzahl von kubeception-Nutzerclustern erforderlich sind:
Anzahl der kubeception-Nutzercluster | CPU des Administratorclusterknotens | Arbeitsspeicher des Administratorclusterknotens |
---|---|---|
0 bis 10 | 4 CPUs | 16 GB |
11 bis 20 | 4 CPUs | 32 GB |
20 bis 100 | 4 CPUs | 90 GB |
Wenn es beispielsweise 2 Administratorclusterknoten mit jeweils 4 CPUs und 16 GB Arbeitsspeicher gibt, können Sie 0 bis 10 kubeception-Nutzercluster ausführen. Wenn Sie mehr als 20 kubeception-Nutzercluster erstellen möchten, müssen Sie zuerst die Größe des Arbeitsspeichers des Knotenarbeitsspeichers des Administratorclusters von 16 GB auf 90 GB ändern.
GKE Hub
Standardmäßig können Sie maximal 15 Nutzercluster registrieren.
Für die Registrierung weiterer Cluster in GKE Hub können Sie über die Google Cloud Console eine Anfrage zur Erhöhung Ihres Kontingents stellen:
Viele Knoten und Pods in einem Nutzercluster ausführen
Führen Sie bei der Erstellung vieler Knoten und Pods in einem Nutzercluster die folgenden Schritte aus, wenn Sie den Nutzercluster erstellen.
Pod-CIDR-Block im Nutzercluster
Der Pod-CIDR-Block ist der CIDR-Block für alle Pods in einem Nutzercluster. Es wird über das Feld network.podCIDR
in user-cluster.yaml
konfiguriert.
Aus diesem Bereich wird jedem Knoten ein kleinerer /24-Block zugewiesen. Wenn Sie einen Cluster mit N Knoten benötigen, müssen Sie darauf achten, dass dieser Block groß genug ist, um N /24-Blöcke zu unterstützen.
In der folgenden Tabelle wird die maximale Anzahl an Knoten beschrieben, die von verschiedenen Pod-CIDR-Blockgrößen unterstützt werden:
CIDR-Blockgröße des Pods | Maximale Anzahl der unterstützten Knoten |
---|---|
/18 | 64 |
/17 | 128 |
/16 | 256 |
/15 | 512 |
Der Standard-CIDR-Block des Pods ist 192.168.0.0/16 mit 256 Knoten. Wenn Sie beispielsweise einen Cluster mit 500 Knoten erstellen möchten, müssen Sie den Pod-CIDR-Block im Nutzercluster ändern, um einen 15-Bereich zu verwenden.
Dienst-CIDR-Block im Nutzercluster
Der Dienst-CIDR-Block ist der CIDR-Block für alle Dienste in einem Nutzercluster. Es wird über das Feld network.serviceCIDR
in user-cluster.yaml
konfiguriert.
In der folgenden Tabelle wird die maximale Anzahl von Diensten erläutert, die von unterschiedlichen Dienst-CIDR-Blockgrößen unterstützt werden:
Dienst-CIDR-Blockgröße | Maximale Anzahl unterstützter Dienste |
---|---|
/21 | 2.048 |
/20 | 4.096 |
/19 | 8.192 |
/18 | 16.384 |
Knoten für die Steuerungsebene des Nutzerclusters
Die Arbeitsspeichernutzung der Komponenten der Steuerungsebene des Nutzerclusters wird nach der Anzahl der Knoten im Nutzercluster skaliert.
In der folgenden Tabelle sind die CPU und der Arbeitsspeicher aufgeführt, die für den Knoten der Steuerungsebene eines Nutzerclusters je nach Größe des Nutzerclusters erforderlich sind:
Anzahl an Nutzerclusterknoten | CPU des Steuerungsebenenknotens | Arbeitsspeicher des Steuerungsebenenknotens |
---|---|---|
0 bis 20 | 3 CPUs | 5 GB |
21 bis 75 | 3 CPUs | 6 GB |
76 bis 250 | 4 CPUs | 8 GB |
251 bis 500 | 4 CPUs | 16 GB |
Wenn Sie beispielsweise mehr als 250 Knoten in einem Nutzercluster erstellen möchten, müssen Sie Knoten für die Nutzercluster-Steuerungsebene mit mindestens 16 GB Arbeitsspeicher verwenden.
Die Knotenspezifikation der Nutzercluster-Steuerungsebene kann in user-cluster.yaml
im Feld masterNode
geändert werden.
Dataplane V2
Für Nutzercluster mit 500 Knoten, die Dataplan V2 verwenden, empfehlen wir 120 GB Arbeitsspeicher und 32 CPU-Kerne für die Knoten der Steuerungsebene des Nutzerclusters.
Cloud Logging und Cloud Monitoring
Mit Cloud Logging und Cloud Monitoring können Sie Ihre Ressourcen verfolgen.
Die CPU- und Arbeitsspeichernutzung der In-Cluster-Agents, die in einem Nutzercluster bereitgestellt werden, skaliert anhand der Anzahl der Knoten und Pods in einem Nutzercluster.
Cloud Logging- und Monitoring-Komponenten wie prometheus-server
und stackdriver-prometheus-sidecar
haben unterschiedliche CPU- und Speicherressourcennutzung, die auf der Anzahl der Knoten und der Anzahl der Pods basieren. Bevor Sie den Cluster hochskalieren, müssen Sie die Ressourcenanfrage und das Ressourcenlimit gemäß der geschätzten durchschnittlichen Nutzung dieser Komponenten festlegen. In der folgenden Tabelle sehen Sie Schätzungen für die durchschnittliche Nutzung pro Komponente:
Anzahl der Knoten | Containername | Geschätzte CPU-Auslastung | Geschätzte Speichernutzung | ||
---|---|---|---|---|---|
0 Pods/Knoten | 30 Pods/Knoten | 0 Pods/Knoten | 30 Pods/Knoten | ||
3 to 50 | prometheus-server | 100 m | 390 m | 650 m | 1,3 G |
stackdriver-prometheus-sidecar | 100 m | 340 m | 1,5 G | 1,6 G | |
51 bis 100 | prometheus-server | 160m | 500m | 1,8 G | 5,5 G |
stackdriver-prometheus-sidecar | 200m | 500m | 1,9G | 5,7G | |
101 bis 250 | prometheus-server | 400m | 2500m | 6,5 G | 16G |
stackdriver-prometheus-sidecar | 400m | 1300m | 7,5G | 12G | |
250 auf 500 | prometheus-server | 1200 Mio. | 2600 Mio. | 22G | 25G |
stackdriver-prometheus-sidecar | 400m | 2250 Mio. | 65G | 78G |
Achten Sie darauf, dass Ihre Knoten groß genug sind, um die Komponenten von Cloud Logging und Cloud Monitoring zu planen. Eine Möglichkeit besteht darin, zuerst einen kleinen Cluster zu erstellen. Bearbeiten Sie dazu zuerst die Cloud Logging- und Cloud Monitoring-Komponentenressourcen gemäß der obigen Tabelle und erstellen Sie einen Knotenpool, um die Komponenten aufzunehmen. und hochskaliert dann den Cluster schrittweise zu vergrößern.
Sie können einen Knotenpool für die Monitoring- und Logging-Komponenten so groß halten, dass keine anderen Pods in dem Knotenpool geplant werden. Dazu müssen Sie dem Knotenpool die folgenden Holdts hinzufügen:
taints: - effect: NoSchedule key: node-role.gke.io/observability
Dadurch wird verhindert, dass andere Komponenten für den Knotenpool geplant werden und Nutzerarbeitslasten nicht aufgrund des Ressourcenverbrauchs der Monitoring-Komponenten entfernt werden.
Load-Balancer
Die in diesem Abschnitt beschriebenen Dienste beziehen sich auf die Kubernetes-Dienste mit dem Typ „Load-Balancer“.
Die Anzahl der Knoten in Ihrem Cluster und die Anzahl der Dienste, die Sie auf dem Load-Balancer konfigurieren können, sind begrenzt.
Für das gebündelte Load-Balancing (Seesaw) gibt es außerdem ein Limit für die Anzahl der Systemdiagnosen. Die Anzahl der Systemdiagnosen hängt von der Anzahl der Knoten und der Anzahl der lokalen Dienste des Traffics ab. Ein lokaler Trafficdienst ist ein Dienst, dessen externalTrafficPolicy auf Local
gesetzt ist.
Die folgende Tabelle beschreibt die maximale Anzahl von Diensten, Knoten und Systemdiagnosen für das gebündelte Load-Balancing (Seesaw) und das integrierte Load-Balancing (F5):
Gebündeltes Load-Balancing (Seesaw) | Integriertes Load-Balancing (F5) | |
---|---|---|
Maximale Anzahl von Diensten | 500 | 250 2 |
Maximale Anzahl von Knoten | 500 | 250 2 |
Maximale Systemdiagnosen | N + (L * N) <= 10K, wobei N die Anzahl der Knoten und L die Anzahl der lokalen Dienste des Traffics ist 1 | N/A 2 |
1 Angenommen, Sie haben 100 Knoten und 99 lokale Trafficdienste. Die Anzahl der Systemdiagnosen liegt bei 100 + (99 * 100) = 10.000, welche innerhalb des Limits von 10.000 liegt.
2 Weitere Informationen erhalten Sie unter F5. Diese Zahl hängt von Faktoren wie der F5-Hardware-Modellnummer, der CPU- bzw. Speicherkapazität der virtuellen Instanz und den Lizenzen ab.
Systemkomponenten mit automatischer Skalierung
GKE on VMware skaliert die Systemkomponenten in Nutzerclustern automatisch entsprechend der Anzahl von Knoten, ohne dass Sie die Konfigurationen ändern müssen. Die Informationen in diesem Abschnitt können Sie für die Ressourcenplanung verwenden.
GKE on VMware führt automatisch eine vertikale Skalierung durch. Dabei werden die CPU- und Arbeitsspeicheranfragen/-limits der folgenden Systemkomponenten mithilfe von addon-resizer skaliert:
kube-state-metrics ist ein Deployment, das auf Cluster-Worker-Knoten ausgeführt wird, die den Kubernetes API-Server überwachen und Messwerte zum Status der Objekte generieren. Die CPU- und Speicheranforderungen und die Skalierung werden basierend auf der Anzahl der Knoten skaliert.
In der folgenden Tabelle werden die Ressourcenanforderungen/-limits beschrieben, die vom System festgelegt werden, unter Berücksichtigung der Anzahl der Knoten in einem Cluster:
Anzahl der Knoten Ungefähre1 CPU-Anfrage/Limit (Milli) Ungefähre1 Speicheranfrage/Limit (Mi) 3 bis 5 105 110 6 auf 500 100 + num_nodes 100 + (2 * num_nodes) 1 Es gibt einen Rand von +-5 %, um die Anzahl der Komponentenneustarts während der Skalierung zu verringern.
Beispiel: In einem Cluster mit 50 Knoten ist die CPU-Anfrage/-grenze auf 150 m/150 Min. und die Speicheranforderung/-grenze auf 200 Mi/200Mi eingestellt. In einem Cluster mit 250 Knoten wird die CPU-Anfrage/-grenze auf 350 m/350 m festgelegt und die Speicheranforderung/-grenze auf 600 Mi.
metrics-server ist eine Bereitstellung, die auf Cluster-Worker-Knoten ausgeführt wird, die von integrierten Kubernetes-Autoscaling-Pipelines verwendet werden. Die CPU- und Speicheranforderungen und die Skalierung werden basierend auf der Anzahl der Knoten skaliert.
GKE on VMware führt automatisch eine horizontale Skalierung sowohl in Administrator- als auch in Nutzerclustern durch. Dabei wird die Anzahl der Replikate der folgenden Systemkomponenten skaliert:
core-dns ist die DNS-Lösung, die für die Diensterkennung in GKE on VMware verwendet wird. Sie wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. GKE on VMware skaliert die Anzahl der Replikate automatisch entsprechend der Anzahl der Knoten und CPU-Kerne im Cluster. Mit jedem Hinzufügen/Löschen von 16 Knoten oder 256 Kernen wird 1 Replikat erhöht/verringert. Wenn Sie einen Cluster mit
N
Knoten undC
Kernen haben, können Siemax(N/16, C/256)
-Replikate erwarten.calico-typha ist eine Komponente zur Unterstützung von Pod-Netzwerken in GKE on VMware. Sie wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. GKE on VMware skaliert die Anzahl der Calico-Typha-Replikate automatisch anhand der Anzahl der Knoten im Cluster:
Anzahl der Knoten (N) Anzahl der calico-typha-Replikate N = 1 1 1 < N < 200 2 N >= 200 Mindestens drei Istio Ingress-Gateway ist die Komponente zur Unterstützung von Cluster-Ingress und wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. Abhängig von der Menge des vom eingehenden Traffic verarbeiteten Traffics verwendet GKE on VMware horizontales Pod-Autoscaling, um die Anzahl der Replikate basierend auf ihrer CPU-Nutzung mit mindestens zwei und maximal fünf Replikaten zu skalieren.
Der konnectivity-Netzwerkproxy (KNP) bietet einen TCP-Proxy für den ausgehenden Traffic von Knoten der Nutzercluster-Steuerungsebene. Er leitet den ausgehenden kube-apiserver-Traffic des Nutzers weiter, der an die Knoten des Nutzerclusters gerichtet ist. Der Konnectivity-Agent wird als Deployment auf Nutzercluster-Worker-Knoten ausgeführt. Google Distributed Cloud skaliert die Anzahl der Replikate des Konnektivitäts-Agents automatisch anhand der Anzahl der Knoten im Cluster.
Anzahl der Knoten (N) Anzahl der Replikate des konnectivity-Agents 1 <= N <= 6 ✘ 6 < N < 10 6 10 <= N < 100 8 N >= 100 Mindestens 12
Best Practices
In diesem Abschnitt werden Best Practices zur Skalierung Ihrer Ressourcen beschrieben.
Cluster schrittweise skalieren
Beim Erstellen eines Kubernetes-Knotens wird die Image-Vorlage des Knotenbetriebssystems in eine neue Laufwerksdatei kopiert. Dabei handelt es sich um einen E/A-intensiven vSphere-Vorgang. Es gibt keine E/A-Isolation zwischen dem Klonvorgang und den E/A-Vorgängen der Arbeitslast. Wenn zu viele Knoten gleichzeitig erstellt werden, dauert der Klonvorgang lange, was die Leistung und Stabilität des Clusters und der vorhandenen Arbeitslasten beeinträchtigen kann.
Achten Sie darauf, dass der Cluster in Abhängigkeit von Ihren vSphere-Ressourcen skaliert wird. Wenn Sie beispielsweise die Größe eines Clusters von 3 auf 500 Knoten ändern möchten, sollten Sie ihn in Phasen von 150 auf 350 bis 500 skalieren, um die Last der vSphere-Infrastruktur zu reduzieren.
E/A-Leistung von etcd-Laufwerk optimieren
etcd ist ein Schlüssel/Wert-Speicher, der als Sicherungsspeicher von Kubernetes für alle Clusterdaten verwendet wird. Die Leistung und Stabilität sind für den Zustand eines Clusters von entscheidender Bedeutung und hängen von der E/A-Latenz des Laufwerks und des Netzwerks ab.
Optimieren Sie die E/A-Leistung des vSphere-Datenspeichers, der für die VMs auf Steuerungsebene verwendet wird. Beachten Sie dabei die folgenden Empfehlungen:
- Beachten Sie die etcd-Hardwareanforderungen.
- Verwenden Sie SSD oder den gesamten Flash-Speicher.
Die Latenz von einigen hundert Millisekunden weist auf einen Engpass auf dem Laufwerk oder der E/A des Netzwerks zu. Dies kann zu einem fehlerhaften Cluster führen. Benachrichtigungsschwellen für die folgenden etcd-E/A-Latenzmesswerte überwachen und festlegen:
etcd_disk_backend_commit_duration_seconds
etcd_disk_wal_fsync_duration_seconds
E/A-Leistung von Knoten-Bootlaufwerk optimieren
Pods verwenden für ihre internen Vorgänge einen sitzungsspezifischen Speicher, z. B. zum Speichern temporärer Dateien. Flüchtiger Speicher wird von der beschreibbaren Ebene des Containers, dem Logverzeichnis und den emptyDir-Volumes belegt. Sitzungsspezifischer Speicher stammt aus dem Dateisystem des GKE on VMware-Knotens, das vom Bootlaufwerk des Knotens unterstützt wird.
Da auf Kubernetes-Knoten keine Speicher-E/A-Isolierung vorhanden ist, können Anwendungen, die bei ihrem flüchtigen Speicher extrem hohe E/A-Vorgänge verbrauchen, zu Knoteninstabilität führen, indem sie Systemkomponenten wie Kubelet und den Docker-Daemon von Ressourcen.
Prüfen Sie, ob die E/A-Leistungsmerkmale des Datenspeichers, auf denen die Bootlaufwerke bereitgestellt werden, die richtige Leistung für die Verwendung von flüchtigem Speicher und Logging-Traffic bieten.
Konflikte mit physischen Ressourcen überwachen
Achten Sie auf vCPUs und pCPU-Verhältnisse und Speicherüberlastung. Ein suboptimales Verhältnis oder Speicherkonflikte bei den physischen Hosts können die VM-Leistung beeinträchtigen. Sie sollten die physische Ressourcennutzung auf Hostebene überwachen und genügend Ressourcen für die Ausführung großer Cluster zuweisen.