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:

kubernetesk8sYAMLDevOpsValidationTutoriel

Valider du YAML Kubernetes avant `kubectl apply`

Une faute de frappe dans apiVersion, un Deployment sans spec.selector.matchLabels ou un Ingress sans pathType n'apparaît souvent qu'après le push, quand la CI, un collègue ou l'API server rejette le manifeste. FastMinify n'exécute pas kubectl, ne contacte pas de cluster et n'est pas kubeconform. Le validateur YAML Kubernetes applique des contrôles structurels dans le navigateur : la couche A (apiVersion, kind, metadata) plus des règles propres à chaque kind pour Deployment, Service, Ingress et d'autres. Associez-le au formateur de manifests Kubernetes pour un YAML de plusieurs documents lisible. Toute la famille d'outils se trouve sur le hub Kubernetes, voisin du hub DevOps pour Compose, Terraform et Dockerfile.

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

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

YAML de plusieurs documents (`---`) validé document par document

100 % dans le navigateur : les manifests ne sont pas envoyés à un serveur

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

Erreurs fréquentes et enchaînement avant apply

Ce que la validation repère souvent

Quelques erreurs reviennent sans cesse dans les manifests collés, la sortie de Helm et les extraits de tutoriels.

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

Labels du selector d'un Deployment qui ne correspondent pas à ceux du pod template

Container sans `image` après un mauvais conflit de fusion

Service avec tableau `ports` vide

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

La configuration voisine dans le même projet

Un déploiement Kubernetes voyage rarement seul. Commencez par valider les manifests, puis passez le lint sur le build de l'image et sur l'IaC qui provisionne le cluster.

Validez Compose et `.env`, comme décrit dans validation Docker Compose et .env

Formatez le HCL Terraform de la même pile avec Terraform et HCL en ligne

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

Ne collez jamais de vrais secrets (tokens, kubeconfig, données de Secret) dans une zone de texte publique

Traitez le YAML validé comme une source Git : relu, versionné, appliqué via la CI

Les différences entre valider, formater, kubeconform et kubectl

Choisir la bonne couche

La validation dans le navigateur, le formatage, les outils de schéma OpenAPI et les dry-runs sur un cluster répondent à des questions différentes. Les confondre donne une coche verte 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:Un YAML lisible, pas une correction sémantique

validate:GVK structurel et règles par kind, pas OpenAPI complet

minify:Acceptation par le schéma ou l'apiserver, ce qui demande une CLI ou un cluster

Ordre recommandé

Une séquence simple repère la plupart des fautes de frappe avant tout contact avec un cluster.

Formater le manifeste 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 de dev et lancer un test de fumée

Gardez les values Helm à part et formatez-les avec formater Helm values plutôt qu'avec le formateur de manifests

Quand l'outil du navigateur suffit

Scénarios courants

Vous n'avez pas besoin d'un cluster ni d'un kubeconfig pour repérer trois erreurs structurelles dans un manifeste reçu par ticket.

Relire un trio Deployment, Service et Ingress collé depuis Slack

Faire une vérification rapide de la sortie de helm template avant d'ouvrir une PR

Enseigner la forme du YAML Kubernetes sans mettre en place de cluster

Dépanner un collègue qui ne peut pas lancer kubectl en local

Faire un tri rapide sur un manifeste de fournisseur ou de tutoriel avant de l'adapter

Les limites de l'outil du navigateur et ce qu'il ne remplace pas

kubeconform et `kubectl apply --dry-run`

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

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 les kinds inconnus, pas le schéma CRD complet

Les moteurs de politique (OPA, Kyverno) sont hors périmètre de la validation structurelle

La connectivité réseau, les image pull secrets et les quotas de ressources ne se voient qu'à l'exécution

Ce que FastMinify ne simule pas

Le validateur ne lit que le YAML collé. Il ne résout pas les charts Helm et ne déplie pas les overlays Kustomize. Il ne vérifie pas non plus que le nom de Service référencé par un Ingress existe dans un autre document.

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

Pas de `helm template` et pas de `kustomize build` : collez la sortie rendue

Aucune valeur par défaut de namespace ni logique de fusion du server-side apply

ConfigMap/Secret avec data vide → simple avertissement (un espace réservé est accepté)

Au-delà de 512 Kio UTF-8, l'entrée est rejetée : découpez-la 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 usages ponctuels.

kubeconform

Contrôle des manifests contre les schémas OpenAPI de Kubernetes (version épinglée).

Avantages :

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

S'intègre à la CI et aux hooks pre-commit

Prend en charge les CRD quand les schémas sont fournis

Inconvénients :

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

Moins pratique pour un seul extrait collé

kubectl apply --dry-run=client

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

Avantages :

Déjà présent sur la plupart des postes de développement

Sortie familière pour les équipes plateforme

Se combine avec un dry-run sur un vrai cluster quand il est configuré

Inconvénients :

Nécessite kubectl et souvent un contexte kubeconfig valide

Le dry-run côté client et celui côté serveur se comportent différemment

yamllint

Linter YAML générique pour l'indentation et le style.

Avantages :

Règles d'indentation configurables

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

Intégration aux éditeurs

Inconvénients :

Ignore la sémantique d'apiVersion/kind

Ne détecte pas les écarts entre selector et template

Les manifests courants comme Deployment, Service et Ingress

Forme minimale d'un document Kubernetes

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

Fichiers de plusieurs documents : séparez les ressources avec `---`, et chaque document est validé indépendamment

Les kinds inconnus (CRD) sont signalés au niveau info : les règles structurelles sont ignorées et metadata reste contrôlée

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

Une entrée vide reste au repos et n'est pas signalée comme « valide »

Les erreurs d'analyse YAML indiquent la ligne quand js-yaml la fournit

Le selector, le template et les containers d'un Deployment

Un Deployment nécessite un spec.selector.matchLabels non vide, un tableau spec.template.spec.containers 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. C'est une erreur classique de copier-coller qui passe le lint YAML mais casse à l'exécution.

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 le chemin

selector_mismatch quand les labels du template ne correspondent pas au selector

replicas doit être un nombre quand présent

Créez un squelette avec générer Deployment, puis validez

Ports Service et pathType Ingress

Un Service doit déclarer un tableau spec.ports non vide, et chaque port nécessite port sous forme de nombre ou de chaîne IntOrString. Un Ingress en networking.k8s.io/v1 nécessite spec.rules avec http.paths. Chaque path exige 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 à générer Ingress pour obtenir un squelette v1

Les values Helm ont une autre forme : utilisez formater Helm values plutôt que le validateur de manifests

Un enchaînement concret pour formater, valider et générer

Utiliser le validateur YAML Kubernetes

Ouvrez valider Kubernetes, collez ou importez un fichier .yaml ou .yml (512 Kio au plus) et attendez le debounce (~300 ms). Le panneau de résultats liste les problèmes par niveau (erreur, avertissement, info), avec path, un docIndex facultatif pour les fichiers de plusieurs documents et une ligne quand elle existe. Un résultat Valide avec avertissements affiche quand même des problèmes : lisez les avertissements avant la fusion.

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

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

Le YAML de plusieurs documents est pris en charge, et docIndex indique quel bloc `---` a échoué

Ce n'est ni kubeconform, ni l'OpenAPI de l'apiserver, ni des politiques d'admission

Tout reste local, sans compte et sans identifiants de cluster

Formater les manifests avant la relecture

L'outil de formatage (formater Kubernetes) réécrit les manifests de plusieurs documents avec js-yaml et une indentation de 2 ou 4 espaces. Collez, importez ou chargez l'exemple, et le formatage se fait tout seul. Après une modification manuelle, utilisez le bouton Formater (⌘↵). Les commentaires YAML # sont perdus à l'aller-retour : copiez-les d'abord si vous en avez besoin.

Le `---` de plusieurs documents est conservé, contrairement aux formateurs YAML génériques qui ne gèrent qu'un document

Les commentaires ne sont pas conservés, avec un avertissement discret quand 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

Un Ingress sans pathType après une mise à jour de l'API

Vous passez de networking.k8s.io/v1beta1 à v1. Le YAML s'analyse encore, mais chaque path nécessite un pathType explicite. Le validateur signale invalid_path_type avant que vous ne gaspilliez une étape de pipeline sur kubectl apply.

Une apiVersion dépréciée donne un avertissement : planifiez la migration du GVK

pathType manquant ou invalide → erreur avec le chemin

Régénérez un squelette v1 avec générer Ingress si le fichier est surtout du code répétitif

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

Pour du YAML de 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 fautes de frappe que le navigateur peut repérer. Utilisez FastMinify comme filtre structurel rapide : formatez pour la lisibilité, puis validez le GVK et les règles par kind. Ajoutez kubeconform ou un dry-run sur un cluster quand la conformité au schéma compte. Poursuivez sur le hub Kubernetes pour les générateurs et les values Helm, et sur le hub DevOps pour Compose et Terraform.

Validez maintenant votre YAML Kubernetes

Valider Kubernetes Formater les manifests Générer Deployment Hub Kubernetes

Formatez le YAML de plusieurs documents avant la relecture : les commentaires sont perdus au formatage

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

Traitez les avertissements (API dépréciée, ConfigMap vide) comme des bloqueurs de fusion quand ils comptent

Lancez kubeconform ou kubectl dry-run en CI pour la conformité exacte au schéma

Ne collez jamais de kubeconfig ni de payloads Secret dans un outil en ligne

Partager cet article

Partager cet article:

Articles connexes

HTTP/2, HTTP/3 et minification : la minification est-elle encore utile ?

HTTP/2 et HTTP/3 changent le trajet des fichiers, pas leur poids. Mesures de taille, de compilation et de bundling : ce que la minification apporte encore.

22.10.202617 min de lecture

Timestamp Unix : convertir un epoch et éviter les erreurs de fuseau

Convertissez un epoch Unix en date lisible et inversement, distinguez secondes et millisecondes, et évitez les pièges de fuseau, de JWT et de changement d’heure.

19.10.202620 min de lecture

Expression cron : lire la syntaxe et calculer les prochaines exécutions

Lisez une expression cron champ par champ, voyez ses prochaines exécutions en UTC ou en heure locale et évitez les pièges de pas, de fuseau et de dialecte.

16.10.202619 min de lecture