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

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

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

Ниже приведена таблица с пояснениями к связанным понятиям в этом разделе.

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

Для высокой доступности балансировщика нагрузки требуется VIP. См. Configure 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. Перейдите в Управление платформой.

2. В левой боковой панели нажмите Управление сетью > Балансировщик нагрузки.

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

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

   Параметр	Описание
   Режим сети	Режим сети хоста: На одном узле допускается развертывание только одного экземпляра балансировщика нагрузки, при этом несколько сервисов используют один ALB, что обеспечивает более высокую производительность сети. Режим контейнерной сети: На одном узле можно развернуть несколько экземпляров балансировщика нагрузки, чтобы удовлетворить требования к отдельным ALB для каждого сервиса, при несколько более низкой производительности сети.
   Service и аннотации (Alpha)	Service: При включении будет создан внутренний service типа LoadBalancer для адреса доступа балансировщика нагрузки. Перед использованием убедитесь, что текущий кластер поддерживает service типа LoadBalancer. Вы можете использовать встроенный в платформу service типа LoadBalancer; если функция отключена, для балансировщика нагрузки необходимо настроить Пул внешних адресов. Аннотации: Используются для объявления конфигурации или возможностей маршрутизации внутреннего LoadBalancer типа; подробности см. в Аннотации для маршрутизации внутреннего типа LoadBalancer.
   Адрес доступа	Адрес доступа к балансировке нагрузки, то есть адрес сервиса экземпляра балансировщика нагрузки. После успешного создания балансировщика нагрузки доступ к нему осуществляется по этому адресу. В режиме сети хоста заполните это поле в соответствии с фактическими условиями; это может быть доменное имя или IP-адрес (внутренний IP, внешний IP, VIP). В режиме контейнерной сети адрес будет получен автоматически.

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

   Параметр	Описание
   Спецификация	Устанавливайте спецификацию разумно, исходя из бизнес-потребностей. Для справки также можно обратиться к материалу Как правильно распределять ресурсы CPU и памяти.
   Тип развертывания	Одна точка: группа контейнеров балансировщика нагрузки развертывается на одном узле, что может привести к риску недоступности балансировщика при отказе оборудования. Высокая доступность: несколько групп контейнеров балансировщика нагрузки развертываются на соответствующем количестве узлов, обычно 3. Это удовлетворяет потребности в балансировке нагрузки для больших объемов бизнеса и обеспечивает возможности аварийного восстановления.
   Реплики	Количество реплик — это количество групп контейнеров балансировщика нагрузки. Совет: Чтобы обеспечить высокую доступность балансировщика нагрузки, рекомендуется, чтобы количество реплик было не менее 3.
   Метки узлов	Фильтруйте узлы по меткам для развертывания балансировщика нагрузки. Совет: Рекомендуется, чтобы количество узлов, соответствующих требованиям, было больше количества реплик балансировщика нагрузки. Метка с одинаковым ключом может быть выбрана только одна (если выбрано несколько, подходящие узлы будут недоступны).
   Метод распределения ресурсов	Экземпляр: Для использования проекта можно предоставить любой порт в диапазоне 1–65535, на котором может прослушивать экземпляр балансировщика нагрузки. Порт (Alpha): Для использования проекта можно распределять только порты в указанном диапазоне. Этот метод позволяет более точно контролировать ресурсы, когда ресурсы портов ограничены.
   Назначенный проект	Когда для Метода распределения ресурсов задано значение Экземпляр, балансировщик нагрузки можно распределить для всех проектов, связанных с текущим кластером, или для указанных проектов. В распределенных проектах все Pods во всех пространствах имен могут получать запросы, распределяемые балансировщиком нагрузки. Все проекты: распределяет балансировщик нагрузки для использования всеми проектами, связанными с текущим кластером. Указанные проекты (Alpha): нажмите раскрывающийся список в разделе Указанные проекты и отметьте флажком слева от имени проекта один или несколько проектов, чтобы распределить балансировщик нагрузки для использования этими указанными проектами. Совет: Вы можете фильтровать проекты, вводя их имена в раскрывающемся списке. Без распределения (Alpha): временно не распределяет ни один проект. После создания балансировщика нагрузки вы можете использовать операцию Обновить проект для изменения параметров назначенных проектов для созданного балансировщика нагрузки. Когда для Метода распределения ресурсов задано значение Порт, этот пункт настраивать не требуется. После создания балансировщика нагрузки назначьте информацию о портах вручную.

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

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

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

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

1. Перейдите в Управление платформой.

2. В левой панели навигации нажмите Управление сетью > Балансировщик нагрузки.

3. Нажмите ⋮ > Обновить.

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

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

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

5. Нажмите Обновить.

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

1. Перейдите в Управление платформой.

2. В левой панели навигации нажмите Управление сетью > Балансировщик нагрузки.

3. Нажмите ⋮ > Удалить и подтвердите действие.

#Удаление балансировщика нагрузки через 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. Перейдите в Платформа контейнеров.

2. В левой панели навигации нажмите Сеть > Балансировка нагрузки.

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

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

5. Для настройки соответствующих параметров воспользуйтесь приведенными ниже инструкциями.

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

6. Нажмите ОК.

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

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

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

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

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

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

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

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

#Пример пользовательского ресурса 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
• method — post
• параметр url group равен vip
• host — *.app.com
• значение header 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"

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

1. Перейдите в Платформа контейнеров.

2. В левой панели навигации нажмите Сеть > Балансировка нагрузки.

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

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

5. Нажмите Добавить правило.

6. Для настройки соответствующих параметров воспользуйтесь приведенными ниже описаниями.

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

7. Нажмите Добавить.

#Создание Rule через CLI

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

#Журналы и мониторинг

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

#Просмотр журналов

1. Перейдите в Управление платформой.

2. В левой панели навигации нажмите Управление сетью > Балансировщик нагрузки.

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

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

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

1. Перейдите в Управление платформой.

2. В левой панели навигации нажмите Управление сетью > Балансировщик нагрузки.

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

4. На вкладке Мониторинг просмотрите информацию о тенденции метрик балансировщика нагрузки с точки зрения узла.

   • Коэффициент использования: фактическое использование CPU и памяти балансировщиком нагрузки на текущем узле.

   • Пропускная способность: общий входящий и исходящий трафик экземпляра балансировщика нагрузки.

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

• ALB Monitoring