Checklist d'exploitation Kubernetes Ingress en production avec exemples pratiques

Intro

La checklist d'exploitation Kubernetes Ingress en production avec exemples pratiques est essentielle car déployer un cluster est simple, mais faire tourner Ingress de façon fiable au quotidien ne l'est pas. Ce guide s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui cherchent une méthode reproductible pour configurer, vérifier et dépanner les ressources Ingress. Il relie les thèmes principaux — opérations Ingress Kubernetes, checklist Ingress, bonnes pratiques Ingress et maintenance Ingress — afin que vous puissiez passer du concept à la vérification locale, puis à l'intégration continue en toute confiance.

L'objectif est pratique : comprendre les composants mobiles, les tester localement et éviter les surprises lorsque le même schéma est réutilisé dans un environnement proche de la production.

Workflow Overview

Commencez par identifier la ressource Ingress que vous allez modifier, le champ exact à changer et la commande qui prouve que la modification fonctionne. Maintenez la boucle courte : modifiez un manifeste, appliquez-le, puis vérifiez l'état observé avant de passer à l'étape suivante.

Les concepts clés incluent le routage basé sur l'hôte, le routage basé sur le chemin, la terminaison TLS via un secret et les points de terminaison de santé. Les éléments connexes tels que le contrôleur Nginx Ingress, cert-manager et les définitions de Service Kubernetes sont importants car un sélecteur de Service mal câblé ou un secret TLS manquant se manifestent par des erreurs 502 ou 503.

Commandes de vérification typiques :

kubectl get ingress -n <namespace> -o wide
kubectl describe ingress <name> -n <namespace>
kubectl get svc <backend-svc> -n <namespace>
kubectl port-forward svc/<backend-svc> -n <namespace> 8080:80
curl -k https://<host>/healthz

Si le secret TLS "tls-example" n'existe pas, kubectl describe ingress affichera "TLS secret not found" et le contrôleur renverra 503 pour les requêtes HTTPS. L'ajout du secret et la réapplication de l'Ingress corrigent l'erreur.

Local Pilot Plan

Exécutez un pilote minimal avant de promouvoir toute modification d'Ingress vers la préproduction ou la production.

1. Déployez un petit serveur d'écho (par exemple kennethreitz/httpbin) en tant que Deployment et exposez-le avec un Service ClusterIP nommé httpbin.
2. Créez un manifeste Ingress qui route httpbin.example.com vers le Service, active TLS avec le secret tls-example et définit un chemin /healthz renvoyant 200.

Exemple d'Ingress (environ 12 lignes) :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: httpbin-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
    - httpbin.example.com
    secretName: tls-example
  rules:
  - host: httpbin.example.com
    http:
      paths:
      - path: /healthz
        pathType: Prefix
        backend:
          service:
            name: httpbin
            port:
              number: 80

1. Appliquez les manifestes, puis exécutez la checklist de vérification :

Si une ligne échoue, inspectez kubectl describe ingress httpbin-ingress et les logs du contrôleur (kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx) pour identifier l'erreur exacte.

Conclusion

Traitez chaque modification d'Ingress comme une unité testable : écrivez le manifeste, appliquez-le, lancez les commandes ci-dessus et consignez le résultat. La voie la plus sûre consiste à garder les exemples petits, à exécuter la vérification localement et à confirmer le comportement attendu avant d'ajouter d'autres services ou de l'automatisation.

Pour l'étape suivante, choisissez un service, documentez les commandes exactes utilisées pour construire, déployer, inspecter et annuler son Ingress, puis comparez les résultats avec des domaines connexes tels que la topologie des Services Kubernetes, le réglage de Nginx Ingress et la rotation des certificats TLS. Un workflow fiable rend l'échec visible — les logs sont faciles à trouver, les données persistantes survivent aux reconstructions et le comportement local reflète suffisamment la production pour détecter les erreurs tôt.