#Настройка балансировщика нагрузки

Балансировщик нагрузки — это сервис, который распределяет трафик по контейнерным инстансам. Используя функциональность балансировки нагрузки, он автоматически распределяет входящий трафик для вычислительных компонентов и перенаправляет его на контейнерные инстансы этих компонентов. Балансировка нагрузки может повысить отказоустойчивость вычислительных компонентов, масштабировать внешнюю сервисную способность этих компонентов и улучшить доступность приложений.

Администраторы платформы могут создавать одноточечные или высокодоступные балансировщики нагрузки для любого кластера на платформе, а также централизованно управлять и распределять ресурсы балансировщиков нагрузки. Например, балансировка нагрузки может быть назначена проектам, обеспечивая использование балансировки только пользователями с соответствующими правами в проекте.

Пожалуйста, обратитесь к таблице ниже для объяснения связанных понятий в этом разделе.

#Предварительные требования

Высокая доступность Load Balancer требует наличия VIP. Пожалуйста, обратитесь к Настройка VIP.

#Пример ресурса ALB2 (CR)

# test-alb.yaml
apiVersion: crd.alauda.io/v2beta1
kind: ALB2
metadata:
  name: alb-demo
  namespace: cpaas-system
  annotations:
    cpaas.io/display-name: ""
spec:
  address: 192.168.66.215
  config:
    vip:
      enableLbSvc: false
      lbSvcAnnotations: {}
    networkMode: host
    enablePortProject: false
    nodeSelector:
      cpu-model.node.kubevirt.io/Nehalem: "true"
    projects:
      - ALL_ALL
    replicas: 1
    resources:
      limits:
        cpu: 200m
        memory: 256Mi
      requests:
        cpu: 200m
        memory: 256Mi
  type: nginx

#Создание балансировщика нагрузки через веб-консоль

1. Перейдите в Platform Management.

2. В левой боковой панели нажмите Network Management > Load Balancer.

3. Нажмите Create Load Balancer.

4. Следуйте инструкциям ниже для завершения настройки сети.

   Параметр	Описание
   Network Mode	Host Network Mode: На одном узле разрешается развертывать только один реплика балансировщика нагрузки, при этом несколько сервисов используют один ALB, что обеспечивает лучшую производительность сети. Container Network Mode: На одном узле можно развернуть несколько реплик балансировщика нагрузки, чтобы удовлетворить требования отдельных ALB для каждого сервиса, с немного меньшей производительностью сети.
   Service and Annotations (Alpha)	Service: При включении создаётся внутренний сервис типа LoadBalancer для адреса доступа балансировщика нагрузки. Перед использованием убедитесь, что текущий кластер поддерживает сервис типа LoadBalancer. Можно использовать встроенный сервис типа LoadBalancer платформы; при отключении необходимо настроить External Address Pool для балансировщика нагрузки. Annotations: Используются для объявления конфигурации или возможностей внутреннего маршрутизации типа LoadBalancer; подробности см. в Annotations for Internal LoadBalancer Type Routing.
   Access Address	Адрес доступа для балансировки нагрузки, то есть адрес сервиса инстанса балансировщика нагрузки. После успешного создания балансировщика к нему можно обращаться по этому адресу. В режиме host network mode заполните согласно реальным условиям; это может быть доменное имя или IP-адрес (внутренний IP, внешний IP, VIP). В режиме container network mode адрес будет получен автоматически.

5. Следуйте инструкциям ниже для завершения настройки ресурсов.

   Параметр	Описание
   Specification	Установите характеристики разумно в соответствии с бизнес-требованиями. Также можно обратиться к Как правильно распределять ресурсы CPU и памяти для справки.
   Deployment Type	Single Point: Контейнерная группа балансировщика нагрузки развёрнута на одном узле, что может привести к недоступности балансировщика при сбое машины. High Availability: Несколько контейнерных групп балансировщика нагрузки развёрнуты на соответствующем количестве узлов, обычно 3. Это удовлетворяет потребности балансировки при больших объёмах бизнеса и обеспечивает возможности аварийного восстановления.
   Replicas	Количество реплик — это количество контейнерных групп балансировщика нагрузки. Совет: Для обеспечения высокой доступности балансировщика рекомендуется количество реплик не менее 3.
   Node Labels	Фильтрация узлов по меткам для развертывания балансировщика нагрузки. Совет: Рекомендуется, чтобы количество узлов, удовлетворяющих требованиям, было больше количества реплик балансировщика. Метка с одинаковым ключом может выбрать только одну (если выбрано несколько, подходящих хостов не будет).
   Resource Allocation Method	Instance: Любой порт в диапазоне 1-65535, на котором может слушать инстанс балансировщика, может быть предоставлен для использования проектом. Port (Alpha): Можно выделять только порты в указанном диапазоне для использования проектом. Этот метод позволяет более тонко контролировать ресурсы при ограниченности портов.
   Assigned Project	При установке Resource Allocation Method в Instance балансировщик может быть выделен всем проектам, связанным с текущим кластером, или указанным проектам. Во всех выделенных проектах все Pod во всех пространствах имён могут получать запросы, распределяемые балансировщиком. Все проекты: Выделяет балансировщик для использования всеми проектами, связанными с текущим кластером. Указанные проекты (Alpha): Нажмите выпадающий список под Specified Projects и отметьте чекбоксы слева от названий проектов для выбора одного или нескольких проектов, выделяя балансировщик для использования этими проектами. Совет: Можно фильтровать проекты, вводя их имена в выпадающем списке. Без выделения (Alpha): Временно не выделяет ни один проект. После создания балансировщика можно использовать операцию Update Project для обновления параметров выделения проекта. При установке Resource Allocation Method в Port этот пункт не нужно настраивать. Порты выделяются вручную после создания балансировщика.

6. Нажмите Create. Процесс создания займет некоторое время, пожалуйста, подождите.

#Создание балансировщика нагрузки через CLI

kubectl apply -f test-alb.yaml -n cpaas-system

#Обновление балансировщика нагрузки через веб-консоль

1. Перейдите в Platform Management.

2. В левой навигационной панели нажмите Network Management > Load Balancer.

3. Нажмите ⋮ > Update.

4. Обновите сетевые и ресурсные настройки по необходимости.

   • Устанавливайте характеристики разумно в соответствии с бизнес-требованиями. Также можно обратиться к Как правильно распределять ресурсы CPU и памяти для справки.

   • Внутренняя маршрутизация поддерживает обновление только из состояния Disabled в состояние Enabled.

5. Нажмите Update.

#Удаление балансировщика нагрузки через веб-консоль

1. Перейдите в Platform Management.

2. В левой навигационной панели нажмите Network Management > Load Balancer.

3. Нажмите ⋮ > Delete и подтвердите.

#Удаление балансировщика нагрузки через CLI

kubectl delete alb2 test-alb -n cpaas-system

#Настройка портов слушателя (Frontend)

Балансировщик нагрузки поддерживает приём клиентских соединений через порты слушателя и соответствующие протоколы, включая HTTPS, HTTP, gRPC, TCP и UDP.

#Предварительные требования

Если необходимо добавить HTTPS-порт слушателя, следует также обратиться к администратору для назначения TLS-сертификата текущему проекту для шифрования.

#Пример ресурса Frontend (CR)

# alb-frontend-demo.yaml
apiVersion: crd.alauda.io/v1
kind: Frontend
metadata:
  labels:
    alb2.cpaas.io/name: alb-demo
  name: alb-demo-00080
  namespace: cpaas-system
spec:
  backendProtocol: "http"
  certificate_name: ""
  port: 80
  protocol: http
  serviceGroup:
    services:
      - name: hello-world
        namespace: default
        port: 80
        weight: 100

#Создание портов слушателя (Frontend) через веб-консоль

1. Перейдите в Container Platform.

2. В левой навигационной панели нажмите Network > Load Balancing.

3. Нажмите на имя балансировщика нагрузки для перехода на страницу деталей.

4. Нажмите Add Listener Port.

5. Ознакомьтесь с инструкциями ниже для настройки параметров.

   Параметр	Описание
   Protocol	Поддерживаемые протоколы: HTTPS, HTTP, gRPC, TCP и UDP. При выборе HTTPS необходимо добавить сертификат; для gRPC добавление сертификата опционально. Примечание: При выборе протокола gRPC протокол бэкенда по умолчанию — gRPC, при этом не поддерживается сессия. Если для gRPC задан сертификат, балансировщик снимет сертификат gRPC и перенаправит незашифрованный трафик gRPC на бэкенд. При использовании кластера Google GKE балансировщик одного типа контейнерной сети не может одновременно иметь протоколы слушателя TCP и UDP.
   Internal Routing Group	- При выборе алгоритма балансировки Round Robin (RR) трафик распределяется по портам внутренней маршрутизации в порядке группы маршрутов. - При выборе алгоритма Weighted Round Robin (WRR) внутренние маршруты с большим значением веса имеют большую вероятность выбора; трафик распределяется по портам внутренней маршрутизации согласно рассчитанной вероятности на основе настроенного weight. Совет: Вероятность рассчитывается как отношение текущего значения веса к сумме всех весов.
   Session Persistence	Всегда перенаправляет определённые запросы на бэкенд-сервисы, соответствующие вышеуказанной внутренней группе маршрутов. Определённые запросы включают (выберите один): Хэш исходного адреса: все запросы с одного IP-адреса. Примечание: В публичных облаках исходный адрес часто меняется, что может привести к тому, что запросы от одного клиента будут иметь разные IP-адреса в разное время, и метод хэширования по адресу не даст ожидаемого результата. Ключ cookie: запросы, содержащие указанный cookie. Имя заголовка: запросы, содержащие указанный заголовок.
   Backend Protocol	Протокол, используемый для передачи трафика на бэкенд-сервисы. Например, при передаче на Kubernetes или dex-сервисы бэкенда следует выбрать протокол HTTPS.

6. Нажмите OK.

#Создание портов слушателя (Frontend) через CLI

kubectl apply -f alb-frontend-demo.yaml -n cpaas-system

#Последующие действия

Для трафика с портов HTTP, gRPC и HTTPS, помимо дефолтной внутренней группы маршрутов, можно настроить более разнообразные правила сопоставления бэкенд-сервисов rules. Балансировщик сначала пытается сопоставить соответствующий бэкенд согласно установленным правилам; если совпадений нет, то направляет трафик на бэкенд из указанной внутренней группы маршрутов.

#Связанные операции

Вы можете нажать значок ⋮ справа на странице списка или кнопку Actions в правом верхнем углу страницы деталей, чтобы при необходимости обновить дефолтный маршрут или удалить порт слушателя.

#Настройка правил

Добавление правил переадресации для портов слушателя протоколов HTTPS, HTTP и gRPC. Балансировщик будет сопоставлять бэкенд-сервисы на основе этих правил.

#Пример ресурса Rule (CR)

# alb-rule-demo.yaml
apiVersion: crd.alauda.io/v1
kind: Rule
metadata:
  labels:
    alb2.cpaas.io/frontend: alb-demo-00080
    alb2.cpaas.io/name: alb-demo
  name: alb-demo-00080-test
  namespace: cpaas-system
spec:
  backendProtocol: ""
  certificate_name: ""
  dslx:
    - type: METHOD
      values:
        - - EQ
          - POST
    - type: URL
      values:
        - - STARTS_WITH
          - /app-a
        - - STARTS_WITH
          - /app-b
    - type: PARAM
      key: group
      values:
        - - EQ
          - vip
    - type: HOST
      values:
        - - ENDS_WITH
          - .app.com
    - type: HEADER
      key: LOCATION
      values:
        - - IN
          - east-1
          - east-2
    - type: COOKIE
      key: uid
      values:
        - - EXIST
    - type: SRC_IP
      values:
        - - RANGE
          - "1.1.1.1"
          - "1.1.1.100"
  enableCORS: false
  priority: 4
  serviceGroup:
    services:
      - name: hello-world
        namespace: default
        port: 80
        weight: 100

#dslx

dslx — это предметно-ориентированный язык, используемый для описания критериев сопоставления.

Например, следующее правило соответствует запросу, который удовлетворяет всем нижеперечисленным условиям:

• URL начинается с /app-a или /app-b
• метод POST
• параметр URL с ключом group равен vip
• хост соответствует *.app.com
• заголовок LOCATION равен east-1 или east-2
• присутствует cookie с именем uid
• исходные IP-адреса находятся в диапазоне 1.1.1.1-1.1.1.100

dslx:
  - type: METHOD
    values:
      - - EQ
        - POST
  - type: URL
    values:
      - - STARTS_WITH
        - /app-a
      - - STARTS_WITH
        - /app-b
  - type: PARAM
    key: group
    values:
      - - EQ
        - vip
  - type: HOST
    values:
      - - ENDS_WITH
        - .app.com
  - type: HEADER
    key: LOCATION
    values:
      - - IN
        - east-1
        - east-2
  - type: COOKIE
    key: uid
    values:
      - - EXIST
  - type: SRC_IP
    values:
      - - RANGE
        - "1.1.1.1"
        - "1.1.1.100"

#Создание правила через веб-консоль

1. Перейдите в Container Platform.

2. В левой навигационной панели нажмите Network > Load Balancing.

3. Нажмите на имя балансировщика нагрузки.

4. Нажмите на имя порта слушателя.

5. Нажмите Add Rule.

6. Ознакомьтесь с описаниями ниже для настройки параметров.

   Параметр	Описание
   Internal Route Group	- При выборе алгоритма балансировки Round Robin (RR) трафик распределяется по портам внутренней маршрутизации в порядке группы маршрутов. - При выборе алгоритма Weighted Round Robin (WRR) внутренние маршруты с большим значением веса имеют большую вероятность выбора; трафик распределяется по портам внутренней маршрутизации согласно рассчитанной вероятности на основе настроенного weight. Совет: Вероятность рассчитывается как отношение текущего значения веса к сумме всех весов.
   Rule	Критерии сопоставления балансировщика с бэкенд-сервисами, включая индикаторы правил и их значения. Отношение между разными индикаторами — «и». Доменное имя: поддерживается добавление wildcard-доменов и точных доменных имён. При равенстве приоритетов для одного правила, если существуют и wildcard, и точные доменные правила, приоритет имеет точное доменное правило. URL: RegEx — регулярные выражения URL, начинающиеся с /; StartsWith — префиксы URL, начинающиеся с /. IP: Equal — конкретный IP-адрес; Range — диапазон IP-адресов. Заголовок: кроме ключа заголовка, необходимо задать правило сопоставления. Equal — конкретное значение заголовка; Range — диапазон значений заголовка; RegEx — регулярное выражение заголовка. Cookie: кроме ключа cookie, необходимо задать правило сопоставления. Equal — конкретное значение cookie. URL Param: в правилах сопоставления Equal — конкретный параметр URL; Range — диапазон параметров URL. Service Name: имя сервиса, использующего протокол gRPC. При использовании gRPC можно настроить этот параметр, чтобы трафик перенаправлялся на соответствующий сервис по имени, например: /helloworld.Greeter.
   Session Persistence	Всегда перенаправляет определённые запросы на бэкенд-сервисы, соответствующие внутренней группе маршрутов. Определённые запросы включают (выберите один): Хэш исходного адреса: все запросы с одного IP-адреса. Ключ cookie: запросы, содержащие указанный cookie. Имя заголовка: запросы, содержащие указанный заголовок.
   URL Rewrite	Перезаписывает обращаемый адрес на адрес бэкенд-сервиса платформы. Для работы требуется настройка правила URL с индикатором StartsWith, а адрес перезаписи (rewrite-target) должен начинаться с /. Например: при настройке домена bar.example.com и начального пути URL /, включении функции URL Rewrite и установке адреса перезаписи в /test обращение к bar.example.com будет переписано в bar.example.com/test.
   Backend Protocol	Протокол, используемый для передачи трафика на бэкенд-сервис. Например, при передаче на Kubernetes или dex-сервисы бэкенда следует выбрать протокол HTTPS.
   Redirection	Перенаправляет трафик на новый адрес, а не на бэкенд-сервисы внутренней группы маршрутов. Например: при обновлении страницы по исходному адресу, чтобы избежать ошибок 404 или 503, трафик можно перенаправить на новый адрес. HTTP Status Code: код состояния, который браузер покажет пользователю перед перенаправлением. Redirect Address: при вводе относительного адреса (например, /index.html) трафик будет направлен на адрес балансировщика/index.html; при вводе абсолютного адреса (например, https://www.example.com) трафик будет направлен на указанный адрес.
   Rule Priority	Приоритет сопоставления правил: 10 уровней от 1 до 10, где 1 — самый высокий приоритет, по умолчанию 5. Если одновременно удовлетворяются несколько правил, выбирается правило с более высоким приоритетом; при равенстве приоритетов применяется правило по умолчанию.
   Cross-Origin Resource Sharing (CORS)	CORS (Cross-origin resource sharing) — механизм, использующий дополнительные HTTP-заголовки, чтобы указать браузеру, что веб-приложение с одного источника (домена) может получить доступ к ресурсам с другого источника. При запросе ресурса с сервера другого домена, протокола или порта инициируется кросс-доменный HTTP-запрос.
   Allowed Origins	Указывает разрешённые источники доступа. *: разрешает запросы с любого источника. Доменное имя: разрешает запросы с указанного домена.
   Allowed Headers	Указывает HTTP-заголовки, разрешённые в CORS, чтобы избежать лишних предварительных запросов и повысить эффективность. Примеры: Примечание: Другие часто используемые или кастомные заголовки не перечислены; заполняйте по необходимости. Origin: указывает источник запроса, то есть домен, отправляющий запрос. Authorization: указывает данные авторизации, например Basic Authentication или Token. Content-Type: указывает тип содержимого запроса/ответа, например application/json, application/x-www-form-urlencoded и др. Accept: указывает типы содержимого, которые клиент может принимать, обычно для получения определённого типа ответа.

7. Нажмите Add.

#Создание правила через CLI

kubectl apply -f alb-rule-demo.yaml -n cpaas-system

#Логи и мониторинг

Сочетая визуализированные логи и данные мониторинга, можно быстро выявлять и устранять проблемы или сбои балансировщика нагрузки.

#Просмотр логов

1. Перейдите в Platform Management.

2. В левой навигационной панели нажмите Network Management > Load Balancer.

3. Нажмите на Load Balancer Name.

4. Во вкладке Logs просмотрите логи работы балансировщика с точки зрения контейнера.

#Метрики мониторинга

1. Перейдите в Platform Management.

2. В левой навигационной панели нажмите Network Management > Load Balancer.

3. Нажмите на Load Balancer Name.

4. Во вкладке Monitoring просмотрите тренды метрик балансировщика с точки зрения узла.

   • Usage Rate: текущая загрузка CPU и памяти балансировщика на данном узле.

   • Throughput: общий входящий и исходящий трафик инстанса балансировщика.

#Дополнительные ресурсы

• ALB Monitoring