K8s Manifest Inspector
Inspect Kubernetes YAML manifests for missing resource limits, probes, and image tag issues
Enter your Kubernetes YAML manifest to inspect for misconfigurations and best-practice violations
Inspecting Kubernetes Manifests for Production Readiness
Kubernetes manifests define the desired state of your workloads — containers, resource allocations,
health checks, and scheduling constraints. A manifest that deploys successfully is not necessarily
production-ready. Missing resource limits can cause node exhaustion, absent health probes prevent
the scheduler from detecting unhealthy pods, and :latest tags introduce unpredictable
deployments. The Manifest Inspector analyzes your YAML definitions against production best practices
and reports issues before they cause incidents in live clusters.
This tool inspects Deployments, StatefulSets, DaemonSets, and standalone Pod specifications to detect common configuration gaps. Each finding includes the specific container, the missing configuration, and a recommendation explaining why it matters for reliability and performance. All analysis runs entirely in your browser — your manifests never leave your device.
Resource Requests and Limits
Resource requests and limits are the most critical missing configuration in production manifests. Without them, the Kubernetes scheduler cannot make informed placement decisions and containers can consume unbounded resources:
- Missing CPU requests: The scheduler cannot guarantee CPU time for the pod, leading to performance degradation under contention.
- Missing memory limits: A container with a memory leak can consume all node memory, triggering OOMKills on unrelated pods sharing the same node.
- Requests exceeding limits: An invalid configuration that Kubernetes rejects but is easy to introduce through copy-paste errors.
-
Extremely high limits: Limits set to values like
64Gimemory effectively mean no limit and bypass the protection they should provide.
The inspector flags containers missing any resource specification and recommends starting values based on the workload type — web servers, workers, databases, and sidecars each have different baseline resource profiles.
Health Probes: Liveness, Readiness, and Startup
Health probes tell Kubernetes how to determine whether a container is alive, ready to serve traffic, and has completed initialization:
- Liveness probe: Restarts the container when it enters a broken state (deadlock, infinite loop). Missing liveness probes mean broken containers run indefinitely.
- Readiness probe: Removes the pod from Service endpoints when it cannot handle requests (database connection lost, dependency unavailable). Missing readiness probes route traffic to pods that will return errors.
- Startup probe: Gives slow-starting containers time to initialize before liveness checks begin. Missing startup probes with aggressive liveness settings cause restart loops during initialization.
The inspector checks for missing probes on each container and verifies that existing probes have reasonable timing configurations — a liveness probe with a 1-second timeout on a database connection check will trigger false-positive restarts under load.
Image Tag Best Practices
Container image references determine exactly which code runs in your cluster. The inspector detects problematic image configurations:
-
:latesttag usage: The:latesttag is mutable — the actual image it points to changes with every push. This means deployments are non-reproducible and rollbacks may not return to the previous code version. -
Missing tag entirely: Images specified without any tag default to
:latest, carrying the same risks plus making it harder to identify the issue. -
Inappropriate imagePullPolicy: Using
Alwayswith a pinned SHA digest wastes bandwidth, while usingIfNotPresentwith:latestmeans you may never get updated images after the initial pull.
Best practice is pinning images to immutable tags (semantic versions or SHA digests) and setting
imagePullPolicy: IfNotPresent to reduce registry load while ensuring consistency.
Code Examples
Deployment with Common Issues (Before Fixing)
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
replicas: 3
template:
spec:
containers:
- name: api
image: myregistry/api:latest # Issue: mutable tag
ports:
- containerPort: 8080
# Missing: resources.requests and resources.limits
# Missing: livenessProbe
# Missing: readinessProbe
# Inspector findings:
# - WARN: Container 'api' uses :latest tag (non-reproducible)
# - ERROR: Container 'api' missing resource requests
# - ERROR: Container 'api' missing resource limits
# - WARN: Container 'api' missing liveness probe
# - WARN: Container 'api' missing readiness probeProduction-Ready Deployment (After Fixing)
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
spec:
replicas: 3
template:
spec:
containers:
- name: api
image: myregistry/api:2.4.1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 8080
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 500m
memory: 512Mi
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5 Frequently Asked Questions
What does the K8s Manifest Inspector check?
The inspector analyzes Kubernetes YAML manifests for common misconfigurations: missing resource requests and limits, missing readiness and liveness probes, use of :latest tag or untagged images, and missing or inappropriate imagePullPolicy settings. It identifies the resource type (Deployment, Pod, StatefulSet, DaemonSet, Job, CronJob) and inspects each container within the workload.
How is the score calculated?
The score starts at 100 and deducts points based on finding severity: High issues (like missing resource limits) deduct 15 points, Medium issues (like missing probes or :latest tag) deduct 8, and Low issues (like unset imagePullPolicy) deduct 3. The final score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
Does it support multi-document YAML files?
Yes. The inspector fully supports multi-document YAML separated by --- delimiters. Each document is analyzed independently, and all resources and their containers are included in the inspection report. This is common for Kubernetes manifests that bundle multiple resources in a single file.
Why are resource limits important?
Without resource limits, a container can consume unbounded CPU and memory on the node, potentially starving other pods and causing node instability. Setting limits ensures the Kubernetes scheduler can properly place pods and that a single misbehaving container cannot bring down an entire node.
Why are readiness and liveness probes recommended?
Liveness probes let Kubernetes detect deadlocked or crashed containers and restart them automatically. Readiness probes prevent traffic from being routed to pods that aren't ready to serve requests (e.g., still initializing). Without these probes, you lose self-healing and graceful traffic management.
Why is the :latest tag flagged?
Using :latest or omitting a tag means your deployments are non-reproducible — the same manifest may deploy different versions at different times. This makes rollbacks unreliable and debugging harder. Pin images to a specific version tag or SHA digest for deterministic deployments.
Is my Kubernetes manifest sent to any server?
No. All inspection happens entirely in your browser using JavaScript. Your Kubernetes manifests — which may contain internal service names, namespace details, environment variables, and infrastructure topology — never leave your device. No data is stored, logged, or transmitted.
What Kubernetes resource types are supported?
The inspector handles Deployment, StatefulSet, DaemonSet, Job, CronJob, ReplicaSet, ReplicationController, and Pod resources. For other resource types, it attempts to locate containers in standard locations (spec.containers or spec.template.spec.containers). Non-workload resources like Services and ConfigMaps are identified but not inspected for container-level issues.