Ответ
Команда kubectl create deployment инициирует создание объекта Deployment через Kubernetes API. Вот что происходит внутри кластера:
-
kubectlотправляет YAML-манифест вkube-apiserver. Манифест выглядит примерно так:apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest -
API-сервер валидирует запрос, аутентифицирует и авторизует пользователя (через RBAC), затем сохраняет объект Deployment в etcd — распределенном key-value хранилище состояния кластера.
-
Deployment Controller (часть
kube-controller-manager), который постоянно наблюдает за состоянием etcd, замечает новый объект. Его цель — поддерживать желаемое состояние (spec.replicas: 3). Он создает объект ReplicaSet. -
ReplicaSet Controller также наблюдает за кластером. Он видит, что у нового ReplicaSet'а желаемое количество Pod'ов (
replicas: 3) не совпадает с текущим (0). Он создает 3 объекта Pod (но пока без назначенной ноды). -
Scheduler (
kube-scheduler) наблюдает за Pod'ами в состоянииPending. Он выполняет фильтрацию и оценку всех нод в кластере:- Проверяет достаточно ли ресурсов (CPU, memory).
- Учитывает node affinity/anti-affinity, taints и tolerations.
- Выбирает лучшую ноду и привязывает Pod к ней (обновляет поле
nodeNameв спецификации Pod'а).
-
Kubelet на выбранной ноде наблюдает за Pod'ами, назначенными его ноде. Он:
- Скачивает образ контейнера (
nginx:latest) из container registry через Container Runtime Interface (CRI) (например, containerd). - Создает контейнер через CRI.
- Запускает контейнеры, настраивает volumes, сети (через CNI плагин, например Calico).
- Скачивает образ контейнера (
-
Kube-proxy на каждой ноде обновляет правила iptables или IPVS, чтобы трафик к Service мог попадать на новые Pod'ы.
Итог: Через несколько секунд после команды у вас работают 3 Pod'а с nginx, распределенные по нодам кластера, доступные через Service.