Это многостраничный печатный вид этого раздела. Нажмите что бы печатать.

Вернуться к обычному просмотру страницы.

Ссылки

Этот раздел документации Kubernetes содержит ссылки.

Ссылки API

Клиентские библиотеки API

Для вызова API Kubernetes из языка программирования вы можете использовать клиентские библиотеки. Официально поддерживаемые клиентские библиотеки:

Ссылки CLI

  • kubectl - Основной инструмент CLI для запуска команд и управления кластерами Kubernetes.
  • JSONPath - Документация по синтаксису использования выражений JSONPath с kubectl.
  • kubeadm - Инструмент CLI для легкого разворачивания защищенного кластера Kubernetes.
  • kubefed - Инструмент CLI для помощи в администрировании федеративных кластеров.

Ссылки на конфигурации

  • kubelet - Основной агент ноды, который работает на каждой ноде. Kubelet принимает набор PodSpecs и гарантирует, что описанные контейнеры работают исправно.
  • kube-apiserver - REST API, который проверяет и настраивает данные для объектов API, таких, как модули, службы, контроллеры и репликации.
  • kube-controller-manager - Демон, который встраивает основные контрольные циклы, поставляемые с Kubernetes.
  • kube-proxy - Может выполнять простую пересылку запросов TCP/UDP или циклическую переадресацию TCP/UDP через набор бекендов.
  • kube-scheduler - Планировщик, который управляет доступностью, производительностью и хранилищем.
  • federation-apiserver - Сервер API для федеративных кластеров.
  • federation-controller-manager - Демон, который встраивает основные контрольные циклы, поставляемые с Kubernetes.

Дизайн документация

Архив документации по дизайну для функциональности Kubernetes. Начните с Архитектуры Kubernetes и Обзора дизайна Kubernetes.

1 - Стандартизированный глоссарий

2 - kubectl CLI

2.1 - Обзор kubectl

Kubectl — это инструмент командной строки для управления кластерами Kubernetes. kubectl ищет файл config в директории $HOME/.kube. Вы можете указать другие файлы kubeconfig, установив переменную окружения KUBECONFIG или флаг --kubeconfig.

На этой странице рассматривается синтаксис kubectl, описаны командные операции и приведены распространённые примеры. Подробную информацию о каждой команде, включая все поддерживаемые в ней флаги и подкоманды, смотрите в справочной документации kubectl. Инструкции по установке находятся на странице Установка и настройка kubectl.

Синтаксис

Используйте следующий синтаксис для выполнения команд kubectl в терминале:

kubectl [command] [TYPE] [NAME] [flags]

где command, TYPE, NAME и flags:

  • command: определяет выполняемую операцию с одним или несколькими ресурсами, например, create, get, describe, delete.

  • TYPE: определяет тип ресурса. Типы ресурсов не чувствительны к регистру, кроме этого вы можете использовать единственную, множественную или сокращенную форму. Например, следующие команды выведут одно и то же.

    ```shell
    kubectl get pod pod1
    kubectl get pods pod1
    kubectl get po pod1
    ```
    
  • NAME: определяет имя ресурса. Имена чувствительны к регистру. Если имя не указано, то отображаются подробности по всем ресурсам, например, kubectl get pods.

    При выполнении операции с несколькими ресурсами можно выбрать каждый ресурс по типу и имени, либо сделать это в одном или нескольких файлов:

    • Выбор ресурсов по типу и имени:

      • Сгруппировать ресурсы, если все они одного типа: TYPE1 name1 name2 name<#>.
        Пример: kubectl get pod example-pod1 example-pod2

      • Выбор нескольких типов ресурсов по отдельности: TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>.
        Пример: kubectl get pod/example-pod1 replicationcontroller/example-rc1

    • Выбор ресурсов по одному или нескольким файлов: -f file1 -f file2 -f file<#>

      • Используйте YAML вместо JSON, так как YAML удобнее для пользователей, особенно в конфигурационных файлах.
        Пример: kubectl get pod -f ./pod.yaml
  • flags: определяет дополнительные флаги. Например, вы можете использовать флаги -s или --server, чтобы указать адрес и порт API-сервера Kubernetes.

Если вам нужна помощь, выполните команду kubectl help.

Операции

В следующей таблице приведены краткие описания и общий синтаксис всех операций kubectl:

Операция Синтаксис Описание
annotate kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] Добавить или обновить аннотации одного или нескольких ресурсов.
api-versions kubectl api-versions [flags] Вывести доступные версии API.
apply kubectl apply -f FILENAME [flags] Внести изменения в конфигурацию ресурса из файла или потока stdin.
attach kubectl attach POD -c CONTAINER [-i] [-t] [flags] Подключиться к запущенному контейнеру либо для просмотра потока вывода, либо для работы с контейнером (stdin).
autoscale kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] Автоматически промасштабировать набор подов, управляемых контроллером репликации.
cluster-info kubectl cluster-info [flags] Показать информацию о главном узле и сервисах в кластере.
config kubectl config SUBCOMMAND [flags] Изменить файлы kubeconfig. Подробные сведения смотрите в отдельных подкомандах.
create kubectl create -f FILENAME [flags] Создать один или несколько ресурсов из файла или stdin.
delete kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов.
describe kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] Показать подробное состояние одного или нескольких ресурсов.
diff kubectl diff -f FILENAME [flags] Diff file or stdin against live configuration (BETA)
edit kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] Отредактировать и обновить определение одного или нескольких ресурсов на сервере, используя редактор по умолчанию.
exec kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]] Выполнить команду в контейнере пода.
explain kubectl explain [--recursive=false] [flags] Посмотреть документацию по ресурсам. Например, поды, узлы, сервисы и т.д.
expose kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] Создать Kubernetes-сервис из контроллера репликации, сервиса или пода.
get kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] Вывести один или несколько ресурсов.
label kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] Добавить или обновить метки для одного или нескольких ресурсов.
logs kubectl logs POD [-c CONTAINER] [--follow] [flags] Вывести логи контейнера в поде.
patch kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] Обновить один или несколько полей ресурса, используя стратегию слияния патча.
port-forward kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags] Переадресовать один или несколько локальных портов в под.
proxy kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags] Запустить прокси для API Kubernetes.
replace kubectl replace -f FILENAME Заменить ресурс из файла или потока stdin.
rolling-update kubectl rolling-update OLD_CONTROLLER_NAME ([NEW_CONTROLLER_NAME] --image=NEW_CONTAINER_IMAGE | -f NEW_CONTROLLER_SPEC) [flags] Выполните плавающее обновление, постепенно заменяя указанный контроллер репликации и его поды.
run kubectl run NAME --image=image [--env="key=value"] [--port=port] [--replicas=replicas] [--dry-run=bool] [--overrides=inline-json] [flags] Запустить указанный образ в кластере.
scale kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] Обновить размер указанного контроллера репликации.
version kubectl version [--client] [flags] Отобразить версию Kubernetes, запущенного на клиенте и сервере.

Примечание: подробную информацию о командных операциях смотрите в справочную документацию kubectl.

Типы ресурсов

В следующей таблице перечислены все доступные типы ресурсов вместе с сокращенными аббревиатурами.

(Это актуальный вывод команды kubectl api-resources с версии Kubernetes 1.13.3.)

Resource Name Short Names API Group Namespaced Resource Kind
bindings true Binding
componentstatuses cs false ComponentStatus
configmaps cm true ConfigMap
endpoints ep true Endpoints
limitranges limits true LimitRange
namespaces ns false Namespace
nodes no false Node
persistentvolumeclaims pvc true PersistentVolumeClaim
persistentvolumes pv false PersistentVolume
pods po true Pod
podtemplates true PodTemplate
replicationcontrollers rc true ReplicationController
resourcequotas quota true ResourceQuota
secrets true Secret
serviceaccounts sa true ServiceAccount
services svc true Service
mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration
customresourcedefinitions crd, crds apiextensions.k8s.io false CustomResourceDefinition
apiservices apiregistration.k8s.io false APIService
controllerrevisions apps true ControllerRevision
daemonsets ds apps true DaemonSet
deployments deploy apps true Deployment
replicasets rs apps true ReplicaSet
statefulsets sts apps true StatefulSet
tokenreviews authentication.k8s.io false TokenReview
localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview
selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview
selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview
subjectaccessreviews authorization.k8s.io false SubjectAccessReview
horizontalpodautoscalers hpa autoscaling true HorizontalPodAutoscaler
cronjobs cj batch true CronJob
jobs batch true Job
certificatesigningrequests csr certificates.k8s.io false CertificateSigningRequest
leases coordination.k8s.io true Lease
events ev events.k8s.io true Event
ingresses ing extensions true Ingress
networkpolicies netpol networking.k8s.io true NetworkPolicy
poddisruptionbudgets pdb policy true PodDisruptionBudget
podsecuritypolicies psp policy false PodSecurityPolicy
clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding
clusterroles rbac.authorization.k8s.io false ClusterRole
rolebindings rbac.authorization.k8s.io true RoleBinding
roles rbac.authorization.k8s.io true Role
priorityclasses pc scheduling.k8s.io false PriorityClass
csidrivers storage.k8s.io false CSIDriver
csinodes storage.k8s.io false CSINode
storageclasses sc storage.k8s.io false StorageClass
volumeattachments storage.k8s.io false VolumeAttachment

Опции вывода

В следующих разделах рассматривается форматирование и сортировка вывода определенных команд. Дополнительные сведения о том, какие команды поддерживают разные варианты вывода, смотрите в справочной документации kubectl.

Форматирование вывода

Стандартный формат вывода всех команд kubectl представлен в понятном для человека текстовом формате. Чтобы вывести подробности в определенном формате можно добавить флаги -o или --output к команде kubectl.

Синтаксис

kubectl [command] [TYPE] [NAME] -o <output_format>

В зависимости от операции kubectl поддерживаются следующие форматы вывода:

Выходной формат Описание
-o custom-columns=<spec> Вывести таблицу с использованием списка пользовательских столбцов, разделённого запятыми.
-o custom-columns-file=<filename> Вывести таблицу с использованием шаблона с пользовательскими столбцами в файле <filename>.
-o json Вывести API-объект в формате JSON.
-o jsonpath=<template> Вывести поля, определенные в выражении jsonpath.
-o jsonpath-file=<filename> Вывести поля, определённые в выражении jsonpath из файла <filename>.
-o name Вывести только имя ресурса.
-o wide Вывести в текстовом формате с дополнительной информацией. Для подов отображается имя узла.
-o yaml Вывести API-объект в формате YAML
Пример

В данном примере следующая команда выводит подробную информацию по указанному поду в виде объекта в YAML-формате:

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

Примечание: подробную информацию о доступных форматах вывода в определенной команде смотрите в справочной документации kubectl.

Пользовательские столбцы

Для определения пользовательских столбцов и вывода в таблицу только нужных данных, можно использовать опцию custom-columns. Вы можете определить пользовательские столбцы в самой опции, либо сделать это в файле шаблона: -o custom-columns=<spec> или -o custom-columns-file=<filename>.

Примеры

Столбцы указаны в самой команде:

kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion

Столбцы указаны в файле шаблона:

kubectl get pods <pod-name> -o custom-columns-file=template.txt

где файл template.txt содержит следующее:

NAME          RSRC
metadata.name metadata.resourceVersion

Результат выполнения любой из показанной выше команды:

NAME           RSRC
submit-queue   610995

Получение вывода с сервера

kubectl может получать информацию об объектах с сервера. Это означает, что для любого указанного ресурса сервер вернет столбцы и строки по этому ресурсу, которые отобразит клиент. Благодаря тому, что сервер инкапсулирует реализацию вывода, гарантируется единообразный и понятный для человека вывод на всех клиентах, использующих один и тот же кластер.

Эта функциональность включена по умолчанию, начиная с kubectl 1.11 и выше. Чтобы отключить ее, добавьте флаг --server-print=false в команду kubectl get.

Примеры

Для вывода информации о состоянии пода, используйте следующую команду:

kubectl get pods <pod-name> --server-print=false

Вывод будет выглядеть следующим образом:

NAME       READY     STATUS              RESTARTS   AGE
pod-name   1/1       Running             0          1m

Сортировка списка объектов

Для вывода объектов в виде отсортированного списка в терминал используется флаг --sort-by к команде kubectl. Для сортировки объектов нужно указать любое числовое или строковое поле в флаге --sort-by. Для определения поля используйте выражение jsonpath.

Синтаксис

kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
Пример

Чтобы вывести список подов, отсортированных по имени, выполните команду ниже:

kubectl get pods --sort-by=.metadata.name

Примеры: распространенные операции

Посмотрите следующие примеры, чтобы ознакомиться с часто используемыми операциями kubectl:

kubectl apply - Внести изменения или обновить ресурс из файла или потока stdin.

# Создать сервис из определения в example-service.yaml.
kubectl apply -f example-service.yaml

# Создать контроллер репликации из определения в example-controller.yaml.
kubectl apply -f example-controller.yaml

# Создать объекты, которые определены в файлах с расширением .yaml, .yml или .json в директории <directory>.
kubectl apply -f <directory>

kubectl get - Вывести один или несколько ресурсов.

# Вывести все поды в текстовом формате вывода.
kubectl get pods

# Вывести все поды в текстовом формате вывода и включить дополнительную информацию (например, имя узла).
kubectl get pods -o wide

# Вывести контроллер репликации с указанным именем в текстовом формате вывода. Совет: вы можете использовать сокращенный псевдоним 'rc' вместо 'replicationcontroller'.
kubectl get replicationcontroller <rc-name>

# Вывести все контроллеры репликации и сервисы вместе в текстовом формате вывода.
kubectl get rc,services

# Вывести все наборы демонов в текстовом формате вывода.
kubectl get ds

# Вывести все поды, запущенные на узле server01
kubectl get pods --field-selector=spec.nodeName=server01

kubectl describe - Показать подробное состояние одного или нескольких ресурсов, по умолчанию также включаются неинициализированные ресурсы.

# Показать информацию об узле с именем <node-name>.
kubectl describe nodes <node-name>

# Показать подробности пода <pod-name>.
kubectl describe pods/<pod-name>

# Показать подробности всех подов, управляемые контроллером репликации <rc-name>.
# Обратите внимание: любые поды, созданные контроллером репликации, имеют префикс с именем контроллера репликации.
kubectl describe pods <rc-name>

# Показать подробности по всем подам
kubectl describe pods

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

# Удалить под по типу и имени, указанных в файле pod.yaml.
kubectl delete -f pod.yaml

# Удалить все поды и сервисы с именем метки <label-name>.
kubectl delete pods,services -l name=<label-name>

# Удалить все поды, включая неинициализированные.
kubectl delete pods --all

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

# Получить вывод от запущенной команды 'date' в поде <pod-name>. По умолчанию отображается вывод из первого контейнера.
kubectl exec <pod-name> date

# Получить вывод из запущенной команды 'date' в контейнере <container-name> пода <pod-name>.
kubectl exec <pod-name> -c <container-name> date

# Получить интерактивный терминал (TTY) и запустить /bin/bash в поде <pod-name>. По умолчанию отображается вывод из первого контейнера.
kubectl exec -ti <pod-name> /bin/bash

kubectl logs - Вывести логи контейнера в поде.

# Возвращает текущие логи в поде <pod-name>.
kubectl logs <pod-name>

# Вывод логов в поде <pod-name> в режиме реального времени. Это похоже на команду 'tail -f' Linux.
kubectl logs -f <pod-name>

Примеры: создание и использование плагинов

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

# Плагин может быть на на любом языке, а сам исполняемый файл должен начинается с префикса "kubectl-".
cat ./kubectl-hello
#!/bin/bash

# Этот плагин выводит строку "hello world"
echo "hello world"

# Сделать плагин исполняемым
sudo chmod +x ./kubectl-hello

# Переместить его в директорию из PATH
sudo mv ./kubectl-hello /usr/local/bin

# Плагин дял kubectl создан и "установлен".
# Воспользоваться плагином можно через kubectl, вызвав его подобно обычной команды.
kubectl hello
hello world
# "Отмена установки" плагина происходит через удаление его файла из директории в PATH.
sudo rm /usr/local/bin/kubectl-hello

Посмотреть все доступные плагины kubectl можно с помощью подкоманды kubectl plugin list:

kubectl plugin list
The following kubectl-compatible plugins are available:

/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
/usr/local/bin/kubectl-bar
# Эта команда также может сообщить, что плагин является неисполняемым,
# либо что плагин переопределен другими плагинами

sudo chmod -x /usr/local/bin/kubectl-foo
kubectl plugin list
The following kubectl-compatible plugins are available:

/usr/local/bin/kubectl-hello
/usr/local/bin/kubectl-foo
  - warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
/usr/local/bin/kubectl-bar

error: one plugin warning was found

Плагины можно рассматривать как способ создания более сложной функциональности поверх существующих команд kubectl:

cat ./kubectl-whoami
#!/bin/bash

# Этот плагин использует команду `kubectl config` для вывода
# информации о текущем пользователе из текущего выбранного контекста
kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ .context.user }}{{ end }}{{ end }}'

Выполнение этого плагина генерирует вывод, содержащий пользователя для текущего выбранного контекста в файле KUBECONFIG:

# Сделать файл исполняемым
sudo chmod +x ./kubectl-whoami

# Перенести файл в директорию из PATH
sudo mv ./kubectl-whoami /usr/local/bin

kubectl whoami
Current user: plugins-user

Чтобы узнать больше о плагинах, изучите пример CLI-плагина.

Что дальше

Начните использовать команды kubectl.

2.2 - Поддержка JSONPath

Kubectl поддерживает шаблон JSONPath.

Шаблон JSONPath состоит из выражений JSONPath, заключенных в фигурные скобки {}. Kubectl использует JSONPath-выражения для фильтрации по определенным полям в JSON-объекте и форматирования вывода. В дополнение к оригинальному синтаксису шаблона JSONPath, допустимы следующие функции и синтаксис:

  1. Внутри выражений JSONPath текстовые значения заключайте в двойные кавычки.
  2. Используйте операторы range, end, конечные операторы для перебора списков.
  3. Используйте отрицательные индексы срезов для перехода на предыдущий элемент в списке. Отрицательные индексы не "зацикливаются" в списке и работают пока истинно выражение -index + listLength >= 0.

Все примеры ниже будут ориентироваться на следующий JSON-объект:

{
  "kind": "List",
  "items":[
    {
      "kind":"None",
      "metadata":{"name":"127.0.0.1"},
      "status":{
        "capacity":{"cpu":"4"},
        "addresses":[{"type": "LegacyHostIP", "address":"127.0.0.1"}]
      }
    },
    {
      "kind":"None",
      "metadata":{"name":"127.0.0.2"},
      "status":{
        "capacity":{"cpu":"8"},
        "addresses":[
          {"type": "LegacyHostIP", "address":"127.0.0.2"},
          {"type": "another", "address":"127.0.0.3"}
        ]
      }
    }
  ],
  "users":[
    {
      "name": "myself",
      "user": {}
    },
    {
      "name": "e2e",
      "user": {"username": "admin", "password": "secret"}
    }
  ]
}
Функция Описание Пример Результат
text обычный текст kind is {.kind} kind is List
@ текущий объект {@} то же, что и ввод
. или [] оператор выбора по ключу {.kind}, {['kind']} или {['name\.type']} List
.. рекурсивный спуск {..name} 127.0.0.1 127.0.0.2 myself e2e
* шаблон подстановки. Получение всех объектов {.items[*].metadata.name} [127.0.0.1 127.0.0.2]
[start:end:step] оператор индексирования {.users[0].name} myself
[,] оператор объединения {.items[*]['metadata.name', 'status.capacity']} 127.0.0.1 127.0.0.2 map[cpu:4] map[cpu:8]
?() фильтрация {.users[?(@.name=="e2e")].user.password} secret
range, end перебор списка {range .items[*]}[{.metadata.name}, {.status.capacity}] {end} [127.0.0.1, map[cpu:4]] [127.0.0.2, map[cpu:8]]
'' интерпретируемая в кавычках строка {range .items[*]}{.metadata.name}{'\t'}{end} 127.0.0.1 127.0.0.2

Примеры использования kubectl и JSONPath-выражений:

kubectl get pods -o json
kubectl get pods -o=jsonpath='{@}'
kubectl get pods -o=jsonpath='{.items[0]}'
kubectl get pods -o=jsonpath='{.items[0].metadata.name}'
kubectl get pods -o=jsonpath="{.items[*]['metadata.name', 'status.capacity']}"
kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.startTime}{"\n"}{end}'

2.3 - kubectl

Краткое описание

kubectl управляет кластерами Kubernetes.

Более подробная информация по ссылке: https://kubernetes.io/ru/docs/reference/kubectl/overview/

kubectl [flags]

Опции

--add-dir-header
Если true, добавляет директорию файла в заголовок
--alsologtostderr
Логировать в стандартный поток ошибок, а также в файлы
--application-metrics-count-limit int     По умолчанию: 100
Максимальное количество сохраняемых метрик приложения (на каждый контейнер)
--as string
Имя пользователя, от которого будет выполняться операция
--as-group stringArray
Группа, от которой будет выполняться операция, этот флаг можно использовать неоднократно, чтобы указать несколько групп.
--azure-container-registry-config string
Путь к файлу, который содержит информацию с конфигурацией реестра контейнера Azure.
--boot-id-file string     По умолчанию: "/proc/sys/kernel/random/boot_id"
Разделенный запятыми список файлов для проверки boot-id. Используйте первый существующий.
--cache-dir string     По умолчанию: "$HOME/.kube/http-cache"
Директория HTTP-кеша по умолчанию
--certificate-authority string
Путь к файлу сертификата для центра сертификации
--client-certificate string
Путь к файлу клиентского сертификата для TLS
--client-key string
Путь к файлу клиентского ключа для TLS
--cloud-provider-gce-l7lb-src-cidrs cidrs     По умолчанию: 130.211.0.0/22,35.191.0.0/16
Открыть CIDR в брандмауэре GCE для прокси трафика L7 LB и проверки работоспособности
--cloud-provider-gce-lb-src-cidrs cidrs     По умолчанию: 130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16
Открыть CIDR в брандмауэре GCE для прокси трафика L4 LB и проверки работоспособности
--cluster string
Имя используемого кластера kubeconfig
--container-hints string     По умолчанию: "/etc/cadvisor/container_hints.json"
Путь к файлу подсказок контейнера
--containerd string     По умолчанию: "/run/containerd/containerd.sock"
Конечная точка containerd
--containerd-namespace string     По умолчанию: "k8s.io"
Пространство имени containerd
--context string
Имя контекста kubeconfig
--default-not-ready-toleration-seconds int     По умолчанию: 300
Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого не установлено такое допущение.
--default-unreachable-toleration-seconds int     По умолчанию: 300
Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого не установлено такое допущение.
--disable-root-cgroup-stats
Отключить сбор статистики корневой группы (Cgroup)
--docker string     По умолчанию: "unix:///var/run/docker.sock"
docker endpoint
--docker-env-metadata-whitelist string
Список ключей переменных окружения, разделенный запятыми, которые необходимо собрать для Docker-контейнеров
--docker-only
В дополнение к корневой статистике уведомлять только о Docker-контейнерах
--docker-root string     По умолчанию: "/var/lib/docker"
УСТАРЕЛО: корень docker считывается из информации docker (запасной вариант, по умолчанию: /var/lib/docker)
--docker-tls
Использовать TLS для подключения к Docker
--docker-tls-ca string     По умолчанию: "ca.pem"
Путь к доверенному CA
--docker-tls-cert string     По умолчанию: "cert.pem"
Путь к клиентскому сертификату
--docker-tls-key string     По умолчанию: "key.pem"
Путь к приватному ключу
--enable-load-reader
Включить считыватель нагрузки процессора
--event-storage-age-limit string     По умолчанию: "default=0"
Максимальный период времени для хранения события (по каждому типу). Значение флага — список из ключей и значений, разделенные запятыми, где ключи — это типы событий (например: создание, oom) либо "default", а значение — длительность. По умолчанию флаг применяется ко всем неуказанным типам событий
--event-storage-event-limit string     По умолчанию: "default=0"
Максимальное количество событий для хранения (по каждому типу). Значение флага — список из ключей и значений, разделенные запятыми, где ключи — это типы событий (например: создание, oom) либо "default", а значение — целое число. По умолчанию флаг применяется ко всем неуказанным типам событий
--global-housekeeping-interval duration     По умолчанию: 1m0s
Интервал между глобальными служебными операциями (housekeepings)
-h, --help
Получить справочную информацию по команде kubectl
--housekeeping-interval duration     По умолчанию: 10s
Интервал между служебными операциями (housekeepings) контейнера
--insecure-skip-tls-verify
Если true, значит сертификат сервера не будет проверяться на достоверность. Это сделает подключения через HTTPS небезопасными.
--kubeconfig string
Путь к файлу kubeconfig для использования в CLI-запросах.
--log-backtrace-at traceLocation     По умолчанию: :0
При логировании указанной строки (file:N), сгенерировать трассировку стека
--log-cadvisor-usage
Записывать ли в журнал использование контейнера cAdvisor
--log-dir string
Если указан, хранить лог-файлы в этой директории.
--log-file string
Если указан, использовать этот лог-файл
--log-file-max-size uint     По умолчанию: 1800
Установить максимальный размер файла лог-файла (в Мб). Если значение равно 0, максимальный размер файла не ограничен.
--log-flush-frequency duration     По умолчанию: 5s
Максимальное количество секунд между очисткой лог-файлов
--logtostderr     По умолчанию: true
Вывод логов в стандартный поток ошибок вместо сохранения их в файлы
--machine-id-file string     По умолчанию: "/etc/machine-id,/var/lib/dbus/machine-id"
Список файлов, разделенных запятыми, для проверки machine-id. Используйте первый существующий.
--match-server-version
Убедиться, что версия сервера соответствует версии клиента
-n, --namespace string
Указать область пространства имен для данного запроса CLI
--password string
Пароль для базовой аутентификации на API-сервере
--profile string     По умолчанию: "none"
Имя профиля. Может быть одним из перечисленных значений: none|cpu|heap|goroutine|threadcreate|block|mutex
--profile-output string     По умолчанию: "profile.pprof"
Имя файла для записи профиля.
--request-timeout string     По умолчанию: "0"
Время ожидания перед тем, как перестать ожидать ответ от сервера. Значения должны содержать соответствующую единицу времени (например, 1s, 2m, 3h). Нулевое значение означает, что у запросов нет тайм-аута.
-s, --server string
Адрес и порт API-сервера Kubernetes
--skip-headers
Если true, не отображать заголовки в сообщениях лога.
--skip-log-headers
Если true, не отображать заголовки при открытии лог-файлов.
--stderrthreshold severity     По умолчанию: 2
Логи указанного уровня серьёзности или выше выводить в поток stderr
--storage-driver-buffer-duration duration     По умолчанию: 1m0s
Буферизировать запись в драйвере хранилища в течение указанного времени, и сохранять в файловом хранилище в виде одной транзакции
--storage-driver-db string     По умолчанию: "cadvisor"
Имя базы данных
--storage-driver-host string     По умолчанию: "localhost:8086"
Хост и порт базы данных, записанный в формате host:port
--storage-driver-password string     По умолчанию: "root"
Пароль к базе данных
--storage-driver-secure
Использовать безопасное соединение с базой данных
--storage-driver-table string     По умолчанию: "stats"
Имя таблицы
--storage-driver-user string     По умолчанию: "root"
Имя пользователя базы данных
--token string
Аутентификационный (bearer) токен для аутентификации на API-сервере
--update-machine-info-interval duration     По умолчанию: 5m0s
Интервал между обновлениями информации о машине.
--user string
Имя пользователя для kubeconfig
--username string
Имя пользователя для базовой аутентификации на API-сервере
-v, --v Level
Номер уровня серьёзности логирования
--version version[=true]
Вывод версии команды
--vmodule moduleSpec
Список, разделённый запятыми, в виде настроек pattern=N для фильтрации лог-файлов

См. также

  • kubectl annotate - Обновить аннотации ресурса.
  • kubectl api-resources - Вывести доступные API-ресурсы на сервере.
  • kubectl api-versions - Вывести доступные API-версии на сервере в виде "group/version".
  • kubectl apply - Внести изменения в конфигурацию ресурса из файла или потока stdin.
  • kubectl attach - Присоединиться к запущенному контейнеру.
  • kubectl auth - Проверить разрешение на выполнение определённых действий.
  • kubectl autoscale - Автоматически масштабировать Deployment, ReplicaSet или ReplicationController.
  • kubectl certificate - Изменить сертификаты ресурсов.
  • kubectl cluster-info - Показать информацию по кластеру.
  • kubectl completion - Вывод кода автодополнения указанной командной оболочки (bash или zsh).
  • kubectl config - Изменить файлы kubeconfig.
  • kubectl convert - Конвертировать конфигурационные файлы в различные API-версии.
  • kubectl cordon - Отметить узел как неназначаемый.
  • kubectl cp - Копировать файлы и директории в/из контейнеров.
  • kubectl create - Создать ресурс из файла или потока stdin.
  • kubectl delete - Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов.
  • kubectl describe - Показать подробную информацию о конкретном ресурсе или группе ресурсов.
  • kubectl diff - Сравнить действующую версию с новой (применяемой).
  • kubectl drain - Вытеснить узел для подготовки к эксплуатации.
  • kubectl edit - Отредактировать ресурс на сервере.
  • kubectl exec - Выполнить команду в контейнере.
  • kubectl explain - Получить документацию ресурсов.
  • kubectl expose - Создать новый сервис Kubernetes из контроллера репликации, сервиса, развёртывания или пода.
  • kubectl get - Вывести один или несколько ресурсов.
  • kubectl kustomize - Собрать ресурсы kustomization из директории или URL-адреса.
  • kubectl label - Обновить метки ресурса.
  • kubectl logs - Вывести логи контейнера в поде.
  • kubectl options - Вывести список флагов, применяемых ко всем командам.
  • kubectl patch - Обновить один или несколько полей ресурса, используя стратегию слияния патча.
  • kubectl plugin - Команда для работы с плагинами.
  • kubectl port-forward - Переадресовать один или несколько локальных портов в под.
  • kubectl proxy - Запустить прокси на API-сервер Kubernetes.
  • kubectl replace - Заменить ресурс из определения в файле или потоке stdin.
  • kubectl rollout - Управление плавающим обновлением ресурса.
  • kubectl run - Запустить указанный образ в кластере.
  • kubectl scale - Задать новый размер для Deployment, ReplicaSet или Replication Controller.
  • kubectl set - Конфигурировать ресурсы в объектах.
  • kubectl taint - Обновить ограничения для одного или нескольких узлов.
  • kubectl top - Показать информацию по использованию системных ресурсов (процессор, память, диск).
  • kubectl uncordon - Отметить узел как назначаемый.
  • kubectl version - Вывести информацию о версии клиента и сервера.
  • kubectl wait - Экспериментально: ожидать выполнения определенного условия в одном или нескольких ресурсах.

2.4 - kubectl для пользователей Docker

Вы можете использовать инструмент командной строки kubectl в Kubernetes для работы с API-сервером. Если вы знакомы с инструментом командной строки Docker, то использование kubectl не составит проблем. Однако команды docker и kubectl отличаются. В следующих разделах показана подкоманда docker и приведена эквивалентная команда в kubectl.

docker run

Для развёртывания nginx и открытия доступа к объекту Deployment используйте команду kubectl run.

docker:

docker run -d --restart=always -e DOMAIN=cluster --name nginx-app -p 80:80 nginx
55c103fa129692154a7652490236fee9be47d70a8dd562281ae7d2f9a339a6db
docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   9 seconds ago       Up 9 seconds        0.0.0.0:80->80/tcp   nginx-app

kubectl:

# запустить под, в котором работает nginx
kubectl create deployment --image=nginx nginx-app
deployment "nginx-app" created
# add env to nginx-app
kubectl set env deployment/nginx-app  DOMAIN=cluster
deployment.apps/nginx-app env updated
# открыть порт, чтобы иметь доступ к сервису
kubectl expose deployment nginx-app --port=80 --name=nginx-http
service "nginx-http" exposed

С помощью kubectl можно создать объект Deployment, чтобы убедиться, что N подов, запущены под nginx, где N — это количество реплик, указанных в спецификации (по умолчанию — 1). Вы также можете создать сервис с селектором, соответствующим меткам подов. Для получения дополнительной информации перейдите на страницу Use a Service to Access an Application in a Cluster.

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

kubectl run [-i] [--tty] --attach <name> --image=<image>

В отличие от docker run ..., если вы укажете --attach, то присоедините stdin, stdout and stderr. Нельзя проконтролировать, какие потоки прикрепляются (docker -a ...). Чтобы отсоединиться от контейнера, воспользуетесь комбинацией клавиш Ctrl+P, а затем Ctrl+Q.

Так как команда kubectl run запускает развёртывание для контейнера, то оно начнет перезапускаться, если завершить прикрепленный процесс по нажатию Ctrl+C, в отличие от команды docker run -it. Для удаления объекта Deployment вместе с подами, необходимо выполнить команду kubectl delete deployment <name>.

docker ps

Посмотреть, что сейчас запущено можно с помощью команды kubectl get.

docker:

docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                     PORTS                NAMES
14636241935f        ubuntu:16.04        "echo test"              5 seconds ago        Exited (0) 5 seconds ago                        cocky_fermi
55c103fa1296        nginx               "nginx -g 'daemon of…"   About a minute ago   Up About a minute          0.0.0.0:80->80/tcp   nginx-app

kubectl:

kubectl get po
NAME                        READY     STATUS      RESTARTS   AGE
nginx-app-8df569cb7-4gd89   1/1       Running     0          3m
ubuntu                      0/1       Completed   0          20s

docker attach

Чтобы присоединить процесс, который уже запущен в контейнере, используйте команду kubectl attach.

docker:

docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   5 minutes ago       Up 5 minutes        0.0.0.0:80->80/tcp   nginx-app
docker attach 55c103fa1296
...

kubectl:

kubectl get pods
NAME              READY     STATUS    RESTARTS   AGE
nginx-app-5jyvm   1/1       Running   0          10m
kubectl attach -it nginx-app-5jyvm
...

Для отсоединения его от контейнера используйте сочетания клавиш Ctrl+P и Ctrl+Q.

docker exec

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

docker:

docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
55c103fa1296        nginx               "nginx -g 'daemon of…"   6 minutes ago       Up 6 minutes        0.0.0.0:80->80/tcp   nginx-app
docker exec 55c103fa1296 cat /etc/hostname
55c103fa1296

kubectl:

kubectl get po
NAME              READY     STATUS    RESTARTS   AGE
nginx-app-5jyvm   1/1       Running   0          10m
kubectl exec nginx-app-5jyvm -- cat /etc/hostname
nginx-app-5jyvm

Примеры с командной оболочкой

docker:

docker exec -ti 55c103fa1296 /bin/sh
# exit

kubectl:

kubectl exec -ti nginx-app-5jyvm -- /bin/sh
# exit

Для получения дополнительной информации обратитесь к странице Get a Shell to a Running Container.

docker logs

Для отслеживания логов в потоки stdout/stderr запущенного процесса используйте команду kubectl logs.

docker:

docker logs -f a9e
192.168.9.1 - - [14/Jul/2015:01:04:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"
192.168.9.1 - - [14/Jul/2015:01:04:03 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.35.0" "-"

kubectl:

kubectl logs -f nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"

Есть небольшая разница между подами и контейнерами: по умолчанию поды не прекращают выполнение, если их процессы завершаются. Вместо этого поды перезапускают процесс. Это похоже на опцию --restart=always в Docker, только с одной большой разницей. В Docker вывод каждого вызова процесса объединяется, в отличие от Kubernetes, где каждый вызов является отдельным. Для просмотра вывода предыдущего запуска в Kubernetes, используйте команду ниже:

kubectl logs --previous nginx-app-zibvs
10.240.63.110 - - [14/Jul/2015:01:09:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"
10.240.63.110 - - [14/Jul/2015:01:09:02 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.26.0" "-"

Для получения дополнительной информации обратитесь к странице Logging Architecture.

docker stop и docker rm

Для завершения и удаления запущенного процесса используйте команду kubectl delete.

docker:

docker ps
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                         NAMES
a9ec34d98787        nginx               "nginx -g 'daemon of"  22 hours ago        Up 22 hours         0.0.0.0:80->80/tcp, 443/tcp   nginx-app
docker stop a9ec34d98787
a9ec34d98787
docker rm a9ec34d98787
a9ec34d98787

kubectl:

kubectl get deployment nginx-app
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
nginx-app    1/1     1            1           2m
kubectl get po -l app=nginx-app
NAME                         READY     STATUS    RESTARTS   AGE
nginx-app-2883164633-aklf7   1/1       Running   0          2m
kubectl delete deployment nginx-app
deployment "nginx-app" deleted
kubectl get po -l app=nginx-app
# Return nothing

docker login

В kubectl нет прямого аналога команды docker login. Если вы планируете использовать Kubernetes с приватным реестром, изучите страницу Using a Private Registry.

docker version

Для получения версии клиента и сервера используйте команду kubectl version.

docker:

docker version
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64
Server version: 1.7.0
Server API version: 1.19
Go version (server): go1.4.2
Git commit (server): 0baf609
OS/Arch (server): linux/amd64

kubectl:

kubectl version
Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.9+a3d1dfa6f4335", GitCommit:"9b77fed11a9843ce3780f70dd251e92901c43072", GitTreeState:"dirty", BuildDate:"2017-08-29T20:32:58Z", OpenPaasKubernetesVersion:"v1.03.02", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}

docker info

Для получения разной информации про окружение и конфигурации перейдите в раздел kubectl cluster-info.

docker:

docker info
Containers: 40
Images: 168
Storage Driver: aufs
 Root Dir: /usr/local/google/docker/aufs
 Backing Filesystem: extfs
 Dirs: 248
 Dirperm1 Supported: false
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.13.0-53-generic
Operating System: Ubuntu 14.04.2 LTS
CPUs: 12
Total Memory: 31.32 GiB
Name: k8s-is-fun.mtv.corp.google.com
ID: ADUV:GCYR:B3VJ:HMPO:LNPQ:KD5S:YKFQ:76VN:IANZ:7TFV:ZBF4:BYJO
WARNING: No swap limit support

kubectl:

kubectl cluster-info
Kubernetes master is running at https://203.0.113.141
KubeDNS is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kube-dns/proxy
kubernetes-dashboard is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/kubernetes-dashboard/proxy
Grafana is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
Heapster is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy
InfluxDB is running at https://203.0.113.141/api/v1/namespaces/kube-system/services/monitoring-influxdb/proxy

2.5 - Команды kubectl

Справочник команд kubectl

2.6 - Шпаргалка по kubectl

Смотрите также: обзор Kubectl и руководство по JsonPath.

Эта команда представляет собой обзор команды kubectl.

kubectl - Шпаргалка

Автодополнение ввода для Kubectl

BASH

source <(kubectl completion bash) # настройка автодополнения в текущую сессию bash, предварительно должен быть установлен пакет bash-completion .
echo "source <(kubectl completion bash)" >> ~/.bashrc # добавление автодополнения autocomplete постоянно в командную оболочку bash.

Вы также можете использовать короткий псевдоним для kubectl, который можно интегрировать с автодополнениями:

alias k=kubectl
complete -F __start_kubectl k

ZSH

source <(kubectl completion zsh)  # настройка автодополнения в текущую сессию zsh
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # add autocomplete permanently to your zsh shell

Контекст и конфигурация kubectl

Установка того, с каким Kubernetes-кластером взаимодействует kubectl и изменяет конфигурационную информацию. Подробную информацию о конфигурационном файле смотрите на странице Authenticating Across Clusters with kubeconfig.

kubectl config view # показать объединённые настройки kubeconfig

# использовать несколько файлов kubeconfig одновременно и посмотреть объединённую конфигурацию из этих файлов
KUBECONFIG=~/.kube/config:~/.kube/kubconfig2

kubectl config view

# получить пароль для пользователя e2e
kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}'

kubectl config view -o jsonpath='{.users[].name}'    # показать первого пользователя
kubectl config view -o jsonpath='{.users[*].name}'   # получить список пользователей
kubectl config get-contexts                          # показать список контекстов
kubectl config current-context                       # показать текущий контекст (current-context)
kubectl config use-context my-cluster-name           # установить my-cluster-name как контекст по умолчанию

# добавить новую конфигурацию для кластера в kubeconf с базовой аутентификацией
kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword

# сохранить пространство имен для всех последующих команд kubectl в этом контексте.
kubectl config set-context --current --namespace=ggckad-s2

# установить контекст, используя имя пользователя и пространство имен.
kubectl config set-context gce --user=cluster-admin --namespace=foo \
  && kubectl config use-context gce

kubectl config unset users.foo                       # удалить пользователя foo

Apply

apply управляет приложениями с помощью файлов, которые определяют ресурсы Kubernetes. Выполните команду kubectl apply для создания и обновления ресурсов. Это рекомендуемый способ управления приложениями Kubernetes в промышленном окружении. Смотрите Kubectl Book.

Создание объектов

Манифесты Kubernetes могут быть определены в YAML или JSON. Можно использовать расширение файла .yaml, .yml и .json

kubectl apply -f ./my-manifest.yaml            # создать ресурсы
kubectl apply -f ./my1.yaml -f ./my2.yaml      # создать ресурсы из нескольких файлов
kubectl apply -f ./dir                         # создать ресурсы из всех файлов манифеста в директории
kubectl apply -f https://git.io/vPieo          # создать ресурсы из URL-адреса
kubectl create deployment nginx --image=nginx  # запустить один экземпляр nginx
kubectl explain pods                           # посмотреть документацию по манифестам подов

# Создать несколько YAML-объектов из stdin
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
---
apiVersion: v1
kind: Pod
metadata:
  name: busybox-sleep-less
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000"
EOF

# Создать секрет с несколькими ключами
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: $(echo -n "s33msi4" | base64 -w0)
  username: $(echo -n "jane" | base64 -w0)
EOF

Просмотр и поиск ресурсов

# Get-команды с основном выводом
kubectl get services                          # Вывести все сервисы в пространстве имён
kubectl get pods --all-namespaces             # Вывести все поды во всех пространств имён
kubectl get pods -o wide                      # Вывести все поды в текущем пространстве имён с подробностями
kubectl get deployment my-dep                 # Вывести определённое развёртывание
kubectl get pods                              # Вывести все поды в пространстве имён
kubectl get pod my-pod -o yaml                # Получить информацию по поду в формате YAML

# Посмотреть дополнительные сведения команды с многословным выводом
kubectl describe nodes my-node
kubectl describe pods my-pod

# Вывести сервисы, отсортированные по имени
kubectl get services --sort-by=.metadata.name

# Вывести поды, отсортированные по количеству перезагрузок
kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'

# Вывести постоянные тома (PersistentVolumes), отсортированные по емкости
kubectl get pv --sort-by=.spec.capacity.storage

# Получить метку версии всех подов с меткой app=cassandra
kubectl get pods --selector=app=cassandra -o \
  jsonpath='{.items[*].metadata.labels.version}'

# Получить все рабочие узлы (с помощью селектора исключаем узлы с меткой 'node-role.kubernetes.io/master')
kubectl get node --selector='!node-role.kubernetes.io/master'

# Получить все запущенные поды в пространстве имён
kubectl get pods --field-selector=status.phase=Running

# Получить внешние IP-адреса (ExternalIP) всех узлов
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'

# Вывести имена подов, принадлежащие к определённому RC
# Использование команды "jq" помогает упросить поиск в jsonpath, подробнее смотрите на сайте https://stedolan.github.io/jq/
sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})

# Показать метки всех подов (или любого другого объекта Kubernetes, которым можно прикреплять метки)
kubectl get pods --show-labels

# Получить готовые узлы
JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \
 && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"

# Вывод декодированных секретов без внешних инструментов
kubectl get secret my-secret -o go-template='{{range $k,$v := .data}}{{"### "}}{{$k}}{{"\n"}}{{$v|base64decode}}{{"\n\n"}}{{end}}'

# Вывести все секреты, используемые сейчас в поде.
kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq

# Вывести все идентификаторы (containerID) контейнеров инициализации (initContainers) во всех подах.
# Это полезно при очистке остановленных контейнеров, не удаляя при этом контейнеры инициализации.
kubectl get pods --all-namespaces -o jsonpath='{range .items[*].status.initContainerStatuses[*]}{.containerID}{"\n"}{end}' | cut -d/ -f3

# Вывести события, отсортированные по временной метке
kubectl get events --sort-by=.metadata.creationTimestamp

# Сравнить текущее состояние кластера с состоянием, в котором находился бы кластер в случае применения манифеста.
kubectl diff -f ./my-manifest.yaml

Обновление ресурсов

Начиная с версии 1.11 подкоманда rolling-update была удалена (см. CHANGELOG-1.11.md), поэтому вместо неё используйте rollout.

kubectl set image deployment/frontend www=image:v2               # Плавающее обновление контейнеров "www" развёртывания "frontend", обновление образа
kubectl rollout history deployment/frontend                      # Проверить историю развёртывания, включая ревизии.
kubectl rollout undo deployment/frontend                         # Откатиться к предыдущему развёртыванию
kubectl rollout undo deployment/frontend --to-revision=2         # Откатиться к определённой ревизии
kubectl rollout status -w deployment/frontend                    # Отслеживать статус плавающего развёртывания "frontend" до его завершения
kubectl rollout restart deployment/frontend                      # Перезапуск плавающего развёртывания "frontend"


# Объявлено устаревшим, начиная с версии 1.11
kubectl rolling-update frontend-v1 -f frontend-v2.json           # (устарело) Плавающее обновление подов frontend-v1
kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2  # (устарело) Изменить имя ресурса и обновить образ
kubectl rolling-update frontend --image=image:v2                 # (устарело) Обновить образ подов frontend
kubectl rolling-update frontend-v1 frontend-v2 --rollback        # (устарело) Отменить выполняющееся обновление

cat pod.json | kubectl replace -f -                              # Заменить под из определения в JSON-файле, переданного в поток stdin

# Принудительно заменить, удалить, а затем пересоздать ресурс. Это приведет к простою приложения
kubectl replace --force -f ./pod.json

# Создать сервис с реплицированным nginx на порту 80, который подключается к контейнерам на порту 8000.
kubectl expose rc nginx --port=80 --target-port=8000

# Обновить версию (метку) образа пода из одного контейнера single до v4
kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -

kubectl label pods my-pod new-label=awesome                      # Добавить метку
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq       # Добавить аннотацию
kubectl autoscale deployment foo --min=2 --max=10                # Автоматически масштабировать развёртывание "foo" в диапазоне от 2 до 10 подов

Обновление ресурсов

# Обновить часть узла
kubectl patch node k8s-node-1 -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"}]'

# Удалить развертывание livenessProbe через json-патч с позиционными массивами
kubectl patch deployment valid-deployment  --type json   -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'

# Добавить нового элемента в позиционный массив
kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]'

Редактирование ресурсов

Вы можете отредактировать API-ресурс в любом редакторе.

kubectl edit svc/docker-registry                      # Отредактировать сервис docker-registry
KUBE_EDITOR="nano" kubectl edit svc/docker-registry   # Использовать другой редактор

Масштабирование ресурсов

kubectl scale --replicas=3 rs/foo                                 # Масштабирование набора реплик (replicaset) 'foo' до 3
kubectl scale --replicas=3 -f foo.yaml                            # Масштабирование ресурса в "foo.yaml" до 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql  # Если количество реплик в развёртывании mysql равен 2, масштабировать его до 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz                   # Масштабирование нескольких контроллеров репликации до 5

Удаление ресурсов

kubectl delete -f ./pod.json                                              # Удалить под по типу и имени в pod.json
kubectl delete pod,service baz foo                                        # Удалить поды и сервисы с одноимёнными именам "baz" и "foo"
kubectl delete pods,services -l name=myLabel                              # Удалить поды и сервисы с именем метки myLabel
kubectl -n my-ns delete pod,svc --all                                     # Удалить все поды и сервисы в пространстве имен my-ns
# Удалить все поды, соответствующие pattern1 или pattern2 в awk
kubectl get pods  -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs  kubectl delete -n mynamespace pod

Работа с запущенными подами

kubectl logs my-pod                                 # вывести логи пода (в stdout)
kubectl logs -l name=myLabel                        # вывести логи пода с меткой myLabel (в stdout)
kubectl logs my-pod --previous                      # вывести логи пода (в stdout) по предыдущему экземпляру контейнера
kubectl logs my-pod -c my-container                 # вывести логи контейнера пода (в stdout, при работе с несколькими контейнерами)
kubectl logs -l name=myLabel -c my-container        # вывести логи пода с меткой myLabel (в stdout)
kubectl logs my-pod -c my-container --previous      # вывести логи контейнера пода (в stdout, при работе с несколькими контейнерами) по предыдущему экземпляру контейнера
kubectl logs -f my-pod                              # вывести логи пода в режиме реального времени (в stdout)
kubectl logs -f my-pod -c my-container              # вывести логи контейнера пода в режиме реального времени (в stdout, при работе с несколькими контейнерами)
kubectl logs -f -l name=myLabel --all-containers    # вывести логи всех подов с меткой myLabel (в stdout)
kubectl run -i --tty busybox --image=busybox -- sh  # запустить под как интерактивную оболочку
kubectl run nginx --image=nginx --restart=Never -n
mynamespace                                         # Запустить под nginx в заданном пространстве имён
kubectl run nginx --image=nginx --restart=Never     # Запустить под nginx и записать его спецификацию в файл pod.yaml
--dry-run -o yaml > pod.yaml

kubectl attach my-pod -i                            # Прикрепить к запущенному контейнеру
kubectl port-forward my-pod 5000:6000               # Переадресовать порт 5000 в локальной машине на порт 6000 в поде my-pod
kubectl exec my-pod -- ls /                         # Выполнить команду в существующем поде (в случае одного контейнера).
kubectl exec my-pod -c my-container -- ls /         # Выполнить команду в существующем поде (в случае нескольких контейнеров)
kubectl top pod POD_NAME --containers               # Показать метрики по заданному поду вместе с его контейнерами

Работа с узлами и кластером

kubectl cordon my-node                                                # Отметить узел my-node как неназначаемый
kubectl drain my-node                                                 # Вытеснить узел my-node, чтобы подготовиться к эксплуатации
kubectl uncordon my-node                                              # Отметить узел my-node как назначаемый
kubectl top node my-node                                              # Показать метрики по заданному узлу
kubectl cluster-info                                                  # Показать адреса главного узла и сервисов
kubectl cluster-info dump                                             # Вывести состояние текущего кластера в stdout
kubectl cluster-info dump --output-directory=/path/to/cluster-state   # Вывести состояние текущего кластера в /path/to/cluster-state

# Если ограничение с заданным ключом и проявлением уже существует, его значение будет заменено указанным
kubectl taint nodes foo dedicated=special-user:NoSchedule

Типы ресурсов

Вывести все поддерживаемые типы ресурсов, включая API-группу, флаг namespaced (организован ли ресурс в пространство имён или нет) и Kind:

kubectl api-resources

Другие варианты команды для анализа API-ресурсов:

kubectl api-resources --namespaced=true      # Все ресурсы с пространством имён
kubectl api-resources --namespaced=false     # Все ресурсы без пространства имён
kubectl api-resources -o name                # Все ресурсы с простым выводом  (только имя ресурса)
kubectl api-resources -o wide                # Все ресурсы с расширенным (с неограниченной длинной) выводом
kubectl api-resources --verbs=list,get       # Все ресурсы, которые поддерживают глаголы запроса "list" и "get"
kubectl api-resources --api-group=extensions # Все ресурсы в API-группе "extensions"

Форматирование вывода

Для вывода подробной информации в окно терминала в определенном формате, добавьте флаг -o (или --output) в команду kubectl, которая поддерживает форматирование.

Формат вывода Описание
-o=custom-columns=<spec> Вывод таблицы из списка пользовательских столбцов через запятую
-o=custom-columns-file=<filename> Вывод таблицы из списка пользовательских столбцов, определённых в файле <filename>
-o=json Вывод API-объекта в формате JSON
-o=jsonpath=<template> Вывод полей, определённых в выражении jsonpath
-o=jsonpath-file=<filename> Вывод полей, определённых в выражении jsonpath из файла <filename>
-o=name Вывод только имена ресурсов
-o=wide Вывод дополнительную информации в обычном текстовом формате, в случае подов отображается имя узла
-o=yaml Вывод API-объекта в формате YAML

Уровни детальности вывода и отладки в Kubectl

Уровни детальности вывода Kubectl регулируются с помощью флагов -v или --v, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированию Kubernetes и связанные с ними уровни описаны здесь.

Уровень детальности Описание
--v=0 Как правило, используется чтобы всегда видеть, что происходит
--v=1 Достаточный уровень логирования по умолчанию, если вам не нужна большая детальность.
--v=2 Полезная информация про стабильное состояние сервиса и важные сообщения логов, которые могут связаны со значительными изменениями в системе. Это рекомендуемый уровень логирования по умолчанию для большинства систем.
--v=3 Расширенная информация об изменениях.
--v=4 Уровень детальности для отладки.
--v=6 Показать запрашиваемые ресурсы.
--v=7 Показать заголовки HTTP-запросов.
--v=8 Показать содержимое HTTP-запросов.
--v=9 Показать содержимого HTTP-запроса в полном виде.

Что дальше

3 - Проблемы и безопасность Kubernetes

3.1 - Трекер задач (Issues) Kubernetes

Чтобы сообщить о проблеме в области безопасности, воспользуйтесь процедурой раскрытия информации о безопасности Kubernetes.

Механизм GitHub Issues позволяет работать с кодом Kubernetes и отслеживать активные задачи.

Связанные с безопасностью анонсы публикуются в рассылке kubernetes-security-announce@googlegroups.com.

3.2 - Общие сведения о безопасности Kubernetes и раскрытии информации

На этой странице приводятся общие сведения о безопасности Kubernetes и раскрытии информации, имеющей к ней отношение.

Анонсы в области безопасности

Информация о проблемах в области безопасности и ключевых изменениях API доступна в рассылке kubernetes-security-announce.

Сообщить об уязвимости

Мы искренне признательны исследователям в области безопасности и пользователям, которые передают информацию об уязвимостях в Open Source-сообщество Kubernetes. Все отчеты тщательно изучаются группой добровольцев сообщества.

Чтобы создать отчет, отправьте свою уязвимость в Bug Bounty-программу Kubernetes. Это позволит отследить и обработать уязвимость в стандартные сроки.

Также можно оправить стандартное письмо об ошибках Kubernetes с описанием проблемы с безопасностью и ее подробностями в закрытый список security@kubernetes.io.

Письмо можно зашифровать, используя GPG-ключи членов Комитета по безопасности. Шифрование с использованием GPG НЕ является обязательным.

Когда следует сообщать об уязвимости

  • Вы думаете, что обнаружили уязвимость в безопасности Kubernetes.
  • Вы не уверены, как именно уязвимость повлияет на Kubernetes.
  • Вы думаете, что обнаружили уязвимость в другом проекте, от которого зависит работа Kubernetes.
    • Если у проекта имеется собственный регламент регистрации и раскрытия информации об уязвимостях, пожалуйста, следуйте ему и пишите сразу в проект.

Когда НЕ следует сообщать об уязвимости

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

Реагирование на уязвимости в области безопасности

Каждый отчет об уязвимости подтверждается и анализируется членами Комитета по реагированию на угрозы безопасности в течение 3 рабочих дней. После этого запускается соответствующая процедура.

Любая информация об уязвимостях, переданная Комитету по реагированию на угрозы безопасности, остается внутри проекта Kubernetes и не передается в другие проекты, если только этого не требуется для устранения проблемы.

Автору отчета будет сообщено о результатах триажа и дальнейших шагах по подготовке исправления и планированию релиза.

Сроки раскрытия информации

Дата публичного раскрытия согласовывается Комитетом по реагированию на угрозы безопасности Kubernetes и автором отчета об уязвимости. Мы предпочитаем полностью раскрывать информацию об обнаруженной проблеме сразу после того, как станет понятно, какие шаги необходимо предпринять для устранения ее последствий. Разумно отложить раскрытие информации, если проблема или порядок дальнейших шагов не до конца понятны, решение плохо протестировано или необходима координация действий вендоров. Срок раскрытия информации варьируется от незамедлительного (особенно если она уже широко известна) до нескольких недель. Для "простых" уязвимостей с момента подачи отчета до даты раскрытия обычно проходит около 7 дней. Комитет по реагированию на угрозы безопасности сохраняет последнее слово при определении даты раскрытия информации.

3.3 - Официальный CVE-фид

СТАТУС ФИЧИ: Kubernetes v1.27 [beta]

Поддерживаемый сообществом список официальных CVE, анонсированных Комитетом по реагированию на проблемы безопасности Kubernetes. Подробности см. на странице Общие сведения о безопасности Kubernetes и раскрытии информации.

Проект Kubernetes публикует фиды с анонсами проблем в области безопасности в формате JSON и RSS, доступные для автоматического считывания. Доступ к ним можно получить, выполнив следующие команды:

Ссылка на JSON-формат

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/index.json

Ссылка на RSS-формат

curl -Lv https://k8s.io/docs/reference/issues-security/official-cve-feed/feed.xml
Официальный список Kubernetes CVE (последнее обновление: 13 авг. 2024 13:22:05 UTC)
CVE ID Описание проблемы CVE GitHub Issue URL
CVE-2024-5321 Incorrect permissions on Windows containers logs #126161
CVE-2024-3744 azure-file-csi-driver discloses service account tokens in logs #124759
CVE-2024-3177 Bypassing mountable secrets policy imposed by the ServiceAccount admission plugin #124336
CVE-2023-5528 Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes #121879
CVE-2023-3955 Insufficient input sanitization on Windows nodes leads to privilege escalation #119595
CVE-2023-3893 Insufficient input sanitization on kubernetes-csi-proxy leads to privilege escalation #119594
CVE-2023-3676 Insufficient input sanitization on Windows nodes leads to privilege escalation #119339
CVE-2023-2431 Bypass of seccomp profile enforcement #118690
CVE-2023-2728 Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin #118640
CVE-2023-2727 Bypassing policies imposed by the ImagePolicyWebhook and bypassing mountable secrets policy imposed by the ServiceAccount admission plugin #118640
CVE-2023-2878 secrets-store-csi-driver discloses service account tokens in logs #118419
CVE-2022-3294 Node address isn't always verified when proxying #113757
CVE-2022-3162 Unauthorized read of Custom Resources #113756
CVE-2022-3172 Aggregated API server can cause clients to be redirected (SSRF) #112513
CVE-2021-25749 `runAsNonRoot` logic bypass for Windows containers #112192
CVE-2021-25741 Symlink Exchange Can Allow Host Filesystem Access #104980
CVE-2021-25737 Holes in EndpointSlice Validation Enable Host Network Hijack #102106
CVE-2021-3121 Processes may panic upon receipt of malicious protobuf messages #101435
CVE-2021-25735 Validating Admission Webhook does not observe some previous fields #100096
CVE-2020-8554 Man in the middle using LoadBalancer or ExternalIPs #97076
CVE-2020-8566 Ceph RBD adminSecrets exposed in logs when loglevel >= 4 #95624
CVE-2020-8565 Incomplete fix for CVE-2019-11250 allows for token leak in logs when logLevel >= 9 #95623
CVE-2020-8564 Docker config secrets leaked when file is malformed and log level >= 4 #95622
CVE-2020-8563 Secret leaks in kube-controller-manager when using vSphere provider #95621
CVE-2020-8557 Node disk DOS by writing to container /etc/hosts #93032
CVE-2020-8559 Privilege escalation from compromised node to cluster #92914
CVE-2020-8558 Node setting allows for neighboring hosts to bypass localhost boundary #92315
CVE-2020-8555 Half-Blind SSRF in kube-controller-manager #91542
CVE-2020-10749 IPv4 only clusters susceptible to MitM attacks via IPv6 rogue router advertisements #91507
CVE-2019-11254 kube-apiserver Denial of Service vulnerability from malicious YAML payloads #89535
CVE-2020-8552 apiserver DoS (oom) #89378
CVE-2020-8551 Kubelet DoS via API #89377
CVE-2019-11251 kubectl cp symlink vulnerability #87773
CVE-2018-1002102 Unvalidated redirect #85867
CVE-2019-11255 CSI volume snapshot, cloning and resizing features can result in unauthorized volume data access or mutation #85233
CVE-2019-11253 Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack #83253
CVE-2019-11250 Bearer tokens are revealed in logs #81114
CVE-2019-11248 /debug/pprof exposed on kubelet's healthz port #81023
CVE-2019-11249 Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal #80984
CVE-2019-11247 API server allows access to custom resources via wrong scope #80983
CVE-2019-11245 container uid changes to root after first restart or if image is already pulled to the node #78308
CVE-2019-11243 rest.AnonymousClientConfig() does not remove the serviceaccount credentials from config created by rest.InClusterConfig() #76797
CVE-2019-11244 `kubectl:-http-cache=<world-accessible dir>` creates world-writeable cached schema files #76676
CVE-2019-1002100 json-patch requests can exhaust apiserver resources #74534
CVE-2018-1002105 proxy request handling in kube-apiserver can leave vulnerable TCP connections #71411
CVE-2018-1002101 smb mount security issue #65750
CVE-2018-1002100 Kubectl copy doesn't check for paths outside of it's destination directory. #61297
CVE-2017-1002102 atomic writer volume handling allows arbitrary file deletion in host filesystem #60814
CVE-2017-1002101 subpath volume mount handling allows arbitrary file access in host filesystem #60813
CVE-2017-1002100 Azure PV should be Private scope not Container scope #47611
CVE-2017-1000056 PodSecurityPolicy admission plugin authorizes incorrectly #43459

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

В качестве источника используется набор GitHub Issues, отфильтрованный по контролируемому и ограниченному лейблу official-cve-feed. Исходные данные хранятся в бакете Google Cloud, право на запись в который есть только у небольшого числа доверенных представителей сообщества.