Configurer des marges de capacité

Les tampons de capacité améliorent la réactivité et la fiabilité des charges de travail critiques en gérant de manière proactive la capacité de cluster de réserve et les états suspendus de la capacité préprovisionnée et préconfigurée à l'aide d'une définition de ressource personnalisée (CRD) Kubernetes CapacityBuffer. Les tampons de capacité vous permettent de définir explicitement une quantité spécifique de capacité de nœud inutilisée dans votre cluster. Cette capacité réservée permet de réduire le temps de planification des pods.

Lorsqu'une charge de travail de priorité élevée doit évoluer rapidement, la nouvelle charge de travail peut utiliser immédiatement la capacité vide sans attendre le provisionnement des nœuds. Cette approche minimise la latence et évite les conflits de ressources lors des pics de demande soudains.

Cette page propose des méthodes pour configurer des tampons de capacité : un tampon d'instances répliquées fixes, un tampon de limites de ressources et un tampon basé sur un pourcentage.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Kubernetes Engine.
    • Activer l'API Google Kubernetes Engine
  • Pour utiliser la 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.
  • Créez ou ayez accès à un cluster GKE répondant aux exigences de version suivantes :
    • Pour les tampons actifs, utilisez la version 1.35.2-gke.1842000 ou ultérieure sur les clusters Standard et Autopilot.
    • Pour les tampons de secours, utilisez la version 1.36.0-gke.2253000 ou ultérieure sur les clusters standards, ou la version 1.36.0-gke.2853000 ou ultérieure sur les clusters Autopilot avec des ComputeClasses personnalisées.
  • Activez la création automatique de pools de nœuds sur vos clusters standards. Dans les clusters Autopilot, la création automatique de pools de nœuds est déjà activée. La création automatique de pools de nœuds est facultative, mais recommandée pour les tampons actifs et obligatoire pour les tampons de secours.

Créer les objets Kubernetes requis

Pour configurer un CapacityBuffer, vous avez besoin d'un espace de noms contenant tous les objets requis (le CapacityBuffer lui-même et des ressources supplémentaires telles qu'un PodTemplate ou une charge de travail). Le PodTemplate et le CapacityBuffer doivent se trouver dans le même espace de noms. Vous pouvez créer un espace de noms ou utiliser un espace de noms existant, y compris l'espace de noms default.

Selon le type de CapacityBuffer que vous configurez, vous avez également besoin de l'un des éléments suivants :

  • PodTemplate : définit les besoins en ressources pour une seule unité de capacité de tampon. La configuration spécifiée dans l'objet CapacityBuffer fait référence au modèle de pod.

  • Charge de travail : charge de travail existante que vous référencez dans l'objet CapacityBuffer. Ce guide utilise un objet Deployment comme exemple de charge de travail, mais les tampons de capacité sont compatibles avec les types de ressources suivants :

    • Déploiement
    • ReplicaSet
    • StatefulSet
    • ReplicationController
    • Job

    • Objets CustomResourceDefinition (CRD) qui implémentent la sous-ressource scale.

Cette section fournit des exemples de ces objets. Si vous disposez déjà d'une charge de travail que vous souhaitez configurer avec un tampon de capacité, passez à la section Appliquer un tampon de capacité.

Pour créer un exemple de charge de travail Kubernetes, procédez comme suit :

  1. Enregistrez le manifeste suivant sous le nom namespace.yaml :

    apiVersion: v1
kind: Namespace
metadata:
  name: capacity-buffer-example
  labels:
    name: capacity-buffer-example

    Ce fichier manifeste crée un espace de noms appelé capacity-buffer-example.

  2. Facultatif : Pour utiliser des tampons de capacité avec une ComputeClass personnalisée, enregistrez le fichier manifeste suivant sous le nom custom-compute-class.yaml :

    apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: ccc-example
spec:
  # Buffers are also created according to these priorities
  priorities:
  - machineFamily: n4
  - machineFamily: n4d
  - machineFamily: c4
  - machineFamily: c4d
  nodePoolAutoCreation:
    enabled: true

    Ce fichier manifeste crée un ComputeClass personnalisé qui définit et contrôle les priorités de calcul pour les nœuds provisionnés par GKE. Pour en savoir plus, consultez ComputeClasses personnalisées.

  3. Enregistrez le manifeste suivant sous le nom buffer-pod-template.yaml :

    apiVersion: v1
kind: PodTemplate
metadata:
  name: buffer-unit-template
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
template:
  spec:
    terminationGracePeriodSeconds: 0
    containers:
    - name: buffer-container
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: "1"
          memory: "1Gi"
        limits:
          cpu: "1"
          memory: "1Gi"
    # Optional: Using buffers with a custom ComputeClass /
    # controls the properties of the provisioned nodes.
    nodeSelector:
      cloud.google.com/compute-class: ccc-example

    Ce fichier manifeste crée un PodTemplate qui définit les besoins en ressources pour une seule unité de capacité de tampon (1 de processeur et 1Gi de mémoire). Cette configuration spécifie la taille des unités de capacité que GKE provisionne pour la mémoire tampon. Par exemple, avec ce PodTemplate, GKE ne prendra pas en compte les nœuds disposant de moins de 1 processeur et de 1 Gio de ressources disponibles dans le tampon si le cluster effectue un scaling à la hausse.

  4. Enregistrez le manifeste suivant sous le nom sample-workload-deployment.yaml :

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: critical-workload-ref
  namespace: capacity-buffer-example # the namespace must be the same namespace as the CapacityBuffer
spec:
  replicas: 10
  selector:
    matchLabels:
      app: critical-workload
  template:
    metadata:
      labels:
        app: critical-workload
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["sleep", "3600"]
        resources:
          requests:
            cpu: 100m
      # Optional: Using buffers with a custom ComputeClass /
      # controls the properties of the provisioned nodes.
      nodeSelector:
        cloud.google.com/compute-class: ccc-example

    Ce fichier manifeste crée un exemple de déploiement avec 10 instances répliquées, qui est l'objet de référence pour l'exemple de tampon basé sur un pourcentage dans la section suivante.

  5. Appliquez les fichiers manifestes à votre cluster :

    kubectl apply -f namespace.yaml -f custom-compute-class.yaml -f buffer-pod-template.yaml -f sample-workload-deployment.yaml

  6. Vérifiez que GKE a créé les objets :

    kubectl get podtemplate -n capacity-buffer-example
kubectl get deployment critical-workload-ref -n capacity-buffer-example

    Le résultat ressemble à ce qui suit :

    NAME                   AGE
buffer-unit-template   1m

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
critical-workload-ref   10/10   10           10          1m

Appliquer un tampon de capacité

Cette section fournit des exemples des différents types de tampons de capacité que vous pouvez appliquer à vos charges de travail.

Configurer un tampon d'instances répliquées fixe

La configuration d'un CapacityBuffer avec des instances répliquées fixes spécifie le nombre exact d'unités de tampon que vous souhaitez en fonction d'un PodTemplate.

Pour créer un tampon avec des instances répliquées fixes, procédez comme suit :

  1. Enregistrez le manifeste suivant sous le nom cb-fixed-replicas.yaml :

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: fixed-replica-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  replicas: 3
  provisioningStrategy: "STRATEGY"

    Remplacez les éléments suivants :

    • NAMESPACE : nom de votre espace de noms, par exemple capacity-buffer-example.
    • POD_TEMPLATE : PodTemplate qui définit vos besoins en ressources, par exemple buffer-unit-template.
    • STRATEGY : stratégie de provisionnement, soit "buffer.x-k8s.io/active-capacity" (par défaut), soit "buffer.gke.io/standby-capacity".

    Ce fichier manifeste crée une ressource CapacityBuffer qui fait référence à un PodTemplate pour demander un nombre spécifique d'unités de tampon.

  2. Appliquez le fichier manifeste :

    kubectl apply -f cb-fixed-replicas.yaml

  3. Vérifiez que GKE a appliqué le tampon de capacité :

    kubectl get capacitybuffer fixed-replica-buffer -n NAMESPACE

    Le champ replicas de l'état doit afficher 3, ce qui reflète le nombre d'instances répliquées que vous avez défini dans le fichier manifeste. Le champ STATUS doit afficher ReadyForProvisioning.

Configurer un tampon de limites de ressources

Vous pouvez utiliser le champ limits pour définir la quantité maximale de ressources que le tampon doit consommer, calculée en fonction de la taille de votre PodTemplate.

Pour créer un tampon de limites de ressources, procédez comme suit :

  1. Enregistrez le manifeste suivant sous le nom cb-resource-limits.yaml :

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: resource-limit-buffer
  namespace: NAMESPACE
spec:
  podTemplateRef:
    name: POD_TEMPLATE
  limits:
    cpu: "5"
    memory: "5Gi"
  provisioningStrategy: "STRATEGY"

    Remplacez les éléments suivants :

    • NAMESPACE : nom de votre espace de noms, par exemple capacity-buffer-example.
    • POD_TEMPLATE : PodTemplate qui définit vos besoins en ressources, par exemple buffer-unit-template.
    • STRATEGY : stratégie de provisionnement, soit "buffer.x-k8s.io/active-capacity" (par défaut), soit "buffer.gke.io/standby-capacity".

    Ce fichier manifeste crée une ressource CapacityBuffer avec une limite totale de 5 processeurs et 5 Gio de mémoire. Si vous utilisez l'exemple PodTemplate de l'étape précédente, vous définissez chaque unité sur 1 CPU et 1Gi de mémoire, ce qui devrait donner cinq unités de tampon.

  2. Appliquez le fichier manifeste :

    kubectl apply -f cb-resource-limits.yaml

  3. Vérifiez que GKE a appliqué le tampon de capacité :

    kubectl get capacitybuffer resource-limit-buffer -n NAMESPACE

    Vérifiez l'état de CapacityBuffer. Le champ replicas doit afficher une valeur dérivée des limites que vous avez définies. Si vous utilisez l'exemple PodTemplate de la section précédente, vous devriez voir 5 unités de tampon, car il s'agit du nombre maximal d'unités qui respectent les limites définies.

Configurer une mémoire tampon basée sur un pourcentage

La configuration d'un tampon basé sur un pourcentage dimensionne dynamiquement le tampon en fonction d'un pourcentage d'une charge de travail évolutive existante. Les tampons de capacité basés sur un pourcentage ne sont compatibles qu'avec les objets Kubernetes évolutifs qui implémentent la sous-ressource de scaling, tels que les objets Deployment, StatefulSet, ReplicaSet ou Job. Vous ne pouvez pas définir de tampon basé sur un pourcentage pour les modèles de pods, car ils ne comportent pas de champ replicas.

Dans la plupart des cas, commencez par des stratégies de réplicas fixes ou de limite de ressources plutôt que par des tampons basés sur un pourcentage. Tenez compte des points suivants lorsque vous faites votre choix :

  • Les tampons basés sur un pourcentage sont moins réactifs aux scaling à la hausse soudains si la charge de travail est mise à l'échelle à des nombres faibles ou nuls, car la marge de sécurité diminue proportionnellement aux pods actifs.
  • Les nœuds de secours entraînent des frais de calcul pendant leur période d'initialisation avant d'être suspendus. Le scaling dynamique des tampons de secours en fonction des fluctuations de la charge de travail gaspille des ressources de calcul. Utilisez plutôt des instances répliquées fixes ou des limites de ressources pour les tampons de secours.
  • Les tampons basés sur un pourcentage sont principalement utiles pour les tampons actifs sur les déploiements de grande envergure qui n'évoluent jamais vers un faible nombre d'instances répliquées.

Dans GKE 1.36.3-gke.1244000 et versions ultérieures, pour conserver une taille de tampon minimale lorsque la charge de travail référencée est réduite, définissez le champ replicas avec le champ percentage. GKE utilise le champ qui génère le plus d'unités de tampon. Pour limiter la taille de la mémoire tampon, définissez également le champ limits.

Par exemple, prenons un tampon avec percentage: 20 et replicas: 3 qui fait référence à un déploiement avec 10 instances répliquées. Étant donné que 20 % de 10 instances répliquées est égal à 2, ce qui est inférieur à la valeur replicas de 3, GKE provisionne 3 unités de tampon. Si le déploiement passe à 20 instances répliquées, le tampon passe à 4 unités. Pour en savoir plus, consultez la documentation de référence sur CapacityBuffer.

Pour créer un tampon basé sur un pourcentage, procédez comme suit :

  1. Enregistrez le manifeste suivant sous le nom cb-percentage-based.yaml :

    apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: percentage-buffer
  namespace: NAMESPACE
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: SCALABLE_RESOURCE_NAME
  percentage: 20
  provisioningStrategy: "STRATEGY"

    Remplacez les éléments suivants :

    • NAMESPACE : nom de votre espace de noms
    • SCALABLE_RESOURCE_NAME : nom de votre ressource évolutive, par exemple critical-workload-ref.
    • STRATEGY : stratégie de provisionnement, soit "buffer.x-k8s.io/active-capacity" (par défaut), soit "buffer.gke.io/standby-capacity".

    Ce fichier manifeste crée une ressource CapacityBuffer qui demande une taille de tampon équivalente à 20 % des instances répliquées de la ressource référencée. Si vous utilisez l'exemple de déploiement de la section précédente, la valeur de l'instance répliquée est définie sur 10.

  2. Appliquez le fichier manifeste :

    kubectl apply -f cb-percentage-based.yaml

  3. Vérifiez que GKE a appliqué le tampon de capacité :

    kubectl get capacitybuffer percentage-buffer -n NAMESPACE

    Vérifiez l'état de CapacityBuffer. Le champ replicas doit afficher une valeur issue du calcul du pourcentage. Si vous utilisez l'exemple de déploiement de la section précédente, vous devriez voir 2 unités de tampon, ce qui correspond à 20% des 10 instances répliquées définies dans le déploiement.

  4. Testez l'autoscaling en effectuant un scaling manuel du déploiement jusqu'à 20 instances répliquées :

    kubectl scale deployment critical-workload-ref -n NAMESPACE --replicas=20

    Le contrôleur CapacityBuffer réagit et effectue automatiquement un scaling du tampon pour atteindre quatre instances répliquées.

Personnaliser le comportement du tampon de secours

Vous pouvez utiliser des annotations pour personnaliser le démarrage et l'actualisation des tampons de secours. Ajoutez ces annotations au champ metadata.annotations de votre ressource CapacityBuffer :

  • buffer.gke.io/standby-capacity-init-time : durée pendant laquelle un nœud reste actif après sa création avant que GKE ne le suspende. Spécifiez une chaîne de durée telle que 5m ou 1h. La valeur par défaut est 5m.

  • buffer.gke.io/standby-capacity-refresh-frequency : fréquence à laquelle GKE actualise les nœuds suspendus. Spécifiez une chaîne de durée telle que 12h ou 24h. La valeur par défaut est 24h.

L'exemple suivant montre un fichier manifeste avec ces champs facultatifs pour personnaliser le comportement des tampons de secours :

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: customized-standby-buffer
  namespace: my-namespace
  annotations:
    buffer.gke.io/standby-capacity-init-time: "15m"
    buffer.gke.io/standby-capacity-refresh-frequency: "12h"
spec:
  podTemplateRef:
    name: buffer-unit-template
  replicas: 3
  provisioningStrategy: "buffer.gke.io/standby-capacity"

Précharger des images sur des tampons de secours

Pour accélérer le démarrage des charges de travail lorsqu'un nœud de secours reprend, vous pouvez précharger des images de conteneurs à l'aide d'un DaemonSet. Le DaemonSet s'exécute pendant la période de démarrage avant la suspension du nœud.

Pour précharger des images à l'aide du DaemonSet, procédez comme suit :

  1. Enregistrez le manifeste suivant sous le nom image-puller-daemonset.yaml :

    apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: image-prefetch-daemonset
  namespace: NAMESPACE
spec:
  selector:
    matchLabels:
      name: image-prefetch
  template:
    metadata:
      labels:
        name: image-prefetch
    spec:
      tolerations:
      - key: "buffer.gke.io/standby-capacity-node-suspended"
        operator: "Exists"
      initContainers:
      - name: image-puller
        image: IMAGE_NAME
        command: ["sh", "-c", "true"]
      containers:
      - name: pause
        image: registry.k8s.io/pause:3.9

    Remplacez les éléments suivants :

    • NAMESPACE : espace de noms du DaemonSet, par exemple capacity-buffer-example.
    • IMAGE_NAME : nom de l'image à précharger, par exemple your-app-image:latest.

    Ce fichier manifeste inclut la tolérance buffer.gke.io/standby-capacity-node-suspended afin que le DaemonSet reste planifié sur les nœuds de secours après que GKE les a suspendus.

  2. Appliquez le fichier manifeste DaemonSet à votre cluster :

    kubectl apply -f image-puller-daemonset.yaml

  3. Vérifiez que le DaemonSet est créé :

    kubectl get daemonset image-prefetch-daemonset -n NAMESPACE

  4. Vérifiez que votre tampon de capacité est créé et prêt pour le provisionnement :

    kubectl get capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

    Vérifiez l'état. Le champ STATUS doit afficher ReadyForProvisioning.

Surveiller l'état et les performances du tampon de capacité

Vous pouvez surveiller l'état et l'état de vos tampons de capacité à l'aide de commandes kubectl et de métriques Cloud Monitoring.

Vérifier l'état de la ressource CapacityBuffer

Pour vérifier l'état de vos tampons de capacité et vous assurer qu'ils sont prêts à recevoir des charges de travail, procédez comme suit :

  1. Obtenez l'état de tous les tampons de capacité du cluster :

    kubectl get capacitybuffer -A

  2. Inspectez l'état détaillé, les conditions et les journaux d'événements d'un tampon spécifique :

    kubectl describe capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

Identifier les nœuds de tampon de secours suspendus

Les VM de tampon de secours sont préprovisionnées, mais conservées dans un état suspendu pour réduire les coûts. Vous pouvez reconnaître ces nœuds suspendus, car ils ont une condition personnalisée. Pour auditer les instances de nœud suspendues, exécutez la commande suivante :

kubectl get nodes -o custom-columns='NAME:.metadata.name,SUSPENDED:.status.conditions[?(@.type=="Suspended")].status'

L'état True indique qu'une VM de secours est suspendue. L'état False ou <none> indique un nœud actif en cours d'exécution.

Surveillez les performances avec Cloud Monitoring

Pour surveiller l'impact de bout en bout des tampons de capacité sur les temps de scaling à la hausse, utilisez les tableaux de bord Latence de démarrage dans la console Google Cloud . Utilisez les graphiques Distribution de la latence de démarrage des pods et Latence du premier pod prêt pour suivre la métrique kubernetes.io/pod/latencies/pod_first_ready de la création du pod à son aptitude. Vous pouvez également interroger les événements Scheduled dans Cloud Logging pour mesurer la latence de planification des pods. Pour obtenir des instructions, consultez Surveiller les métriques de latence de démarrage.

Supprimer les tampons de capacité

Si vous n'avez plus besoin d'un tampon de capacité pour vos charges de travail, supprimez l'objet CapacityBuffer. Cela supprime les pods d'espace réservé et permet à l'autoscaler de cluster de réduire la capacité des nœuds.

kubectl delete capacitybuffer CAPACITY_BUFFER_NAME -n NAMESPACE

Remplacez CAPACITY_BUFFER_NAME par le nom du CapacityBuffer que vous souhaitez supprimer.

Dépannage

La section suivante contient des informations sur la résolution des problèmes courants liés aux tampons de capacité.

La capacité tampon n'est pas prête en raison du modèle de facturation

Si vous créez un CapacityBuffer pour une charge de travail qui utilise le modèle de facturation basé sur les pods (paiement par pod), le tampon de capacité ne sera pas prêt pour le provisionnement.

Pour identifier ce problème, vérifiez l'état de CapacityBuffer :

kubectl describe capacitybuffer BUFFER_NAME -n NAMESPACE

Recherchez une condition de type ReadyForProvisioning avec l'état False.

Pour résoudre ce problème, assurez-vous que votre CapacityBuffer fait référence à une charge de travail ou à un PodTemplate compatible avec la facturation basée sur les nœuds.

Erreurs d'autorisation pour les ressources évolutives personnalisées

Si vous configurez un CapacityBuffer pour qu'il fonctionne avec des objets évolutifs personnalisés (à l'aide du champ scalableRef), l'autoscaler de cluster peut ne pas parvenir à effectuer le scaling du tampon s'il ne dispose pas des autorisations nécessaires. Ce problème ne se produit que dans les versions de GKE antérieures à la version 1.36.0-gke.2459000.

Pour résoudre ce problème, accordez manuellement les autorisations requises en créant un ClusterRole et un ClusterRoleBinding, comme dans l'exemple suivant :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: custom-scale-getter
rules:
- apiGroups: ["api.example.com"]
  resources: ["customreplicatedresources/scale"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ca-custom-scale-getter
subjects:
- kind: User
  name: "system:cluster-autoscaler"
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: custom-scale-getter

Pour en savoir plus sur la configuration du RBAC, consultez la documentation sur le RBAC Kubernetes.

Les pods de tampon ne sont pas programmés sur les nœuds provisionnés par des ComputeClasses personnalisées

Si la dépendance de votre configuration CapacityBuffer (par exemple, un PodTemplate) sélectionne une ComputeClass personnalisée, vous pouvez rencontrer un problème où les pods de tampon ne sont pas planifiés sur les nœuds nouvellement provisionnés. Ce problème entraîne la création répétée de pools de nœuds et de nœuds redondants par l'autoscaler de cluster, tandis que les nœuds inactifs sont supprimés.

Ce problème se produit si la ComputeClass personnalisée provisionne des nœuds avec des rejets ou des exigences d'exécution spécifiques, et que vos pods de tampon (ou le PodTemplate sur lequel ils s'appuient) ne disposent pas des tolérances ou des paramètres correspondants.

Pour résoudre ce problème, mettez à jour votre configuration CapacityBuffer afin de spécifier les tolérances, les sélecteurs de nœuds ou les classes d'exécution requis. Par exemple, si votre dépendance sélectionne une ComputeClass personnalisée configurée avec GKE Sandbox, mettez à jour la dépendance pour effectuer l'une des opérations suivantes :

  • Spécifiez le champ spec.runtimeClassName: gvisor.
  • Incluez une tolérance explicite pour le rejet sandbox.gke.io/runtime=gvisor:NoSchedule.

Pour en savoir plus, consultez la documentation sur les ComputeClass personnalisées.

Échec de la reprise des nœuds de tampon de secours

La reprise des nœuds de tampon de secours suspendus peut échouer pour l'une des raisons suivantes :

  • La reprise d'un nœud de secours suspendu nécessite une capacité Compute Engine disponible dans la zone pour le type de machine du nœud et la génération de plate-forme de processeur spécifique, par exemple dans la série de machines E2 ou N2. Si la zone ne dispose pas d'une capacité de calcul suffisante pour cette configuration exacte, le nœud ne peut pas reprendre. Pour en savoir plus, consultez Limites de suspension et de reprise de Compute Engine.
  • Si votre ComputeClass personnalisée active la migration active vers des nœuds de priorité supérieure (activeMigration.optimizeRulePriority: true) et place les VM Spot à une priorité plus élevée que les VM à la demande, GKE migre les nœuds de secours à la demande vers des VM Spot au fil du temps. Étant donné que les VM Spot sont plus soumises à des contraintes de capacité et que les VM Spot suspendues ne peuvent pas être converties en VM à la demande lors de la reprise, ces contraintes peuvent empêcher la reprise de ces nœuds de secours.
  • La reprise du nœud dépasse les quotas Compute Engine de votre projet. Pour en savoir plus, consultez Échec du provisionnement du tampon de capacité en raison des limites de quota.

Pour identifier la raison pour laquelle un nœud de secours n'a pas pu reprendre, interrogez les journaux d'audit Compute Engine dans l'explorateur de journaux pour rechercher les erreurs ZONE_RESOURCE_POOL_EXHAUSTED ou QUOTA_EXCEEDED sur les opérations compute.instances.resume.

Pour résoudre ou atténuer ce problème, effectuez une ou plusieurs des opérations suivantes :

  • Utilisez des clusters régionaux pour que l'autoscaler de cluster puisse provisionner ou reprendre des nœuds dans plusieurs zones.
  • Configurez plusieurs familles de machines dans la liste spec.priorities de votre ComputeClass personnalisée. Si les nœuds suspendus ne peuvent pas reprendre, l'autoscaler de cluster peut se rabattre sur la création de nœuds en fonction d'une autre règle de priorité. Ces nouveaux nœuds mettent plus de temps à être prêts que les nœuds de secours réactivés. Cette configuration ne permet pas de réactiver les nœuds suspendus, car un nœud suspendu ne peut être réactivé qu'avec son type de machine d'origine.
  • Utilisez une ComputeClass personnalisée dédiée avec des VM à la demande, ou définissez le champ activeMigration.optimizeRulePriority sur false pour la ComputeClass utilisée par votre tampon de secours.
  • Associez votre tampon de secours à un petit tampon actif pour absorber les pics de trafic immédiats.

Échec du provisionnement de la capacité tampon en raison des limites de quota

Un tampon de capacité peut provisionner moins d'instances répliquées que demandé ou ne pas effectuer de scaling à la hausse s'il dépasse les ResourceQuotas Kubernetes ou les quotas Compute Engine.

Pour identifier le quota qui limite le tampon, vérifiez un ou plusieurs des quotas suivants :

  • Vérifiez si un ResourceQuota Kubernetes dans l'espace de noms limite le tampon :

    kubectl describe capacitybuffer \
    CAPACITY_BUFFER_NAME \
    -n NAMESPACE

    Dans la sortie status.conditions, recherchez une condition LimitedByQuotas avec l'état True. Les unités de tampon actives et de secours, y compris celles sauvegardées par des nœuds de secours suspendus, sont comptabilisées dans les limites de ResourceQuota de l'espace de noms, comme si les pods de tampon étaient en cours d'exécution. Lorsqu'un tampon dépasse le quota de l'espace de noms, GKE limite le champ status.replicas pour qu'il ne dépasse pas le quota disponible.

  • Vérifiez si les quotas de projet Compute Engine bloquent le provisionnement des nœuds. Dans l'explorateur de journaux, recherchez les événements no.scale.up.nap.quota.exceeded dans le journal container.googleapis.com/cluster-autoscaler-visibility ou recherchez les erreurs QUOTA_EXCEEDED dans les journaux d'audit Compute Engine.

    Lorsque vous vérifiez les quotas Compute Engine pour les tampons de secours, vérifiez les deux quotas suivants en plus des quotas de processeurs virtuels et de mémoire :

    • Les nœuds de secours suspendus conservent leurs adresses IP internes et externes, ce qui consomme le quota d'adresses IP en cours d'utilisation.
    • Lors de la suspension d'une VM de secours, Compute Engine écrit la mémoire du nœud sur le disque, ce qui consomme un quota de disque Persistent disk standard (GB) proportionnel à la taille de la mémoire du nœud.

Pour résoudre la limite de quota, effectuez l'une des opérations suivantes :

Les pods DaemonSet cessent de recevoir des données après la reprise d'un nœud de secours

Après la reprise d'un nœud de tampon de secours suspendu, les pods DaemonSet de ce nœud peuvent cesser de recevoir des données via des connexions de longue durée qui ont été ouvertes avant la suspension du nœud. Les pods n'enregistrent aucune erreur et ne se reconnectent pas.

Ce problème se produit lorsqu'un pod DaemonSet agit en tant que client en réception seule, par exemple pour une réponse HTTP en streaming, une connexion WebSocket, des événements envoyés par le serveur ou un appel de streaming de serveur gRPC. Pendant que le nœud de secours est suspendu, le serveur ou un appareil réseau intermédiaire expire et ferme la connexion. Lorsque le nœud reprend, la pile réseau du pod considère toujours que la connexion est ouverte. Comme le pod n'envoie aucune donnée, il ne détecte jamais que la connexion a été fermée et attend indéfiniment des données.

Pour résoudre ce problème, configurez l'application cliente dans votre pod DaemonSet afin de détecter les connexions fermées et de vous reconnecter en effectuant l'une des opérations suivantes :

  • Configurez le keepalive TCP côté client dans l'application de votre pod (l'activation du keepalive uniquement sur le serveur n'envoie pas de notification au pod). Pour en savoir plus sur les paramètres de keepalive TCP, consultez Connexions inactives.
    1. Activez l'option de socket SO_KEEPALIVE dans votre bibliothèque cliente ou votre environnement d'exécution de langage, par exemple socket.setKeepAlive(true, initialDelay) dans Node.js ou net.Dialer.KeepAlive dans Go. Certains environnements d'exécution désactivent TCP keepalive par défaut.
    2. Configurez un temps d'inactivité keepalive court (TCP_KEEPIDLE), par exemple quelques secondes, au lieu de vous fier à la valeur par défaut du système d'exploitation.
    3. Mettez à jour votre application pour intercepter l'erreur de connexion (telle qu'une réinitialisation ou un délai avant expiration de la connexion) lorsqu'une vérification de l'activité échoue, et ouvrez une nouvelle connexion.
  • Configurez des signaux de pulsation ou des délais avant expiration de lecture au niveau de l'application dans votre client, tels que des frames ping et pong WebSocket ou des pings gRPC keepalive, et mettez à jour votre application pour qu'elle se reconnecte lorsqu'un délai avant expiration se produit.

Étapes suivantes