## 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 : ```bash 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 : ```bash 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 : ```bash kubectl get ingress --all-namespaces kubectl describe ingress -n ``` 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 : ```bash kubectl get endpoints -n ``` 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 : ```bash 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 : ```bash kubectl get ingress -n -o yaml > ingress-before.yaml kubectl get svc -n -o yaml > svc-before.yaml kubectl get deploy -n -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 : ```bash 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 : ```bash 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 : ```yaml 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 : ```yaml 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 : ```yaml 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```promql 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 : ```bash #!/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:///) if [ "$response" != "200" ]; then echo "Verification failed: HTTP $response" exit 1 fi echo "Ingress verification passed" ``` Remplacez `` 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 :** ```bash kubectl get endpoints app-service -n default ``` Si les endpoints sont vides, vérifiez le sélecteur du Service et les labels des Pods : ```bash 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 :** ```bash 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 :** ```bash 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 : ```bash 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 :** ```bash 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 : ```bash 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 : ```bash 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. | Élément à vérifier | Commande / Action | Résultat attendu | |----------------------|--------------------------------------------------|-----------------------------------------------| | Version du cluster | `kubectl version --short` | Versions client et serveur enregistrées | | Version du contrôleur | `kubectl get deployment -n ingress-nginx -o jsonpath='{.spec.template.spec.containers[0].image}'` | L'étiquette d'image correspond à la version attendue | | Ressources Ingress existent | `kubectl get ingress --all-namespaces` | Liste des Ingress avec les noms souhaités | | Endpoints backend prêts | `kubectl get endpoints ` | Au moins une adresse dans la colonne ENDPOINTS | | Journaux récents du contrôleur propres | `kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=100` | Pas d'erreurs continues | | Annotations canary correctes | `kubectl get ingress -o yaml` | `canary: "true"` et poids défini | | Secret TLS valide | `kubectl get secret ` | Le secret existe, n'est pas expiré (vérifier les dates) | | Plan de rollback documenté | Examiner le runbook | Étapes claires pour revenir sur l'Ingress et le Deployment | | Test de vérification exécuté | Exécuter le script `curl` de test | Renvoie HTTP 200 | ## 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.