Throttling looks exactly like a slow dependency

A limit is a quota, not a priority

A CPU limit does not mean 'use less when the node is busy'. It means 'never exceed this, whatever the node is doing'. A container limited to 100m gets a tenth of a core on a node with fifteen idle ones.

The symptom is latency, and only latency. Nothing is killed, nothing restarts, no probe fails, and the node graphs show a machine with capacity to spare. Every instinct points outward — at the database, at the network, at whatever the service calls — and none of them point at a number in your own manifest.

The tell is the throttling metric, which almost nobody has a dashboard for, and the arithmetic: a limit below the request is a container that has asked to be starved.

A limit below the request is always wrong. It asks the scheduler to reserve more than the runtime will ever let the container use.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 4
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout
    spec:
      containers:
      - name: api
        image: checkout:v1
        resources:
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: 100m
            memory: 512Mi

Diagnosing latency whose cause is in the application rather than in a control-loop decision is that gym's subject. debug.liter8.sh