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 64Gi memory 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:

  • :latest tag usage: The :latest tag 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 Always with a pinned SHA digest wastes bandwidth, while using IfNotPresent with :latest means 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 probe

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