Best Practices für große Cluster

Best Practice: Burst-Skalierung auf etwa 10% der Pods und Knoten in einem Cluster begrenzen

Es wird empfohlen, Knoten und Pods in Batches von etwa 10% ihrer Gesamtzahl zu einem großen Cluster hinzuzufügen oder daraus zu entfernen.

Cluster-Skalierungsaktionen (wie die Änderung der Anzahl der Knoten in einem Knotenpool, die Konfiguration der Anzahl der Replikate in einem Deployment und das Starten von Jobs im Cluster) können einen hohen API-Traffic für die verteilte Koordination und Planung von Ressourcen generieren. Die 10%-Empfehlung ist im Allgemeinen konservativ genug, um Ratenlimits im Kubernetes-API-Server und anderen Downstream-Cloud-Endpunkten zu vermeiden. Vermeiden Sie daher kostspielige Wiederholungen während einer Zeit mit hohem Datenverkehr, die zu Verzögerungen aufgrund von Backoffs führen können.

Die 10%-Empfehlung ist ein Ausgangspunkt und hängt von der Größe des Clusters und den darin enthaltenen Workload-Typen ab. Workloads mit vielen Operatoren, die alle mit dem kube-apiserver kommunizieren, erfordern möglicherweise eine Burst-Glättung, während leere Knoten mit minimaler Workload schneller burstfähig sein können.

Siehe Hinweise zu großen Clustern in der Kubernetes-Dokumentation.

Best Practice: Konfigurieren Sie FlowSchemas, um Entscheidungen zur Ratenbegrenzung bei Belastung zu optimieren

Es wird empfohlen, Anforderungen, die bei großen Clustern nicht zeitkritisch sind, zu priorisieren.

Die API-Priorität und Fairness-(APF-)Funktion im kube-apiserver stellt einige Steuerelemente zur Verfügung, um Anforderungen mit Begrenzungsraten zu begrenzen. Sie können das APF-Feature mit Prioritätsebenen konfigurieren, die flexible Konfigurationen für die Handgröße und Warteschlangengröße definieren, die einer bestimmten Priorität zugewiesen sind. Durch die Verwendung von Prioritätsebenen können erweiterte Workloads die Anforderungsverarbeitung optimieren und sicherstellen, dass Anforderungen mit hoher Priorität verarbeitet werden.

Eine FlowSchema definiert die Prioritätsebene, zu der eine Anforderung gehört. Eine häufige Konfiguration, insbesondere in Clustern mit Bursting-Workloads, bei denen eine große Anzahl von Pods oder Knoten hinzugefügt oder entfernt werden muss, ist die Verwendung einer FlowSchema, mit der die Priorität von LIST /events-Anforderungen auf die Prioritätsebene catch-all reduziert wird. In Kubernetes sind LIST-Aufrufe für den Kube-apiserver in der Regel am teuersten zu bedienen, und in Zeiten hoher Abwanderung kann die Anzahl der Ereignisse groß werden. Durch die Installation einer FlowSchema, die den Prioritätsgrad dieser Aufrufe senkt, können mehr zeitkritische Anforderungen bedient werden. Anforderungen mit niedrigerer Priorität erhalten HTTP 429-Fehler "Zu viele Anforderungen" und werden später von den Clients wiederholt, um schließlich konsistent zu werden.

Siehe Nicht wesentliche Anforderungen von anderen Abläufen isolieren in der Kubernetes-Dokumentation.

Mit den Metriken, die vom kube-apiserver unter /metrics veröffentlicht werden, können Sie ermitteln, wann Throttling stattfindet und welche Flows möglicherweise gute Kandidaten für ein benutzerdefiniertes Schema sind:

• Verwenden Sie die Metrik apiserver_flowcontrol_rejected_requests_total, um zu sehen, wann Anforderungen nicht verarbeitet werden können und wann sie wiederholt werden müssen. Wenn der Wert ungleich Null wird, ist eine Drosselung aufgetreten, und Sie können Maßnahmen ergreifen.
• Verwenden Sie die Metrik apiserver_flowcontrol_request_wait_duration_seconds, um zu sehen, welche Prioritätsebenen einen Engpass darstellen.

Siehe Gute Vorgehensweisen zur Verwendung von API-Priorität und -Fairness in der Kubernetes-Dokumentation.

Best Practice: Cluster-Add-ons entsprechend der Clustergröße optimieren

Wir empfehlen, die CoreDNS- und Flannel-Add-ons in großen Clustern zu konfigurieren.

Mit erweiterten Clustern in der Kubernetes Engine können Sie die Add-ons konfigurieren, die in einem Cluster installiert sind (siehe Cluster-Add-on aktualisieren). Die Standardwerte, die für kleinere Cluster sinnvoll sind, sind nicht unbedingt optimal für große Cluster.

Die Standardkonfiguration für CoreDNS weist 1 Replikat pro Knoten zu. In großen Clustern können jedoch weniger Replikate geeigneter sein. Beispiel: Eine Konfiguration wie {minReplica: 3, nodesPerReplica: 8} kann in einem großen Cluster geeigneter sein. Eine Konfiguration mit weniger Replikaten belegt nicht nur weniger Compute-Ressourcen im Cluster, sondern erhöht auch die Wahrscheinlichkeit effizienter Cachetreffer, indem DNS-Anforderungen auf weniger Replikate konsolidiert werden.

Um zu vermeiden, dass ein einzelner nicht verfügbarer Knoten das Rollout einer Änderung am Flannel DaemonSet anhält, können Sie die Rolloutstrategie so konfigurieren, dass sie einen maxUnavailable-Wert wie 25% aufweist. Eine solche Strategie ermöglicht das Rollout einer Flannel-DaemonSet-Änderung in ein großes Cluster mit Tausenden von Knoten, selbst wenn eine Reihe dieser Knoten nicht verfügbar sind.

Sowohl für die CoreDNS- als auch für die Flannel-Add-ons ist es in großen Clustern möglicherweise erforderlich, die zugewiesenen CPU- und Speicheranforderungen/-limits zu erhöhen, um die Last zu bewältigen.

Siehe Cluster-Add-ons konfigurieren.

Best Practice: Kubernetes-Clients so konfigurieren, dass der protobuf-Inhaltstyp anstelle von JSON verwendet wird

Es wird empfohlen, den protobuf-Inhaltstyp mit großen Clustern zu verwenden, sofern verfügbar.

Standardmäßig verwenden Kubernetes-Clients JSON als Inhaltstyp für alle Anforderungen. Die Verwendung von JSON als Inhaltstyp ist eine benutzerfreundliche Option und für die meisten Anwendungsfälle ausreichend. Bei großen Clustern kann jedoch die Verwendung von protobuf anstelle von JSON als Inhaltstyp die Performance verbessern.

So geben Sie die Verwendung des protobuf-Inhaltstyps an:

• Verwenden Sie für Anforderungen den Header Content-Type: application/vnd.kubernetes.protobuf.
• Verwenden Sie für Antworten den Header Accept: application/vnd.kubernetes.protobuf, application/json. Wenn Sie sowohl protobuf als auch json im Header Accept angeben, kann der Kubernetes-API-Server auf JSON zurückgreifen, wenn keine Protobuf-Darstellung für ein Objekt vorhanden ist.

Siehe Alternative Darstellungen von Ressourcen in der Kubernetes-Dokumentation.

Best Practice: Service-Logging für Sichtbarkeit der Kubernetes-Control-Plane-Logs aktivieren

Es wird empfohlen, Servicelogs für große Cluster zu aktivieren.

Der Kubernetes-API-Server meldet viele Probleme an Clients durch Warnungen in Serverantworten sowie über Ereignisse. Die Logs der folgenden Kubernetes-Control-Plane-Container erfassen jedoch auch zusätzliche Informationen, mit denen Sie das Verhalten großer Cluster verstehen können:

• Kube-Scheduler
• kube-controller-manager
• Cloud-Controller-Manager
• kube-apiserver

Um diese Kubernetes-Control-Plane-Logs als Servicelogs in Oracle Cloud Infrastructure Logging zu aktivieren und anzuzeigen, befolgen Sie die Anweisungen unter Kubernetes Engine-(OKE-)Servicelogs anzeigen.

Best Practice: Netzwerk-CIDR-Blöcke mit ausreichenden IP-Adressen für die erwartete Anzahl von Pods zuweisen

Wir empfehlen, im Voraus zu überlegen, wie die Größe des Netzwerk-CIDR-Blocks für ein großes Cluster angegeben werden soll und welches CNI-Plug-in ausgewählt werden soll.

Subnetzänderungen in einem ausgeführten Cluster können störend sein. Bei Pod-CIDR-Blöcken können Sie den Pod-CIDR-Block, den Sie anfänglich für ein Cluster angeben, nach der Clustererstellung nicht mehr ändern. Bevor Sie ein großes Cluster erstellen, sollten Sie daher sorgfältig überlegen, welches CNI-Plug-in am besten geeignet ist und welche CIDR-Blockgröße am besten angegeben werden kann, um Netzwerkkomplikationen bei der Skalierung des Clusters zu vermeiden.

Mit dem Flannel-CNI-Plug-in können große private Subnetze zur Verwendung zugewiesen werden. Wir empfehlen einen /12-CIDR-Block für den Pod-CIDR-Block. Aufgrund der Art von VXLANs kann das Flannel-CNI-Plugin Pods schnell zuweisen/entteilen, mit dem Kompromiss, dass sich der Podtraffic jetzt innerhalb der VXLAN-Kapselung befindet. Beachten Sie bei der Auswahl der Größe eines Pod-CIDR-Blocks, dass Kubernetes Engine jedem Knoten einen /25-CIDR-Block zuweist. Die Größe des Pod-CIDR-Blocks, den Sie angeben, kann die Anzahl der Knoten begrenzen, die für ein Cluster verfügbar sind (Beispiel: Wenn Sie einen /24-CIDR-Block als Pod-CIDR-Block angeben, kann das Cluster nur 8 Knoten haben). Je nach erwartetem Pod-zu-Knoten-Verhältnis wird jedem Knoten möglicherweise eine erhebliche Anzahl von IP-Adressen zugewiesen, die nicht verwendet werden und nicht für andere Knoten verfügbar sind. Wenn dies der Fall ist, geben Sie einen größeren Pod-CIDR-Block an (siehe IPv4 CIDR-Blöcke und Kubernetes Engine (OKE)).

Das CNI-Plug-in für natives Podnetworking lässt sich direkt mit dedizierten VNIC-Anhängen in das VCN-Networking integrieren. Bei diesem Ansatz werden Einschränkungen bei der Zuweisung von IP-Adressen pro Knoten beseitigt, und es ist keine zusätzliche VXLAN-Overlay-Netzwerkschicht im Cluster erforderlich. VCN-Subnetze sind jedoch auf einen /16-CIDR-Block begrenzt, der ein kleinerer Adressraum ist als Flannel (siehe Zulässige VCN-Größe und Adressbereiche). Beachten Sie, dass die Anzahl der VNICs, die an einen Knoten angehängt werden können, durch die Knotengröße begrenzt ist. Berücksichtigen Sie daher die Ausprägungsauswahl für jeden Knoten, wenn Sie bewerten, wie viele Pod-IP-Adressen benötigt werden (siehe Compute-Ausprägungen).

Das Subnetz des Kubernetes-API-Endpunkts erfordert im Allgemeinen nur einen kleinen CIDR-Block, da für jedes Cluster, das das Subnetz gemeinsam verwendet, nur eine einzige Endpunkt-IP-Adresse erforderlich ist. Beispiel: Wenn Sie einen /29-CIDR-Block für das Kubernetes-API-Endpunktsubnetz angeben, können 6 Cluster das Subnetz gemeinsam nutzen, während ein /28-CIDR-Block es 14 Clustern ermöglicht, das Subnetz gemeinsam zu nutzen.

Best Practice: Service-Limit-Erhöhungen präventiv anfordern

Wir empfehlen, die für Ihren Mandanten konfigurierten Servicelimits zu prüfen und Anforderungen im Voraus zu übermitteln, um die Servicelimits zu erhöhen, die von großen Clustern erwartet werden. Siehe Limits nach Service.

Große Cluster erreichen in der Regel folgende Grenzen:

• Anzahl und Größe der Containerimage-Repositorys.
• Die Anzahl der für ein einzelnes Cluster zulässigen Knoten.
• Die Anzahl der Gigabyte an Block-Volumes, die zugewiesen werden können.

Um eine mögliche Unterbrechung zu vermeiden, empfehlen wir daher, im Voraus Anforderungen zur Erhöhung der Servicelimits zu übermitteln, insbesondere für Limits für Block-Volumes, die als Boot-Volumes für Knoten verwendet werden.

Siehe Erhöhung des Servicelimits beantragen

Best Practice: Nutzen Sie die automatische Skalierung, um Compute-Ressourcen proportional mit Workloads zu verwalten

Es wird empfohlen, Autoscaler (wie Kubernetes Cluster Autoscaler (CA), Horizontal Pod Autoscaler (HPA) und Vertical Pod Autoscaler (VPA) mit großen Clustern zu verwenden, um die Ressourcennutzung zu optimieren.

Mit einem Autoscaler können Sie Regeln einrichten, die definieren, wann weitere Knoten bereitgestellt, weitere Replikate erstellt oder ein Cluster während eines ruhigen Zeitraums horizontal skaliert werden sollen.

Die automatische, regelbasierte Skalierung ist eine effiziente Möglichkeit, große Cluster mit Tausenden von Knoten und Pods zu verwalten.

Siehe Best Practices für Autoscaler.

Best Practice: Verwenden Sie zustandslose Regeln für Sicherheitslisten und Netzwerksicherheitsgruppen, um den Aufwand für das Verbindungs-Tracking zu minimieren

Bei der Konfiguration von Sicherheitslisten und Netzwerksicherheitsgruppen für große Cluster wird empfohlen, zustandslose Regeln zu verwenden.

In Tutorials und Dokumentationen wird oft angegeben, dass Sie Sicherheitslisten und Netzwerksicherheitsgruppen mit zustandsbehafteten Regeln erstellen. Zustandsbehaftete Regeln nutzen das Verbindungstracking, um sicherzustellen, dass der Rückgabepfad für eine Anforderung automatisch zulässig ist, unabhängig davon, ob eine Egress-Regel vorhanden ist (siehe Verbindungstracking). Obwohl das automatische Zulassen von Rückgabepfaden das Regelsetup vereinfachen soll, stellen diese automatisch zulässigen Rückgabepfade einen potenziellen Overhead dar, der für große Cluster zu einem Problem werden kann. Die Anzahl der Verbindungen, die verfolgt werden können, ist proportional zur Ausprägung der verwendeten Instanz, aber die einfache Auswahl einer größeren Ausprägung löst das Problem nicht unbedingt.

Um den Overhead der Verbindungsverfolgung zu vermeiden und mögliche Skalierungsgrenzen zu vermeiden, empfehlen wir daher für jeden Netzwerkpfad:

1. Sie definieren eine Ingress-Regel und eine entsprechende Egress-Regel als Paar.
2. Sie geben die Ingress- und Egress-Regeln als "zustandslos" an.

Siehe Regeln für zustandsbehafteten und zustandslosen Traffic im Vergleich.