Unterstützte Labels für verschiedene Anwendungsfälle

Die Kubernetes-Engine fügt den einzelnen Worker-Knoten (sowohl verwaltete Knoten als auch virtuelle Knoten) in einem Cluster automatisch das Label topology.kubernetes.io/zone hinzu, je nachdem, in welcher Availability-Domain es platziert wird. (Das Label topology.kubernetes.io/zone war früher das Label failure-domain.beta.kubernetes.io/zone in früheren Kubernetes-Releases.)

Eine Availability-Domain entspricht einem oder mehreren Data Centern innerhalb einer Region. Eine Region besteht aus einer oder mehreren Availability-Domains. Availability-Domains sind voneinander isoliert und fehlertolerant. Daher ist es sehr unwahrscheinlich, dass sie gleichzeitig ausfallen. Siehe Regionen und Availability-Domains.

Sie können das Label topology.kubernetes.io/zone auf unterschiedliche Weise verwenden:

• Sie können das Label topology.kubernetes.io/zone (in Verbindung mit dem Label oci.oraclecloud.com/fault-domain) verwenden, um die Worker-Knoten einzuschränken, auf denen ein Pod ausgeführt werden soll, falls es sich um ein Cluster mit Worker-Knoten in mehreren Availability-Domains handelt. Schließen Sie das Label topology.kubernetes.io/zone in die Podspektion ein, um die Availability-Domain für die Platzierung der Worker-Knoten anzugeben.
• Mit dem Label topology.kubernetes.io/zone können Sie die Availability-Domain und die Region angeben, um Persistent Volume Claims im Block-Volume-Service bereitzustellen, wenn Sie das Volume-Plug-in FlexVolume verwenden. Siehe Speicher für Kubernetes-Cluster einrichten.

Wenn Sie einen Wert für das Label topology.kubernetes.io/zone angeben, müssen Sie die richtige gekürzte Version des Availability-Domainnamens in einer Oracle Cloud Infrastructure-Region verwenden.

In den meisten Fällen haben die gekürzten Versionen der Availability-Domainnamen das Format <region-identifier>-1-AD-<availability-domain-number>. Beispiel: UK-LONDON-1-AD-1, UK-LONDON-1-AD-2, UK-LONDON-1-AD-3, AP-MELBOURNE-1-AD-1, ME-JEDDAH-1-AD-1. Weitere Informationen zu den verwendeten Regions-IDs und Availability-Domains finden Sie unter Verfügbarkeit nach Region.

Hinweis: Die gekürzten Versionen der Availability-Domainnamen in den Regionen "Ashburn" und "Phoenix" sind Ausnahmen, wie unten dargestellt:

• Für die Region "Phoenix" haben abgekürzte Versionen der Availability-Domainnamen das Format PHX-AD-<availability-domain-number>. Beispiele: PHX-AD-1, PHX-AD-2, PHX-AD-3.
• Für die Region "Ashburn" haben abgekürzte Versionen der Availability-Domainnamen das Format US-ASHBURN-AD-<availability-domain-number>. Beispiele: US-ASHBURN-AD-1, US-ASHBURN-AD-2, US-ASHBURN-AD-3.

Die Kubernetes-Engine fügt jedem Worker-Knoten (sowohl verwaltete Knoten als auch virtuelle Knoten) in einem Cluster automatisch das Label oci.oraclecloud.com/fault-domain entsprechend der Faultdomain hinzu, in der er platziert ist.

Eine Faultdomain ist eine Gruppierung von Hardware und Infrastruktur, die sich von anderen Faultdomains in derselben Availability-Domain unterscheidet. Jede Availability-Domain umfasst drei Faultdomains (FAULT-DOMAIN-1, FAULT-DOMAIN-2, FAULT-DOMAIN-3). Jede Compute-Instanz wird in eine Faultdomain platziert. Siehe Faultdomains.

Sie können die Worker-Knoten einschränken, auf denen ein Pod ausgeführt werden soll, indem Sie das Label oci.oraclecloud.com/fault-domain in die Podspezifikation einschließen. Mit dem Label oci.oraclecloud.com/fault-domain geben Sie die Faultdomain an, in der Worker-Knoten platziert werden müssen.

Normalerweise verwenden Sie das Label oci.oraclecloud.com/fault-domain, um High Availability zu erreichen, wenn sich ein Cluster in einer Region mit einer einzelnen Availability-Domain befindet.

Beispiel:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
  nodeSelector:
    oci.oraclecloud.com/fault-domain: FAULT-DOMAIN-3

Wenn Sie das obige Beispiel für eine Podspezifikation auf ein Cluster anwenden, wird nur ein nginx-Pod erstellt, wenn das Cluster Worker-Knoten in FAULT-DOMAIN-3 in der Availability-Domain aufweist. Wenn das Cluster nur Worker-Knoten in FAULT-DOMAIN-1 oder FAULT-DOMAIN-2 enthält, wird der Pod nicht erstellt und behält den Status "Ausstehend" bei.

Wenn ein Cluster Worker-Knoten in mehreren Availability-Domains hat, schließen Sie sowohl das Label failure-domain.beta.kubernetes.io/zone als auch das Label oci.oraclecloud.com/fault-domain in eine Podspezifikation ein, um die Availability-Domain und die Faultdomain der Worker-Knoten anzugeben, auf denen der Pod ausgeführt werden soll.

Die Kubernetes-Engine aktiviert automatisch das Feature-Gate ServiceNodeExclusion in den erstellten Clustern. Wenn das ServiceNodeExclusion-Feature-Gate in einem Cluster aktiviert ist, können Sie bestimmten verwalteten Knoten ein Label hinzufügen, um sie aus der Liste der Backend-Server in einem Oracle Cloud Infrastructure-Load-Balancer-Backend-Set auszuschließen. Je weniger Worker-Knoten in einem Backend-Set enthalten sind, desto schneller kann der Load Balancer aktualisiert werden.

kubectl label nodes <node-name> node.kubernetes.io/exclude-from-external-load-balancers=true

Beispiel:

kubectl label nodes 10.0.1.2 node.kubernetes.io/exclude-from-external-load-balancers=true

Hinweis: Wenn Sie einem Knoten das Label hinzugefügt haben, wird der Knoten unabhängig vom Wert des Labels aus der Liste der Backend-Server ausgeschlossen. Auch wenn Sie beispielsweise node.kubernetes.io/exclude-from-external-load-balancers label=false angeben, wird der Worker-Knoten aus der Liste der Backend-Server ausgeschlossen.

Um das Label für den Knoten zu entfernen, geben Sie Folgendes ein:

kubectl label nodes <node-name> node.kubernetes.io/exclude-from-external-load-balancers-

Um alle Knoten in einem Knotenpool aus der Liste der Backend-Server auszuschließen, fügen Sie node.kubernetes.io/exclude-from-external-load-balancers=true zur Eigenschaft Kubernetes-Labels des Knotenpools hinzu, wenn Sie den Knotenpool erstellen oder ändern.

Beachten Sie, dass das Label node.kubernetes.io/exclude-from-external-load-balancers bei virtuellen Knoten nicht unterstützt wird.