Статические поды в Kubernetes: что это, зачем и как использовать

В Kubernetes большинство подов управляются контроллерами (Deployment, DaemonSet) через API-сервер. Однако существуют статические поды — они управляются напрямую через kubelet и не зависят от управляющих компонентов кластера.

Зачем использовать статические поды

• Для запуска системных компонентов на узле (например, мониторинга или логгирования).
• Когда нужен под, работающий независимо от control plane.
• При инициализации собственного кластера Kubernetes (например, для запуска etcd).

Основные особенности

• Управляются только kubelet.
• Не отображаются через kubectl, если не синхронизируются с API-сервером.
• Задаются YAML-манифестом в специальной директории.

Как создать статический под

1. Указание пути манифестов для kubelet

Убедитесь, что параметр --pod-manifest-path указан в конфигурации или systemd-сервисе kubelet:

--pod-manifest-path=/etc/kubernetes/manifests

Перезапустите kubelet.

2. Создание манифеста пода

Пример файла nginx-static.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-static
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Сохраните его в директорию /etc/kubernetes/manifests. Kubelet подхватит его автоматически.

3. Проверка статуса

crictl ps -a

Просмотр логов:

crictl logs <container-id>

Если отображается через API:

kubectl get pods -A | grep nginx-static

Ограничения

• Нет лейблов/селекторов — нельзя использовать Service/Deployment.
• Не управляются через API — отсутствуют lifecycle-хуки, rolling update.
• Привязка к конкретному узлу, сложно масштабировать.

Когда использовать

• Для запуска etcd и компонентов control plane на старте.
• Для запуска агентов мониторинга.
• На bare-metal системах с минимальной зависимостью от API.

Заключение

Статические поды — мощный, но нишевый инструмент Kubernetes. Они обеспечивают надежность и независимость, полезную при настройке критических компонентов или создании собственного кластера.