В предыдущем посте мы масштабировали набор реплик MongoDB и познакомились со StatefulSet. Сейчас мы займемся оркестрацией кластера высокой доступности Elasticsearch (с другими мастер-нодами, нодами данных и клиентскими нодами) и задействуем ES-HQ и Kibana.  (Деплой и headless-сервис для мастер-нод) Интересно изучить логи подов на мастер-нодах и посмотреть, как выбирается среди них мастер сейчас и как это будет потом, когда мы добавим новые ноды данных и клиентские ноды. Здесь видно, что под es-master с именем es-master-594b58b86c-bj7g7 выбран мастером, а остальные два пода добавлены к нему и друг к другу. headless сервис elasticsearch-discovery по умолчанию устанавливается в образе Docker как переменная среды и служит для обнаружения в нодах. Эту настройку при желании можно заменить. Точно так же мы развертываем ноды данных и клиентские ноды. Конфигурации смотрите ниже. (StatefulSet и headless сервис для нод данных) headless сервис на нодах данных выдает нодам стабильные идентификаторы сети и помогает передавать данные между нодами. Важно отформатировать постоянный том, прежде чем привязывать его к поду. Просто укажите тип тома, когда создаете класс хранилища. Еще можно задать параметр, разрешающий автомтическое расширение тома. Подробности читайте здесь. (Деплой и внешний сервис для клиентских нод) Развернутый здесь сервис открывает доступ к кластеру ES снаружи кластера Kubernetes, но все равно находится внутри подсети. За это отвечает аннотация cloud.google.com/load-balancer-type: Internal. Но если приложение, которое обращается к кластеру ES для чтения и записи, развернуть внутри кластера, то доступ к сервису ElasticSearch можно получить по адресу http://elasticsearch.elasticsearch:9200. Когда вы развернете ноды данных и клиентские ноды, они добавятся в кластер автоматически. (Ищите мастер-под в логах) В логах главного мастер-пода хорошо видно, когда каждая нода добавляется в кластер. Это полезно знать при отладке. Мы развернули все компоненты, и теперь нужно проверить: 1) Деплой Elasticsearch из кластера Kubernetes с помощью контейнера Ubuntu. 2) Деплой Elasticsearch снаружи кластера по IP внутреннего балансировщика GCP (в нашем случае — 10.9.120.8). 3) Правила anti-affinity для подов ES. Заметьте — у нас нет двух похожих подов на одной ноде, так что мы обеспечили высокую надежность при отказе ноды. Мы можем развернуть сервисы автомасштабирования для клиентских нод в зависимости от лимита ЦП. Пример HPA для клиентской ноды: Автомасштабирование добавляет поды на клиентской ноде в кластер, и это видно в логах любого пода на мастер-ноде. Что касается подов на нодах данных, нужно просто увеличить число реплик на панели управления Kubernetes или в консоли GKE. Созданная нода данных сама добавится в кластер и начнет реплицировать данные с других нод. Подам на мастер-нодах автомасштабирование не нужно — они хранят только данные о состоянии кластера. Но если вы собираетесь добавлять ноды данных, следите, чтобы число мастер-нод в кластере было нечетным, и не забывайте менять для среды переменную NUMBER_OF_MASTERS. Kibana и ES-HQ Kibana — это простой инструмент для визуализации данных ES, а ES-HQ помогает администрировать и мониторить кластер Elasticsearch. При деплое Kibana и ES-HQ помните, что: (Деплой и сервис Kibana) (Деплой и сервис ES-HQ) К обоим сервисам мы обращаемся через созданный внутренний балансировщик. http://<External-Ip-Kibana-Service>/app/kibana#/home?_g=() (Панель управления Kibana) http://<External-Ip-ES-Hq-Service>/#!/clusters/my-es (Панель управления ElasticHQ для мониторинга и управления кластером) ES — это одна из самых популярных распределенных систем поиска и анализа, а в Kubernetes она решает ключевые проблемы машстабирования и высокой доступности. К тому же новые кластеры ES в Kubernetes развертываются моментально.