Использование Kuma для запуска мультиоблачной сервисной сети

Question

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

В частности, как будет работать обнаружение сервисов, чтобы рабочие нагрузки на основе виртуальных машин могли обнаруживать нагрузки на основе K8s и наоборот?

Answer 1

Кума определяет так называемый zoneкак область изоляции управления, т.е. все соединения рабочей нагрузки управляются единой плоскостью управления. Такая плоскость управления называетсяremote. Общий вид и управление политиками осуществляется вglobal плоскость управления, объединяющая все зоны.

Когда кто-то начинает планировать распределенное развертывание, он должен включить следующие элементы:

• Где GlobalБудет развернута плоскость управления и ее тип. Последний может быть либоUniversal (ВМ /BareMetal/ Контейнер) или Kubernetes(локально / в облаке).
• Количество и тип добавляемых зон. Со временем они могут быть изменены.

Следуйте инструкциям по установкеglobalплоскость управления, выполняя шаги, специфичные для выбранного типа развертывания. Получите соответствующий IP-адрес / порты, как описано.

Установка remote Плоскость управления довольно тривиальна. Этот процесс может повторяться по мере необходимости в течение всего многозонного развертывания.

Здесь кратко описано межзональное потребление услуг. Короче говоря, мы рекомендуем использовать следующий синтаксис для доступа к службеecho-server, развернутый в пространстве имен Kubernetes echo-example и выставлен в порту 1010:

<kuma-enabled-pod>$ curl http://echo-server_echo-example_svc_1010.mesh

Используя этот синтаксис, службу можно найти и использовать даже из соседней универсальной зоны, где рабочая нагрузка выполняется в виртуальной машине. Kuma использует собственную службу DNS, которая позволяет обнаруживать эту службу.

Рекомендуется, чтобы службы, объявленные в виртуальных машинах, следовали одному и тому же формату именования служб, чтобы при необходимости иметь реплику службы в кластере Kubernetes, их можно было легко заменить без необходимости перенастраивать всю инфраструктуру.