Kubernetes: Validate Deployment, Service and Ingress YAML…

Why validate Kubernetes YAML before `kubectl apply`?

A typo in apiVersion, a Deployment without spec.selector.matchLabels, or an Ingress missing pathType often surfaces only after you push — when CI, a teammate, or the API server rejects the manifest. FastMinify does not run kubectl, does not talk to a cluster, and is not kubeconform. The Kubernetes YAML validator runs structural checks in the browser: Layer A (apiVersion, kind, metadata) plus kind-specific rules for Deployment, Service, Ingress, and more. Pair it with the Kubernetes manifest formatter for readable multi-document YAML. The full cluster lives on the Kubernetes tools hub, sibling to the DevOps hub (Compose, Terraform, Dockerfile).

Catch apiVersion/kind mismatches and missing metadata before a push

Kind-aware checks: Deployment selectors, Service ports, Ingress pathType

Multi-document YAML (`---`) validated document by document

100% in the browser — manifests are not uploaded to a server

512 KiB UTF-8 cap, same as other Kubernetes tools on the site

Common errors and pre-apply workflow

What validation catches often

A few mistakes show up constantly in pasted manifests, Helm output, and tutorial snippets.

apiVersion/kind mismatch (Deployment with `v1` instead of `apps/v1`)

Deployment selector labels not matching pod template labels

Container missing `image` after a bad merge conflict

Service with empty `ports` array

Ingress path without `pathType` after networking v1 migration

Neighbouring config in the same project

A Kubernetes rollout rarely ships alone. Validate manifests, then lint the image build and the IaC that provisions the cluster.

Validate Compose and `.env` — see Docker Compose and .env validation

Format Terraform HCL on the same stack — Terraform and HCL online

Browse the Kubernetes hub for generators and Helm values

Never paste real secrets (tokens, kubeconfig, Secret data) into a public textarea

Treat validated YAML as Git source: reviewed, versioned, applied via CI

Validate vs format vs kubeconform vs kubectl

Pick the right layer

Browser validation, formatting, OpenAPI schema tools, and cluster dry-runs answer different questions. Mixing them up produces a green check here and a red CI job later.

Tool / layer

format:FastMinify format-kubernetes

validate:FastMinify validate-kubernetes

minify:kubeconform / kubectl apply --dry-run

What it proves

format:Readable YAML — not semantic correctness

validate:Structural GVK + kind rules — not full OpenAPI

minify:Schema or apiserver acceptance — needs CLI/cluster

Recommended order

A simple sequence catches most typos before anything touches a cluster.

Format the manifest for consistent indentation

Validate structure in the browser (FastMinify)

Run kubeconform or `kubectl apply --dry-run=client` in CI when schemas matter

Apply to a dev namespace and smoke-test

Keep Helm values separate — format with format Helm values, not the manifest formatter

When the browser tool is enough

Common scenarios

You do not need a cluster or kubeconfig to catch three structural errors on a manifest from a ticket.

Review a Deployment + Service + Ingress trio pasted from Slack

Sanity-check Helm template output before opening a PR

Teach Kubernetes YAML shape without provisioning a cluster

Unblock a teammate who cannot run kubectl locally

Quick filter on a vendor or tutorial manifest before you adapt it

Limits: what the browser does not replace

kubeconform and `kubectl apply --dry-run`

As soon as you need OpenAPI schema validation against a specific Kubernetes version, CRD schemas, or admission webhook policies, CLI tools and the apiserver remain mandatory.

kubeconform with a pinned Kubernetes JSON schema version

`kubectl apply --dry-run=server` against a real apiserver

CRD manifests — FastMinify reports info for unknown kinds, not full CRD schema

Policy engines (OPA, Kyverno) — out of scope for structural validation

Network reachability, image pull secrets, resource quotas — runtime only

What FastMinify does not simulate

The validator reads only the pasted YAML. It does not resolve Helm charts, does not expand Kustomize overlays, and does not validate that a Service name referenced by an Ingress actually exists in another document.

No cross-document reference checks between `---` blocks

No `helm template` or `kustomize build` — paste the rendered output

No namespace defaulting or server-side apply merge logic

ConfigMap/Secret with empty data → warning only (placeholder OK)

Past 512 KiB UTF-8 → input rejected — split or use local CLI tools

CLI and ecosystem

Reference local tools

kubeconform, kubectl, and yamllint remain the standard in CI. FastMinify complements exploration and one-shots.

kubeconform

Validates manifests against Kubernetes OpenAPI schemas (version-pinned).

Pros:

Schema-level errors with Kubernetes version control

Fits CI and pre-commit hooks

Supports CRDs when schemas are provided

Cons:

Requires install and schema download

Less convenient for a single pasted snippet

kubectl apply --dry-run=client

Client-side dry-run using local schema validation (kubectl version dependent).

Pros:

Already on most developer machines

Familiar output for platform teams

Pairs with real cluster dry-run when configured

Cons:

Needs kubectl and often a valid kubeconfig context

Client vs server dry-run behaviour differs

yamllint

Generic YAML linter for indentation and style.

Pros:

Configurable indentation rules

Useful beyond Kubernetes (CI, Ansible…)

Editor integration

Cons:

Unaware of apiVersion/kind semantics

Does not catch selector/template mismatches

Common manifests: Deployment, Service and Ingress

The minimum shape of a Kubernetes document

Every manifest is a YAML mapping with apiVersion, kind, and metadata (name or generateName). FastMinify checks that pairing: for example Deployment expects apps/v1, Service expects v1, Ingress expects networking.k8s.io/v1. Deprecated API groups such as extensions/v1beta1 trigger a warning — not a hard block.

Multi-document files: separate resources with `---` — each doc is validated independently

Unknown kinds (CRDs) → info level — structural rules are skipped, metadata still checked

Deprecated apiVersion → warning with a hint to upgrade the GVK

Empty input stays idle — not reported as “valid”

YAML parse errors include a line hint when js-yaml provides one

Deployment: selector, template and containers

A Deployment needs spec.selector.matchLabels (non-empty), spec.template.spec.containers (non-empty array), and each container needs name and image. FastMinify also checks that spec.selector.matchLabels values match spec.template.metadata.labels — a classic copy-paste mistake that passes YAML lint but breaks at runtime.

Before

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

After

Fix spec.template.metadata.labels.app to match spec.selector.matchLabels.app (both "api").

Missing selector or empty matchLabels → error

Container without name or image → error with path

selector_mismatch when template labels disagree with selector

replicas must be a number when present

Scaffold a starter with generate Deployment, then validate

Service ports and Ingress pathType

A Service must declare a non-empty spec.ports array; each port needs port (number or IntOrString string). An Ingress (networking.k8s.io/v1) needs spec.rules with http.paths, each path requiring path, pathType (Prefix, Exact, or ImplementationSpecific), and backend.service.name plus backend.service.port.number or port.name.

Service without ports → error

Ingress path missing pathType → error (common after v1 migration)

Ingress backend without service name or port → error

Pair Ingress with generate Ingress for a v1 scaffold

Helm values are a different shape — use format Helm values, not the manifest validator

Format, validate, generate: a concrete workflow

Using the Kubernetes YAML validator

Open the validate Kubernetes tool, paste or upload a .yaml / .yml file (max 512 KiB), and wait for debounce (~300 ms). The results panel lists issues by level (error, warning, info) with path, optional docIndex for multi-doc files, and a line when available. Valid with warnings still shows issues — read warnings before you merge.

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

Layer B: kind-specific structural rules for built-in kinds

Multi-document YAML supported — docIndex identifies which `---` block failed

Not kubeconform, not apiserver OpenAPI, not admission policies

Everything stays local — no account, no cluster credentials

Format manifests before review

The format Kubernetes tool pretty-prints multi-document manifests via js-yaml (indent 2 or 4 spaces). Paste, upload, or sample: auto-format; after a manual edit, use the Format button (⌘↵). YAML # comments are dropped on the round-trip — copy them first if you rely on them.

Multi-doc `---` preserved — unlike generic single-doc beautifiers

Comments not preserved — soft warning when input likely had comments

Chain format → validate for readable diffs and structural checks

Generic YAML outside K8s: beautify YAML

Compose files are not K8s manifests — use validate Docker Compose

Scenario — Ingress missing pathType after API upgrade

You upgrade from networking.k8s.io/v1beta1 to v1. The YAML still parses, but every path needs an explicit pathType. The validator flags invalid_path_type before you waste a pipeline step on kubectl apply.

Deprecated apiVersion → warning — plan the GVK migration

pathType missing or invalid → error with path

Regenerate a v1 skeleton with generate Ingress if the file is mostly boilerplate

Format first so line numbers match your editor

For CI YAML in the same repo, see GitHub Actions workflow lint

Conclusion

Validating Kubernetes manifest structure before kubectl apply avoids wasted CI minutes on typos you could catch in the browser. Use FastMinify for a fast structural filter — format for readability, validate for GVK and kind rules — then kubeconform or cluster dry-run when schema truth matters. Continue on the Kubernetes hub for generators, Helm values, and the DevOps cluster for Compose and Terraform.

Validate your Kubernetes YAML now

Format multi-doc YAML before review — comments are dropped on format

Fix apiVersion/kind pairs and selector/template labels early

Treat warnings (deprecated API, empty ConfigMap data) as merge blockers when they matter

Run kubeconform or kubectl dry-run in CI for schema-level truth

Never paste kubeconfig or Secret payloads into an online tool

Kubernetes: Validate Deployment, Service and Ingress YAML Online

Why validate Kubernetes YAML before `kubectl apply`?

Common errors and pre-apply workflow

Validate vs format vs kubeconform vs kubectl

Tool / layer

What it proves

When the browser tool is enough

Limits: what the browser does not replace

CLI and ecosystem

kubeconform

Pros:

Cons:

kubectl apply --dry-run=client

Pros:

Cons:

yamllint

Pros:

Cons:

Common manifests: Deployment, Service and Ingress

Before

After

Format, validate, generate: a concrete workflow

Conclusion

Related Articles