Ресурсы: requests и limits

Без указания ресурсов один прожорливый под способен положить весь узел — requests и limits задают рамки.

requests — сколько ресурсов поду гарантированно нужно (влияет на выбор узла); limits — потолок, выше которого поду подняться нельзя.

Каждый контейнер можно охарактеризовать двумя числами по CPU и памяти. requests — это бронь: scheduler разместит под только на узел, где столько свободно. limits — это ограничение: контейнер не получит больше, даже если захочет.

Как задают ресурсы

spec:
  containers:
    - name: app
      image: my-app:1.0
      resources:
        requests:
          cpu: "250m"      # 0.25 ядра
          memory: "128Mi"
        limits:
          cpu: "500m"      # не больше 0.5 ядра
          memory: "256Mi"

Единицы измерения

• CPU: 1 = одно ядро. 500m = «500 милли-ядер» = половина ядра. 250m = четверть.
• Память: Mi — мебибайты (1024²), Gi — гибибайты. 128Mi, 1Gi и т. п.

Что бывает при превышении limit

CPU и память ведут себя по-разному при достижении потолка:

• CPU просто придушивается (throttling): контейнер работает медленнее, но живёт.
• Память жёстче: превысил memory limit — контейнер убивают со статусом OOMKilled (Out Of Memory).

kubectl get pod app
kubectl describe pod app  # в Events будет OOMKilled, если память кончилась

Вывод:

NAME   READY   STATUS      RESTARTS   AGE
app    0/1     OOMKilled   2          1m

Зачем это всё

requests дают честное планирование: scheduler знает, сколько узлу занять, и не перегружает его. limits защищают соседей: один сервис с утечкой памяти не съест весь узел. Правильно подобранные значения — основа стабильного кластера.

Итог

• requests — бронь ресурсов для планирования, limits — потолок при работе.
• CPU задают в милли-ядрах (500m), память — в Mi/Gi.
• Превышение memory limit ведёт к OOMKilled, CPU лишь придушивается.