kubectl - Управление ресурсами
Быстрая навигация: используйте
Ctrl/Cmd + Fдля перехода к разделам. Ключевые слова:apply,create,edit,patch,set,delete,diff,ssa,replace,wait.
Создание и применение ресурсов (apply/create)
Официальная документация Декларативное управление объектами ↗
# Применить конфигурацию из файла
kubectl apply -f deployment.yaml
# Применить все yaml файлы из директории
kubectl apply -f ./configs/
# Применить конфигурацию из URL
kubectl apply -f https://example.com/config.yaml
# Создать namespace
kubectl create namespace <namespace-name>
kubectl create ns <namespace-name>
# Создать deployment императивно
kubectl create deployment <name> --image=<image>
# Создать service
kubectl create service clusterip <name> --tcp=80:8080
# Создать configmap из файла
kubectl create configmap <name> --from-file=config.txt
# Создать configmap из literal
kubectl create configmap <name> --from-literal=key=value
# Создать secret из literal
kubectl create secret generic <name> --from-literal=password=secret123
# Создать secret для docker registry
kubectl create secret docker-registry <name> --docker-server=<server> --docker-username=<user> --docker-password=<pass>
Редактирование ресурсов (edit)
Официальная документация kubectl edit ↗
# Редактировать deployment в редакторе по умолчанию
kubectl edit deployment <deployment-name>
# Редактировать service
kubectl edit service <service-name>
# Редактировать configmap
kubectl edit configmap <configmap-name>
# Редактировать в конкретном namespace
kubectl edit deployment <deployment-name> -n <namespace>
# Использовать конкретный редактор
KUBE_EDITOR="nano" kubectl edit deployment <deployment-name>
Патчинг ресурсов (patch)
Официальная документация Обновление объектов через patch ↗
# Изменить количество реплик через patch
kubectl patch deployment <deployment-name> -p '{"spec":{"replicas":3}}'
# Изменить image контейнера
kubectl patch deployment <deployment-name> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container>","image":"nginx:1.21"}]}}}}'
# Patch в формате merge
kubectl patch deployment <deployment-name> --type=merge -p '{"spec":{"replicas":5}}'
# Patch в формате JSON
kubectl patch deployment <deployment-name> --type=json -p='[{"op":"replace","path":"/spec/replicas","value":2}]'
# Добавить переменную окружения
kubectl patch deployment <deployment-name> --type=json -p='[{"op":"add","path":"/spec/template/spec/containers/0/env/-","value":{"name":"NEW_VAR","value":"value"}}]'
# Изменить service type
kubectl patch svc <service-name> -p '{"spec":{"type":"NodePort"}}'
Быстрое изменение ресурсов (set)
Официальная документация kubectl set ↗
# Изменить image контейнера
kubectl set image deployment/<deployment-name> <container-name>=nginx:1.21
# Изменить image для всех контейнеров
kubectl set image deployment/<deployment-name> *=nginx:1.21
# Изменить image и явно записать причину изменения в аннотацию
kubectl set image deployment/<deployment-name> nginx=nginx:1.21
kubectl annotate deployment/<deployment-name> kubernetes.io/change-cause="nginx=nginx:1.21" --overwrite
# Добавить переменную окружения
kubectl set env deployment/<deployment-name> ENV_VAR=value
# Добавить несколько переменных
kubectl set env deployment/<deployment-name> VAR1=value1 VAR2=value2
# Удалить переменную окружения
kubectl set env deployment/<deployment-name> ENV_VAR-
# Установить переменную из secret
kubectl set env deployment/<deployment-name> --from=secret/mysecret
# Установить переменную из configmap
kubectl set env deployment/<deployment-name> --from=configmap/myconfig
# Изменить resource limits
kubectl set resources deployment/<deployment-name> -c=nginx --limits=cpu=200m,memory=512Mi
# Изменить resource requests
kubectl set resources deployment/<deployment-name> -c=nginx --requests=cpu=100m,memory=256Mi
# Изменить service account
kubectl set serviceaccount deployment/<deployment-name> myserviceaccount
# Изменить selector для service
kubectl set selector service/<service-name> app=myapp,tier=frontend
Удаление ресурсов (delete)
Официальная документация kubectl delete ↗
# Удалить pod
kubectl delete pod <pod-name>
# Удалить deployment
kubectl delete deployment <deployment-name>
# Удалить service
kubectl delete service <service-name>
# Удалить ресурсы из файла
kubectl delete -f deployment.yaml
# Удалить все ресурсы по label
kubectl delete pods -l app=myapp
# Удалить namespace (и все ресурсы в нём)
kubectl delete namespace <namespace-name>
# Принудительное удаление пода: используйте только если обычное удаление зависло
kubectl delete pod <pod-name> --force --grace-period=0
# Удалить все поды в namespace
kubectl delete pods --all -n <namespace>
Сравнение конфигураций (diff)
Официальная документация kubectl diff ↗
# Сравнить локальный файл с текущим состоянием в кластере
kubectl diff -f deployment.yaml
# Сравнить все файлы из директории
kubectl diff -f ./configs/
# Сравнить конфигурацию из URL
kubectl diff -f https://example.com/config.yaml
# Сравнить с использованием kustomize
kubectl diff -k ./overlays/production/
# Показать diff перед apply (полезно в CI/CD)
kubectl diff -f deployment.yaml && kubectl apply -f deployment.yaml
# Diff с указанием server-side
kubectl diff -f deployment.yaml --server-side
# Проверить конфигурацию без применения (dry-run + diff)
kubectl apply -f deployment.yaml --dry-run=server
kubectl apply -f deployment.yaml --dry-run=client
# Валидация файла без применения
kubectl apply --validate=true --dry-run=client -f deployment.yaml
# Проверить что изменится при удалении
kubectl delete -f deployment.yaml --dry-run=client
Server-side apply (SSA)
Официальная документация Server-Side Apply ↗
# Применить манифест через server-side apply — рекомендуется для GitOps и мульти-акторных сред
kubectl apply -f deployment.yaml --server-side
# SSA с именованным field manager (фиксирует, кто владеет каждым полем)
kubectl apply -f deployment.yaml --server-side --field-manager=argocd
# Принудительно забрать ownership конфликтующих полей у другого менеджера
kubectl apply -f deployment.yaml --server-side --force-conflicts
# Dry-run с валидацией на стороне сервера
kubectl apply -f deployment.yaml --server-side --dry-run=server
# Diff текущего состояния в кластере vs локального файла (server-side логика)
kubectl diff -f deployment.yaml --server-side
# Посмотреть field manager-ы ресурса
kubectl get deployment my-deploy -o json | jq '.metadata.managedFields'
# Убрать managedFields из вывода для читаемости
kubectl get deployment my-deploy -o json | jq 'del(.metadata.managedFields)'
# или через плагин neat:
kubectl neat get deployment my-deploy -o yaml
# Удалить устаревшую аннотацию last-applied-configuration после перехода на SSA
kubectl annotate deployment my-deploy kubectl.kubernetes.io/last-applied-configuration-
# Применить целую директорию через SSA
kubectl apply -f ./manifests/ --server-side --field-manager=platform-team
# SSA vs client-side apply:
# Client-side: отслеживает изменения через аннотацию kubectl.kubernetes.io/last-applied-configuration
# Server-side: отслеживает ownership через .metadata.managedFields — безопасно при нескольких менеджерах
# SSA рекомендуется, когда несколько инструментов (ArgoCD, Helm, kubectl) работают с одним объектом
Замена и подключение к ресурсам (replace/attach)
Официальная документация kubectl replace ↗ kubectl attach ↗
# Полная замена ресурса из файла
kubectl replace -f deployment.yaml
# Принудительная замена (удалить и создать заново)
kubectl replace --force -f deployment.yaml
# Замена из stdin
cat deployment.yaml | kubectl replace -f -
# Подключиться к stdout/stderr запущенного контейнера
kubectl attach <pod-name>
# Интерактивное подключение к контейнеру (stdin + tty)
kubectl attach -it <pod-name>
# Подключение к конкретному контейнеру
kubectl attach <pod-name> -c <container-name>
# Подключение в определённом namespace
kubectl attach <pod-name> -n <namespace>
# Конвертировать конфигурацию между версиями API (требует отдельного kubectl-convert plugin)
kubectl convert -f deployment.yaml --output-version apps/v1
# Просмотреть completion для bash/zsh
kubectl completion bash
kubectl completion zsh
# Включить автодополнение (добавить в .bashrc/.zshrc)
# source <(kubectl completion bash)
# source <(kubectl completion zsh)
# Создать alias для kubectl
# alias k=kubectl
# complete -o default -F __start_kubectl k
Ожидание готовности ресурсов (wait)
Официальная документация kubectl wait ↗
# Дождаться, пока под перейдёт в состояние Ready
kubectl wait pod/<pod-name> --for=condition=Ready
# Дождаться готовности пода с таймаутом (по умолчанию 30s)
kubectl wait pod/<pod-name> --for=condition=Ready --timeout=120s
# Дождаться готовности всех подов с меткой
kubectl wait pods -l app=myapp --for=condition=Ready --timeout=60s
# Дождаться завершения деплоймента (все реплики готовы)
kubectl wait deployment/<deploy-name> --for=condition=Available --timeout=300s
# Дождаться завершения Job (условие Complete)
kubectl wait job/<job-name> --for=condition=Complete --timeout=120s
# Дождаться, пока Job не провалится (условие Failed)
kubectl wait job/<job-name> --for=condition=Failed --timeout=60s
# Дождаться удаления ресурса
kubectl wait pod/<pod-name> --for=delete --timeout=60s
# Дождаться удаления всех подов с меткой
kubectl wait pods -l app=myapp --for=delete --timeout=120s
# Дождаться готовности ноды
kubectl wait node/<node-name> --for=condition=Ready --timeout=300s
# Дождаться готовности всех нод
kubectl wait nodes --all --for=condition=Ready --timeout=300s
# Дождаться установки CRD (Custom Resource Definition)
kubectl wait crd/<crd-name> --for=condition=Established --timeout=60s
# Дождаться в конкретном неймспейсе
kubectl wait pod/<pod-name> -n <namespace> --for=condition=Ready --timeout=60s
# Дождаться готовности нескольких ресурсов одного типа
kubectl wait pods -l tier=backend --for=condition=Ready --all-namespaces --timeout=120s
# Дождаться PVC в состоянии Bound
kubectl wait pvc/<pvc-name> --for=jsonpath='{.status.phase}'=Bound --timeout=60s
# Дождаться произвольного поля через jsonpath (k8s >= 1.23)
kubectl wait deployment/<deploy-name> \
--for=jsonpath='{.status.readyReplicas}'=3 --timeout=120s
# Пример использования в CI/CD пайплайне
kubectl apply -f deployment.yaml
kubectl wait deployment/myapp --for=condition=Available --timeout=300s
echo "Деплой завершён успешно"
# Проверить сразу несколько условий (через несколько вызовов)
kubectl wait pod/<pod-name> --for=condition=Initialized --timeout=30s
kubectl wait pod/<pod-name> --for=condition=Ready --timeout=120s
kubectl wait pod/<pod-name> --for=condition=ContainersReady --timeout=120s
# Доступные условия для подов:
# Initialized — все init-контейнеры завершились
# Ready — под готов принимать трафик
# ContainersReady — все контейнеры пода готовы
# PodScheduled — под назначен на ноду
# Доступные условия для нод:
# Ready — нода в рабочем состоянии
# MemoryPressure — нехватка памяти
# DiskPressure — нехватка дискового пространства
# PIDPressure — нехватка PID
# NetworkUnavailable — сеть не настроена