Kubernetes YAML Validator and Best-Practice Checker
Schema, removed APIs, Pod Security and reliability checks for your Kubernetes version.
Try before you buy.
- Free preview: every count (objects, errors, warnings, notes) and the list of objects, with the first problems of the report (up to 10).
- Locked until you unlock it: download and copy.
- Unlock: Pro pass, ₹179 for 30 days, a one-time payment that never renews.
Ways to unlock shows how to get the full result.
Printing this result is locked in the free preview.
Separate documents with ---; a kubectl get -o yaml List or JSON works too. Checked as you type, in your browser. Render Helm charts first
(helm template). Ctrl/⌘ + Enter checks now.
Objects
| Line | Kind | Name | apiVersion |
|---|
Problems
Locked in the free preview. Opens the ways to unlock this result.
Locked in the free preview. Batch runs unlock with a pass.
Locked in the free preview. Query results unlock with a pass.
About the Kubernetes YAML Validator and Best-Practice Checker
Paste one or more Kubernetes manifests — documents separated by ---, a kubectl get -o yaml List or JSON — choose the Kubernetes version of your cluster, and every object is checked the way that version of the API server would read it, with the line of each problem:
- API versions: API versions that the chosen version no longer serves (such as
extensions/v1beta1Ingress orbatch/v1beta1CronJob) with the version to use and what changed in it, versions that are not served yet, deprecated APIs and fields, and alpha or beta APIs that clusters do not serve unless they are switched on. - Schema: each object against the schema of its kind in that Kubernetes version — misspelt or unknown fields with a “did you mean”, wrong types, missing required fields, and fields that only exist in newer versions.
- Kubernetes rules: names and labels, selectors that match their pod templates, ports, quantities such as
512mwritten for512Mi, probes and CronJob schedules. - Pod Security Standards: the Baseline and Restricted controls — privileged containers, hostPath volumes, host networking, running as root, added capabilities, seccomp and the rest.
- Best practices: missing resource requests and limits, missing probes, the
latesttag, single-replica Deployments, Services whose selectors match no pod, Ingress backends that are not in the file, and passwords written as plain environment variables.
The schemas of Kubernetes 1.25 to 1.37 are part of the page, so nothing is uploaded and no cluster is contacted. Helm charts must be rendered first. Without a pass the result is a free preview: every count and the list of objects, with the first problems of the report. The whole report, copying it and downloading it unlock with a Pro pass.
How to use it
- Paste your manifests, open a
.yaml,.ymlor.jsonfile, or press Load example. A Helm chart must be rendered first:helm template my-release ./chart -f values.yaml. - Choose your cluster’s Kubernetes version (
kubectl versionshows it as Server Version) and the Pod Security level to check: Restricted, Baseline or off. - Read the report: errors are what the API server or a Pod Security level would refuse, warnings are problems it accepts, notes are advice. Show selects the line in your text, and each finding links the Kubernetes page it follows.
- Fix the YAML and the report updates as you type. With a pass, or once the report is unlocked, copy it as Markdown or download it as Markdown or JSON; the free preview shows its first problems and locks both.
Examples
apiVersion: extensions/v1beta1
kind: Ingress
…
backend:
serviceName: shop-web
servicePort: 80Error (API version), line 1: extensions/v1beta1 is no longer served for Ingress (removed in Kubernetes 1.22): use apiVersion: networking.k8s.io/v1 (available since 1.19). - Changed in the new version: the backend serviceName field is renamed to service.name. - Changed in the new version: pathType is now required for each path.
Kubernetes 1.29 · a Service with spec: trafficDistribution: PreferClose
Error (Schema), line 6: Property "trafficDistribution" is not allowed here. trafficDistribution is a field of Kubernetes 1.30 and later, not of 1.29: choose your cluster’s version above, or remove it.
containers:
- name: web
image: ghcr.io/acme/web:latest
securityContext:
privileged: trueError (Pod Security · Baseline: Privileged Containers): Container “web” is privileged… Warning (Pod Security · Restricted: Running as Non-root): Container “web” may run as root… Warning (Best practice): the image “ghcr.io/acme/web:latest” uses the tag latest…
Baseline violations are errors: a namespace that enforces Baseline or Restricted refuses the pod. Restricted-only problems are warnings.
What each check follows
- API versions follow the Deprecated API Migration Guide, which lists every API version removed since Kubernetes 1.16 and its replacement. The versions in which each kind is served, and its deprecated fields, come from the OpenAPI document of each Kubernetes release.
- Schemas are those OpenAPI documents, made strict like kubeconform’s: an object may have no fields its schema does not define, so a typo is caught instead of being dropped.
- Pod Security follows the Pod Security Standards for the chosen version, as the built-in Pod Security Admission controller applies them — including the probe-host control of 1.34, the SELinux type of 1.31, the sysctls added in 1.27, 1.29, 1.32 and 1.37, image volumes at the Restricted level from 1.33, the exceptions for pods with user namespaces from 1.35, and those for Windows pods.
- Best practices follow the Kubernetes documentation on resources, probes, images and disruptions.
Choosing the Kubernetes version
Pick the version of your cluster’s API server, not of kubectl: kubectl version prints both. Managed clusters (EKS, GKE, AKS) show it in their console. Checking against the version you are about to upgrade to tells you, before the upgrade, which manifests will stop applying.
An API version that a release no longer serves is an error for that release and later ones; for earlier releases it is a warning with the release that removes it.
After the check
kubectl apply --dry-run=server -f manifests.yamllets your cluster check the objects with its own admission policies, quotas and custom resources, without changing anything.kubectl label namespace shop pod-security.kubernetes.io/enforce=restrictedmakes Pod Security Admission enforce a level for a namespace;pod-security.kubernetes.io/warn=restrictedonly warns.- To write new manifests, use the Kubernetes YAML Generator; to convert between YAML and JSON, JSON to YAML.
Limitations
- Schemas cover the built-in kinds of Kubernetes 1.25 to 1.37 as each release defines them. Custom resources (cert-manager, Argo, Istio, the Gateway API…) are reported but not checked against a schema.
- Helm charts and kustomize overlays are not rendered here: run
helm templateorkubectl kustomizefirst and paste the output. - The page does not know your cluster: admission webhooks, quotas, existing objects and the APIs a managed cluster enables are only checked by
kubectl apply --dry-run=server. - Best practices are advice, not rules: a CronJob without a liveness probe or a deliberate single replica can be right for your case.
Privacy
Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.
Frequently asked questions
What do I get without a pass?
Without a pass, Kubernetes YAML Validator and Best-Practice Checker shows every count (objects, errors, warnings, notes) and the list of objects, with the first problems of the report (up to 10). Until you unlock it, the result can’t be downloaded or copied. A Pro, Premium or Ultimate pass, a one-time payment that never renews, unlocks the full result. The pricing page lists the passes and their prices.
Is this like kubeconform, kube-score or Pluto?
It does the jobs of all three in one report: the strict schema check of kubeconform for a chosen Kubernetes version, the removed and deprecated API versions that Pluto finds, and reliability checks in the spirit of kube-score — plus the Pod Security Standards. It runs in your browser, so there is nothing to install.
Why is a field reported as “not allowed” when the YAML looks right?
Usually a typo (contaners, imagePullPolicy in the wrong place) or a field that belongs to a newer Kubernetes version than the one chosen. The message suggests the closest field name, or says which versions have the field. kubectl apply validates strictly by default (--validate=strict), so the API server refuses unknown fields too.
What is the difference between the Baseline and Restricted levels?
Baseline blocks known privilege escalations — privileged containers, host namespaces, hostPath volumes, host ports, extra capabilities — and accepts a default pod. Restricted also requires hardening: running as non-root, allowPrivilegeEscalation: false, a RuntimeDefault seccomp profile, dropping all capabilities and only common volume types.
Why does “yes” or “on” in my YAML get a note?
Kubernetes reads YAML 1.1, in which unquoted yes, no, on, off, y and n are booleans. A label value or an environment variable must be text, so quote it: "yes".
Is my YAML sent anywhere?
No. The schemas are part of the page and every check runs in your browser; nothing is uploaded and no cluster is contacted.