# kubeval: Validate Manifests (Legacy)

> kubeval validates Kubernetes manifests against JSON schemas. Reference for --strict, --kubernetes-version, and a note that kubeconform is its maintained successor.

Source: https://latchkey.dev/learn/command-reference/kubeval-validate  
Updated: 2026-06-30

kubeval <files> validates manifests against bundled Kubernetes JSON schemas; it is now unmaintained, with kubeconform as the recommended replacement.

kubeval pioneered offline manifest validation and still appears in older pipelines. It works, but it is no longer maintained, so new pipelines should reach for kubeconform.

## What it does

kubeval reads each manifest, looks up the schema for its apiVersion/kind, and reports whether the resource conforms. It is structural validation only, with no cluster contact, much like kubeconform.

## Common usage

```Terminal
kubeval deployment.yaml
kubeval --strict --kubernetes-version 1.18.0 manifests/*.yaml
cat manifest.yaml | kubeval
```

## Options

| Flag | What it does |
| --- | --- |
| --strict | Disallow additional properties (catch typos) |
| --kubernetes-version | Schema version to validate against |
| --ignore-missing-schemas | Skip kinds without a schema instead of failing |
| --skip-kinds | Comma-separated kinds to skip |
| -o, --output | Output format: stdout, json, tap |

## Deprecation note

kubeval is archived and its schema set lags behind current Kubernetes releases, so newer apiVersions may report `could not find schema`. Migrate to kubeconform: the flags map closely (`--strict` to `-strict`, `--kubernetes-version` to `-kubernetes-version`), and it tracks current schemas and runs faster.

## Common errors in CI

`Failed initializing schema ... could not find schema for <Kind>` is common on recent apiVersions because kubeval is unmaintained; this alone is a reason to switch to kubeconform. `The document ... contains an invalid <Kind>` lists the specific schema violation. `--ignore-missing-schemas` quiets missing-schema failures but hides genuinely unknown kinds.

## 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.

```Terminal
# 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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubeval: Validate Manifests (Legacy)?

kubeval pioneered offline manifest validation and still appears in older pipelines. It works, but it is no longer maintained, so new pipelines should reach for kubeconform.

### What it does?

kubeval reads each manifest, looks up the schema for its apiVersion/kind, and reports whether the resource conforms. It is structural validation only, with no cluster contact, much like kubeconform.

### Deprecation note?

kubeval is archived and its schema set lags behind current Kubernetes releases, so newer apiVersions may report could not find schema. Migrate to kubeconform: the flags map closely (--strict to -strict, --kubernetes-version to -kubernetes-version), and it tracks current schemas and runs faster.

### Common errors in CI?

Failed initializing schema ... could not find schema for <Kind> is common on recent apiVersions because kubeval is unmaintained; this alone is a reason to switch to kubeconform. The document ... contains an invalid <Kind> lists the specific schema violation.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt