Automatisation CI/CD d'Ingress Kubernetes avec exemples pratiques

Introduction

L'automatisation CI/CD d'Ingress Kubernetes avec exemples pratiques doit aider les opérateurs à passer d'un problème observé à un résultat vérifié. Commencez par identifier la version installée, la topologie de déploiement, les prérequis et le composant exact inspecté. Cet article se concentre sur le CI/CD d'Ingress Kubernetes pour les développeurs, les consultants DevOps et les équipes techniques de startups. Il relie l'automatisation d'Ingress Kubernetes, le déploiement d'Ingress Kubernetes, le pipeline d'Ingress Kubernetes et le rollback d'Ingress Kubernetes aux commandes, aux sorties attendues, aux signaux d'échec et aux décisions de reprise qui correspondent à la technologie sélectionnée.

L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier le résultat et documenter comment récupérer si l'état attendu n'est pas atteint. Chaque section ci-dessous comprend une commande concrète ou un extrait de configuration que vous pouvez adapter à votre environnement, ainsi que des conseils pour interpréter la sortie. Nous supposons que vous avez kubectl configuré avec accès à un cluster et une familiarité de base avec les ressources Kubernetes telles que les Deployments, les Services et les Ingress.

Inventaire des versions et de l'environnement

Avant d'automatiser le CI/CD d'Ingress, établissez une base fiable. Vous devez connaître la version de Kubernetes, le type et la version du contrôleur Ingress, et comment le trafic circule actuellement. Cette section fournit des commandes pour collecter ces informations en toute sécurité sans effectuer de modifications.

Étape 1 : Identifier les versions du cluster et du contrôleur Ingress

Exécutez les commandes suivantes et enregistrez la sortie dans un runbook ou un journal d'automatisation :

kubectl version --short
kubectl get nodes -o wide
kubectl get pods -n ingress-nginx -o wide   # si vous utilisez ingress-nginx
# ou pour d'autres contrôleurs, ajustez le namespace et le sélecteur de label
kubectl get pods -n kube-system -l app.kubernetes.io/name=traefik -o wide  # exemple pour Traefik

La sortie attendue pour kubectl version --short affiche les versions client et serveur, par exemple :

Client Version: v1.29.2
Server Version: v1.28.5

Inspectez l'étiquette d'image du contrôleur Ingress pour déterminer sa version :

kubectl get deployment ingress-nginx-controller -n ingress-nginx -o jsonpath='{.spec.template.spec.containers[0].image}'

Exemple de sortie : registry.k8s.io/ingress-nginx/controller:v1.9.4. Cette version est importante car les fonctionnalités et les annotations varient entre les versions du contrôleur. Épinglez toujours la version du contrôleur dans votre pipeline CI/CD pour éviter un comportement inattendu.

Étape 2 : Confirmer la ressource Ingress et les services backend

Listez toutes les ressources Ingress et leurs backends :

kubectl get ingress --all-namespaces
kubectl describe ingress <ingress-name> -n <namespace>

La sortie de la description montre les règles, les chemins, les services backend et la configuration TLS. Par exemple :

Rules:
  Host              Path  Backends
  ----              ----  --------
  app.example.com
                    /api   api-service:8080 (10.244.1.5:8080)
                    /      web-service:80 (10.244.2.10:80)

Assurez-vous que les services backend existent et ont des endpoints prêts :

kubectl get endpoints <service-name> -n <namespace>

Si la liste des endpoints est vide, le sélecteur de Service ne correspond à aucun Pod en cours d'exécution. C'est un échec courant pendant le CI/CD lorsqu'un nouveau déploiement a une incohérence de label.

Étape 3 : Vérifier les journaux du contrôleur Ingress pour des anomalies

Consultez les journaux du contrôleur pour des erreurs ou des problèmes de rechargement de configuration :

kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=50

Recherchez les lignes indiquant des échecs de rechargement ou des définitions Ingress invalides. Par exemple, une erreur comme ingress rule contains invalid annotation pointe vers un problème de manifeste qui doit être corrigé avant de poursuivre l'automatisation.

Observation pratique : Capturer l'état actuel avant tout changement

Enregistrez toujours l'état actuel de l'Ingress, du Service et du Pod avant d'appliquer des modifications. Utilisez kubectl get avec -o yaml pour sauvegarder l'état actuel :

kubectl get ingress <name> -n <ns> -o yaml > ingress-before.yaml
kubectl get svc <name> -n <ns> -o yaml > svc-before.yaml
kubectl get deploy <name> -n <ns> -o yaml > deploy-before.yaml

Cela permet une comparaison rapide ou un rollback si le pipeline CI/CD introduit une régression.

Chemin de configuration sûr

Un chemin de configuration sûr pour le CI/CD d'Ingress minimise le risque de casser le trafic en direct. Cette section décrit une approche de déploiement canary ou par étapes, en utilisant un petit changement comme exemple.

Étape 1 : Commencer avec un Ingress de test sur un cluster local

Avant d'intégrer avec le CI/CD, validez votre manifeste Ingress sur un cluster local ou un namespace de développement dédié. Utilisez kubectl port-forward pour tester sans équilibreur de charge externe :

kubectl apply -f test-ingress.yaml
kubectl port-forward -n ingress-nginx deployment/ingress-nginx-controller 8080:80

Accédez à http://localhost:8080 avec l'en-tête Host approprié pour simuler le trafic :

curl -H "Host: app.test" http://localhost:8080/api/health

Sortie attendue du service backend, par exemple {"status":"ok"}.

Étape 2 : Implémenter des déploiements canary pour Ingress

Un déploiement canary route un petit pourcentage de trafic vers une nouvelle version backend sans affecter tous les utilisateurs. Avec ingress-nginx, vous pouvez utiliser les annotations canary. Exemple :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app-v2
            port:
              number: 80

Cet Ingress envoie 10% du trafic pour app.example.com vers le Service app-v2. Surveillez les taux d'erreur et la latence avant d'augmenter le poids.

Étape 3 : Utiliser Helm ou Kustomize pour des déploiements reproductibles

Automatiser les changements d'Ingress est plus facile lorsque vous gérez les manifestes avec Helm ou Kustomize. Par exemple, un fichier de valeurs Helm pour ingress-nginx :

controller:
  service:
    type: LoadBalancer
  ingressClass: nginx

Dans votre pipeline CI/CD, exécutez helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx -f values.yaml puis vérifiez le déploiement.

Étape 4 : Appliquer les changements de manière idempotente

Utilisez kubectl apply avec un manifeste stocké pour garantir l'état souhaité. Incluez la classe Ingress pour éviter les conflits lorsque plusieurs contrôleurs sont installés :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app
  annotations:
    kubernetes.io/ingress.class: nginx   # déprécié ; utilisez spec.ingressClassName à la place
spec:
  ingressClassName: nginx
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app
            port:
              number: 80

kubectl apply -f app-ingress.yaml créera ou mettra à jour la ressource sans effets secondaires.

Étape 5 : Vérifier avec une sonde de readiness

Après avoir appliqué l'Ingress, confirmez que les pods backend sont prêts :

kubectl rollout status deployment/app -n default

Sortie attendue : deployment "app" successfully rolled out. Ensuite, testez l'endpoint Ingress en utilisant curl depuis le cluster ou via port-forward comme montré précédemment.

Vérification et diagnostics

La vérification est au cœur du CI/CD pour Ingress. Vous devez confirmer que le trafic est routé correctement et qu'aucune erreur ne se produit dans le contrôleur. Cette section fournit un flux de travail de diagnostic systématique.

Étape 1 : Inspecter les événements et l'état de l'Ingress

Après avoir appliqué un Ingress, vérifiez son état et ses événements :

kubectl describe ingress app -n default

Recherchez une adresse dans le champ d'état, par exemple Address: 203.0.113.10. Si l'adresse est vide, le contrôleur peut ne pas avoir encore traité l'Ingress ou il y a une mauvaise configuration. Les événements peuvent révéler des problèmes comme service "app" not found ou invalid path type.

Étape 2 : Vérifier les journaux du contrôleur pour les rechargements de configuration

Les contrôleurs Ingress rechargent leur configuration lorsque les ressources Ingress changent. Consultez les journaux récents :

kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=100 | grep -i reload

Un rechargement réussi enregistre généralement quelque chose comme Configuration reloaded successfully. Si vous voyez Error reloading configuration, inspectez la configuration nginx générée pour des erreurs de syntaxe :

kubectl exec -n ingress-nginx deployment/ingress-nginx-controller -- cat /etc/nginx/nginx.conf | grep -C 5 error

Étape 3 : Valider le trafic de bout en bout avec Curl

Testez le routage réel depuis l'intérieur du cluster en utilisant un pod temporaire :

kubectl run curl-test --image=curlimages/curl --rm -it --restart=Never -- curl -v -H "Host: app.example.com" http://ingress-nginx-controller.ingress-nginx.svc.cluster.local/

Vérifiez le code de réponse et les en-têtes. Si vous obtenez un 404, assurez-vous que le chemin correspond ou que le service backend est accessible. Un 503 indique souvent aucun endpoint backend sain.

Étape 4 : Utiliser les métriques pour diagnostiquer la distribution du trafic

Si vous avez Prometheus ou une pile de surveillance, interrogez des métriques comme nginx_ingress_controller_requests pour voir le nombre de requêtes par backend. Pour un canary, comparez le taux de requêtes vers app-v1 vs app-v2 pour confirmer que le poids est appliqué correctement :

sum(rate(nginx_ingress_controller_requests{service="app-v2"}[5m]))

Cela devrait refléter approximativement le poids canary configuré en moyenne sur le temps.

Étape 5 : Automatiser la vérification dans le pipeline CI

Ajoutez une étape de vérification à votre pipeline CI qui s'exécute après la mise à jour de l'Ingress. Exemple avec un script shell :

#!/bin/bash
set -e
kubectl apply -f ingress.yaml
sleep 20  # attendre que le contrôleur recharge
response=$(curl -s -o /dev/null -w "%{http_code}" -H "Host: app.example.com" http://<ingress-ip>/)
if [ "$response" != "200" ]; then
  echo "Verification failed: HTTP $response"
  exit 1
fi
echo "Ingress verification passed"

Remplacez <ingress-ip> par l'adresse IP réelle de l'équilibreur de charge ou utilisez un port-forward en CI.

Modes d'échec et récupération

Même avec une automatisation minutieuse, des échecs surviennent. Cette section décrit les modes d'échec courants liés à Ingress et comment récupérer, y compris les stratégies de rollback.

Mode d'échec 1 : Service backend mal configuré

Symptôme : Les requêtes renvoient 503 Service Unavailable. Cause : L'Ingress pointe vers un Service qui n'a pas d'endpoints sains. Diagnostic :

kubectl get endpoints app-service -n default

Si les endpoints sont vides, vérifiez le sélecteur du Service et les labels des Pods :

kubectl get pods --show-labels -n default
kubectl describe service app-service -n default

Récupération : Corrigez l'incohérence du sélecteur ou augmentez le nombre de répliques du déploiement. Appliquez le manifeste de Service corrigé.

Mode d'échec 2 : Le contrôleur Ingress ne prend pas en compte les changements

Symptôme : Après mise à jour d'un Ingress, le trafic va toujours vers l'ancien backend ou renvoie 404. Cause : Le contrôleur n'a peut-être pas rechargé, ou la classe Ingress est incorrecte. Diagnostic :

kubectl get ingress app -o yaml | grep -A 5 ingressClassName
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=50 | grep -i error

Récupération : Assurez-vous que spec.ingressClassName correspond à la classe configurée du contrôleur. Forcez un rechargement en redémarrant les pods du contrôleur (dernier recours) ou vérifiez les erreurs de validation.

Mode d'échec 3 : Problèmes de certificat TLS

Symptôme : HTTPS renvoie des erreurs de certificat. Cause : Secret manquant, mauvais nom de secret, ou certificat expiré. Diagnostic :

kubectl get secret app-tls -n default
kubectl describe secret app-tls -n default

Vérifiez si le certificat est valide en le décodant :

kubectl get secret app-tls -n default -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -dates

Récupération : Mettez à jour le Secret avec un certificat et une clé valides, puis déclenchez un rechargement en mettant à jour l'annotation de l'Ingress nginx.ingress.kubernetes.io/ssl-redirect: "true" ou en redémarrant le contrôleur.

Mode d'échec 4 : Trafic canary non distribué comme prévu

Symptôme : Le poids canary n'est pas respecté ; le trafic va entièrement vers une version. Cause : Annotation canary: "true" manquante ou définitions Ingress conflictuelles. Diagnostic :

kubectl get ingress app-canary -o yaml

Confirmez les annotations et qu'il existe un Ingress stable avec le même hôte et chemin. Récupération : Assurez-vous que l'Ingress canary a nginx.ingress.kubernetes.io/canary: "true" et que l'Ingress stable existe. Le poids canary est appliqué au backend supplémentaire.

Flux de récupération : Rollback avec kubectl rollout undo

Pour les changements aux Deployments (pas directement à l'Ingress), vous pouvez revenir en arrière en utilisant :

kubectl rollout undo deployment/app -n default

Cela revient à la révision précédente. Pour les ressources Ingress, gardez le manifeste précédent dans le contrôle de version et réappliquez avec kubectl apply -f ingress-previous.yaml.

Rollback automatisé dans le CI/CD

Dans votre pipeline CI/CD, incluez une étape de rollback qui se déclenche si la vérification échoue :

if [ "$verification_failed" = true ]; then
  kubectl apply -f ingress-stable.yaml
  kubectl rollout undo deployment/app -n default
fi

Testez toujours le chemin de rollback dans un environnement de staging avant de vous y fier en production.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour assurer des opérations CI/CD d'Ingress sûres. Chaque élément comprend une commande ou une vérification concrète.

Conclusion

L'automatisation CI/CD d'Ingress Kubernetes avec exemples pratiques n'est utile que si chaque recommandation est versionnée, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure d'exploitation.

Comme prochaine étape, choisissez une vérification à faible risque pour le CI/CD d'Ingress Kubernetes, enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et examinez les dépendances telles que la classe Ingress, le Service et la Network Policy.

Un flux de travail technique fiable rend l'échec visible, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. En mettant en œuvre les pratiques de cet article, vous construisez une base pour une automatisation CI/CD d'Ingress sûre et efficace.

Rappelez-vous toujours : l'automatisation amplifie à la fois le succès et les erreurs. Commencez par l'observation, procédez par petits changements, vérifiez soigneusement et ayez un plan de rollback prêt.