Что происходит после ввода kubectl create deployment в Kubernetes

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

После ввода kubectl create deployment происходит каскад событий в Kubernetes, который преобразует вашу команду в работающие контейнеры. Процесс начинается с вашего kubectl CLI, проходит через kube-apiserver, затем компоненты control plane (контроллеры и планировщик) и завершается на worker nodes узлах. Это фундаментальный пример работы declarative model Kubernetes.

Детальный пошаговый процесс

Вот что происходит последовательно, когда вы выполняете команду, например:

kubectl create deployment nginx --image=nginx:latest --replicas=3

1. Обработка команды в kubectl

• Клиент kubectl валидирует синтаксис, параметры и проверяет подключение к кластеру (читает конфигурацию из ~/.kube/config).
• Он преобразует вашу императивную команду в declarative manifest — объект Deployment в формате YAML/JSON.
• Этот манифест отправляется через REST API call (обычно HTTPS) на kube-apiserver.

2. Аутентификация, авторизация и адмиссия в kube-apiserver

• Authentication: kube-apiserver проверяет ваши учетные данные (токен, клиентский сертификат и т.д.).
• Authorization: Проверяет, имеете ли вы права (RBAC) на создание объектов Deployment в указанном namespace.
• Admission Control: Цепочка admission controllers (таких как ResourceQuota, PodSecurity) может изменять или валидировать манифест. Например, может быть добавлен контейнер для сбора логов (sidecar) или проверены политики безопасности.

3. Сохранение состояния в etcd

После успешного прохождения всех проверок, kube-apiserver сериализует объект Deployment и сохраняет его в распределенном key-value хранилище etcd. Это "source of truth" (единственный источник истины) для кластера. Теперь желаемое состояние (spec) развертывания зафиксировано.

4. Работа контроллеров Control Plane (Цикл согласования)

Здесь включается controller manager, а именно Deployment Controller:

• Он наблюдает за изменениями в etcd через kube-apiserver.
• Обнаружив новый Deployment, он сравнивает желаемое состояние (spec.replicas: 3) с текущим. Поскольку ReplicaSet еще не существует, текущее состояние равно 0.
• Для достижения желаемого состояния Deployment Controller создает новый объект ReplicaSet и записывает его обратно в etcd через API-сервер. Этот ReplicaSet содержит шаблон пода (Pod template) и цель по репликам.

Запускается ReplicaSet Controller:

• Он наблюдает за ReplicaSet и видит, что требуется 3 пода, а существующих — 0.
• Он создает 3 объекта Pod (только их определения, не сами процессы) и записывает их в etcd. Поды на этом этапе имеют статус Pending.

5. Планирование подов на узлы (kube-scheduler)

• Kube-scheduler наблюдает за подами с статусом Pending.
• Для каждого пода он выполняет двухэтапную операцию:

    *   **Filtering**: Отфильтровывает узлы, не соответствующие требованиям (недостаточно ресурсов, несовпадение nodeSelector, taints/tolerations).
    *   **Scoring**: Присваивает оставшимся узлам баллы на основе политик (распределение нагрузки, affinity/anti-affinity правила). Выбирает узел с наивысшим баллом.

• Scheduler обновляет спецификацию пода, присваивая ему поле nodeName (выбранный узел), и записывает обновленный объект Pod обратно в etcd.

6. Запуск контейнеров на рабочем узле (kubelet)

• Kubelet на каждом worker node постоянно опрашивает kube-apiserver о назначенных ему подах.
• Kubelet на выбранном узле обнаруживает, что ему назначен новый Pod (поле nodeName совпадает с именем узла).
• Он выполняет следующую последовательность:

    1.  Скачивает образ контейнера (`nginx:latest`) из указанного **container registry** с помощью **container runtime** (например, containerd или CRI-O).
    2.  Подготавливает **volume** (тома), если они определены в спецификации пода.
    3.  Применяет параметры безопасности (политики **Pod Security Standards**, `securityContext`).
    4.  Через **CRI (Container Runtime Interface)** дает команду runtime запустить контейнер(ы).

• После успешного запуска kubelet начинает постоянно report status (отчитываться о статусе) обратно в kube-apiserver, который обновляет состояние Pod в etcd (статус меняется на Running).

7. Сетевые настройки (CNI Plugin)

Параллельно, при создании пода kubelet вызывает CNI plugin (например, Calico, Cilium), который:

• Назначает pod IP-адрес из пула CIDR сети кластера.
• Настраивает сетевое пространство (network namespace) и политики сети, если они определены.

8. Настройка сервис-прокси (kube-proxy)

• Kube-proxy, работающий на каждом узле, наблюдает за изменениями в API, касающихся Services и Endpoints.
• Если для этих подов позже будет создан Service, kube-proxy обновит свои правила (iptables, ipvs) на всех узлах, чтобы направлять трафик на новые поды по их IP-адресам.

Итоговая картина

Весь этот процесс, от вашей команды в терминале до работающих контейнеров, занимает секунды. Вы в итоге получаете:

• 1 объект Deployment в etcd (управляет стратегией обновления и историей).
• 1 объект ReplicaSet в etcd (управляет масштабированием).
• 3 объекта Pod в etcd (описывают экземпляры приложения).
• 3 запущенных контейнера на одном или нескольких worker nodes в кластере.

Deployment обеспечивает декларативное обновление, откат и работоспособность этих подов, поддерживая желаемое состояние, даже если какие-то из них выйдут из строя. Это демонстрирует мощь Kubernetes control loop (цикла управления).