Для какого типа подов в Kubernetes не нужен kube-scheduler?

«Для какого типа подов в Kubernetes не нужен kube-scheduler?» — вопрос из категории Kubernetes, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Kube-scheduler не участвует в планировании статических подов (Static Pods). Их жизненным циклом управляет напрямую kubelet на конкретном узле.

Как это работает:

  1. Файлы манифестов статических подов размещаются в специальной директории на узле (например, /etc/kubernetes/manifests).
  2. Kubelet отслеживает эту директорию и самостоятельно создает/обновляет/удаляет поды, минуя API-сервер Kubernetes (хотя позже он создает для них зеркальные объекты в API для видимости).
  3. Поскольку планировщик работает на уровне API-сервера, для этих локально управляемых подов он не требуется.

Пример использования из моего опыта: Мы использовали статические поды для развертывания критичных системных компонентов самого control plane (например, kube-scheduler, kube-controller-manager) на мастер-узлах, чтобы обеспечить их запуск до полной готовности кластера.

Пример манифеста статического пода для системного демона:

apiVersion: v1
kind: Pod
metadata:
  name: node-log-collector
  namespace: kube-system
spec:
  priorityClassName: system-node-critical
  containers:
  - name: fluent-bit
    image: fluent/fluent-bit:latest
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    hostPath:
      path: /var/log
  nodeSelector:
    node-role.kubernetes.io/master: ""

Важно: Для всех остальных подов, создаваемых через Deployment, StatefulSet, Job и т.д., kube-scheduler является обязательным компонентом для выбора подходящего узла.