Kubernetes где хранит данные конфигурации pod

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

Эта команда представляет собой обзор команды 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='' # получить список пользователей 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  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  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=''  # Получить все рабочие узлы (с помощью селектора исключаем узлы с меткой '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=''  # Вывести имена подов, принадлежащие к определённому 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=':=;' \  && kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"  # Вывод декодированных секретов без внешних инструментов kubectl get secret my-secret -o go-template='>>>><<$v|base64decode>>><>'  # Вывести все секреты, используемые сейчас в поде. 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='' | 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.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='[]'  # Удалить развертывание livenessProbe через json-патч с позиционными массивами kubectl patch deployment valid-deployment --type json -p='[]'  # Добавить нового элемента в позиционный массив kubectl patch sa default --type='json' -p='[ >]' 

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

Вы можете отредактировать 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/' | 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=	Вывод таблицы из списка пользовательских столбцов через запятую
-o=custom-columns-file=	Вывод таблицы из списка пользовательских столбцов, определённых в файле
-o=json	Вывод API-объекта в формате JSON
-o=jsonpath=	Вывод полей, определённых в выражении jsonpath
-o=jsonpath-file=	Вывод полей, определённых в выражении jsonpath из файла
-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-запроса в полном виде.

Что дальше

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

Обратная связь

Эта страница была полезна?

Спасибо за обратную связь! Если у вас есть конкретный вопрос об использовании Kubernetes, спросите на Stack Overflow. Создайте issue в репозитории GitHub, если вы хотите сообщить о проблеме или предложить улучшение.

Хранение данных в кластере Kubernetes

Настроить хранение данных приложений, запущенных в кластере Kubernetes, можно несколькими способами. Одни из них уже устарели, другие появились совсем недавно. В этой статье рассмотрим концепцию трёх вариантов подключения СХД, в том числе самый последний — подключение через Container Storage Interface.

Способ 1. Указание PV в манифесте пода

Типичный манифест, описывающий под в кластере Kubernetes:

Цветом выделены части манифеста, где описано, какой том подключается и куда.

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

В разделе volumes перечисляют все тома, которые используются в поде. Указывают имя каждого тома, а также тип (в нашем случае: awsElasticBlockStore) и параметры подключения. Какие именно параметры перечисляются в манифесте, зависит от типа тома.

Один и тот же том может быть смонтирован одновременно в несколько контейнеров пода. Таким образом разные процессы приложения могут иметь доступ к одним и тем же данным.

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

При его использовании возникает несколько проблем:

1. все тома надо создавать вручную, Kubernetes не сможет создать ничего за нас;
2. параметры доступа к каждому из томов уникальные, и их надо указывать в манифестах всех подов, которые используют том;
3. чтобы поменять систему хранения (например, переехать из AWS в Google Cloud), надо менять настройки и тип подключённых томов во всех манифестах.

Всё это очень неудобно, поэтому в реальности подобным способом пользуются для подключения только некоторых специальных типов томов: configMap, secret, emptyDir, hostPath:

• configMap и secret — служебные тома, позволяют создать в контейнере том с файлами из манифестов Kubernetes.
• emptyDir — временный том, создаётся только на время жизни пода. Удобно использовать для тестирования или хранения временных данных. Когда pod удаляется, том типа emptyDir тоже удаляется и все данные пропадают.
• hostPath — позволяет смонтировать внутрь контейнера с приложением любой каталог локального диска сервера, на котором работает приложение, — в том числе /etc/kubernetes. Это небезопасная возможность, поэтому обычно политики безопасности запрещают использовать тома этого типа. Иначе приложение злоумышленника сможет замонтировать внутрь своего контейнера каталог /etc/kubernetes и украсть все сертификаты кластера. Как правило, тома hostPath разрешают использовать только системным приложениям, которые запускаются в namespace kube-system.

Способ 2. Подключение к подам SC/PVC/PV

Альтернативный способ подключения — концепция Storage class, PersistentVolumeClaim, PersistentVolume.

Storage class хранит параметры подключения к системе хранения данных.

PersistentVolumeClaim описывает требования к тому, который нужен приложению.
PersistentVolume хранит параметры доступа и статус тома.

Суть идеи: в манифесте пода указывают volume типа PersistentVolumeClaim и указывают название этой сущности в параметре claimName.

В манифесте PersistentVolumeClaim описывают требования к тому данных, который необходим приложению. В том числе:

• размер диска;
• способ доступа: ReadWriteOnce или ReadWriteMany;
• ссылка на Storage class — в какой системе хранения данных мы хотим создавать том.

В манифесте Storage class хранятся тип и параметры подключения к системе хранения данных. Они нужны кублету, чтобы смонтировать том к себе на узел.

В манифестах PersistentVolume указывается Storage class и параметры доступа к конкретному тому (ID тома, путь, и т. д.).

Создавая PVC, Kubernetes смотрит, том какого размера и из какого Storage class потребуется, и подбирает свободный PersistentVolume.

Если таких PV нет в наличии, Kubernetes может запустить специальную программу — Provisioner (её название указывают в Storage class). Эта программа подключается к СХД, создаёт том нужного размера, получает идентификатор и создает в кластере Kubernetes манифест PersistentVolume, который связывается с PersistentVolumeClaim.

Всё это множество абстракций позволяет убрать информацию о том, с какой СХД работает приложение, с уровня манифеста приложений на уровень администрирования.

Все параметры подключения к системе хранения данных находятся в Storage class, за который отвечают администраторы кластера. Всё, что надо сделать при переезде из AWS в Google Cloud, — это в манифестах приложения изменить название Storage class в PVC. Persistance Volume для хранения данных будут созданы в кластере автоматически, с помощью программы Provisioner.

Способ 3. Container Storage Interface

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

Чтобы решить проблему, разработчики из Cloud Foundry, Kubernetes, Mesos и Docker создали Container Storage Interface (CSI) — простой унифицированный интерфейс, который описывает взаимодействие системы управления контейнерами и специального драйвера (CSI Driver), работающего с конкретной СХД. Весь код по взаимодействию с СХД вынесли из ядра Kubernetes в отдельную систему.

Как правило, CSI Driver состоит из двух компонентов: Node Plugin и Controller plugin.

Node Plugin запускается на каждом узле и отвечает за монтирование томов и за операции на них. Controller plugin взаимодействует с СХД: создает или удаляет тома, назначает права доступа и т. д.

Пока в ядре Kubernetes остаются старые драйверы, но пользоваться ими уже не рекомендуют и всем советуют устанавливать CSI Driver конкретно для той системы, с которой предстоит работать.

Нововведение может напугать тех, кто уже привык настраивать хранение данных через Storage class, но на самом деле ничего страшного не случилось. Для программистов точно ничего не меняется — они как работали только с именем Storage class, так и продолжат. Для администраторов добавилась установка helm chart и поменялась структура настроек. Если раньше настройки вводились в Storage class напрямую, то теперь их сначала надо задать в helm chart, а потом уже в Storage class. Если разобраться, ничего страшного не произошло.

Давайте, на примере, рассмотрим какие преимущества можно получить, перейдя на подключение СХД Ceph с помощью CSI драйвера.

При работе с Ceph плагин CSI даёт больше возможностей для работы с СХД, чем встроенные драйверы.

1. Динамическое создание дисков. Обычно диски RBD используются только в режиме RWO, а CSI для Ceph позволяет использовать их в режиме RWX. Несколько pod’ов на разных узлах могут смонтировать один и тот же RDB-диск к себе на узлы и работать с ними параллельно. Справедливости ради, не всё так лучезарно — этот диск можно подключить только как блочное устройство, то есть придётся адаптировать приложение под работу с ним в режиме множественного доступа.
2. Создание снапшотов. В кластере Kubernetes можно создать манифест с требованием создать снапшот. Плагин CSI его увидит и сделает снапшот с диска. На его основании можно будет сделать либо бэкап, либо копию PersistentVolume.
3. Увеличение размера диска на СХД и PersistentVolume в кластере Kubernetes.
4. Квоты. Встроенные в Kubernetes драйверы CephFS не поддерживают квоты, а свежие CSI-плагины со свежим Ceph Nautilus умеют включать квоты на CephFS-разделы.
5. Метрики. CSI-плагин может отдавать в Prometheus множество метрик о том, какие тома подключены, какие идут взаимодействия и т. д.
6. Topology aware. Позволяет указать в манифестах, как географически распределён кластер, и избежать подключения к подам, запущенным в Лондоне системы хранения данных, расположенной в Амстердаме.

Как подключить Ceph к кластеру Kubernetes через CSI, смотрите в практической части лекции вечерней школы Слёрм. Так же можно подписаться на видео-курс Ceph, который будет запущен 15 октября.

Автор статьи: Сергей Бондарев, практикующий архитектор Southbridge, Certified Kubernetes Administrator, один из разработчиков kubespray.

Немного Post Scriptum не рекламы для, а пользы ради.

P.S. Сергей Бондарев ведёт два интенсива: обновлённый Kubernetes База 28-30 сентября и продвинутый Kubernetes Мега 14–16 октября.

Основы Kubernetes

В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.

Что такое Kubernetes?

Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.

Компания Google пользуется контейнерной технологией уже более десяти лет. Она начинала с запуска более 2 млрд контейнеров в течение одной недели. С помощью проекта Kubernetes компания делится своим опытом создания открытой платформы, предназначенной для масштабируемого запуска контейнеров.

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

Концепции Kubernetes

Nodes (node.md): Нода это машина в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod’ы будут запущены в любой момент времени.
Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединённый набор pod и политику доступа к ним.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label’ы это пары ключ/значение которые прикрепляются к объектам, например pod’ам. Label’ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.

Архитектура Kubernetes

Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.

Нода Kubernetes

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

Kubelet

Kubelet управляет pod’ами их контейнерами, образами, разделами, etc.

Kube-Proxy

Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.

Компоненты управления Kubernetes

Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.

etcd

Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.

Kubernetes API Server

Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).

Scheduler

Scheduler привязывает незапущенные pod’ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler’ов и пользовательских scheduler’ов.

Kubernetes Controller Manager Server

Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.

ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.

Пример настройки кластера

В качестве платформы для примера настройки была выбрана Ubuntu-server 14.10 как наиболее простая для примера и, в то же время, позволяющая продемонстрировать основные параметры настройки кластера.

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

• Conf
• Node1: 192.168.0.10 — master, minion
• Node2: 192.168.0.11 — minion
• Node3: 192.168.0.12 — minion

Подготовка нод

Требования для запуска:

1. На всех нодах установлен docker версии 1.2+ и bridge-utils
2. Все машины связаны друг с другом, необходимости в доступе к интернету нет (в этом случае необходимо использовать локальный docker registry)
3. На все ноды можно войти без ввода логина/пароля, с использованием ssh-ключей

Установка ПО на ноды

Установку Docker можно произвести по статье в официальных источниках:

node% sudo apt-get update $ sudo apt-get install wget node% wget -qO- https://get.docker.com/ | sh 

Дополнительная настройка Docker после установки не нужна, т.к. будет произведена скриптом установки Kubernetes.
Установка bridge-utils:

node% sudo apt-get install bridge-utils 

Добавление ssh-ключей

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

conf% ssh-keygen 

Копируем ключи на удалённые машины, предварительно убедившись в наличии на них необходимого пользователя, в нашем случае core.

conf% ssh-copy-id core@192.168.0.10 conf% ssh-copy-id core@192.168.0.11 conf% ssh-copy-id core@192.168.0.12 

Установка Kubernetes

Далее мы займёмся установкой непосредственно Kubernetes. Для этого в первую очередь скачаем и распакуем последний доступный релиз с GitHub:

conf% wget https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0.17.0/kubernetes.tar.gz conf% tar xzf ./kubernetes.tar.gz conf% cd ./kubernetes 

Настройка

Настройка Kubernetes через стандартные скрипты примеров полностью производится перед установкой производится через конфигурационные файлы. При установке мы будем использовать скрипты папке ./cluster/ubuntu/.

В первую очередь изменим скрипт ./cluster/ubuntu/build.sh который скачивает и подготавливает необходимые для установки бинарники Kubernetes, etcd и flannel:

conf% vim ./cluster/ubuntu/build.sh 

Для того, чтобы использовать последний, на момент написания статьи, релиз 0.17.0 необходимо заменить:

# k8s echo "Download kubernetes release . " K8S_VERSION="v0.15.0" 

# k8s echo "Download kubernetes release . " K8S_VERSION="v0.17.0" 

conf% cd ./cluster/ubuntu/ conf% ./build.sh #Данный скрипт важно запускать именно из той папки, где он лежит. 

Далее указываем параметры будущего кластера, для чего редактируем файл ./config-default.sh:

## Contains configuration values for the Ubuntu cluster # В данном пункте необходимо указать все ноды будущего кластера, MASTER-нода указывается первой # Ноды указываются в формате   разделитель - пробел # В качестве пользователя указывается тот пользователь для которого по нодам разложены ssh-ключи export nodes="core@192.168.0.10 core@192.168.0.10 core@192.168.0.10" # Определяем роли нод : a(master) или i(minion) или ai(master и minion), указывается в том же порядке, что и ноды в списке выше. export roles=("ai" "i" "i") # Определяем количество миньонов export NUM_MINIONS=$ # Определяем IP-подсеть из которой, в последствии будут выделяться адреса для сервисов. # Выделять необходимо серую подсеть, которая не будет пересекаться с имеющимися, т.к. эти адреса будут существовать только в пределах каждой ноды. #Перенаправление на IP-адреса сервисов производится локальным iptables каждой ноды. export PORTAL_NET=192.168.3.0/24 #Определяем подсеть из которой будут выделяться подсети для создания внутренней сети flannel. #flannel по умолчанию выделяет подсеть с маской 24 на каждую ноду, из этих подсетей будут выделяться адреса для Docker-контейнеров. #Подсеть не должна пересекаться с PORTAL_NET export FLANNEL_NET=172.16.0.0/16 # Admission Controllers определяет политику доступа к объектам кластера. ADMISSION_CONTROL=NamespaceLifecycle,NamespaceAutoProvision,LimitRanger,ResourceQuota # Дополнительные параметры запуска Docker. Могут быть полезны для дополнительных настроек # например установка --insecure-registry для локальных репозиториев. DOCKER_OPTS="" 

На этом настройка заканчивается и можно переходить к установке.

Установка

Первым делом необходимо сообщить системе про наш ssh-agent и используемый ssh-ключ для этого выполняем:

eval `ssh-agent -s` ssh-add /путь/до/ключа 

Далее переходим непосредственно к установке. Для этого используется скрипт ./kubernetes/cluster/kube-up.sh которому необходимо указать, что мы используем ubuntu.

conf% cd ../ conf% KUBERNETES_PROVIDER=ubuntu ./kube-up.sh 

В процессе установки скрипт потребует пароль sudo для каждой ноды. По окончанию установки проверит состояние кластера и выведет список нод и адреса Kubernetes api.

Пример вывода скрипта

Starting cluster using provider: ubuntu . calling verify-prereqs . calling kube-up Deploying master and minion on machine 192.168.0.10 [sudo] password to copy files and start node: etcd start/running, process 16384 Connection to 192.168.0.10 closed. Deploying minion on machine 192.168.0.11 [sudo] password to copy files and start minion: etcd start/running, process 12325 Connection to 192.168.0.11 closed. Deploying minion on machine 192.168.0.12 [sudo] password to copy files and start minion: etcd start/running, process 10217 Connection to 192.168.0.12 closed. Validating master Validating core@192.168.0.10 Validating core@192.168.0.11 Validating core@192.168.0.12 Kubernetes cluster is running. The master is running at: http://192.168.0.10 . calling validate-cluster Found 3 nodes. 1 NAME LABELS STATUS 2 192.168.0.10 Ready 3 192.168.0.11 Ready 4 192.168.0.12 Ready Validate output: NAME STATUS MESSAGE ERROR etcd-0 Healthy <"action":"get","node":<"dir":true,"nodes":[<"key":"/coreos.com","dir":true,"modifiedIndex":11,"createdIndex":11>,],"modifiedIndex":5,"createdIndex":5>> nil controller-manager Healthy ok nil scheduler Healthy ok nil Cluster validation succeeded Done, listing cluster services: Kubernetes master is running at http://192.168.0.10:8080 

Посмотрим, какие ноды и сервисы присутствуют в новом кластере:

conf% cp ../kubernetes/platforms/linux/amd64/kubectl /opt/bin/ conf% /opt/bin/kubectl get services,minions -s "http://192.168.0.10:8080" NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes 192.168.3.1 80/TCP NAME LABELS STATUS 192.168.0.10 Ready 192.168.0.11 Ready 192.168.0.12 Ready 

Видим список из установленных нод в состоянии Ready и два предустановленных сервиса kubernetes и kubernetes-ro — это прокси для непосредственного доступа к Kubernetes API. Как и к любому сервису Kubernetes к kubernetes и kubernetes-ro можно обратиться непосредственно по IP адресу с любой из нод.

Запуск тестового сервиса

Для запуска сервиса необходимо подготовить docker контейнер, на основе которого будет создан сервис. Дабы не усложнять, в примере будет использован общедоступный контейнер nginx. Обязательными составляющими сервиса являются Replication Controller, обеспечивающий запущенность необходимого набора контейнеров (точнее pod) и service, который определяет, на каких IP адресе и портах будет слушать сервис и правила распределения запросов между pod’ами.

Любой сервис можно запустить 2-я способами: вручную и с помощью конфиг-файла. Рассмотрим оба.

Запуск сервиса вручную

Начнём с создания Replication Controller’а:

conf% /opt/bin/kubectl run-container nginx --port=80 --port=443 --image=nginx --replicas=6 -s "http://192.168.0.10:8080" 

• nginx — имя будущего rc
• —port — порты на которых будут слушать контейнеры rc
• —image — образ из которого будут запущены контейнеры
• —replicas=6 — количество реплик

/opt/bin/kubectl get pods,rc -s "http://192.168.0.10:8080" 

POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE nginx-3gii4 172.16.58.4 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 9 seconds nginx-3xudc 172.16.62.6 192.168.0.10/192.168.0.10 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-igpon 172.16.58.6 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-km78j 172.16.58.5 192.168.0.11/192.168.0.11 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-sjb39 172.16.83.4 192.168.0.12/192.168.0.12 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds nginx-zk1wv 172.16.62.7 192.168.0.10/192.168.0.10 run-container=nginx Running 9 seconds nginx nginx Running 8 seconds CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx nginx nginx run-container=nginx 6 

• Часть pod находится в состоянии pending: это значит, что они ещё не запустились, необходимо немного подождать
• У pod не определён HOST: это значит, что scheduler ещё не назначил ноду на которой будет запущен pod

Далее создаём service который будет использовать наш Replication Controller как бекенд.
Для http:

conf% /opt/bin/kubectl expose rc nginx --port=80 --target-port=80 --service-name=nginx-http -s "http://192.168.0.10:8080" 

conf% /opt/bin/kubectl expose rc nginx --port=443 --target-port=443 --service-name=nginx-https -s "http://192.168.0.10:8080" 

• rc nginx — тип и имя используемого ресурса (rc = Replication Controller)
• —port — порт на котором будет «слушать» сервис
• —target-port — порт контейнера на который будет производиться трансляция запросов
• —service-name — будущее имя сервиса

/opt/bin/kubectl get rc,services -s "http://192.168.0.10:8080" 

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx nginx nginx run-container=nginx 6 NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes 192.168.3.1 80/TCP nginx-http run-container=nginx 192.168.3.66 80/TCP nginx-https run-container=nginx 192.168.3.172 443/TCP 

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

node% curl http://192.168.3.66 

В выводе curl увидим стандартную приветственную страницу nginx. Готово, сервис запущен и доступен.

Запуск сервиса с помощью конфигов

Для этого способа запуска необходимо создать конфиги для Replication Controller’а и service’а. Kubernetes принимает конфиги в форматах yaml и json. Мне ближе yaml поэтому будем использовать его.

Предварительно очистим наш кластер от предыдущего эксперимента:

conf% /opt/bin/kubectl delete services nginx-http nginx-https -s "http://192.168.0.10:8080" conf% /opt/bin/kubectl stop rc nginx -s "http://192.168.0.10:8080" Теперь приступим к написанию конфигов. 

nginx_rc.yaml
содержимое

apiVersion: v1beta3 kind: ReplicationController # Указываем имя ReplicationController metadata: name: nginx-controller spec: # Устанавливаем количество реплик replicas: 6 selector: name: nginx template: metadata: labels: name: nginx spec: containers: #Описываем контейнер - name: nginx image: nginx #Пробрасываем порты ports: - containerPort: 80 - containerPort: 443 livenessProbe: # включаем проверку работоспособности enabled: true type: http # Время ожидания после запуска pod'ы до момента начала проверок initialDelaySeconds: 30 TimeoutSeconds: 5 # http проверка httpGet: path: / port: 80 portals: - destination: nginx 

conf% /opt/bin/kubectl create -f ./nginx_rc.yaml -s "http://192.168.0.10:8080" 

conf% /opt/bin/kubectl get pods,rc -s "http://192.168.0.10:8080" 

POD IP CONTAINER(S) IMAGE(S) HOST LABELS STATUS CREATED MESSAGE nginx-controller-0wklg 172.16.58.7 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-2jynt 172.16.58.8 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-8ra6j 172.16.62.8 192.168.0.10/192.168.0.10 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-avmu8 172.16.58.9 192.168.0.11/192.168.0.11 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-ddr4y 172.16.83.7 192.168.0.12/192.168.0.12 name=nginx Running About a minute nginx nginx Running About a minute nginx-controller-qb2wb 172.16.83.5 192.168.0.12/192.168.0.12 name=nginx Running About a minute nginx nginx Running About a minute CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx-controller nginx nginx name=nginx 6 

Был создан Replication Controller с именем nginx и количеством реплик равным 6. Реплики в произвольном порядке запущены на нодах, местоположения каждой pod’ы указано в столбце HOST.

nginx_service.yaml

Содержимое

apiVersion: v1beta3 kind: Service metadata: name: nginx spec: publicIPs: - 12.0.0.5 # IP который будет присвоен сервису помимо автоматически назначенного. ports: - name: http port: 80 #порт на котором будет слушать сервис targetPort: 80 порт контейнера на который будет производиться трансляция запросов protocol: TCP - name: https port: 443 targetPort: 443 protocol: TCP selector: name: nginx # поле должно совпадать с аналогичным в конфиге ReplicationController 

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

conf% /opt/bin/kubectl create -f ./nginx_service.yaml -s "http://192.168.0.10:8080" 

/opt/bin/kubectl get rc,services -s "http://192.168.0.10:8080" 

CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS nginx-controller nginx nginx name=nginx 6 NAME LABELS SELECTOR IP PORT(S) kubernetes component=apiserver,provider=kubernetes 192.168.3.2 443/TCP kubernetes-ro component=apiserver,provider=kubernetes 192.168.3.1 80/TCP nginx name=nginx 192.168.3.214 80/TCP 12.0.0.5 443/TCP 

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

node% curl http://192.168.3.214 node% curl http://12.0.0.5 

В выводе curl увидим стандартную приветственную страницу nginx.

Заметки на полях

В качестве заключения хочу описать пару важных моментов, о которые уже пришлось запнуться при проектировании системы. Связаны они были с работой kube-proxy, того самого модуля, который позволяет превратить разрозненный набор элементов в сервис.
PORTAL_NET. Сущность сама по себе интересная, предлагаю ознакомиться с тем, как же это реализовано.
Недолгие раскопки привели меня к осознанию простой, но эффективной модели, заглянем в вывод iptables-save:

-A PREROUTING -j KUBE-PORTALS-CONTAINER -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER -A OUTPUT -j KUBE-PORTALS-HOST -A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER -A POSTROUTING -s 10.0.42.0/24 ! -o docker0 -j MASQUERADE -A KUBE-PORTALS-CONTAINER -d 10.0.0.2/32 -p tcp -m comment --comment "default/kubernetes:" -m tcp --dport 443 -j REDIRECT --to-ports 46041 -A KUBE-PORTALS-CONTAINER -d 10.0.0.1/32 -p tcp -m comment --comment "default/kubernetes-ro:" -m tcp --dport 80 -j REDIRECT --to-ports 58340 -A KUBE-PORTALS-HOST -d 10.0.0.2/32 -p tcp -m comment --comment "default/kubernetes:" -m tcp --dport 443 -j DNAT --to-destination 172.16.67.69:46041 -A KUBE-PORTALS-HOST -d 10.0.0.1/32 -p tcp -m comment --comment "default/kubernetes-ro:" -m tcp --dport 80 -j DNAT --to-destination 172.16.67.69:58340 

• gcloud — платная разработка от Google
• bgp — с помощью анонсирования подсетей
• IPVS
• и прочие варианты, которых множество

На этом всё, спасибо за внимание
К сожалению, всю информацию, которую хочется передать, не получается уместить в одну статью.

Использование материалы:

• Архитектура Kubernetes
• Kubernetes user guide
• Kubernetes ubuntu cluster
• Scaling Docker with Kubernetes
• Kubernetes services

Компоненты Kubernetes

При развёртывании Kubernetes вы имеете дело с кластером.

Кластер Kubernetes cluster состоит из набор машин, так называемые узлы, которые запускают контейнеризированные приложения. Кластер имеет как минимум один рабочий узел.

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

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

Ниже показана диаграмма кластера Kubernetes со всеми связанными компонентами.

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

Компоненты панели управления отвечают за основные операции кластера (например, планирование), а также обрабатывают события кластера (например, запускают новый под, когда поле replicas развертывания не соответствует требуемому количеству реплик).

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

kube-apiserver

Сервер API — компонент Kubernetes панели управления, который представляет API Kubernetes. API-сервер — это клиентская часть панели управления Kubernetes

Основной реализацией API-сервера Kubernetes является kube-apiserver. kube-apiserver предназначен для горизонтального масштабирования, то есть развёртывание на несколько экземпляров. Вы можете запустить несколько экземпляров kube-apiserver и сбалансировать трафик между этими экземплярами.

etcd

Распределённое и высоконадёжное хранилище данных в формате «ключ-значение», которое используется как основное хранилище всех данных кластера в Kubernetes.

Если ваш кластер Kubernetes использует etcd в качестве основного хранилища, убедитесь, что у вас настроено резервное копирование данных.

Вы можете найти подробную информацию о etcd в официальной документации.

kube-scheduler

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

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

kube-controller-manager

Компонент Control Plane запускает процессы контроллера.

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

Эти контроллеры включают:

• Контроллер узла (Node Controller): уведомляет и реагирует на сбои узла.
• Контроллер репликации (Replication Controller): поддерживает правильное количество подов для каждого объекта контроллера репликации в системе.
• Контроллер конечных точек (Endpoints Controller): заполняет объект конечных точек (Endpoints), то есть связывает сервисы (Services) и поды (Pods).
• Контроллеры учетных записей и токенов (Account & Token Controllers): создают стандартные учетные записи и токены доступа API для новых пространств имен.

cloud-controller-manager

cloud-controller-manager запускает контроллеры, которые взаимодействуют с основными облачными провайдерами. Двоичный файл cloud-controller-manager — это альфа-функциональность, появившиеся в Kubernetes 1.6.

cloud-controller-manager запускает только циклы контроллера, относящиеся к облачному провайдеру. Вам нужно отключить эти циклы контроллера в kube-controller-manager. Вы можете отключить циклы контроллера, установив флаг —cloud-provider со значением external при запуске kube-controller-manager.

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

Следующие контроллеры зависят от облачных провайдеров:

• Контроллер узла (Node Controller): проверяет облачный провайдер, чтобы определить, был ли удален узел в облаке после того, как он перестал работать
• Контроллер маршрутов (Route Controller): настраивает маршруты в основной инфраструктуре облака
• Контроллер сервисов (Service Controller): создаёт, обновляет и удаляет балансировщики нагрузки облачного провайдера.
• Контроллер тома (Volume Controller): создаёт, присоединяет и монтирует тома, а также взаимодействует с облачным провайдером для оркестрации томов.

Компоненты узла

Компоненты узла работают на каждом узле, поддерживая работу подов и среды выполнения Kubernetes.

kubelet

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

Утилита kubelet принимает набор PodSpecs, и гарантирует работоспособность и исправность определённых в них контейнеров. Агент kubelet не отвечает за контейнеры, не созданные Kubernetes.

kube-proxy

kube-proxy — сетевой прокси, работающий на каждом узле в кластере, и реализующий часть концепции сервис.

kube-proxy конфигурирует правила сети на узлах. При помощи них разрешаются сетевые подключения к вашими подам изнутри и снаружи кластера.

kube-proxy использует уровень фильтрации пакетов в операционной системы, если он доступен. В противном случае, kube-proxy сам обрабатывает передачу сетевого трафика.

Среда выполнения контейнера

Иполняемая среда контейнера — это программа, предназначенная для запуска контейнера в Kubernetes.

Kubernetes поддерживает различные среды для запуска контейнеров: Docker, containerd, CRI-O, и любые реализации Kubernetes CRI (Container Runtime Interface).

Дополнения

Дополнения используют ресурсы Kubernetes (DaemonSet, Deployment и т.д.) для расширения функциональности кластера. Поскольку дополнения охватывают весь кластер, ресурсы относятся к пространству имен kube-system .

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

DNS

Хотя прочие дополнения не являются строго обязательными, однако при этом у всех Kubernetes-кластеров должен быть кластерный DNS, так как многие примеры предполагают его наличие.

Кластерный DNS — это DNS-сервер наряду с другими DNS-серверами в вашем окружении, который обновляет DNS-записи для сервисов Kubernetes.

Контейнеры, запущенные посредством Kubernetes, автоматически включают этот DNS-сервер в свои DNS.

Веб-интерфейс (Dashboard)

Dashboard — это универсальный веб-интерфейс для кластеров Kubernetes. С помощью этой панели, пользователи могут управлять и устранять неполадки кластера и приложений, работающих в кластере.

Мониторинг ресурсов контейнера

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

Логирование кластера

Механизм логирования кластера отвечает за сохранение логов контейнера в централизованном хранилище логов с возможностью их поиска/просмотра.

Что дальше

• Подробнее про узлы
• Подробнее про контроллеры
• Подробнее про kube-scheduler
• Официальная документация etcd

Обратная связь

Эта страница была полезна?

Спасибо за обратную связь! Если у вас есть конкретный вопрос об использовании Kubernetes, спросите на Stack Overflow. Создайте issue в репозитории GitHub, если вы хотите сообщить о проблеме или предложить улучшение.