Configurer l'utilisation intensive des pods dans GKE

Cette page explique comment configurer des pods pour une utilisation intensive de la capacité inutilisée disponible 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 que ce qu'ils avaient initialement 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 planificateur Kubernetes place vos pods sur des nœuds disposant d'une capacité suffisante pour répondre à ces demandes de ressources.

Certaines charges de travail n'utilisent pas 100 % des ressources demandées pendant toute la durée de leur exécution. Par exemple, une charge de travail qui consomme des ressources de processeur supplémentaires pendant sa période de démarrage peut ne pas nécessiter la même quantité de ressources pour les opérations normales. Dans ces situations, vous pouvez définir les limites de ressources pour votre charge de travail sur une valeur supérieure aux demandes de ressources ou ne pas définir de limites. GKE permet à la charge de travail d'utiliser temporairement plus de ressources que celles que vous avez spécifiées dans les requêtes, si cette capacité est disponible.

Pour en savoir plus sur le fonctionnement de ce processus dans GKE, consultez la section Capacité burstable dans GKE sur cette page.

Avantages de l'utilisation intensive de pod

L'utilisation intensive est utile lorsque vos pods n'ont besoin de ressources supplémentaires que pendant de courtes périodes pour faire face aux pics d'utilisation des ressources. Les exemples de scénarios incluent les éléments suivants:

• Vous avez des groupes de charges de travail qui sont souvent inactifs et envoient un petit nombre de demandes par seconde, mais connaissent parfois des pics de trafic et pourraient bénéficier de ressources supplémentaires pour traiter ces demandes.
• Vos charges de travail ont besoin de plus de ressources au démarrage qu'au cours des opérations normales.
• Vous souhaitez maximiser 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 l'essentiel de son environnement d'exécution, tout en garantissant que votre pod peut consommer plus de ressources si nécessaire. Les avantages de l'utilisation intensive sont les suivants :

• Réduction des coûts d'exploitation: vous n'avez pas besoin de demander la consommation correspondant au pic d'activité attendu de la charge de travail. Vos requêtes peuvent concerner les valeurs d'état stable inférieures. Avec Autopilot, vous payez la somme des demandes de ressources de votre pod, ce qui réduit les coûts d'exploitation.
• Utilisation plus efficace des ressources: vous évitez d'avoir une capacité de calcul inutilisée, car vos pods exploitent 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 des événements d'ajustement.

Cas pour lesquels l'utilisation de l'éclatement 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 burstable dans la documentation 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.

• Assurez-vous qu'un cluster GKE Autopilot exécute la version 1.30.2-gke.1394000 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é de l'utilisation intensive dans GKE

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

Limites

• Les charges de travail Autopilot ne peuvent utiliser l'utilisation intensive que pour les demandes de ressources mémoire et de processeur.

• Lorsque vous mettez à niveau un cluster Autopilot vers une version compatible, GKE met à jour les nœuds de calcul pour qu'ils correspondent à la version du plan de contrôle au fil du temps. Un redémarrage du plan de contrôle est nécessaire pour activer l'utilisation intensive et doit se produire une fois que tous les nœuds exécutent une version compatible et un mode cgroup compatible. Le plan de contrôle redémarre automatiquement environ une fois par semaine lors d'opérations telles que le scaling, les mises à niveau ou la maintenance.

  Pour déclencher manuellement un redémarrage du plan de contrôle, procédez comme suit :

  1. Vérifiez si tous vos nœuds exécutent la version 1.30.2-gke.1394000 ou ultérieure :

     kubectl get nodes
     

     Le résultat ressemble à ce qui suit :

     NAME                                          STATUS   ROLES    AGE     VERSION
     gk3-ap-cluster-1-default-pool-18092e49-mllk   Ready    <none>   4m26s   v1.30.2-gke.1349000
     

     Tous les nœuds de la sortie doivent afficher la version requise ou une version ultérieure.

  2. Vérifiez que votre cluster exécute cgroupv2. Pour obtenir des instructions, consultez la section Vérifier le mode cgroup.

  3. Démarrez manuellement une mise à niveau du plan de contrôle vers la même version que celle utilisée par le cluster.

     gcloud container clusters upgrade CLUSTER_NAME --master \
         --cluster-version CURRENT_CLUSTER_VERSION
     

     Remplacez les éléments suivants :

     • CLUSTER_NAME : nom de votre cluster existant.
     • CURRENT_CLUSTER_VERSION: version exécutée par votre cluster.

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.

Vérifier que votre cluster est compatible avec l'utilisation intensive

La rafale est toujours activée dans les clusters en mode Standard et pour les charges de travail en mode Autopilot qui demandent des accélérateurs ou des séries de machines spécifiques. Passez à la section Déployer une charge de travail compatible avec l'utilisation intensive.

Les types de charges de travail Autopilot suivants ne peuvent être gérés que si un DaemonSet géré par GKE nommé efficiency-daemon s'exécute dans le cluster:

• Pods Autopilot qui demandent les classes de calcul prédéfinies Scale-Out ou Balanced.
• Pods Autopilot qui ne demandent pas de classe de calcul

GKE déploie le DaemonSet efficiency-daemon lorsque votre cluster Autopilot répond aux exigences d'utilisation intensive, comme décrit dans la section Disponibilité de l'utilisation intensive dans GKE.

Pour vérifier si le DaemonSet efficiency-daemon existe dans votre cluster, exécutez la commande suivante:

kubectl get daemonset --namespace=kube-system efficiency-daemon

Le résultat ressemble à ce qui suit :

NAME                DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
efficiency-daemon   1         1         1       1            1           <none>          105d

Si la sortie est vide, assurez-vous que le cluster répond à toutes les exigences et limites de la section Avant de commencer.

Déployer une charge de travail compatible avec l'utilisation intensive

1. 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:
         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 contient les champs suivants pour activer le forçage:

   • resources.requests: ressources nécessaires au conteneur pour fonctionner. Définissez cette valeur sur la capacité dont votre conteneur aura besoin à l'état stable.
   • resources.limits: capacité de ressources maximale que le conteneur peut utiliser. Définir des limites supérieures aux requêtes permet aux pods d'atteindre la limite spécifiée si cette capacité est disponible sur le nœud. Si vous omettez ce champ, les pods peuvent utiliser jusqu'à la capacité intensive 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 sur le nœud.
     • Mode standard: capacité inutilisée dans les ressources du nœud.
   • spec.nodeSelector et spec.tolerations : facultatifs. Ajoutez ces champs avec des libellés personnalisés tels que pod-type: "non-critical" pour indiquer à GKE de créer des nœuds pour exécuter les pods pouvant passer à l'utilisation intensive. GKE applique des rejets à ces nouveaux nœuds pour éviter que d'autres pods, tels que des charges de travail critiques, ne s'exécutent sur les mêmes nœuds. Autopilot applique des demandes de ressources minimales plus élevées pour les pods qui utilisent la séparation des charges de travail. Pour en savoir plus, consultez les pages Configurer la séparation des charges de travail dans GKE et Demandes de ressources dans Autopilot.

2. Déployer la charge de travail :

   kubectl apply -f burstable-deployment.yaml
   

   Le démarrage de la charge de travail peut prendre quelques minutes.

3. 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é compatible avec l'utilisation intensive dans GKE

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

• Clusters Autopilot :

  • Pods qui demandent des accélérateurs ou des séries de machines spécifiques : la capacité des ressources pouvant être allouées aux nœuds, qui est disponible pour l'utilisation des charges de travail. Pour en savoir plus, consultez la section Ressources pouvant être allouées aux nœuds.
  • Tous les autres pods : la somme des demandes de ressources de tous les pods sur ce nœud, quelle que soit la capacité réelle des ressources sur le nœud. Si un pod est arrêté, la capacité extensible est réduite par les 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 si l'un des pods doit être utilisé 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 : la capacité des ressources pouvant être allouées aux nœuds, qui est disponible pour l'utilisation des charges de travail. Pour en savoir plus, consultez la section Ressources pouvant être allouées aux nœuds.

Bonnes pratiques pour les pics d'activité

Utilisez les pratiques suivantes pour l'utilisation intensive par les pod :

• Définissez vos demandes de ressources sur la base de vos limites pour tous les pods qui fournissent 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 la mémoire que sur les pods capables de gérer leur é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 puisse démarrer. Ne vous fiez pas à 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é compatible avec l'utilisation intensive dans les nœuds Autopilot

Autopilot calcule la capacité extensible en additionnant les ressources de tous les pods d'un nœud spécifique, y compris les pods système et DaemonSets. Vous pouvez optimiser la capacité extensible d'un nœud par les méthodes suivantes. Toutefois, l'envoi groupé est opportuniste et n'est pas garanti.

• Afin d'augmenter la capacité d'utilisation intensive des nœuds pour des charges de travail spécifiques, utilisez Affinité de pod pour placer des pods spécifiques sur le même nœud.
• Pour garantir qu'une capacité extensible spécifique est toujours disponible sur chaque nœud, Créer des DaemonSets s'exécutant sur tous les nœuds du cluster.

Exemple de fonctionnement de l'utilisation intensive

Cette section utilise un exemple de déploiement avec les pods extensibles suivants pour 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é extensible totale du nœud est de 450 CPU (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.

Imaginons les scénarios suivants 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 de capacité d'utilisation intensive.
• 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 d'une capacité extensible restante de 100 CPU.
• 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 250 CPU et ne peut pas utiliser plus que cette limite.

Gestion des pods qui dépassent la capacité compatible avec l'utilisation intensive par GKE

Si vos pods extensibles essaient d'utiliser plus de ressources que la capacité disponible sur le nœud, GKE effectue les actions suivantes:

• CPU : 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 les ressources de processeur qu'ils demandent.
• Mémoire: si l'utilisation de la mémoire dépasse la capacité extensible, GKE arrête les conteneurs pour récupérer la mémoire sur le nœud. GKE commence par arrêter les conteneurs utilisant beaucoup de ressources sur les pods avec une QoS inférieure.

Nous vous recommandons de toujours demander suffisamment de mémoire pour le fonctionnement normal du pod. Si un conteneur dépend de l'utilisation intensive de la mémoire pour fonctionner normalement, il pourrait planter à plusieurs reprises 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 pour réserver de la capacité de calcul supplémentaire pour un scaling plus rapide des pods lors des futurs événements à fort trafic, comme les ventes flash sur la boutique en ligne. Les autres pods du même nœud peuvent utiliser cette capacité réservée inutilisée de façon intensive afin que la capacité ne soit pas inactive dans la période précédant un trafic élevé. Vous pouvez réserver cette capacité à l'aide de différents mécanismes Kubernetes. Par exemple, vous pouvez déployer des pods dont la PriorityClass est faible. Pour en savoir plus, consultez la page Provisionner une capacité de calcul supplémentaire pour un scaling rapide des pods.

Utilisation intensive des pods dans les clusters GKE Standard

Les clusters GKE Standard prennent également en charge 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 pour faire face à l'utilisation intensive. Pour obtenir la réduction de coûts potentielle des Pods extensibles dans les clusters standards, vous devez planifier plus attentivement les nœuds et effectuer un bin-packing des pods, car vous payez les VM Compute Engine sous-jacentes.

Tenez compte des points suivants dans les clusters standards:

• La limite maximale de consommation des ressources qui déclenche l'éviction de Kubernetes ou la limitation du CPU est la capacité de ressources pouvant être allouée nœud. Pour déterminer cette valeur, consultez Planifier les tailles de nœuds GKE Standard.

• L'utilisation des ressources de nœuds dans les clusters standards a plus de chances d'atteindre le seuil d'éviction de Kubernetes, car GKE ne limite pas automatiquement la consommation des ressources si vous ne spécifiez pas de limites. Les pods qui utilisent intensivement la mémoire sont donc plus susceptibles d'être arrêtés par l'éviction de nœuds sous pression de Kubernetes.

Étapes suivantes

• Provisionner une capacité de calcul supplémentaire pour un scaling rapide des pods
• Dimensionner correctement vos charges de travail GKE Standard à grande échelle