kubectl apply против set: Выбор правильной команды для обновления ресурсов

Kubernetes, ведущая платформа оркестрации контейнеров, предоставляет мощные инструменты для управления жизненным циклом приложений. Ключевым аспектом этого управления является обновление существующих ресурсов, таких как Deployments, Services или ConfigMaps. Хотя kubectl предлагает несколько команд для этой цели, kubectl apply и семейство kubectl set/kubectl edit представляют две принципиально разные философии: декларативные и императивные обновления.

Понимание того, когда и как использовать каждый подход, имеет решающее значение для поддержания стабильных, надежных и поддающихся аудиту развертываний Kubernetes. Неправильное использование этих команд может привести к расхождению конфигурации (configuration drift), сложной отладке и операционным несоответствиям. Эта статья углубится в нюансы kubectl apply, kubectl set и kubectl edit, предоставив вам знания для принятия обоснованных решений при разработке стратегий обновления ресурсов.

Основная задача: управление состоянием ресурсов

В Kubernetes каждый компонент — от запущенного Pod до сетевого Service — представлен как объект API. Эти объекты имеют желаемое состояние, которое вы определяете в файлах манифестов YAML или JSON, и наблюдаемое состояние, которое отражает их текущую реальность в кластере. Основная цель любой команды обновления kubectl — согласовать эти два состояния, но метод согласования значительно различается.

Понимание kubectl apply: декларативный подход

kubectl apply является краеугольным камнем декларативного управления ресурсами в Kubernetes. При таком подходе вы определяете желаемое состояние ваших ресурсов в локальном файле конфигурации (или каталоге файлов), а затем даете команду Kubernetes привести состояние кластера в соответствие с этим определением.

Как работает kubectl apply (трехстороннее слияние)

Когда вы запускаете kubectl apply -f your-manifest.yaml, Kubernetes выполняет сложное трехстороннее слияние (three-way merge):

1. Конфигурация последнего применения (Last Applied Configuration): Состояние ресурса, в котором он был в последний раз применен с помощью kubectl apply. Это состояние хранится в аннотации (kubectl.kubernetes.io/last-applied-configuration) на активном объекте.
2. Активная конфигурация (Live Configuration): Текущее состояние ресурса на API-сервере Kubernetes.
3. Новая конфигурация (New Configuration): Состояние, определенное в вашем файле your-manifest.yaml.

Алгоритм слияния сравнивает эти три версии, чтобы определить, какие изменения необходимо внести. Он разумно обрабатывает конфликты, отдавая приоритет изменениям из новой конфигурации, при этом учитывая поля, которые были императивно изменены после последнего apply (хотя это может привести к проблемам, о которых будет сказано ниже).

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

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

Допустим, у вас есть файл deployment.yaml:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webapp
  labels:
    app: my-webapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-webapp
  template:
    metadata:
      labels:
        app: my-webapp
    spec:
      containers:
      - name: webapp-container
        image: nginx:1.21.0
        ports:
        - containerPort: 80

Чтобы создать или обновить этот Deployment, вам нужно выполнить:

kubectl apply -f deployment.yaml

Если вы позже измените image на nginx:1.22.0 в deployment.yaml и снова запустите kubectl apply, Kubernetes обновит Deployment, чтобы использовать новый образ, сохраняя при этом остальные настройки.

Преимущества kubectl apply

• Источник достоверной информации: Ваши файлы конфигурации становятся единственным источником достоверной информации о желаемом состоянии вашего кластера. Это хорошо согласуется с принципами GitOps.
• Аудит и контроль версий: Изменения отслеживаются в вашей системе контроля версий (например, Git), обеспечивая четкий контрольный журнал и легкий откат.
• Согласованность: Обеспечивает согласованность между средами (разработка, стейджинг, продакшен).
• Идемпотентность: Повторные операции apply имеют одинаковый эффект, предотвращая непреднамеренные модификации.
• Сложные обновления: Обрабатывает сложные обновления, включающие несколько типов ресурсов или значительные изменения во многих полях.

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

• Основной метод для создания и обновления всех ресурсов.
• При развертывании приложений через CI/CD-пайплайны.
• Для управления инфраструктурой как кодом (infrastructure-as-code).
• При работе в команде для обеспечения согласованных конфигураций.

Советы и предупреждения для kubectl apply

• Всегда поддерживайте актуальность файлов манифестов в соответствии с желаемым состоянием. Любые изменения, внесенные через kubectl set или kubectl edit и не отраженные в файлах манифестов, будут перезаписаны или вызовут конфликты слияния при следующем apply.
• Менеджеры полей (Field Managers): В Kubernetes 1.16+ представлен Server-Side Apply (SSA), который отслеживает «менеджера полей» (например, kubectl, контроллер), ответственного за каждое поле в ресурсе. Это помогает предотвратить конфликты, когда несколько источников изменяют один и тот же ресурс. Несмотря на мощность этого инструмента, имейте в виду, как различные инструменты могут взаимодействовать с управлением полями.

Понимание kubectl set и kubectl edit: императивный подход

kubectl set и kubectl edit относятся к семейству императивных команд. Вместо определения желаемого состояния в файле, вы напрямую инструктируете Kubernetes выполнить конкретные действия или изменить активные объекты внутри кластера. Эти команды отлично подходят для быстрых, разовых изменений, но имеют определенные оговорки.

kubectl set: сфокусированные императивные модификации

kubectl set предназначен для внесения конкретных, общих модификаций в ресурсы без необходимости обращаться к файлу манифеста. Он предлагает несколько подкоманд для изменения определенных полей.

Как работает kubectl set

kubectl set напрямую изменяет активный объект на API-сервере Kubernetes на основе аргументов командной строки, которые вы предоставляете. Он не взаимодействует с локальными файлами манифестов и не обновляет аннотацию last-applied-configuration.

Практический пример: установка образа

Чтобы обновить образ контейнера в Deployment под названием my-webapp:

kubeclt set image deployment/my-webapp webapp-container=nginx:1.22.0

Эта команда напрямую изменяет поле image для webapp-container в Deployment my-webapp. Если вы ранее управляли my-webapp с помощью kubectl apply, это изменение создаст «расхождение» (drift) между вашим локальным deployment.yaml и активным состоянием кластера.

Другие распространенные команды kubectl set:

• kubectl set resources: Для установки запросов/лимитов ресурсов.
• kubectl set env: Для добавления или обновления переменных среды.
• kubectl set selector: Для изменения селектора ресурса.

kubectl edit: интерактивные императивные модификации

kubectl edit позволяет напрямую изменять любое поле активного объекта ресурса в вашем кластере с помощью настроенного текстового редактора по умолчанию (например, vi, nano).

Как работает kubectl edit

Когда вы запускаете kubectl edit <resource-type>/<resource-name>:

1. kubectl извлекает текущее определение YAML активного ресурса с API-сервера.
2. Он открывает это определение в вашем локальном текстовом редакторе.
3. Вы вносите желаемые изменения и сохраняете файл.
4. Затем kubectl отправляет измененное определение обратно на API-сервер, который пытается применить изменения. Если есть синтаксические ошибки или недопустимые поля, изменения будут отклонены.

Как и kubectl set, kubectl edit также оперирует непосредственно активным объектом и не обновляет локальные файлы манифестов или аннотацию last-applied-configuration.

Практический пример: редактирование Deployment

Чтобы открыть Deployment my-webapp в вашем редакторе:

kubeclt edit deployment/my-webapp

В вашем редакторе откроется YAML-представление активного Deployment. Вы можете изменить такие поля, как replicas, image, или добавить новые аннотации/метки. После сохранения и закрытия редактора kubectl попытается применить эти изменения.

Преимущества kubectl set и kubectl edit

• Скорость: Отлично подходит для быстрых, одноразовых исправлений или отладки в среде разработки.
• Гибкость: Прямое изменение любого поля ресурса (с помощью edit).
• Разовые изменения: Полезно, когда у вас нет под рукой файла манифеста или вы не хотите создавать его для тривиального изменения.

Когда использовать kubectl set/kubectl edit

• Отладка в кластере разработки: Временное увеличение количества реплик или изменение образа для проверки исправления.
• Небольшие, некритические, временные изменения в непродакшен-средах.
• Изучение определений ресурсов: kubectl edit — удобный способ увидеть полный, активный YAML ресурса.

Предупреждения для kubectl set и kubectl edit

• Расхождение конфигурации: Изменения, внесенные с помощью set или edit, не отражаются в ваших локальных файлах манифестов. Следующий kubectl apply из вашего манифеста перезапишет эти императивные изменения или вызовет конфликты.
• Отсутствие возможности аудита: Эти изменения не отслеживаются в контроле версий, что затрудняет понимание того, кто, что и когда изменил, препятствуя отладке и соблюдению требований.
• Неидемпотентность: Многократное внесение одного и того же императивного изменения может привести к неожиданному поведению, если исходное состояние неизвестно.
• Риск ошибок: Ручное редактирование (особенно с помощью edit) увеличивает вероятность появления синтаксических ошибок или недействительных конфигураций.

Ключевые различия: kubectl apply против kubectl set/kubectl edit

Чтобы суммировать основные различия:

Характеристика	kubectl apply (Декларативный)	kubectl set/kubectl edit (Императивный)
Подход	Определяется желаемое состояние в файле, Kubernetes согласует.	Прямое манипулирование активными объектами или конкретными полями.
Источник достоверности	Локальные файлы конфигурации (например, репозиторий Git).	Сам активный объект кластера (эфемерный).
Идемпотентность	Да, применение одного и того же файла дает тот же результат.	Нет, не по сути. Каждая команда — это явное действие.
Аудируемость	Высокая (изменения отслеживаются в Git, last-applied-configuration).	Низкая (нет контроля версий, изменения немедленно применяются в кластере).
Управление конфликтами	Трехстороннее слияние, использует аннотацию last-applied-configuration.	Напрямую перезаписывает (для set) или объединяет в интерактивном режиме (для edit).
Сценарий использования	Продакшен-развертывания, CI/CD, GitOps, командная работа.	Быстрые исправления, отладка, разовые изменения вне продакшена.
Риск расхождения	Низкий, пока файлы актуальны.	Высокий, очень вероятно вызовет расхождение конфигурации с исходными файлами.

Выбор правильной команды: лучшие практики

Для продакшен-сред и совместной работы команд выбор очевиден:

• Всегда отдавайте предпочтение kubectl apply (или инструментам GitOps, построенным на его основе, таким как Argo CD или Flux CD) для управления вашими ресурсами Kubernetes. Это гарантирует, что состояние вашего кластера контролируется версиями, поддается аудиту и согласовано.
• Относитесь к файлам манифестов Kubernetes как к единственному источнику достоверной информации. Все изменения конфигураций ресурсов в идеале должны исходить из этих файлов и быть зафиксированы в системе контроля версий.

Императивные команды, такие как kubectl set и kubectl edit, следует резервировать для:

• Временной отладки или тестирования в кластерах разработки/стейджинга. Если вы их используете, убедитесь, что вы либо отменяете изменение, либо немедленно обновляете исходные файлы манифестов, чтобы отразить новое состояние.
• Разовых, эфемерных операций, которые не представляют желаемого долгосрочного состояния (например, краткосрочная приостановка Deployment).

Гибридный подход (использовать с осторожностью)

В некоторых сценариях может возникнуть необходимость быстрого исправления (hotfix) чего-либо в продакшене. Хотя это, как правило, не рекомендуется, если вы вынуждены использовать kubectl edit:

1. Поймите последствия расхождения конфигурации.
2. Немедленно зафиксируйте изменения, выполнив kubectl get <resource> -o yaml > new-manifest.yaml.
3. Как можно быстрее интегрируйте эти изменения обратно в файлы манифестов, контролируемые версиями.

Предупреждение: Регулярное использование kubectl edit или kubectl set в продакшене без обновления исходных манифестов приведет к неуправляемому, невосстановимому состоянию кластера, где фактическая конфигурация сильно расходится с тем, что думает ваша команда.

Заключение

kubectl apply, kubectl set и kubectl edit — это мощные инструменты для взаимодействия с кластером Kubernetes. Однако они служат разным целям и воплощают различные философии управления ресурсами. Понимая декларативную природу kubectl apply и императивную природу kubectl set и kubectl edit, вы можете внедрить лучшие практики, которые приведут к более стабильным, надежным и удобным в обслуживании развертываниям Kubernetes. Для практически всего постоянного управления ресурсами, особенно в продакшене, используйте kubectl apply и контролируйте версии файлов конфигурации. Резервируйте императивные команды для временного, разового устранения неполадок и убедитесь, что любые критические изменения быстро отражаются обратно в ваших декларативных манифестах. Эта дисциплина будет неоценимой для бесперебойной работы и слаженного сотрудничества в вашей среде Kubernetes.