kubeval: Manifest Validation (Deprecated)
kubeval validated Kubernetes manifests against JSON schemas, but it is no longer maintained; kubeconform is the drop-in replacement for new pipelines.
You will still see kubeval in older pipelines. It works, but the project is archived and its schema store lags new Kubernetes releases. If you are wiring up a check today, use kubeconform; this page covers kubeval for maintaining legacy jobs.
What it does
kubeval reads Kubernetes manifests and validates each resource against the JSON schema for its apiVersion and kind. --strict rejects unknown fields. It is functionally similar to kubeconform but is deprecated and its bundled schemas stop at older Kubernetes versions.
Common usage
# legacy validation
kubeval --strict deployment.yaml
# target a specific k8s version
kubeval --strict --kubernetes-version 1.22.0 deployment.yaml
# the modern replacement
kubeconform -summary -strict deployment.yamlOptions
| Flag | What it does |
|---|---|
| --strict | Disallow additional properties not in the schema |
| --kubernetes-version <v> | API version to validate against |
| --ignore-missing-schemas | Skip resources with no schema instead of failing |
| --schema-location <url> | Base URL/path for the JSON schema store |
| -o, --output <fmt> | Output format: stdout, json, tap |
Migration and CI
kubeval is archived; migrate to kubeconform, which keeps almost the same flags (-strict, -kubernetes-version, -schema-location, -ignore-missing-schemas) and is faster and multi-schema aware. Most CI steps convert by swapping the binary name and changing --flag to -flag. New Kubernetes kinds may have no kubeval schema at all, which alone is a reason to switch.
Common errors in CI
"Failed initializing schemas: Could not read schema" often means kubeval is trying to fetch a schema for a Kubernetes version its store never shipped. "Additional property ... is not allowed" is the --strict rejection of an unknown field. "command not found: kubeval" on newer runner images reflects the tool being dropped; install it explicitly or move to kubeconform.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes