Sélecteurs de nœuds et affinité
Contrôlez où les Pods sont planifiés à l’aide de sélecteurs de nœuds et de règles d’affinité plus expressives entre nœuds et Pods.
Sélecteurs de nœuds et affinité est une leçon Kubernetes Basics gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Kubernetes Basics, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Kubernetes Basics comprend 4 leçons au total.
Contrôler l'emplacement des Pods
Par défaut, Kubernetes planifie les Pods sur n'importe quel nœud disponible. Mais que faire si vous avez besoin de davantage de contrôle ?
Il est parfois nécessaire d'exécuter des Pods sur des nœuds précis. Ces nœuds peuvent disposer d'un matériel particulier, de licences spécifiques ou se trouver dans certaines zones de disponibilité.
Cette leçon explique comment orienter le planificateur de Kubernetes à l'aide des sélecteurs de nœuds et de l'affinité aux nœuds.
Pourquoi orienter le planificateur ?
Imaginez que vous ayez un Pod de base de données qui doit s'exécuter sur un nœud équipé de SSD très performants, ou une application utilisant intensivement le GPU et nécessitant un matériel précis.
Vous pouvez également vouloir éloigner certains Pods les uns des autres pour assurer la tolérance aux pannes, ou vous assurer qu'ils s'exécutent sur des nœuds dotés de systèmes d'exploitation précis.
Kubernetes fournit des outils permettant d'exprimer ces préférences de planification.
Les nœuds possèdent des étiquettes
Avant d'indiquer aux Pods où aller, les nœuds doivent être identifiés ! Kubernetes utilise des étiquettes pour identifier les nœuds selon leurs caractéristiques.
- Les étiquettes sont des paires clé-valeur, comme
disk=ssdougpu=true. - Vous pouvez ajouter des étiquettes personnalisées à vos nœuds avec
kubectl label nodes <node-name> <key>=<value>. - Ces étiquettes permettent de cibler des nœuds précis pour le placement des Pods.
Sélecteurs de nœuds : correspondance simple
Le moyen le plus simple de limiter un Pod à un ensemble précis de nœuds consiste à utiliser nodeSelector.
Il s'agit d'un champ de la spécification de votre Pod qui accepte une table de paires clé-valeur. Le Pod ne sera planifié que sur les nœuds possédant toutes ces étiquettes.
C'est comme dire : « J'ai besoin d'un nœud qui soit exactement comme celui-ci. »
Le sélecteur de nœud en action
Supposons que nous ayons des nœuds portant l'étiquette disk=ssd. Voici comment faire exécuter un Pod uniquement sur ces nœuds :
apiVersion: v1
kind: Pod
metadata:
name: ssd-app
spec:
containers:
- name: my-container
image: nginx
nodeSelector:
disk: ssdAffinité aux nœuds : correspondance avancée
Bien que nodeSelector soit simple, il est très strict. Que faire si vous souhaitez des nœuds « préférés » ou des règles de correspondance plus complexes ?
L'affinité aux nœuds offre davantage de souplesse. Elle permet d'exprimer des exigences « souples » ou « strictes » pour placer les Pods sur des nœuds portant des étiquettes précises.
Elle utilise une syntaxe plus puissante avec des opérateurs comme In, NotIn, Exists, DoesNotExist, Gt et Lt.
Affinité requise et préférée
L'affinité aux nœuds possède deux types principaux :
requiredDuringSchedulingIgnoredDuringExecution: le Pod doit être planifié sur un nœud correspondant aux règles. Si aucun nœud de ce type n'existe, le Pod ne sera pas planifié.preferredDuringSchedulingIgnoredDuringExecution: le planificateur essaie de trouver un nœud correspondant aux règles, mais s'il n'y en a aucun de disponible, il planifie tout de même le Pod ailleurs. Il s'agit d'une approche « au mieux ».
Affinité de nœud requise
Voici un Pod qui exige un nœud portant l'étiquette env=production. Si aucun nœud de ce type n'existe, le Pod restera en attente.
apiVersion: v1
kind: Pod
metadata:
name: prod-app
spec:
containers:
- name: my-container
image: httpd
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: env
operator: In
values:
- productionAffinité des Pods : les autres Pods comptent
Que faire si vous souhaitez planifier les Pods en fonction de l'emplacement d'autres Pods ?
- Affinité des Pods : attire les Pods vers les nœuds où s'exécutent déjà d'autres Pods portant certaines étiquettes. C'est utile pour regrouper des services qui communiquent fréquemment.
- Anti-affinité des Pods : éloigne les Pods des nœuds où s'exécutent d'autres Pods portant certaines étiquettes. C'est idéal pour répartir les réplicas entre les nœuds afin d'assurer une haute disponibilité.
L'anti-affinité des Pods en pratique
Ce manifeste garantit qu'aucun couple de Pods portant l'étiquette app=my-web ne pourra être planifié sur le même nœud. Cela améliore la tolérance aux pannes.
topologyKey indique le domaine auquel s'applique l'anti-affinité (par exemple, un nœud ou une zone).
apiVersion: v1
kind: Pod
metadata:
name: web-app-pod
labels:
app: my-web
spec:
containers:
- name: web-container
image: busybox
command: ["sh", "-c", "echo 'Hello from web-app'; sleep 3600"]
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: my-web
topologyKey: "kubernetes.io/hostname"Testez vos connaissances
Vous voulez vous assurer que vos Pods de base de données critiques ne doivent pas être planifiés sur des nœuds portant l'étiquette zone=dev. Quel type de règle de planification utiliseriez-vous pour cette exclusion stricte fondée sur les étiquettes des nœuds ?
Récapitulatif : contrôle de la planification
Excellent travail ! Vous avez appris à contrôler précisément l'emplacement d'exécution de vos Pods :
- Étiquettes de nœuds : paires clé-valeur identifiant les caractéristiques des nœuds.
- Sélecteurs de nœuds : correspondance simple et stricte pour planifier les Pods sur des nœuds portant certaines étiquettes.
- Affinité aux nœuds : règles plus souples (requises ou préférées) pour sélectionner les nœuds, à l'aide d'opérateurs.
- Affinité et anti-affinité des Pods : regroupement ou séparation des Pods selon l'emplacement d'autres Pods.
Ces outils sont essentiels pour optimiser l'utilisation des ressources, garantir la tolérance aux pannes et répondre aux besoins spécifiques des applications.
Questions Fréquemment Posées
La leçon « Sélecteurs de nœuds et affinité » est-elle gratuite ?
Oui — le texte complet de « Sélecteurs de nœuds et affinité » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Kubernetes Basics, passe à CoddyKit PRO. Le cours Kubernetes Basics comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Sélecteurs de nœuds et affinité » ?
Contrôlez où les Pods sont planifiés à l’aide de sélecteurs de nœuds et de règles d’affinité plus expressives entre nœuds et Pods. Tu pratiques Kubernetes Basics avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Kubernetes Basics ?
Aucune expérience préalable n'est requise. Kubernetes Basics sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.
Combien de temps prend la leçon « Sélecteurs de nœuds et affinité » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Kubernetes Basics ?
Oui. Chaque leçon Kubernetes Basics inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Demandes et limites de ressources
- Sélecteurs de nœuds et affinité
- Taints et tolérances
- Priorité et préemption des Pods