Создание сервисной сетки
В этом документе объясняется, как создать сервисную сетку в одном кластере. Перед началом убедитесь, что вы знакомы со следующими темами:
- Модели развертывания сетки: выберите модель развертывания сетки, которая соответствует вашим требованиям.
- Описание компонентов сетки: поймите роли компонентов сетки и подготовьте необходимые ресурсы CPU и памяти для сервисной сетки.
Для инструкций по созданию сервисной сетки в нескольких кластерах обратитесь к документации Multi-Cluster Service Mesh.
Содержание
Ограничения и лимиты
- В одном кластере разрешена только одна сервисная сетка.
- Если кластер является глобальным и платформа находится в среде аварийного восстановления (то есть глобальный кластер имеет основной кластер и кластер аварийного восстановления), глобальный кластер не может развернуть сервисную сетку.
- Если кластер использует сеть с двойным стеком IPv4/IPv6, сервисная сетка не может быть развернута.
Предварительные требования
Скачайте пакет установки Alauda Service Mesh Operator, соответствующий архитектуре вашей платформы.
Загрузите пакет установки Alauda Service Mesh Operator с помощью механизма Upload Packages.
Убедитесь, что в кластере развернут плагин Prometheus или плагин VictoriaMetrics.
Примечание: При многоузловой архитектуре развертывания VictoriaMetrics vmstorage может находиться в другом кластере, отличном от сервисной сетки.
Убедитесь, что доступен Elasticsearch. Сервисная сетка может взаимодействовать с плагином логирования Elasticsearch кластера или с вашим собственным Elasticsearch.
Если кластер является кластером OpenShift, необходимо также выполнить следующие требования:
- Создано пространство имён
istio-system. - Добавьте пространство имён
istio-systemв группу SCC (Security Context Constraints)anyuid. Для этого войдите на bastion-хост кластера OpenShift и выполните команду:
Шаги
- В левой навигационной панели нажмите Service Mesh > Mesh.
- Нажмите Create Service Mesh.
- Выберите кластер и версию Istio для развертывания сервисной сетки. В расширенной конфигурации убедитесь, что архитектура сетки — single-cluster, и заполните параметры интерфейса для Elasticsearch и системы мониторинга. Вы можете выбрать существующую систему платформы или внешнюю систему.
- Если требуется высокая доступность, установите Pod anti-affinity в обязательный режим.
- Ресурсы компонентов могут использовать значения по умолчанию, но по мере роста масштабов сервисов в сетке компоненты потребуется масштабировать. Настройте политики оповещений для компонентов сетки, чтобы своевременно получать уведомления о необходимости масштабирования.
Для получения дополнительной информации смотрите Mesh Parameter Description
Примечание: Если кластер является кластером OpenShift, сетка автоматически обнаружит и развернёт компонент istio-cni по умолчанию.
Следующие шаги
- Включите Istio CNI, чтобы исключить необходимость в привилегированных init-контейнерах в каждом Pod.
- Включите Global Rate Limiting.
- Используйте инструмент Istioctl.
- Мониторьте компоненты сетки.
Описание параметров сетки
Глобальная конфигурация
Глобальная конфигурация сетки применяется ко всем кластерам, где развернута сетка.
| Параметр | Описание |
|---|---|
| Интерфейс с Elasticsearch | Platform: Интерфейс с плагином логирования Elasticsearch на любом кластере платформы. Выберите кластер, где расположен плагин логирования Elasticsearch. External: Интерфейс с внешним плагином логирования Elasticsearch. Пользователю необходимо настроить следующие параметры: Адрес доступа: адрес доступа к Elasticsearch, начинающийся с http:// или https://.Метод аутентификации: метод аутентификации для доступа к Elasticsearch. - Basic Auth: введите имя пользователя и пароль для проверки подлинности. - No Authentication: доступ без аутентификации. |
| Интерфейс с системой мониторинга | Platform: Интерфейс с плагином Prometheus или VictoriaMetrics в кластере. External: Интерфейс с Prometheus или VictoriaMetrics, предоставляемыми внешним плагином. Пользователю необходимо настроить следующие параметры: Адрес запроса данных: адрес запроса данных компонента мониторинга, начинающийся с http:// или https://.Метод аутентификации: метод аутентификации для доступа к системе мониторинга. - Basic Auth: введите имя пользователя и пароль для проверки подлинности. - No Authentication: доступ без аутентификации. Примечание: из-за невозможности плагина Prometheus агрегировать данные мониторинга из нескольких кластеров, сервисная сетка в этом кластере не может добавлять другие кластеры для формирования multi-cluster service mesh. |
Конфигурация на уровне кластера
Конфигурация на уровне кластера применяется только к выбранному кластеру.
| Параметр | Описание |
|---|---|
| Конфигурация Sidecar | Квота ресурсов: значение квоты ресурсов sidecar по умолчанию на уровне кластера. Может быть изменено в зависимости от реальных условий при инъекции sidecar для конкретных сервисов, но не может превышать максимальный лимит квоты контейнера пространства имён (LimitRange), в котором расположен sidecar. |
| Конфигурация трассировки | Частота выборки: значение частоты выборки трассировки sidecar по умолчанию на уровне кластера. |
| Конфигурация Redis | Должна быть настроена только при использовании функции Global Rate Limiting в плоскости данных. Для конкретных методов настройки смотрите раздел Enable Global Rate Limiting. |
| Политика повторных попыток HTTP | Количество повторных попыток: максимальное количество повторных попыток HTTP по умолчанию на уровне кластера. Примечание: значение Retry Count в политике маршрутизации сервиса Timeout and Retry переопределит это значение по умолчанию. |
Конфигурация компонентов
Примечание: Компоненты сетки развертываются в определённых пространствах имён кластера в виде Deployments. После успешного создания сетки вы можете просмотреть статус работы компонентов на вкладке Components или нажать на Component Name, чтобы перейти в пространство имён, где развернут компонент, на платформе контейнеров и просмотреть подробную информацию о Deployment работающего компонента.
| Параметр | Описание |
|---|---|
| Pod Anti-Affinity | Kubernetes будет планировать Pods компонентов на узлах, соответствующих настройкам Pod Anti-Affinity. Mandatory: на одном узле разрешён запуск только одного Pod одного и того же компонента. Preferred: на одном узле разрешён запуск нескольких Pod одного компонента. Kubernetes будет стараться равномерно распределять Pods компонента по доступным узлам согласно алгоритму планирования, но не гарантирует наличие Pod компонента на каждом узле. |
| Количество экземпляров | Ожидаемое количество Pod компонентов для запуска, устанавливается в соответствии с фактическим объёмом бизнес-запросов. |
| Квота ресурсов | Значение запроса ресурсов (CPU, памяти) (requests) для каждого контейнера компонента при создании, а также лимит (limits) доступных ресурсов для контейнера. Устанавливайте разумно в зависимости от фактического объёма бизнеса и количества экземпляров. |
| Узел развертывания | Узлы, на которых развернут компонент. При создании сетки Pods компонента могут быть запланированы только на выбранных узлах. |
| ELB | Huawei Cloud Elastic Load Balancer (ELB), используемый для обеспечения балансировки нагрузки для Istio Gateway в кластере CCE. Если выбранный кластер является кластером CCE, необходимо заполнить ELB ID и ELB Type для связывания с заранее подготовленным ELB для кластера. |
| Общие ресурсы | Общая квота ресурсов (CPU, памяти), необходимая для создания всех контейнерных экземпляров компонента при текущей конфигурации. При включённом автоскейлинге компонента учитывается максимальное количество экземпляров. |