Евгений Штольц - Из разработчика в архитекторы. Практический путь

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 состоит из физических контейнеров, сетевое взаимодействие между которыми происходит через их порты, поэтому они не дублируются.