Oracle Cloud Infrastructure - Dokumentation

Best Practices für Networking

Erfahren Sie mehr über Best Practices für die Konfiguration von Netzwerkoptionen für Cluster, die Sie mit Kubernetes Engine (OKE) erstellt haben.

Dieser Abschnitt enthält Best Practices für Networking und Kubernetes Engine.

In diesem Abschnitt werden die Best Practices für die Konfiguration von Netzwerkoptionen für Kubernetes-Cluster beschrieben, die Sie mit Kubernetes Engine erstellen. Dieser Abschnitt soll keine Konzepte oder Terminologie für Kubernetes-Netzwerke vorstellen und geht davon aus, dass Sie bereits über ein gewisses Maß an Kubernetes-Netzwerkwissen verfügen. Weitere Informationen finden Sie unter Netzwerkressourcenkonfiguration für Clustererstellung und -Deployment.

Best Practice: Separate Compartments für jedes Team erstellen

Es wird empfohlen, ein separates Compartment für jedes Team zu erstellen, wenn Sie erwarten, dass mehrere Teams Cluster erstellen.

Beispiel: Netzwerkressourcen wie das virtuelle Cloud-Netzwerk (VCN) und Subnetze, die für die Kubernetes-Engine verwendet werden, können sich alle im Root Compartment befinden. Wenn jedoch erwartet wird, dass mehrere Teams Cluster erstellen, wird empfohlen, dass Sie ein separates Compartment für die Clusterressourcen jedes Teams erstellen (z.B. als untergeordnete Compartments des Root Compartments). Da sich ein Cluster und seine Ressourcen nicht in demselben Compartment wie das VCN und die Subnetze befinden müssen, ist es einfacher und sauberer, Cluster zu trennen und sicher zu halten, da separate Compartments für jedes Team vorhanden sind.

Siehe Netzwerkressourcenkonfiguration für Clustererstellung und -Deployment.

Best Practice: VCN entsprechend skalieren

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

Das VCN muss über einen CIDR-Block verfügen, der groß genug ist, um allen Ressourcen, die ein Cluster benötigt, Netzwerkadressen zuzuweisen (Subnetze, Kubernetes-API-Endpunkt, Worker-Knoten, Pods, Load Balancer).

Siehe VCN-Konfiguration und IPv4 CIDR-Blöcke und Kubernetes Engine (OKE).

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

Wir empfehlen Ihnen, die Pod-Netzwerkanforderungen sorgfältig zu berücksichtigen und dann das Pod-Networking-CNI-Plug-in auszuwählen, das Ihren Anforderungen am besten entspricht.

Beispiel:

  • Wenn Anwendungen grundlegende Netzwerkanforderungen (und nicht die Verwendung von IP-Adressen aus dem VCN) erfordern oder eine hohe Dichte von Pods pro Worker-Knoten erfordern, wird die Verwendung des Flannel CNI-Plug-ins empfohlen.
  • Wenn Anwendungen Pods eine IP-Adresse aus dem VCN-CIDR benötigen und/oder die konsistente Netzwerkperformance von virtuellen Maschinen (unabhängig von den Knoten, auf denen die Pods ausgeführt werden) ohne zusätzliches Overlay erfordern, wird die Verwendung des OCI-CNI-Plug-ins für VCN-natives Podnetzwerk empfohlen.

Siehe Pod Networking und IPv4 CIDR-Blöcke und Kubernetes Engine (OKE).

Best Practice: externalTrafficPolicy beim Anzeigen von Anwendungen entsprechend konfigurieren

Beim Provisioning eines Network Load Balancers für einen Kubernetes-Service vom Typ LoadBalancer wird empfohlen, den am besten geeigneten Wert für die Einstellung externalTrafficPolicy zu berücksichtigen:

  • externalTrafficPolicy: Cluster (Clustermodus)

    Geben Sie den Clustermodus an, wenn Sie Traffic immer an alle Pods weiterleiten möchten, auf denen ein Service mit gleicher Verteilung ausgeführt wird, und Client-IP-Adressen nicht beibehalten möchten. Im Clustermodus leitet Kubernetes jeden Traffic, der an einen beliebigen Worker-Knoten auf einem bestimmten Port gesendet wird, an einen der Pods dieses Service weiter.

    Der Clustermodus führt häufig zu einer geringeren Abwanderung von Backends im Cluster, da das Anforderungsrouting nicht vom Status der Pods im Cluster abhängt. Jede Anforderung kann an einen beliebigen Knoten gesendet werden, und Kubernetes verarbeitet das Abrufen der Anforderung an den richtigen Ort. Clustermodus führt zu einer guten Lastverteilung vom Network Load Balancer über Worker-Knoten hinweg. Wenn der Datenverkehr einen Worker-Knoten erreicht, wird er vom Knoten auf dieselbe Weise verarbeitet. Der Load Balancer weiß nicht, welche Knoten im Cluster Pods für seinen Service ausführen. Wenn Sie ein regionales Subnetz für Worker-Knoten ausgewählt haben, wird die Last auf alle Knoten in allen Availability-Domains für die Region des Subnetzes verteilt. Im Clustermodus wird der Traffic über alle Knoten im Cluster verteilt, auch wenn Knoten keinen relevanten Pod ausführen.

  • externalTrafficPolicy: Local (lokaler Modus)

    Geben Sie den lokalen Modus an, wenn Anforderungen mit den IP-Adressen des Clients beendet werden sollen, die in den IP-Paket-Headern angegeben sind. Sie haben nur die Möglichkeit, Client-IP-Adressen beizubehalten, wenn Anforderungen an die Client-IP-Adressen beendet werden, die in den IP-Paket-Headern angegeben sind. Das heißt, wenn die Einstellung externalTrafficPolicy auf Local gesetzt ist.

    Der lokale Modus entfernt den zusätzlichen Netzwerk-Hop, der im Clustermodus erforderlich ist. Der Netzwerkverkehr kann jedoch möglicherweise ein Ungleichgewicht aufweisen, wenn das Netzwerk nicht ordnungsgemäß konfiguriert ist. Im lokalen Modus muss Ingress-Traffic an Knoten gesendet werden, auf denen die entsprechenden Pods für diesen Service ausgeführt werden. Andernfalls wird der Traffic gelöscht. Daher erhalten einige Anwendungspods möglicherweise mehr Traffic als andere Pods.

Weitere Informationen finden Sie unter Anforderungen auf dem empfangenden Knoten beenden und Client-IP-Adresse reservieren.

Best Practice: Vermeiden Sie sich überschneidende Pod- und Service-CIDR-Blöcke mit einem On-Premise-CIDR-Block und bei Verwendung des Flannel-CNI-Plug-ins

Es wird empfohlen, dass Sie vermeiden, dass 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 die Planung von IP-Adressen erforderlich, da Adressen sich nicht mit dem privaten IP-Adressraum überschneiden können, der On-Premise oder in anderen verbundenen VCNs verwendet wird.

Bei Verwendung des Flannel-CNI-Plugins wird die Kommunikation zwischen Pods in einem Cluster im Flannel-Overlay-Netzwerk gekapselt. Das Flannel-Overlay-Netzwerk verwendet einen eigenen CIDR-Block, um Pods und Worker-Knoten mit IP-Adressen bereitzustellen. Die Pods im Flannel-Overlay-Netzwerk sind nur von anderen Pods im selben Cluster aus zugänglich. Externe Compute-Instanzen außerhalb des Clusters können nicht direkt auf Pods zugreifen. Wenn ein Pod versucht, auf eine externe Compute-Instanz zuzugreifen, die dieselbe IP-Adresse wie ein anderer Pod im Cluster hat, wird die Anforderung falsch weitergeleitet, und es treten Probleme auf.

Siehe Flannel-CNI-Plug-in für Podnetworking verwenden.

Best Practice: Regionale Subnetze verwenden und Workloads für High Availability verteilen

Es wird empfohlen, regionale Subnetze für Worker-Knoten auszuwählen, um High Availability sicherzustellen und Workloads zwischen ihnen zu verteilen.

Für das VCN muss eine entsprechende Anzahl von Subnetzen für Worker-Knoten, Load Balancer und den Kubernetes-API-Endpunkt definiert sein. Die Verwendung regionaler Subnetze und die Verteilung von Workloads zwischen ihnen stellen High Availability sicher und vereinfachen die Implementierung von Failover über Availability-Domains hinweg.

Siehe Subnetzkonfiguration.

Best Practice: Verwenden Sie Constraints für die Topologieverteilung, um zu steuern, wie Pods verteilt werden

Es wird empfohlen, Constraints für die Podtopologieverteilung zu verwenden, um zu steuern, wie Pods zwischen Availability-Domains und Worker-Knoten verteilt werden.

Beispiel: Wenn viele Worker-Knoten verfügbar sind, aber nur zwei oder drei Pods erforderlich sind, möchten Sie in der Regel nicht, dass alle Pods auf demselben Worker-Knoten ausgeführt werden, um das Risiko eines einzelnen Point-of-Failure zu vermeiden, wenn ein Problem auftritt.

Da jedoch immer mehr Pods für Clients in mehreren Availability-Domains erforderlich sind, möchten Sie die Pods in der Regel gleichmäßig auf mehrere Worker-Knoten in diesen verschiedenen Availability-Domains verteilen. In diesem Szenario ist die Verteilung der Pods zur Reduzierung der Latenz und der Netzwerkkosten im Zusammenhang mit dem Senden des Netzwerkverkehrs zwischen Availability-Domains genauso problematisch wie die Vermeidung eines einzelnen Ausfalls. Möglicherweise möchten Sie eine ähnliche Anzahl von Pods in jeder Availability-Domain verwenden und das Cluster selbst heilen lassen, wenn ein Problem auftritt.

Mit Podtopologie-Verteilungs-Constraints können Sie ein Cluster konfigurieren, um die beiden Ziele High Availability und effiziente Ressourcenauslastung zu erreichen.

Weitere Informationen finden Sie in der Kubernetes-Dokumentation unter Verteilungs-Constraints für Podtopologie.

Best Practice: Anzahl der Knoten planen

Es wird empfohlen, einen Plan für die Anzahl der Knoten in einem Cluster zu erstellen, der die Knotengröße, das Anwendungsprofil der Pods und das ausgewählte Podnetzwerk-CNI-Plug-in berücksichtigt.

Bei Verwendung des Flannel-CNI-Plug-ins reservieren Cluster, die von der Kubernetes-Engine erstellt wurden, einen /25-Bereich für Pods aus dem Flannel-Overlay-Netzwerk und lassen bis zu 110 Pods pro Knoten zu. Wenn Sie das CNI-Plug-in für OCI-VCN-native Podnetworking verwenden, kann derselbe Knoten je nach ausgewählter Ausprägung für Worker-Knoten einen anderen Bereich aufweisen. Wählen Sie je nach Knotengröße und Anwendungsprofil der Pods im Voraus die gewünschte Knotenanzahl im Cluster aus.

Siehe Pod Networking.

Best Practice: Separate Subnetze und Sicherheitsregeln verwenden

Es wird empfohlen, bei der Konfiguration von Netzwerkressourcen separate Subnetze und Sicherheitsregeln zu verwenden.

Das VCN, in dem Sie Cluster erstellen und bereitstellen möchten, muss mindestens zwei (optional mehr) verschiedene Subnetze aufweisen:

  • ein Kubernetes-API-Endpunktsubnetz
  • ein Worker-Knotensubsetz
  • ein regionales oder zwei AD-spezifische Load-Balancer-Subnetze (optional)
  • ein Podsubnetz (bei Verwendung des OCI-VCN-nativen Podnetworking-CNI-Plug-ins)
  • Bastion-Subnetz (optional)

Sie können die Subnetze 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.

Siehe Subnetzkonfiguration.

Best Practice: Separate Subnetze für Load Balancer verwenden

Es wird empfohlen, separate Subnetze für Load Balancer zum Bereitstellen von Services zu erstellen.

Wenn Sie kein separates Load-Balancer-Subnetz erstellen, werden Services mit einer IP-Adresse aus dem Worker-Knotensubnetz bereitgestellt. Daher wird der zugewiesene Speicherplatz im Worker-Knotensubnetz möglicherweise vollständig verbraucht, bevor Sie erwartet haben. Dadurch kann das Cluster möglicherweise nicht auf die angegebene Knotenanzahl skaliert werden.

Bei den Load-Balancer-Subnetzen kann es sich um öffentliche oder private Subnetze handeln, je nachdem, wie der Zugriff auf die Anwendungen erfolgt, die im Cluster bereitgestellt werden. Wenn der Zugriff auf Anwendungen intern aus Ihrem VCN erfolgt, verwenden Sie private Subnetze für die Load Balancer. Wenn der Zugriff auf Anwendungen über das Internet erfolgt, verwenden Sie öffentliche Subnetze für die Load Balancer.

Siehe Load-Balancer-Subnetzkonfiguration.

Best Practice: Verwenden Sie ein privates Worker-Knotensubnetz für maximale Sicherheit

Für maximale Sicherheit empfehlen wir die Angabe eines privaten Subnetzes als Worker-Knotensubnetz.

Beim Subnetz des Worker-Knotens kann es sich entweder um ein einzelnes regionales Subnetz oder um mehrere AD-spezifische Subnetze handeln (jeweils ein Subnetz pro Availability-Domain). Das Worker-Knotensubnetz kann entweder ein öffentliches oder ein privates Subnetz sein. Für maximale Sicherheit empfehlen wir jedoch die Verwendung eines privaten Subnetzes für Worker-Knoten.

Siehe Worker Node Subnet Configuration.

Best Practice: Cluster zu VCN-nativ migrieren, um den Kubernetes-API-Endpunkt in Ihr VCN zu integrieren

Es wird empfohlen, Cluster zu migrieren, die noch nicht VCN-nativ sind, um VCN-nativ zu sein.

In einem VCN-nativen Cluster sind Worker-Knoten, Load Balancer und der Kubernetes-API-Endpunkt vollständig in Ihr eigenes VCN integriert und können als öffentlich oder privat konfiguriert werden. Der Zugriff auf das Kubernetes-API-Subnetz kann mit Sicherheitsregeln kontrolliert werden, die für Netzwerksicherheitsgruppen (empfohlen) oder Sicherheitslisten definiert sind.

Um die Sicherheitskontrolle zu nutzen, die von VCN-nativen Clustern angeboten wird, migrieren Sie ein Cluster, das noch nicht VCN-nativ ist, um seinen Kubernetes-API-Endpunkt in Ihr eigenes VCN zu integrieren.

Siehe In VCN-native Cluster migrieren.

Best Practice: Erstellen Sie eine ConfigMap, um das Standardverhalten von CoreDNS außer Kraft zu setzen

Wir empfehlen, dass Sie, wenn Sie das Standardverhalten von CoreDNS anpassen möchten, Ihr eigenes ConfigMap erstellen und anwenden, um Einstellungen in der CoreDNS-Coredatei außer Kraft zu setzen.

Beachten Sie, dass Anpassungen des CoreDNS-Standardverhaltens bei internen Aktualisierungen des Clusters regelmäßig gelöscht werden.

Siehe DNS-Server für Kubernetes-Cluster konfigurieren.

Best Practice: Einsatz von Readiness- und Liveness-Sonden für Health Checks

Es wird empfohlen, den Zustand von Containern in einem Cluster mit Kubernetes-Probes zur Lebendigkeit und Bereitschaft zu prüfen und die Probes an Ihre Anforderungen anzupassen.

Die Verwaltung großer, verteilter Systeme kann kompliziert sein, insbesondere wenn etwas schief geht. Mit Kubernetes-Health Checks können Sie ganz einfach sicherstellen, dass Anwendungsinstanzen funktionieren. Durch das Erstellen benutzerdefinierter Health Checks können Sie die Health Checks an Ihre Umgebung anpassen.

Insbesondere empfehlen wir dringend, dass Sie die Verwendung von Bereitschafts- und Lebendigkeitssonden in Betracht ziehen, um zu bestätigen, dass Container korrekt ausgeführt werden und funktionieren, bevor Sie sie dazu bringen, Traffic von einem Service zu erhalten. Die spezifischen Probe- und Probe-Parameter, die verwendet werden sollen, hängen von der Arbeitslast ab. Schlagen Sie ein Gleichgewicht zwischen der zu aggressiven und zu langsamen Sonde und optimieren Sie die Parameter, um die Anforderungen der Anwendung zu erfüllen.

Siehe Configure Liveness, Readiness and Startup Probes in der Kubernetes-Dokumentation.

Best Practice: Mit Load-Balancer- und Network Load-Balancer-Metriken Backends überwachen

Wir empfehlen, den Zustand des OCI-Load Balancers oder des Network Load Balancers zu überwachen, der für einen Kubernetes-Service des Typs LoadBalancer bereitgestellt ist.

Außerdem wird empfohlen, Alarme einzurichten, um Sie zu warnen, wenn die Backend-Verfügbarkeit einen Schwellenwert Ihrer Wahl unterschreitet. Beispiel:

  • Verwenden Sie die Metrik UnhealthyBackendServers des Load Balancers, um einen Alarm einzurichten, der Sie benachrichtigt, wenn die Anzahl der fehlerhaften Backend-Server in einem Backend-Set über Null steigt.
  • Verwenden Sie die Metrik BackendTimeouts des Load Balancers, um einen Alarm einzurichten, der Sie benachrichtigt, wenn die Anzahl der Timeouts für alle Backend-Server über null steigt.
  • Verwenden Sie die Metrik HealthyBackends des Network Load Balancers, um einen Alarm einzurichten, der Sie benachrichtigt, wenn die Anzahl der Backends, die Oracle als fehlerfrei erachtet, unter eins fällt.
  • Verwenden Sie die Network Load Balancer-Metrik UnhealthyBackends, um einen Alarm einzurichten, der Sie benachrichtigt, wenn die Anzahl der Backends, die Oracle als fehlerhaft erachtet, über Null steigt.

Siehe Load-Balancer-Metriken, Network Load Balancer-Metriken und Alarm erstellen.

Best Practice: Mit Knotenlabels eine Teilmenge von Worker-Knoten in ein Backend-Set aufnehmen

Wir empfehlen, die Annotation node-label-selector zu verwenden, um nur die Teilmenge der Worker-Knoten in das Backend-Set eines bestimmten Load Balancers oder Network Load Balancers aufzunehmen, die über die erforderlichen Anwendungspods verfügen. Wenn Sie Teilmengen der Worker-Knoten eines Clusters in die Backend-Sets verschiedener Load Balancer und Network Load Balancer aufnehmen, können Sie ein einzelnes Kubernetes-Cluster als mehrere logische Cluster (Services) darstellen.

Nachdem Sie den Worker-Knoten, die Sie in das Backend-Set eines Load Balancers oder Network Load Balancers aufnehmen möchten, ein Kubenetes-Label zugeordnet haben, geben Sie dieses Label im Manifest des Service vom Typ LoadBalancer an:

  • für einen Load Balancer die Annotation oci.oraclecloud.com/node-label-selector: verwenden
  • Verwenden Sie für einen Network Load Balancer die Annotation oci-network-load-balancer.oraclecloud.com/node-label-selector:
Beispiel:
apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/node-label-selector: lbset=ServiceA
spec:
  type: LoadBalancer
...
Mit der Knotenaffinität können Sie dann sicherstellen, dass Anwendungspods nur auf Worker-Knoten ausgeführt werden, die sich im Backend-Set des entsprechenden Load Balancers oder Network Load Balancers befinden. Beispiel: Das folgende Manifest beschreibt einen Pod mit einer requiredDuringSchedulingIgnoredDuringExecution-Knotenaffinität. Der Pod wird nur auf Knoten ausgeführt, auf denen das Label lbset auf ServiceA gesetzt ist:
apiVersion: v1
kind: Pod
...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: lbset
            operator: In
            values:
            - ServiceA
...

Siehe Worker-Knoten auswählen, die in Backend-Sets aufgenommen werden sollen.

Best Practice: Installieren Sie Calico, bevor Sie Knotenpools erstellen

Wenn Sie Calico zur Verbesserung der Clustersicherheit verwenden möchten, wird empfohlen, Calico auf einem Cluster zu installieren, bevor Sie Knotenpools erstellen.

Sie können die Clustersicherheit verbessern, indem Sie Kubernetes-Netzwerk-Policys implementieren. Um Kubernetes-Netzwerk-Policys zu implementieren, müssen Sie einen Netzwerkprovider installieren und konfigurieren, der NetworkPolicy-Ressourcen unterstützt. Ein solcher Anbieter ist Calico.

Wenn Sie Calico auf einem Cluster installieren, in dem bereits Knotenpools vorhanden sind, in denen Pods ausgeführt werden, müssen Sie die Pods neu erstellen, wenn die Calico-Installation abgeschlossen ist. Hierzu können Sie beispielsweise den Befehl kubectl rollout restart ausführen. Wenn Sie Calico auf einem Cluster installieren, bevor Sie Knotenpools im Cluster erstellen (wie empfohlen), können Sie sicher sein, dass Sie keine Pods neu erstellen müssen.

Informationen hierzu finden Sie unter Beispiel: Calico installieren und Netzwerk-Policys einrichten.