Best Practices für OKE

Weitere Informationen zu OKE-Best Practices für Compute Cloud@Customer.

Verwenden Sie die in diesem Thema beschriebenen Best Practices, um das Beste aus Ihren OKE-Clustern herauszuholen.

Best Practices für das Clustermanagement

Cluster aktualisieren

Führen Sie ein Upgrade Ihrer Cluster aus, damit sie immer Kubernetes-Versionen ausführen, die als aktuell von OKE unterstützt aufgeführt sind. Wenn Sie ein Cluster anzeigen, wird angezeigt, ob eine neuere Kubernetes-Version für dieses Cluster verfügbar ist. Siehe Unterstützte Kubernetes-Versionen und OKE-Cluster aktualisieren.

Verwenden Sie Kubernetes-Labels.

Mit Kubernetes-Labels können Sie die vielen Kubernetes-Ressourcen (wie Services, Pods, Container und Netzwerke) organisieren, aus denen ein Cluster besteht.

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

Ressourcen-Tagging verwenden

Mit Ressourcentagging können Sie die vielen Ressourcen (wie Worker-Knoten, VCNs, Load Balancer und Block-Volumes) organisieren, die von den mit OKE erstellten Kubernetes-Clustern verwendet werden.

Wenn eine große Anzahl von Ressourcen auf mehrere Compartments in einem Mandanten verteilt ist, kann es schwierig sein, die Ressourcen zu verfolgen, die für bestimmte Zwecke verwendet werden. Es kann auch eine Herausforderung sein, die Ressourcen zu aggregieren, darüber zu berichten und Massnahmen zu ergreifen.

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

Weitere Informationen finden Sie unter Ressourcen taggen (IAM in OCI).

Legen Sie Ressourcenanforderungen und -limits fest.

  • Legen Sie Ressourcenanforderungen fest, um die Mindestmenge an Ressourcen anzugeben, die ein Container verwenden kann.

  • Legen Sie Ressourcenlimits fest, um die maximale Ressourcenmenge anzugeben, die ein Container verwenden kann.

Manchmal kann eine Anwendung aufgrund der begrenzten Verfügbarkeit von Ressourcen in diesem Cluster nicht auf einem Kubernetes-Cluster bereitgestellt werden. Der Fehler beim Deployment der Anwendung kann vermieden werden, indem Ressourcenanforderungen und Ressourcenlimits korrekt festgelegt werden.

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 Kubernetes-Scheduler (kube-scheduler) möglicherweise keine neuen Pods auf dem Knoten platzieren, und der Knoten kann sogar abstürzen.

Weitere Informationen finden Sie unter Resource Management für Pods und Container auf der Site kubernetes.io.

Stellen Sie dedizierte Knoten bereit, indem Sie Taints und Toleranzen verwenden.

Verwenden Sie Kubernetes-Taints und -Toleranzen, um ressourcenintensive Anwendungen auf bestimmte Worker-Knoten zu begrenzen.

Durch die Verwendung von Taints und Toleranzen können Sie Knotenressourcen für Workloads, die sie benötigen, verfügbar halten und die Planung anderer Workloads auf den Knoten verhindern.

Weitere Informationen finden Sie unter Taints and Tolerations auf der Site kubernetes.io.

Steuern Sie die Podplanung mithilfe von Knotenselektoren und Affinität.

Es stehen verschiedene Methoden zur Verfügung, um die Ausführung eines Pods auf bestimmten Knoten einzuschränken oder eine Voreinstellung für die Ausführung eines Pods auf bestimmten Knoten anzugeben. Die empfohlenen Ansätze verwenden alle Labelselektoren, um die Knotenauswahl anzugeben.

Häufig führt die kube-scheduler eine angemessene Platzierung durch, wenn Einschränkungen und Voreinstellungen nicht angegeben werden. Es gibt jedoch einige Umstände, unter denen Sie den Knoten steuern möchten, auf dem ein Pod ausgeführt wird. In diesen Situationen ist es Best Practice, die Planung von Pods auf Knoten mit Kubernetes-Knotenselektoren, Knotenaffinität und Inter-Pod-Affinität zu steuern.

Durch die Verwendung von Knotenselektoren, Knotenaffinität und Interpod-Affinität kann kube-scheduler Workloads logisch isolieren, z.B. entsprechend der Hardware des Knotens.

Verwenden Sie Tools von Drittanbietern für Backup und Disaster Recovery.

Verwenden Sie Drittanbietertools wie Velero mit OKE für Backup und Disaster Recovery.

Die kombinierten Backup- und Disaster Recovery-Funktionen dieser Tools und OKE können eine zuverlässige, robuste und skalierbare Kubernetes-Plattform bereitstellen, die produktionsreif ist.

Best Practices für Networking

Erstellen Sie separate Compartments für jedes Team.

Wenn Sie davon ausgehen, dass mehrere Teams Cluster erstellen, erstellen Sie ein separates Compartment für jedes Team.

Passen Sie die Größe Ihres VCN an.

Lassen Sie mögliche zukünftige Skalierungsanforderungen für Cluster- und Knotenpools bei der Skalierung des VCN zu, in dem Sie Kubernetes-Cluster erstellen und bereitstellen möchten.

Stellen Sie sicher, dass das VCN über einen CIDR-Block verfügt, der groß genug ist, um allen Ressourcen, die ein Cluster benötigt, Netzwerkadressen zuzuweisen: Subnetze, Kubernetes-API-Endpunkt, Worker-Knoten, Pods, Load Balancer.

Wählen Sie das Pod-Networking-CNI-Plugin aus, das Ihren Anforderungen am besten entspricht.

Erwägen Sie die Pod-Netzwerkanforderungen sorgfältig, und wählen Sie dann das Pod-Netzwerk-CNI-Plugin aus, das am besten zu Ihren Anforderungen passt.

  • Wenn Anwendungen die Verwendung von grundlegenden Netzwerkanforderungen erfordern (und nicht die Verwendung von IP-Adressen aus dem VCN) oder eine hohe Poddichte pro Worker-Knoten erfordern, empfiehlt es sich, das Flannel Overlay-CNI-Plug-in zu verwenden. Siehe Flannel Overlay-Netzwerkressourcen erstellen.

  • Wenn Anwendungen erfordern, dass Pods über eine IP-Adresse aus dem VCN-CIDR verfügen oder die konsistente Netzwerkperformance von virtuellen Maschinen (unabhängig von den Knoten, auf denen die Pods ausgeführt werden) ohne zusätzliches Overlay erfordern, empfiehlt es sich, das OCI VCN-native Pod Networking-CNI-Plug-in zu verwenden. Siehe Native Podnetzwerkressourcen für VCN erstellen.

Konfigurieren Sie externalTrafficPolicy beim Bereitstellen von Anwendungen entsprechend.

Berücksichtigen Sie beim Provisioning eines Network Load Balancers für einen Kubernetes-Service vom Typ LoadBalancer sorgfältig den am besten geeigneten Wert für die Einstellung externalTrafficPolicy.

Vermeiden Sie Überschneidungen von Pod- und Service-CIDR-Blöcken mit einem On-Premise-CIDR-Block und bei Verwendung des Flannel Overlay-CNI-Plug-ins.

Vermeiden Sie die Situation, in der sich der CIDR-Block, der vom Flannel Overlay-Netzwerk zum Provisioning von Pods und Services mit IP-Adressen verwendet wird, mit einem CIDR-Block überschneidet, der zum Provisioning externer Compute-Instanzen mit IP-Adressen verwendet wird.

Kubernetes-Cluster erfordern eine eindeutige IP-Adresse für jeden Pod. Daher ist eine IP-Adressplanung erforderlich, da sich Adressen nicht mit dem privaten IP-Adressraum überschneiden können, der On-Premise oder in anderen verbundenen VCNs verwendet wird.

Planen Sie die Anzahl der Knoten, die Sie benötigen.

Erstellen Sie einen Plan für die Anzahl der Knoten in einem Cluster, der die Knotengröße, das Anwendungsprofil von Pods und das ausgewählte Pod-Networking-CNI-Plug-in berücksichtigt.

Verwenden Sie separate Subnetze und Sicherheitsregeln.

Verwenden Sie separate Subnetze und Sicherheitsregeln, wenn Sie Netzwerkressourcen konfigurieren. Das VCN, in dem Sie Cluster erstellen und bereitstellen möchten, muss mindestens zwei verschiedene Subnetze aufweisen und kann mehrere Subnetze aufweisen:

  • Ein Kubernetes-API-Endpunktsubnetz

  • Ein Worker-Knoten-Subnetz

  • Ein regionales oder zwei AD-spezifische Load-Balancer-Subnetze (optional)

  • Podsubnetz (bei Verwendung des CNI-Plug-ins für OCI-VCN-natives Podnetzwerk)

  • Ein Bastionsubnetz (optional)

Sie können die Subnetze kombinieren und auch Sicherheitsregeln kombinieren. Dieser Ansatz erschwert jedoch die Verwaltung der Sicherheit und wird daher nur empfohlen, wenn Sie Netzwerksicherheitsgruppen verwenden, um den Zugriff auf Cluster zu kontrollieren.

Best Practices bei der Sicherheit

Planrisikostufe

Beantworten Sie die folgenden Fragen, bevor Sie einen Sicherheitsplan für die mit OKE erstellten Cluster implementieren:

  • Wie viel Internet-Exposition wollen Sie Cluster haben?

  • Wie planen Sie, Workloads intern für Ihr VCN und extern für das Internet bereitzustellen?

  • Wie planen Sie die Skalierung von Workloads?

  • Welche Oracle-Services werden vom Cluster genutzt?

Private Cluster erstellen

Wenn Ihr Cluster keinen direkten Zugriff aus dem Internet benötigt, erstellen Sie ein privates Cluster. In einem privaten Cluster werden dem Kubernetes-API-Server und den Worker-Knoten nur private IP-Adressen zugewiesen.

Optional können Sie ein NAT-Gateway für den ausgehenden Internetzugriff, ein dynamisches Routinggateway (DRG) für den Zugriff vom On-Premise-Netzwerk und ein lokales Peering-Gateway (LPG) für den Zugriff von anderen VCNs verwenden.

Platzieren Sie alle Anwendungen in privaten Subnetzen.

Wenn die Anwendungen, die auf Worker-Knoten ausgeführt werden, keinen direkten Zugriff auf das Internet erfordern, müssen sowohl das Worker-Knoten-Subnetz als auch das Worker-Load-Balancer-Subnetz privat sein.

Schränken Sie den Clusterverkehr mit Netzwerksicherheitsgruppen ein.

Definieren Sie Sicherheitsregeln in Netzwerksicherheitsgruppen (NSGs) und nicht in Sicherheitslisten für das VCN, in dem Sie Cluster erstellen und bereitstellen möchten. Siehe Traffic mit Netzwerksicherheitsgruppen kontrollieren.

Allgemeine Best Practices bei der Sicherheit.

  • Spielen Sie Sicherheitspatches regelmäßig ein.

  • Verwenden Sie eine Kombination aus Kubernetes-Netzwerk-Policys und NSGs.

  • Verwenden Sie NSGs in Verbindung mit Infrastructure-as-Code-Tools (wie Terraform).

  • Rotieren Sie Secrets und Zertifikate regelmäßig.

  • Führen Sie alle Anwendungen als Benutzer ohne Berechtigung aus.

  • Behandeln Sie Container als unveränderlich.

Auditing, Logging und Monitoring.

  • Prüfen Sie die Logs regelmäßig.

  • Aktivieren Sie das Auditlogging.

  • Clusterbasiertes Kubernetes-Logging verwenden

  • Clusterkomponenten überwachen

  • Protokollieren Sie Metadaten des Netzwerkverkehrs, und analysieren Sie sie regelmäßig.

  • Verwenden Sie kleine und sichere Container-Images.

  • Beschränken Sie die Offenlegung von Zugangsdaten.

Best Practices für den Speicher

  • Wählen Sie den entsprechenden Speichertyp.

  • Erstellen und verwenden Sie Speicherklassen, um Anwendungsanforderungen zu definieren.

  • Erstellen und verwenden Sie Volumes für persistenten Speicher.

  • Begrenzen Sie den Speicherressourcenverbrauch.

  • Daten sichern und sichern

Best Practices für Upgrades

  • Verwenden Sie die neueste unterstützte Version von Kubernetes.

  • Test- und Produktionsumgebungen einrichten

  • Cordon- und Drain-Worker-Knoten zur Vorbereitung auf die Wartung.

  • Worker-Knoten als unveränderlich behandeln.