Евгений Штольц - Облачная экосистема

Проверим распределение информации между нодами с помощью распределенного key-value хранилища, то есть, если мы в одну ноду добавили записи, то они должны распространиться и на другие ноды, при этом жёстко заданного координирующего (Master) ноды у неё не должно быть. Поскольку Consul состоит из одного исполняемого файла – скачиваем его с официального сайта по ссылке https://www.consul.io/downloads. html на каждой ноде:

wget https://releases.hashicorp.com/consul/1.3.0/consul_1.3.0_linux_amd64.zip -O consul.zip

unzip consul.zip

rm -f consul.zip

Теперь необходимо запустить одну ноду, пока, как master consul -server -ui, а другие как slave consul -server -ui и consul -server -ui . После чего остановим Consul, находящийся в режиме master, и запускаем его как равного, в результате Consul – переизберут временного лидера, а в случае иго падения, переизберут снова. Проверим работу нашего кластера consul members:

consul members;

И так проверим распределение информации нашего хранилища:

curl -X PUT -d 'value1' .....:8500/v1/kv/group1/key1

curl -s .....:8500/v1/kv/group1/key1

curl -s .....:8500/v1/kv/group1/key1

curl -s .....:8500/v1/kv/group1/key1

Настроим мониторинг сервисов, подробнее в документации https://www.consul.io/docs/agent/options. html #telemetry, для этого .... https://medium.com/southbridge/monitoring-consul-with-statsd-exporter-and-prometheus-bad8bee3961b

Чтобы не настраивать, воспользуемся контейнером и режимом для разработки с уже настроенным IP-адресом на 172.17.0.2:

essh@kubernetes-master:~$ mkdir consul && cd $_

essh@kubernetes-master:~/consul$ docker run -d –name=dev-consul -e CONSUL_BIND_INTERFACE=eth0 consul

Unable to find image 'consul:latest' locally

latest: Pulling from library/consul

e7c96db7181b: Pull complete

3404d2df15cb: Pull complete

1b2797650ac6: Pull complete

42eaf145982e: Pull complete

cef844389e8c: Pull complete

bc7449359c58: Pull complete

Digest: sha256:94cdbd83f24ec406da2b5d300a112c14cf1091bed8d6abd49609e6fe3c23f181

Status: Downloaded newer image for consul:latest

c6079f82500a41f878d2c513cf37d45ecadd3fc40998cd35020c604eb5f934a1

essh@kubernetes-master:~/consul$ docker inspect dev-consul | jq ' .[] | .NetworkSettings.Networks.bridge.IPAddress'

"172.17.0.4"

essh@kubernetes-master:~/consul$ docker run -d –name=consul_follower_1 -e CONSUL_BIND_INTERFACE=eth0 consul agent -dev -join=172.17.0.4

8ec88680bc632bef93eb9607612ed7f7f539de9f305c22a7d5a23b9ddf8c4b3e

essh@kubernetes-master:~/consul$ docker run -d –name=consul_follower_2 -e CONSUL_BIND_INTERFACE=eth0 consul agent -dev -join=172.17.0.4

babd31d7c5640845003a221d725ce0a1ff83f9827f839781372b1fcc629009cb

essh@kubernetes-master:~/consul$ docker exec -t dev-consul consul members

Node Address Status Type Build Protocol DC Segment

53cd8748f031 172.17.0.5:8301 left server 1.6.1 2 dc1 < all>

8ec88680bc63 172.17.0.5:8301 alive server 1.6.1 2 dc1 < all>

babd31d7c564 172.17.0.6:8301 alive server 1.6.1 2 dc1 < all>

essh@kubernetes-master:~/consul$ curl -X PUT -d 'value1' 172.17.0.4:8500/v1/kv/group1/key1

true

essh@kubernetes-master:~/consul$ curl $(docker inspect dev-consul | jq -r ' .[] | .NetworkSettings.Networks.bridge.IPAddress'):8500/v1/kv/group1/key1

[

{

"LockIndex": 0,

"Key": "group1/key1",

"Flags": 0,

"Value": "dmFsdWUx",

"CreateIndex": 277,

"ModifyIndex": 277

}

]

essh@kubernetes-master:~/consul$ firefox $(docker inspect dev-consul | jq -r ' .[] | .NetworkSettings.Networks.bridge.IPAddress'):8500/ui

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

dockerd -H fd:// –cluster-store=consul://192.168.1.6:8500 –cluster-advertise=eth0:2376

* –cluster-store – можно получать данные о ключах

* –cluster-advertise – можно сохранять

docker network create –driver overlay –subnet 192.168.10.0/24 demo-network

docker network ls

Простая кластеризация

В данной стать мы не будем рассматривать как создать кластер вручную, а воспользуемся двумя инструментами: Docker Swarm и Google Kubernetes – наиболее популярные и наиболее распаренные решения. Docker Swarm проще, он является частью Docker и поэтому, имеет наибольшую аудиторию (субъективно), а Kubernetes предоставляет гораздо большие возможности, большее число интеграций с инструментами (например, распределённое хранилище для Volume), поддержка в популярных облаках и более просто масштабируемый для больших проектов (большая абстракция, компонентный подход).

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

* случае падения одного сервера, переброс контейнеров (создания новых) на другие сервера;

* равномерное распределение контейнеров по серверам для отказоустойчивости;

* создание контейнера на сервере, подходящем по свободным ресурсам;

* Разворачивание контейнера, в случае выхода его из строя;

* единый интерфейс управления из одной точки;

* выполнения операций с учётом параметров серверов, например, размера и типа диска и особенностей контейнеров, заданных администратором, например, связанные контейнера единым точкой монтирования размещаются на данном сервере;

* унификация разных серверов, например, на разных ОС, облачных и не облачных.

Теперь мы перейдём от рассмотрения Docker Swarm к Kubernetes. Обе эти системы – системы оркестрации, обе работаю с контейнерами Docker (Kubernetes также поддерживает RKT и Containerd), но взаимодействий между контейнерами принципиально другое из-за дополнительного уровня абстракции Kubernetes – POD. И Docker Swarm, и Kubernetes управляют контейнерами на основе IP адресов и распределяют их по нодам, внутри которых всё работает через localhost, проксируемый мостом, но в отличии от Docker Swarm, который работает для пользователя с физическими контейнерами, Kubernetes для пользователя работает с логическими – POD. Логический контейнер Kubernetes состоит из физических контейнеров, сетевое взаимодействие, между которыми происходит через их порты, поэтому они не дублируются.