Kubernetes: Deployment-, Service- und Ingress-YAML online validieren

Deployment, Service, Ingress: YAML-Struktur vor `kubectl apply` prüfen — lokal im Browser validieren, ohne Cluster und kubectl.

07.09.2026

7 Min. Lektüre

Teilen Sie diesen Artikel:

kubernetes

k8s

YAML

DevOps

Validierung

Anleitung

Warum Kubernetes-YAML vor `kubectl apply` validieren?

Ein Tippfehler in apiVersion, ein Deployment ohne spec.selector.matchLabels oder ein Ingress ohne pathType fällt oft erst nach dem Push auf — wenn CI, ein Kollege oder der API-Server das Manifest ablehnt. FastMinify führt kein kubectl aus, spricht keinen Cluster an und ist nicht kubeconform. Der Kubernetes-YAML-Validator führt strukturelle Prüfungen im Browser aus: Layer A (apiVersion, kind, metadata) plus kind-spezifische Regeln für Deployment, Service, Ingress und mehr. Kombinieren Sie ihn mit dem Kubernetes-Manifest-Formatter für lesbares Multi-Dokument-YAML. Der vollständige Cluster liegt im Kubernetes-Hub, Schwester des DevOps-Hubs (Compose, Terraform, Dockerfile).

apiVersion/kind-Mismatches und fehlende Metadata vor dem Push erkennen

Kind-bewusste Checks: Deployment-Selektoren, Service-Ports, Ingress-pathType

Multi-Dokument-YAML (`---`) wird Dokument für Dokument validiert

100 % im Browser — Manifeste werden nicht auf einen Server hochgeladen

512 KiB UTF-8 Limit wie bei anderen Kubernetes-Tools auf der Seite

Häufige Fehler und Workflow vor apply

Was die Validierung oft findet

Einige Fehler tauchen ständig in eingefügten Manifesten, Helm-Ausgabe und Tutorial-Snippets auf.

apiVersion/kind-Mismatch (Deployment mit `v1` statt `apps/v1`)

Deployment-Selector-Labels passen nicht zu Pod-Template-Labels

Container ohne `image` nach schlechtem Merge-Konflikt

Service mit leerem `ports`-Array

Ingress-Path ohne `pathType` nach networking-v1-Migration

Nachbar-Config im selben Projekt

Ein Kubernetes-Rollout reist selten allein. Manifeste validieren, dann Image-Build und IaC für den Cluster prüfen.

Compose und `.env` validieren — siehe Docker Compose und .env validieren

Terraform-HCL auf demselben Stack formatieren — Terraform und HCL online

Den Kubernetes-Hub für Generatoren und Helm-Values durchsuchen

Keine echten Secrets (Tokens, kubeconfig, Secret-Daten) in eine öffentliche Textarea einfügen

Validiertes YAML als Git-Quelle behandeln: reviewed, versioniert, per CI angewendet

Validieren vs. formatieren vs. kubeconform vs. kubectl

Die richtige Schicht wählen

Browser-Validierung, Formatierung, OpenAPI-Schema-Tools und Cluster-Dry-Runs beantworten verschiedene Fragen. Sie zu vermischen ergibt hier ein grünes Häkchen und später eine rote CI.

Tool / Schicht

format:FastMinify format-kubernetes

validate:FastMinify validate-kubernetes

minify:kubeconform / kubectl apply --dry-run

Was es beweist

format:Lesbares YAML — keine semantische Korrektheit

validate:Strukturelles GVK + Kind-Regeln — kein vollständiges OpenAPI

minify:Schema oder apiserver-Akzeptanz — braucht CLI/Cluster

Empfohlene Reihenfolge

Eine einfache Sequenz fängt die meisten Tippfehler ab, bevor etwas einen Cluster berührt.

Manifest für konsistenten Einzug formatieren

Struktur im Browser validieren (FastMinify)

kubeconform oder `kubectl apply --dry-run=client` in CI, wenn Schemas zählen

Auf einen Dev-Namespace anwenden und smoke-testen

Helm-Values separat halten — mit Helm-Values formatieren, nicht mit dem Manifest-Formatter

Wann das Browser-Tool reicht

Typische Szenarien

Für drei strukturelle Fehler in einem Ticket-Manifest brauchen Sie keinen Cluster oder kubeconfig.

Deployment + Service + Ingress-Trio aus Slack reviewen

Helm-Template-Ausgabe vor dem PR sanity-checken

Kubernetes-YAML-Form lehren ohne Cluster-Provisionierung

Kollegen entblocken, die kubectl lokal nicht starten können

Schnellfilter auf Vendor- oder Tutorial-Manifest vor der Anpassung

Grenzen: was der Browser nicht ersetzt

kubeconform und `kubectl apply --dry-run`

Sobald Sie OpenAPI-Schema-Validierung gegen eine bestimmte Kubernetes-Version, CRD-Schemas oder Admission-Webhook-Policies brauchen, bleiben CLI-Tools und der apiserver Pflicht.

kubeconform mit gepinnter Kubernetes-JSON-Schema-Version

`kubectl apply --dry-run=server` gegen einen echten apiserver

CRD-Manifeste — FastMinify meldet Info für unbekannte Kinds, kein vollständiges CRD-Schema

Policy-Engines (OPA, Kyverno) — außerhalb struktureller Validierung

Netzwerk, Image-Pull-Secrets, Quotas — nur zur Laufzeit

Was FastMinify nicht simuliert

Der Validator liest nur das eingefügte YAML. Er löst keine Helm-Charts auf, expandiert keine Kustomize-Overlays und prüft nicht, ob ein von einem Ingress referenzierter Service-Name in einem anderen Dokument existiert.

Keine Querverweis-Checks zwischen `---`-Blöcken

Kein `helm template` oder `kustomize build` — gerenderte Ausgabe einfügen

Kein Namespace-Defaulting oder Server-Side-Apply-Merge

ConfigMap/Secret mit leeren data → nur Warnung (Placeholder OK)

Über 512 KiB UTF-8 → Eingabe abgelehnt — teilen oder lokale CLI-Tools nutzen

CLI und Ökosystem

Referenz-Tools lokal

kubeconform, kubectl und yamllint bleiben der Standard in CI. FastMinify ergänzt Exploration und One-Shots.

kubeconform

Validiert Manifeste gegen Kubernetes-OpenAPI-Schemas (versioniert).

Vorteile:

Schema-Fehler mit Kubernetes-Versionskontrolle

Passt in CI und Pre-Commit-Hooks

Unterstützt CRDs, wenn Schemas bereitgestellt werden

Nachteile:

Installation und Schema-Download nötig

Weniger praktisch für ein einzelnes eingefügtes Snippet

kubectl apply --dry-run=client

Client-seitiger Dry-Run mit lokaler Schema-Validierung (kubectl-Version abhängig).

Vorteile:

Auf den meisten Entwicklermaschinen vorhanden

Vertraute Ausgabe für Platform-Teams

Kombinierbar mit echtem Cluster-Dry-Run

Nachteile:

Braucht kubectl und oft gültigen kubeconfig-Kontext

Client- vs. Server-Dry-Run-Verhalten unterschiedlich

yamllint

Generischer YAML-Linter für Einzug und Stil.

Vorteile:

Konfigurierbare Einzugsregeln

Nützlich über Kubernetes hinaus (CI, Ansible…)

Editor-Integration

Nachteile:

Kennt apiVersion/kind-Semantik nicht

Erkennt keine Selector/Template-Mismatches

Häufige Manifeste: Deployment, Service und Ingress

Minimale Form eines Kubernetes-Dokuments

Jedes Manifest ist ein YAML-Mapping mit apiVersion, kind und metadata (name oder generateName). FastMinify prüft die Paarung: z. B. erwartet Deployment apps/v1, Service v1, Ingress networking.k8s.io/v1. Veraltete API-Gruppen wie extensions/v1beta1 erzeugen eine Warnung — keinen harten Block.

Multi-Dokument-Dateien: Ressourcen mit `---` trennen — jedes Dokument wird unabhängig validiert

Unbekannte Kinds (CRDs) → Info-Level — strukturelle Regeln übersprungen, Metadata wird geprüft

Veraltete apiVersion → Warnung mit Hinweis zur GVK-Migration

Leere Eingabe bleibt idle — nicht als „gültig“ gemeldet

YAML-Parse-Fehler mit Zeilenhinweis, wenn js-yaml eine liefert

Deployment: Selector, Template und Container

Ein Deployment braucht spec.selector.matchLabels (nicht leer), spec.template.spec.containers (nicht leeres Array), und jeder Container braucht name und image. FastMinify prüft auch, dass spec.selector.matchLabels mit spec.template.metadata.labels übereinstimmt — ein klassischer Copy-Paste-Fehler, der YAML-Lint passiert, aber zur Laufzeit bricht.

Vorher

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

Nachher

spec.template.metadata.labels.app an spec.selector.matchLabels.app anpassen (beide "api").

Fehlender Selector oder leere matchLabels → Fehler

Container ohne name oder image → Fehler mit Pfad

selector_mismatch wenn Template-Labels nicht zum Selector passen

replicas muss eine Zahl sein, wenn vorhanden

Starter erzeugen mit Deployment generieren, dann validieren

Service-Ports und Ingress-pathType

Ein Service muss ein nicht leeres spec.ports-Array deklarieren; jeder Port braucht port (Zahl oder IntOrString-String). Ein Ingress (networking.k8s.io/v1) braucht spec.rules mit http.paths; jeder Path erfordert path, pathType (Prefix, Exact oder ImplementationSpecific) sowie backend.service.name und backend.service.port.number oder port.name.

Service ohne Ports → Fehler

Ingress-Path ohne pathType → Fehler (häufig nach v1-Migration)

Ingress-Backend ohne Service-Name oder Port → Fehler

Ingress mit Ingress generieren für ein v1-Gerüst kombinieren

Helm-Values haben eine andere Form — Helm-Values formatieren, nicht den Manifest-Validator

Formatieren, validieren, generieren: ein konkreter Workflow

Den Kubernetes-YAML-Validator nutzen

Öffnen Sie Kubernetes validieren, fügen Sie eine .yaml-/.yml-Datei ein oder laden Sie sie hoch (max. 512 KiB) und warten Sie auf das Debounce (~300 ms). Das Ergebnispanel listet Issues nach Level (Fehler, Warnung, Info) mit path, optionalem docIndex für Multi-Doc-Dateien und einer Zeile, wenn verfügbar. Gültig mit Warnungen zeigt trotzdem Issues — vor dem Merge lesen.

Layer A: apiVersion, kind, metadata.name oder generateName

Layer B: kind-spezifische strukturelle Regeln für eingebaute Kinds

Multi-Dokument-YAML unterstützt — docIndex zeigt, welcher `---`-Block fehlschlug

Nicht kubeconform, nicht apiserver-OpenAPI, keine Admission-Policies

Alles bleibt lokal — kein Konto, keine Cluster-Credentials

Manifeste vor dem Review formatieren

Das Tool Kubernetes formatieren pretty-printet Multi-Dokument-Manifeste via js-yaml (Einzug 2 oder 4 Leerzeichen). Einfügen, Upload oder Beispiel: Auto-Format; nach manueller Bearbeitung Format-Button (⌘↵). YAML-#-Kommentare gehen beim Round-Trip verloren — vorher kopieren, wenn Sie darauf angewiesen sind.

Multi-Doc `---` bleibt erhalten — anders als generische Single-Doc-Beautifier

Kommentare nicht erhalten — Soft-Warnung, wenn die Eingabe vermutlich Kommentare hatte

Format → validate für lesbare Diffs und strukturelle Checks

Generisches YAML außerhalb K8s: YAML verschönern

Compose-Dateien sind keine K8s-Manifeste — Docker Compose validieren

Szenario — Ingress ohne pathType nach API-Upgrade

Sie migrieren von networking.k8s.io/v1beta1 zu v1. Das YAML parst noch, aber jeder Path braucht ein explizites pathType. Der Validator meldet invalid_path_type, bevor Sie einen Pipeline-Schritt mit kubectl apply verschwenden.

Veraltete apiVersion → Warnung — GVK-Migration planen

pathType fehlt oder ungültig → Fehler mit Pfad

v1-Skelett mit Ingress generieren, wenn die Datei vor allem Boilerplate ist

Zuerst formatieren, damit Zeilennummern zum Editor passen

Für CI-YAML im selben Repo: GitHub-Actions-Workflow-Lint

Fazit

Die Struktur von Kubernetes-Manifesten vor kubectl apply zu validieren, spart CI-Minuten für Tippfehler, die Sie im Browser fangen können. Nutzen Sie FastMinify als schnellen strukturellen Filter — formatieren für Lesbarkeit, validieren für GVK und Kind-Regeln — dann kubeconform oder Cluster-Dry-Run, wenn Schema-Wahrheit zählt. Weiter im Kubernetes-Hub für Generatoren, Helm-Values und im DevOps-Cluster für Compose und Terraform.

Kubernetes-YAML jetzt validieren

Multi-Doc-YAML vor dem Review formatieren — Kommentare gehen beim Format verloren

apiVersion/kind-Paare und Selector/Template-Labels früh korrigieren

Warnungen (veraltete API, leere ConfigMap) als Merge-Blocker behandeln, wenn relevant

kubeconform oder kubectl dry-run in CI für Schema-Wahrheit

Kein kubeconfig oder Secret-Payloads in ein Online-Tool einfügen

Teilen Sie diesen Artikel

Teilen Sie diesen Artikel:

Kubernetes: Deployment-, Service- und Ingress-YAML online validieren

Warum Kubernetes-YAML vor `kubectl apply` validieren?

Häufige Fehler und Workflow vor apply

Validieren vs. formatieren vs. kubeconform vs. kubectl

Tool / Schicht

Was es beweist

Wann das Browser-Tool reicht

Grenzen: was der Browser nicht ersetzt

CLI und Ökosystem

kubeconform

Vorteile:

Nachteile:

kubectl apply --dry-run=client

Vorteile:

Nachteile:

yamllint

Vorteile:

Nachteile:

Häufige Manifeste: Deployment, Service und Ingress

Vorher

Nachher

Formatieren, validieren, generieren: ein konkreter Workflow

Fazit

Verwandte Artikel