Возможность использования многоузловой кластерной архитектуры Kubernetes - PullRequest
0 голосов
/ 10 мая 2018

Я пытаюсь реализовать конвейер CI / CD с использованием Kubernetes и Jenkins. В моем приложении у меня 25 микро сервисов. И нужно развернуть его для 5 разных клиентов. Код микросервиса уникален. Но конфигурация для каждого клиента различна.

Итак, я настраиваю сервер конфигурации Spring Cloud с 5 различными профилями / конфигурациями. И когда я создаю образы Docker, я определю, какой профиль активного сервера конфигурации, добавив активный профиль в файл Docker. Итак, из 25 микросервисов я создаю 25 * 5 изображений Docker и внедряю их. Итого 125 микросервисов, которые мне нужно развернуть в кластере Kubernetes. И эти микросервисы вызываются из моего внешнего приложения Angular 2.

Здесь, когда я рассматриваю производительность приложения и скорость отклика, достаточно ли одного мастера этой архитектуры приложения? Или мне обязательно нужно использовать мультимастерный кластер Kubernetes? Как я могу управлять этим приложением?

Я новичок в этих задачах облачной и конвейерной архитектуры CI / CD. Так что у меня есть путаница, связанная с проектированием рабочего процесса. Если одного мастера достаточно, то я могу продолжить с текущим. В противном случае мне нужно реализовать мультимастерный кластер HA Kubernetes.

Ответы [ 2 ]

0 голосов
/ 22 мая 2018

Мульти мастер звучит как хорошая идея для HA.

Вы также можете использовать Helm , который позволяет настраивать микросервисы для каждой установки, чтобы вам не приходилось каждый раз переиздавать образы док-станции для настройки новой среды. Затем вы можете ввести конфигурацию helm, скажем, в ConfigMap, который монтирует содержимое как application.yml, так что Spring Boot автоматически загружает настройки

0 голосов
/ 10 мая 2018

Производительность приложения и / или скорость не зависят от количества мастер-узлов. Это решает проблемы высокой доступности, но не производительности. Теперь вы все равно должны подумать о наличии как минимум 3 мастеров для реализации, над которой вы работаете. Если мастер выйдет из строя, ваш кластер бесполезен.

В Kubernetes мастер получает вызовы API и воздействует на них, устанавливая желаемое состояние кластера в текущее состояние. Но в конце концов это узлы (рабы) делают тяжелую работу. Таким образом, ваши проблемы с производительностью будут зависеть в основном, если не исключительно, от ваших узлов. Если у вас достаточно памяти и процессора, все будет в порядке.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...