K8s Inspector

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

PodDeploymentServiceConfigMapSecretIngressStatefulSetDaemonSetJobCronJobPersistentVolumeClaimPersistentVolumeServiceAccountRoleRoleBindingClusterRoleClusterRoleBindingNamespaceHorizontalPodAutoscalerNetworkPolicy

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

Invalid - Deployment with missing limits
containers:
  - name: app
    image: nginx:latest
    # Missing: resources, livenessProbe, readinessProbe
Valid - Well-configured container
containers:
  - name: app
    image: nginx:1.26
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 512Mi

Frequently Asked Questions

What are resource requests and limits?

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.

Why is running as root in a container dangerous?

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.

What are liveness and readiness probes?

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.

Why is using the :latest image tag bad?

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