Image and compute anti-patterns — the workload's foundation

Most of what makes a workload fragile is decided in a dozen lines of the Pod template. A mutable tag, absent resource requests, and no probes each read as an omission rather than a fault, and each one surfaces later as something else entirely — a node that scheduled more than it can hold, or a Deployment that reports Ready while serving errors. This lesson covers the specific defaults that bite and what to set in their place.

The image anti-patterns

The image anti-patterns are:

• :latest tags. The image is :latest; the cluster is at the mercy of the registry.
• No imagePullPolicy. The image has no imagePullPolicy; the kubelet may use a cached image.
• No security context. The image has no security context; the container may run as root.

flowchart TD
    A[Image anti-patterns] --> B[:latest]
    A --> C[No imagePullPolicy]
    A --> D[No security context]

The image anti-patterns are the workload’s foundation.

The compute anti-patterns

The compute anti-patterns are:

• No requests. The container has no CPU/memory requests; the scheduler cannot place the workload.
• No limits. The container has no CPU/memory limits; the workload can starve the node.
• No probes. The container has no readiness/liveness probes; the kubelet cannot detect failures.

flowchart TD
    A[Compute anti-patterns] --> B[No requests]
    A --> C[No limits]
    A --> D[No probes]

The compute anti-patterns are the workload’s capacity.

The diagnostic

The canonical diagnostic:

# Use Polaris to detect anti-patterns
polaris audit --format yaml

# Substitute your own values before running:
DEPLOY=checkout-api
NS=production

# Check the workload's image
kubectl get deployment "$DEPLOY" -n "$NS" -o jsonpath='{.spec.template.spec.containers[0].image}'

# Check the workload's resources
kubectl get deployment "$DEPLOY" -n "$NS" -o jsonpath='{.spec.template.spec.containers[0].resources}'

# Check the workload's probes
kubectl get deployment "$DEPLOY" -n "$NS" -o jsonpath='{.spec.template.spec.containers[0].readinessProbe}'

The diagnostic is the Polaris audit, the workload’s image, the workload’s resources, and the workload’s probes.

The remediation

The remediation depends on the anti-pattern:

# Substitute your own values before running:
DEPLOY=checkout-api
NS=production
IMAGE=ghcr.io/example/checkout-api
TAG=1.8.3

# Option 1: Use a specific tag
kubectl set image deployment "$DEPLOY" -n "$NS" "$IMAGE:$TAG"

# Option 2: Set the requests and limits
kubectl set resources deployment "$DEPLOY" -n "$NS" --requests=cpu=100m,memory=128Mi --limits=cpu=500m,memory=512Mi

# Option 3: Set the probes
kubectl set probe deployment "$DEPLOY" -n "$NS" --readiness=http-get=/health:8080 --liveness=http-get=/health:8080

The remediation is the anti-pattern fix.

Production discipline

The image and compute anti-patterns are the cluster’s hypothesis. The discipline is to walk the 11-step methodology applied to the anti-patterns, identify the cause, apply the remediation. The cluster’s discipline is the same scale-free: every anti-pattern gets a fix.

• Run the detection in CI. The CI is the cluster’s prevention.

Quiz