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 rechange et les états suspendus de la capacité préprovisionnée et préconfigurée à l'aide d'une ressource CustomResourceDefinition (CRD) Kubernetes CapacityBuffer. L'utilisation de tampons de capacité vous permet 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 haute priorité doit être mise à l'échelle 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 la contention des ressources lors de pics de demande soudains.

Cette page fournit 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
  • 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.
  • Créez un cluster GKE en version 1.35.2-gke.1842000 pour les tampons actifs et en version 1.36.0-gke.2253000 ou ultérieure pour les tampons de secours, ou accédez-y.
  • Activez le provisionnement automatique des nœuds sur vos clusters standards. Dans les clusters Autopilot, le provisionnement automatique des nœuds est déjà activé. Le provisionnement automatique des nœuds est facultatif, mais recommandé pour les tampons actifs et obligatoire pour les tampons de secours.

Créer des objets Kubernetes pré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 en utiliser un 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 exigences en matière de 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 à laquelle vous faites référence 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

    • CustomResourceDefinitions (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 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 manifeste suivant sous le nom custom-compute-class.yaml :

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

    Ce manifeste crée une ComputeClass personnalisée qui définit et contrôle les priorités de calcul pour les nœuds provisionnés par GKE. Pour en savoir plus, consultez la section 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 manifeste crée un PodTemplate qui définit les exigences en matière de ressources pour une seule unité de capacité de tampon (1 processeur et 1Gi de mémoire). Cette configuration spécifie la taille des unités de capacité que GKE provisionne pour le tampon. Par exemple, avec ce PodTemplate, GKE ne considère pas les nœuds avec moins d'un processeur et 1 Gio de ressources disponibles comme faisant partie du tampon, si le cluster est mis à l'échelle.

  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 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 de 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 fixes

La configuration d'un CapacityBuffer avec des instances répliquées fixes spécifie le nombre exact d'unités de tampon souhaité 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 exigences en matière de ressources, par exemple buffer-unit-template.
    • STRATEGY : stratégie de provisionnement, "buffer.x-k8s.io/active-capacity" (par défaut) ou "buffer.gke.io/standby-capacity".

    Ce 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 correspond au nombre d'instances répliquées que vous avez défini dans le manifeste. Le champ STATUS doit afficher ReadyForProvisioning.

Configurer un tampon de limites de ressources

Vous pouvez utiliser le champ limits pour définir une 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 exigences en matière de ressources, par exemple buffer-unit-template.
    • STRATEGY : stratégie de provisionnement, "buffer.x-k8s.io/active-capacity" (par défaut) ou "buffer.gke.io/standby-capacity".

    Ce manifeste crée une ressource CapacityBuffer avec une limite totale de cinq processeurs et 5 Gio de mémoire. Si vous utilisez l'exemple de PodTemplate de l'étape précédente, vous définissez chaque unité comme 1 processeur et 1Gi de mémoire, ce qui devrait générer 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 du CapacityBuffer. Le champ replicas doit afficher une valeur dérivée des limites que vous avez définies. Si vous utilisez l'exemple de 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 s'inscrivent dans les limites définies.

Configurer un tampon basé 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 évolutifs Kubernetes qui implémentent la sous-ressource de scaling, tels que les déploiements, les StatefulSets, les ReplicaSets ou les jobs. 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.

Nous vous recommandons généralement de commencer par des stratégies d'instances répliquées fixes ou de limites de ressources, plutôt que par des tampons basés sur un pourcentage. Les tampons basés sur un pourcentage sont moins réactifs aux mises à l'échelle soudaines si la charge de travail est mise à l'échelle à un nombre faible ou à zéro, car la marge de sécurité est mise à l'échelle proportionnellement aux pods actifs. Ils sont principalement utiles pour les déploiements volumineux qui ne sont jamais mis à l'échelle à un nombre très faible d'instances répliquées.

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, "buffer.x-k8s.io/active-capacity" (par défaut) ou "buffer.gke.io/standby-capacity".

    Ce 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 du 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 la mise à l'échelle dynamique en mettant manuellement à l'échelle le 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 met automatiquement à l'échelle le tampon à 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 d'être suspendu. Le format est une chaîne de durée (par exemple, 5m ou 1h). La valeur par défaut est 5m.
  • buffer.gke.io/standby-capacity-refresh-frequency: fréquence à laquelle les nœuds suspendus sont actualisés. La valeur par défaut est 24h.

L'exemple suivant montre un 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 les temps de 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-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.

  2. Appliquez le 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 à être provisionné :

    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'intégrité de vos tampons de capacité à l'aide des commandes kubectl et des métriques Cloud Monitoring.

Vérifier l'état de la ressource CapacityBuffer

Pour vérifier l'intégrité 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 présentent 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.

Surveiller les performances avec Cloud Monitoring

Pour surveiller les performances des tampons de capacité, surveillez les ressources suivantes dans Cloud Monitoring :

  • Latence de réaction (cluster_autoscaler/reaction_time_milliseconds) : suit la durée nécessaire à l'autoscaler de cluster pour prendre une décision de scaling en fonction de la demande en attente de votre CapacityBuffer.
  • Journaux de l'autoscaler de cluster : recherchez des entrées de journal telles que "Capacity pod processor injecting ..." pour observer les événements de remplacement de pod de tampon actif.

Supprimer des 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 taille 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é.

Tampon de capacité non prêt 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 à l'utilisation), le tampon de capacité ne sera pas prêt pour le provisionnement.

Pour identifier ce problème, vérifiez l'état du 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 à mettre à l'échelle le tampon s'il ne dispose pas des autorisations nécessaires. Ce problème ne se produit que dans les versions de GKE antérieures à 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 de RBAC, consultez la documentation Kubernetes RBAC.

Étape suivante