Cette page a été traduite par l'API Cloud Translation.

Placer les pods GKE dans des zones spécifiques

Autopilot Standard

Cette page explique comment indiquer à Google Kubernetes Engine (GKE) d'exécuter vos pods sur des nœuds situés dans des zones Google Cloud spécifiques à l'aide de la topologie zonale. Ce type d'emplacement est utile dans les situations suivantes :

Les pods doivent accéder aux données stockées sur un disque persistant Compute Engine zonal.
Les pods doivent s'exécuter avec d'autres ressources zonales telles que des instances Cloud SQL.

Vous pouvez également utiliser un emplacement zonal avec un routage du trafic basé sur la topologie pour réduire la latence entre les clients et les charges de travail. Pour plus d'informations sur le routage du trafic basé sur la topologie, consultez la page Routage basé sur la topologie.

L'utilisation de la topologie zonale pour contrôler l'emplacement des pods est un mécanisme Kubernetes avancé que vous ne devez utiliser que si votre situation nécessite l'exécution de pods dans des zones spécifiques. Dans la plupart des environnements de production, nous vous recommandons d'utiliser des ressources régionales, qui sont les valeurs par défaut de GKE, lorsque cela est possible.

Méthodes de placement zonal

La topologie zonale est intégrée à Kubernetes avec le libellé de nœud topology.kubernetes.io/zone: ZONE. Pour indiquer à GKE de placer un pod dans une zone spécifique, utilisez l'une des méthodes suivantes :

nodeAffinity : spécifiez une règle nodeAffinity dans la spécification de pod pour une ou plusieurs zones Google Cloud . Cette méthode est plus flexible qu'un nodeSelector, car elle vous permet de placer des pods dans plusieurs zones.
nodeSelector : spécifiez un nodeSelector ciblant une seule zone Google Cloud dans la spécification de pod.
Classes de calcul : configurez votre pod pour qu'il utilise une classe de calcul GKE. Cette approche vous permet de définir une liste hiérarchisée d'ensembles de zones Google Cloud . Il permet de déplacer dynamiquement la charge de travail vers l'ensemble de zones le plus approprié lorsque des nœuds sont disponibles dans ces zones. Pour en savoir plus, consultez À propos des classes de calcul personnalisées.

Remarques

Le placement de pod zonal basé sur la topologie zonale prend en compte les éléments suivants :

Le cluster doit se trouver dans la même région Google Cloud que les zones demandées.
Dans les clusters standards, vous devez utiliser le provisionnement automatique des nœuds ou créer des pools de nœuds avec des nœuds dans les zones demandées. Les clusters Autopilot gèrent automatiquement ce processus pour vous.
Les clusters standards doivent être des clusters régionaux.

Tarifs

La topologie zonale est une fonctionnalité de planification Kubernetes offerte gratuitement dans GKE.

Pour en savoir plus sur les tarifs, consultez la page Tarifs de GKE.

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 existant dans la même régionGoogle Cloud que les zones dans lesquelles vous souhaitez placer vos pods. Pour créer un cluster, consultez la page Créer un cluster Autopilot.

Placer les pods dans plusieurs zones en utilisant nodeAffinity

Kubernetes nodeAffinity fournit un mécanisme de contrôle de planification flexible qui accepte plusieurs sélecteurs de libellés et opérateurs logiques. Utilisez nodeAffinity si vous souhaitez autoriser les pods à s'exécuter dans une zone faisant partie d'un ensemble de zones (par exemple, dans us-central1-a ou dans us-central1-f).

Enregistrez le manifeste suivant sous le nom multi-zone-affinity.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-multi-zone
  template:
    metadata:
      labels:
        app: nginx-multi-zone
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: topology.kubernetes.io/zone
                operator: In
                values:
                - us-central1-a
                - us-central1-f

Ce fichier manifeste crée un déploiement avec trois instances dupliquées et place les pods dans us-central1-a ou us-central1-f en fonction de la disponibilité des nœuds.

Assurez-vous que votre cluster se trouve dans la région us-central1. Si votre cluster se trouve dans une autre région, remplacez les zones du champ de valeurs du fichier manifeste par des zones valides pour la région de votre cluster.

Créez le déploiement :
```
kubectl create -f multi-zone-affinity.yaml
```
GKE crée les pods dans des nœuds de l'une des zones spécifiées. Plusieurs pods peuvent s'exécuter sur le même nœud. Vous pouvez éventuellement utiliser l'anti-affinité de pod pour indiquer à GKE de placer chaque pod sur un nœud distinct.

Placer les pods dans une seule zone en utilisant nodeSelector

Pour placer des pods dans une seule zone, utilisez nodeSelector dans la spécification du pod. Un objet nodeSelector correspond à une règle nodeAffinity requiredDuringSchedulingIgnoredDuringExecution ne comportant qu'une seule zone.

Enregistrez le manifeste suivant sous le nom single-zone-selector.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-singlezone
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-singlezone
  template:
    metadata:
      labels:
        app: nginx-singlezone
    spec:
      nodeSelector:
        topology.kubernetes.io/zone: "us-central1-a"
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Ce fichier manifeste indique à GKE de placer toutes les instances dupliquées dans le déploiement de la zone us-central1-a.

Créez le déploiement :

kubectl create -f single-zone-selector.yaml

Prioriser le placement des pods dans des zones sélectionnées à l'aide d'une classe de calcul

Les classes de calcul GKE fournissent un mécanisme de contrôle qui vous permet de définir une liste de priorités de configuration des nœuds. Les préférences zonales vous permettent de définir les zones dans lesquelles vous souhaitez que GKE place les pods. Pour définir des préférences de zone dans les classes de calcul, vous devez utiliser la version 1.33.1-gke.1545000 de GKE ou une version ultérieure.

L'exemple suivant crée une classe de calcul qui spécifie une liste de zones préférées pour les pods.

Ces étapes supposent que votre cluster se trouve dans la région us-central1. Si votre cluster se trouve dans une autre région, remplacez les valeurs des zones dans le fichier manifeste par des zones valides pour la région de votre cluster.

Enregistrez le manifeste suivant sous le nom zones-custom-compute-class.yaml :
```
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: zones-custom-compute-class
spec:
  priorities:
  - location:
    zones: [us-central1-a, us-central1-b]
  - location:
    zones: [us-central1-c]
  activeMigration:
    optimizeRulePriority: true
  nodePoolAutoCreation:
    enabled: true
  whenUnsatisfiable: ScaleUpAnyway
```
Le fichier manifeste de cette classe de calcul modifie le comportement de scaling comme suit :
1. GKE tente de placer les pods dans us-central1-a ou dans us-central1-b.
2. Si us-central1-a et us-central1-b ne disposent pas de capacité disponible, GKE tente de placer les pods dans us-central1-c.
3. Si us-central1-c ne dispose pas de capacité disponible, le champ whenUnsatisfiable: ScaleUpAnyway permet à GKE de placer les pods dans n'importe quelle zone disponible de la région.
4. Si une zone ayant une priorité plus élevée dans la classe de calcul devient disponible ultérieurement, le champ activeMigration.optimizeRulePriority: true permet à GKE de déplacer les pods vers cette zone à partir de n'importe quelle zone de priorité inférieure. Cette migration utilise le budget d'interruption de pod pour assurer la disponibilité du service.
Créez la classe de calcul personnalisée :
```
kubectl create -f zones-custom-compute-class.yaml
```
GKE crée une classe de calcul personnalisée à laquelle vos charges de travail peuvent faire référence.

Enregistrez le manifeste suivant sous le nom custom-compute-class-deployment.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-zonal-preferences
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-zonal-preferences
  template:
    metadata:
      labels:
        app: nginx-zonal-preferences
    spec:
      nodeSelector:
        cloud.google.com/compute-class: "zones-custom-compute-class"
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Créez le déploiement :

kubectl create -f custom-compute-class-deployment.yaml

Vérifier le placement des pods

Pour vérifier le placement des pods, répertoriez les pods et vérifiez les libellés de nœuds. Plusieurs pods peuvent s'exécuter dans un même nœud. Par conséquent, vous ne verrez peut-être pas de pods répartis sur plusieurs zones si vous avez utilisé nodeAffinity.

Affichez la liste des pods :
```
kubectl get pods -o wide
```
Le résultat affiche la liste des pods en cours d'exécution et le nœud GKE correspondant.

Décrivez les nœuds :

kubectl describe node NODE_NAME | grep "topology.kubernetes.io/zone"

Remplacez NODE_NAME par le nom du nœud.

Le résultat ressemble à ce qui suit :

topology.kubernetes.io/zone: us-central1-a

Si vous souhaitez que GKE répartisse équitablement vos pods sur plusieurs zones pour améliorer le basculement sur plusieurs domaines de défaillance, utilisez topologySpreadConstraints.