> Что такое лимиты и запросы ресурсов в Kubernetes (Go)

Короткий ответ

Лимиты и запросы ресурсов - это механизм Kubernetes для управления CPU и памятью, которые выделяются контейнерам. Requests - минимальный объём ресурсов, который гарантируется контейнеру и используется планировщиком для выбора ноды. Limits - максимальный объём, который контейнер не может превысить. Если лимит превышен, Kubernetes может убить или троттлить контейнер. Это базовый инструмент для стабильности и эффективного использования кластера.

Подробное объяснение

В Kubernetes каждый контейнер может иметь два типа ресурсных спецификаций: requests и limits. Они задаются в поле resources в манифесте пода.

Requests - это количество ресурсов, которое Kubernetes резервирует для контейнера. Планировщик использует requests при размещении пода на ноде: сумма requests всех контейнеров на ноде не должна превышать ёмкость ноды. Requests гарантируют, что контейнер получит как минимум заявленный объём ресурсов, если они доступны.

Limits - это жёсткий потолок. Контейнер не может использовать больше ресурсов, чем указано в limits. Если контейнер пытается превысить limit по CPU, Kubernetes применяет CPU throttling (ограничение частоты). Если превышен limit по памяти, контейнер может быть убит с ошибкой OOMKilled.

Ключевые моменты:

• Requests и limits задаются отдельно для CPU и memory.
• CPU измеряется в ядрах (например, 0.5 = 500m), память - в байтах (128Mi, 1Gi).
• Если limits не заданы, контейнер может использовать все ресурсы ноды, что опасно для соседних подов.
• Если requests не заданы, они по умолчанию равны limits (если limits заданы), либо равны нулю.
• Для CPU limits не являются жёстким ограничением - применяется throttling, для памяти - жёсткое, превышение ведёт к убийству процесса.

Правильная стратегия: requests должны отражать типичное потребление, limits - максимально допустимое. Разница между ними создаёт "burst" - возможность использовать больше ресурсов, когда они свободны.

На практике

В Go-приложениях важно учитывать, что runtime Go имеет свой собственный garbage collector и управление памятью. Если лимит памяти слишком мал, Go-приложение может часто получать OOMKilled, потому что GC не успевает освободить память. Рекомендуется:

• Устанавливать requests на основе профилирования (например, с помощью pprof).
• Устанавливать limits с запасом, но не слишком большим, чтобы избежать неэффективного использования кластера.
• Для CPU в Go-приложениях важно, что GOMAXPROCS по умолчанию равен числу ядер на ноде, а не лимиту. Это может привести к избыточному созданию горутин и перегрузке. Решение - использовать библиотеку automaxprocs, которая автоматически подстраивает GOMAXPROCS под CPU limit.

Пример манифеста для Go-сервиса:

YAML
apiVersion: apps/v1
kind: Deployment
metadata:
  name: go-service
spec:
  template:
    spec:
      containers:
      - name: app
        image: myapp:latest
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi

Пример кода

В Go-приложении полезно логировать текущее потребление ресурсов для настройки requests:

GO
package main

import (
    "log"
    "runtime"
    "time"
)

func printMemUsage() {
    var m runtime.MemStats
    runtime.ReadMemStats(&m)
    log.Printf("Alloc = %v MiB, TotalAlloc = %v MiB, Sys = %v MiB, NumGC = %v",
        m.Alloc/1024/1024, m.TotalAlloc/1024/1024, m.Sys/1024/1024, m.NumGC)
}

func main() {
    go func() {
        for {
            printMemUsage()
            time.Sleep(30 * time.Second)
        }
    }()
    // основной код
}

Как отвечать на собеседовании

Начни с определения: requests - гарантия, limits - ограничение. Затем объясни разницу в поведении для CPU и памяти. Упомяни, что планировщик использует requests, а kubelet - limits. Приведи пример манифеста. Если спросят про Go, добавь про GOMAXPROCS и automaxprocs. Говори структурированно, не уходи в детали, если не спрашивают. Покажи понимание, зачем это нужно: стабильность, эффективность, изоляция.

Что проверяет интервьюер

Интервьюер проверяет:

• Понимание базовых концепций Kubernetes: requests vs limits.
• Знание поведения при превышении limits (throttling для CPU, OOMKill для памяти).
• Умение объяснить, как планировщик принимает решения.
• Понимание практических аспектов для Go-приложений.
• Способность говорить чётко и структурированно.

Типичные ошибки

• Путаница между requests и limits: говорить, что requests - это ограничение.
• Утверждение, что CPU limits - жёсткое ограничение (на самом деле - throttling).
• Игнорирование разницы между CPU и памятью при превышении лимитов.
• Отсутствие упоминания о влиянии на планирование подов.
• Для Go: незнание проблемы с GOMAXPROCS и CPU limits.
• Слишком общий ответ без конкретики и примеров.