Accélérer le démarrage des applications avec l'optimisation du processeur au démarrage

Ce document explique comment utiliser l'optimisation du processeur au démarrage avec l'autoscaler vertical des pods (VPA) dans Google Kubernetes Engine (GKE) pour augmenter temporairement les ressources processeur allouées à un pod pendant sa phase d'initialisation.

L'optimisation du processeur au démarrage accélère le démarrage des applications et améliore l'efficacité des coûts en augmentant temporairement les demandes de processeur lors de l'initialisation et en les redimensionnant sur place aux niveaux de référence. Ce document couvre les exigences, la configuration (au niveau du pod et du conteneur), la validation et les bonnes pratiques de l'optimisation au démarrage.

Ce document est destiné aux ingénieurs DevOps et de plate-forme, ainsi qu'aux développeurs d'applications qui souhaitent optimiser les performances de démarrage des applications dans GKE.

Avantages

L'utilisation de l'optimisation du processeur au démarrage présente les avantages suivants :

  • Démarrage plus rapide : accélérez l'initialisation des applications gourmandes en ressources , telles que celles écrites en Java, Node.js ou Python.
  • Rentabilité : évitez le surprovisionnement du processeur pour un fonctionnement en régime permanent tout en répondant aux exigences de démarrage. Le fonctionnement en régime permanent correspond à la période qui suit l'initialisation d'une application et la stabilisation de son utilisation des ressources.
  • Aucune interruption : redimensionnez les ressources aux niveaux de référence à l'aide du redimensionnement des pods sur place (IPPR) de Kubernetes sans redémarrer vos conteneurs.
  • Réduction des efforts manuels : réduisez le gaspillage de ressources et les efforts manuels nécessaires pour dimensionner correctement vos charges de travail.

Conditions requises

Pour utiliser l'optimisation du processeur au démarrage, vous devez répondre aux exigences suivantes :

  • Version GKE : utilisez 1.36.0-gke.4447000 ou une version ultérieure pour les clusters Standard et Autopilot.
  • VPA activé : activez l'autoscaling vertical des pods sur les clusters Standard. GKE active le VPA par défaut sur les clusters Autopilot. Vous pouvez utiliser le VPA exclusivement pour l'optimisation du processeur au démarrage en choisissant un mode de mise à jour spécifique. Pour activer et configurer le VPA, consultez la section Définir automatiquement les demandes de ressources des pods.
  • Type de charge de travail : utilisez un contrôleur, tel qu'un déploiement ou un StatefulSet, pour gérer votre charge de travail.
  • Capacité des nœuds : assurez-vous que les clusters Standard disposent d'une capacité suffisante pour le pod optimisé. Si la capacité est insuffisante, GKE limite la requête du pod optimisé pour l'adapter au nœud.

Fonctionnement de l'optimisation du processeur au démarrage

Pour en savoir plus sur le cycle de vie de l'optimisation et sur la façon dont l'optimisation du processeur au démarrage calcule les augmentations de ressources, consultez la section Fonctionnement de l'optimisation du processeur au démarrage.

Avant de commencer

Avant de commencer, assurez-vous d'avoir sélectionné le Cloud de Confiance by S3NS projet contenant le cluster que vous souhaitez optimiser et d'avoir effectué 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 la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la gcloud components update commande. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

  • Configurez gcloud CLI pour utiliser le projet sélectionné :

    gcloud config set project PROJECT_ID

    Remplacez PROJECT_ID par l'ID de votre projet.

  • Assurez-vous de disposer d'un cluster GKE existant. Si vous n'en avez pas, consultez la section Créer un cluster.

Rôles requis

Pour obtenir les autorisations nécessaires pour activer et utiliser l'optimisation du processeur au démarrage, demandez à votre administrateur de vous accorder les rôles IAM suivants sur votre projet :

Pour en savoir plus sur l'attribution de rôles, consultez Gérer l'accès aux projets, aux dossiers et aux organisations.

Vous pouvez également obtenir les autorisations requises avec des rôles personnalisés ou d'autres rôles prédéfinis.

Activer l'optimisation du processeur au démarrage

Pour activer l'optimisation du processeur au démarrage, ajoutez un bloc de configuration startupBoost à votre fichier manifeste VerticalPodAutoscaler (VPA). Vous pouvez configurer l'optimisation pour qu'elle s'applique à tous les conteneurs d'un pod ou cibler des conteneurs individuels avec des augmentations de ressources spécifiques.

Configurer une optimisation au niveau du pod

Une optimisation au niveau du pod applique la même augmentation des ressources processeur à chaque conteneur de la charge de travail. Vous pouvez configurer l'optimisation du processeur au démarrage avec ou sans la gestion continue des ressources du VPA.

Pour configurer une optimisation au niveau du pod, utilisez l'une des options suivantes.

Option A : Optimisation au démarrage activée et mode de mise à jour du VPA désactivé

Utilisez cette option pour exploiter le VPA exclusivement pour ses fonctionnalités d'optimisation du processeur au démarrage sans activer les recommandations VPA régulières. L'exemple suivant applique un facteur de multiplication du processeur de 2 et le maintient pendant 10 secondes après que le pod a atteint l'état Ready :

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Option B : Optimisation au démarrage et mode de mise à jour du VPA activés

Si vous souhaitez que GKE gère l'optimisation au démarrage, puis continue d'ajuster automatiquement les demandes de ressources de votre pod en fonction de l'utilisation continue, utilisez cette option. L'exemple suivant applique l'optimisation au démarrage et définit le champ updateMode sur InPlaceOrRecreate :

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
      durationSeconds: 10

Configurer une optimisation au niveau du conteneur

Si votre charge de travail inclut des side-cars ou d'autres conteneurs qui ne nécessitent pas de ressources supplémentaires, vous pouvez cibler des conteneurs spécifiques pour une optimisation au démarrage dans la section resourcePolicy. La valeur containerName doit correspondre au champ name d'un conteneur dans la spécification de votre déploiement.

Pour configurer une optimisation au niveau du conteneur, utilisez l'une des options suivantes.

Option A : Optimiser un conteneur spécifique (activation du VPA désactivée)

Utilisez cette option pour appliquer une optimisation à un seul conteneur tout en laissant intactes les demandes de ressources du reste du pod. L'exemple de fichier manifeste suivant ajoute deux processeurs virtuels à la requête de référence pour un conteneur nommé boosted-container-name :

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "boosted-container-name"
      mode: "Off"
      startupBoost:
        cpu:
          type: "Quantity"
          quantity: "2"

Option B : Désactiver un conteneur spécifique d'une optimisation au niveau du pod

Si vous avez configuré une optimisation au niveau du pod, mais que vous souhaitez exclure un conteneur spécifique, utilisez cette option. L'exemple de fichier manifeste suivant applique un facteur de multiplication du processeur de 2 à l'ensemble du pod, mais désactive l'optimisation pour un conteneur nommé disable-cpu-boost-for-this-container en définissant son facteur sur 1 :

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: example-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: example
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  startupBoost:
    cpu:
      type: "Factor"
      factor: 2
  resourcePolicy:
    containerPolicies:
    - containerName: "disable-cpu-boost-for-this-container"
      startupBoost:
        cpu:
          type: "Factor"
          factor: 1

Valider l'optimisation du processeur au démarrage

Pour vérifier que vos pods bénéficient de l'optimisation, vérifiez la configuration du VPA, les demandes de ressources des pods, les annotations des pods et les événements du VPA.

Vérifier la configuration du VPA

Pour vérifier les détails de votre objet VerticalPodAutoscaler, exécutez la commande suivante :

kubectl describe vpa VPA_NAME

Remplacez VPA_NAME par le nom de votre objet VPA.

Vérifier la demande de processeur optimisée sur le pod

Pour vérifier les demandes de ressources actuelles de votre pod, exécutez la commande suivante :

kubectl describe pod POD_NAME

Remplacez POD_NAME par le nom de votre pod.

Vérifier l'optimisation du processeur à l'aide des annotations de pod

Le webhook d'admission du VPA injecte une annotation à portée de conteneur pour suivre les ressources d'origine auxquelles chaque conteneur doit revenir lorsque l'optimisation expire. Pour vérifier ces annotations, exécutez la commande suivante :

kubectl get pod POD_NAME --output yaml

Dans la section metadata.annotations, recherchez une annotation au format vpaCpuStartupBoost/CONTAINER_NAME. Exemple :

metadata:
  annotations:
    vpaCpuStartupBoost/slow-starter: '{"requests":{"cpu":"50m","memory":"64Mi"},"limits":{"cpu":"200m","memory":"128Mi"}}'

Le résultat de la commande indique l'un des résultats de validation suivants :

Rechercher des événements de réduction d'échelle

Pour vérifier que GKE a bien réduit l'allocation de ressources processeur à la valeur de référence, vérifiez les événements du cluster en exécutant la commande suivante :

kubectl get events --field-selector reason=InPlaceResizedByVPA

Le résultat de la commande indique l'un des résultats de validation suivants :

  • Optimisation inversée réussie : un événement InPlaceResizedByVPA s'affiche avec un message indiquant que le pod a été redimensionné sur place par le programme de mise à jour du VPA. Cela confirme que la demande de processeur est revenue à sa valeur de référence sans redémarrer le conteneur.
  • Optimisation inversée infructueuse : l' vpaCpuStartupBoost/CONTAINER_NAME annotation reste sur le pod longtemps après l'expiration de l'optimisation, et aucun événement InPlaceResizedByVPA ne s'affiche.

Bonnes pratiques et limites

Tenez compte des points suivants lorsque vous utilisez l'optimisation du processeur au démarrage.

Interactions avec l'autoscaling horizontal des pods

Si vous utilisez l' autoscaler horizontal des pods (AHP) avec l'optimisation du processeur au démarrage, suivez ces consignes :

  • Définissez des sondes d'état : vous devez définir un readinessProbe pour vos charges de travail.
  • Configurez le délai : vous devez définir le paramètre durationSeconds sur 0. Cette configuration empêche le AHP de faire évoluer votre application prématurément en raison d'une utilisation élevée du processeur au démarrage.

Autoscaler de cluster et boucles d'éviction

Si vous utilisez l'autoscaler de cluster sur des clusters GKE Standard, tenez compte des comportements de nœuds suivants :

  • Boucles d'éviction potentielles : une optimisation temporaire du processeur peut déclencher un scaling à la hausse des nœuds. Une fois le pod prêt et l'échelle réduite, la sous-utilisation peut déclencher un scaling à la baisse des nœuds et évincer le pod, ce qui entraîne une boucle sans fin.
  • Atténuation : nous vous recommandons vivement d'utiliser GKE Autopilot pour atténuer les problèmes de défragmentation des nœuds et de boucle d'éviction.

Redémarrages de conteneurs

Comprenez comment les redémarrages de conteneurs affectent l'optimisation du processeur au démarrage en examinant les comportements suivants :

  • Uniquement lors de la création du pod : l'optimisation du processeur au démarrage ne s'applique que lors de l'étape initiale de création du pod.
  • Aucune optimisation au redémarrage : si un conteneur redémarre (par exemple, en raison d'un événement OOMKill), mais que le pod reste actif, GKE n'applique pas à nouveau l' optimisation. Ce comportement se produit, car le webhook d'admission du pod ne se déclenche que lors du processus initial de création du pod.

Effectuer un nettoyage

Étant donné que vous configurez l'optimisation du processeur au démarrage sur des charges de travail existantes, gardez à l'esprit les points suivants pour éviter toute interruption de la charge de travail :

  • Vous n'avez pas besoin de supprimer de ressources Kubernetes.
  • Si votre objet VerticalPodAutoscaler ou vos contrôleurs de charge de travail (tels que les déploiements ou les StatefulSets) sont toujours nécessaires pour les opérations en régime permanent, ne les supprimez pas.

  • Si vous n'avez pas besoin de l'optimisation du processeur au démarrage, vous pouvez désactiver uniquement l'optimisation à l'aide de l'une des méthodes suivantes en fonction de votre champ d'application :

    • Désactiver l'optimisation pour l'ensemble de la charge de travail : supprimez le startupBoost bloc de la spécification de votre objet VerticalPodAutoscaler et appliquez le fichier manifeste mis à jour à votre cluster.

    • Désactiver l'optimisation pour un conteneur spécifique : pour exclure un conteneur spécifique d'une optimisation au niveau du pod, ajoutez une règle de conteneur dans la section containerPolicies et définissez le facteur multiplicateur du processeur sur 1.

        startupBoost:
    cpu:
      type: "Factor"
      factor: 1

      Pour en savoir plus, consultez la section Configurer une optimisation au niveau du conteneur.

Étape suivante