Kubernetes: Validate Deployment, Service and Ingress YAML Online

Deployment, Service, Ingress: structurally validate Kubernetes YAML before `kubectl apply` — browser-local check, no cluster or kubectl required.

07.09.2026

8 min read

Share this article:

kubernetesk8sYAMLDevOpsValidateTutorial

Validating 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 for Compose, Terraform, and Dockerfile.

Catch apiVersion/kind mismatches and missing metadata before a push

Checks per kind: 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

Neighboring 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`, as described in Docker Compose and .env validation

Format Terraform HCL on the same stack with 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 and kind rules, not full OpenAPI

minify:Schema or apiserver acceptance, which needs a CLI or a 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, and format them with format Helm values rather than 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 of the browser tool and what it does not replace

kubeconform and `kubectl apply --dry-run`

You still need CLI tools and the apiserver once you require OpenAPI schema validation against a specific Kubernetes version, CRD schemas, or admission webhook policies.

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 the full CRD schema

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

Network reachability, image pull secrets, and resource quotas only show up at runtime

What FastMinify does not simulate

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

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

No `helm template` or `kustomize build`, so paste the rendered output

No namespace defaulting or server-side apply merge logic

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

Above 512 KiB UTF-8 the input is rejected, so split it 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 and server dry-run behavior 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 such as 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, and 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 `---`, and each document is validated independently

Unknown kinds (CRDs) get info level: structural rules are skipped and metadata is still checked

Deprecated apiVersion → warning with a hint to upgrade the GVK

Empty input stays idle and is not reported as “valid”

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

Deployment selector, template and containers

A Deployment needs a non-empty spec.selector.matchLabels, a non-empty spec.template.spec.containers array, and a name and image on each container. FastMinify also checks that spec.selector.matchLabels values match spec.template.metadata.labels. This is 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, and each port needs port as a number or an IntOrString string. An Ingress on networking.k8s.io/v1 needs spec.rules with http.paths. Each path requires 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 have a different shape, so use format Helm values rather than the manifest validator

A concrete workflow to format, validate, and generate

Using the Kubernetes YAML validator

Open the validate Kubernetes tool, paste or upload a .yaml or .yml file (max 512 KiB), and wait for the short debounce delay (~300 ms). The results panel lists issues by level (error, warning, info) with path, an optional docIndex for multi-document files, and a line when available. A result of Valid with warnings still shows issues, so read the 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 is supported, and docIndex identifies which `---` block failed

Not kubeconform, not apiserver OpenAPI, not admission policies

Everything stays local, with no account and no cluster credentials

Format manifests before review

The format Kubernetes tool rewrites multi-document manifests with js-yaml and a 2 or 4 space indent. Paste, upload, or load the sample, and it formats automatically. After a manual edit, use the Format button (⌘↵). YAML # comments are dropped on the round-trip, so copy them first if you rely on them.

Multi-document `---` is preserved, unlike generic single-document beautifiers

Comments are not preserved, with a soft warning when the 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, so use validate Docker Compose

An Ingress missing pathType after an 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.

A deprecated apiVersion gives a warning, so 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 as a fast structural filter: format for readability, then validate for GVK and kind rules. Add kubeconform or a cluster dry-run when schema truth matters. Continue on the Kubernetes hub for generators and Helm values, and on the DevOps hub for Compose and Terraform.

Validate your Kubernetes YAML now

Validate Kubernetes Format manifests Generate Deployment Kubernetes hub

Format multi-document YAML before review, since 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

Share this article

Share this article:

HTTP/2, HTTP/3 and Minification: Is Minification Still Worth It?

HTTP/2 and HTTP/3 change how files travel, not how big they are. Measured sizes, compile times and bundling tests show what minification still saves.

22.10.202615 min read

Unix Timestamps: Convert Epochs and Avoid Time Zone Mistakes

Convert a Unix epoch to a readable date and back, tell seconds from milliseconds, and avoid time zone, JWT and clock change traps, all in your browser.

19.10.202618 min read

Cron Expressions: Read the Syntax and Calculate the Next Runs

Read a cron expression field by field, check its next runs in UTC or local time and avoid traps with steps, time zones and dialects, all in your browser.

16.10.202618 min read

Validating 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 of the browser tool and what it does not replace

CLI and ecosystem

kubeconform

Pros:

Cons:

kubectl apply --dry-run=client

Pros:

Cons:

yamllint

Pros:

Cons:

Common manifests such as Deployment, Service, and Ingress

Before

After

A concrete workflow to format, validate, and generate

Conclusion

Related Articles