Ce que fait ce validateur
Les manifests Kubernetes ressemblent à du YAML normal, mais la vraie validation vit dans le cluster : `kubectl apply` accepte un fichier et seulement plus tard, après que l'API server le résout contre le schéma live et les admission controllers, vous découvrez que quelque chose ne va pas. À ce moment-là vous avez peut-être un Deployment mal configuré qui tourne en production sans liveness probe, sans resource limits, et un Service qui ne route pas vraiment vers ses pods parce que le label selector ne matche pas.
Cet outil attrape les 30 erreurs principales avant que vous appliquiez. Collez n'importe quel manifest K8s, fichiers multi-documents avec séparateurs `---` inclus. Le validateur parse chaque document, détecte le kind, et lance des vérifs écrites à la main : `apiVersion` ou `metadata.name` manquant, Service `targetPort` qui n'existe pas sur le pod, Deployment selector qui ne matche pas les labels de pod, conteneurs `privileged: true`, tags `:latest`, resource limits et probes manquants, Ingress sur une version API dépréciée, PVC sans taille de stockage.
Tout tourne dans votre navigateur. Pas d'upload, pas de kubectl, pas de contact cluster. Le validateur ne pulle pas les schémas CRD live (ils vivent dans votre cluster spécifique), les ressources custom apparaissent donc seulement en info.
Mode d'emploi
- Choisissez un exemple en haut pour voir à quoi la sortie ressemble, ou collez votre propre YAML dans le panneau d'entrée. Le validateur gère les fichiers multi-documents avec séparateurs `---`.
- Lisez les compteurs erreur / avertissement / info sur la droite. Erreurs signifient que le manifest sera rejeté par l'API server ou se comportera cassé (champs manquants, selectors qui ne matchent pas, HPA invalide). Avertissements sont des violations de bonnes pratiques (tag `:latest`, pas de resource limits, `privileged: true`). Les items Info sont des suggestions.
- Chaque issue liste le kind, le nom de ressource, l'index de document (quel manifest dans un fichier multi-doc), le message, et un indice de fix.
- Fixes courants couverts : ajouter liveness/readiness probes, régler les resource requests et limits, retirer hostPort, remplacer `:latest` par un tag épinglé, aligner selector matchLabels avec template metadata.labels, régler HPA scaleTargetRef et une plage de réplicas min/max valide.
- Pour les Services, le validateur cross-check que le `targetPort` existe vraiment comme `containerPort` sur le pod sélectionné par `spec.selector`. Ça attrape la classique erreur d'un Service qui route silencieusement vers rien.
- Quand l'entrée est vide ou que le parsing YAML échoue, vous obtenez une erreur de parse avec le numéro de ligne de js-yaml. Corrigez ça d'abord et le reste des vérifs s'allume.
- Cliquez sur Copier pour mettre le manifest dans votre presse-papiers, puis mettez-le dans `kubectl apply -f -` pour réellement déployer. Le validateur n'envoie jamais votre YAML nulle part.
Quand cet outil est utile
Sept situations concrètes où attraper les erreurs K8s avant kubectl apply économise du vrai downtime :
- Première fois à toucher K8s. La doc officielle est énorme et vous n'avez pas encore l'intuition pour quels champs sont obligatoires. Le validateur flague `apiVersion`, `kind`, `metadata.name` manquants immédiatement et donne un indice de fix pour chacun.
- Service qui se connecte à rien. La classique erreur : Service selector dit `app: web`, labels de template Deployment disent `app: api`. K8s crée le Service, le Service n'a pas d'endpoints, le trafic 503. Le validateur dit exactement quelles clés ne matchent pas.
- Gate pre-commit pour les repos K8s. Branchez la vérif de sortie du validateur dans votre process de review. Les PRs qui introduisent `privileged: true`, `:latest`, limits manquants, probes manquants sont flagués avant merge.
- Vérif de santé d'un repo GitOps. Un repo avec des centaines de manifests est dur à auditer à l'œil. Collez un fichier, voyez toutes les issues d'un coup. Répétez par fichier ou câblez dans CI à la main.
- Migration de Ingress extensions/v1beta1 vers networking.k8s.io/v1. Le validateur flague l'ancienne version d'API avec un fix d'une ligne. Économise un déploiement qui 404 au prochain upgrade de cluster.
- CronJob sans limits qui tourne sur un petit node. Un backup nocturne sans memory limit peut OOM le node. Le validateur avertit pour chaque conteneur sans limits.
- HPA mal configuré pour ne scaler qu'entre 1 et 1. La vérif attrape `minReplicas >= maxReplicas` (qui est invalide) et `scaleTargetRef` manquant (qui fait que le HPA ne fait rien).