Kubernetes : valider Deployment, Service et Ingress YAML en ligne

Deployment, Service, Ingress : validez la structure YAML avant `kubectl apply` — contrôle local dans le navigateur, sans cluster ni kubectl.

07.09.2026

9 min de lecture

Partager cet article:

kubernetes

k8s

YAML

DevOps

Validation

Tutoriel

Pourquoi valider du YAML Kubernetes avant `kubectl apply` ?

Une faute de frappe dans apiVersion, un Deployment sans spec.selector.matchLabels, ou un Ingress sans pathType apparaît souvent trop tard — quand la CI, un collègue ou l'API server rejette le manifest. FastMinify n'exécute pas kubectl, ne contacte pas un cluster, et n'est pas kubeconform. Le validateur YAML Kubernetes applique des contrôles structurels dans le navigateur : couche A (apiVersion, kind, metadata) plus des règles par kind pour Deployment, Service, Ingress, et d'autres. Couplez-le avec le formateur de manifests Kubernetes pour un YAML multi-documents lisible. Le cluster complet vit sur le hub Kubernetes, voisin du hub DevOps (Compose, Terraform, Dockerfile).

Repérer les incohérences apiVersion/kind et metadata manquantes avant un push

Contrôles par kind : sélecteurs Deployment, ports Service, pathType Ingress

YAML multi-documents (`---`) validé document par document

100 % dans le navigateur — les manifests ne sont pas envoyés sur un serveur

Plafond 512 Kio UTF-8, comme les autres outils Kubernetes du site

Erreurs fréquentes et workflow pré-apply

Ce que la validation attrape souvent

Quelques erreurs reviennent constamment dans les manifests collés, la sortie Helm et les snippets de tutoriels.

Incohérence apiVersion/kind (Deployment avec `v1` au lieu de `apps/v1`)

Labels du selector Deployment ne correspondant pas aux labels du pod template

Container sans `image` après un mauvais merge conflict

Service avec tableau `ports` vide

Path Ingress sans `pathType` après migration networking v1

Config voisine dans le même projet

Un déploiement Kubernetes ne voyage rarement seul. Validez les manifests, puis lintez le build d'image et l'IaC qui provisionne le cluster.

Valider Compose et `.env` — voir validation Docker Compose et .env

Formater le HCL Terraform sur la même stack — Terraform et HCL en ligne

Parcourir le hub Kubernetes pour les générateurs et values Helm

Ne jamais coller de vrais secrets (tokens, kubeconfig, données Secret) dans une textarea publique

Traiter le YAML validé comme source Git : revu, versionné, appliqué via CI

Valider vs formater vs kubeconform vs kubectl

Choisir la bonne couche

Validation navigateur, formatage, outils OpenAPI et dry-runs cluster répondent à des questions différentes. Les confondre produit un check vert ici et une CI rouge ensuite.

Outil / couche

format:FastMinify format-kubernetes

validate:FastMinify validate-kubernetes

minify:kubeconform / kubectl apply --dry-run

Ce que ça prouve

format:YAML lisible — pas la correction sémantique

validate:GVK structurel + règles par kind — pas OpenAPI complet

minify:Schéma ou acceptation apiserver — nécessite CLI/cluster

Ordre recommandé

Une séquence simple attrape la plupart des typos avant tout contact avec un cluster.

Formater le manifest pour une indentation cohérente

Valider la structure dans le navigateur (FastMinify)

Lancer kubeconform ou `kubectl apply --dry-run=client` en CI quand les schémas comptent

Appliquer sur un namespace dev et smoke-tester

Garder les values Helm séparées — formater avec formater Helm values, pas le formateur de manifests

Quand l'outil navigateur suffit

Scénarios courants

Vous n'avez pas besoin d'un cluster ni d'un kubeconfig pour attraper trois erreurs structurelles sur un manifest reçu dans un ticket.

Revoir un trio Deployment + Service + Ingress collé depuis Slack

Sanity-check de la sortie template Helm avant d'ouvrir une PR

Enseigner la forme YAML Kubernetes sans provisionner un cluster

Débloquer un collègue qui ne peut pas lancer kubectl localement

Filtre rapide sur un manifest vendor ou tutoriel avant adaptation

Limites : ce que le navigateur ne remplace pas

kubeconform et `kubectl apply --dry-run`

Dès que vous avez besoin de validation schéma OpenAPI contre une version Kubernetes précise, de schémas CRD, ou de politiques admission webhook, les outils CLI et l'apiserver restent obligatoires.

kubeconform avec une version de schéma JSON Kubernetes épinglée

`kubectl apply --dry-run=server` contre un vrai apiserver

Manifests CRD — FastMinify signale info pour kinds inconnus, pas le schéma CRD complet

Moteurs de politique (OPA, Kyverno) — hors périmètre de la validation structurelle

Connectivité réseau, image pull secrets, quotas — runtime uniquement

Ce que FastMinify ne simule pas

Le validateur lit uniquement le YAML collé. Il ne résout pas les charts Helm, n'expand pas les overlays Kustomize, et ne valide pas que le nom de Service référencé par un Ingress existe dans un autre document.

Pas de contrôles de références croisées entre blocs `---`

Pas de `helm template` ni `kustomize build` — collez la sortie rendue

Pas de defaulting namespace ni logique server-side apply

ConfigMap/Secret avec data vide → avertissement seulement (placeholder OK)

Au-delà de 512 Kio UTF-8 → entrée rejetée — découpez ou utilisez des outils CLI locaux

CLI et écosystème

Outils locaux de référence

kubeconform, kubectl et yamllint restent la norme en CI. FastMinify complète l'exploration et les one-shots.

kubeconform

Valide les manifests contre les schémas OpenAPI Kubernetes (version épinglée).

Avantages :

Erreurs au niveau schéma avec contrôle de version Kubernetes

S'intègre en CI et pre-commit

Supporte les CRD quand les schémas sont fournis

Inconvénients :

Nécessite installation et téléchargement de schémas

Moins pratique pour un snippet collé unique

kubectl apply --dry-run=client

Dry-run côté client avec validation schéma locale (dépend de la version kubectl).

Avantages :

Déjà présent sur la plupart des machines dev

Sortie familière pour les équipes plateforme

Se combine avec un dry-run cluster quand configuré

Inconvénients :

Nécessite kubectl et souvent un contexte kubeconfig valide

Comportement client vs server dry-run différent

yamllint

Linter YAML générique pour indentation et style.

Avantages :

Règles d'indentation configurables

Utile au-delà de Kubernetes (CI, Ansible…)

Intégration éditeur

Inconvénients :

Ignore la sémantique apiVersion/kind

Ne détecte pas les incohérences selector/template

Manifests courants : Deployment, Service et Ingress

Forme minimale d'un document Kubernetes

Chaque manifest est un mapping YAML avec apiVersion, kind et metadata (name ou generateName). FastMinify vérifie l'appariement : par exemple Deployment attend apps/v1, Service attend v1, Ingress attend networking.k8s.io/v1. Les groupes d'API dépréciés comme extensions/v1beta1 déclenchent un avertissement — pas un blocage dur.

Fichiers multi-documents : séparer les ressources avec `---` — chaque doc est validé indépendamment

Kinds inconnus (CRD) → niveau info — règles structurelles ignorées, metadata toujours contrôlée

apiVersion dépréciée → avertissement avec indication de migrer le GVK

Entrée vide reste idle — pas signalée comme « valide »

Erreurs de parse YAML avec indication de ligne quand js-yaml la fournit

Deployment : selector, template et containers

Un Deployment nécessite spec.selector.matchLabels (non vide), spec.template.spec.containers (tableau non vide), et chaque container doit avoir name et image. FastMinify vérifie aussi que les valeurs de spec.selector.matchLabels correspondent à spec.template.metadata.labels — une erreur classique de copier-coller qui passe le lint YAML mais casse en production.

Avant

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api-wrong
    spec:
      containers:
        - name: api
          image: myapp:1.0

Après

Corrigez spec.template.metadata.labels.app pour qu'il corresponde à spec.selector.matchLabels.app (les deux "api").

Selector manquant ou matchLabels vide → erreur

Container sans name ou image → erreur avec chemin

selector_mismatch quand les labels du template ne correspondent pas au selector

replicas doit être un nombre quand présent

Générez un starter avec générer Deployment, puis validez

Ports Service et pathType Ingress

Un Service doit déclarer un tableau spec.ports non vide ; chaque port nécessite port (nombre ou chaîne IntOrString). Un Ingress (networking.k8s.io/v1) nécessite spec.rules avec http.paths, chaque path exigeant path, pathType (Prefix, Exact ou ImplementationSpecific), et backend.service.name plus backend.service.port.number ou port.name.

Service sans ports → erreur

Path Ingress sans pathType → erreur (fréquent après migration v1)

Backend Ingress sans nom de service ou port → erreur

Associez Ingress avec générer Ingress pour un scaffold v1

Les values Helm ont une autre forme — utilisez formater Helm values, pas le validateur de manifests

Formater, valider, générer : un workflow concret

Utiliser le validateur YAML Kubernetes

Ouvrez l'outil valider Kubernetes, collez ou uploadez un fichier .yaml / .yml (max 512 Kio), et attendez le debounce (~300 ms). Le panneau de résultats liste les issues par niveau (erreur, avertissement, info) avec path, docIndex optionnel pour les fichiers multi-doc, et une ligne quand disponible. Valide avec avertissements affiche quand même les issues — lisez-les avant de merger.

Couche A : apiVersion, kind, metadata.name ou generateName

Couche B : règles structurelles par kind pour les kinds intégrés

YAML multi-documents supporté — docIndex identifie quel bloc `---` a échoué

Pas kubeconform, pas OpenAPI apiserver, pas de politiques d'admission

Tout reste local — pas de compte, pas d'identifiants cluster

Formater les manifests avant review

L'outil formater Kubernetes met en forme des manifests multi-documents via js-yaml (indent 2 ou 4 espaces). Collage, upload ou exemple : auto-format ; après édition manuelle, bouton Formater (⌘↵). Les commentaires YAML # sont perdus au round-trip — copiez-les d'abord si vous en dépendez.

Multi-doc `---` préservé — contrairement aux beautifiers génériques mono-doc

Commentaires non préservés — avertissement soft si l'entrée en contenait probablement

Enchaînez format → validate pour des diffs lisibles et des contrôles structurels

YAML générique hors K8s : beautify YAML

Les fichiers Compose ne sont pas des manifests K8s — utilisez valider Docker Compose

Scénario — Ingress sans pathType après upgrade d'API

Vous migrez de networking.k8s.io/v1beta1 vers v1. Le YAML parse encore, mais chaque path nécessite un pathType explicite. Le validateur signale invalid_path_type avant de gaspiller une étape de pipeline sur kubectl apply.

apiVersion dépréciée → avertissement — planifiez la migration GVK

pathType manquant ou invalide → erreur avec chemin

Régénérez un squelette v1 avec générer Ingress si le fichier est surtout du boilerplate

Formatez d'abord pour que les numéros de ligne correspondent à votre éditeur

Pour du YAML CI dans le même dépôt, voir linter workflow GitHub Actions

Conclusion

Valider la structure des manifests Kubernetes avant kubectl apply évite de gaspiller des minutes de CI sur des typos attrapables dans le navigateur. Utilisez FastMinify comme filtre structurel rapide — formater pour la lisibilité, valider pour GVK et règles par kind — puis kubeconform ou dry-run cluster quand la vérité schéma compte. Continuez sur le hub Kubernetes pour les générateurs, values Helm, et le cluster DevOps pour Compose et Terraform.

Validez votre YAML Kubernetes maintenant

Formater le YAML multi-doc avant review — les commentaires sont perdus au format

Corriger tôt les paires apiVersion/kind et labels selector/template

Traiter les avertissements (API dépréciée, ConfigMap vide) comme bloquants merge quand ils comptent

Lancer kubeconform ou kubectl dry-run en CI pour la vérité schéma

Ne jamais coller kubeconfig ou payloads Secret dans un outil en ligne

Partager cet article

Partager cet article:

Articles connexes

FastMinify : la plateforme d'outils dev en ligne (minify, DevOps, API, SVG, IA/LLM)

Tour d'horizon des clusters FastMinify, intentions SEO et workflows — minify, DevOps, API et SVG dans le navigateur, sans compte.

04.09.20268 min de lecture

Déminifier JS et CSS : déboguer du code minifié en production

Source maps absentes : retrouvez du JS et du CSS lisibles dans le navigateur avec unminify et beautify — formatage seul, noms mangled perdus.

02.09.202611 min de lecture

PHP unserialize : décoder options WordPress et données sérialisées

Désérialisez `wp_postmeta`, sessions PHP et caches Laravel en JSON lisible dans le navigateur — tableaux et scalaires uniquement, sans script local.

31.08.202610 min de lecture