Sauvegarde et restauration des classes Ingress Kubernetes avec exemples pratiques

Introduction

Les classes Ingress Kubernetes contrôlent la façon dont le trafic atteint vos services. Les perdre ou les mal configurer peut entraîner l'interruption de vos applications en production. Cet article vous propose une approche pratique et adaptée à votre version pour sauvegarder, restaurer et valider les classes Ingress, avec des commandes exécutables dès aujourd'hui.

Vous apprendrez à prendre un instantané de vos classes Ingress actuelles, à les restaurer à partir d'une sauvegarde, à revenir à un état connu de bon fonctionnement et à vérifier que tout fonctionne comme prévu. Nous couvrirons les commandes exactes, les sorties attendues, les modes de défaillance courants et la manière de récupérer en cas de problème.

Ce guide s'adresse aux développeurs, aux ingénieurs DevOps et aux équipes techniques qui souhaitent gérer les classes Ingress en toute sécurité. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter l'impact, protéger les secrets et vérifier chaque résultat.

Inventaire de l'environnement et des versions

Avant de toucher quoi que ce soit, comprenez votre environnement. La version de Kubernetes et de votre contrôleur Ingress détermine les commandes et fonctionnalités disponibles. Par exemple, le champ ingressClassName dans la spécification Ingress est stable depuis Kubernetes 1.22, et l'API networking.k8s.io/v1 est la norme actuelle.

Vérification des versions de Kubernetes et du contrôleur

Commencez par identifier la version de votre cluster et le contrôleur Ingress que vous utilisez :

kubectl version --short
kubectl get pods -n ingress-nginx -o wide

Sortie attendue pour la version du cluster :

Client Version: v1.29.0
Server Version: v1.29.2

Pour le contrôleur, vous verrez des pods comme ingress-nginx-controller-xxxx avec l'étiquette de l'image indiquant la version.

Inventaire des classes Ingress actuelles

Listez toutes les classes Ingress du cluster :

kubectl get ingressclass

Exemple de sortie :

NAME    CONTROLLER                      PARAMETERS   AGE
nginx   k8s.io/ingress-nginx           <none>       30d

Pour voir les détails, y compris les annotations et les paramètres, utilisez :

kubectl describe ingressclass nginx

Capturer une sauvegarde

Créez une sauvegarde de toutes les classes Ingress au format YAML :

kubectl get ingressclass -o yaml > ingressclass-backup.yaml

Vérifiez que le fichier n'est pas vide et contient les données attendues :

wc -l ingressclass-backup.yaml
head -20 ingressclass-backup.yaml

Si vous utilisez GitOps, validez ce fichier dans votre dépôt. Pour une sauvegarde plus robuste, exportez également les ressources associées comme le déploiement du contrôleur Ingress, les services et les ConfigMaps, car les classes Ingress en dépendent souvent.

Enregistrer les horodatages et l'état

Avant toute modification, capturez l'heure actuelle et l'état exact des classes Ingress :

date -u +"%Y-%m-%dT%H:%M:%SZ"
kubectl get ingressclass -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.creationTimestamp}{"\n"}{end}'

Cela vous donne un instantané clair à comparer après toute modification.

Chemin de configuration sécurisé

Maintenant que vous avez une sauvegarde, vous pouvez effectuer des modifications en toute sécurité. Le principe est de faire une modification à la fois, de la tester et d'avoir toujours un plan de restauration.

Créer une nouvelle classe Ingress

Supposons que vous souhaitiez ajouter une nouvelle classe Ingress pour un autre contrôleur. Créez un fichier YAML :

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: traefik
spec:
  controller: traefik.io/ingress-controller

Appliquez-le :

kubectl apply -f traefik-ingressclass.yaml

Vérifiez qu'il a été créé :

kubectl get ingressclass traefik

Mettre à jour une classe Ingress existante

Pour modifier les paramètres d'une classe Ingress existante, modifiez l'objet. Par exemple, pour ajouter un paramètre référençant une ConfigMap pour le contrôleur NGINX :

apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  name: nginx
spec:
  controller: k8s.io/ingress-nginx
  parameters:
    apiGroup: k8s.example.com
    kind: IngressParameters
    name: nginx-params

Appliquez la modification :

kubectl apply -f updated-ingressclass.yaml

Vérifiez toujours que la modification a pris effet :

kubectl describe ingressclass nginx | grep -A2 Parameters

Tester avec un Ingress minimal

Créez un Ingress simple qui utilise la classe Ingress et pointe vers un service de test :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: test.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: echo
            port:
              number: 80

Appliquez et vérifiez que le contrôleur Ingress le prend en compte :

kubectl apply -f test-ingress.yaml
kubectl get ingress test-ingress
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller --tail=50 | grep test.example.com

Les lignes de journal attendues incluent "Adding or updating ingress" pour l'hôte.

Vérification et diagnostics

La vérification ne consiste pas seulement à s'assurer que les ressources existent ; il s'agit de confirmer que le système fonctionne comme prévu.

Vérifier la santé du contrôleur Ingress

Utilisez ces commandes pour vous assurer que le contrôleur Ingress fonctionne correctement :

kubectl get pods -n ingress-nginx -o wide
kubectl describe pod -n ingress-nginx <pod-name>
kubectl logs -n ingress-nginx <pod-name> --tail=20

Vérifiez le statut "Running", les journaux récents et l'absence de crash loops.

Valider les ressources Ingress

Listez toutes les ressources Ingress et vérifiez leur classe :

kubectl get ingress -A
kubectl get ingress -A -o custom-columns=NAME:.metadata.name,CLASS:.spec.ingressClassName

Cela vous aide à confirmer que chaque Ingress pointe vers la bonne classe.

Tester le flux de trafic

Pour un test local, utilisez le port-forwarding :

kubectl port-forward service/echo 8080:80

Ensuite, dans un autre terminal, faites une requête :

curl -H "Host: test.example.com" http://localhost:8080/

Vous devriez voir une réponse du service echo, confirmant que la classe Ingress et le contrôleur fonctionnent.

Utiliser des commandes de diagnostic

En cas de problème, utilisez kubectl describe et kubectl logs pour diagnostiquer. Par exemple, si l'Ingress n'obtient pas d'adresse, vérifiez les événements :

kubectl describe ingress test-ingress

Recherchez des événements comme "Error on ingress ..." ou "Scheduled for sync".

Modes de défaillance et récupération

Même avec une planification minutieuse, des problèmes peuvent survenir. Voici les modes de défaillance courants et comment les résoudre.

Classe Ingress introuvable

Si votre Ingress référence une classe inexistante, le contrôleur peut l'ignorer ou générer une erreur. Vérifiez les événements de l'Ingress :

kubectl describe ingress <name>

Si vous voyez "class nginx not found", restaurez la classe Ingress à partir de votre sauvegarde.

Étapes de récupération manuelle

1. Restaurez la classe Ingress à partir de la sauvegarde :

kubectl apply -f ingressclass-backup.yaml

1. Vérifiez qu'elle existe :

kubectl get ingressclass

1. Réappliquez l'Ingress si nécessaire :

kubectl replace -f test-ingress.yaml

Revenir à une version précédente

Si vous avez modifié une classe Ingress et que cela a causé des problèmes, revenez à la version précédente. Comme les classes Ingress ne sont pas versionnées comme les ConfigMaps, vous devez réappliquer le fichier de sauvegarde. Si vous utilisez le flag --server-side, vous pouvez aussi utiliser kubectl apply --server-side --force-conflicts pour écraser.

Crash du contrôleur

Si le contrôleur Ingress plante, vérifiez ses journaux :

kubectl logs -n ingress-nginx <pod-name> --previous

S'il s'agit d'une boucle de crash, revenez à une version précédente du contrôleur. Si vous avez une configuration GitOps, annulez le commit qui a modifié le contrôleur.

Liste de contrôle opérationnelle

Suivez cette liste de contrôle pour chaque opération sur les classes Ingress.

Avant la modification

• [ ] Vérifiez la version du cluster : kubectl version --short
• [ ] Listez les classes Ingress actuelles : kubectl get ingressclass
• [ ] Prenez une sauvegarde : kubectl get ingressclass -o yaml > backup.yaml
• [ ] Enregistrez les horodatages : date -u +"%Y-%m-%dT%H:%M:%SZ"
• [ ] Identifiez l'impact : quels services sont affectés ?

Pendant la modification

• [ ] Appliquez la modification : kubectl apply -f <fichier>.yaml
• [ ] Vérifiez que la ressource est mise à jour : kubectl describe ingressclass <nom>
• [ ] Testez avec un Ingress factice : appliquez un Ingress de test et vérifiez le trafic

Après la modification

• [ ] Confirmez que le contrôleur Ingress est sain : kubectl get pods -n ingress-nginx
• [ ] Validez que tous les Ingress utilisent la bonne classe : kubectl get ingress -A -o custom-columns=...
• [ ] Mettez à jour votre fichier de sauvegarde avec le nouvel état : kubectl get ingressclass -o yaml > backup.yaml

En cas de problème

• [ ] Ne paniquez pas ; évaluez l'erreur.
• [ ] Restaurez à partir de la sauvegarde : kubectl apply -f backup.yaml
• [ ] Vérifiez les journaux du contrôleur : kubectl logs -n ingress-nginx <pod> --previous
• [ ] Si nécessaire, revenez à une version précédente du déploiement du contrôleur.

Conclusion

La sauvegarde et la restauration des classes Ingress Kubernetes sont des opérations courantes qui peuvent prévenir les temps d'arrêt et la perte de données. En suivant un processus adapté à votre version, observable et réversible, vous pouvez gérer les modifications en toute confiance.

Les points clés sont : inventorier toujours votre environnement, prendre des sauvegardes avant toute modification, effectuer des changements de petite envergure et vérifier chaque résultat avec des commandes concrètes. Utilisez les exemples de cet article comme point de départ et adaptez-les à votre contrôleur et à votre version.

Comme prochaine étape, effectuez un exercice de sauvegarde et de restauration à faible risque dans un cluster de développement. Documentez le processus et partagez-le avec votre équipe. Ainsi, en cas d'incident en production, tout le monde saura exactement quoi faire.