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

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

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

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

create

Создать под на основе данных в pod.json

kubectl create -f ./pod.json

Создать под на основе JSON, переданного в стандартный ввод

cat pod.json | kubectl create -f -

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

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

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

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

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

$ kubectl create -f FILENAME

Флаги

роли кластера

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

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 Group

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

Создать роль кластера с именем "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]

Флаги

связывание ролей кластера

Создать привязку ролей кластера для пользователей 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

Создать новый configmap с именем my-config на основе папки bar

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

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

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

Создать новый configmap с именем my-config с ключами key1=config1 и key2=config2

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

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

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

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

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

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

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

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

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

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

$ 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

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

kubectl create deployment my-dep --image=busybox

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

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

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

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

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

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

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

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

$ 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:порт и Ingress Class как "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 с несколькими хостами и pathType как 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, используя определённый секрет и pathType как Prefix

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

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

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

Создать job

kubectl create job my-job --image=busybox

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

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

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

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

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

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

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

Флаги

namespace

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

kubectl create namespace my-namespace

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

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

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

Флаги

poddisruptionbudget

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

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

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

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

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

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

$ 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, который не может прерывать pods с более низким приоритетом

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

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

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

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

Флаги

квота

Создать новый ресурсный лимит с именем 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]

Флаги

роль

Создать роль с именем «pod-reader», которая позволяет пользователю выполнять «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 Group

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

Создать роль с именем «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]

Флаги

связывание ролей

Создать привязку ролей для 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]

Флаги

секрет

Создать секрет, используя указанную подкоманду.

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

$ kubectl create secret

секрет реестра Docker

Если у вас ещё нет файла .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 из файла env

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

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

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

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

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

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

$ kubectl create 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

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

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

$ kubectl create service

service clusterip

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

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

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

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

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

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

$ 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]

Флаги

get

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

kubectl get pods

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

kubectl get pods -o wide

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

kubectl get replicationcontroller web

Список развертываний в формате JSON, в группе API "apps" версии "v1"

kubectl get deployments.v1.apps -o json

Вывод информации об одном под в формате JSON

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

Список под, идентифицированного по типу и имени, указанным в "pod.yaml", в формате JSON

kubectl get -f pod.yaml -o json

Список ресурсов из каталога с kustomization.yaml - например, dir/kustomization.yaml

kubectl get -k dir/

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

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

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

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

Неинициализированные объекты не отображаются, если не передать --include-uninitialized.

Указав вывод как '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]

Флаги

Запуск

Запустить 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, но перегрузить spec частичным набором значений, разобранных из 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>

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

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

$ 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

Создать службу для под 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 с использованием replica set, который обслуживает порт 80 и подключается к контейнерам по порту 8000

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

Создать службу для nginx deployment, который обслуживает порт 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]

Флаги

удаление

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

kubectl delete -f ./pod.json

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

kubectl delete -k dir

Удалить pod, основываясь на типе и имени в JSON, переданном в стандартный ввод

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

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

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

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

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

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

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

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

Флаги

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

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

применение

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

kubectl apply -f ./pod.json

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

kubectl apply -k dir/

Применить переданный в stdin JSON к под

cat pod.json | kubectl apply -f -

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

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

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

kubectl apply --prune -f manifest.yaml --all --prune-whitelist=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

Изменить аннотации последней применённой конфигурации по типу/имени в YAML

kubectl apply edit-last-applied deployment/nginx

Изменить аннотации последней применённой конфигурации по файлу в 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

Установить последнюю применённую конфигурацию ресурса, соответствующую содержимому файла

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

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

kubectl apply set-last-applied -f path/

Установить последнюю применённую конфигурацию ресурса, соответствующую содержимому файла; создаст аннотацию, если она не существует

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'

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

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", с количеством pod от 2 до 10, без указанного целевого использования CPU, поэтому будет использоваться политика autoscaling по умолчанию

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

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

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

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

Ищет deployment, replica set, stateful set или replication controller по имени и создаёт autoscaler, который использует данный ресурс в качестве ссылки. Autoscaler может автоматически увеличивать или уменьшать количество развернутых pod в системе по мере необходимости.

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

$ 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.

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

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

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

Примечание: KUBECTL_EXTERNAL_DIFF, если используется, должен следовать этой конвенции.

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

$ kubectl diff -f FILENAME

Флаги

edit

Редактировать сервис под названием 'docker-registry'

kubectl edit svc/docker-registry

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

KUBE_EDITOR="nano" kubectl edit svc/docker-registry

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

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

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

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

Редактировать ресурс из системного редактора.

Команда 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

Флаги

метка

Обновить pod 'foo' с меткой 'unhealthy' и значением 'true'

kubectl label pods foo unhealthy=true

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

kubectl label --overwrite pods foo status=unhealthy

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

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 символов каждый.
• Ключ может начинаться с префикса доменного имени и одиночного '/', например, 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]

Флаги

патч

Частично обновить узел с помощью стратегического объединяющего патча, указав патч в формате JSON

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

Частично обновить узел с помощью стратегического объединяющего патча, указав патч в формате YAML

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

Частично обновить узел, идентифицированный типом и именем, указанным в "node.json", с помощью стратегического объединяющего патча

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 патча с позиционными массивами

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

Обновить поля ресурса с помощью стратегического объединяющего патча, JSON объединяющего патча или JSON патча.

Принимаются форматы JSON и YAML.

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

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

Флаги

замена

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

kubectl replace -f ./pod.json

Заменить pod на основе JSON, переданного в стандартный ввод

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

Замена ресурса по имени файла или стандартному вводу.

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

$ kubectl get TYPE NAME -o yaml

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

$ kubectl replace -f FILENAME

Флаги

развертывание

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

kubectl rollout undo deployment/abc

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

kubectl rollout status daemonset/foo

Управление развертыванием ресурса.

Допустимые типы ресурсов включают:

• deployments
• daemonsets
• statefulsets

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

$ kubectl rollout SUBCOMMAND

история

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

kubectl rollout history deployment/abc

Просмотреть детали ревизии daemonset 3

kubectl rollout history daemonset/abc --revision=3

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

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

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

Флаги

пауза

Отметить deployment nginx как приостановленный # Любое текущее состояние deployment продолжит свою функцию; новые обновления # deployment не будут иметь эффекта, пока deployment приостановлен

kubectl rollout pause deployment/nginx

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

Приостановленные ресурсы не будут согласованы контроллером. Используйте «kubectl rollout resume» для возобновления приостановленного ресурса. В настоящее время только deployments поддерживают приостановку.

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

$ kubectl rollout pause RESOURCE

Флаги

restart

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

kubectl rollout restart deployment/nginx

Перезапустить набор демонов

kubectl rollout restart daemonset/abc

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

Развертывание ресурса будет перезапущено.

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

$ 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

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

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

Изменить количество реплик для StatefulSet 'web' на 3

kubectl scale --replicas=3 statefulset/web

Установить новое количество реплик для развертывания, реплицированного набора, контроллера репликации или StatefulSet.

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

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

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

Импортировать определённые ключи из конфиг-мапа

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 -", переменные окружения можно читать из стандартного ввода с использованием стандартного синтаксиса env.

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

под (po), контроллер репликации (rc), деплоймент (deploy), демона (ds), statefulset (sts), cronjob (cj), replicaset (rs)

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

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

Флаги

image

Установить образ контейнера nginx деплоймента на 'nginx:1.9.1', а образ контейнера busybox на 'busybox'

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

Обновить образ контейнера nginx для всех деплойментов и rc на 'nginx:1.9.1'

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

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

kubectl set image daemonset abc *=nginx:1.9.1

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

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

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

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

под (po), контроллер репликации (rc), деплоймент (deploy), демона (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

Флаги

ресурсы

Установить лимиты ЦП контейнера nginx развертывания для "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

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

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

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

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

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

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

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

Флаги

селектор

Установить метки и селектор перед созданием пары развертывания/сервиса

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]

Флаги

Учетная запись сервиса

Установить учетную запись сервиса развертывания nginx-deployment на serviceaccount1

kubectl set serviceaccount deployment nginx-deployment serviceaccount1

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

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

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

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

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

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

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

Подождать, пока pod "busybox1" будет содержать условие статуса типа "Ready"

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

Значение условия статуса по умолчанию — true; можно установить в false

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

Подождать удаления pod "busybox1" с таймаутом 60 сек после выполнения команды "delete"

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

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

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

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

Успешное сообщение будет выведено в стандартный вывод, показывая, когда указанное условие выполнено. Можно использовать опцию -o для изменения места вывода.

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

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

Флаги

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

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

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

attach

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

kubectl attach mypod

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

kubectl attach mypod -c ruby-container

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

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

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

kubectl attach rs/nginx

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

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

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

Флаги

auth

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

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

$ kubectl auth

can-i

Проверить возможность создания pod в любом namespace

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

Проверить возможность перечисления deployments в текущем namespace

kubectl auth can-i list deployments.apps

Проверить возможность выполнения всех операций в текущем namespace ("*" означает все)

kubectl auth can-i '*' '*'

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

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

Проверить возможность чтения журналов pod

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

Проверить доступ к URL /logs/

kubectl auth can-i get /logs/

Перечислить все разрешенные действия в namespace "foo"

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

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

VERB — это логический глагол API Kubernetes, такой как 'get', 'list', 'watch', 'delete' и т. д. TYPE — это ресурс Kubernetes. Псевдонимы и группы будут разрешены. NONRESOURCEURL — это частичный URL, начинающийся с "/". NAME — это имя конкретного ресурса Kubernetes.

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

$ 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.

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

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

$ kubectl auth reconcile -f FILENAME

Флаги

cp

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

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

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

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

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

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

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

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

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

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

Скопировать /tmp/foo из удалённого pod в /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

Описание pod

kubectl describe pods/nginx

Описание pod, определённого по типу и имени в "pod.json"

kubectl describe -f pod.json

Описание всех pod

kubectl describe pods

Описание pod по метке name=myLabel

kubectl describe po -l name=myLabel

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

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)

Флаги

exec

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

kubectl exec mypod -- date

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

kubectl exec mypod -c ruby-container -- date

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

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

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

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

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

kubectl exec deploy/mydeployment -- date

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

kubectl exec svc/myservice -- date

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

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

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

Флаги

Журналы

Возвращает моментальный снимок логов из под 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

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

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

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

Флаги

Перенаправление портов

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

kubectl port-forward pod/mypod 5000 6000

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

kubectl port-forward deployment/mydeployment 5000 6000

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

kubectl port-forward service/myservice 8443:https

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

kubectl port-forward pod/mypod 8888:5000

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

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

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

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

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

kubectl port-forward pod/mypod :5000

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

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

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

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

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

Флаги

Прокси

Для проксирования всего 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 по другому корню # Вы можете получить информацию о pod с помощью '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 на произвольном локальном порту # Выбранный порт сервера будет выведен в стандартный вывод

kubectl proxy --port=0

Запустить прокси к серверу API Kubernetes, изменив префикс API на k8s-api # Это делает, например, API pods доступным по адресу 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

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

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

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

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

$ kubectl top

узел

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

kubectl top node

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

kubectl top node NODE_NAME

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

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

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

$ kubectl top node [NAME | -l label]

Флаги

pod

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

kubectl top pod

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

kubectl top pod --namespace=NAMESPACE

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

kubectl top pod POD_NAME --containers

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

kubectl top pod -l name=myLabel

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

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

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

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

$ kubectl top pod [NAME | -l label]

Флаги

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

api-versions

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

kubectl api-versions

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

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

$ kubectl api-versions

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

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

kubectl cluster-info dump

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

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

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

kubectl cluster-info dump --all-namespaces

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

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

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

Команда также выводит логи всех pod в кластере; эти логи выводятся в разные директории, в зависимости от пространства имён и имени pod.

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

$ 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/ . В противном случае будет использоваться обычное удаление DELETE. Команда 'drain' удаляет или вытесняет все поды, кроме зеркальных подов (которые не могут быть удалены через сервер API). Если существуют поды, управляемые набором демонов, drain не будет продолжаться без флага --ignore-daemonsets, и независимо от этого не удалит никакие поды, управляемые набором демонов, так как эти поды немедленно будут заменены контроллером набора демонов, который игнорирует пометки о нераспределяемости. Если есть какие-либо поды, которые не являются ни зеркальными, ни управляемыми контроллером репликации, набором реплик, набором демонов, набором состояний или заданием, то drain не будет удалять поды, если не использовать флаг --force. --force также позволит продолжить удаление, если управляющий ресурс одного или нескольких подов отсутствует.

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

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

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 символов.
• Ключ может начинаться с префикса доменного имени и одиночного '/', например 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

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-ресурсы с указанным APIGroup.

kubectl api-resources --api-group=extensions

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

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

$ kubectl api-resources

Флаги

completion

Установка bash-completion на 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 ## Если bash-completion не установлен на Linux, установите пакет '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"

Вывод кода завершения оболочки для указанной оболочки (bash или zsh). Код оболочки должен быть оценен для предоставления интерактивного завершения команд 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

Отключить проверку сертификатов для записи кластера dev

kubectl config set-cluster e2e --insecure-skip-tls-verify=true

Установить пользовательское имя сервера TLS для валидации для записи кластера e2e

kubectl config set-cluster e2e --tls-server-name=my-cluster-name

Установить запись кластера в 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

Установить поле user в записи контекста 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

Сбросить текущий контекст

kubectl config unset current-context

Сбросить пространство имен в контексте foo

kubectl config unset contexts.foo.namespace

Сбросить отдельное значение в файле kubeconfig.

Имя_СВОЙСТВА — это имя, разделенное точками, где каждый токен представляет либо имя атрибута, либо ключ карты. Ключи карт не могут содержать точки.

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

$ kubectl config unset PROPERTY_NAME

use-context

Использовать контекст для кластера minikube

kubectl config use-context minikube

Установить текущий контекст в файле 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:

<тип>.<имя_поля>[.<имя_поля>]

Добавьте флаг --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/

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

$ kubectl plugin [flags]

list

Отобразить все доступные файлы плагинов в PATH пользователя.

Доступные файлы плагинов — это те, которые: - исполняемые - находятся в любом месте в PATH пользователя - начинаются с "kubectl-"

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

$ kubectl plugin list

Флаги

version

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

kubectl version

Вывести информацию о версии клиента и сервера для текущего контекста.

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

$ kubectl version

Флаги