Базовая работа с Kubernetes — часть 2

Рассмотрим несколько основных ресурсов/объектов в Kubernetes

Ресурс/Объект Pod
Pod  — минимальная базовая единица Kubernetes, представляет собой группу из одного или нескольких контейнеров (например, контейнеров Docker) с общим хранилищем / сетью и спецификацией для запуска контейнеров
Сам по себе не может перезапускаться автоматически при ручном или аварийном завершении своей работы. Поэтому выше над Pod-ом существуют другие ресурсы,которые позволяют отслеживать и перезапускать поды(ReplicaSet/Deployment)

Создание пода

Просмотр наличия созданного пода

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

 

Ресурс/Объект ReplicaSet

ReplicaSet следит и поддерживает желаемое кол-во запущенных реплик Pod-ов в любой момент времени
Как правило,самостоятельно ReplicaSet не используется в виду того,что не поддерживает некоторые полезные возможности, которые релизованы/поддерживаются в ресурсе Deployment, который включает в себя и управляет в том числе ReplicaSet-ом
Например, при обновлении приложения ReplicaSet удаляет все свои реплики, а потом создает новые реплики с новым приложением без контроля порядка запуска и какой-либо гарантии успешного запуска, что приводит к недоступности приложения при его обновлении
Ресурс Deployment позволяет определить условия/порядок/политики очередности удаления и создания реплик для того, чтобы поддерживать необходимое кол-во реплик всегда в запущенном виде и таким образом гарантировать ,что приложение всегда было доступно(т.е. zero-downtime обновление)

 

Ресурс/Объект horizontalpodautoscaler
Автоматическое регулирование кол-ва подов в зависимости от нагрузки процессора(добавление пода/подов при нагрузке CPU от 80%)
Минимальное кол-во подов-1
Максимальное кол-во подов-10
После выполнения этой команды(до этого было 3 запущенных пода) останется запущенным только 1 под(2 пода будут автоматически удалены) т.к. нагрузка на процессор маленькая и происходит автоудаление кол-во подов до минимального кол-ва, которого достаточно, чтобы нагрузка на процессоре не выходила за установленные пределы

Декларативным способ создания horizontalpodautoscaler с помощью yaml-файла

 

Ресурс/Объект Deployment

Deployment включает в себя ReplicaSet и Pod и позволяет устанавливать политики/правила для zero-downtime автоматического обновления/отката приложений, запущенных в контейнерах

Создание Deployment

Если установлена опция —record, то текущая kubectl команда будет записана в аннотацию ресурса(деплоймента)

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

Все дальнейшие команды по этому деплойменту также будут присутствовать в истории

 

Посмотрим как происходит процесс обновления приложения

Обновим образ, с которого запускаются контейнеры в подах в деплойменте nginx-deployment

И посмотрим,как происходит замена replicaset-ов(соответственно и подов ,принадлежащих этой replicaset) на новый replicaset

Это то,что было до выполнения команды по обновлению образа

После обновления образа кол-во реплик в новой ReplicaSet(nginx-deployment-57d896dbfc) увеличивается на 1(с 0 на 1), после чего кол-во реплик в старой ReplicaSet(nginx-deployment-78dc5754fb) уменьшается на 1 (с 3 до 2)
Т.к. в настройках RollingUpdate выставлены следующие параметры

Максимальное кол-во недоступных подов состовляет 0 (параметр maxUnavailable ) и максимальное кол-во подов, которые может быть создано за раз составляет 1(параметр maxSurge)
т.е. при кол-ве реплик 3, сначала создается первый новый под с новым образом(первая реплика новой ReplicaSet)(но в сумме он уже является четвертым), потом удаляется один под со старым образом(удаляется первая реплика старой ReplicaSet)(таким образом общее кол-во подов уменьшается до 3-х)
Так происходит до тех пор, пока все поды не обновляться со старого образа на новый

Просмотр кол-ва новой(nginx-deployment-57d896dbfc) и старой(nginx-deployment-78dc5754fb) ReplicaSet-ов

 

Посмотрим как происходит процесс отката приложения(rollback) на более раннюю версию
Откатимся к предыдущей версии приложения

Проверим, что старая ReplicaSet(nginx-deployment-78dc5754fb) снова имеет 3 реплики, а новая(nginx-deployment-57d896dbfc) ReplicaSet-0

Соответственно и поды запущенные со старой ReplicaSet

 

Ресурс/Объект Service

Service – это абстракция, которая определяет логический набор Pod-ов и политику доступа к ним
Т.к. IP-адреса подов действительны только на протяжении жизни пода и авто/ручное масштабирование подразумевает увеличение/уменьшение кол-ва запущенных подов, да и просто под может быть автоматичеки перезапущен deployment-ом/replicaset-ом в случае проблем с ним, то для доступа к группе подов используют единую точку доступа – Service

 

Объект Service с типом ClusterIP
Сервисе с типом CusterIP доступен только внутри кластера для любого пода, запущенного в этом кластере

Проверим наличие созданного объекта Service

Просмотрим детальное описание сервиса nginx-service, его Endpoints – поды, на которые перенаправляются запросы поступившие на этот под
Т.е. запросы на сервис nginx-service( на кластерный IP-адрес сервиса 10.7.251.234 и Port(80) протокол(TCP) будут перенаправляться на поды 10.4.0.15, 10.4.1.12, 10.4.2.9 на порт 80

Кластерный IP-адрес у Service — 10.7.251.234

Kubernetes поддерживает 2 основных способа/метода разименования Service(получение IP-адреса и порта, который соответствует данному имени сервиса)
— DNS
— переменные окружения

Рассмотрим рекомендуемый способ/метод разименования — DNS

Благодаря встроенному в Kubernetes Service Discovery (Etcd) и DNS-серверам в кластере(KubeDNS или CoreDNS), имя сервиса nginx-service резолвится в кластерный IP-адрес(10.7.251.234), который доступен со всех подов кластера

Например, создадим Pod с именем busybox на основе образа busybox
Подключимся внутрь контейнера, запущенного в этом Pod-е и проверим доступность сервиса nginx-service внутри этого пода

Просмотр содержимого фалйа /etc/resolv.conf внутр. Контейнера с busybox

Как видно, в файле /etc/resolv.conf внутри контейнера указаны DNS-сервер/IP-адрес 10.7.240.10
На самом деле этот IP-адрес 10.7.240.10 — это кластерный IP-адрес Service kube-dns

Этот Service kube-dns имеет под собой endpoint-ы – поды с запущенной DNS-службой кластера, куда и перенаправляет запросы, поступивший от нашего пода busybox

Просмотр подов,которым принадлежат эти IP-адреса

Вот так выглядит цепочка прохождения запроса от кластерного IP-адреса сервиса с типом ClusterIP(10.7.240.10) до одного из активных/запущенных подов, используемых как endpoint-ы для этого сервиса

Т.е. каждый первый запрос перенаправляется на под с адресом 10.4.0.7
каждый второй запрос перенаправляется на под с адресом 10.4.2.3
т.е. равномерное распределение запросов на все поды(в данном случае на два пода)

Выполним проверку на разименование имени сервиса nginx-service в кластерный IP-адрес сервиса nginx-service (10.7.251.234)
Делаем запрос на получение IP-адреса, на котором доступен сервис nginx-service(10.7.251.234)

Т.е. контейнер с busybox корректно получил кластерный IP-адрес сервиса nginx-service(10.7.251.234)

Рассмотрим альтернативный способ/метод разименования имени сервиса в IP-адрес — через переменные окружения

Внутри контейнера с busybox также доступны следующие переменные относительно nginx-service
Наполнение контейнера переменными происходит при старте контейнера
Если изменяется Service, то новые настройки Service будут доступны внутри контейнера только после рестарта контейнера
Также это накладывает ограничения на порядок создания сервисов и подов — любой сервис, к которому должен обращаться под
должен быть создан ДО содания самого пода, иначе переменные по сервису будут отсутствовать в этом поде
DNS-способ разименования сервиса лишен такого недостатка

 

Объект Service с типом LoadBalancer
Service c типом LoadBalancer позволяется опубликовать/выставить порты наружу для возможности подключения к приложению снаружи кластера
Сервис с типом ClusterIP, на которую будет пернаправляться запросы с внешнего лоадбалансера, создается автоматически

Проверим наличие созданного объекта Service

Через 1-2 минуты проверим наличие внешнего IP-адреса, который выдал нам облачным провайдер(в данном случае Google Cloud)

Внешний IP-адрес у Service — 35.195.161.174
На этот адрес приходят клиентские запросы на приложение
Т.е. curl http://35.195.161.174/ отдаст дефолтную страницу nginx одного из контейнеров, запущенных на одном из трех подов в кластере

Приведенные команды и их вывод позволяет отследить путь прохождения пакета по цепочкам таблицы nat для того, чтобы лучше понять, как пакет от клиента достигает одного из подов кластера
Часть вывода команд не релевантного с путем прохождения пакетов была удалена, с целью сделать цепочку прохождения пакета более прозрачнее/нагляднее

Service с типом LoadBalancer(внешний IP-адрес 35.195.161.174)

т.е. каждый третий пакет идет на под с адресом 10.4.0.15
каждый второй пакет от оставшихся 2/3 пакетов(т.е. половина из оставшихся) идет на под с адресом 10.4.1.12
все остальные оставшиеся пакеты(это 1/3) идут на под с адресом 10.4.2.9
Тем самым достигается равномерное распределение запросов на все 3 пода

 

Service с типом Node Port
Аналогичная ситуация с прохождением пакеты по сервису с типом NodePort(на всех нодах кластера открывается средствами запущенного на каждой ноде kube-proxy рандомный порт (если не указано принудительно) из диапазона 30000-32767) и на этот порт можно направлять запросы на любую из нод(независимо от того, запущен ли на этой ноде нужный под или нет)
Сервис с типом ClusterIP, на которую будет пернаправляться запросы с service NodePort, создается автоматически
Например, сервис с типом NodePort можно использовать, когда перед нодами кластерами стоит собственный(не облачный) лоадбалансер(например, Haproxy)

Далее цепочка прохождения пакетов аналогично варианту с типом Service LoadBalancer
Начиная с команды

Взаимодействие компонентов кластера при сервисе типа ClusterIP и сервисы типа LoadBalancer указаны на схеме

 

Ресурс/Объект Secret

Создание файлов, из которых будем создавать Secret

Создание Secret из файлов императивным способом

Проверка наличия созданного секрета

Просмотр детальной информации о секрете

 

Создание Secret из файлов декларативным способом(из yaml-файла)
Для этого получим base64-код содержимого файлов, из которых создаем Secret

YAML-файл для создания Secret имеет вид

Создадим Secret применяя данный файл

 

Монтирование Secret-ов внутри пода с помощью volume(тома) для доступа контейнеров к Secret-ам
Например, создадам Pod через yaml-файл с примонтированным внутри контейнера (в каталог /secrets) секретом my-secrets, который был создан ранее

Файл для создания ресурса Pod с монтированием секретов

Проверка синтаксиса созданного файла pod-secrets.yml

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

 

Ресурс/Объект ConfigMap

Ключевые особенности/преимущества ConfigMap-ов
а) могут содержать пары ключ/значение
б) могут использоваться множеством подов одновременно
в) могут быть обновлены не зависимо от пода


Наполнение переменных окружения пода с помощью Configmap

Создание Configmap с помощью императивного способа
ConfigMap-ы могут быть
А)созданы из файлов с переменными(эти файлы должны содержать информацию в формате ключ=значение по одному на строку, пустые строки и строки, начинающиеся с символа # игнорируются.)

Следует заметить, что при передаче нескольких параметров —from-env-file для создания конфигмапа, будет использован только последний из указанных файлов.

Б)c указанием переменных непосредственно в команде

Создание Configmap с помощью декларативного способа(из yaml-файла)

В) Создание из yaml-файлов

Значения переменных, которые берутся из Configmap наполняются в поде при старте пода.
Если после запуска пода изменилось значение в ConfigMap, то для того, чтобы под применил такое изменение, под должен быть перезапущен

Например, файл описания сonfimap имеет вид

Создадим его и проверим его наличие

Файл описания пода имеет вид

Создадим под и проверим наличие корректного значения переменной someVariable внутри этого пода.

Изменим значение переменной someVariable в configmap c «some value2» на «some value2» в действующем конфигмапе

Но в поде остается старое значение переменной

Для того,чтобы в поде появилось новое значение, под нужно перезапустить

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

Если нужно все переменные получить доступными в поде из конфигмапа, тогда описание пода относительно получения всех доступных в конфигмапе переменных может иметь вид

 

Конфигурации приложения, запущенного в поде с помощью Configmap

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

Либо с нескольких файлов

Либо с нескольких файлов, находящихся внутри одной директории

Например, создадим configmap из файлов,находящихся внутри каталога config

Файл описания пода имеет вид
Смонтируем внутри каталога /etc/config в контейнере файлы, содержащиеся в configmap-е my-configmap

Проверим наличие файлов внутри контейнера в каталоге,куда смонтирован configmap

При обновлении Configmap-а, kubernetes автоматически обновит смонтированные внутри контейнера файлы без необходимости перезапуска пода

Комментирование и размещение ссылок запрещено.

Комментарии закрыты.

Яндекс.Метрика