OKE - Best Practices

Erfahren Sie mehr über OKE-Best Practices für Compute Cloud@Customer.

Verwenden Sie die in diesem Thema beschriebenen Best Practices, um das Beste aus Ihren Kubernetes-Engine-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.

Verwenden Sie Kubernetes-Labels, um die vielen Kubernetes-Ressourcen (wie Services, Pods, Container und Netzwerke) zu 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 dem Ressourcentagging können Sie die vielen Ressourcen (wie Worker-Knoten, VCNs, Load Balancer und Block-Volumes) organisieren, die von den Kubernetes-Clustern verwendet werden, die Sie mit der Kubernetes-Engine erstellen.

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 schwierig sein, die Ressourcen zu aggregieren, über sie zu berichten und Massenaktionen an ihnen durchzuführen.

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

Weitere Informationen finden Sie unter Ressourcen auf Compute Cloud@Customer taggen.

Ressourcenanforderungen und -grenzwerte festlegen

  • 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 nicht in einem Kubernetes-Cluster bereitgestellt werden, da nur begrenzte Ressourcen auf diesem Cluster verfügbar sind. 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 beginnt, mehr CPU oder Speicher auf einem Knoten zu belegen, kann der Kubernetes-Scheduler (kube-scheduler) möglicherweise keine neuen Pods auf dem Knoten platzieren, und der Knoten stürzt möglicherweise sogar ab.

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

Stellen Sie dedizierte Knoten mithilfe von Farben und Toleranzen bereit.

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

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

Weitere Informationen finden Sie unter Farben und Toleranzen auf der Website kubernetes.io.

Kontrollieren 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 Label-Selektoren, um die Knotenauswahl anzugeben.

Oft macht die kube-scheduler eine angemessene Platzierung, wenn Constraints 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 Pod-übergreifende Affinität zu steuern.

Durch die Verwendung von Knotenselektoren, Knotenaffinität und Pod-übergreifende 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 Tools von Drittanbietern wie Velero mit der Kubernetes Engine für Backup und Disaster Recovery.

Die kombinierten Backup- und Disaster Recovery-Funktionen dieser Tools und der Kubernetes Engine 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 erwarten, 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 zu, wenn Sie die Größe des VCN festlegen, 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-Plug-in aus, das Ihren Anforderungen am besten entspricht.

Berücksichtigen Sie die Podnetzwerkanforderungen sorgfältig, und wählen Sie dann das Podnetzwerk-CNI-Plug-in aus, das Ihren Anforderungen am besten entspricht.

  • 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 Anzeigen von Anwendungen entsprechend.

Achten Sie beim Provisioning eines Network Load Balancers für einen Kubernetes-Service des Typs LoadBalancer sorgfältig auf 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-Adressbereich überschneiden können, der On-Premise oder in anderen verbundenen VCNs verwendet wird.

Planen Sie die Anzahl der benötigten Knoten.

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 CNI-Plug-in für Podnetze berücksichtigt.

Verwenden Sie separate Subnetze und Sicherheitsregeln.

Verwenden Sie separate Subnetze und Sicherheitsregeln bei der Konfiguration von Netzwerkressourcen. Das VCN, in dem Sie Cluster erstellen und bereitstellen möchten, muss mindestens zwei verschiedene Subnetze aufweisen und kann über mehr verfügen:

  • Ein Kubernetes-API-Endpunktsubnetz

  • Ein Worker-Knotensubnetz

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

  • Ein Pods-Subnetz (bei Verwendung des OCI-VCN-nativen Podnetworking-CNI-Plug-ins)

  • Ein Bastionsubnetz (optional)

Sie können die Subnetze und Sicherheitsregeln auch kombinieren. Dieser Ansatz erschwert jedoch die Verwaltung der Sicherheit und wird daher nur empfohlen, wenn Sie Netzwerksicherheitsgruppen zur Kontrolle des Zugriffs auf Cluster verwenden.

Best Practices zur Sicherheit

Planrisikostufe.

Beantworten Sie die folgenden Fragen, bevor Sie einen Sicherheitsplan für die Cluster implementieren, die Sie mit der Kubernetes-Engine erstellen:

  • Wie viel Internet-Exposition sollen 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 verbraucht das Cluster?

Erstellen Sie private Cluster.

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 Clustertraffic 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 zur Sicherheit.

  • Spielen Sie Sicherheitspatches regelmäßig ein.

  • Verwenden Sie eine Kombination aus Kubernetes-Netzwerkrichtlinien und NSGs.

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

  • Secrets und Zertifikate regelmäßig rotieren.

  • Führen Sie alle Anwendungen als nicht privilegierter Benutzer aus.

  • Behältnisse als unveränderlich behandeln.

Auditing, Logging und Überwachung.

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

  • Auditprotokollierung aktivieren.

  • Verwenden Sie clusterbasiertes Kubernetes-Logging.

  • Clusterkomponenten überwachen.

  • Protokollieren Sie Netzwerkverkehrsmetadaten, und analysieren Sie sie regelmäßig.

  • Verwenden Sie kleine und sichere Container-Images.

  • Beschränken Sie die Berechtigungsprüfung.

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.

  • Sichern und sichern Sie Daten.

Best Practices für Upgrades

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

  • Richten Sie Test- und Produktionsumgebungen ein.

  • Cordon und Drain Worker Knoten in Vorbereitung auf die Wartung.

  • Worker-Knoten als unveränderlich behandeln.