Kubernetes YAML Formatter & Validator
指导
Kubernetes YAML Formatter & Validator
Format and validate your Kubernetes manifest YAML files instantly in the browser. Paste any K8s manifest — Deployments, Services, ConfigMaps, Ingress, CronJobs, and more — and get consistent 2-space indentation, optional key sorting, and schema validation against 19 Kubernetes resource types. Catches missing required fields, deprecated apiVersions, selector/label mismatches, and structural errors with clear line-numbered annotations.
如何使用
Paste your Kubernetes YAML manifest into the input area or load one of the built-in examples. The tool automatically detects the resource kind and validates it against the appropriate schema. Multi-document manifests separated by --- are supported — each document is validated independently. Toggle key sorting, choose between formatting only or full validation, and copy the clean output to your clipboard.
特征
- 19 Resource Types – Validates Deployment, Service, ConfigMap, Secret, Ingress, Pod, StatefulSet, DaemonSet, Job, CronJob, HPA, PVC, PV, Namespace, ServiceAccount, Role, RoleBinding, ClusterRole, and ClusterRoleBinding
- Schema Validation – Checks required fields, valid apiVersions, correct spec structure, and type constraints for each resource kind
- Deprecated API Detection – Flags deprecated apiVersions like
extensions/v1beta1and suggests the correct replacement - Selector/Label Matching – Verifies that Deployment and StatefulSet selectors match their pod template labels
- Multi-Document Support – Handles YAML files with multiple
---separated documents, validating each independently - Consistent Formatting – Applies clean 2-space indentation with optional alphabetical key sorting
- Line-Numbered Errors – Validation errors and warnings include line numbers for quick identification
- Example Manifests – Load sample Deployment, Service, or multi-document manifests to see the tool in action
常问问题
-
What are the most common Kubernetes YAML mistakes?
The most frequent errors include using deprecated apiVersions (like extensions/v1beta1 instead of apps/v1 for Deployments), forgetting required fields like metadata.name or spec.containers, mismatched label selectors between a Deployment spec.selector.matchLabels and its pod template metadata.labels, incorrect indentation causing fields to be parsed at the wrong level, and using wrong field types like strings where integers are expected for ports or replicas.
-
What is the difference between apiVersion apps/v1 and extensions/v1beta1?
The extensions/v1beta1 apiVersion was the original API group for Deployments, DaemonSets, and ReplicaSets in early Kubernetes versions. It was deprecated in Kubernetes 1.16 and removed in 1.22 in favor of apps/v1, which is the stable API group. Similarly, networking.k8s.io/v1 replaced extensions/v1beta1 for Ingress resources. Always use the stable API versions for production manifests.
-
How do multi-document YAML files work in Kubernetes?
Kubernetes supports multiple resource definitions in a single YAML file by separating them with a line containing only three dashes (---). When you apply a multi-document file with kubectl apply -f, Kubernetes creates or updates each resource independently. This is commonly used to bundle related resources like a Deployment and its Service in one file for easier management.
-
Why do Deployment selectors need to match pod template labels?
A Deployment uses its spec.selector.matchLabels to identify which Pods it manages. The pod template under spec.template.metadata.labels must include all the labels specified in the selector. If they do not match, the Deployment controller cannot find its Pods, and Kubernetes will reject the manifest with a validation error. This selector mechanism is how Kubernetes connects higher-level controllers to the Pods they manage.
