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 secours à l'aide d'une définition de ressource personnalisée Kubernetes CapacityBuffer. L'utilisation d'un tampon 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 s'assurer que GKE provisionne les nœuds à l'avance.

Lorsqu'une charge de travail de haute priorité doit évoluer rapidement, la nouvelle charge de travail peut utiliser immédiatement la capacité vide sans attendre le provisionnement des nœuds. Cela réduit la latence et évite la contention des ressources lors de pics de demande soudains.

Cette page présente trois méthodes de configuration des tampons de capacité : un tampon d'instances répliquées fixes, un tampon basé sur un pourcentage et un tampon de limites de ressources.

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 la Google Cloud CLI pour cette tâche, installez et 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 un cluster GKE ou accédez-y en version 1.35.2-gke.1842000 ou ultérieure.
  • (Facultatif, mais recommandé) Activez le provisionnement automatique des nœuds sur votre cluster.

  • Pour utiliser des tampons de secours, vous devez créer un cluster avec la version GKE suivante :

    gcloud container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --cluster-version=1.35.2-gke.1842002 \
    --release-channel=None

    Remplacez les éléments suivants :

    • CLUSTER_NAME : nom de votre nouveau cluster
    • COMPUTE_REGION : région Compute Engine de votre nouveau cluster, par exemple us-central1

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

    • 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 fichier manifeste crée un espace de noms appelé capacity-buffer-example.

  2. 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"

    Ce fichier 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érera pas les nœuds avec moins d'un processeur et 1 Gio de ressources disponibles comme faisant partie du tampon, si le cluster évolue.

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

    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 de la section suivante.

  4. Appliquez les fichiers manifestes à votre cluster :

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

  5. 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ées 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 fichier manifeste crée une ressource CapacityBuffer qui 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 fichier manifeste. Le champ STATUS doit afficher ReadyForProvisioning.

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 basés sur un pourcentage sont compatibles avec tout objet qui définit une sous-ressource de scaling, telle 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 pod, car ils ne comportent pas de champ replicas.

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 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 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 le scaling dynamique en effectuant manuellement un scaling 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 met automatiquement à l'échelle le tampon à quatre instances répliquées.

Configurer un tampon de limites de ressources

Vous pouvez utiliser le champ limits pour définir un nombre maximal de ressources que le tampon doit consommer, calculé en fonction de la taille du 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 fichier 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.

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 1d.

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

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 le nombre de 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 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.

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