apply, create, delete
Тема дорожной карты · Kubernetes
kubectl apply — команда декларативного управления ресурсами, создающая или обновляющая объекты Kubernetes путём сравнения поданного манифеста с последней применённой конфигурацией, хранящейся в аннотации kubectl.kubernetes.io/last-applied-configuration, и живым состоянием кластера. В отличие от kubectl create (завершающейся с ошибкой, если ресурс уже существует) или kubectl replace (требующей точного текущего состояния), kubectl apply -f manifest.yaml является идемпотентной и безопасной для повторного запуска в CI/CD-конвейерах и GitOps-рабочих процессах. Флаг --server-side (kubectl apply --server-side) делегирует управление полями API-серверу Kubernetes с использованием Server-Side Apply, который отслеживает владение отдельными полями по менеджеру и разрешает конфликты с использованием семантики менеджеров полей — рекомендуемый подход для production K8s-кластеров. Связанные команды: kubectl delete -f manifest.yaml удаляет ресурсы, определённые в манифесте, а kubectl diff -f manifest.yaml показывает предварительный просмотр того, что изменит kubectl apply, делая её важным шагом проверки перед применением вывода Helm-чарта или Kustomize к Kubernetes.
Как это работает
apply, create, delete — операция kubectl, которая общается с API-сервером Kubernetes. CLI читает ваш kubeconfig (по умолчанию ~/.kube/config), аутентифицирует (token, сертификат или OIDC), отправляет HTTPS-запрос API-серверу и печатает ответ. Для команд, изменяющих состояние (apply, patch, delete), API-сервер валидирует запрос, сохраняет в etcd и триггерит соответствующие контроллеры.
Когда применять
Используйте apply, create, delete в ежедневных операциях кластера: инспектирование текущего состояния (kubectl get/describe), применение декларативных изменений (kubectl apply -f), отладка pods (kubectl logs/exec), валидация конфигов перед деплоем. Для повторяющихся workflow оборачивайте в shell-скрипты или Helm chart; для one-off отладки kubectl напрямую быстрее, чем писать инструменты.
Типичные ошибки
Распространённые ловушки kubectl: забыли -n <namespace> и инспектируете не тот namespace; используете kubectl edit на production-ресурсах (нет audit trail — используйте GitOps); копипаст из Stack Overflow без чтения, что удаляется. Всегда выполняйте kubectl config current-context перед деструктивными командами, чтобы убедиться, что указываете на правильный кластер.