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 qu'une 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 ce cas, vous pouvez définir les limites de ressources de votre charge de travail sur une valeur supérieure à celle des demandes de ressources ou ne pas définir de limites. GKE autorise d'utiliser temporairement plus de ressources que celles indiqué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é extensible dans GKE de ce document.

Avantages de l'utilisation intensive des pods

L'utilisation intensive est utile lorsque vos pods n'ont besoin que de ressources supplémentaires pour de courtes périodes afin de 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 des valeurs d'état stable plus faibles. 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 la capacité de calcul inactive, car vos pods utilisent une 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 de mise à l'échelle.

Cas dans lesquels ne pas utiliser l'utilisation intensive

Kubernetes attribue la classe Burstable Qualité de service (QoS) aux pods qui spécifient des limites de ressources supérieures à leurs requêtes. Les pods QoS Burstable sont plus susceptibles d'être expulsés lorsque Kubernetes doit récupérer des ressources sur le nœud. Pour en savoir plus, consultez Classe QoS intensive 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 initialize 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.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é de l'utilisation intensive dans GKE

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

Disponibilité de l'utilisation intensive
Mode GKE Autopilot

Les pods qui utilisent la classe de calcul Performance ou la classe de calcul Accelerator 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 répond aux deux conditions suivantes:

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

Cette restriction existe, car dans les clusters Autopilot, l'utilisation intensive nécessite cgroup v2. cgroup v2 n'est disponible que dans les clusters créés à l'origine avec la version 1.26 ou ultérieure.
Mode GKE Standard Les pods peuvent passer en utilisation intensive dans n'importe quelle version de GKE.

Les clusters Autopilot créés à l'origine avec une version antérieure à 1.26 et mis ensuite à niveau vers la version 1.29.2-gke.1060000 ou 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)"

Le résultat doit être GKE version 1.26 ou 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 compatible de GKE. 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 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:
      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 contient les champs suivants pour activer l'envoi par lot :

    • 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é maximale des ressources que le conteneur peut utiliser. Si vous définissez des limites supérieures aux requêtes, les pods peuvent dépasser la limite spécifiée si cette capacité est disponible sur le nœud. Si vous omettez ce champ, les pods peuvent passer en utilisation intensive jusqu'à la capacité 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 de nœuds.
    • spec.nodeSelector et spec.tolerations : facultatifs. 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 empêcher que les pods, comme les charges de travail critiques, s'exécutent sur les mêmes nœuds. Pour en savoir plus, consultez la page Configurer la séparation des charges de travail dans GKE.

  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. Pour un nœud spécifique, le calcul est le suivant:

  • Clusters Autopilot : somme des demandes de ressources de tous les pods sur ce nœud, quelle que soit la capacité de ressources réelle du nœud. Si un pod est arrêté, la capacité extensible est réduite en fonction des 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 : capacité totale des ressources disponible sur la VM de nœud.

Bonnes pratiques d'utilisation intensive

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 essentielles 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 démarre. 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. Cependant, l'utilisation intensive est opportuniste et n'est pas garantie.

  • 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.

Considérons 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é d'utilisation intensive, GKE arrête les conteneurs pour récupérer de 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 la 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é en utilisant divers mécanismes Kubernetes. Par exemple, vous pouvez déployer des pods dont la PriorityClass est faible. Pour en savoir plus, consultez 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 acceptent également l'utilisation intensive des pods en définissant des limites supérieures aux demandes 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