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

Ce document explique comment utiliser le boost de démarrage du processeur avec l'autoscaler de pods verticaux (VPA) dans Google Kubernetes Engine (GKE) pour augmenter temporairement les ressources de 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 la rentabilité en augmentant temporairement les demandes de processeur lors de l'initialisation et en les redimensionnant à nouveau aux niveaux de base. Ce document aborde les exigences, la configuration (au niveau du pod et du conteneur), la vérification et les bonnes pratiques concernant le boost au démarrage.

Ce document s'adresse 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, comme celles écrites en Java, Node.js ou Python.
  • Rentabilité : évitez de surdimensionner le processeur pour un fonctionnement à l'état stable tout en répondant aux exigences de démarrage. L'état stable correspond à la période qui suit l'initialisation d'une application et la stabilisation de son utilisation des ressources.
  • Aucune interruption : redimensionnez les ressources pour revenir aux niveaux de référence à l'aide du redimensionnement de pods sur place (IPPR) de Kubernetes sans redémarrer vos conteneurs.
  • Réduction des efforts manuels : minimisez 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 remplir les conditions suivantes :

  • Version GKE : utilisez la version 1.36.0-gke.4447000 ou ultérieure pour les clusters Standard et Autopilot.
  • VPA activé : activez l'autoscaling vertical des pods sur les clusters standards. GKE active VPA par défaut sur les clusters Autopilot. Vous pouvez utiliser 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 Définir automatiquement les demandes de ressources des pods.
  • Type de charge de travail : utilisez un contrôleur, tel qu'un objet Deployment ou StatefulSet, pour gérer votre charge de travail.
  • Capacité des nœuds : assurez-vous que les clusters standards disposent d'une capacité suffisante pour le pod boosté. Si la capacité est insuffisante, GKE limite la demande de 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 Fonctionnement de l'optimisation du processeur au démarrage.

Avant de commencer

Avant de commencer, assurez-vous d'avoir sélectionné le projet Cloud de Confiance by S3NS contenant le cluster que vous souhaitez booster et d'avoir effectué les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Pour 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 commande gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

  • Configurez la 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 Créer un cluster.

Rôles requis

Pour obtenir les autorisations nécessaires pour activer et utiliser le boost au démarrage du processeur, 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'augmentation pour qu'elle s'applique à tous les conteneurs d'un pod ou cibler des conteneurs individuels avec des augmentations de ressources spécifiques.

Configurer un boost au niveau du pod

Un boost au niveau du pod applique la même augmentation des ressources de 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 un boost au niveau du pod, utilisez l'une des options suivantes.

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

Utilisez cette option pour exploiter les capacités de boost de démarrage du processeur de VPA exclusivement, sans appliquer les recommandations VPA habituelles. L'exemple suivant applique un facteur de multiplication du CPU 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 du processeur au démarrage et mode de mise à jour du VPA activés

Utilisez cette option si vous souhaitez que GKE gère l'augmentation du démarrage, puis continue d'ajuster automatiquement les demandes de ressources de votre pod en fonction de l'utilisation continue. L'exemple suivant applique le boost 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 un boost au niveau du conteneur

Si votre charge de travail inclut des sidecars ou d'autres conteneurs qui ne nécessitent pas de ressources supplémentaires, vous pouvez cibler des conteneurs spécifiques pour un boost de 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 un boost au niveau du conteneur, utilisez l'une des options suivantes.

Option A : Booster un conteneur spécifique (action VPA désactivée)

Utilisez cette option pour appliquer un boost à 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 pour un boost au niveau du pod

Utilisez cette option si vous avez configuré un boost au niveau du pod, mais que vous souhaitez exclure un conteneur spécifique. L'exemple de fichier manifeste suivant applique un facteur de multiplication du processeur de 2 à l'ensemble du pod, mais désactive le boost 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

Vérifier l'optimisation du processeur au démarrage

Pour vérifier que vos pods bénéficient de l'augmentation, vérifiez la configuration VPA, les demandes de ressources de pod, les annotations de pod et les événements 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érifiez la demande de processeur boosté 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'augmentation de la fréquence du processeur à l'aide des annotations de pod

Le webhook d'admission VPA insère une annotation à portée de conteneur pour suivre les ressources d'origine auxquelles chaque conteneur doit revenir à l'expiration du boost. 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 :

Vérifier les événements de réduction de capacité

Pour vérifier que GKE a bien réduit l'allocation de ressources CPU à 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 :

  • Désactivation réussie du boost : un événement InPlaceResizedByVPA s'affiche avec un message indiquant que le pod a été redimensionné sur place par le VPA Updater. Cela confirme que la demande de processeur est revenue à sa valeur de référence sans redémarrer le conteneur.
  • Annulation du boost non effectuée : l'annotation vpaCpuStartupBoost/CONTAINER_NAME reste sur le pod longtemps après l'expiration du boost, et aucun événement InPlaceResizedByVPA n'est enregistré.

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 de pods (AHP) avec l'augmentation du processeur au démarrage, suivez ces consignes :

  • Définissez des vérifications d'état : vous devez définir un readinessProbe pour vos charges de travail.
  • Configurer le délai de durée : vous devez définir le paramètre durationSeconds sur 0. Cette configuration empêche AHP de faire évoluer votre application de manière prématurée 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 scale-up de nœud. Une fois le pod prêt et réduit, la sous-utilisation peut déclencher la réduction du nœud et l'expulsion du 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

Pour comprendre l'impact des redémarrages de conteneurs sur l'optimisation du processeur au démarrage, examinez les comportements suivants :

  • Uniquement lors de la création du pod : l'optimisation du processeur au démarrage ne s'applique qu'à la phase initiale de création du pod.
  • Pas de boost 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 de nouveau boost. Ce comportement se produit, car le webhook d'admission de pod ne se déclenche que lors du processus de création initial du pod.

Effectuer un nettoyage

Étant donné que vous configurez le boost de démarrage du processeur sur des charges de travail existantes, gardez les points suivants à l'esprit pour éviter toute perturbation :

  • 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 la désactiver uniquement à l'aide de l'une des méthodes suivantes, en fonction de votre champ d'application :

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

    • Désactiver le boost pour un conteneur spécifique : pour exclure un conteneur spécifique d'un boost 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 Configurer un boost au niveau du conteneur.

Étapes suivantes