kubectl-validate is a SIG-CLI subproject to support the local validation of resources for native Kubernetes types and CRDs.
This project has two goals:
1.) Shift-left validation of resources with as close to parity to server-side Kubernetes as possible. 2.) Improve declarative validation support in upstream Kubernetes over time, making those improvements available for kubectl-validate users early.
kubectl-validate
distinguishes itself among other OpenAPI-based validators by
to its deep integration with Kubernetes upstream validation. kubectl-validate
is written by Kubernetes apiserver authors using the same code as the server-side.
This allows kubectl-validate
to give the most accurate error messages and support
the Kubernetes-specific validations often ignored by other tools.
kubectl-validate
suffers from similar drawbacks to other OpenAPI-based validation tools.
For CRDs, users should expect a first-class experience likely identical to how the server treats CRDs.
For Native Types, the OpenAPI definitions are a best-effort replication of the handwritten validation rules conducted by the apiserver. There is an ongoing effort to improve the quality of native types' definitions, and eventually replace the handwritten rules. As the improvements are made upstream, kubectl-validate will integrate them to make them available to all users.
Bottom line is that users should expect nearly a seamless experience with CRDs, and great but constantly improving support for the built-in Kubernetes types.
You can get started using kubectl-validate right away with an existing installation of Go:
go install sigs.k8s.io/kubectl-validate@latest
Once installed, you have the option of invoking kubectl-validate
through
kubectl
or directly:
kubectl validate ./path/to/file.yaml
is equivalent to
kubectl-validate ./path/to/file.yaml
Native types can be validated out of the box with kubectl-validate
. The tool
has built-in schemas for Kubernetes 1.23-1.27 which are kept up to date with releases.
By default, the tool will validate native types with the latest built-in version it ships with. You can specify a specific Kubernetes version to validate against using the version argument:
kubectl validate ./my_pod.yaml --version 1.27
If the version is not recognized, kubectl-validate
will attempt to look up
the schemas for the selected version in the official upstream Kubernetes repository
on GitHub.
kubectl-validate
is also capable of validating CRDs. To do that, it needs to be
aware of their definitions. There are two ways to provide this:
If you have access to a cluster with the CRDs already installed, then kubectl-validate will automatically connect to the cluster to download the definitions.
This is done automatically if your cluster is the currently active context, or you can supply the name of the context for the cluster you'd like to use:
kubectl validate ./my_crd.yaml --kube-context <cluster_context>
If you are working offline or do not have access to a cluster with the CRDs installed, you may supply a directory to use as a search path for types:
kubectl validate ./my_crd.yaml --local-crds ./path/to/folder/with/crds
If you are working offline or do not have access to a cluster to load openapi schemas, you may supply a directory to use as a search path for schemas:
kubectl validate ./my_crd.yaml --local-schemas ./path/to/folder/with/schemas
Directory should have openapi files following directory layout:
/<apis>/<group>/<version>.json
/api/<version>.json
By default the output of the tool is human readable, but you may also request JSON structured output for easier integration with other software:
kubectl-validate ./testcases/error_array_instead_of_map.yaml --output json
Example output:
{
"./testcases/error_array_instead_of_map.yaml": {
"metadata": {},
"status": "Failure",
"message": "ConfigMap.core \"my-deployment\" is invalid: data: Invalid value: \"array\": data in body must be of type object: \"array\"",
"reason": "Invalid",
"details": {
"name": "my-deployment",
"group": "core",
"kind": "ConfigMap",
"causes": [
{
"reason": "FieldValueTypeInvalid",
"message": "Invalid value: \"array\": data in body must be of type object: \"array\"",
"field": "data"
}
]
},
"code": 422
}
}
🚧 COMING SOON: native docker image & GitHub action 🚧
Here is an example of a simaple GitHub Actions workflow that uses kubectl-validate
to validate Kubernetes manifests.
This workflow will run on every pull request to the main
branch and will fail if any of the manifests in the dir k8s-manifest/
are invalid.
name: kubectl-validate
on:
pull_request:
branches:
- main
jobs:
k8sManifestsValidation:
runs-on: ubuntu-latest
steps:
- name: Checkout repo content
uses: actions/checkout@v3
- name: Setup go
uses: actions/setup-go@v4
with:
go-version: '1.20'
- name: Install kubectl-validate
run: go install sigs.k8s.io/kubectl-validate@latest
- name: Run kubectl-validate
run: kubectl-validate ./k8s-manifest/ --version 1.23
This project doesn't have a native docker image (yet), but you can use the given Dockerfile to build one.
First, you will need to build it from the Dockerfile (final image size is 98MB):
docker build -t kubectl-validate .
And then you can run it and mount the directory (k8s-manifest
) with your manifests:
docker run --volume k8s-manifest:/usr/local/k8s-manifest -it kubectl-validate --version 1.23 /usr/local/k8s-manifest/
Learn how to engage with the Kubernetes community on the community page.
You can reach the maintainers of this project at:
- Kubernetes Slack in the #kubectl-validate channel.
- Mailing List
Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.