Inspecteur Manifestes K8s

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