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:

kubernetesk8sYAMLDevOpsValidierungAnleitung

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 die 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 Regeln für einzelne Kinds wie Deployment, Service und Ingress. Kombinieren Sie ihn mit dem Kubernetes-Manifest-Formatter für lesbares YAML mit mehreren Dokumenten. Die ganze Werkzeugfamilie liegt im Kubernetes-Hub, einem Schwesterbereich des DevOps-Hubs für Compose, Terraform und Dockerfile.

Abweichungen bei apiVersion/kind und fehlende Metadata vor dem Push erkennen

Prüfungen je Kind: Deployment-Selektoren, Service-Ports, Ingress-pathType

YAML mit mehreren Dokumenten (`---`) wird Dokument für Dokument validiert

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

Grenze von 512 KiB UTF-8, wie bei den anderen Kubernetes-Werkzeugen der Website

Häufige Fehler und Ablauf vor apply

Was die Validierung oft findet

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

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

Selector-Labels eines Deployments, die nicht zu den Labels des Pod-Templates passen

Container ohne `image` nach einem fehlerhaft aufgelösten Merge-Konflikt

Service mit leerem `ports`-Array

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

Benachbarte Konfiguration im selben Projekt

Ein Kubernetes-Rollout kommt selten allein. Validieren Sie die Manifeste und prüfen Sie dann den Image-Build und die IaC, die den Cluster bereitstellt.

Validieren Sie Compose und `.env`, wie in Docker Compose und .env validieren beschrieben

Formatieren Sie das Terraform-HCL desselben Stacks mit Terraform und HCL online

Durchsuchen Sie den Kubernetes-Hub nach Generatoren und Helm-Values

Fügen Sie nie echte Secrets (Tokens, kubeconfig, Secret-Daten) in ein öffentliches Textfeld ein

Behandeln Sie validiertes YAML als Git-Quelle: geprüft, versioniert, per CI angewendet

Validieren, Formatieren, kubeconform und kubectl im Vergleich

Die richtige Schicht wählen

Browser-Validierung, Formatierung, OpenAPI-Schema-Werkzeuge und Cluster-Dry-Runs beantworten verschiedene Fragen. Wer sie vermischt, bekommt 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 und Kind-Regeln, kein vollständiges OpenAPI

minify:Akzeptanz durch Schema oder apiserver, wofür eine CLI oder ein Cluster nötig ist

Empfohlene Reihenfolge

Eine einfache Reihenfolge 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 der CI laufen lassen, wenn Schemas zählen

Auf einen Dev-Namespace anwenden und kurz auf Funktion testen

Halten Sie Helm-Values getrennt und formatieren Sie sie mit Helm-Values formatieren statt mit dem Manifest-Formatter

Wann das Browser-Werkzeug reicht

Typische Szenarien

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

Ein aus Slack eingefügtes Trio aus Deployment, Service und Ingress prüfen

Die Ausgabe von helm template vor dem Öffnen einer PR kurz gegenprüfen

Die Form von Kubernetes-YAML vermitteln, ohne einen Cluster bereitzustellen

Einem Kollegen helfen, der kubectl lokal nicht ausführen kann

Ein Manifest eines Anbieters oder aus einem Tutorial vor der Anpassung schnell vorsortieren

Grenzen des Browser-Werkzeugs und was es nicht ersetzt

kubeconform und `kubectl apply --dry-run`

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

kubeconform mit gepinnter Kubernetes-JSON-Schema-Version

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

CRD-Manifeste: FastMinify meldet für unbekannte Kinds nur einen Hinweis, nicht das vollständige CRD-Schema

Policy-Engines (OPA, Kyverno) liegen außerhalb der strukturellen Validierung

Netzwerkerreichbarkeit, Image-Pull-Secrets und Ressourcenquoten zeigen sich nur zur Laufzeit

Was FastMinify nicht simuliert

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

Keine Prüfung von Querverweisen zwischen `---`-Blöcken

Weder `helm template` noch `kustomize build`: Fügen Sie die gerenderte Ausgabe ein

Keine Standardwerte für den Namespace und keine Merge-Logik des Server-Side-Apply

ConfigMap/Secret mit leerem data → nur eine Warnung (ein Platzhalter ist in Ordnung)

Über 512 KiB UTF-8 wird die Eingabe abgelehnt: Teilen Sie sie auf oder nutzen Sie lokale CLI-Werkzeuge

CLI und Ökosystem

Lokale Referenzwerkzeuge

kubeconform, kubectl und yamllint bleiben der Standard in der CI. FastMinify ergänzt die Erkundung und einmalige Prüfungen.

kubeconform

Validiert Manifeste gegen die OpenAPI-Schemas von Kubernetes (an eine Version gebunden).

Vorteile:

Schema-Fehler mit Kubernetes-Versionskontrolle

Passt in die CI und in Pre-Commit-Hooks

Unterstützt CRDs, wenn Schemas bereitgestellt werden

Nachteile:

Installation und Schema-Download nötig

Weniger praktisch für einen einzelnen eingefügten Ausschnitt

kubectl apply --dry-run=client

Dry-Run auf Clientseite mit lokaler Schema-Validierung (abhängig von der kubectl-Version).

Vorteile:

Auf den meisten Entwicklerrechnern bereits vorhanden

Vertraute Ausgabe für Platform-Teams

Lässt sich mit einem echten Cluster-Dry-Run kombinieren

Nachteile:

Braucht kubectl und oft einen gültigen kubeconfig-Kontext

Dry-Run auf Client- und Serverseite verhalten sich unterschiedlich

yamllint

Generischer YAML-Linter für Einzug und Stil.

Vorteile:

Konfigurierbare Einzugsregeln

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

Integration in Editoren

Nachteile:

Kennt die Semantik von apiVersion/kind nicht

Erkennt keine Abweichungen zwischen Selector und Template

Häufige Manifeste wie 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 diese Paarung. So erwartet Deployment zum Beispiel apps/v1, Service erwartet v1 und Ingress erwartet networking.k8s.io/v1. Veraltete API-Gruppen wie extensions/v1beta1 erzeugen eine Warnung, keinen harten Abbruch.

Dateien mit mehreren Dokumenten: Trennen Sie Ressourcen mit `---`, jedes Dokument wird unabhängig validiert

Kinds, die Kubernetes nicht kennt (CRDs), erhalten die Stufe Information: Strukturregeln werden übersprungen, metadata wird weiter geprüft

Veraltete apiVersion → Warnung mit Hinweis zur GVK-Migration

Leere Eingabe bleibt im Ruhezustand und wird nicht als „gültig“ gemeldet

YAML-Einlesefehler enthalten einen Zeilenhinweis, wenn js-yaml einen liefert

Selector, Template und Container eines Deployments

Ein Deployment braucht ein nicht leeres spec.selector.matchLabels, ein nicht leeres Array spec.template.spec.containers und je Container ein name und ein image. FastMinify prüft auch, dass die Werte von spec.selector.matchLabels zu spec.template.metadata.labels passen. Das ist ein klassischer Copy-Paste-Fehler, der den YAML-Lint besteht, 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

Erzeugen Sie ein Gerüst mit Deployment generieren und validieren Sie es dann

Service-Ports und Ingress-pathType

Ein Service muss ein nicht leeres Array spec.ports deklarieren, und jeder Port braucht port als Zahl oder als IntOrString-String. Ein Ingress mit networking.k8s.io/v1 braucht spec.rules mit http.paths. Jeder Path verlangt 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

Kombinieren Sie Ingress mit Ingress generieren für ein v1-Gerüst

Helm-Values haben eine andere Form: Nutzen Sie Helm-Values formatieren statt des Manifest-Validators

Ein konkreter Ablauf zum Formatieren, Validieren und Generieren

Den Kubernetes-YAML-Validator nutzen

Öffnen Sie Kubernetes validieren, fügen Sie eine .yaml- oder .yml-Datei ein oder laden Sie sie hoch (höchstens 512 KiB) und warten Sie auf das Debounce (~300 ms). Das Ergebnispanel listet Probleme nach Stufe (Fehler, Warnung, Information) mit path, einem optionalen docIndex für Dateien mit mehreren Dokumenten und einer Zeile, wenn vorhanden. Ein Ergebnis Gültig mit Warnungen zeigt trotzdem Probleme an: Lesen Sie die Warnungen vor dem Merge.

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

Layer B: Strukturregeln für die Standardressourcen von Kubernetes

YAML mit mehreren Dokumenten wird unterstützt, und docIndex zeigt, welcher `---`-Block fehlschlug

Es ist weder kubeconform noch die OpenAPI-Beschreibung des API-Servers noch eine Admission-Policy

Alles bleibt lokal, ohne Konto und ohne Cluster-Zugangsdaten

Manifeste vor der Prüfung formatieren

Das Werkzeug Kubernetes formatieren schreibt Manifeste mit mehreren Dokumenten mit js-yaml und 2 oder 4 Leerzeichen Einzug neu. Beim Einfügen, Hochladen oder Laden des Beispiels formatiert es automatisch. Nach einer manuellen Änderung nutzen Sie die Schaltfläche Format (⌘↵). YAML-Kommentare mit # gehen bei der Hin- und Rückkonvertierung verloren: Kopieren Sie sie vorher, wenn Sie sie brauchen.

Das `---` bei mehreren Dokumenten bleibt erhalten, anders als bei generischen Formatierungswerkzeugen für ein einzelnes Dokument

Kommentare bleiben nicht erhalten, mit einer dezenten Warnung, wenn die Eingabe vermutlich welche enthielt

Verketten Sie format → validate für lesbare Diffs und strukturelle Prüfungen

Generisches YAML außerhalb von K8s: YAML verschönern

Compose-Dateien sind keine K8s-Manifeste: Nutzen Sie Docker Compose validieren

Ein Ingress ohne pathType nach einem API-Upgrade

Sie wechseln von networking.k8s.io/v1beta1 zu v1. Das YAML lässt sich weiter einlesen, aber jeder Path braucht ein ausdrückliches pathType. Der Validator meldet invalid_path_type, bevor Sie einen Pipeline-Schritt mit kubectl apply verschwenden.

Eine veraltete apiVersion ergibt eine Warnung: Planen Sie die GVK-Migration

pathType fehlt oder ungültig → Fehler mit Pfad

Erzeugen Sie ein v1-Gerüst mit Ingress generieren, wenn die Datei überwiegend Standardtext enthält

Zuerst formatieren, damit Zeilennummern zum Editor passen

Für CI-YAML im selben Repository siehe GitHub-Actions-Workflow-Lint

Zusammenfassung

Wer die Struktur von Kubernetes-Manifesten vor kubectl apply validiert, spart CI-Minuten für Tippfehler, die der Browser findet. Nutzen Sie FastMinify als schnellen Strukturfilter: formatieren Sie für die Lesbarkeit und validieren Sie dann GVK und Kind-Regeln. Ergänzen Sie kubeconform oder einen Cluster-Dry-Run, wenn es auf das echte Schema ankommt. Weiter geht es im Kubernetes-Hub für Generatoren und Helm-Values und im DevOps-Hub für Compose und Terraform.

Kubernetes-YAML jetzt validieren

Kubernetes validieren Manifeste formatieren Deployment generieren Kubernetes-Hub

Formatieren Sie YAML mit mehreren Dokumenten vor der Prüfung, denn Kommentare gehen beim Formatieren verloren

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

Behandeln Sie Warnungen (veraltete API, leere ConfigMap) als Merge-Blocker, wenn sie relevant sind

Lassen Sie kubeconform oder kubectl dry-run in der CI laufen, wenn das echte Schema zählt

Fügen Sie nie kubeconfig oder Secret-Payloads in ein Online-Werkzeug ein

Teilen Sie diesen Artikel

Teilen Sie diesen Artikel:

Kubernetes-YAML vor `kubectl apply` validieren

Häufige Fehler und Ablauf vor apply

Validieren, Formatieren, kubeconform und kubectl im Vergleich

Tool / Schicht

Was es beweist

Wann das Browser-Werkzeug reicht

Grenzen des Browser-Werkzeugs und was es nicht ersetzt

CLI und Ökosystem

kubeconform

Vorteile:

Nachteile:

kubectl apply --dry-run=client

Vorteile:

Nachteile:

yamllint

Vorteile:

Nachteile:

Häufige Manifeste wie Deployment, Service und Ingress

Vorher

Nachher

Ein konkreter Ablauf zum Formatieren, Validieren und Generieren

Zusammenfassung

Verwandte Artikel