Libellés pris en charge pour différents cas d'emploi

Le moteur Kubernetes ajoute automatiquement le libellé topology.kubernetes.io/zone à chaque noeud de processus actif (noeuds gérés et noeuds virtuels) d'un cluster, en fonction du domaine de disponibilité dans lequel il est placé. (Le libellé topology.kubernetes.io/zone était auparavant le libellé failure-domain.beta.kubernetes.io/zone dans les versions antérieures de Kubernetes.)

Un domaine de disponibilité représente les centres de données situés dans une région. Une région est composée de domaines de disponibilité. Les domaines de disponibilité sont isolés les uns des autres, tolèrent les pannes et sont prémunis contre les pannes simultanées. Reportez-vous à Régions et domaines de disponibilité.

Vous pouvez utiliser le libellé topology.kubernetes.io/zone de différentes manières :

• Vous pouvez utiliser le libellé topology.kubernetes.io/zone (conjointement avec le libellé oci.oraclecloud.com/fault-domain) pour limiter les noeuds de processus actif sur lesquels exécuter un pod, dans le cas d'un cluster ayant des noeuds de processus actif dans plusieurs domaines de disponibilité. Incluez le libellé topology.kubernetes.io/zone dans la spécification de pod pour indiquer le domaine de disponibilité dans lequel les noeuds de processus actif doivent avoir été placés.
• Vous pouvez utiliser le libellé topology.kubernetes.io/zone pour indiquer la région et le domaine de disponibilité afin de provisionner les demandes de volume persistant sur le service Block Volume lors de l'utilisation du module d'extension de volume FlexVolume. Reportez-vous à Configuration du stockage pour les clusters Kubernetes.

Lorsque vous spécifiez une valeur pour le libellé topology.kubernetes.io/zone, vous devez utiliser la version raccourcie correcte du nom de domaine de disponibilité dans une région Oracle Cloud Infrastructure.

Dans la plupart des cas, les versions abrégées des noms de domaine de disponibilité sont au format <region-identifier>-1-AD-<availability-domain-number>. Par exemple : 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. Pour connaître les identificateurs de région et les domaines de disponibilité à utiliser, reportez-vous à Disponibilité par région.

Les versions abrégées des noms de domaine de disponibilité dans les régions Ashburn et Phoenix sont des exceptions, comme indiqué ci-dessous :

• Pour la région Phoenix, les versions abrégées des noms de domaine de disponibilité sont au format PHX-AD-<availability-domain-number>. Par exemple, PHX-AD-1, PHX-AD-2, PHX-AD-3.
• Pour la région Ashburn, les versions abrégées des noms de domaine de disponibilité sont au format US-ASHBURN-AD-<availability-domain-number>. Par exemple, US-ASHBURN-AD-1, US-ASHBURN-AD-2, US-ASHBURN-AD-3.

Kubernetes Engine ajoute automatiquement le libellé oci.oraclecloud.com/fault-domain à chaque noeud de processus actif (noeuds gérés et noeuds virtuels) dans un cluster, en fonction du domaine de pannes dans lequel il se trouve.

Un domaine de pannes est un regroupement de matériel et d'infrastructure distinct des autres domaines de pannes du même domaine de disponibilité Chaque domaine de disponibilité comporte trois domaines de pannes (nommés FAULT-DOMAIN-1, FAULT-DOMAIN-2, FAULT-DOMAIN-3). Chaque instance de calcul est placée dans un domaine de pannes. Reportez-vous à Domaines de pannes.

Vous pouvez limiter les noeuds de processus actif sur lesquels exécuter un pod en incluant le libellé oci.oraclecloud.com/fault-domain dans la spécification du pod. Utilisez le libellé oci.oraclecloud.com/fault-domain pour indiquer le domaine de pannes dans lequel les noeuds de processus actif doivent avoir été placés.

Vous utiliserez généralement le libellé oci.oraclecloud.com/fault-domain pour obtenir une haute disponibilité lorsqu'un cluster est situé dans une région avec un seul domaine de disponibilité.

Par exemple :

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

Si vous appliquez l'exemple de spécification de pod ci-dessus à un cluster, un pod nginx n'est créé que si le cluster comporte des noeuds de processus actif dans FAULT-DOMAIN-3 dans le domaine de disponibilité. Si le cluster a uniquement des noeuds de processus actif dans FAULT-DOMAIN-1 ou FAULT-DOMAIN-2, le pod n'est pas créé et reste dans un statut en attente.

Si un cluster comporte des noeuds de processus actif dans plusieurs domaines de disponibilité, incluez les libellés failure-domain.beta.kubernetes.io/zone et oci.oraclecloud.com/fault-domain dans une spécification de pod pour indiquer à la fois le domaine de disponibilité et le domaine de pannes des noeuds de processus actif sur lesquels exécuter le pod.

Le moteur Kubernetes active automatiquement le portail de fonctionnalité ServiceNodeExclusion sur les clusters qu'il crée. Lorsque le point de contrôle de fonctionnalité ServiceNodeExclusion est activé sur un cluster, vous pouvez ajouter un libellé à des noeuds gérés spécifiques pour les exclure de la liste des serveurs back-end d'un ensemble d'équilibreurs de charge Oracle Cloud Infrastructure. Moins les noeuds de processus actif inclus dans un ensemble de back-ends sont nombreux, plus l'équilibreur de charge peut être mis à jour rapidement.

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

Par exemple :

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

Après avoir ajouté le libellé à un noeud, ce dernier est exclu de la liste des serveurs back-end quelle que soit la valeur du libellé. Par exemple, même si vous spécifiez node.kubernetes.io/exclude-from-external-load-balancers label=false, le noeud de processus actif est toujours exclu de la liste des serveurs back-end.

Pour enlever le libellé du noeud, entrez la commande ci-dessous :

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

Pour exclure tous les noeuds d'un pool de noeuds de la liste des serveurs back-end, ajoutez node.kubernetes.io/exclude-from-external-load-balancers=true à la propriété Libellés Kubernetes du pool de noeuds lorsque vous créez ou modifiez le pool de noeuds.

Le libellé node.kubernetes.io/exclude-from-external-load-balancers n'est pas pris en charge avec les noeuds virtuels.