September 25, 2026 路 #9
The neighbor that ate the node
This API deployment is missing a control. What fails first under load?
apiVersion: apps/v1
kind: Deployment
metadata:
name: checkout-api
spec:
replicas: 6
selector:
matchLabels:
app: checkout-api
template:
metadata:
labels:
app: checkout-api
spec:
containers:
- name: api
image: ghcr.io/acme/checkout@sha256:abc123
ports:
- containerPort: 8080Next puzzle in UTC
One try. The first answer sticks.
How to fix it
Without resources.limits.memory the kubelet will not OOM-kill this container before the node itself is in trouble. Set requests and limits on every workload container.
The selector matches the labels, the image is pinned to a digest, and six replicas is a normal setting. The gap is resources. With no memory limit, a leak or a bad query expands until the node starts killing other pods, including kube-system if you are unlucky.
Requests are how the scheduler reserves capacity. Limits are how the kubelet decides who to stop. Set them from a load test, not from a guess you copy between services. A limit far below the request is invalid. A limit with no request is allowed, but the scheduler still needs the request to place the pod honestly.
Fix
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
memory: 512Mi
Leave CPU unlimited if you want bursts, but always cap memory. Add a LimitRange on the namespace so a manifest that omits resources gets defaults instead of a silent pass.