Создание сервисной сетки
В этом документе объясняется, как создать сервисную сетку в одном кластере. Перед началом работы убедитесь, что вы знакомы со следующими темами:
- Модели развертывания сетки: выберите модель развертывания сетки, которая соответствует вашим требованиям.
- Описание компонентов сетки: понимайте роли компонентов сетки и подготовьте необходимые ресурсы 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 в значение mandatory.
- Ресурсы компонентов могут использовать значения по умолчанию, но по мере роста масштабов сервисов в сетке компоненты потребуется масштабировать. Настройте политики оповещений для компонентов сетки, чтобы своевременно получать уведомления о необходимости масштабирования.
Для получения дополнительной информации смотрите 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 сервисной сетки. |
Конфигурация по кластеру
Конфигурация по кластеру применяется только к выбранному кластеру.
| Параметр | Описание |
|---|---|
| Конфигурация 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, чтобы перейти в пространство имён, где развернут компонент на Container Platform, и просмотреть подробную информацию о 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, памяти), необходимая для создания всех контейнерных экземпляров компонента при текущей конфигурации. При включённом автоскейлинге компонента учитывается максимальное количество экземпляров. |