Best Practices für das Clustermanagement

Best Practice: Kubernetes-Labels verwenden

Wir empfehlen, die vielen Kubernetes-Ressourcen (wie Services, Pods, Container, Netzwerke) mit Kubernetes-Labels zu organisieren, die ein Cluster umfassen.

Kubernetes-Labels sind Schlüssel/Wert-Paare, mit denen Sie diese Ressourcen verwalten und verfolgen können, wie sie in einem Cluster miteinander interagieren.

Beispiel: Sie können die oci.oraclecloud.com/oke-is-preemptible=true label (die Kubernetes-Engine für Worker-Knoten gilt, die auf präemptiven Instanzen gehostet werden) mit Kubernetes-Knotenselektoren und Knotenaffinität/Antiaffinität verwenden, um zu steuern, welche Pods auf diesen Worker-Knoten geplant werden.

Siehe Bekannte Labels, Anmerkungen und Farben in der Kubernetes-Dokumentation.

Best Practice: OCI-Ressourcentagging verwenden

Wir empfehlen, dass Sie das OCI-Ressourcentagging verwenden, um die vielen Ressourcen (wie Worker-Knoten, VCNs, Load Balancer und Block-Volumes) zu organisieren, die von den Kubernetes-Clustern verwendet werden, die Sie mit der Kubernetes-Engine erstellen. Wenn in einem Mandanten eine große Anzahl von Ressourcen über mehrere Compartments verteilt ist, ist es schwierig, die für bestimmte Zwecke verwendeten Ressourcen zu verfolgen. Ebenso kann es schwierig sein, die Ressourcen zu aggregieren, Berichte darüber zu erstellen und Bulk-Aktionen mit ihnen durchzuführen.

Mit Tagging können Sie Schlüssel und Werte definieren und sie mit Ressourcen verknüpfen. Anschließend können Sie mit den Tags Ressourcen basierend auf Ihren Geschäftsanforderungen organisieren und auflisten.

Siehe Clusterbezogene Kubernetes-Ressourcen taggen.

Best Practice: Ressourcenanforderungen und Grenzwerte festlegen

Empfohlene Einstellungen:

• Ressourcenanforderungen, um die Mindestmenge an Ressourcen anzugeben, die ein Container verwenden kann
• Ressourcenlimits, um die maximale Ressourcenmenge anzugeben, die ein Container verwenden kann

Eine häufige Herausforderung bei der Arbeit mit einem Kubernetes-Cluster ist der gelegentliche Ausfall einer Anwendung bei der Bereitstellung in einem Cluster aufgrund der begrenzten Verfügbarkeit von Ressourcen in diesem Cluster. Der Fehler wird dadurch verursacht, dass Ressourcenanforderungen und Ressourcengrenzwerte nicht festgelegt wurden.

Wenn Sie keine Ressourcenanforderungen und -limits festlegen, können Pods in einem Cluster mehr Ressourcen als erforderlich nutzen. Wenn ein Pod mehr CPU oder Speicher auf einem Knoten belegt, kann der Kube-Scheduler möglicherweise keine neuen Pods auf dem Knoten platzieren, und der Knoten selbst kann sogar abstürzen.

Siehe Anforderungen und Limits in der Kubernetes-Dokumentation.

Best Practice: Ressourcen für Kubernetes- und Betriebssystem-Daemons reservieren

kubectl get node <NODE_NAME> -o=yaml | grep -A 6 -B 7 capacity

  allocatable:
    cpu: 15743m
    ephemeral-storage: "34262890849"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 234972476Ki
    pods: "110"
  capacity:
    cpu: "16"
    ephemeral-storage: 37177616Ki
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 257197372Ki
    pods: "110"

Weitere Empfehlungen:

• Bevor Sie Reservierungsänderungen auf Produktionscluster anwenden, sollten Sie in einer Nicht-Produktionsumgebung immer einen Benchmark durchführen und die Auswirkungen der Reservierungsänderungen testen.
• Verwenden Sie die Kubelet-Flags --eviction-hard oder --eviction-soft, um geeignete Schwellenwerte für Speicher und Datenträgerdruck festzulegen. Wenn Sie diese Schwellenwerte festlegen, kann das Kubernetes-System die Systemstabilität schützen, indem bei Bedarf weniger wichtige Pods entfernt werden. Weitere Informationen hierzu finden Sie unter Knotendruckentfernung in der Kubernetes-Dokumentation.
• Beachten Sie, dass das Reservieren zu vieler Ressourcen zu einer zu geringen Auslastung der Knoten führen kann. Ihr Ziel ist es, ein angemessenes Gleichgewicht zwischen der Gewährleistung der Ressourcenverfügbarkeit für kritische Komponenten und der Maximierung der Ressourcenverfügbarkeit für Workloads zu finden. Wir empfehlen, dass Sie mit größeren Ressourcenreservierungen beginnen und die Reservierungsgrößen basierend auf der Beobachtung schrittweise reduzieren, anstatt mit kleineren Ressourcenreservierungen zu beginnen, die zu niedrig sind und das Risiko einer Systeminstabilität bergen. Verwenden Sie Metriken aus Monitoring- und Alertingtools, um die Nutzung von Ressourcen durch Kubernetes und Systemkomponenten im Laufe der Zeit zu beobachten.
• Berücksichtigen Sie beim Reservieren von Ressourcen Unterschiede in der Knotenausprägung und dem Workload-Typ. Große Knoten erfordern möglicherweise größere absolute Reservierungen als kleinere Knoten. Workloads mit bestimmten Ressourcenanforderungen oder bekannten Burst-Mustern erfordern möglicherweise größere oder kleinere Ressourcenreservierungen.

Weitere Informationen zum Reservieren von Ressourcen finden Sie unter Compute-Ressourcen für System-Daemons reservieren in der Kubernetes-Dokumentation.

Best Practice: Bereitstellung dedizierter Knoten mithilfe von Taints und Toleranzen

Es wird empfohlen, Kubernetes-Taints und -Toleranzen zu verwenden, um ressourcenintensive Anwendungen auf bestimmte Worker-Knoten zu beschränken.

Mit Taints und Tolerations können Sie Knotenressourcen für Workloads verfügbar halten, die sie erfordern, und die Planung anderer Workloads auf den Knoten verhindern.

Beispiel: Wenn Sie ein Cluster mit der Kubernetes-Engine erstellen, können Sie Worker-Knoten mit einer GPU-Ausprägung oder einer Ausprägung mit einer großen Anzahl leistungsstarker CPUs definieren. Diese gut angegebenen Worker-Knoten sind ideal für große Datenverarbeitungs-Workloads geeignet. Eine solche spezialisierte Hardware ist jedoch normalerweise teuer bereitzustellen. Folglich sollten Sie in der Regel die Workloads begrenzen, die auf diesen Knoten geplant werden können. Um die Workloads zu begrenzen, die auf den angegebenen Worker-Knoten geplant werden können, fügen Sie den Knoten eine Färbung hinzu. Führen Sie z.B. einen der folgenden Befehle aus:

• kubectl taint nodes <node-name> special=true:NoSchedule
• kubectl taint nodes <node-name> special=true:PreferNoSchedule

Nachdem Sie den gut angegebenen Worker-Knoten einen Taint hinzugefügt haben, fügen Sie den Pods, die Sie die Verwendung der Knoten zulassen möchten, eine entsprechende Toleranz hinzu.

Ebenso können Sie die oci.oraclecloud.com/oke-is-preemptible=true label (die Kubernetes-Engine für Worker-Knoten gilt, die auf präemptiven Instanzen gehostet werden) mit Kubernetes-Toleranzen verwenden, um zu steuern, welche Pods auf diesen Worker-Knoten geplant werden.

Siehe Taints and Tolerations in der Kubernetes-Dokumentation.

Best Practice: Podplanung mit Knotenselektoren und Affinität steuern

Es gibt mehrere Möglichkeiten, einen Pod so zu beschränken, dass er auf bestimmten Knoten ausgeführt wird, oder eine Voreinstellung für einen Pod anzugeben, die auf bestimmten Knoten ausgeführt werden soll. Die empfohlenen Ansätze verwenden alle Etikettenselektoren, um die Auswahl zu erleichtern. Oft macht der Kube-Scheduler automatisch eine vernünftige Platzierung ohne solche Einschränkungen oder Vorlieben. In einigen Fällen können Sie jedoch den Knoten steuern, auf dem ein Pod ausgeführt wird.

In diesen Situationen wird empfohlen, die Planung von Pods auf Knoten mit Kubernetes-Knotenselektoren, Knotenaffinität und Interpod-Affinität zu steuern.

Mit Knotenselektoren, Knotenaffinität und Interpod-Affinität kann der Kube-Scheduler Workloads logisch isolieren, z. B. durch die Hardware des Knotens.

Beispiel: Sie können Knoten ein Label zuweisen, das angibt, dass sie über lokal angeschlossenen SSD-Speicher verfügen. Um anzugeben, dass ein Pod nur auf Knoten mit lokal angeschlossenem SSD-Speicher ausgeführt werden soll, fügen Sie dieses Label dann als Knotenselektor in die Podspezifikation ein. Kubernetes plant die Pods nur auf Knoten mit übereinstimmenden Labels.

Siehe Pods zu Knoten zuweisen in der Kubernetes-Dokumentation.

Best Practice: OCI Full Stack Disaster Recovery-Service für Backup und Disaster Recovery verwenden

Wir empfehlen, den OCI Full Stack Disaster Recovery-Service mit Kubernetes Engine für Backup und Disaster Recovery zu verwenden. Full Stack Disaster Recovery ist ein Cloud-nativer Disaster-Recovery-Orchestrierungs- und -Managementservice, der umfassende Disaster-Recovery-Funktionen für alle Layer eines Anwendungsstacks bereitstellt, einschließlich Infrastruktur, Middleware, Datenbank und Anwendungen.

Wenn Sie Full Stack Disaster Recovery verwenden, können Sie Kubernetes-Cluster, die Sie mit der Kubernetes Engine erstellt haben, zu Disaster-Recovery-Schutzgruppen hinzufügen, sodass Sie die End-to-End-Recovery-Orchestrierung Ihres Kubernetes-Systems zwischen OCI-Regionen automatisieren können.

Weitere Informationen finden Sie in der Dokumentation zu Full Stack Disaster Recovery sowie insbesondere in den folgenden Abschnitten:

• Kubernetes Engine (OKE) für Disaster Recovery vorbereiten
• OKE-Cluster zu einer Disaster-Recovery-Schutzgruppe hinzufügen
• das Tutorial Switchover- und Failover-Pläne für OCI Kubernetes Engine (zustandsbehaftet) mit OCI Full Stack Disaster Recovery automatisieren

Beachten Sie, dass wir vor der Veröffentlichung von Full Stack Disaster Recovery zuvor die Verwendung von Tools von Drittanbietern (wie Kasten, Rancher, Trilio oder Velero) mit der Kubernetes Engine für Backup und Disaster Recovery empfohlen haben. Wenn bereits ein Disaster Recovery-Tool eines Drittanbieters vorhanden ist, können Sie es weiterhin verwenden. Wir empfehlen Ihnen jedoch, die Vorteile von OCI Full Stack Disaster Recovery als Alternative zu Tools von Drittanbietern zu betrachten.