Configurer l'utilisation intensive des pods dans GKE

Autopilot Standard

Vous trouverez sur cette page la procédure à suivre pour configurer les pods pour qu'ils utilisent en utilisation intensive la capacité inutilisée sur les nœuds Google Kubernetes Engine (GKE).

Qu'est-ce que l'utilisation intensive ?

L'utilisation intensive décrit l'action des pods qui utilisent temporairement plus de capacité de calcul sur le nœud qu'ils ne l'avaient demandé.

Kubernetes vous permet de demander des capacités spécifiques de ressources telles que le processeur ou la mémoire pour vos pods. Vous définissez ces requêtes dans le fichier manifeste de votre pod. Le programmeur Kubernetes place vos pods sur des nœuds disposant d'une capacité suffisante pour traiter ces demandes de ressources.

Certaines charges de travail n'utilisent pas 100% des ressources demandées pendant l'intégralité de leur durée d'exécution. Par exemple, une charge de travail qui consomme des ressources processeur supplémentaires pendant sa période de démarrage peut ne pas nécessiter la même quantité de ressources pour des opérations normales. Dans ces situations, vous pouvez définir les limites de ressources de votre charge de travail sur une valeur plus élevée que les demandes de ressources ou laisser les limites non définies. GKE permet à la charge de travail d'utiliser temporairement plus de ressources que celles spécifiées dans les requêtes, sous réserve de disponibilité.

Pour en savoir plus sur le fonctionnement de ce processus dans GKE, consultez la page Fonctionnement de l'utilisation intensive du présent document.

Avantages de l'utilisation intensive des pods

L'utilisation intensive est utile lorsque vos pods n'ont besoin de ressources supplémentaires que pendant de courtes périodes, afin de faire face aux pics d'utilisation des ressources. Voici quelques exemples de scénarios:

Vous avez des groupes de charges de travail qui sont souvent inactifs et envoient un petit nombre de requêtes par seconde, mais qui connaissent parfois des pics de trafic et qui ont besoin de ressources supplémentaires pour traiter ces requêtes.
Vos charges de travail nécessitent plus de ressources au démarrage que lors d'opérations normales.
Vous souhaitez optimiser l'utilisation de la capacité de calcul que vous provisionnez.

L'utilisation intensive vous permet de ne demander que les ressources dont votre pod a besoin pour la majorité de son environnement d'exécution, tout en vous assurant qu'il peut consommer davantage de ressources si nécessaire. L'utilisation intensive présente les avantages suivants:

Réduction des coûts d'exploitation: vous n'avez pas besoin de demander le pic de consommation de ressources attendu de la charge de travail. Vos requêtes peuvent être pour les valeurs à état stable inférieures. Dans Autopilot, vous payez pour la somme de vos demandes de ressources de pod, ce qui réduit vos coûts d'exploitation.
Utilisation plus efficace des ressources: vous évitez la capacité de calcul inutilisée, car vos pods utilisent la capacité inutilisée. Vos charges de travail sont plus susceptibles d'utiliser toutes vos ressources payantes.
Amélioration des performances: les pods peuvent utiliser des ressources supplémentaires si nécessaire pour réduire le temps de traitement des requêtes entrantes ou pour démarrer plus rapidement lors d'événements de scaling à la hausse.

Cas pour lesquels l'utilisation intensive n'est pas recommandée

Kubernetes attribue la classe de qualité de service (QoS) Burstable aux pods qui spécifient des limites de ressources plus élevées que leurs requêtes. Les pods QoS Burstable sont plus susceptibles d'être évincés lorsque Kubernetes doit récupérer des ressources sur le nœud. Pour en savoir plus, consultez la section Classe QoS intensive dans la documentation de Kubernetes.

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 Autopilot exécutant la version 1.29.2-gke.1060000 ou ultérieure, ou toute version d'un cluster GKE standard. Pour créer un cluster, consultez la page Créer un cluster Autopilot.

Disponibilité intensive dans GKE

Les charges de travail peuvent passer en utilisation intensive dans les situations suivantes:

Disponibilité d'utilisation intensive
Mode GKE Autopilot	Les pods qui utilisent la classe de calcul Performance ou la classe de calcul d'accélérateur peuvent passer en utilisation intensive dans n'importe quelle version de GKE compatible avec cette classe de calcul. Dans toute autre classe de calcul et pour les pods qui ne spécifient pas de classe de calcul, l'utilisation intensive n'est disponible que si le cluster remplit les deux conditions suivantes: Vous avez créé le cluster avec la version 1.26 ou une version ultérieure de GKE. Le cluster exécute GKE version 1.29.2-gke.1060000 ou ultérieure. Cette restriction existe, car l'utilisation intensive nécessite cgroup v2 dans les clusters Autopilot. cgroup v2 n'est disponible que dans les clusters créés initialement avec la version 1.26.
Mode GKE Standard	Les pods peuvent passer en utilisation intensive dans n'importe quelle version de GKE.

Disponibilité d'utilisation intensive

Mode GKE Autopilot

Les pods qui utilisent la classe de calcul Performance ou la classe de calcul d'accélérateur peuvent passer en utilisation intensive dans n'importe quelle version de GKE compatible avec cette classe de calcul.

Dans toute autre classe de calcul et pour les pods qui ne spécifient pas de classe de calcul, l'utilisation intensive n'est disponible que si le cluster remplit les deux conditions suivantes:

Vous avez créé le cluster avec la version 1.26 ou une version ultérieure de GKE.
Le cluster exécute GKE version 1.29.2-gke.1060000 ou ultérieure.

Cette restriction existe, car l'utilisation intensive nécessite cgroup v2 dans les clusters Autopilot. cgroup v2 n'est disponible que dans les clusters créés initialement avec la version 1.26.

Mode GKE Standard

Les pods peuvent passer en utilisation intensive dans n'importe quelle version de GKE.

Les clusters Autopilot qui ont été créés à l'origine avec une version antérieure à la version 1.26 et qui ont été mis à niveau par la suite vers la version 1.29.2-gke.1060000 et ultérieure ne sont pas compatibles avec l'utilisation intensive. Pour vérifier la version d'origine du cluster, exécutez la commande suivante:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="value(initialClusterVersion)"

La sortie doit être la version 1.26 de GKE ou une version ultérieure.

Limites

Les charges de travail Autopilot ne peuvent utiliser l'utilisation intensive que pour les demandes de ressources mémoire et de processeur.
Les plans de contrôle et les nœuds Autopilot doivent utiliser une version de GKE compatible. Si vous avez récemment mis à niveau vos clusters vers une version compatible, assurez-vous que vos nœuds exécutent cette version avant d'utiliser l'utilisation intensive.

Se connecter au cluster

Exécutez la commande ci-dessous.

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

Remplacez les éléments suivants :

CLUSTER_NAME : nom de votre cluster existant.
LOCATION : emplacement de votre cluster.

Déployer une charge de travail extensible

Enregistrez le manifeste suivant sous le nom burstable-deployment.yaml :
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloweb
  labels:
    app: hello
spec:
  selector:
    matchLabels:
      app: hello
      tier: web
  template:
    metadata:
      labels:
        app: hello
        tier: web
    spec:
      nodeSelector:
        pod-type: "non-critical"
      tolerations:
      - key: pod-type
        operator: Equal
        value: "non-critical"
        effect: NoSchedule
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 350m
```
Ce fichier manifeste comporte les champs suivants pour permettre l'utilisation intensive:
- resources.requests: ressources nécessaires au fonctionnement du conteneur. Définissez cette valeur sur la capacité dont votre conteneur aura besoin à l'état stable.
- resources.limits: capacité maximale de ressources que le conteneur peut utiliser. Si vous définissez des limites supérieures aux requêtes, les pods peuvent passer en utilisation intensive jusqu'à la limite spécifiée si cette capacité est disponible sur le nœud. Si vous omettez ce champ, les pods peuvent utiliser la capacité extensible disponible sur le nœud. Cette capacité est calculée comme suit :
  - Mode Autopilot: capacité inutilisée dans la somme des demandes de ressources des pods du nœud.
  - Mode standard: capacité inutilisée dans les ressources de nœud.
- spec.nodeSelector et spec.tolerations : facultatifs. Indique à GKE de créer des nœuds pour exécuter les pods extensibles. GKE applique des rejets à ces nouveaux nœuds pour empêcher d'autres pods, tels que des charges de travail critiques, de s'exécuter sur les mêmes nœuds. Pour en savoir plus, consultez la page Configurer la séparation des charges de travail dans GKE.
Déployer la charge de travail :
```
kubectl apply -f burstable-deployment.yaml
```
Le démarrage de la charge de travail peut prendre quelques minutes.

Vérifiez la classe QoS d'un pod:

kubectl describe pod helloweb | grep -m 1 "QoS"

Le résultat est le suivant :

QoS Class: Burstable

Capacité extensible dans GKE

Pour faciliter l'utilisation intensive des pods, GKE calcule la capacité intensive pour chaque nœud d'un cluster. Ce calcul pour un nœud spécifique est le suivant:

Clusters Autopilot: somme des demandes de ressources de tous les pods sur ce nœud, quelle que soit la capacité réelle des ressources du nœud. Si un pod est arrêté, la capacité extensible est réduite par le nombre de requêtes de ce pod. La partie de la capacité extensible qui n'est pas utilisée par les pods en cours d'exécution est disponible à allouer si l'un des pods doit passer en utilisation intensive.

Autopilot ajoute également un tampon prédéfini à la capacité extensible de sorte que les pods système du nœud qui passent à une utilisation intensive au-delà de leurs requêtes n'affectent pas vos propres pods extensibles.
Clusters standards: capacité totale des ressources disponible sur la VM de nœud.

Bonnes pratiques en matière d'utilisation intensive

Appliquez les pratiques suivantes avec l'utilisation intensive des pods:

Définissez vos demandes de ressources sur des valeurs égales à vos limites pour tous les pods fournissant des fonctionnalités critiques dans votre environnement. Cela garantit que ces pods obtiennent la classe de qualité de service (QoS) Kubernetes Guaranteed.
Veillez à ne configurer l'utilisation intensive de mémoire que sur les pods pouvant gérer l'éviction lorsque Kubernetes doit récupérer de la mémoire sur le nœud.
Demandez toujours suffisamment de mémoire pour que votre pod démarre. Ne comptez pas sur l'utilisation intensive de la mémoire pour répondre à vos exigences de démarrage.
Pour éviter que les pods extensibles qui utilisent systématiquement en utilisation intensive plusieurs de leurs requêtes de processeur ne perturbent potentiellement les charges de travail critiques, utilisez la séparation des charges de travail afin d'éviter de placer ces pods avec vos pods critiques.

Optimiser la capacité extensible dans les nœuds Autopilot

Autopilot calcule la capacité extensible comme la somme des demandes de ressources de tous les pods d'un nœud spécifique, y compris les pods système et les DaemonSets. Vous pouvez optimiser la capacité extensible sur un nœud de différentes manières. Cependant, l'utilisation intensive est opportuniste et n'est pas garantie.

Pour augmenter la capacité extensible sur les nœuds pour des charges de travail spécifiques, utilisez l'affinité de pods pour placer des pods spécifiques ensemble sur le même nœud.
Pour vous assurer qu'une capacité extensible spécifique est toujours disponible sur chaque nœud, créez des objets DaemonSets à exécuter sur tous les nœuds du cluster.

Exemple de fonctionnement de l'utilisation intensive

Cette section utilise un exemple de déploiement comportant les pods extensibles suivants pour illustrer le fonctionnement de l'utilisation intensive des pods dans les clusters GKE Autopilot:

Le pod 1 demande un processeur 250 m et n'a pas de limite de processeur. Le pod 1 utilise un processeur 100 m pour s'exécuter.
Le pod 2 demande un processeur 200 m et a une limite de 250 m. Le pod 2 utilise un processeur 100 m pour s'exécuter.

Les deux pods s'exécutent sur le même nœud. La capacité totale disponible sur le nœud est de 450 mCPU (somme des demandes de ressources). Chaque pod n'utilise que des processeurs 100 m pour s'exécuter, ce qui signifie que le nœud dispose d'une capacité extensible disponible de 250 m.

Voici quelques exemples de scénarios dans lesquels un pic de trafic se produit:

Le pod 1 nécessite un processeur supplémentaire 300 m: il peut passer en utilisation intensive et utiliser un processeur 250 m, ce qui est la capacité intensive disponible. Le nœud ne dispose plus d'une capacité extensible.
Le pod 2 nécessite un processeur supplémentaire 150 m: il peut passer en utilisation intensive et utiliser un processeur 150 m en plus. Le nœud dispose alors de 100 m de processeur à utilisation intensive.
Le pod 2 nécessite un processeur supplémentaire 200 m: il peut passer en utilisation intensive et utiliser un processeur 150 m, ce qui porte l'utilisation totale du processeur à 250 m pour le pod 2. Le pod 2 a une limite de processeur de 250 m et ne peut pas passer en utilisation intensive au-delà de cette limite.

Gestion des pods qui dépassent la capacité extensible par GKE

Si vos pods extensibles tentent d'utiliser plus de ressources que la capacité extensible du nœud, GKE effectue les actions suivantes:

Processeur: si l'utilisation du processeur dépasse la capacité extensible, GKE limite l'utilisation du processeur de certains conteneurs afin que tous les conteneurs du nœud obtiennent le processeur demandé.
Mémoire: si l'utilisation de la mémoire dépasse la capacité extensible, GKE arrête les conteneurs pour récupérer de la mémoire sur le nœud. GKE commence par arrêter les conteneurs gourmands en ressources dans les pods dont la qualité de service est plus faible.

Nous vous recommandons de toujours demander suffisamment de mémoire pour un fonctionnement normal du pod. Si un conteneur est dépendant d'une utilisation intensive de la mémoire pour fonctionner normalement, il peut planter de manière répétée si cette mémoire n'est pas disponible.

Utiliser l'utilisation intensive des pods avec le provisionnement de capacité de secours

GKE vous permet de déployer des pods inactifs afin de réserver une capacité de calcul supplémentaire afin d'accélérer le scaling des pods lors d'événements à fort trafic tels que les ventes flash de magasin en ligne. D'autres pods du même nœud peuvent passer en utilisation intensive sur cette capacité réservée inutilisée afin que la capacité ne soit pas inactive pendant le temps précédant votre événement de trafic élevé. Vous pouvez réserver cette capacité à l'aide de divers mécanismes Kubernetes. Par exemple, vous pouvez déployer des pods ayant une PriorityClass faible. Pour en savoir plus, consultez la page Provisionner une capacité de calcul supplémentaire pour le scaling rapide de pods.

Utilisation intensive des pods dans les clusters GKE Standard

Les clusters GKE Standard sont également compatibles avec l'utilisation intensive des pods en définissant des limites supérieures aux requêtes ou en omettant les limites. Toutefois, dans les clusters standards, vous devez créer et configurer des pools de nœuds avec une capacité de ressources appropriée pour permettre l'utilisation intensive. La réduction potentielle du coût des pods extensibles dans les clusters Standard nécessite une planification plus minutieuse des nœuds et le bin-packing des pods, car vous payez pour les VM Compute Engine sous-jacentes.

Tenez compte des points suivants dans les clusters standards:

La limite maximale de consommation de ressources qui déclenche l'éviction de Kubernetes ou la limitation du processeur est la capacité de ressources pouvant être allouée sur le nœud. Pour déterminer cette valeur, consultez la section Planifier les tailles de nœud GKE Standard.
L'utilisation des ressources de nœuds dans les clusters standards est plus susceptible d'atteindre un seuil d'éviction Kubernetes, car GKE ne limite pas automatiquement la consommation des ressources si vous ne spécifiez pas de limites. Les pods qui basculent en mémoire sont donc plus susceptibles d'être arrêtés par l'éviction par pression des nœuds de Kubernetes.