K8s Inspector
Kubernetes YAML validator online free. Inspect K8s manifests, detect resource types, validate required fields. K8s YAML checker—analyze Kubernetes YAML instantly.
Kubernetes YAML
Paste a Kubernetes YAML manifest to analyze
Supported Resources
Features
- Parse and analyze Kubernetes YAML manifests visually
- Display resource kind, API version, name, namespace, and labels
- Inspect spec fields: containers, images, ports, env vars, volumes, resource limits
- Highlight missing best-practice fields (resource limits, liveness probes, security context)
- Multi-document YAML support (multiple resources in one file)
- Export parsed resource summary as JSON
Common Use Cases
- Quickly understand the contents of an unfamiliar Kubernetes manifest
- Review third-party manifests before applying to your cluster
- Identify missing resource limits that could cause OOMKills or CPU throttling
- Check containers are not running as root (<code>securityContext</code>)
- Audit images for unpinned tags (e.g., <code>:latest</code>)
- Prepare for Kubernetes security reviews and compliance audits
Kubernetes Resource Structure
Every Kubernetes resource has four top-level fields: apiVersion, kind, metadata, and spec (plus status, which is managed by the cluster). Understanding this structure allows you to read any manifest regardless of the resource type.
For workload resources (Deployment, StatefulSet, DaemonSet), the key nested structure is: spec.template.spec.containers[] — a list of containers each with image, ports, env, resources, and probes. This is where most operational configuration lives.
The Inspector surfaces all these fields visually, making it easy to spot missing configurations like resource limits, health checks, or security contexts without reading raw YAML.
Examples
containers:
- name: app
image: nginx:latest
# Missing: resources, livenessProbe, readinessProbecontainers:
- name: app
image: nginx:1.26
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512MiFrequently Asked Questions
Requests: the minimum CPU/memory the scheduler guarantees to the container. Limits: the maximum the container is allowed to use. Without requests, the scheduler cannot make informed placement decisions. Without limits, a runaway process can starve other containers on the same node. Always set both.
If a container process is compromised, running as root gives the attacker the highest privilege level inside the container. Combined with container escape vulnerabilities, this can compromise the host node. Use securityContext.runAsNonRoot: true and runAsUser: 1000 (or similar non-zero UID) to limit blast radius.
Liveness probe: Kubernetes restarts the container if it fails. Readiness probe: Kubernetes removes the pod from the Service endpoints until it passes (no traffic sent to unready pods). Without probes, Kubernetes cannot distinguish a stuck pod from a healthy one. Always define both for production workloads.
:latest is mutable — the same tag can point to different image versions on different pulls. This makes deployments non-deterministic and roll-backs unreliable. Always pin to a specific immutable tag (e.g., nginx:1.26.0) or a content digest (nginx@sha256:...).
💡 Tips
- Set resource requests to the p50 (median) usage and limits to the p99 (99th percentile) from your monitoring data.
- Use <code>securityContext.allowPrivilegeEscalation: false</code> to prevent processes from gaining more privileges than their parent.
- Add <code>readinessProbe</code> before <code>livenessProbe</code> — a failing readiness probe just removes traffic; a failing liveness probe restarts the pod.
- Pin image tags to digests (<code>image: nginx@sha256:...</code>) for fully reproducible deployments that are immune to tag mutation.