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é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 de déploiement 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

    • Définitions de ressources personnalisées (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. 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 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 é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 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é 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

    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.

    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éfinies dans le 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.

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

    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.

    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 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 jusqu'à 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"

    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.

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

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

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 contrôle des accès basé sur les rôles, consultez la documentation Kubernetes RBAC.

Étape suivante