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
What is the K8s Manifest Inspector?
The K8s Manifest Inspector is a client-side tool that analyzes your Kubernetes YAML manifests for common misconfigurations and best-practice violations. It detects missing resource requests and limits, missing readiness and liveness probes, use of the :latest tag or untagged images, and missing or inappropriate imagePullPolicy settings — then calculates a quality score with actionable recommendations.
How to Use
- Paste your Kubernetes YAML manifest into the input field (multi-document YAML supported)
- Click "Inspect" or wait for automatic processing
- Review findings with severity ratings (High, Medium, Low)
- Follow the recommendations to improve your manifest
- Export a full report in JSON or Markdown format
Example: Deployment with Issues
This Deployment manifest has several common issues that the inspector will detect:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 2
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web
image: nginx:latest
ports:
- containerPort: 80What Issues Are Detected?
- Missing resource limits — Container can consume unbounded CPU/memory, risking node stability
- Missing resource requests — Scheduler cannot guarantee resources; affects QoS classification
- Missing liveness probe — Kubernetes cannot detect deadlocked containers for automatic restart
- Missing readiness probe — Traffic may be sent to pods before they are ready to serve
- :latest tag usage — Deployments are non-reproducible; rollbacks become unreliable
- Missing imagePullPolicy — Pull behavior is implicit and depends on the tag used
Quality Scoring
Each manifest receives a score from 0 to 100 based on detected findings. Severity weights are: High (15 points), Medium (8 points), Low (3 points). The score maps to a letter grade: A (90+), B (75+), C (60+), D (40+), F (below 40).
Kubernetes Manifest Best Practices
- Always set
resources.requestsandresources.limitsfor CPU and memory - Add a
livenessProbeso Kubernetes can restart unhealthy containers - Add a
readinessProbeso Services only route traffic to ready pods - Pin container images to specific version tags or SHA digests
- Explicitly set
imagePullPolicyto make pull behavior deterministic - Use namespaces to organize and isolate workloads
- Set appropriate
replicasfor high availability
Supported Resource Types
The inspector handles Deployment, StatefulSet, DaemonSet, Job, CronJob, ReplicaSet,
ReplicationController, and Pod resources. Multi-document YAML files separated by ---
are fully supported.
Privacy and Security
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 — are never transmitted to any server. No data is stored, logged, or shared.
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.