Automatiser la gestion des quotas de ressources Kubernetes avec CI/CD

Introduction

Les quotas de ressources Kubernetes (Resource Quotas) sont essentiels pour éviter qu'une seule équipe ou un seul namespace ne consomme excessivement les ressources du cluster. Cependant, gérer les quotas manuellement sur de nombreux namespaces est source d'erreurs et prend du temps. Automatiser la gestion des quotas avec CI/CD garantit des changements cohérents, auditables et reproductibles. Cet article fournit un guide pratique et concret pour construire un pipeline CI/CD pour les quotas de ressources, couvrant l'inventaire de l'environnement, la configuration sécurisée, la vérification, la récupération en cas d'échec et une liste de contrôle opérationnelle. Nous utiliserons des commandes, des manifestes et des exemples concrets pour que vous puissiez adapter le flux de travail à vos propres clusters.

Inventaire des versions et de l'environnement

Avant d'automatiser les changements de quotas, vous devez comprendre votre environnement actuel. Cette section explique comment collecter les informations de version, de topologie et les prérequis à l'aide de commandes en lecture seule, puis planifier le plus petit changement sûr.

Prérequis

• Cluster Kubernetes version 1.21 ou supérieure (l'API Resource Quota est stable depuis la v1, mais certaines fonctionnalités comme les sélecteurs d'étendue peuvent varier). Vérifiez avec :

  kubectl version --short

Sortie attendue :

  Client Version: v1.27.0
  Server Version: v1.27.0

• kubectl configuré avec les permissions RBAC appropriées pour obtenir, lister et créer des objets ResourceQuota dans les namespaces cibles.
• Un dépôt Git pour stocker les manifestes YAML des quotas et les définitions du pipeline.
• Un système CI/CD (par exemple, GitHub Actions, GitLab CI, Jenkins) avec un compte de service disposant de droits limités sur le cluster.

Observation en lecture seule

Commencez par inspecter les quotas de ressources existants dans un namespace sans rien modifier. Par exemple, dans le namespace team-a :

kubectl get resourcequota -n team-a

Si aucun quota n'existe, vous verrez :

No resources found in team-a namespace.

Si des quotas existent, la sortie ressemblera à :

NAME            AGE   REQUEST                                            LIMIT
compute-quota   10d   requests.cpu: 2/4, requests.memory: 2Gi/4Gi        limits.cpu: 4/8, limits.memory: 4Gi/8Gi

Obtenez les détails d'un quota spécifique :

kubectl describe resourcequota compute-quota -n team-a

Notez les valeurs utilisées (Used) et dures (Hard). Cela vous indique à quel point vous êtes proche des limites avant tout changement.

Inspectez également les libellés du namespace, car les quotas peuvent être limités par sélecteur de namespace si vous utilisez ResourceQuota avec scopeSelector (plus de détails plus loin). Vérifiez les libellés :

kubectl get namespace team-a --show-labels

Rayon d'impact et plus petit changement

Modifier un quota de ressources affecte tous les pods de ce namespace : les nouveaux pods peuvent être rejetés s'ils dépassent le quota, mais les pods existants ne sont pas expulsés automatiquement. Le rayon d'impact est à l'échelle du namespace. Par conséquent, le plus petit changement justifié pourrait être d'ajouter un nouveau quota pour une ressource spécifique plutôt que de modifier un quota existant. Par exemple, si vous devez limiter le nombre de demandes de volumes persistants, créez un objet quota séparé au lieu de modifier le quota de calcul.

Exemple de nouveau quota minimal YAML (pvc-quota.yaml) :

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pvc-quota
  namespace: team-a
spec:
  hard:
    persistentvolumeclaims: "5"

Appliquez d'abord ceci manuellement dans un namespace de test pour vérifier le comportement, puis automatisez.

Commande de vérification

Après tout changement, vérifiez que le quota est actif et correctement configuré :

kubectl get resourcequota pvc-quota -n team-a -o yaml

Vérifiez les champs spec.hard et status.used.

Chemin de configuration sûr

Cette section détaille comment gérer les configurations de quotas de ressources en toute sécurité dans un pipeline CI/CD, en garantissant que chaque changement est revu, testé et appliqué avec un plan de restauration.

Structure du dépôt

Organisez vos manifestes de quotas dans un dépôt Git avec une structure de répertoires claire. Par exemple :

quotas/
  team-a/
    compute-quota.yaml
    pvc-quota.yaml
  team-b/
    compute-quota.yaml
  global/
    default-quotas.yaml

Chaque fichier doit contenir une ou plusieurs définitions ResourceQuota avec le namespace spécifié dans les métadonnées. Alternativement, utilisez Kustomize ou Helm pour gérer les surcharges spécifiques au namespace.

Étapes du pipeline

Un pipeline CI/CD typique pour les quotas de ressources comporte ces étapes :

1. Lint : Valider la syntaxe YAML et le schéma Kubernetes.
2. Dry-run : Utiliser kubectl apply --dry-run=client pour vérifier les erreurs d'API.
3. Appliquer au staging : Déployer d'abord sur un cluster ou namespace de staging.
4. Test de fumée : Vérifier que les quotas sont créés et appliqués comme prévu.
5. Approbation : Exiger une approbation manuelle avant la production.
6. Appliquer en production : Déployer avec --server-side en option pour éviter les conflits.
7. Enregistrer : Stocker les manifestes appliqués et les sorties pour l'audit.

Exemple de pipeline (GitHub Actions)

Créez un fichier de workflow .github/workflows/quota-deploy.yaml :

name: Deploy Resource Quotas
on:
  push:
    paths:
      - 'quotas/**'
    branches:
      - main
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v3
      - name: Set up kubectl
        uses: azure/setup-kubectl@v3
        with:
          version: 'v1.27.0'
      - name: Dry-run apply
        run: |
          set -e
          for file in $(find quotas -name '*.yaml'); do
            echo "Dry-run applying $file"
            kubectl apply -f $file --dry-run=client
          done
      - name: Apply to production
        run: |
          for file in $(find quotas -name '*.yaml'); do
            kubectl apply -f $file
          done

Dans cet exemple, le pipeline s'exécute à chaque push sur main affectant les fichiers de quotas. Il effectue d'abord un dry-run de tous les manifestes, puis les applique. Vous pouvez ajouter une étape d'approbation manuelle en utilisant les règles de protection des environnements GitHub.

Stratégie de restauration

Les changements de quotas sont faciles à annuler si vous utilisez des tags Git ou conservez les versions précédentes dans le dépôt. Pour annuler, appliquez simplement la version précédente du manifeste :

git revert <commit-hash>
kubectl apply -f quotas/team-a/compute-quota.yaml

Si le quota a été supprimé accidentellement, réappliquez-le depuis Git. Comme les objets ResourceQuota sont déclaratifs, l'application de l'ancien manifeste restaure l'état souhaité.

Vérification et diagnostic

Après avoir appliqué les changements de quotas, vous devez vérifier non seulement que l'objet quota existe, mais aussi qu'il est correctement appliqué. Cette section fournit des commandes pour diagnostiquer les problèmes.

Vérifier la création du quota

Vérifiez que le quota est présent :

kubectl get resourcequota -n team-a

La sortie attendue montre le nom du quota et son âge. S'il est absent, vérifiez les journaux du pipeline pour les erreurs.

Vérifier l'application

Créez un pod de test qui dépasse le quota pour voir s'il est rejeté. Par exemple, si vous avez défini requests.cpu: "4" dans un quota, créez un pod demandant 5 CPU :

# test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-overquota
  namespace: team-a
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      requests:
        cpu: "5"

Appliquez-le :

kubectl apply -f test-pod.yaml

Erreur attendue :

Error from server (Forbidden): error when creating "test-pod.yaml": pods "test-overquota" is forbidden: exceeded quota: compute-quota, requested: requests.cpu=5, used: requests.cpu=2, limited: requests.cpu=4

Si le pod est créé, le quota n'est pas appliqué ou est mal configuré.

Commandes de diagnostic

• Lister les événements du namespace pour voir les erreurs liées aux quotas :

  kubectl get events -n team-a --sort-by='.lastTimestamp'

Recherchez les messages FailedCreate ou ExceededQuota.

• Décrire le quota pour son statut :

  kubectl describe resourcequota compute-quota -n team-a

• Consulter les journaux du serveur API si nécessaire (nécessite des droits d'administrateur du cluster).

Modes de défaillance et récupération

Même avec l'automatisation, des échecs surviennent. Cette section couvre les modes de défaillance courants pour CI/CD des quotas de ressources et comment les récupérer.

Modes de défaillance courants

1. Syntaxe de manifeste invalide : erreur d'indentation YAML ou champ manquant. Le pipeline devrait détecter cela à l'étape lint/dry-run. Sinon, l'application échoue avec une erreur d'analyse. Récupération : corriger le manifeste et relancer le pipeline.
2. RBAC insuffisant : le compte de service CI/CD n'a pas la permission de créer/mettre à jour ResourceQuota dans le namespace cible. Erreur : forbidden: User "system:serviceaccount:ci:deployer" cannot create resource "resourcequotas". Récupération : accorder le rôle RBAC approprié.
3. Namespace incohérent : le manifeste spécifie un namespace qui n'existe pas. Erreur : namespaces "team-c" not found. Récupération : créer d'abord le namespace ou corriger le manifeste.
4. Quota trop restrictif : les développeurs ne peuvent pas déployer de pods, provoquant un incident. Récupération : augmenter immédiatement le quota en modifiant le YAML et en l'appliquant, ou supprimer temporairement le quota (avec prudence).
5. Le pipeline s'applique au mauvais cluster : le contexte kubeconfig pointe vers la production alors que vous vouliez le staging. Récupération : utiliser des contextes séparés et la protection d'environnement dans CI.

Procédures de restauration

Pour tout changement échoué, restaurez le dernier état connu bon depuis Git :

git log --oneline -- quotas/team-a/compute-quota.yaml
# Identifier le hash du commit précédent
git revert <commit-hash>
kubectl apply -f quotas/team-a/compute-quota.yaml

Si le pipeline lui-même est cassé, appliquez manuellement le dernier bon manifeste :

kubectl apply -f quotas/team-a/compute-quota.yaml

Surveillance et alertes

Configurez des alertes sur l'utilisation des quotas pour détecter proactivement les problèmes. Par exemple, si vous utilisez Prometheus, une règle d'alerte :

groups:
- name: quota-alerts
  rules:
  - alert: QuotaAlmostFull
    expr: kube_resourcequota{resource="requests.cpu", type="used"} / kube_resourcequota{resource="requests.cpu", type="hard"} > 0.9
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Resource quota {{ $labels.resourcequota }} is over 90% used"

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour chaque changement de quota via CI/CD afin de garantir sécurité et cohérence.

Exemple de scénario concret

Parcourons un exemple concret : augmenter le quota de demandes CPU pour team-a de 4 à 6 CPU.

1. Quota actuel (compute-quota.yaml) :

   apiVersion: v1
   kind: ResourceQuota
   metadata:
     name: compute-quota
     namespace: team-a
   spec:
     hard:
       requests.cpu: "4"
       requests.memory: "4Gi"
       limits.cpu: "8"
       limits.memory: "8Gi"

1. Modifier requests.cpu en "6" dans une branche de fonctionnalité.
2. Pousser la branche, ouvrir une PR. Le CI exécute dry-run et lint.
3. Réviser et fusionner dans main. Le pipeline applique en production.
4. Vérifier :

   kubectl describe resourcequota compute-quota -n team-a

Attendez requests.cpu: 2/6 (si l'utilisation actuelle est de 2).

1. Tester : déployer un pod demandant 5 CPU, cela devrait réussir maintenant.

Conclusion

Automatiser la gestion des quotas de ressources Kubernetes avec CI/CD apporte reproductibilité, auditabilité et sécurité à la gouvernance des ressources par namespace. En suivant les pratiques décrites dans cet article—inventorier votre environnement, concevoir un chemin de configuration sûr, vérifier rigoureusement les changements, se préparer aux échecs et utiliser une liste de contrôle opérationnelle—vous pouvez prévenir la contention des ressources et les erreurs de configuration. Commencez petit : choisissez un namespace, définissez ses quotas dans Git et créez un pipeline simple avec des étapes de dry-run et d'application. Au fur et à mesure que vous gagnez en confiance, étendez à tous les namespaces et ajoutez des tests automatisés et des alertes. N'oubliez pas que la clé est d'observer avant de changer, de limiter le rayon d'impact et de toujours avoir un plan de restauration.