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

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

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

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

create

Создать pod с данными из pod.json.

kubectl create -f ./pod.json

Создать pod на основе 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

Флаги

clusterrole

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

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

Создать ClusterRole с именем "pod-reader" со значением ResourceName.

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

Создать ClusterRole с именем "foo" со значением API Group.

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

Создать ClusterRole с именем "foo" со значением SubResource.

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

Создать ClusterRole с именем "foo" со значением NonResourceURL.

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

Создать ClusterRole с именем "monitoring" со значением AggregationRule.

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

Создать ClusterRole.

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

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

Флаги

clusterrolebinding

Создать ClusterRoleBinding для user1, user2 и group1, используя ClusterRole cluster-admin.

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

Создать ClusterRoleBinding для определенного ClusterRole.

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

$ 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 на основе файла, ключ по умолчанию устанавливается равным имени файла без расширения, а значение по умолчанию — содержимое файла. Если имя файла без расширения является недопустимым ключом, вы можете указать альтернативный ключ.

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

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

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

Флаги

cronjob

Создать cronjob

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

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

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

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

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

$ 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", указывающий на service 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 с бэкендом по умолчанию.

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 из CronJob с именем "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 disruption budget с именем my-pdb, который выберет все pods с меткой app=rails # и потребует, чтобы хотя бы один из них был доступен в любой момент времени.

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

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

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

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

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

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

Флаги

priorityclass

Создать priorityclass с именем high-priority

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

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

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

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

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

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

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

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

Флаги

quota

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

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

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

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

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

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

Флаги

роль

Создать роль с именем «pod-reader», разрешающую пользователю выполнять «get», «watch» и «list» для pod

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]

Флаги

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

Создать RoleBinding для user1, user2 и group1, используя ClusterRole «admin»

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

Создать RoleBinding для определённой роли или ClusterRole.

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

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

Флаги

секрет

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

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

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

Создать новый секрет для использования с реестрами 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 docker-registry NAME --docker-username=user --docker-password=password --docker-email=email [--docker-server=string] [--from-literal=key1=value1] [--dry-run=server|client|none]

Флаги

секрет_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 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 (в режиме headless)

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

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

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

$ kubectl create 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 вместо только pod, что позволит авторам приложений ссылаться на сервисы, которые существуют вне платформы, в других кластерах или локально.

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

$ kubectl create 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 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 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, в версии "v1" группы API "apps":

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|wide|custom-columns=...|custom-columns-file=...|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...] (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 с использованием набора реплик, который служит на порту 80 и подключается к контейнерам на порту 8000.

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

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

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

Экспонировать ресурс как новую Kubernetes-службу.

Ищет развертывание, службу, набор реплик, контроллер репликации или pod по имени и использует селектор для этого ресурса как селектор для новой службы на указанном порту. Развертывание или набор реплик будут экспонированы как служба только в том случае, если его селектор может быть преобразован в селектор, который поддерживает служба, т. е. когда селектор содержит только компонент 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 или передать --now, чтобы установить период благоразумия в 1. Поскольку эти ресурсы часто представляют сущности в кластере, удаление может не быть подтверждено немедленно. Если узел, на котором находится pod, выведен из строя или не может связаться с API-сервером, завершение может занять значительно больше времени, чем период благоразумия. Чтобы принудительно удалить ресурс, необходимо указать флаг --force. Примечание: только подмножество ресурсов поддерживает плавное удаление. При отсутствии поддержки --grace-period игнорируется.

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

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

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

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

Применить JSON, переданный в стандартный ввод, к pod.

cat pod.json | kubectl apply -f -

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

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

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

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

Примените конфигурацию к ресурсу по имени файла или стандартному вводу. Имя ресурса должно быть указано. Этот ресурс будет создан, если он ещё не существует. Для использования «apply» всегда сначала создавайте ресурс с помощью «apply» или «create --save-config».

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

Предупреждение о версии альфа: функциональность --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

Просмотрите последние применённые аннотации конфигурации по типу/имени или файлу.

По умолчанию вывод будет выведен в формате YAML на стандартный поток вывода. Можно использовать опцию -o для изменения формата вывода.

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

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

Флаги

annotate

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

kubectl annotate pods foo description='my frontend'

Обновить под, идентифицированный по типу и имени в "pod.json"

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

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

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

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

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

Обновить под 'foo' только если ресурс не изменён с версии 1.

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

Обновить под '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.

Ищет развертывание, набор реплик, состояние StatefulSet или контроллер репликации по имени и создаёт автомасштабируемый контроллер, использующий данный ресурс в качестве ссылки. Автомасштабируемый контроллер может автоматически увеличивать или уменьшать количество развернутых подов в системе по мере необходимости.

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

$ 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' автоматизирует общие задачи отладки для объектов кластера, идентифицированных по ресурсу и имени. Если ресурс не указан, будут использоваться Pod по умолчанию.

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

• Workload: Создать копию существующего Pod с измененными атрибутами, например, изменить тег образа на новую версию.
• Workload: Добавить временный контейнер в уже запущенный Pod, например, для добавления инструментов отладки без перезапуска Pod.
• Node: Создать новый Pod, который выполняется в пространстве имен хоста узла и может получить доступ к файловой системе узла.

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

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

Флаги

diff

Ресурсы diff включены в pod.json.

kubectl diff -f pod.json

Diff файла, считанного из stdin

cat service.yaml | kubectl diff -f -

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

Вывод всегда в формате YAML.

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

По умолчанию, команда "diff", доступная в вашей системе, будет запущена с параметрами "-u" (unified diff) и "-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%20kustomize%20.

Использовать общую директорию конфигураций

kubectl kustomize /home/configuration/production

Использовать URL

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

Вывести набор API-ресурсов, сгенерированных из инструкций в файле kustomization.yaml.

Аргументом должен быть путь к директории, содержащей файл, или URL репозитория Git с суффиксом пути, указывающим на него относительно корня репозитория.

kubectl kustomize somedir

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

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

Частично обновить узел с помощью стратегической слияния патча. Укажите патч как 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]

Флаги

replace

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

kubectl replace -f ./pod.json

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

cat pod.json | kubectl replace -f -

Обновить версию образа (тег) под с одним контейнером на 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

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

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

• deployments
• daemonsets
• statefulsets

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

$ kubectl rollout SUBCOMMAND

история

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

kubectl rollout history deployment/abc

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

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

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

$ kubectl rollout pause RESOURCE

Флаги

restart

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

kubectl rollout restart deployment/nginx

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

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

Откатиться к версии daemonset 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]

Флаги

масштабирование

Изменить масштаб реплики с именем '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.

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

Если указаны --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

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

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

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

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), job, 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

Обновить изображение всех контейнеров daemonset 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

Обновление существующего(их) изображения контейнера ресурсов.

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

pod (po), replicationcontroller (rc), deployment (deploy), daemonset (ds), 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 с учетной записью сервиса из локального файла, без обращения к apiserver

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

Флаги

тема

Обновить ClusterRoleBinding для serviceaccount1

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

Обновить RoleBinding для 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

Обновить пользователя, группу или учётную запись сервиса в RoleBinding/ClusterRoleBinding.

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

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

Флаги

ожидание

Ожидание под "busybox1" для наличия условия статуса типа "Ready".

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

Ожидание удаления под "busybox1" с таймаутом 60 сек после команды "delete".

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

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

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

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

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

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

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

Флаги

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

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

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

attach

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

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

Получить вывод из первого под заданного ReplicaSet nginx

kubectl attach rs/nginx

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

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

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

Флаги

auth

Просмотр авторизации

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

$ kubectl auth

могу-ли-я

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

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

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

kubectl auth can-i list deployments.apps

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

kubectl auth can-i '*' '*'

Проверить, могу ли я получить job с именем "bar" в пространстве имён "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/

Перечислить все разрешённые действия в пространстве имён "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, RoleBinding, ClusterRole и ClusterRoleBinding объектов.

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

Существующие роли обновляются, чтобы включать разрешения в входных объектах, и удаляются дополнительные разрешения, если указан --remove-extra-permissions.

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

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

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

$ kubectl auth reconcile -f FILENAME

Флаги

cp

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

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 в пространстве имён

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, управляемых replication controller 'frontend' (pod, созданные rc, получают имя 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 из pod mypod

kubectl exec mypod -c ruby-container -- date

Переключение в режим терминала raw, отправка stdin в 'bash' в контейнере ruby из 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...]

Флаги

logs

Возвращение снимков логов из pod nginx с одним контейнером

kubectl logs nginx

Возвращение снимков логов из pod nginx с несколькими контейнерами

kubectl logs nginx --all-containers=true

Возвращение снимков логов из всех контейнеров в pod, определённых меткой app=nginx

kubectl logs -lapp=nginx --all-containers=true

Возвращение снимка логов предыдущего завершённого контейнера ruby из pod web-1

kubectl logs -p -c ruby web-1

Начало потоковой передачи логов контейнера ruby в pod web-1

kubectl logs -f -c ruby web-1

Начало потоковой передачи логов из всех контейнеров в pod, определённых меткой app=nginx

kubectl logs -f -lapp=nginx --all-containers=true

Отображение только последних 20 строк вывода в pod nginx

kubectl logs --tail=20 nginx

Отображение всех логов из pod 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

Перенаправлять один или несколько локальных портов в под. Для выполнения этой команды на узле должен быть установлен сокет 'socat'.

Используйте тип/имя ресурса, например, 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 и некоторых статических файлов:

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

Выше позволяет 'curl localhost:8001/api/v1/pods'. # Для проксирования всего API kubernetes с другим корнем используйте:

$ kubectl proxy --api-prefix=/custom/

Выше позволяет 'curl localhost:8001/custom/api/v1/pods' # Запустить прокси к API-серверу kubernetes на порте 8011, предоставляя статическое содержимое из ./local/www/

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

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

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

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

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

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

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

$ kubectl top

узел

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

kubectl top node

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

kubectl top node NODE_NAME

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

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

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

$ kubectl top node [NAME | -l label]

Флаги

под

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

kubectl top pod

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

kubectl top pod --namespace=NAMESPACE

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

kubectl top pod POD_NAME --containers

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

kubectl top pod -l name=myLabel

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

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

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

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

$ kubectl top pod [NAME | -l label]

Флаги

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

api-versions

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

kubectl api-versions

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

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

$ kubectl api-versions

certificate

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

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

$ kubectl certificate SUBCOMMAND

approve

Утвердить запрос на подписание сертификата.

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

ВНИМАНИЕ: В зависимости от запрошенных атрибутов, выданный сертификат может предоставить запросившему доступ к ресурсам кластера или аутентификацию в качестве запрошенной личности. Перед утверждением CSR убедитесь, что вы понимаете, какие возможности может предоставить подписанный сертификат.

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

$ kubectl certificate approve (-f FILENAME | NAME)

Флаги

deny

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

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 для вывода всех пространств имён.

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

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

$ kubectl cluster-info dump

Флаги

cordon

Пометить узел "foo" как неподлежащий планированию.

kubectl cordon foo

Пометить узел как неподлежащий планированию.

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

$ kubectl cordon NODE

Флаги

drain

Откачать узел "foo", даже если на нём есть под, не управляемые ReplicationController, ReplicaSet, Job, DaemonSet или StatefulSet.

$ kubectl drain foo --force

Как выше, но прервать, если есть под, не управляемые ReplicationController, ReplicaSet, Job, DaemonSet или StatefulSet, и использовать период благосклонности 15 минут.

$ kubectl drain foo --grace-period=900

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

Указанный узел будет помечен как неподлежащий планированию, чтобы предотвратить появление новых под. 'drain' удаляет под, если APIServer поддерживает http://kubernetes.io/docs/admin/disruptions/ . В противном случае он будет использовать обычное DELETE для удаления под. 'drain' удаляет или выгоняет все под, кроме зеркальных под (которые не могут быть удалены через API-сервер). Если есть под, управляемые DaemonSet, drain не будет продолжаться без --ignore-daemonsets, и в любом случае не будет удалять под, управляемые DaemonSet, потому что эти под будут немедленно заменены контроллером DaemonSet, который игнорирует метки, указывающие на непригодность для планирования. Если есть под, которые не являются зеркальными под и не управляются ReplicationController, ReplicaSet, DaemonSet, StatefulSet или Job, то drain не будет удалять никакие под, если вы не используете --force. --force также позволит продолжить удаление, если управляющий ресурс одной или нескольких под отсутствует.

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

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

http://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

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

• Пометка состоит из ключа, значения и эффекта. В качестве аргумента здесь она выражается как ключ=значение:эффект.
• Ключ должен начинаться с буквы или цифры и может содержать буквы, цифры, дефисы, точки и символы подчеркивания, до 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

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

ПРИМЕЧАНИЕ: «kubectl alpha debug» устарело и будет удалено в релизе 1.21. Используйте вместо него «kubectl debug».

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

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

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

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

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

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

Флаги

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, это должно заработать сразу. ## Если вы установили его другими способами, возможно, вам нужно добавить completion в ваш каталог completion

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

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

source <(kubectl completion bash)

Запись кода bash completion в файл и загрузка его из .bash_profile

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

Kubectl shell completion

source '$HOME/.kube/completion.bash.inc' " >> $HOME/.bash_profile source $HOME/.bash_profile

Загрузка кода completion для kubectl для zsh[1] в текущую оболочку

source <(kubectl completion zsh)

Установка кода completion для kubectl для zsh[1] для автоматической загрузки при запуске

kubectl completion zsh > "${fpath[1]}/_kubectl"

Вывод кода shell completion для указанной оболочки (bash или zsh). Код оболочки должен быть оценён для предоставления интерактивного completion команд kubectl. Это можно сделать, загрузив его из .bash_profile.

Подробные инструкции по этому вопросу доступны здесь: https://kubernetes.io/docs/tasks/tools/install-kubectl/#enabling-shell-autocompletion

Примечание для пользователей zsh: [1] completion для 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

Установка basic auth для записи "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 auth для записи "cluster-admin"

kubectl config set-credentials cluster-admin --exec-env=var-to-remove-

Устанавливает запись пользователя в kubeconfig

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

Флаги сертификата клиента: --client-certificate=certfile --client-key=keyfile

Флаги токена Bearer: --token=bearer_token

Флаги аутентификации Basic: --username=basic_user --password=basic_password

Токен Bearer и аутентификация Basic взаимно исключают друг друга.

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

$ 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

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

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

$ 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

Список всех доступных файлов плагинов в пути пользователя.

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

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

$ kubectl plugin list

Флаги

version

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

kubectl version

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

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

$ kubectl version

Флаги