Что будет происходить при kubectl apply?

Разбор команды kubectl apply

Команда kubectl apply является одним из ключевых инструментов для декларативного управления ресурсами в Kubernetes. В отличие от императивных команд (например, create или replace), apply работает с файлами конфигурации (обычно YAML или JSON) и использует механизм системы разности (diff) и слияния (merge), чтобы привести реальное состояние кластера к желаемому, описанному в манифесте.

Основные этапы выполнения kubectl apply

Когда вы выполняете команду, например, kubectl apply -f deployment.yaml, происходит следующая последовательность событий:

1. Парсинг и валидация манифеста

• Клиент kubectl читает файл конфигурации.
• Проверяется его структура и соответствие схеме API Kubernetes.
• Определяется тип ресурса (например, Deployment, Service) и его имя.

2. Расчет разности (Diff) и применение патча Это самая важная часть процесса. kubectl не просто заменяет ресурс целиком. Он:

• Получает текущее состояние объекта из кластера (если он уже существует).
• Сравнивает его с новым состоянием из предоставленного манифеста.
• Вычисляет разность (patch) между ними.
• Отправляет на API сервер Kubernetes PATCH запрос (чаще всего с типом strategic merge patch), содержащий только изменения.

# Пример: исходный манифест deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: app
        image: my-image:v1.0

Если мы изменим replicas: 5 и обновим образ image: my-image:v1.1, kubectl apply создаст и отправит патч, который затрагивает только эти поля, сохраняя все остальные конфигурации (например, метки, порты) неизменными.

3. Обновление поля last-applied-configuration Для реализации декларативной модели, kubectl сохраняет последнюю примененную конфигурацию в аннотации объекта kubectl.kubernetes.io/last-applied-configuration. Это позволяет в будущем:

• Корректно вычислять разность между текущим состоянием в кластере и последней примененной версией файла.
• Определять, какие поля были удалены из манифеста и должны быть удалены из объекта (при следующем apply).

4. Создание или обновление ресурса в кластере

• Если ресурс с указанным именем и типом не существует, Kubernetes выполнит операцию CREATE. Объект будет создан на основе предоставленного манифеста, и в его аннотации будет сохранена полная конфигурация.
• Если ресурс уже существует, Kubernetes выполнит операцию UPDATE/PATCH. Контроллеры соответствующего ресурса (например, Deployment Controller) получит новое желаемое состояние и начать процесс его достижения (например, создание новых Pods с обновленным образом).

Ключевые особенности и преимущества

• Декларативный подход: Вы описываете желаемое состояние, а Kubernetes самостоятельно определяет действия для его достижения и поддержания.
• Инкрементальные изменения: Обновляются только измененные поля, что минимизирует риск ошибок и не затрагивает неуказанные параметры.
• История конфигураций: Аннотация last-applied-configuration позволяет работать с конфигурацией как с кодом, отслеживая изменения в Git.
• Идемпотентность: Многократное выполнение apply с тем же манифестом не изменяет состояние системы после первого применения.

Практический пример и сравнение

# Императивное создание (без сохранения конфигурации для future diff)
kubectl create -f deployment.yaml

# Декларативное применение (с сохранением конфигурации)
kubectl apply -f deployment.yaml

# Посмотреть вычисленную разность без реального применения (dry-run)
kubectl apply -f deployment.yaml --dry-run=client

Важно отличать apply от replace:

• kubectl replace использует PUT запрос и полностью заменяет объект новой конфигурацией. Если вы удалите поле из манифеста и выполните replace, это поле будет удалено из объекта в кластере. Однако replace не использует механизм трехстороннего слияния и может вызвать конфликты, если объект был изменен другими средствами.
• kubectl apply более безопасен для постепенного управления конфигурацией в командной работе.

Таким образом, kubectl apply — это не просто команда для создания объектов, а сложный механизм декларативного, инкрементального и безопасного управления состоянием кластера Kubernetes, основанный на сравнении и слиянии конфигураций.