⚠️ Эта страница устарела и будет удалена в одном из будущих выпусков.

Используйте новую справочную документацию kubectl. Чтобы просмотреть её на одной странице, см. версию для печати.

НАЧАЛО РАБОТЫ

В этом разделе описаны основные команды для запуска рабочей нагрузки в кластере.

• run запустит в кластере один или несколько экземпляров образа контейнера.
• expose распределит трафик между запущенными экземплярами и может создать прокси-сервер высокой доступности для доступа к контейнерам извне кластера.

После запуска рабочих нагрузок можно использовать команды из раздела РАБОТА С ПРИЛОЖЕНИЯМИ, чтобы проверить их.

create

Создать pod, используя данные из pod.json

kubectl create -f ./pod.json

Создать pod на основе JSON, переданного через stdin

cat pod.json | kubectl create -f -

Отредактировать данные в registry.yaml в формате JSON, а затем создать ресурс, используя отредактированные данные

kubectl create -f registry.yaml --edit -o json

Создать ресурс из файла или из stdin.

Поддерживаются форматы JSON и YAML.

Использование

$ kubectl create -f FILENAME

Флаги

clusterrole

Создать роль кластера с именем "pod-reader", которая разрешает пользователю выполнять операции "get", "watch" и "list" над pod

kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

Создать роль кластера с именем "pod-reader" и указанным ResourceName

kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

Создать роль кластера с именем "foo" и указанной группой API

kubectl create clusterrole foo --verb=get,list,watch --resource=rs.apps

Создать роль кластера с именем "foo" и указанным SubResource

kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

Создать роль кластера с именем "foo" и указанным NonResourceURL

kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*

Создать роль кластера с именем "monitoring" и указанным AggregationRule

kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

Создать роль кластера.

Использование

$ kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename] [--dry-run=server|client|none]

Флаги

clusterrolebinding

Создать привязку роли кластера для user1, user2 и group1, используя роль кластера cluster-admin

kubectl create clusterrolebinding cluster-admin --clusterrole=cluster-admin --user=user1 --user=user2 --group=group1

Создать привязку роли кластера для указанной роли кластера.

Использование

$ kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Флаги

configmap

Создать новую карту конфигурации с именем my-config на основе папки bar

kubectl create configmap my-config --from-file=path/to/bar

Создать новую карту конфигурации с именем my-config, указав ключи вместо имён файлов на диске

kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt

Создать новую карту конфигурации с именем my-config и ключами key1=config1 и key2=config2

kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

Создать новую карту конфигурации с именем my-config на основе пар ключ=значение из файла

kubectl create configmap my-config --from-file=path/to/bar

Создать новую карту конфигурации с именем my-config на основе файла окружения

kubectl create configmap my-config --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env

Создать карту конфигурации на основе файла, каталога или указанного литерального значения.

Одна карта конфигурации может содержать одну или несколько пар ключ/значение.

При создании карты конфигурации на основе файла ключем по умолчанию будет имя файла без пути, а значением — содержимое файла. Если имя файла не является допустимым ключом, можно указать другой ключ.

При создании карты конфигурации на основе каталога в неё будут включены все файлы каталога, имена которых без пути являются допустимыми ключами. Все элементы каталога, кроме обычных файлов, игнорируются (например, подкаталоги, символические ссылки, устройства, каналы и т. д.).

Использование

$ kubectl create configmap NAME [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run=server|client|none]

Флаги

cronjob

Создать задание cron

kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *"

Создать задание cron с командой

kubectl create cronjob my-job --image=busybox --schedule="*/1 * * * *" -- date

Создать задание cron с указанным именем.

Использование

$ kubectl create cronjob NAME --image=image --schedule='0/5 * * * ?' -- [COMMAND] [args...]

Флаги

deployment

Создать deployment с именем my-dep, запускающий образ busybox

kubectl create deployment my-dep --image=busybox

Создать deployment с командой

kubectl create deployment my-dep --image=busybox -- date

Создать deployment с именем my-dep, запускающий образ nginx с 3 репликами

kubectl create deployment my-dep --image=nginx --replicas=3

Создать deployment с именем my-dep, запускающий образ busybox и открывающий порт 5701

kubectl create deployment my-dep --image=busybox --port=5701

Создать deployment с указанным именем.

Использование

$ kubectl create deployment NAME --image=image -- [COMMAND] [args...]

Флаги

ingress

Создать один ingress с именем 'simple', который направляет запросы к foo.com/bar на svc # svc1:8080 с TLS-секретом "my-cert"

kubectl create ingress simple --rule="foo.com/bar=svc1:8080,tls=my-cert"

Создать универсальный ingress для пути "/path", направляющий запросы к сервису svc:port, с классом Ingress "otheringress"

kubectl create ingress catch-all --class=otheringress --rule="/path=svc:port"

Создать ingress с двумя аннотациями: ingress.annotation1 и ingress.annotations2

kubectl create ingress annotated --class=default --rule="foo.com/bar=svc:port" \ --annotation ingress.annotation1=foo \ --annotation ingress.annotation2=bla

Создать ingress с одним хостом и несколькими путями

kubectl create ingress multipath --class=default \ --rule="foo.com/=svc:port" \ --rule="foo.com/admin/=svcadmin:portadmin"

Создать ingress с несколькими хостами и типом пути Prefix

kubectl create ingress ingress1 --class=default \ --rule="foo.com/path*=svc:8080" \ --rule="bar.com/admin*=svc2:http"

Создать ingress с включенным TLS, используя сертификат ingress по умолчанию и разные типы путей

kubectl create ingress ingtls --class=default \ --rule="foo.com/=svc:https,tls" \ --rule="foo.com/path/subpath*=othersvc:8080"

Создать ingress с включенным TLS, используя конкретный секрет и тип пути Prefix

kubectl create ingress ingsecret --class=default \ --rule="foo.com/*=svc:8080,tls=secret1"

Создать ingress с backend по умолчанию

kubectl create ingress ingdefault --class=default \ --default-backend=defaultsvc:http \ --rule="foo.com/*=svc:8080,tls=secret1"

Создать ingress с указанным именем.

Использование

$ kubectl create ingress NAME --rule=host/path=service:port[,tls[=secret]]

Флаги

job

Создать задание

kubectl create job my-job --image=busybox

Создать задание с командой

kubectl create job my-job --image=busybox -- date

Создать задание на основе cron job с именем "a-cronjob"

kubectl create job test-job --from=cronjob/a-cronjob

Создать задание с указанным именем.

Использование

$ kubectl create job NAME --image=image [--from=cronjob/name] -- [COMMAND] [args...]

Флаги

namespace

Создать пространство имен с именем my-namespace

kubectl create namespace my-namespace

Создать пространство имен с указанным именем.

Использование

$ kubectl create namespace NAME [--dry-run=server|client|none]

Флаги

poddisruptionbudget

Создать бюджет disruption pod с именем my-pdb, который выберет все pod с меткой app=rails и потребует, чтобы хотя бы один из них был доступен в любой момент времени

kubectl create poddisruptionbudget my-pdb --selector=app=rails --min-available=1

Создать бюджет disruption pod с именем my-pdb, который выберет все pod с меткой app=nginx и потребует, чтобы в любой момент времени были доступны не менее половины выбранных pod

kubectl create pdb my-pdb --selector=app=nginx --min-available=50%

Создать бюджет disruption pod с указанными именем, селектором и минимальным количеством доступных pod.

Использование

$ kubectl create poddisruptionbudget NAME --selector=SELECTOR --min-available=N [--dry-run=server|client|none]

Флаги

priorityclass

Создать класс приоритета с именем high-priority

kubectl create priorityclass high-priority --value=1000 --description="high priority"

Создать класс приоритета с именем default-priority, который будет считаться глобальным приоритетом по умолчанию

kubectl create priorityclass default-priority --value=1000 --global-default=true --description="default priority"

Создать класс приоритета с именем high-priority, который не может вытеснять pod с более низким приоритетом

kubectl create priorityclass high-priority --value=1000 --description="high priority" --preemption-policy="Never"

Создать класс приоритета с указанными именем, значением, параметром globalDefault и описанием.

Использование

$ kubectl create priorityclass NAME --value=VALUE --global-default=BOOL [--dry-run=server|client|none]

Флаги

quota

Создать квоту ресурсов с именем my-quota

kubectl create quota my-quota --hard=cpu=1,memory=1G,pods=2,services=3,replicationcontrollers=2,resourcequotas=1,secrets=5,persistentvolumeclaims=10

Создать квоту ресурсов с именем best-effort

kubectl create quota best-effort --hard=pods=100 --scopes=BestEffort

Создать квоту ресурсов с указанными именем, жесткими ограничениями и необязательными областями действия.

Использование

$ kubectl create quota NAME [--hard=key1=value1,key2=value2] [--scopes=Scope1,Scope2] [--dry-run=server|client|none]

Флаги

role

Создать роль с именем "pod-reader", которая разрешает пользователю выполнять для pod операции "get", "watch" и "list"

kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

Создать роль с именем "pod-reader" с указанным ResourceName

kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

Создать роль с именем "foo" с указанной группой API

kubectl create role foo --verb=get,list,watch --resource=rs.apps

Создать роль с именем "foo" с указанным SubResource

kubectl create role foo --verb=get,list,watch --resource=pods,pods/status

Создать роль с одним правилом.

Использование

$ kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] [--dry-run=server|client|none]

Флаги

rolebinding

Создать привязку роли для user1, user2 и group1, используя кластерную роль admin

kubectl create rolebinding admin --clusterrole=admin --user=user1 --user=user2 --group=group1

Создать привязку роли для определённой роли или кластерной роли.

Использование

$ kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Флаги

secret

Создать секрет с помощью указанной подкоманды.

Использование

$ kubectl create secret

secret docker-registry

Если у вас ещё нет файла .dockercfg, вы можете создать секрет dockercfg напрямую с помощью следующей команды:

kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

Создать секрет с именем my-secret из ~/.docker/config.json

kubectl create secret docker-registry my-secret --from-file=.dockerconfigjson=path/to/.docker/config.json

Создать новый секрет для использования с реестрами Docker.

Секреты Dockercfg используются для аутентификации в реестрах Docker.

При отправке образов с помощью командной строки Docker для аутентификации в определённом реестре выполните: '$ docker login DOCKER_REGISTRY_SERVER --username=DOCKER_USER --password=DOCKER_PASSWORD --email=DOCKER_EMAIL'.

В результате будет создан файл ~/.dockercfg, который используется последующими командами 'docker push' и 'docker pull' для аутентификации в реестре. Адрес электронной почты указывать необязательно.

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

Использование

$ kubectl create secret docker-registry NAME --docker-username=user --docker-password=password --docker-email=email [--docker-server=string] [--from-file=[key=]source] [--dry-run=server|client|none]

Флаги

secret generic

Создать секрет с именем my-secret, добавив в него ключ для каждого файла в каталоге bar

kubectl create secret generic my-secret --from-file=path/to/bar

Создать секрет с именем my-secret, указав ключи вместо имён файлов на диске

kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-file=ssh-publickey=path/to/id_rsa.pub

Создать секрет с именем my-secret с key1=supersecret и key2=topsecret

kubectl create secret generic my-secret --from-literal=key1=supersecret --from-literal=key2=topsecret

Создать секрет с именем my-secret, используя сочетание файла и литерального значения

kubectl create secret generic my-secret --from-file=ssh-privatekey=path/to/id_rsa --from-literal=passphrase=topsecret

Создать секрет с именем my-secret из файлов окружения

kubectl create secret generic my-secret --from-env-file=path/to/foo.env --from-env-file=path/to/bar.env

Создать секрет на основе файла, каталога или заданного литерального значения.

Один секрет может содержать одну или несколько пар ключ/значение.

При создании секрета на основе файла ключем по умолчанию будет базовое имя файла, а значением — его содержимое. Если базовое имя недопустимо в качестве ключа или вы хотите задать собственное имя, можно указать другой ключ.

При создании секрета на основе каталога в секрет будут включены все файлы каталога, базовые имена которых являются допустимыми ключами. Все элементы каталога, кроме обычных файлов, игнорируются (например, подкаталоги, символические ссылки, устройства, каналы и т. д.).

Использование

$ kubectl create secret generic NAME [--type=string] [--from-file=[key=]source] [--from-literal=key1=value1] [--dry-run=server|client|none]

Флаги

secret tls

Создать новый TLS-секрет с именем tls-secret из указанной пары ключей

kubectl create secret tls tls-secret --cert=path/to/tls.cert --key=path/to/tls.key

Создать TLS-секрет из указанной пары открытого и закрытого ключей.

Пара открытого и закрытого ключей должна существовать заранее. Сертификат открытого ключа должен быть закодирован в формате .PEM и соответствовать указанному закрытому ключу.

Использование

$ kubectl create secret tls NAME --cert=path/to/cert/file --key=path/to/key/file [--dry-run=server|client|none]

Флаги

service

Создать сервис с помощью указанной подкоманды.

Использование

$ kubectl create service

service clusterip

Создать новый сервис ClusterIP с именем my-cs

kubectl create service clusterip my-cs --tcp=5678:8080

Создать новый сервис ClusterIP с именем my-cs (в режиме без головного узла)

kubectl create service clusterip my-cs --clusterip="None"

Создать сервис ClusterIP с указанным именем.

Использование

$ kubectl create service clusterip NAME [--tcp=<port>:<targetPort>] [--dry-run=server|client|none]

Флаги

service externalname

Создать новый сервис ExternalName с именем my-ns

kubectl create service externalname my-ns --external-name bar.com

Создать сервис ExternalName с указанным именем.

Сервис ExternalName ссылается на внешний DNS-адрес, а не только на поды, что позволяет авторам приложений обращаться к сервисам, размещённым вне платформы, в других кластерах или локально.

Использование

$ kubectl create service externalname NAME --external-name external.name [--dry-run=server|client|none]

Флаги

service loadbalancer

Создать новый сервис LoadBalancer с именем my-lbs

kubectl create service loadbalancer my-lbs --tcp=5678:8080

Создать сервис LoadBalancer с указанным именем.

Использование

$ kubectl create service loadbalancer NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

Флаги

service nodeport

Создать новый сервис NodePort с именем my-ns

kubectl create service nodeport my-ns --tcp=5678:8080

Создайте службу NodePort с указанным именем.

Использование

$ kubectl create service nodeport NAME [--tcp=port:targetPort] [--dry-run=server|client|none]

Флаги

serviceaccount

Создайте учётную запись службы с именем my-service-account

kubectl create serviceaccount my-service-account

Создайте учётную запись службы с указанным именем.

Использование

$ kubectl create serviceaccount NAME [--dry-run=server|client|none]

Флаги

token

Запросите токен для аутентификации в kube-apiserver от имени учётной записи службы «myapp» в текущем пространстве имён

kubectl create token myapp

Запросите токен для учётной записи службы в пользовательском пространстве имён

kubectl create token myapp --namespace myns

Запросите токен с пользовательским сроком действия

kubectl create token myapp --duration 10m

Запросите токен с пользовательской аудиторией

kubectl create token myapp --audience https://example.com

Запросите токен, связанный с экземпляром объекта Secret

kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret

Запросите токен, связанный с экземпляром объекта Secret с определённым uid

kubectl create token myapp --bound-object-kind Secret --bound-object-name mysecret --bound-object-uid 0d4691ed-659b-4935-a832-355f77ee47cc

Запросите токен учётной записи службы.

Использование

$ kubectl create token SERVICE_ACCOUNT_NAME

Флаги

get

Выведите список всех pod в формате вывода ps

kubectl get pods

Выведите список всех pod в формате вывода ps с дополнительной информацией (например, именем узла)

kubectl get pods -o wide

Выведите список одного контроллера репликации с указанным NAME в формате вывода ps

kubectl get replicationcontroller web

Выведите список развёртываний в формате JSON, в версии «v1» группы API «apps»

kubectl get deployments.v1.apps -o json

Выведите один pod в формате JSON

kubectl get -o json pod web-pod-13je7

Выведите ресурс типа pod с именем, указанным в «pod.yaml», в формате JSON

kubectl get -f pod.yaml -o json

Выведите список ресурсов из каталога с файлом kustomization.yaml, например dir/kustomization.yaml

kubectl get -k dir/

Выведите только значение фазы указанного pod

kubectl get -o template pod/web-pod-13je7 --template={{.status.phase}}

Выведите сведения о ресурсах в пользовательских столбцах

kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image

Выведите список всех контроллеров репликации и служб вместе в формате вывода ps

kubectl get rc,services

Выведите список одного или нескольких ресурсов по их типу и именам

kubectl get rc/web service/frontend pods/web-pod-13je7

Выведите подресурс status для одного pod.

kubectl get pod web-pod-13je7 --subresource status

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

Выводит таблицу с наиболее важной информацией об указанных ресурсах. Список можно отфильтровать с помощью селектора меток и флага --selector. Если указанный тип ресурса относится к пространству имён, вы увидите результаты только для текущего пространства имён, если не укажете --all-namespaces.

Указав формат вывода «template» и передав шаблон Go в качестве значения флага --template, можно отфильтровать атрибуты полученных ресурсов.

Используйте «kubectl api-resources», чтобы просмотреть полный список поддерживаемых ресурсов.

Использование

$ kubectl get [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file|custom-columns|custom-columns-file|wide] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags]

Флаги

run

Запустить pod nginx

kubectl run nginx --image=nginx

Запустить pod hazelcast и открыть порт 5701 контейнера

kubectl run hazelcast --image=hazelcast/hazelcast --port=5701

Запустить pod hazelcast и задать в контейнере переменные окружения "DNS_DOMAIN=cluster" и "POD_NAMESPACE=default"

kubectl run hazelcast --image=hazelcast/hazelcast --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default"

Запустить pod hazelcast и задать в контейнере метки "app=hazelcast" и "env=prod"

kubectl run hazelcast --image=hazelcast/hazelcast --labels="app=hazelcast,env=prod"

Выполнить пробный запуск; вывести соответствующие объекты API, не создавая их

kubectl run nginx --image=nginx --dry-run=client

Запустить pod nginx, переопределив спецификацию частичным набором значений, разобранных из JSON

kubectl run nginx --image=nginx --overrides='{ "apiVersion": "v1", "spec": { ... } }'

Запустить pod busybox в интерактивном режиме и не перезапускать его при завершении работы

kubectl run -i -t busybox --image=busybox --restart=Never

Запустить pod nginx с командой по умолчанию, но использовать для неё пользовательские аргументы (arg1 .. argN)

kubectl run nginx --image=nginx -- <arg1> <arg2> ... <argN>

Запустить pod nginx с другой командой и пользовательскими аргументами

kubectl run nginx --image=nginx --command -- <cmd> <arg1> ... <argN>

Создать и запустить указанный образ в pod.

Использование

$ kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server|client] [--overrides=inline-json] [--command] -- [COMMAND] [args...]

Параметры

expose

Создать сервис для реплицированного nginx, который обслуживает порт 80 и подключается к контейнерам через порт 8000

kubectl expose rc nginx --port=80 --target-port=8000

Создать сервис для контроллера репликации, тип и имя которого указаны в "nginx-controller.yaml", который обслуживает порт 80 и подключается к контейнерам через порт 8000

kubectl expose -f nginx-controller.yaml --port=80 --target-port=8000

Создать сервис для pod valid-pod, который обслуживает порт 444 под именем "frontend"

kubectl expose pod valid-pod --port=444 --name=frontend

Создать второй сервис на основе сервиса выше, открыв порт контейнера 8443 как порт 443 под именем "nginx-https"

kubectl expose service nginx --port=443 --target-port=8443 --name=nginx-https

Создать сервис для реплицированного потокового приложения на порту 4100, распределяющий трафик UDP и имеющий имя 'video-stream'.

kubectl expose rc streamer --port=4100 --protocol=UDP --name=video-stream

Создать сервис для реплицированного nginx с использованием ReplicaSet, который обслуживает порт 80 и подключается к контейнерам через порт 8000

kubectl expose rs nginx --port=80 --target-port=8000

Создать сервис для deployment nginx, который обслуживает порт 80 и подключается к контейнерам через порт 8000

kubectl expose deployment nginx --port=80 --target-port=8000

Предоставить ресурс как новый сервис Kubernetes.

Найти deployment, service, replica set, replication controller или pod по имени и использовать селектор этого ресурса в качестве селектора нового сервиса на указанном порту. Deployment или replica set будет предоставлен как сервис только в том случае, если его селектор можно преобразовать в селектор, поддерживаемый сервисом, то есть когда селектор содержит только компонент matchLabels. Обратите внимание: если параметр --port не задан, а у предоставляемого ресурса несколько портов, новый сервис повторно использует их все. Кроме того, если метки не указаны, новый сервис повторно использует метки предоставляемого ресурса.

Возможные ресурсы (без учёта регистра):

pod (po), service (svc), replicationcontroller (rc), deployment (deploy), replicaset (rs)

Использование

$ kubectl expose (-f FILENAME | TYPE NAME) [--port=port] [--protocol=TCP|UDP|SCTP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type]

Параметры

delete

Удалить pod, используя тип и имя, указанные в pod.json

kubectl delete -f ./pod.json

Удалить ресурсы из каталога, содержащего kustomization.yaml, например dir/kustomization.yaml

kubectl delete -k dir

Удалить ресурсы из всех файлов с расширением '.json', то есть раскрыть подстановочные символы в именах файлов

kubectl delete -f '*.json'

Удалить pod на основе типа и имени в JSON, переданном через stdin

cat pod.json | kubectl delete -f -

Удалить pods и services с одинаковыми именами "baz" и "foo"

kubectl delete pod,service baz foo

Удалить pods и services с меткой name=myLabel

kubectl delete pods,services -l name=myLabel

Удалить pod с минимальной задержкой

kubectl delete pod foo --now

Принудительно удалить pod на неработающем узле

kubectl delete pod foo --force

Удалить все pods

kubectl delete pods --all

Удалить ресурсы по именам файлов, из stdin, по типам ресурсов и именам либо по типам ресурсов и селектору меток.

Допускаются форматы JSON и YAML. Можно указать только один тип аргументов: имена файлов, типы ресурсов и имена либо типы ресурсов и селектор меток.

Некоторые ресурсы, например pods, поддерживают корректное удаление. Для таких ресурсов задан период ожидания по умолчанию перед принудительным завершением (период ожидания), но это значение можно переопределить с помощью флага --grace-period или передать --now, чтобы установить период ожидания, равный 1. Поскольку такие ресурсы часто представляют сущности в кластере, подтверждение удаления может прийти не сразу. Если узел, на котором размещен pod, не работает или не может связаться с API-сервером, завершение может занять значительно больше времени, чем период ожидания. Чтобы принудительно удалить ресурс, необходимо указать флаг --force. Примечание: корректное удаление поддерживается только некоторыми ресурсами. Если поддержка отсутствует, флаг --grace-period игнорируется.

ВАЖНО: принудительное удаление pods не ожидает подтверждения завершения процессов pod, поэтому эти процессы могут продолжать работать, пока узел не обнаружит удаление и не завершит корректное удаление. Если процессы используют общее хранилище или обращаются к удаленному API и идентифицируют себя по имени pod, принудительное удаление таких pods может привести к тому, что на разных машинах будут работать несколько процессов с одним и тем же идентификатором, что может вызвать повреждение или несогласованность данных. Принудительно удаляйте pods, только если уверены, что pod завершен, или если ваше приложение может допустить одновременную работу нескольких копий одного pod. Кроме того, если принудительно удалить pods, планировщик может разместить новые pods на этих узлах до того, как узел освободит ресурсы, и эти pods будут немедленно вытеснены.

Обратите внимание, что команда delete НЕ выполняет проверку версии ресурса, поэтому, если кто-либо отправит обновление ресурса одновременно с вашей командой удаления, это обновление будет потеряно вместе с остальной частью ресурса.

После удаления CustomResourceDefinition инвалидация кэша обнаружения может занять до 6 часов. Если вы не хотите ждать, можно выполнить "kubectl api-resources", чтобы обновить кэш обнаружения.

Использование

$ kubectl delete ([-f FILENAME] | [-k DIRECTORY] | TYPE [(NAME | -l label | --all)])

Флаги

УПРАВЛЕНИЕ ПРИЛОЖЕНИЯМИ

В этом разделе описаны команды для создания, обновления, удаления и просмотра рабочих нагрузок в кластере Kubernetes.

apply

Применить конфигурацию из pod.json к pod

kubectl apply -f ./pod.json

Применить ресурсы из каталога, содержащего kustomization.yaml, например dir/kustomization.yaml

kubectl apply -k dir/

Применить к pod JSON, переданный через stdin

cat pod.json | kubectl apply -f -

Применить конфигурацию из всех файлов с расширением '.json', то есть раскрыть подстановочные символы в именах файлов

kubectl apply -f '*.json'

Примечание: --prune все еще находится на стадии Alpha # Применить конфигурацию из manifest.yaml, соответствующую метке app=nginx, и удалить все остальные ресурсы, которых нет в файле и которые соответствуют метке app=nginx

kubectl apply --prune -f manifest.yaml -l app=nginx

Применить конфигурацию из manifest.yaml и удалить все остальные config maps, которых нет в файле

kubectl apply --prune -f manifest.yaml --all --prune-allowlist=core/v1/ConfigMap

Применить конфигурацию к ресурсу по имени файла или из stdin. Необходимо указать имя ресурса. Если ресурса еще нет, он будет создан. Для использования 'apply' сначала всегда создавайте ресурс с помощью 'apply' или 'create --save-config'.

Допускаются форматы JSON и YAML.

Отказ от ответственности для Alpha: функциональность --prune еще не завершена. Не используйте ее, если не знаете о ее текущем состоянии. См. https://issues.k8s.io/34274.

Использование

$ kubectl apply (-f FILENAME | -k DIRECTORY)

Флаги

edit-last-applied

Изменить аннотации last-applied-configuration ресурса, указав его тип и имя; формат YAML

kubectl apply edit-last-applied deployment/nginx

Изменить аннотации last-applied-configuration ресурса из файла; формат JSON

kubectl apply edit-last-applied -f deploy.yaml -o json

Изменить последние аннотации last-applied-configuration ресурсов с помощью редактора по умолчанию.

Команда edit-last-applied позволяет напрямую изменять любые ресурсы API, которые можно получить с помощью инструментов командной строки. Она откроет редактор, заданный переменными среды KUBE_EDITOR или EDITOR, либо, если они не заданы, использует 'vi' в Linux или 'notepad' в Windows. Можно редактировать несколько объектов, однако изменения применяются по одному. Команда принимает имена файлов, а также аргументы командной строки, но указанные файлы должны содержать ранее сохранённые версии ресурсов.

По умолчанию используется формат YAML. Чтобы редактировать в формате JSON, укажите "-o json".

Флаг --windows-line-endings можно использовать для принудительного задания окончаний строк Windows; в противном случае будут использоваться окончания строк, принятые в вашей операционной системе.

Если при обновлении возникает ошибка, на диске будет создан временный файл с изменениями, которые не удалось применить. Чаще всего ошибка при обновлении ресурса возникает, когда другой редактор изменяет ресурс на сервере. В этом случае необходимо применить изменения к более новой версии ресурса либо обновить временную сохранённую копию, добавив в неё последнюю версию ресурса.

Использование

$ kubectl apply edit-last-applied (RESOURCE/NAME | -f FILENAME)

Флаги

set-last-applied

Задать для ресурса last-applied-configuration в соответствии с содержимым файла

kubectl apply set-last-applied -f deploy.yaml

Выполнить set-last-applied для каждого файла конфигурации в каталоге

kubectl apply set-last-applied -f path/

Задать для ресурса last-applied-configuration в соответствии с содержимым файла; создать аннотацию, если она ещё не существует

kubectl apply set-last-applied -f deploy.yaml --create-annotation=true

Задать последние аннотации last-applied-configuration, приведя их в соответствие с содержимым файла. В результате last-applied-configuration обновится так, как если бы была выполнена команда 'kubectl apply -f ', при этом другие части объекта не изменятся.

Использование

$ kubectl apply set-last-applied -f FILENAME

Флаги

view-last-applied

Просмотреть аннотации last-applied-configuration ресурса, указав его тип и имя; формат YAML

kubectl apply view-last-applied deployment/nginx

Просмотреть аннотации last-applied-configuration ресурса из файла; формат JSON

kubectl apply view-last-applied -f deploy.yaml -o json

Просмотреть последние аннотации last-applied-configuration, указав тип и имя ресурса или файл.

По умолчанию вывод будет направлен в stdout в формате YAML. Чтобы изменить формат вывода, используйте параметр -o.

Использование

$ kubectl apply view-last-applied (TYPE [NAME | -l label] | TYPE/NAME | -f FILENAME)

Флаги

annotate

Обновить Pod 'foo', добавив аннотацию 'description' со значением 'my frontend' # Если одна и та же аннотация задана несколько раз, будет применено только последнее значение

kubectl annotate pods foo description='my frontend'

Обновить Pod, указанный типом и именем в файле "pod.json"

kubectl annotate -f pod.json description='my frontend'

Обновить Pod 'foo', задав для аннотации 'description' значение 'my frontend running nginx' и перезаписав существующее значение

kubectl annotate --overwrite pods foo description='my frontend running nginx'

Обновить все Pod в пространстве имён

kubectl annotate pods --all description='my frontend running nginx'

Обновить Pod 'foo' только в том случае, если ресурс не изменился с версии 1

kubectl annotate pods foo description='my frontend running nginx' --resource-version=1

Обновить Pod 'foo', удалив аннотацию с именем 'description', если она существует # Флаг --overwrite не требуется

kubectl annotate pods foo description-

Обновляет аннотации одного или нескольких ресурсов.

Все объекты Kubernetes поддерживают возможность хранения дополнительных данных в виде аннотаций. Аннотации — это пары «ключ/значение», которые могут быть больше меток и содержать произвольные строковые значения, например структурированный JSON. Инструменты и системные расширения могут использовать аннотации для хранения собственных данных.

Попытка задать уже существующую аннотацию завершится ошибкой, если не указан флаг --overwrite. Если указан флаг --resource-version, но его значение не совпадает с текущей версией ресурса на сервере, команда завершится ошибкой.

Используйте «kubectl api-resources», чтобы получить полный список поддерживаемых ресурсов.

Использование

$ kubectl annotate [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

Флаги

autoscale

Автоматически масштабировать развёртывание "foo", задав число подов от 2 до 10. Целевая загрузка ЦП не указана, поэтому будет применена политика автомасштабирования по умолчанию

kubectl autoscale deployment foo --min=2 --max=10

Автоматически масштабировать контроллер репликации "foo", задав число подов от 1 до 5 и целевую загрузку ЦП 80%

kubectl autoscale rc foo --max=5 --cpu-percent=80

Создаёт автомасштабировщик, который автоматически выбирает и задаёт число подов, работающих в кластере Kubernetes.

Находит развёртывание, набор реплик, stateful-набор или контроллер репликации по имени и создаёт автомасштабировщик, использующий указанный ресурс в качестве ссылки. При необходимости автомасштабировщик может автоматически увеличивать или уменьшать число подов, развёрнутых в системе.

Использование

$ kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU]

Флаги

debug

Создать интерактивный сеанс отладки в поде mypod и сразу подключиться к нему. # (требуется включить функцию EphemeralContainers в кластере)

kubectl debug mypod -it --image=busybox

Создать контейнер отладки с именем debugger, используя пользовательский образ для автоматизированной отладки. # (требуется включить функцию EphemeralContainers в кластере)

kubectl debug --image=myproj/debug-tools -c debugger mypod

Создать копию mypod, добавив контейнер отладки, и подключиться к ней

kubectl debug mypod -it --image=busybox --copy-to=my-debugger

Создать копию mypod, изменив команду контейнера mycontainer

kubectl debug mypod -it --copy-to=my-debugger --container=mycontainer -- sh

Создать копию mypod, заменив образы всех контейнеров на busybox

kubectl debug mypod --copy-to=my-debugger --set-image=*=busybox

Создать копию mypod, добавив контейнер отладки и изменив образы контейнеров

kubectl debug mypod -it --copy-to=my-debugger --image=debian --set-image=app=app:debug,sidecar=sidecar:debug

Создать интерактивный сеанс отладки на узле и сразу подключиться к нему. # Контейнер будет работать в пространствах имён хоста, а файловая система хоста будет подключена в /host

kubectl debug node/mynode -it --image=busybox

Отладка ресурсов кластера с помощью интерактивных контейнеров отладки.

Команда 'debug' автоматизирует распространённые задачи отладки объектов кластера, указанных по ресурсу и имени. Если ресурс не указан, по умолчанию используются поды.

Действие команды 'debug' зависит от указанного ресурса. Поддерживаются следующие действия:

Рабочая нагрузка: создать копию существующего пода с изменёнными атрибутами, например заменить тег образа на новую версию.
Рабочая нагрузка: добавить эфемерный контейнер в уже работающий под, например добавить средства отладки без перезапуска пода.
* Узел: создать новый под, работающий в пространствах имён хоста узла и имеющий доступ к файловой системе узла.

Использование

$ kubectl debug (POD | TYPE[[.VERSION].GROUP]/NAME) [ -- COMMAND [args...] ]

Флаги

diff

Сравнить ресурсы, содержащиеся в pod.json

kubectl diff -f pod.json

Сравнить файл, прочитанный из stdin

cat service.yaml | kubectl diff -f -

Сравнивает конфигурации, указанные именем файла или через stdin, с текущей конфигурацией в сети и конфигурацией, которая была бы применена.

Результат всегда выводится в формате YAML.

Для выбора собственной команды diff можно использовать переменную окружения KUBECTL_EXTERNAL_DIFF. Также можно использовать внешние команды с параметрами, например: KUBECTL_EXTERNAL_DIFF="colordiff -N -u"

По умолчанию запускается команда "diff", доступная в PATH, с параметрами "-u" (унифицированный формат diff) и "-N" (считать отсутствующие файлы пустыми).

Код завершения: 0 — различий не найдено. 1 — найдены различия. >1 — Kubectl или diff завершилась с ошибкой.

Примечание: если используется KUBECTL_EXTERNAL_DIFF, ожидается, что она будет следовать этому соглашению.

Использование

$ kubectl diff -f FILENAME

Флаги

edit

Изменить сервис с именем 'registry'

kubectl edit svc/registry

Использовать другой редактор

KUBE_EDITOR="nano" kubectl edit svc/registry

Изменить задание 'myjob' в формате JSON, используя формат API v1

kubectl edit job.v1.batch/myjob -o json

Изменить развёртывание 'mydeployment' в формате YAML и сохранить изменённую конфигурацию в его аннотации

kubectl edit deployment/mydeployment -o yaml --save-config

Изменить субресурс status для deployment/mydeployment

kubectl edit deployment mydeployment --subresource='status'

Изменить ресурс в редакторе по умолчанию.

Команда edit позволяет напрямую изменять любые ресурсы API, которые можно получить с помощью инструментов командной строки. Она откроет редактор, заданный переменными среды KUBE_EDITOR или EDITOR, либо использует 'vi' в Linux или 'notepad' в Windows. Можно изменять несколько объектов, хотя изменения применяются по одному. Команда принимает имена файлов, а также аргументы командной строки, однако указанные файлы должны быть ранее сохранёнными версиями ресурсов.

Редактирование выполняется с использованием версии API, применённой для получения ресурса. Чтобы редактировать ресурс с помощью определённой версии API, укажите полные имена ресурса, версии и группы.

Формат по умолчанию — YAML. Чтобы редактировать в формате JSON, укажите "-o json".

Флаг --windows-line-endings можно использовать для принудительного применения окончаний строк Windows; в противном случае будут использоваться окончания строк по умолчанию для вашей операционной системы.

Если при обновлении возникает ошибка, на диске будет создан временный файл с неприменёнными изменениями. Наиболее распространённая ошибка при обновлении ресурса возникает, когда другой редактор изменяет ресурс на сервере. В этом случае необходимо применить изменения к более новой версии ресурса либо обновить временную сохранённую копию, добавив в неё последнюю версию ресурса.

Использование

$ kubectl edit (RESOURCE/NAME | -f FILENAME)

Флаги

kustomize

Собрать ресурсы из текущего рабочего каталога

kubectl kustomize

Собрать ресурсы из общего каталога конфигурации

kubectl kustomize /home/config/production

Собрать ресурсы из GitHub

kubectl kustomize https://github.com/kubernetes-sigs/kustomize.git/examples/helloWorld?ref=v1.0.6

Собрать набор ресурсов KRM с помощью файла 'kustomization.yaml'. Аргумент DIR должен быть путём к каталогу, содержащему 'kustomization.yaml', или URL-адресом репозитория Git с суффиксом пути, указывающим на соответствующий каталог относительно корня репозитория. Если DIR не указан, используется '.'.

Использование

$ kubectl kustomize DIR

Флаги

label

Обновить метку pod 'foo': задать для метки 'unhealthy' значение 'true'

kubectl label pods foo unhealthy=true

Обновить pod 'foo': задать для метки 'status' значение 'unhealthy', перезаписав существующее значение

kubectl label --overwrite pods foo status=unhealthy

Обновить все pod в пространстве имён

kubectl label pods --all status=unhealthy

Обновить pod, тип и имя которого указаны в "pod.json"

kubectl label -f pod.json status=unhealthy

Обновить pod 'foo', только если ресурс не изменился после версии 1

kubectl label pods foo status=unhealthy --resource-version=1

Обновить pod 'foo', удалив метку с именем 'bar', если она существует # Флаг --overwrite не требуется

kubectl label pods foo bar-

Обновить метки ресурса.

Ключ и значение метки должны начинаться с буквы или цифры и могут содержать буквы, цифры, дефисы, точки и подчёркивания; длина каждого из них не должна превышать 63 символа.
При необходимости перед ключом можно указать префикс DNS-поддомена и символ '/', например example.com/my-app.
Если для --overwrite задано значение true, существующие метки можно перезаписывать; в противном случае попытка перезаписать метку приведёт к ошибке.
Если указан --resource-version, обновления будут использовать эту версию ресурса; в противном случае будет использоваться существующая версия ресурса.

Использование

$ kubectl label [--overwrite] (-f FILENAME | TYPE NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--resource-version=version]

Флаги

patch

Частично обновить узел с помощью strategic merge patch, указав патч в формате JSON

kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}'

Частично обновить узел с помощью strategic merge patch, указав патч в формате YAML

kubectl patch node k8s-node-1 -p $'spec:\n unschedulable: true'

Частично обновить узел, тип и имя которого указаны в "node.json", с помощью strategic merge patch

kubectl patch -f node.json -p '{"spec":{"unschedulable":true}}'

Обновить образ контейнера; spec.containers[*].name обязателен, поскольку используется как ключ слияния

kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'

Обновить образ контейнера с помощью JSON patch с позиционными массивами

kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'

Обновить количество реплик развёртывания через субресурс scale с помощью merge patch.

kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}'

Обновить поля ресурса с помощью strategic merge patch, JSON merge patch или JSON patch.

Поддерживаются форматы JSON и YAML.

Примечание: strategic merge patch не поддерживается для пользовательских ресурсов.

Использование

$ kubectl patch (-f FILENAME | TYPE NAME) [-p PATCH|--patch-file FILE]

Флаги

replace

Заменить pod данными из pod.json

kubectl replace -f ./pod.json

Заменить pod на основе JSON, переданного через stdin

cat pod.json | kubectl replace -f -

Обновить версию образа (тег) pod с одним контейнером до v4

kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

Выполнить принудительную замену: удалить ресурс, а затем создать его заново

kubectl replace --force -f ./pod.json

Заменить ресурс, указав имя файла или stdin.

Допускаются форматы JSON и YAML. При замене существующего ресурса необходимо указать его полную спецификацию. Её можно получить с помощью команды

$ kubectl get TYPE NAME -o yaml

Использование

$ kubectl replace -f FILENAME

Флаги

rollout

Выполнить откат к предыдущему развёртыванию

kubectl rollout undo deployment/abc

Проверить состояние развёртывания daemonset

kubectl rollout status daemonset/foo

Перезапустить развёртывание

kubectl rollout restart deployment/abc

Перезапустить развёртывания с меткой app=nginx

kubectl rollout restart deployment --selector=app=nginx

Управлять развёртыванием одного или нескольких ресурсов.

Допустимые типы ресурсов:

deployments
daemonsets
* statefulsets

Использование

$ kubectl rollout SUBCOMMAND

history

Просмотреть историю развёртывания deployment

kubectl rollout history deployment/abc

Просмотреть сведения о редакции 3 daemonset

kubectl rollout history daemonset/abc --revision=3

Просмотреть предыдущие редакции развёртывания и их конфигурации.

Использование

$ kubectl rollout history (TYPE NAME | TYPE/NAME) [flags]

Флаги

pause

Приостановить развёртывание nginx # Текущее состояние развёртывания продолжит функционировать; новые обновления # не будут применяться, пока развёртывание приостановлено

kubectl rollout pause deployment/nginx

Приостановить указанный ресурс.

Контроллер не будет выполнять сверку приостановленных ресурсов. Чтобы возобновить работу приостановленного ресурса, используйте "kubectl rollout resume". В настоящее время приостанавливать можно только deployments.

Использование

$ kubectl rollout pause RESOURCE

Флаги

restart

Перезапустить развёртывание

kubectl rollout restart deployment/nginx

Перезапустить daemon set

kubectl rollout restart daemonset/abc

Перезапустить развёртывания с меткой app=nginx

kubectl rollout restart deployment --selector=app=nginx

Перезапустить ресурс.

Будет выполнен перезапуск развёртывания ресурса.

Использование

$ kubectl rollout restart RESOURCE

Флаги

resume

Возобновить приостановленное развертывание

kubectl rollout resume deployment/nginx

Возобновить приостановленный ресурс.

Контроллер не выполняет сверку приостановленных ресурсов. Возобновив ресурс, мы разрешаем снова выполнять его сверку. В настоящее время возобновление поддерживается только для развертываний.

Использование

$ kubectl rollout resume RESOURCE

Флаги

status

Наблюдать за состоянием развертывания

kubectl rollout status deployment/nginx

Показать состояние развертывания.

По умолчанию команда 'rollout status' отслеживает состояние последнего развертывания до его завершения. Если вы не хотите ждать завершения развертывания, можно использовать --watch=false. Обратите внимание: если за это время начнётся новое развертывание, команда 'rollout status' продолжит отслеживать последнюю ревизию. Чтобы привязаться к конкретной ревизии и прервать отслеживание, если её сменит другая ревизия, используйте --revision=N, где N — номер ревизии, которую нужно отслеживать.

Использование

$ kubectl rollout status (TYPE NAME | TYPE/NAME) [flags]

Флаги

undo

Откатиться к предыдущему развертыванию

kubectl rollout undo deployment/abc

Откатиться к ревизии 3 набора демонов

kubectl rollout undo daemonset/abc --to-revision=3

Откатиться к предыдущему развертыванию в режиме пробного запуска

kubectl rollout undo --dry-run=server deployment/abc

Откатиться к предыдущему развертыванию.

Использование

$ kubectl rollout undo (TYPE NAME | TYPE/NAME) [flags]

Флаги

scale

Масштабировать набор реплик с именем 'foo' до 3

kubectl scale --replicas=3 rs/foo

Масштабировать ресурс, указанный типом и именем в файле "foo.yaml", до 3

kubectl scale --replicas=3 -f foo.yaml

Если текущий размер развертывания с именем mysql равен 2, масштабировать mysql до 3

kubectl scale --current-replicas=2 --replicas=3 deployment/mysql

Масштабировать несколько контроллеров репликации

kubectl scale --replicas=5 rc/foo rc/bar rc/baz

Масштабировать stateful set с именем 'web' до 3

kubectl scale --replicas=3 statefulset/web

Задать новый размер для развертывания, набора реплик, контроллера репликации или stateful set.

Команда scale также позволяет указать одно или несколько предварительных условий для операции масштабирования.

Если указаны --current-replicas или --resource-version, значение проверяется перед выполнением масштабирования; гарантируется, что предварительное условие будет выполнено при отправке запроса на масштабирование серверу.

Использование

$ kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)

Флаги

set

Настроить ресурсы приложения.

Эти команды позволяют вносить изменения в существующие ресурсы приложения.

Использование

$ kubectl set SUBCOMMAND

env

Обновить развертывание 'registry', добавив новую переменную окружения

kubectl set env deployment/registry STORAGE_DIR=/local

Вывести переменные окружения, определённые для развертывания 'sample-build'

kubectl set env deployment/sample-build --list

Вывести переменные окружения, определённые для всех подов

kubectl set env pods --all --list

Вывести изменённое развертывание в формате YAML, не изменяя объект на сервере

kubectl set env deployment/sample-build STORAGE_DIR=/data -o yaml

Задать ENV=prod для всех контейнеров во всех контроллерах репликации проекта

kubectl set env rc --all ENV=prod

Импортировать переменные окружения из секрета

kubectl set env --from=secret/mysecret deployment/myapp

Импортировать переменные окружения из config map с префиксом

kubectl set env --from=configmap/myconfigmap --prefix=MYSQL_ deployment/myapp

Импортировать отдельные ключи из config map

kubectl set env --keys=my-example-key --from=configmap/myconfigmap deployment/myapp

Удалить переменную окружения ENV из контейнера 'c1' во всех конфигурациях развертывания

kubectl set env deployments --all --containers="c1" ENV-

Удалить переменную окружения ENV из определения развертывания на диске и # обновить конфигурацию развертывания на сервере

kubectl set env -f deploy.json ENV-

Задать часть переменных окружения локальной оболочки в конфигурации развертывания на сервере

env | grep RAILS_ | kubectl set env -e - deployment/registry

Обновить переменные окружения в шаблоне пода.

Вывести определения переменных окружения в одном или нескольких подах или шаблонах подов. Добавить, обновить или удалить определения переменных окружения контейнеров в одном или нескольких шаблонах подов (в контроллерах репликации или конфигурациях развертывания). Просмотреть или изменить определения переменных окружения во всех контейнерах указанных подов или шаблонов подов либо только в тех, которые соответствуют подстановочному шаблону.

Если передан параметр "--env -", переменные окружения можно считывать из STDIN в стандартном формате env.

Возможные ресурсы (без учёта регистра):

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs)

Использование

$ kubectl set env RESOURCE/NAME KEY_1=VAL_1 ... KEY_N=VAL_N

Флаги

image

Задать для контейнера nginx в deployment образ 'nginx:1.9.1', а для контейнера busybox — образ 'busybox'

kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1

Обновить образ контейнера nginx во всех deployment и rc на 'nginx:1.9.1'

kubectl set image deployments,rc nginx=nginx:1.9.1 --all

Обновить образ всех контейнеров daemonset abc на 'nginx:1.9.1'

kubectl set image daemonset abc *=nginx:1.9.1

Вывести результат обновления образа контейнера nginx из локального файла (в формате yaml), не обращаясь к серверу

kubectl set image -f path/to/file.yaml nginx=nginx:1.9.1 --local -o yaml

Обновить образы существующих контейнеров ресурсов.

Возможные ресурсы (без учёта регистра):

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), statefulset (sts), cronjob (cj), replicaset (rs)

Использование

$ kubectl set image (-f FILENAME | TYPE NAME) CONTAINER_NAME_1=CONTAINER_IMAGE_1 ... CONTAINER_NAME_N=CONTAINER_IMAGE_N

Флаги

resources

Задать для контейнера nginx в deployment ограничения CPU "200m" и памяти "512Mi"

kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi

Задать запросы и ограничения ресурсов для всех контейнеров в nginx

kubectl set resources deployment nginx --limits=cpu=200m,memory=512Mi --requests=cpu=100m,memory=256Mi

Удалить запросы ресурсов для ресурсов контейнеров в nginx

kubectl set resources deployment nginx --limits=cpu=0,memory=0 --requests=cpu=0,memory=0

Вывести результат обновления ограничений контейнера nginx из локального файла (в формате yaml), не обращаясь к серверу

kubectl set resources -f path/to/file.yaml --limits=cpu=200m,memory=512Mi --local -o yaml

Указать требования к вычислительным ресурсам (CPU, память) для любого ресурса, определяющего шаблон pod. Если для pod успешно назначен узел, ему гарантируется запрошенный объём ресурсов, но он может использовать объём до указанного предела.

Для каждого вычислительного ресурса, если указан предел, а запрос не указан, запрос по умолчанию будет равен пределу.

Возможные ресурсы (без учёта регистра): используйте "kubectl api-resources", чтобы получить полный список поддерживаемых ресурсов.

Использование

$ kubectl set resources (-f FILENAME | TYPE NAME) ([--limits=LIMITS & --requests=REQUESTS]

Флаги

selector

Задать метки и селектор перед созданием пары deployment/service

kubectl create service clusterip my-svc --clusterip="None" -o yaml --dry-run=client | kubectl set selector --local -f - 'environment=qa' -o yaml | kubectl create -f - kubectl create deployment my-dep -o yaml --dry-run=client | kubectl label --local -f - environment=qa -o yaml | kubectl create -f -

Задать селектор для ресурса. Обратите внимание, что новый селектор заменит старый, если у ресурса был селектор до вызова команды 'set selector'.

Селектор должен начинаться с буквы или цифры и может содержать буквы, цифры, дефисы, точки и символы подчёркивания; максимальная длина — 63 символа. Если указан --resource-version, для обновления будет использоваться эта версия ресурса, в противном случае будет использоваться существующая версия ресурса. Примечание: в настоящее время селекторы можно задавать только для объектов Service.

Использование

$ kubectl set selector (-f FILENAME | TYPE NAME) EXPRESSIONS [--resource-version=version]

Флаги

serviceaccount

Задать для deployment nginx-deployment учётную запись службы serviceaccount1

kubectl set serviceaccount deployment nginx-deployment serviceaccount1

Вывести результат обновления deployment nginx с учётной записью службы из локального файла (в формате YAML), не обращаясь к API-серверу

kubectl set sa -f nginx-deployment.yaml serviceaccount1 --local --dry-run=client -o yaml

Обновить учетную запись службы ресурсов шаблона пода.

Возможные ресурсы (без учета регистра):

replicationcontroller (rc), deployment (deploy), daemonset (ds), job, replicaset (rs), statefulset

Использование

$ kubectl set serviceaccount (-f FILENAME | TYPE NAME) SERVICE_ACCOUNT

Флаги

subject

Обновить привязку роли кластера для serviceaccount1

kubectl set subject clusterrolebinding admin --serviceaccount=namespace:serviceaccount1

Обновить привязку роли для user1, user2 и group1

kubectl set subject rolebinding admin --user=user1 --user=user2 --group=group1

Вывести результат обновления субъектов rolebinding (в формате YAML), выполненного локально, без обращения к серверу

kubectl create rolebinding admin --role=admin --user=admin -o yaml --dry-run=client | kubectl set subject --local -f - --user=foo -o yaml

Обновить пользователя, группу или учетную запись службы в привязке роли или привязке роли кластера.

Использование

$ kubectl set subject (-f FILENAME | TYPE NAME) [--user=username] [--group=groupname] [--serviceaccount=namespace:serviceaccountname] [--dry-run=server|client|none]

Флаги

wait

Дождаться, пока под "busybox1" получит условие состояния типа "Ready"

kubectl wait --for=condition=Ready pod/busybox1

Значение условия состояния по умолчанию — true; можно ожидать и другие значения, указав их после знака равенства (сравнение выполняется после простого приведения регистра Unicode, являющегося более общим способом сравнения без учета регистра):

kubectl wait --for=condition=Ready=false pod/busybox1

Дождаться, пока фаза состояния пода "busybox1" не станет "Running".

kubectl wait --for=jsonpath='{.status.phase}'=Running pod/busybox1

Дождаться удаления пода "busybox1" в течение 60s после выполнения команды "delete"

kubectl delete pod/busybox1 kubectl wait --for=delete pod/busybox1 --timeout=60s

Экспериментальная функция: ожидание определенного условия для одного или нескольких ресурсов.

Команда принимает несколько ресурсов и ожидает, пока указанное условие не появится в поле Status каждого из заданных ресурсов.

Также команда может ожидать удаления указанного набора ресурсов, если в качестве значения флага --for указать ключевое слово "delete".

При выполнении условия в stdout будет выведено сообщение об успехе. С помощью параметра -o можно изменить место вывода.

Использование

$ kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available|--for=jsonpath='{}'=value]

Флаги

РАБОТА С ПРИЛОЖЕНИЯМИ

В этом разделе приведены команды для проверки и отладки приложений.

• logs выводит журналы указанного пода и контейнера.
• exec можно использовать для открытия интерактивной оболочки в поде и контейнере.
• describe выводит отладочную информацию об указанном ресурсе.

attach

Получить вывод работающего пода mypod; для выбора контейнера используется аннотация 'kubectl.kubernetes.io/default-container' # если она отсутствует, будет выбран первый контейнер в поде

kubectl attach mypod

Получить вывод ruby-container из пода mypod

kubectl attach mypod -c ruby-container

Переключиться в режим необработанного терминала; передавать stdin в 'bash' контейнера ruby-container из пода mypod # и передавать stdout/stderr из 'bash' обратно клиенту

kubectl attach mypod -c ruby-container -i -t

Получить вывод первого пода набора реплик с именем nginx

kubectl attach rs/nginx

Подключиться к процессу, уже работающему в существующем контейнере.

Использование

$ kubectl attach (POD | TYPE/NAME) -c CONTAINER

Флаги

auth

Проверка авторизации

Использование

$ kubectl auth

can-i

Проверить, могу ли я создавать поды в любом пространстве имен

kubectl auth can-i create pods --all-namespaces

Проверить, могу ли я просматривать развертывания в текущем пространстве имен

kubectl auth can-i list deployments.apps

Проверить, могу ли я выполнять любые действия в текущем пространстве имен ("*" означает все)

kubectl auth can-i '*' '*'

Проверить, могу ли я получить задание с именем "bar" в пространстве имен "foo"

kubectl auth can-i list jobs.batch/bar -n foo

Проверить, могу ли я читать журналы подов

kubectl auth can-i get pods --subresource=log

Проверить, могу ли я обращаться к URL /logs/

kubectl auth can-i get /logs/

Вывести все разрешенные действия в пространстве имен "foo"

kubectl auth can-i --list --namespace=foo

Проверить, разрешено ли действие.

VERB — логический глагол API Kubernetes, например 'get', 'list', 'watch', 'delete' и т. д. TYPE — ресурс Kubernetes. Краткие имена и группы будут преобразованы. NONRESOURCEURL — частичный URL, начинающийся с "/". NAME — имя конкретного ресурса Kubernetes. Эта команда хорошо сочетается с имперсонацией. См. глобальный флаг --as.

Использование

$ kubectl auth can-i VERB [TYPE | TYPE/NAME | NONRESOURCEURL]

Флаги

reconcile

Согласовать ресурсы RBAC из файла

kubectl auth reconcile -f my-rbac-rules.yaml

Согласует правила для объектов RBAC role, role binding, cluster role и cluster role binding.

Отсутствующие объекты создаются; при необходимости для объектов с пространством имен создается соответствующее пространство имен.

Существующие роли обновляются с добавлением разрешений из входных объектов; лишние разрешения удаляются, если указан флаг --remove-extra-permissions.

Существующие привязки обновляются с добавлением субъектов из входных объектов; лишние субъекты удаляются, если указан флаг --remove-extra-subjects.

Для ресурсов RBAC этот способ предпочтительнее 'apply', поскольку он выполняет семантически корректное объединение правил и субъектов.

Использование

$ kubectl auth reconcile -f FILENAME

Флаги

cp

!!!Важное примечание!!! # В образе контейнера должен присутствовать двоичный файл 'tar'. # Если 'tar' отсутствует, команда 'kubectl cp' завершится ошибкой. # # Для сложных сценариев использования, например при работе с символическими ссылками, подстановке шаблонов или # сохранении режима доступа к файлам, рассмотрите возможность использования 'kubectl exec'. # Скопировать локальный файл /tmp/foo в /tmp/bar в удалённом поде в пространстве имён

tar cf - /tmp/foo | kubectl exec -i -n <some-namespace> <some-pod> -- tar xf - -C /tmp/bar

Скопировать /tmp/foo из удалённого пода в локальный файл /tmp/bar

kubectl exec -n <some-namespace> <some-pod> -- tar cf - /tmp/foo | tar xf - -C /tmp/bar

Скопировать локальный каталог /tmp/foo_dir в /tmp/bar_dir в удалённом поде в пространстве имён по умолчанию

kubectl cp /tmp/foo_dir <some-pod>:/tmp/bar_dir

Скопировать локальный файл /tmp/foo в /tmp/bar в удалённом поде в определённом контейнере

kubectl cp /tmp/foo <some-pod>:/tmp/bar -c <specific-container>

Скопировать локальный файл /tmp/foo в /tmp/bar в удалённом поде в пространстве имён

kubectl cp /tmp/foo <some-namespace>/<some-pod>:/tmp/bar

Скопировать /tmp/foo из удалённого пода в локальный файл /tmp/bar

kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar

Копирование файлов и каталогов в контейнеры и из них.

Использование

$ kubectl cp <file-spec-src> <file-spec-dest>

Флаги

describe

Описать узел

kubectl describe nodes kubernetes-node-emt8.c.myproject.internal

Описать под

kubectl describe pods/nginx

Описать под, указанный типом и именем в файле "pod.json"

kubectl describe -f pod.json

Описать все поды

kubectl describe pods

Описать поды по метке name=myLabel

kubectl describe po -l name=myLabel

Описать все поды, управляемые контроллером репликации 'frontend' # (имя подов, созданных контроллером репликации, начинается с имени контроллера)

kubectl describe pods frontend

Показать сведения об указанном ресурсе или группе ресурсов.

Вывести подробное описание выбранных ресурсов, включая связанные ресурсы, например события или контроллеры. Можно выбрать один объект по имени, все объекты этого типа, указать префикс имени или селектор меток. Например:

$ kubectl describe TYPE NAME_PREFIX

сначала будет выполнен поиск точного соответствия TYPE и NAME_PREFIX. Если такой ресурс не найден, будут выведены сведения обо всех ресурсах, имена которых начинаются с NAME_PREFIX.

Чтобы просмотреть полный список поддерживаемых ресурсов, используйте "kubectl api-resources".

Использование

$ kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)

Флаги

events

Вывести последние события в пространстве имён по умолчанию.

kubectl events

Вывести последние события во всех пространствах имён.

kubectl events --all-namespaces

Вывести последние события для указанного пода, а затем ожидать новые события и выводить их по мере поступления.

kubectl events --for pod/web-pod-13je7 --watch

Вывести последние события в указанном формате. Помимо формата по умолчанию поддерживаются json и yaml.

kubectl events -oyaml

Вывести только последние события указанных типов

kubectl events --types=Warning,Normal

Отобразить события

Вывести таблицу с наиболее важными сведениями о событиях. Можно запросить события для одного пространства имён, для всех пространств имён или отфильтровать их, оставив только события, относящиеся к указанному ресурсу.

Использование

$ kubectl events [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file] [--for TYPE/NAME] [--watch] [--event=Normal,Warning]

Флаги

exec

Получить вывод команды 'date', запущенной в поде mypod; по умолчанию используется первый контейнер

kubectl exec mypod -- date

Получить вывод команды 'date', запущенной в ruby-container пода mypod

kubectl exec mypod -c ruby-container -- date

Переключиться в режим необработанного терминала; передавать stdin команде 'bash' в ruby-container пода mypod # и отправлять stdout/stderr команды 'bash' обратно клиенту

kubectl exec mypod -c ruby-container -i -t -- bash -il

Вывести содержимое /usr из первого контейнера пода mypod и отсортировать по времени изменения # Если у команды, которую нужно выполнить в поде, есть флаги, совпадающие с флагами kubectl (например, -i), # используйте два дефиса (--) для отделения флагов и аргументов команды # Также не заключайте команду и её флаги или аргументы в кавычки, # если обычно вы запускаете её без кавычек (то есть используйте ls -t /usr, а не "ls -t /usr")

kubectl exec mypod -i -t -- ls -t /usr

Получить вывод команды 'date', запущенной в первом поде развёртывания mydeployment; по умолчанию используется первый контейнер

kubectl exec deploy/mydeployment -- date

Получить вывод команды 'date', запущенной в первом поде сервиса myservice; по умолчанию используется первый контейнер

kubectl exec svc/myservice -- date

Выполнить команду в контейнере.

Использование

$ kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...]

Флаги

logs

Получить снимок журналов пода nginx с одним контейнером

kubectl logs nginx

Получить снимок журналов пода nginx с несколькими контейнерами

kubectl logs nginx --all-containers=true

Получить снимок журналов всех контейнеров в подах, выбранных по метке app=nginx

kubectl logs -l app=nginx --all-containers=true

Получить снимок журналов предыдущего завершившего работу контейнера ruby в поде web-1

kubectl logs -p -c ruby web-1

Начать потоковую передачу журналов контейнера ruby в поде web-1

kubectl logs -f -c ruby web-1

Начать потоковую передачу журналов всех контейнеров в подах, выбранных по метке app=nginx

kubectl logs -f -l app=nginx --all-containers=true

Показать только 20 последних строк вывода в поде nginx

kubectl logs --tail=20 nginx

Показать все журналы пода nginx, записанные за последний час

kubectl logs --since=1h nginx

Показать журналы kubelet с просроченным сертификатом сервера

kubectl logs --insecure-skip-tls-verify-backend nginx

Получить снимок журналов первого контейнера задания с именем hello

kubectl logs job/hello

Получить снимок журналов контейнера nginx-1 развёртывания с именем nginx

kubectl logs deployment/nginx -c nginx-1

Вывести журналы контейнера в поде или указанном ресурсе. Если в поде только один контейнер, имя контейнера можно не указывать.

Использование

$ kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]

Флаги

port-forward

Прослушивать локально порты 5000 и 6000, перенаправляя данные в под и из него через порты 5000 и 6000

kubectl port-forward pod/mypod 5000 6000

Прослушивать локально порты 5000 и 6000, перенаправляя данные в под, выбранный развертыванием, и из него через порты 5000 и 6000

kubectl port-forward deployment/mydeployment 5000 6000

Прослушивать локальный порт 8443, перенаправляя данные на targetPort порта службы с именем "https" в поде, выбранном службой

kubectl port-forward service/myservice 8443:https

Прослушивать порт 8888 локально, перенаправляя данные на порт 5000 в поде

kubectl port-forward pod/mypod 8888:5000

Прослушивать порт 8888 на всех адресах, перенаправляя данные на порт 5000 в поде

kubectl port-forward --address 0.0.0.0 pod/mypod 8888:5000

Прослушивать порт 8888 на localhost и выбранном IP-адресе, перенаправляя данные на порт 5000 в поде

kubectl port-forward --address localhost,10.19.21.23 pod/mypod 8888:5000

Прослушивать случайный порт локально, перенаправляя данные на порт 5000 в поде

kubectl port-forward pod/mypod :5000

Перенаправить один или несколько локальных портов в под.

Используйте тип/имя ресурса, например deployment/mydeployment, чтобы выбрать под. Если тип ресурса не указан, по умолчанию используется 'pod'.

Если критериям соответствуют несколько подов, под будет выбран автоматически. Сеанс перенаправления завершится, когда выбранный под будет остановлен; чтобы возобновить перенаправление, команду необходимо запустить повторно.

Использование

$ kubectl port-forward TYPE/NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]

Флаги

proxy

Чтобы проксировать весь API Kubernetes и ничего больше

kubectl proxy --api-prefix=/

Чтобы проксировать только часть API Kubernetes, а также некоторые статические файлы # Информацию о подах можно получить с помощью 'curl localhost:8001/api/v1/pods'

kubectl proxy --www=/my/files --www-prefix=/static/ --api-prefix=/api/

Чтобы проксировать весь API Kubernetes по другому корневому пути # Информацию о подах можно получить с помощью 'curl localhost:8001/custom/api/v1/pods'

kubectl proxy --api-prefix=/custom/

Запустить прокси-сервер для API-сервера Kubernetes на порту 8011, предоставляя статическое содержимое из ./local/www/

kubectl proxy --port=8011 --www=./local/www/

Запустить прокси-сервер для API-сервера Kubernetes на произвольном локальном порту # Выбранный порт сервера будет выведен в stdout

kubectl proxy --port=0

Запустить прокси-сервер для API-сервера Kubernetes, изменив префикс API на k8s-api # Например, API подов станет доступен по адресу localhost:8001/k8s-api/v1/pods/

kubectl proxy --api-prefix=/k8s-api

Создаёт прокси-сервер или шлюз прикладного уровня между localhost и API-сервером Kubernetes. Также позволяет предоставлять статическое содержимое по указанному пути HTTP. Все входящие данные поступают через один порт и перенаправляются на порт удалённого API-сервера Kubernetes, за исключением пути, соответствующего пути статического содержимого.

Использование

$ kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix]

Флаги

top

Отображение использования ресурсов (ЦП/память).

Команда top позволяет просматривать потребление ресурсов узлами или подами.

Для работы этой команды Metrics Server должен быть правильно настроен и функционировать на сервере.

Использование

$ kubectl top

node

Показать метрики для всех узлов

kubectl top node

Показать метрики для указанного узла

kubectl top node NODE_NAME

Отображение использования ресурсов (ЦП/память) узлами.

Команда top-node позволяет просматривать потребление ресурсов узлами.

Использование

$ kubectl top node [NAME | -l label]

Флаги

pod

Показать метрики для всех подов в пространстве имён по умолчанию

kubectl top pod

Показать метрики для всех подов в указанном пространстве имён

kubectl top pod --namespace=NAMESPACE

Показать метрики для указанного пода и его контейнеров

kubectl top pod POD_NAME --containers

Показать метрики для подов, выбранных по метке name=myLabel

kubectl top pod -l name=myLabel

Отображение использования ресурсов (ЦП/память) подами.

Команда 'top pod' позволяет просматривать потребление ресурсов подами.

Из-за задержки в конвейере сбора метрик они могут быть недоступны в течение нескольких минут после создания пода.

Использование

$ kubectl top pod [NAME | -l label]

Флаги

УПРАВЛЕНИЕ КЛАСТЕРОМ

api-versions

Вывести поддерживаемые версии API

kubectl api-versions

Вывести поддерживаемые на сервере версии API в формате "group/version".

Использование

$ kubectl api-versions

api-resources

Вывести поддерживаемые ресурсы API

kubectl api-resources

Вывести поддерживаемые ресурсы API с дополнительной информацией

kubectl api-resources -o wide

Вывести поддерживаемые ресурсы API, отсортированные по столбцу

kubectl api-resources --sort-by=name

Вывести поддерживаемые ресурсы с пространствами имён

kubectl api-resources --namespaced=true

Вывести поддерживаемые ресурсы без пространств имён

kubectl api-resources --namespaced=false

Вывести поддерживаемые ресурсы API для указанной группы API

kubectl api-resources --api-group=rbac.authorization.k8s.io

Вывести поддерживаемые на сервере ресурсы API.

Использование

$ kubectl api-resources

Флаги

certificate

Изменение ресурсов сертификатов.

Использование

$ kubectl certificate SUBCOMMAND

approve

Одобрить CSR 'csr-sqgzp'

kubectl certificate approve csr-sqgzp

Одобрить запрос на подписание сертификата.

kubectl certificate approve позволяет администратору кластера одобрить запрос на подписание сертификата (CSR). Это действие сообщает контроллеру подписания сертификатов, что нужно выдать запрашивающему сертификат с атрибутами, указанными в CSR.

УВЕДОМЛЕНИЕ О БЕЗОПАСНОСТИ: в зависимости от запрошенных атрибутов выданный сертификат потенциально может предоставить запрашивающему доступ к ресурсам кластера или возможность аутентификации от имени запрошенной учетной записи. Прежде чем одобрить CSR, убедитесь, что понимаете, какие действия можно выполнять с помощью подписанного сертификата.

Использование

$ kubectl certificate approve (-f FILENAME | NAME)

Флаги

deny

Отклонить CSR 'csr-sqgzp'

kubectl certificate deny csr-sqgzp

Отклонить запрос на подпись сертификата.

kubectl certificate deny позволяет администратору кластера отклонить запрос на подпись сертификата (CSR). Это действие сообщает контроллеру подписи сертификатов, что не следует выдавать сертификат запрашивающему.

Использование

$ kubectl certificate deny (-f FILENAME | NAME)

Флаги

cluster-info

Вывести адрес плоскости управления и служб кластера

kubectl cluster-info

Показать адреса плоскости управления и служб с меткой kubernetes.io/cluster-service=true. Для дальнейшей отладки и диагностики проблем кластера используйте 'kubectl cluster-info dump'.

Использование

$ kubectl cluster-info

dump

Вывести текущее состояние кластера в stdout

kubectl cluster-info dump

Вывести текущее состояние кластера в /path/to/cluster-state

kubectl cluster-info dump --output-directory=/path/to/cluster-state

Вывести все пространства имен в stdout

kubectl cluster-info dump --all-namespaces

Вывести набор пространств имен в /path/to/cluster-state

kubectl cluster-info dump --namespaces default,kube-system --output-directory=/path/to/cluster-state

Вывести сведения о кластере для отладки и диагностики проблем. По умолчанию все данные выводятся в stdout. При необходимости можно указать каталог с помощью --output-directory. Если указан каталог, Kubernetes создаст в нем набор файлов. По умолчанию выводятся данные только из текущего пространства имен и пространства имен 'kube-system', но можно выбрать другое пространство имен с помощью флага --namespaces или указать --all-namespaces, чтобы вывести данные из всех пространств имен.

Команда также выводит журналы всех подов в кластере; они сохраняются в разных каталогах в зависимости от пространства имен и имени пода.

Использование

$ kubectl cluster-info dump

Флаги

cordon

Пометить узел "foo" как недоступный для планирования

kubectl cordon foo

Пометить узел как недоступный для планирования.

Использование

$ kubectl cordon NODE

Флаги

drain

Вывести узел "foo" из эксплуатации, даже если на нем есть поды, не управляемые контроллером репликации, набором реплик, заданием, набором демонов или набором с отслеживанием состояния

kubectl drain foo --force

Как выше, но прервать выполнение, если есть поды, не управляемые контроллером репликации, набором реплик, заданием, набором демонов или набором с отслеживанием состояния, и использовать льготный период в 15 минут

kubectl drain foo --grace-period=900

Вывести узел из эксплуатации для подготовки к обслуживанию.

Указанный узел будет помечен как недоступный для планирования, чтобы на него не назначались новые поды. Команда 'drain' выселяет поды, если API-сервер поддерживает выселение https://kubernetes.io/docs/concepts/workloads/pods/disruptions/ https://kubernetes.io/docs/concepts/workloads/pods/disruptions/ . В противном случае для удаления подов используется обычный запрос DELETE. Команда 'drain' выселяет или удаляет все поды, кроме зеркальных (их нельзя удалить через API-сервер). Если на узле есть поды, управляемые набором демонов, команда drain не продолжит работу без --ignore-daemonsets и в любом случае не удалит такие поды, поскольку контроллер набора демонов немедленно создаст их заново, игнорируя отметки о недоступности для планирования. Если есть поды, которые не являются зеркальными и не управляются контроллером репликации, набором реплик, набором демонов, набором с отслеживанием состояния или заданием, команда drain не удалит их без флага --force. Флаг --force также позволяет продолжить удаление, если отсутствует управляющий ресурс одного или нескольких подов.

Команда 'drain' ожидает завершения с учетом льготного периода. Не выполняйте операции на машине, пока команда не завершится.

Когда будете готовы снова ввести узел в эксплуатацию, используйте kubectl uncordon, чтобы снова сделать узел доступным для планирования.

https://kubernetes.io/images/docs/kubectl_drain.svg Рабочий процессhttps://kubernetes.io/images/docs/kubectl_drain.svg

Использование

$ kubectl drain NODE

Флаги

taint

Обновить узел 'foo', добавив пометку с ключом 'dedicated', значением 'special-user' и эффектом 'NoSchedule' # Если пометка с таким ключом и эффектом уже существует, ее значение будет заменено указанным

kubectl taint nodes foo dedicated=special-user:NoSchedule

Удалить с узла 'foo' пометку с ключом 'dedicated' и эффектом 'NoSchedule', если она существует

kubectl taint nodes foo dedicated:NoSchedule-

Удалить с узла 'foo' все пометки с ключом 'dedicated'

kubectl taint nodes foo dedicated-

Добавить пометку с ключом 'dedicated' узлам с меткой mylabel=X

kubectl taint node -l myLabel=X dedicated=foo:PreferNoSchedule

Добавить узлу 'foo' пометку с ключом 'bar' без значения

kubectl taint nodes foo bar:NoSchedule

Обновить пометки одного или нескольких узлов.

Пометка состоит из ключа, значения и эффекта. Здесь она задается в формате key=value:effect.
Ключ должен начинаться с буквы или цифры и может содержать буквы, цифры, дефисы, точки и символы подчеркивания; максимальная длина — 253 символа.
При необходимости перед ключом можно указать префикс DNS-поддомена и один символ '/', например example.com/my-app.
Значение необязательно. Если оно указано, то должно начинаться с буквы или цифры и может содержать буквы, цифры, дефисы, точки и символы подчеркивания; максимальная длина — 63 символа.
Эффект должен быть NoSchedule, PreferNoSchedule или NoExecute.
В настоящее время пометки можно применять только к узлам.

Использование

$ kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N

Флаги

uncordon

Пометить узел "foo" как доступный для планирования

kubectl uncordon foo

Пометить узел как доступный для планирования.

Использование

$ kubectl uncordon NODE

Флаги

НАСТРОЙКИ И ИСПОЛЬЗОВАНИЕ KUBECTL

alpha

Эти команды соответствуют альфа-функциям, которые по умолчанию не включены в кластерах Kubernetes.

Использование

$ kubectl alpha

auth

Проверить авторизацию

Использование

$ kubectl alpha auth

auth whoami

Получить атрибуты субъекта.

kubectl alpha auth whoami

Получить атрибуты субъекта в формате JSON.

kubectl alpha auth whoami -o json

Экспериментальная команда: определить, кто вы и каковы ваши атрибуты (группы, дополнительные атрибуты).

Эта команда помогает узнать текущие атрибуты пользователя, особенно если в кластере Kubernetes включена динамическая аутентификация, например через token webhook, прокси аутентификации или поставщика OIDC.

Использование

$ kubectl alpha auth whoami

Флаги

completion

Установка автодополнения bash в macOS с помощью homebrew ## Если используется Bash 3.2, входящий в состав macOS

brew install bash-completion

или, если используется Bash 4.1+

brew install bash-completion@2

Если kubectl установлен через homebrew, автодополнение должно сразу заработать ## Если установка выполнялась другим способом, возможно, потребуется добавить автодополнение в каталог автодополнения

kubectl completion bash > $(brew --prefix)/etc/bash_completion.d/kubectl

Установка автодополнения bash в Linux ## Если в Linux не установлен bash-completion, установите пакет 'bash-completion' ## с помощью менеджера пакетов вашего дистрибутива. ## Загрузить код автодополнения kubectl для bash в текущую оболочку

source <(kubectl completion bash)

Записать код автодополнения bash в файл и подключить его из .bash_profile

kubectl completion bash > ~/.kube/completion.bash.inc printf "

Автодополнение kubectl в оболочке

source '$HOME/.kube/completion.bash.inc' " >> $HOME/.bash_profile source $HOME/.bash_profile

Загрузить код автодополнения kubectl для zsh[1] в текущую оболочку

source <(kubectl completion zsh)

Настроить автозагрузку кода автодополнения kubectl для zsh[1] при запуске

kubectl completion zsh > "${fpath[1]}/_kubectl"

Загрузить код автодополнения kubectl для fish[2] в текущую оболочку

kubectl completion fish | source

Чтобы загружать автодополнение в каждом сеансе, выполните один раз:

kubectl completion fish > ~/.config/fish/completions/kubectl.fish

Загрузить код автодополнения kubectl для powershell в текущую оболочку

kubectl completion powershell | Out-String | Invoke-Expression

Настроить запуск кода автодополнения kubectl для powershell при запуске ## Сохранить код автодополнения в скрипт и выполнить его в профиле

kubectl completion powershell > $HOME\.kube\completion.ps1 Add-Content $PROFILE "$HOME\.kube\completion.ps1"

Выполнить код автодополнения в профиле

Add-Content $PROFILE "if (Get-Command kubectl -ErrorAction SilentlyContinue) { kubectl completion powershell | Out-String | Invoke-Expression }"

Добавить код автодополнения непосредственно в скрипт $PROFILE

kubectl completion powershell >> $PROFILE

Вывести код автодополнения для указанной оболочки (bash, zsh, fish или powershell). Для обеспечения интерактивного автодополнения команд kubectl необходимо выполнить код оболочки. Это можно сделать, подключив его из .bash_profile.

Подробные инструкции доступны здесь:

для macOS:
https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/#enable-shell-autocompletion

для Linux:
https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#enable-shell-autocompletion

для Windows:
https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/#enable-shell-autocompletion

Примечание для пользователей zsh: [1] автодополнение zsh поддерживается только в версиях zsh >= 5.2.

Использование

$ kubectl completion SHELL

config

Изменение файлов kubeconfig с помощью подкоманд, например "kubectl config set current-context my-context"

Порядок загрузки определяется следующими правилами:

1. Если задан флаг --kubeconfig, загружается только указанный файл. Флаг можно задать только один раз; объединение файлов не выполняется.
2. Если задана переменная окружения $KUBECONFIG, она используется как список путей (с обычными для вашей системы правилами разделения путей). Указанные файлы объединяются. При изменении значения оно изменяется в файле, где определен соответствующий раздел. Новое значение создается в первом существующем файле. Если ни один файл в списке не существует, создается последний файл списка.
3. В противном случае используется ${HOME}/.kube/config, объединение файлов не выполняется.

Использование

$ kubectl config SUBCOMMAND

Флаги

current-context

Показать текущий контекст

kubectl config current-context

Показать текущий контекст.

Использование

$ kubectl config current-context

delete-cluster

Удалить кластер minikube

kubectl config delete-cluster minikube

Удалить указанный кластер из kubeconfig.

Использование

$ kubectl config delete-cluster NAME

delete-context

Удалить контекст кластера minikube

kubectl config delete-context minikube

Удалить указанный контекст из kubeconfig.

Использование

$ kubectl config delete-context NAME

delete-user

Удалить пользователя minikube

kubectl config delete-user minikube

Удалить указанного пользователя из kubeconfig.

Использование

$ kubectl config delete-user NAME

get-clusters

Вывести список кластеров, известных kubectl

kubectl config get-clusters

Показать кластеры, определенные в kubeconfig.

Использование

$ kubectl config get-clusters

get-contexts

Вывести список всех контекстов в файле kubeconfig

kubectl config get-contexts

Описать один контекст в файле kubeconfig

kubectl config get-contexts my-context

Показать один или несколько контекстов из файла kubeconfig.

Использование

$ kubectl config get-contexts [(-o|--output=)name)]

Флаги

get-users

Вывести список пользователей, известных kubectl

kubectl config get-users

Показать пользователей, определенных в kubeconfig.

Использование

$ kubectl config get-users

rename-context

Переименовать контекст 'old-name' в 'new-name' в файле kubeconfig

kubectl config rename-context old-name new-name

Переименовать контекст в файле kubeconfig.

CONTEXT_NAME — имя контекста, которое нужно изменить.

NEW_NAME — новое имя, которое нужно задать.

Примечание: если переименовываемый контекст является 'current-context', это поле также будет обновлено.

Использование

$ kubectl config rename-context CONTEXT_NAME NEW_NAME

set

Задать для поля server кластера my-cluster значение https://1.2.3.4

kubectl config set clusters.my-cluster.server https://1.2.3.4

Задать поле certificate-authority-data кластера my-cluster

kubectl config set clusters.my-cluster.certificate-authority-data $(echo "cert_data_here" | base64 -i -)

Задать для поля cluster контекста my-context значение my-cluster

kubectl config set contexts.my-context.cluster my-cluster

Задать поле client-key-data пользователя cluster-admin с помощью параметра --set-raw-bytes

kubectl config set users.cluster-admin.client-key-data cert_data_here --set-raw-bytes=true

Задать отдельное значение в файле kubeconfig.

PROPERTY_NAME — имя, разделенное точками, где каждый элемент обозначает имя атрибута или ключ карты. Ключи карты не могут содержать точки.

PROPERTY_VALUE — новое значение, которое нужно задать. Для двоичных полей, таких как 'certificate-authority-data', требуется строка в кодировке base64, если не используется флаг --set-raw-bytes.

Если указать имя атрибута, которое уже существует, новые поля будут объединены с существующими значениями.

Использование

$ kubectl config set PROPERTY_NAME PROPERTY_VALUE

Флаги

set-cluster

Задать только поле server для записи кластера e2e, не изменяя остальные значения

kubectl config set-cluster e2e --server=https://1.2.3.4

Встроить данные центра сертификации для записи кластера e2e

kubectl config set-cluster e2e --embed-certs --certificate-authority=~/.kube/e2e/kubernetes.ca.crt

Отключить проверку сертификата для записи кластера e2e

kubectl config set-cluster e2e --insecure-skip-tls-verify=true

Задать собственное имя TLS-сервера для проверки записи кластера e2e

kubectl config set-cluster e2e --tls-server-name=my-cluster-name

Задать URL прокси для записи кластера e2e

kubectl config set-cluster e2e --proxy-url=https://1.2.3.4

Задать запись кластера в kubeconfig.

Указание уже существующего имени приведет к объединению новых полей с существующими значениями этих полей.

Использование

$ kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certificate/authority] [--insecure-skip-tls-verify=true] [--tls-server-name=example.com]

Флаги

set-context

Задайте поле пользователя для записи контекста gce, не изменяя другие значения

kubectl config set-context gce --user=cluster-admin

Задайте запись контекста в kubeconfig.

Указание уже существующего имени приведет к объединению новых полей с существующими значениями этих полей.

Использование

$ kubectl config set-context [NAME | --current] [--cluster=cluster_nickname] [--user=user_nickname] [--namespace=namespace]

Флаги

set-credentials

Задайте только поле "client-key" для записи "cluster-admin", не изменяя другие значения

kubectl config set-credentials cluster-admin --client-key=~/.kube/admin.key

Задайте базовую аутентификацию для записи "cluster-admin"

kubectl config set-credentials cluster-admin --username=admin --password=uXFGweU9l35qcif

Встройте данные сертификата клиента в запись "cluster-admin"

kubectl config set-credentials cluster-admin --client-certificate=~/.kube/admin.crt --embed-certs=true

Включите поставщика аутентификации Google Compute Platform для записи "cluster-admin"

kubectl config set-credentials cluster-admin --auth-provider=gcp

Включите поставщика аутентификации OpenID Connect для записи "cluster-admin" с дополнительными аргументами

kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-id=foo --auth-provider-arg=client-secret=bar

Удалите значение конфигурации "client-secret" для поставщика аутентификации OpenID Connect из записи "cluster-admin"

kubectl config set-credentials cluster-admin --auth-provider=oidc --auth-provider-arg=client-secret-

Включите новый подключаемый модуль аутентификации exec для записи "cluster-admin"

kubectl config set-credentials cluster-admin --exec-command=/path/to/the/executable --exec-api-version=client.authentication.k8s.io/v1beta1

Задайте новые аргументы подключаемого модуля аутентификации exec для записи "cluster-admin"

kubectl config set-credentials cluster-admin --exec-arg=arg1 --exec-arg=arg2

Создайте или обновите переменные среды подключаемого модуля аутентификации exec для записи "cluster-admin"

kubectl config set-credentials cluster-admin --exec-env=key1=val1 --exec-env=key2=val2

Удалите переменные среды подключаемого модуля аутентификации exec для записи "cluster-admin"

kubectl config set-credentials cluster-admin --exec-env=var-to-remove-

Задайте запись пользователя в kubeconfig.

Указание уже существующего имени приведет к объединению новых полей с существующими значениями.

Флаги сертификата клиента: --client-certificate=certfile --client-key=keyfile

Флаг токена Bearer: --token=bearer_token

Флаги базовой аутентификации: --username=basic_user --password=basic_password

Токен Bearer и базовая аутентификация взаимоисключают друг друга.

Использование

$ kubectl config set-credentials NAME [--client-certificate=path/to/certfile] [--client-key=path/to/keyfile] [--token=bearer_token] [--username=basic_user] [--password=basic_password] [--auth-provider=provider_name] [--auth-provider-arg=key=value] [--exec-command=exec_command] [--exec-api-version=exec_api_version] [--exec-arg=arg] [--exec-env=key=value]

Флаги

unset

Удалите значение current-context

kubectl config unset current-context

Удалите пространство имен из контекста foo

kubectl config unset contexts.foo.namespace

Удалите отдельное значение из файла kubeconfig.

PROPERTY_NAME — это имя, компоненты которого разделены точками; каждый компонент обозначает имя атрибута или ключ карты. Ключи карты не могут содержать точки.

Использование

$ kubectl config unset PROPERTY_NAME

use-context

Используйте контекст кластера minikube

kubectl config use-context minikube

Задайте current-context в файле kubeconfig.

Использование

$ kubectl config use-context CONTEXT_NAME

view

Покажите объединенные настройки kubeconfig

kubectl config view

Покажите объединенные настройки kubeconfig, необработанные данные сертификатов и раскрытые секреты

kubectl config view --raw

Получите пароль пользователя e2e

kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

Покажите объединенные настройки kubeconfig или указанный файл kubeconfig.

Для извлечения определенных значений можно использовать --output jsonpath={...} с выражением jsonpath.

Использование

$ kubectl config view

Флаги

explain

Получите документацию по ресурсу и его полям

kubectl explain pods

Получите документацию по определенному полю ресурса

kubectl explain pods.spec.containers

Выведите список полей поддерживаемых ресурсов.

Эта команда описывает поля, связанные с каждым поддерживаемым ресурсом API. Поля задаются с помощью простого идентификатора JSONPath:

<type>.<fieldName>[.<fieldName>]

Добавьте флаг --recursive, чтобы вывести сразу все поля без описаний. Информация о каждом поле извлекается с сервера в формате OpenAPI.

Для получения полного списка поддерживаемых ресурсов используйте "kubectl api-resources".

Использование

$ kubectl explain RESOURCE

Флаги

options

Выведите флаги, наследуемые всеми командами

kubectl options

Выведите список флагов, наследуемых всеми командами

Использование

$ kubectl options

plugin

Предоставляет утилиты для взаимодействия с подключаемыми модулями.

Подключаемые модули предоставляют дополнительные возможности, не входящие в основной дистрибутив командной строки. Дополнительные сведения о создании собственных подключаемых модулей см. в документации и примерах.

Самый простой способ найти и установить подключаемые модули — воспользоваться проектом Kubernetes krew. Инструкции по установке krew см. на странице https://krew.sigs.k8s.io/docs/user-guide/setup/install/ krew.sigs.k8s.io https://krew.sigs.k8s.io/docs/user-guide/setup/install/

Использование

$ kubectl plugin [flags]

list

Выведите список всех доступных подключаемых модулей

kubectl plugin list

Выведите список всех доступных файлов подключаемых модулей в PATH пользователя.

Доступные файлы подключаемых модулей — это файлы, которые: - являются исполняемыми - находятся в любом каталоге из PATH пользователя - начинаются с "kubectl-"

Использование

$ kubectl plugin list

Флаги

version

Выведите версии клиента и сервера для текущего контекста

kubectl version

Выведите сведения о версиях клиента и сервера для текущего контекста.

Использование

$ kubectl version

Флаги