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

kubectl — ваш пульт управления кластером, а манифесты в YAML — основной способ описывать желаемое состояние.

Декларативный подход: вы описываете в файле, ЧТО должно быть в кластере, а не пишете шаги КАК этого добиться — приведение к нужному состоянию берёт на себя Kubernetes.

kubectl — клиент, который переводит ваши команды в запросы к API server. Любое действие в кластере проходит через него.

Два стиля работы

Императивный — вы командуете по шагам: «создай», «измени», «удали». Быстро для разовых проб:

kubectl run web --image=nginx

Декларативный — вы пишете манифест с описанием объекта и применяете его. Это основной способ в реальной работе, потому что файл можно хранить в Git, ревьюить и применять повторно.

Анатомия манифеста

Манифест — это YAML-файл. Почти у каждого объекта есть четыре поля верхнего уровня:

apiVersion: v1          # версия API для этого объекта
kind: Pod               # тип объекта
metadata:               # имя, метки, namespace
  name: my-pod
spec:                   # желаемое состояние (что внутри)
  containers:
    - name: web
      image: nginx:1.27

• apiVersion — какая версия API описывает объект (для Pod это v1, для Deployment — apps/v1).
• kind — тип объекта (Pod, Deployment, Service…).
• metadata — идентификация: имя, метки, namespace.
• spec — описание желаемого состояния. Главное поле.

kubectl apply — рабочая лошадка

Сохраните манифест в файл pod.yaml и примените:

kubectl apply -f pod.yaml

Вывод:

pod/my-pod created

Изменили файл (например, версию образа) и снова apply — Kubernetes сам вычислит разницу и обновит объект. Команда идемпотентна: повторный запуск без изменений ничего не сломает.

Идемпотентность: применить один и тот же манифест дважды — то же самое, что один раз. Состояние сходится к описанному, а не накапливает изменения.

Почему apply, а не run

Императивные команды удобны на пробу, но состояние «уплывает»: через неделю никто не вспомнит, какими флагами запускали сервис. Манифест в Git — это документация и история изменений одновременно. Такой подход называют GitOps: Git как источник правды о кластере.

Итог

• kubectl общается с кластером через API server.
• Манифест описывает желаемое состояние полями apiVersion, kind, metadata, spec.
• kubectl apply -f идемпотентно приводит кластер к описанному состоянию — это основной рабочий приём.