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

Обе системы оркестрации используют оверлейную сеть (Overlay Network) между нодами хостами для эмуляции нахождения управляемых единиц в едином локальном сетевом пространстве. Данный тип сети является логическим типом, который использует для транспорта обычные сети TCP/IP и призвана эмулировать нахождение нод кластера в единой сети для управления кластером и обмена информации между его нодами, тогда как на уровне TCP/IP они не могут быть связанны. Дело в том, что, когда разработчик разрабатывает кластер, он может описать сеть только для одной ноду, а при развёртывании кластера создаётся несколько его экземпляров, причём их количество может динамически меняться, а в одной сети не может существовать трёх нод с одним IP адресами и подсетями (например 10.0.0.1), а требовать от разработчика указывать IP адреса неправильно, поскольку не известно, какие адреса свободны и сколько их потребуется. Данная сеть берёт на себя отслеживания реальных IP адресов узлов, которые могут выделяться из свободных рандомно и меняться по мере пересоздания нод к кластере, и предоставляет возможность обращаться к ним через ID контейнеров/подов. При таком подходе пользователь обращается к конкретным сущностям, а не динамики меняющимся IP адресам. Взаимодействие осуществляется с помощью балансировщика, который для Docker Swarm логически не выделен, а в Kubernetes он создаётся отдельной сущностью для выбора конкретной реализации, как и другие сервисы. Подобный балансировщик должен присутствовать в каждом кластере и но называется в рамках экосистемы Kuberntes сервисом (Service). Его можно объявить, как отдельно как Service, так и в описании с кластером, например, как Deployment. К сервису можно обратиться по его IP-адресу (посмотреть в его описании) или по имени, которое регистрируется как домен первого уровня во встроенном DNS сервере, например, если имя сервиса, заданного в метаданных my_service, то к кластеру можно обратиться через него так: curl my_service;. Это является довольно стандартным решением, когда компоненты системы вместе с их IP адресами меняются со временем (пересоздаются, добавляются новые, удаляются старые) – направлять трафик через прокси сервер, I P- или DNS адреса для внешней сети остаются постоянными, а внутренние могут меняться, оставляя заботу согласование их на прокси сервере.

Обе системы оркестрации использую оверлейную сеть Ingress для предоставления к себе доступа из внешней сети через балансировщик, который согласует внутреннею сеть с внешней на основе таблиц соответствия IP адресов ядра Linux (iptalbes), разделяя их и позволяя обмениваться информацией, даже при наличи одинаковых IP адресов во внутренней и внешней сети. А, вот, для поддержания соединения между этими потенциально конфликтными на IP уровне сетями используется оверлейнера Ingress сеть. Kubernetes предоставляет возможность создать логическую сущность – контроллер Ingress, который позволит настроить сервис LoadBalancer или NodePort в зависимости от содержимого трафика на уровне выше HTTP, например, маршрутизацию на основе путей адресов (application router) или шифрование трафика TSL/HTTPS, как это делаю GCP и AWS.

Kubernetes – результат эволюции через внутренних проектов Google через Borg, затем через Omega, на полученном опыте от экспериментов сложилась довольно масштабируемая архитектура. Выделим основные типы компонентов:

* Pod – обычный под

* ReplicaSet, Deployment – масштабируемые поды

* DaemonSet – в каждой ноде кластера он создаётся

* сервисы (отсортированы по мере важности): ClusterIP (по умолчанию, базовый для остальных), NodePort

(перенаправляет порты, открытые в кластере, у каждого пода, на порты из диапазона 30000-32767 для

обращения к конкретным подам из внешней), LoadBalancer (NodePort с возможностью создания публичного

IP-адреса для доступа в интернет в таких публичных облаках, как AWS и GCP), HostPort (открывает порты

на хостовой машине соответствующие контейнеру, то есть если в контейнере открыт порт 9200, он будет

открыт и на хостовой машине для прямого перенаправления трафика) и HostNetwork (контейнеры в поде

будут находиться в сетевом пространстве хоста)

Мастер как минимум содержит: kube-apiserver, kube-sheduler и kube-controller-manager. Состав слейва:

* kubelet – проверка работоспособности компонента системы (ноды), создание и управление контейнерами. Он находится на каждой ноде,

обращается к kube-apiserver и приводит в соответствие ноду, на которой расположен.

* cAdviser – мониторинг ноды

//http://linux-notes.org/nastrojka-docker-swarm-klastera-v-unix-linux/

Допустим у на есть хостинг и мы создали три AVS сервера. Теперь необходимо на каждый сервер установить docker и docker-machine, о том как это сделать было рассказано выше. Docker-machine сама является виртуальной машиной для doker контейнеров, мы собирем лишь внутренний для неё драйвер – virtualbox – чтобы не устанавливать дополнительные пакеты. Теперь, из операций, которые должны быть выполнены на каждом сервере останется создать doker машины, остальные же операции по настройки и созданию контейнеров на них можно выполнять из master-ноды, а они буду автоматически запущены на свободных нодах и перераспределяться при изменении их количества. Итак. запустим docker-machine на первой ноде: