Name: Tremplin Numérique
Price range: $$$

Les teintes et les tolérances sont un mécanisme Kubernetes permettant de contrôler la façon dont les pods planifient les nœuds de votre cluster. Les souillures sont appliquées aux nœuds et agissent comme une barrière répulsive contre les nouveaux pods. Les nœuds contaminés n’accepteront que les pods qui ont été marqués avec une tolérance correspondante.

Les taches sont l’un des mécanismes de planification les plus avancés de Kubernetes. Ils facilitent de nombreux cas d’utilisation différents dans lesquels vous souhaitez empêcher les pods de se retrouver sur des nœuds indésirables. Dans cet article, vous apprendrez ce que sont les rejets et les tolérances et comment vous pouvez les utiliser dans votre propre cluster.

Sommaire

Comment fonctionne la planification

Kubernetes est un système distribué dans lequel vous pouvez déployer des applications conteneurisées (pods) sur plusieurs hôtes physiques (nœuds). Lorsque vous créez un nouveau pod, Kubernetes doit déterminer l’ensemble de nœuds sur lesquels il peut être placé. C’est à cela que fait référence l’ordonnancement.

Le planificateur prend en compte de nombreux facteurs différents pour établir un emplacement approprié pour chaque pod. Il sélectionnera par défaut un nœud pouvant fournir suffisamment de ressources pour satisfaire les demandes de processeur et de mémoire du pod.

Le nœud sélectionné ne sera pas nécessairement approprié pour votre déploiement. Il peut manquer le matériel requis ou être réservé à une utilisation en développement. Les rejets de nœuds sont un mécanisme permettant d’appliquer ces contraintes en empêchant l’attribution arbitraire de pods à des nœuds.

Cas d’utilisation de la souillure

Corrompre un nœud signifie qu’il commencera à repousser les pods, forçant le planificateur à considérer le prochain nœud candidat à la place. Vous pouvez surmonter la souillure en définissant une tolérance correspondante sur le pod. Cela fournit un mécanisme permettant d’autoriser des pods spécifiques sur le nœud.

Les souillures sont souvent utilisées pour éloigner les pods des nœuds réservés à des fins spécifiques. Certains clusters Kubernetes peuvent héberger plusieurs environnements, tels que la préproduction et la production. Dans cette situation, vous souhaiterez empêcher les déploiements intermédiaires de se retrouver sur le matériel de production dédié.

Vous pouvez obtenir le comportement souhaité en tachant le nœud de production et en définissant une tolérance correspondante sur les pods de production. Les pods intermédiaires seront confinés aux autres nœuds de votre cluster, les empêchant de consommer des ressources de production.

Les teintes peuvent également aider à distinguer les nœuds avec un matériel particulier. Les opérateurs peuvent déployer un sous-ensemble de nœuds avec des GPU dédiés à utiliser avec des charges de travail d’IA. La contamination de ces nœuds garantit que les pods qui n’ont pas besoin du GPU ne peuvent pas planifier sur eux.

Effets de souillure

Chaque rejet de nœud peut avoir l’un des trois effets différents sur les décisions de planification Kubernetes :

NoSchedule – Les pods qui ne tolèrent pas la souillure ne seront pas programmés sur le nœud. Les pods déjà programmés pour le nœud ne sont pas affectés, même s’ils ne tolèrent pas la contamination.
PreferNoSchedule – Kubernetes évitera de programmer des pods sans la tolérance de la contamination. Le pod peut toujours être programmé sur le nœud en dernier recours. Cela n’affecte pas les pods existants.
NoExecute – Cela fonctionne de la même manière que NoSchedule sauf que les pods existants sont également impactés. Les pods sans tolérance seront immédiatement expulsés du nœud, ce qui les obligera à être replanifiés sur d’autres nœuds de votre cluster.

La NoExecute est utile lorsque vous modifiez le rôle d’un nœud qui exécute déjà certaines charges de travail. NoSchedule est plus approprié si vous souhaitez protéger le nœud contre la réception de nouveaux pods, sans perturber les déploiements existants.

Altérer un nœud

Les teintes sont appliquées aux nœuds à l’aide de la kubectl taint commande. Il prend le nom du nœud cible, une clé et une valeur pour la souillure, et un effet.

Voici un exemple de contamination d’un nœud pour l’allouer à un environnement spécifique :

$ kubectl taint nodes demo-node env=production:NoSchedule
node/demo-node tainted

Vous pouvez appliquer plusieurs teintes à un nœud en répétant la commande. La valeur de la clé est facultative. Vous pouvez créer des rejets binaires en l’omettant :

$ kubectl taint nodes demo-node has-gpu:NoSchedule

Pour supprimer une coloration précédemment appliquée, répétez la commande mais ajoutez un trait d’union (-) au nom de l’effet :

$ kubectl taint nodes demo-node has-gpu:NoSchedule-
node/demo-node untainted

Cela supprimera la souillure correspondante si elle existe.

Vous pouvez récupérer une liste de toutes les teintes appliquées à un nœud à l’aide de la describe commande. Les teintes seront affichées en haut de la sortie, après les étiquettes et les annotations du nœud :

$ kubectl describe node demo-node
Name:   demo-node
...
Taints: env=production:NoSchedule
...

Ajout de tolérances aux pods

L’exemple ci-dessus entaché demo-node avec l’intention de le réserver aux charges de travail de production. L’étape suivante consiste à ajouter une tolérance équivalente à vos pods de production afin qu’ils soient autorisés à planifier sur le nœud.

Les tolérances des gousses sont déclarées dans le spec.tolerations champ manifeste :

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: example.com/api:latest
  tolerations:
    - key: env
      operator: Equals
      value: production
      effect: NoSchedule

Cette tolérance permet au api Pod à programmer sur les nœuds qui ont un env souillure d’une valeur de production et NoSchedule comme effet. L’exemple de pod peut maintenant être programmé pour demo-node.

Pour tolérer les défauts sans valeur, utilisez le Exists opérateur à la place :

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: example.com/api:latest
  tolerations:
    - key: has-gpu
      operator: Exists
      effect: NoSchedule

Le Pod tolère désormais les has-gpu souillure, qu’une valeur ait été définie ou non.

Les tolérances ne exiger que le pod est programmé sur un nœud contaminé. Il s’agit d’une idée fausse commune autour des souillures et des tolérances. Le mécanisme indique seulement qu’un nœud ne peut pas héberger un pod ; il n’exprime pas le point de vue alternatif selon lequel un pod doit être placé sur un nœud particulier. Les souillures sont généralement combinées avec des affinités pour obtenir ce comportement bidirectionnel.

Règles de correspondance de teinte et de tolérance

Les nœuds contaminés ne reçoivent que des pods qui tolèrent toutes leurs contaminations. Kubernetes découvre d’abord les défauts sur le nœud, puis filtre les défauts tolérés par le pod. Les effets demandés par l’ensemble restant de souillures seront appliqués au Pod.

Il y a un cas particulier pour le NoExecute effet. Les pods qui tolèrent ce type de souillure resteront généralement sur le nœud après l’application de la souillure. Vous pouvez modifier ce comportement afin que les pods soient volontairement évincés après un certain temps, malgré la tolérance du trait :

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: example.com/api:latest
  tolerations:
    - key: env
      operator: Equals
      value: production
      effect: NoExecute
      tolerationSeconds: 900

Un nœud qui héberge ce pod mais qui est ensuite entaché de env=production:NoExecute permettra au Pod de rester présent jusqu’à 15 minutes après l’application de la souillure. Le Pod sera alors expulsé malgré le fait d’avoir le NoExecute tolérance.

Teintes automatiques

Les nœuds sont automatiquement contaminés par le plan de contrôle Kubernetes pour expulser les pods et empêcher la planification en cas de conflit de ressources. Des souillures telles que node.kubernetes.io/memory-pressure et node.kubernetes.io/disk-pressure Cela signifie que Kubernetes empêche le nœud de prendre de nouveaux pods car il manque de ressources suffisantes.

D’autres souillures couramment appliquées comprennent node.kubernetes.io/not-readylorsqu’un nouveau nœud n’accepte pas les pods, et node.kubernetes.io/unschedulable. Ce dernier est appliqué aux nœuds bouclés pour arrêter toute activité de planification de pod.

Ces rejets implémentent les systèmes d’éviction et de gestion des nœuds de Kubernetes. Vous n’avez normalement pas besoin d’y penser et vous ne devriez pas gérer ces souillures manuellement. Si vous les voyez sur un nœud, c’est parce que Kubernetes les a appliqués en réponse à des conditions changeantes ou à une autre commande que vous avez émise. Il est possible de créer des tolérances de pod pour ces rejets, mais cela pourrait entraîner un épuisement des ressources et un comportement inattendu.

Sommaire

Les teintes et les tolérances sont un mécanisme permettant d’éloigner les pods des nœuds Kubernetes individuels. Ils vous aident à éviter les résultats de planification indésirables en empêchant l’attribution automatique des pods à des nœuds arbitraires.

La souillure n’est pas le seul mécanisme qui permet de contrôler le comportement de planification. Les affinités et anti-affinités de pod sont une technique connexe pour contraindre les nœuds pouvant recevoir un pod. L’affinité peut également être définie au niveau inter-pod, ce qui vous permet de prendre des décisions de planification en fonction des pods déjà exécutés sur un nœud. Vous pouvez combiner l’affinité avec les rejets et les tolérances pour configurer des règles de planification avancées.