Aller au contenu

Exploitation quotidienne

Pour une procédure transversale complète utilisable sans ChatGPT, agent ou MCP, voir le Manuel opérateur sans IA et ses checklists.

Cette page est le runbook opérateur de base. Toutes les procédures ci-dessous sont exécutables manuellement depuis un poste disposant de kubectl et, pour les commandes de réconciliation explicite, du CLI flux. Elles ne nécessitent ni MCP, ni n8n, ni agent, ni IA.

Règles d'exploitation

  • Git reste la source de vérité de toute configuration Kubernetes durable.
  • kubectl sert au diagnostic et aux actions temporaires d'exploitation : lecture, restart d'un Deployment, lancement ponctuel d'un Job et contrôle de convergence.
  • Ne pas utiliser kubectl edit ou kubectl apply pour corriger durablement un manifeste géré par Flux.
  • Ne jamais supprimer un PVC pour résoudre un problème de pod : cela peut supprimer les données applicatives.
  • Pour CloudNativePG, corriger la cause et laisser l'opérateur gérer les instances PostgreSQL ; ne pas supprimer un PVC ou reconstruire manuellement un primaire.

Vérification rapide

kubectl config current-context
kubectl get nodes -o wide
kubectl top nodes
kubectl get pods -A
kubectl -n flux-system get gitrepositories,kustomizations
kubectl get ingress -A
kubectl get pvc -A

État attendu :

  • les quatre nœuds sont Ready ;
  • les pods applicatifs sont Running ou Completed pour les Jobs terminés ;
  • les redémarrages n'augmentent pas en continu ;
  • les objets Flux convergent vers Ready=True ;
  • les PVC attendus sont Bound.

Un objet Flux False ou Unknown juste après un changement n'est pas à lui seul une preuve d'incident. Vérifier d'abord sa dépendance, sa révision et les événements. Si la révision progresse et les dépendances convergent, laisser Flux terminer sa réconciliation.

K9s

k9s --context ovh-primary

Commandes utiles dans K9s :

  • :nodes : nœuds ;
  • :pods : pods ;
  • :deploy : déploiements ;
  • :ingress : routes ;
  • :events : événements ;
  • / : filtrer ;
  • l : logs ;
  • d : description.

Si K9s affiche une ancienne vue, quitter avec Ctrl+C puis relancer. Comparer avec kubectl get nodes avant toute intervention.

Diagnostiquer un pod

kubectl -n <namespace> describe pod <pod>
kubectl -n <namespace> logs <pod> --all-containers --tail=200
kubectl -n <namespace> get events --sort-by=.lastTimestamp

Pour un CrashLoopBackOff, récupérer aussi les logs du conteneur précédent :

kubectl -n <namespace> logs <pod> -c <container> --previous --tail=200

Pour un pod Pending, contrôler en priorité les événements, les ressources du nœud, les PVC, les taints et les contraintes d'affinité.

Redémarrer proprement une application

Un restart est adapté à un processus bloqué lorsque la configuration déployée est correcte. Il ne remplace pas une correction GitOps.

kubectl -n <namespace> rollout restart deployment/<deployment>
kubectl -n <namespace> rollout status deployment/<deployment> --timeout=2m
kubectl -n <namespace> get pods -o wide

Si le nouveau pod reproduit le problème, arrêter les restarts et diagnostiquer la configuration, la dépendance externe, le stockage ou l'image.

Contrôler Flux

kubectl -n flux-system get gitrepositories,kustomizations
kubectl -n flux-system describe kustomization <nom>
kubectl -n flux-system logs deployment/kustomize-controller --tail=200
kubectl -n flux-system logs deployment/source-controller --tail=200

Si le CLI Flux est installé, une réconciliation manuelle peut être demandée sans modifier les manifests :

flux get sources git -A
flux get kustomizations -A
flux reconcile kustomization <nom> --with-source

Toujours corriger Git lorsqu'un manifeste est faux. Ne pas contourner une dépendance Flux en appliquant son YAML directement au cluster.

Contrôler un déploiement après changement

kubectl -n <namespace> get deployment/<deployment> -o wide
kubectl -n <namespace> rollout status deployment/<deployment> --timeout=2m
kubectl -n <namespace> get replicasets,pods -o wide
kubectl -n <namespace> get events --sort-by=.lastTimestamp

Vérifier ensuite le point d'entrée applicatif avec le navigateur, Gatus ou une requête HTTP adaptée.

Lancer ponctuellement un CronJob

Ne pas activer un CronJob suspendu simplement pour effectuer un test unique. Créer un Job à partir de son template :

kubectl -n <namespace> get cronjob
kubectl -n <namespace> create job --from=cronjob/<cronjob> <job-manuel>
kubectl -n <namespace> logs -f job/<job-manuel>
kubectl -n <namespace> get job/<job-manuel>

Supprimer le Job manuel lorsqu'il n'est plus utile :

kubectl -n <namespace> delete job <job-manuel>

Ingress et TLS

kubectl get ingress -A
kubectl get certificate -A
kubectl get certificaterequest -A
kubectl get challenge,order -A

Pour un certificat en erreur :

kubectl -n <namespace> describe certificate <nom>
kubectl -n <namespace> get events --sort-by=.lastTimestamp

Avant de modifier l'Ingress, vérifier aussi que le DNS public pointe toujours vers l'infrastructure attendue.

Capacité et stockage

kubectl top nodes
kubectl top pods -A --sort-by=memory
kubectl get pvc -A
kubectl get clusters.postgresql.cnpg.io -A

Pour une base CloudNativePG :

kubectl -n <namespace> describe cluster.postgresql.cnpg.io <cluster>
kubectl -n <namespace> get pods -l cnpg.io/cluster=<cluster> -o wide
kubectl -n <namespace> get events --sort-by=.lastTimestamp

Ne jamais supprimer le PVC d'une base pour tenter de la réparer. Les procédures de sauvegarde et de reprise sont décrites dans Sauvegarde et reprise.

n8n

n8n, son OAuth2 Proxy et sa base CloudNativePG sont actuellement localisés sur le worker vps-f0621bb1. L'exploitation manuelle ne dépend pas du Gateway MCP.

kubectl -n n8n get pods,pvc,svc,ingress -o wide
kubectl -n n8n get cluster.postgresql.cnpg.io
# Identifier la cible active depuis spec.template.spec.containers[*].env.DB_POSTGRESDB_HOST
kubectl -n n8n get deployment n8n -o yaml
kubectl -n n8n logs deployment/n8n --tail=200
kubectl -n n8n logs deployment/oauth2-proxy --tail=200

En octobre 2026, le manifeste n8n pointe sur n8n-incident-recovery-rw.n8n.svc.cluster.local. Le cluster n8n-postgresql reste présent comme génération distincte ; ne jamais choisir une cible de reprise uniquement sur son nom ou son état Healthy.

Si le processus n8n est bloqué mais que la base réellement utilisée est saine :

kubectl -n n8n rollout restart deployment/n8n
kubectl -n n8n rollout status deployment/n8n --timeout=2m

Contrôler ensuite https://n8n.lab.djayzone.com. Ne pas supprimer le PVC PostgreSQL. La fiche détaillée est disponible dans n8n.

Plane

kubectl -n plane get pods,deploy,svc,ingress -o wide
kubectl -n plane get events --sort-by=.lastTimestamp

Pour un composant en erreur :

kubectl -n plane logs deployment/<deployment> --all-containers --tail=200
kubectl -n plane describe deployment/<deployment>

Contrôler ensuite https://plane.lab.djayzone.com. Une erreur applicative Plane ne doit pas conduire à modifier directement sa base ou ses PVC.

Monitoring et relais Slack

kubectl -n monitoring get pods -o wide
kubectl -n monitoring get deployment alert-relay
kubectl -n monitoring logs deployment/alert-relay -c relay --tail=200
kubectl -n monitoring get events --sort-by=.lastTimestamp

Si les alertes sont visibles dans Alertmanager mais absentes de #incidents, vérifier le Deployment alert-relay, ses logs et sa connectivité avant toute rotation d'identifiants.

Le bridge Bluelink est privé au cluster et ne possède pas d'Ingress.

kubectl -n bluelink get pods,deploy,svc,cronjob,job -o wide
kubectl -n bluelink logs deployment/bluelink-bridge --tail=200

Validation locale du service :

kubectl -n bluelink port-forward svc/bluelink-bridge 18080:8080

Dans un second terminal :

curl.exe http://127.0.0.1:18080/readyz
curl.exe http://127.0.0.1:18080/v1/vehicle/status
curl.exe http://127.0.0.1:18080/v1/vehicle/capabilities

Les coordonnées GPS exactes sont des données privées d'exploitation. Ne pas copier la sortie de l'endpoint de localisation dans GitHub, Plane, Slack ou un historique de chat. Voir Hyundai Bluelink.

Checklist d'incident simple

  1. Identifier le symptôme et le namespace concerné.
  2. Vérifier les nœuds, les pods et les événements.
  3. Vérifier Flux et la révision réellement appliquée.
  4. Vérifier, selon le cas, Ingress/TLS, Service, Deployment, dépendance externe, stockage ou base de données.
  5. Utiliser un restart uniquement si la configuration déployée est correcte.
  6. Si une correction durable est nécessaire, la faire dans Git puis vérifier la convergence Flux.
  7. Confirmer le retour du service depuis son point d'entrée réel.
  8. Conserver les éléments utiles : heure, ressource, erreur, SHA déployé et action effectuée, sans donnée sensible.

Actions à ne pas improviser

Sans procédure dédiée, ne pas :

  • supprimer un PVC ou un cluster PostgreSQL ;
  • modifier manuellement etcd ;
  • retirer plusieurs membres control-plane simultanément ;
  • désactiver une NetworkPolicy pour contourner un problème ;
  • exposer un service interne par Ingress ;
  • activer des commandes distantes Bluelink non prévues par Git ;
  • forcer un déploiement Kubernetes différent de la source de vérité Git.