Configurer la séparation des charges de travail dans GKE

Autopilot Standard

---

Cette page explique comment indiquer à Google Kubernetes Engine (GKE) de planifier vos pods ensemble, séparément ou à des emplacements spécifiques.

La séparation des charges de travail vous permet d'utiliser des rejets et tolérances pour indiquer à GKE de séparer les pods sur différents nœuds ou de placer des pods sur des nœuds répondant à des critères spécifiques, ou pour planifier des charges de travail spécifiques ensemble. La procédure à suivre pour configurer la séparation des charges de travail dépend de la configuration de votre cluster GKE. Le tableau suivant décrit les différences de procédure :

Configuration de la séparation des charges de travail
Autopilot Standard avec provisionnement automatique des nœuds	Ajoutez une tolérance pour une paire clé/valeur spécifique à votre spécification de pod, puis sélectionnez cette paire clé-valeur à l'aide d'un sélecteur de nœuds. GKE crée des nœuds, applique le rejet de nœud correspondant et planifie le pod sur le nœud. Pour obtenir des instructions, reportez-vous à la section Séparer les charges de travail des clusters Autopilot.
Standard sans provisionnement automatique des nœuds	Créez un pool de nœuds avec un rejet de nœud et un libellé de nœud. Ajoutez une tolérance pour ce rejet à la spécification de pod. Pour obtenir des instructions, reportez-vous à la page Isoler des charges de travail dans des pools de nœuds dédiés. Attention : Avec cette méthode, si les nœuds de rejets existants ne disposent pas de suffisamment de ressources pour accepter un pod avec une tolérance, le pod reste à l'état "En attente".

Ce guide utilise un exemple dans lequel vous avez deux charges de travail, un job par lot et un serveur Web, que vous souhaitez séparer.

Quand utiliser la séparation des charges de travail dans GKE ?

La séparation des charges de travail est utile lorsque des charges de travail effectuent des rôles différents et ne doivent pas s'exécuter sur les mêmes machines sous-jacentes. Voici quelques exemples de scénarios :

• Vous avez une charge de travail de coordinateur par lot qui crée des jobs que vous souhaitez séparer.
• Vous exécutez un serveur de jeu avec une charge de travail de mise en correspondance que vous souhaitez séparer des pods de session.
• Vous souhaitez séparer les différentes parties de la pile, par exemple pour séparer un serveur d'une base de données.
• Vous souhaitez séparer certaines charges de travail pour des raisons de conformité ou de stratégie.

Avertissement : La séparation des charges de travail ne doit jamais être utilisée comme limite de sécurité principale. Ce n'est pas une méthode permettant d'isoler les charges de travail non approuvées, et elle ne permet pas d'atténuer tous les chemins d'élévation. La séparation des charges de travail n'est pas conçue pour servir de mécanisme de défense. Pour en savoir plus sur les risques liés à l'utilisation de la planification Kubernetes en tant que méthode d'isolation, consultez la section Éviter les attaques par élévation de privilèges.

Tarifs

Dans les clusters Autopilot, les ressources demandées par vos pods pendant l'exécution vous sont facturées. Pour en savoir plus, consultez la page Tarifs du mode Autopilot. Les pods qui utilisent la séparation des charges de travail ont un nombre minimal de requêtes de ressources plus élevé que les pods standards.

Dans les clusters standards, vous êtes facturé en fonction de la configuration matérielle et de la taille de chaque nœud, que des pods soient exécutés ou non sur les nœuds. Pour plus de détails, consultez la page Tarifs du mode Standard.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

• Activez l'API Google Kubernetes Engine.
Activer l'API Google Kubernetes Engine
• Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez gcloud CLI. Si vous avez déjà installé gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
  Remarque : Pour les installations de gcloud CLI existantes, veillez à définir les propriétés compute/region et compute/zone. En définissant des emplacements par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location.

• Assurez-vous de disposer d'un cluster GKE. Pour apprendre à créer un cluster, utilisez l'une des méthodes suivantes :

  • Créer un cluster Autopilot (recommandé)
  • Créer un cluster Standard avec provisionnement automatique des nœuds
  • Créer un cluster standard

Séparer les charges de travail dans les clusters Autopilot

Pour séparer les charges de travail les unes des autres, ajoutez une tolérance et un sélecteur de nœud à chaque spécification de charge de travail qui définit le nœud sur lequel la charge de travail doit être exécutée. Cette méthode fonctionne également sur les clusters Standard pour lesquels le provisionnement automatique des nœuds est activé.

1. Enregistrez le manifeste suivant sous le nom web-server.yaml :

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: web-server
   spec:
     replicas: 6
     selector:
       matchLabels:
         pod: nginx-pod
     template:
       metadata:
         labels:
           pod: nginx-pod
       spec:
         tolerations:
         - key: group
           operator: Equal
           value: "servers"
           effect: NoSchedule
         nodeSelector:
           group: "servers"
         containers:
         - name: web-server
           image: nginx
   

   Ce fichier manifeste comprend les champs suivants :

   • spec.tolerations : GKE peut placer les pods sur des nœuds avec le rejet group=servers:NoSchedule. GKE ne peut pas planifier de pods qui ne présentent pas cette tolérance sur ces nœuds.
   • spec.nodeSelector : GKE doit placer les pods sur des nœuds portant le libellé de nœud group: servers.

   GKE ajoute les libellés et les rejets correspondants aux nœuds que GKE provisionne automatiquement pour exécuter ces pods.

2. Enregistrez le manifeste suivant sous le nom batch-job.yaml :

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: batch-job
   spec:
     completions: 5
     backoffLimit: 3
     ttlSecondsAfterFinished: 120
     template:
       metadata:
         labels:
           pod: pi-pod
       spec:
         restartPolicy: Never
         tolerations:
         - key: group
           operator: Equal
           value: "jobs"
           effect: NoSchedule
         nodeSelector:
           group: "jobs"
         containers:
         - name: pi
           image: perl
           command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
   

   Ce fichier manifeste comprend les champs suivants :

   • spec.tolerations : GKE peut placer les pods sur des nœuds avec le rejet group=jobs:NoSchedule. GKE ne peut pas planifier de pods qui ne présentent pas cette tolérance sur ces nœuds.
   • spec.nodeSelector : GKE doit placer les pods sur des nœuds portant le libellé de nœud group: jobs.

   GKE ajoute les libellés et les rejets correspondants aux nœuds que GKE provisionne automatiquement pour exécuter ces pods.

3. Déployez les charges de travail :

   kubectl apply -f batch-job.yaml web-server.yaml
   

Lorsque vous déployez les charges de travail, GKE effectue les opérations suivantes pour chaque charge de travail :

1. GKE recherche les nœuds existants qui possèdent le rejet de nœud et le libellé de nœud correspondants spécifiés dans le fichier manifeste. Si des nœuds existent et disposent de ressources disponibles, GKE planifie la charge de travail sur le nœud.
2. Si GKE ne trouve pas de nœud existant éligible pour planifier la charge de travail, il crée un nœud et applique le rejet et le libellé de nœud correspondants en fonction du fichier manifeste. GKE place le pod sur le nouveau nœud.

La présence de l'effet NoSchedule dans le rejet de nœud garantit que les charges de travail sans tolérance ne sont pas placées sur le nœud.

Vérifier la séparation des charges de travail

Répertoriez vos pods pour rechercher les noms des nœuds :

kubectl get pods --output=wide

Le résultat ressemble à ce qui suit :

NAME                          READY   ...   NODE
batch-job-28j9h               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-78rcn               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-gg4x2               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-qgsxh               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
batch-job-v4ksf               0/1     ...   gk3-sandbox-autopilot-nap-1hzelof0-ed737889-2m59
web-server-6bb8cd79b5-dw4ds   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm
web-server-6bb8cd79b5-g5ld6   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-jcdx5   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-9f447e18-275z
web-server-6bb8cd79b5-pxdzw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-s66rw   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-ccd22fd9-qtfq
web-server-6bb8cd79b5-zq8hh   1/1     ...   gk3-sandbox-autopilot-nap-1eurxgsq-f2f3c272-n6xm

Cette sortie montre que les pods batch-job et web-server s'exécutent toujours sur des nœuds différents.

Limites de la séparation des charges de travail avec des rejets et des tolérances

Vous ne pouvez pas utiliser les préfixes de clé suivants pour la séparation des charges de travail :

• Clés spécifiques à GKE et Kubernetes
• *cloud.google.com/
• *kubelet.kubernetes.io/
• *node.kubernetes.io/

Vous devez utiliser vos propres clés uniques pour la séparation des charges de travail.

Séparer les charges de travail des clusters Standard sans provisionnement automatique des nœuds

La séparation des charges de travail dans des clusters Standard sans provisionnement automatique des nœuds nécessite de créer manuellement des pools de nœuds avec les rejets de nœuds et les libellés de nœuds appropriés pour répondre à vos charges de travail. Pour obtenir des instructions, reportez-vous à la page Isoler des charges de travail dans des pools de nœuds dédiés. N'utilisez cette approche que si vous avez des exigences spécifiques vous obligeant à gérer manuellement vos pools de nœuds.

Étapes suivantes

• Appliquez des règles de sécurité prédéfinies à l'aide du contrôleur d'admission PodSecurity.
• Exécutez une charge de travail full stack à grande échelle.