Алгоритм запуска многоузлового кластера Kubernetes и работа с ним в операционной системе Centos Linux

Все чаще в IT-сфере звучит термин DevOps (англ. Development & Operations – «разработка и эксплуатация»), возникший на пересечении двух направлений работы с информационно-технологическими (далее – ИТ) продуктами. DevOps можно обозначить как методология, согласно которой происходит взаимодействие инженеров по разработке и инженеров по ИТ-эксплуатации и взаимная интеграция их рабочих процессов для обеспечения качественной работы продукта [1; 7; 10]. Практики DevOps используются для улучшения эффективности управленческих и коммуникационных процессов. Одной из важных целей в методологии DevOps является использование единой платформы и окружения для разработки и доставки продуктов. Достигнуть этой цели позволяет использование контейнеризированных приложений.

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

Контейнеризация

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

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

Однако с увеличением числа развертываемых в контейнерах сервисов увеличивается и сложность настройки, управления и обеспечения бесперебойной работы системы в целом. Для автоматизации настройки компонентов, их контроля и обработки аварийных ситуаций используется инструмент-оркестратор Kubernetes [2; 4–6]. Kubernetes – это платформа с открытым исходным кодом, которая позволяет развертывать контейнеризированные рабочие нагрузки и управлять ими.

Контейнеры внутри Kubernetes разворачиваются в кластере. Кластер состоит из нескольких физических или виртуальных машин, которые в терминологии Kubernetes называются узлами (Nodes).

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

Приложения в кластере Kubernetes разворачиваются внутри среды запуска контейнеров (ContainerRuntime Interface), где каждый контейнер запускается в специально созданном модуле (Pod).

Алгоритм развертывания простого приложения

Продемонстрируем алгоритм развертывания простого приложения Node.js в кластере Kubernetes на операционной системе Linux CentOS 7 [8; 9]. В качестве среды запуска контейнеров в Kubernetes выбран инструмент Docker. Алгоритм включает в себя настройку операционной системы, установку компонентов Docker и Kubernetes, а также создание контейнерного образа приложения.

В качестве узлов кластера использованы две виртуальные машины со следующими минимальными характеристиками (см. Таблицу):

Алгоритм запуска многоузлового кластера Kubernetes и работа с ним ...

Характеристики виртуальных машин

Роль	Хост	IP адрес	Операционная система	ОЗУ	Процессор
Ведущий	kmaster	192.168.88.72	CentOS 7	2 Гб	2 CPU
Рабочий	kworker	192.168.88.73	CentOS 7	1 Гб	1 CPU

Алгоритм развертывания кластера включает в себя ряд шагов.

Шаг 1. Настройка операционной системы.

Чтобы контейнеры имели доступ к файловой системе, необходимо отключить службу SELinux, выполнив команды

• #    setenforce 0

• #    sed -i --follow-symlinks ‘s/SELINUX=enforcing/SELINUX=disabled/g’ /etc/sysconfig/ selinux

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

• #    firewall-cmd --permanent --add-port=6443/tcp

• #    firewall-cmd --permanent --add-port=2379-2380/tcp

• #    firewall-cmd --permanent --add-port=10250/tcp

• #    firewall-cmd --permanent --add-port=10251/tcp

• #    firewall-cmd --permanent --add-port=10252/tcp

• #    firewall-cmd --permanent --add-port=10255/tcp

• #    firewall-cmd –-reload

• #    swapoff -a; sed -i ‘/swap/d’ /etc/fstab

• #    cat >>/etc/sysctl.d/kubernetes.conf<

EOF

• #    sysctl–system

Шаг 2. Установка компонентов Docker и Kubernetes.

Далее на всех узлах должны быть установлены компоненты служб Kubernetes и среда запуска контейнеров Docker. Их установка происходит из официальных репозиториев. Эти репозитории не доступны из операционной системы по умолчанию, поэтому перед установкой их необходимо подключить. Репозиторий Docker доступен в официальном наборе репозиториев CentOS и подключается при помощи команды

• #    yum-config-manager \ --add-repo \

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

[kubernetes]

name=Kubernetes baseurl=

enabled=1

gpgcheck=0

repo_gpgcheck=1

gpgkey=

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

• #    yum install -y yum-utils device-mapper-persistent-data lvm2

Затем устанавливаются компоненты Kubernetes и Docker:

• #    yum install -y docker-cekubeadmkubeletkubectl

Выполнение указанной выше команды установит пакеты docker-ce (среда запуска контейнеров), kubeadm (инструмент для создания многоузловых кластеров), kubelet (контролер корректной работы контейнеров), kubectl (инструмент командной строки для взаимодействия с Kubernetes).

Когда установка всех компонентов закончится, необходимо запустить службу Docker при помощи команды# systemctlenable --nowdocker

На этом подготовка узлов к созданию кластера завершена и можно переходить к инициализации кластера.

Шаг 3. Создание кластера Kubernetes.

Инициализация кластера выполняется на будущем ведущем узле при помощи команды # sudokubeadminit --pod-network-cidr=10.0.0.0/23

Данная команда обозначит машину, на которой она запущена, в качестве ведущего узла в кластере и произведет его полную настройку, развернув все необходимые компоненты управляющего слоя. После выполнения данной команды в консоли появится текст, в котором будет представлена команда kubeadmjoin с указанием персонализированного токена (см. Рисунок 1). Полученная команда позволяет добавлять другие машины в качестве новых узлов. При этом стоит учесть, что токен действует 24 часа, а сгенерировать новый можно, выполнив команду

• #    kubeadm token create --print-join-command

Your Kubernctcs control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

You should now deploy a pod network to the cluster.

Run "kubcctl apply -f (podnetwork).yaol" with one of the options listed at:

Then you can join any number of worker nodes by running the following on each as root:

kubcadra join 192.168.88.72:6443 •-token сакиаг.ywOnvpnrarshgTvqp \

•-discovery-token-ca-ccrt-hash sha2S6:3086cn0eda25103131948a96cc43b4aa92f96ccel482ba67a2720cf5342b846

Рисунок 1. Результат выполнения команды kubeadminit

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

• #    kubectl label node kworker node-role.kubernetes.io/worker=worker

Алгоритм запуска многоузлового кластера Kubernetes и работа с ним ...

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

• #    mkdir -p $HOME/.kube

• #    sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

• #    sudochown $(id -u):$(id -g) $HOME/.kube/config

Завершает развертывание кластера установка плагина контейнерного сетевого взаимодействия, который позволит узлам и контейнерам корректного общаться друг с другом. В данном примере устанавливается плагин Antrea при помощи команды

• #    kubectl apply -f https://raw.githubusercontent.com/antrea-io/antrea/main/build/ yamls/antrea.yml

Теперь, выполнив на ведущем узле команды kubectlgetnode и kubectlgetpod, можно увидеть состояние всех узлов кластера и статус развернутых на нем модулей (см. Рисунок 2).

(woydpkaaster -Ji kubectl get node
max	STATUS ROLES           *6€	VERSION
lteiiter.Nes.exeiple.ni Ready contret-ptane 111		vl.24.1
kworker-k4$-exaaple-ru Mody worker          Sods		vl.24.1
(vvoydpliaester -Is kubectl get -A pods
MAXSPACE	MAX	READY	STATUS	RESTARTS	AGE
kube-systea	antrea•agent•rkkhc	2/2	Running	2 (4Ois ago)	Sales
kube-systea	entree-agent-sgxzt	2/2	Running	•	teles
kube-systea	ent rea-controller-7d47dc	1/1	Running	•	teJOs
kube-systea	coredns - 6d4b75cb6d • 497dq	1/1	Running	•	Ila
kube-systea	coredns *6d4b7Scb6d • 6Bpdp	1/1	Running	•	lie
kube-systea	etcd-kaister.kbs.exaapte.ru	1/1	Running	•	Ila
kube-systea	kube-aplserver-kaaster.KBs.exaaple.ru	1/1	Running	•	11a
kube-systea	kube-controller-Mnoger-kaaster.kBs .exaaple. ru 1/1		Running	•	Ila
kube-systea	kube-proxy-6lrk2	l/l	Running	e	11a
kube-systea	kube-proxy-j»6xt	1/1	Running	•	5816$
kube-systea	kube•scheduler•kaaster.kBs.exaaple.ru	VI	Running	•	Ila

Рисунок 2. Списки узлов кластера и запущенных на нем модулей

Среди модулей можно увидеть и элементы управляющего слоя Kubernetes, запущенные на ведущем узле (antrea-agent, antrea-controller, coredns, etcd, kube-apiserver, kube-controller-manager, kube-proxy, kube-scheduler), и агенты, запущенные на рабочем узле (antrea-agent, kube-proxy). Таким образом, мы получили работающий двухузловой кластер Kubernetes.

Шаг 4. Создание контейнерного образа приложения.

};

var www = http.createServer(handler);

(8080);

Данное приложение принимает HTTP-запросы и отвечает текстом с именем хоста, на котором оно запущено. Развернув такое приложение в кластере Kubernetes, в ответе можно увидеть имя модуля, в котором запущен контейнерный образ приложения.

Чтобы развернуть приложение в кластере, необходимо создать его контейнерный образ. Для создания контейнерного образа, необходимо предоставить список инструкций, которые Docker будет выполнять при сборке. Инструкции указываются в специальном файле Dockerfile, который расположен в одной директории с файлами приложения. Содержимое файла Dockerfile для текущего примера представлено в Листинге 3.

Листинг 3. Файл Dockerfile для создания контейнерного образа приложения

FROM node:7

В первой строке указан базовый образ, на основе которого происходят дальнейшие настройки. В данном случае используется контейнерный образ платформы Node.js из официального репозитория Docker. Во второй строке добавляется файл app.js из локального каталога в корневой каталог образа. В третьей строке определяется команда, которая будет выполнена при запуске образа. В данном случае это команда node app.js, которая запускает приложение при помощи инструментов node.

Создание контейнерного образа выполняется командой (test – название образа) # dockerbuild -t test

Для запуска получившегося контейнера на любой другой машине, его нужно загрузить в общедоступное хранилище DockerHub, предварительно зарегистрировавшись на сайте , создав свой собственный DockerID. Далее необходимо про-тегировать образ в соответствие с правилами Docker, согласно которым имя образа должно начинаться с DockerID. Создать новый тег для образа можно при помощи команды # dockertagttestvvoyd/test (здесь vvoyd – это Docker ID).

После создания тега необходимо авторизоваться в системе Docker под собственным ID командой dockerlogin и отправить образ в хранилище, выполнив команду

• #    dockerpushvvoyd/test

Шаг 4. Развертывание приложения в кластере Kubernetes.

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

• #    kubectl create namespace test-space

• #    kubectl config set-context --current --namespace= test-space

Когда приложение упаковано в образ контейнера и доступно через реестр Docker Hub, его можно развернуть в кластере Kubernetes при помощи команды# kubectl create deployment test --image= vvoyd/test . После завершения этой команды состояние нового модуля с приложением можно будет увидеть, выполнив команду kubectlgetpod, как показано на Рисунке 3.

Шаг 5. Получение доступа к приложению.

Каждый модуль при создании получает свой внутренний IP-адрес в кластере, недоступный из сети Интернет. Доступ извне можно получить при помощи службы NodePort, которая выделит внешний порт для доступа к запущенному приложению. Использовав этот порт вместе с IP-адресом одного из узлов кластера, можно отправить запрос напрямую в приложение. Создать службу и узнать выделенный порт можно при помощи команд

• #    kubectl expose deployment test --type=NodePort --name=test-service --port=8080

• #    kubectl get services

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE test-service NodePort 10.111.15.196 8080:31884/TCP 14s

Алгоритм запуска многоузлового кластера Kubernetes и работа с ним ...

(vvoydpknaster -)S kubectl get pod -A
MAXSPACE	MAME	READY	STATUS	RESTAMTS			AGE
kube-systee	antrea•opent-rkkhc	2/2	Running	1» <$dlh ago)			3d23h
kube-systee	entree-open t•sgxzP	2/2	Running	8	(5d2h	ago)	Sd23h
kube-systee	entree-centrotter•7d<7dcc«fd-vlppq	1/1	Running	4		ego)	5d23h
kube-systee	coredns-6d4b75	1/1	Aunnlnp	4	(Sd2h	ago)	5d23h
kube-systee	coredns•6d4b75cb6d•eepdp	1/1	Running	4		ago)	5d23h
kube-systee	etcd • booster. Us. exaeple. ru	1/1	Aunnlnp	4	<3d2h	ago)	5d23h
kube-systee	kube-aplserver-keaster.Us.exaeple.ru	1/1	Aunnlnp	4		ago)	5d23h
kube-systee	kube • cent roller • eanager- keener. Us. exaeple. ru	1/1	Running	4		ago)	5d23h
kube-systee	kube-proxy-81rk2	1/1	Aunnlnp	4	(5d2h	ago)	Sd23h
kube-systee	kube-proxy-JS6xt	1/1	Aunnlnp	4	<$dlh	ago)	5d23h
kube-systee	kube - scheduler - keaster. Us. exaeple. hi	l/l	Running	4	(3d2h	ago)	Sd23h
test-space	test-вЫс74всЬс-nrxnn	VI	Running	•			75S

Рисунок 3. Результат выполнения команды kubectlgetpod после развертывания приложения в кластере

Таким образом, приложение становится доступно из внешней сети по адресу 192.168.88.73:31884,

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

• #    curl http://192.168.88.73:31884/

You’ve hit test-6b8c746cbc-nrxnn

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

Заключение

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

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