Возможность стандартного способа развертывания приложений на разных узлах с использованием архитектуры Kubernetes

Question

Я планирую использовать Kubernetes и Jenkins для своего развертывания микросервисов.

Характер приложения

У меня всего 15 микро сервисов Spring Boot.И нужно развернуть все эти 15 микро сервисов для разных клиентов - каждый использует один и тот же код, но нужно развернуть все это отдельно.Означает, что каждый клиент имеет свои собственные развернутые.Всего у меня 5 клиентов (это предположение. Не точное. Оно будет варьироваться от 20 до 50).

Мой текущий дизайн

В настоящее время я планирую использовать5 узлов Kubernetes. Означает один мастер кластера плюс 5 узлов.Всего 6 ВМ.И планируем развернуть каждый из этих 15 микро сервисов на этих 5 узлах для 5 клиентов.Таким образом, каждый получит свое собственное размещение.А также я установлю Jenkins на моей виртуальной машине кластера Kubernetes для создания конвейера CI / CD.

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

Пожалуйста, очистите мою путаницу с моим текущим подходом.Если это хорошо, я могу продолжить.Я только ищу это промышленный стандартный способ использования Kubernetes.Это хорошая архитектура?

Answer 1

Несколько вещей приходят на ум:

• одного мастера недостаточно. Потеря этой виртуальной машины, базового оборудования или сбой служб на главном сервере приведет к отключению всех клиентов и, возможно, к катастрофической потере данных. Запустите минимум 3 мастера.
• каждый клиент, на котором запущены отдельные копии каждой из служб, является субоптимальной моделью аренды. Существует множество ситуаций, в которых это требуется, но в этих ситуациях каждый клиент часто запускает свой собственный отдельный выпуск служб. Управлять этим в микросервисной архитектуре ужасно.
• Компакт-диск в среде, где каждый клиент запускает свои собственные копии сервисов, возможно, свои собственные версии каждого, будет невозможен.
• JVM сильно потребляет процессор и память. Одна JVM была разработана для поддержки нескольких рабочих нагрузок. Таким образом, могут возникать конфликты между управлением ресурсами контейнера и управлением ресурсами JVM и работой микросервисов JVM