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 - Планировщик, который управляет доступностью, производительностью и хранилищем.
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.
Выполните плавающее обновление, постепенно заменяя указанный контроллер репликации и его поды.
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 поддерживаются следующие форматы вывода:
Вывести поля, определённые в выражении 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 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
# Вывести все поды, запущенные на узле server01kubectl 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 get используется для получения одного или нескольких ресурсов одного и того же типа. Она поддерживает большой набор флагов, с помощью которых можно настроить формат вывода, например, с помощью флага -o или --output.
Вы можете указать флаг -w или --watch, чтобы отслеживать изменения в конкретном объекте. Команда kubectl describe в основном сфокусирована на описание многих взаимосвязанных аспектов указанного ресурса. При генерации вывода для пользователя она может обращаться к API-серверу. К примеру, команда kubectl describe node выдает не только информацию об узле, но и краткий обзор запущенных на нем подов, генерируемых событий и т.д.
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
# Переместить его в директорию из PATHsudo 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
# Перенести файл в директорию из PATHsudo mv ./kubectl-whoami /usr/local/bin
kubectl whoami
Current user: plugins-user
Шаблон JSONPath состоит из выражений JSONPath, заключенных в фигурные скобки {}.
Kubectl использует JSONPath-выражения для фильтрации по определенным полям в JSON-объекте и форматирования вывода.
В дополнение к оригинальному синтаксису шаблона JSONPath, допустимы следующие функции и синтаксис:
Внутри выражений JSONPath текстовые значения заключайте в двойные кавычки.
Используйте операторы range, end, конечные операторы для перебора списков.
Используйте отрицательные индексы срезов для перехода на предыдущий элемент в списке. Отрицательные индексы не "зацикливаются" в списке и работают пока истинно выражение -index + listLength >= 0.
Примечание:
Оператор $ необязателен, поскольку по умолчанию выражение всегда начинается с корневого объекта.
Объект результата выводиться через функцию String().
Все примеры ниже будут ориентироваться на следующий JSON-объект:
Примеры использования 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}'
Примечание:
В Windows нужно заключить в двойные кавычки JSONPath-шаблон, который содержит пробелы (не в одинарные, как в примерах выше для bash). Таким образом, любые литералы в таких шаблонах нужно оборачивать в одинарные кавычки или экранированные двойные кавычки. Например:
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{\"\t\"}{.status.startTime}{\"\n\"}{end}"
Логировать в стандартный поток ошибок, а также в файлы
--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 version - Вывести информацию о версии клиента и сервера.
kubectl wait - Экспериментально: ожидать выполнения определенного условия в одном или нескольких ресурсах.
2.4 - kubectl для пользователей Docker
Вы можете использовать инструмент командной строки kubectl в Kubernetes для работы с API-сервером. Если вы знакомы с инструментом командной строки Docker, то использование kubectl не составит проблем. Однако команды docker и kubectl отличаются. В следующих разделах показана подкоманда docker и приведена эквивалентная команда в kubectl.
docker run
Для развёртывания nginx и открытия доступа к объекту Deployment используйте команду kubectl run.
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:
# запустить под, в котором работает nginxkubectl create deployment --image=nginx nginx-app
deployment "nginx-app" created
# add env to nginx-appkubectl set env deployment/nginx-app DOMAIN=cluster
deployment.apps/nginx-app env updated
Примечание:
Команды kubectl выводят тип и имя созданного или измененного ресурса, который затем может быть использован в последующих командах. После создания объекта Deployment можно открыть новый сервис Service.
# открыть порт, чтобы иметь доступ к сервису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
Есть небольшая разница между подами и контейнерами: по умолчанию поды не прекращают выполнение, если их процессы завершаются. Вместо этого поды перезапускают процесс. Это похоже на опцию --restart=always в Docker, только с одной большой разницей. В Docker вывод каждого вызова процесса объединяется, в отличие от Kubernetes, где каждый вызов является отдельным. Для просмотра вывода предыдущего запуска в Kubernetes, используйте команду ниже:
Для получения дополнительной информации обратитесь к странице 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
Примечание:
При использовании kubectl удалить под напрямую не получится. Для этого сначала нужно удалить объект Deployment, которому принадлежит под. Если вы удалите под напрямую, то объект Deployment пересоздаст под.
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
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
Эта команда представляет собой обзор команды kubectl.
kubectl - Шпаргалка
Автодополнение ввода для Kubectl
BASH
source <(kubectl completion bash)# настройка автодополнения в текущую сессию bash, предварительно должен быть установлен пакет bash-completion .echo"source <(kubectl completion bash)" >> ~/.bashrc # добавление автодополнения autocomplete постоянно в командную оболочку bash.
Вы также можете использовать короткий псевдоним для kubectl, который можно интегрировать с автодополнениями:
aliask=kubectl
complete -F __start_kubectl k
ZSH
source <(kubectl completion zsh)# настройка автодополнения в текущую сессию zshecho"[[ $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
# получить пароль для пользователя e2ekubectl 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 # запустить один экземпляр nginxkubectl explain pods # посмотреть документацию по манифестам подов# Создать несколько YAML-объектов из stdincat <<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=cassandrakubectl 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.11kubectl rolling-update frontend-v1 -f frontend-v2.json # (устарело) Плавающее обновление подов frontend-v1kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # (устарело) Изменить имя ресурса и обновить образkubectl rolling-update frontend --image=image:v2 # (устарело) Обновить образ подов frontendkubectl 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 до v4kubectl 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-registryKUBE_EDITOR="nano" kubectl edit svc/docker-registry # Использовать другой редактор
Масштабирование ресурсов
kubectl scale --replicas=3 rs/foo # Масштабирование набора реплик (replicaset) 'foo' до 3kubectl scale --replicas=3 -f foo.yaml # Масштабирование ресурса в "foo.yaml" до 3kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Если количество реплик в развёртывании mysql равен 2, масштабировать его до 3kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Масштабирование нескольких контроллеров репликации до 5
Удаление ресурсов
kubectl delete -f ./pod.json # Удалить под по типу и имени в pod.jsonkubectl delete pod,service baz foo # Удалить поды и сервисы с одноимёнными именам "baz" и "foo"kubectl delete pods,services -l name=myLabel # Удалить поды и сервисы с именем метки myLabelkubectl -n my-ns delete pod,svc --all # Удалить все поды и сервисы в пространстве имен my-ns# Удалить все поды, соответствующие pattern1 или pattern2 в awkkubectl 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-podkubectl 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 # Вывести состояние текущего кластера в stdoutkubectl 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>
Вывод полей, определённых в выражении jsonpath из файла <filename>
-o=name
Вывод только имена ресурсов
-o=wide
Вывод дополнительную информации в обычном текстовом формате, в случае подов отображается имя узла
-o=yaml
Вывод API-объекта в формате YAML
Уровни детальности вывода и отладки в Kubectl
Уровни детальности вывода Kubectl регулируются с помощью флагов -v или --v, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированию Kubernetes и связанные с ними уровни описаны здесь.
Уровень детальности
Описание
--v=0
Как правило, используется чтобы всегда видеть, что происходит
--v=1
Достаточный уровень логирования по умолчанию, если вам не нужна большая детальность.
--v=2
Полезная информация про стабильное состояние сервиса и важные сообщения логов, которые могут связаны со значительными изменениями в системе. Это рекомендуемый уровень логирования по умолчанию для большинства систем.
3.2 - Общие сведения о безопасности Kubernetes и раскрытии информации
На этой странице приводятся общие сведения о безопасности Kubernetes и раскрытии информации, имеющей к ней отношение.
Анонсы в области безопасности
Информация о проблемах в области безопасности и ключевых изменениях API доступна в рассылке kubernetes-security-announce.
Сообщить об уязвимости
Мы искренне признательны исследователям в области безопасности и пользователям, которые передают информацию об уязвимостях в Open Source-сообщество Kubernetes. Все отчеты тщательно изучаются группой добровольцев сообщества.
Чтобы создать отчет, отправьте свою уязвимость в Bug Bounty-программу Kubernetes. Это позволит отследить и обработать уязвимость в стандартные сроки.
Письмо можно зашифровать, используя GPG-ключи членов Комитета по безопасности. Шифрование с использованием GPG НЕ является обязательным.
Когда следует сообщать об уязвимости
Вы думаете, что обнаружили уязвимость в безопасности Kubernetes.
Вы не уверены, как именно уязвимость повлияет на Kubernetes.
Вы думаете, что обнаружили уязвимость в другом проекте, от которого зависит работа Kubernetes.
Если у проекта имеется собственный регламент регистрации и раскрытия информации об уязвимостях, пожалуйста, следуйте ему и пишите сразу в проект.
Когда НЕ следует сообщать об уязвимости
Вам нужна помощь в настройке компонентов Kubernetes для обеспечения безопасности.
Вам нужна помощь в применении обновлений, связанных с безопасностью.
Проблема не связана с безопасностью.
Реагирование на уязвимости в области безопасности
Каждый отчет об уязвимости подтверждается и анализируется членами Комитета по реагированию на угрозы безопасности в течение 3 рабочих дней. После этого запускается соответствующая процедура.
Любая информация об уязвимостях, переданная Комитету по реагированию на угрозы безопасности, остается внутри проекта Kubernetes и не передается в другие проекты, если только этого не требуется для устранения проблемы.
Автору отчета будет сообщено о результатах триажа и дальнейших шагах по подготовке исправления и планированию релиза.
Сроки раскрытия информации
Дата публичного раскрытия согласовывается Комитетом по реагированию на угрозы безопасности Kubernetes и автором отчета об уязвимости. Мы предпочитаем полностью раскрывать информацию об обнаруженной проблеме сразу после того, как станет понятно, какие шаги необходимо предпринять для устранения ее последствий. Разумно отложить раскрытие информации, если проблема или порядок дальнейших шагов не до конца понятны, решение плохо протестировано или необходима координация действий вендоров. Срок раскрытия информации варьируется от незамедлительного (особенно если она уже широко известна) до нескольких недель. Для "простых" уязвимостей с момента подачи отчета до даты раскрытия обычно проходит около 7 дней. Комитет по реагированию на угрозы безопасности сохраняет последнее слово при определении даты раскрытия информации.
Проект Kubernetes публикует фиды с анонсами проблем в области безопасности в формате JSON и RSS, доступные для автоматического считывания. Доступ к ним можно получить, выполнив следующие команды:
Список автоматически обновляется с заметной, но небольшой задержкой (от нескольких минут до нескольких часов)
с момента анонса CVE до момента его появления в этом фиде.
В качестве источника используется набор GitHub Issues, отфильтрованный по контролируемому и
ограниченному лейблу official-cve-feed. Исходные данные хранятся в бакете Google Cloud,
право на запись в который есть только у небольшого числа доверенных представителей сообщества.