Alauda Container Platform
Русский

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

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

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

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

ПараметрОписание
Load BalancerПрограммное или аппаратное устройство, которое распределяет сетевые запросы между доступными узлами в кластере. Используемый на платформе балансировщик нагрузки — это программный балансировщик уровня 7.
VIPВиртуальный IP-адрес (Virtual IP Address) — IP-адрес, который не соответствует конкретному компьютеру или конкретной сетевой карте. При использовании балансировщика нагрузки типа высокодоступности адрес доступа должен быть VIP.

Содержание

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

Высокая доступность 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. При enableLbSvc равном true будет создан внутренний сервис типа LoadBalancer для адреса доступа балансировщика нагрузки. lbSvcAnnotations — ссылка на конфигурацию аннотаций сервиса типа LoadBalancer.
  2. Ознакомьтесь с конфигурацией Network Mode ниже.
  3. Ознакомьтесь с методом распределения ресурсов ниже.
  4. Ознакомьтесь с назначенным проектом ниже.
  5. Ознакомьтесь с техническими характеристиками ниже.

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

  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

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

NOTE

Обновление балансировщика вызовет прерывание сервиса на 3–5 минут. Пожалуйста, выбирайте подходящее время для этой операции!

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

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

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

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

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

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

  5. Нажмите Update.

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

NOTE

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

  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
  1. Обязательно, указывает ALB-инстанс, к которому принадлежит этот Frontend.
  2. Формат $alb_name-$port.
  3. Формат $secret_ns/$secret_name.
  4. Протокол самого Frontend.
    • http|https|grpc|grpcs для прокси уровня 7.
    • tcp|udp для прокси уровня 4.
  5. Для прокси уровня 4 serviceGroup обязателен. Для уровня 7 serviceGroup опционален. При поступлении запроса ALB сначала пытается сопоставить его с правилами, связанными с этим Frontend. Если запрос не соответствует ни одному правилу, ALB перенаправляет его в дефолтный serviceGroup, указанный в конфигурации Frontend.
  6. Конфигурация weight применяется для алгоритмов планирования Round Robin и Weighted Round Robin.
NOTE

ALB слушает ingress и автоматически создаёт Frontend или Rule. Поле source определяется следующим образом:

  1. spec.source.type в настоящее время поддерживает только ingress.
  2. spec.source.name — имя ingress.
  3. spec.source.namespace — пространство имён ingress.

Создание портов слушателя (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 в правом верхнем углу страницы деталей, чтобы при необходимости обновить дефолтный маршрут или удалить порт слушателя.

NOTE

Если метод распределения ресурсов балансировщика — Port, удалять связанные порты слушателя в представлении Platform Management могут только администраторы.

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

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

NOTE

Правила переадресации нельзя добавлять для протоколов TCP и UDP.

Пример ресурса 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
  1. Обязательно, указывает Frontend, к которому принадлежит это правило.
  2. Обязательно, указывает ALB, к которому принадлежит это правило.
  3. Аналогично Frontend.
  4. Аналогично Frontend.
  5. Чем меньше число, тем выше приоритет.
  6. Аналогично Frontend.

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 просмотрите логи работы балансировщика с точки зрения контейнера.

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

NOTE

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

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

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

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

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

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

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

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

Просмотреть полную документацию в формате PDF