• Русский
  • Понимание ALB

    ALB (Another Load Balancer) — это Kubernetes Gateway на базе OpenResty с многолетним опытом эксплуатации от Alauda.

    Основные компоненты

    • ALB Operator: оператор, управляющий жизненным циклом экземпляров ALB. Он отвечает за наблюдение за CR ALB и создание, обновление экземпляров ALB для разных арендаторов.
    • ALB Instance: экземпляр ALB включает Openresty, который выступает в роли data plane, и контроллер на Go в роли control plane. Контроллер на Go отслеживает различные CR (Ingress, Gateway, Rule и др.) и преобразует их в DSL-правила, специфичные для ALB. OpenResty затем использует эти DSL-правила для сопоставления и обработки входящих запросов.

    Быстрый старт

    Развертывание ALB Operator

    1. Создайте кластер.
    2.  helm repo add alb https://alauda.github.io/alb/;helm repo update;helm search repo|grep alb
    3.  helm install alb-operator alb/alauda-alb2

    Развертывание экземпляра ALB

    cat <<EOF | kubectl apply -f -
    apiVersion: crd.alauda.io/v2beta1
    kind: ALB2
    metadata:
        name: alb-demo
        namespace: kube-system
    spec:
        address: "172.20.0.5"  # IP-адрес узла, на котором развернут alb
        type: "nginx"
        config:
            networkMode: host
            loadbalancerName: alb-demo
            projects:
            - ALL_ALL
            replicas: 1
    EOF

    Запуск демонстрационного приложения

    cat <<EOF | kubectl apply -f -
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello-world
      labels:
        k8s-app: hello-world
    spec:
      replicas: 1
      selector:
        matchLabels:
          k8s-app: hello-world
      template:
        metadata:
          labels:
            k8s-app: hello-world
        spec:
          terminationGracePeriodSeconds: 60
          containers:
          - name: hello-world
            image: docker.io/crccheck/hello-world:latest
            imagePullPolicy: IfNotPresent
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: hello-world
      labels:
        k8s-app: hello-world
    spec:
      ports:
      - name: http
        port: 80
        targetPort: 8000
      selector:
        k8s-app: hello-world
    ---
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: hello-world
    spec:
      rules:
      - http:
          paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: hello-world
                port:
                  number: 80
    EOF

    Теперь вы можете получить доступ к приложению через curl http://${ip}

    Общие понятия ALB

    Ниже определены общие понятия в ALB.

    Auth

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

    Подробнее об ALB Auth.

    Network Mode

    Экземпляр ALB может быть развернут в двух режимах: host network mode и container network mode.

    Host Network Mode

    Использует сетевой стек узла напрямую, разделяя IP-адрес и порт с узлом.

    В этом режиме экземпляр балансировщика нагрузки напрямую привязывается к порту узла, без проброса портов или иной контейнерной сетевой инкапсуляции.

    NOTE

    Чтобы избежать конфликтов портов, на одном узле разрешается развертывать только один экземпляр ALB.

    В режиме host-network экземпляр ALB по умолчанию слушает все сетевые интерфейсы узла.

    Преимущества:
    1. Лучшее сетевое быстродействие.
    2. Доступ по IP-адресу узла.
    Недостатки:
    1. На одном узле разрешён только один экземпляр ALB.
    2. Возможны конфликты портов с другими процессами.

    Container Network Mode

    В отличие от host network mode, container network mode разворачивает ALB с использованием контейнерной сети.

    Преимущества:
    1. Поддержка развертывания нескольких экземпляров ALB на одном узле.
    2. ALB интегрируется с MetalLB, который может предоставлять VIP для ALB.
    3. Порты не конфликтуют с другими процессами.
    Недостатки:
    1. Немного ниже производительность.
    2. Доступ к ALB осуществляется через сервис LoadBalancer.

    Frontend

    Определён ресурс frontend (сокращённо ft), который используется для объявления всех портов, на которых должен слушать alb.

    Каждый frontend соответствует порту прослушивания на балансировщике нагрузки (LB). Frontend связывается с ALB через метки.

    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 для L7 прокси.
      • tcp|udp для L4 прокси.
    5. Для L4 прокси serviceGroup обязателен. Для L7 прокси 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 — namespace ingress.

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

    Rules

    Определён ресурс rule, который описывает, как экземпляр alb должен обрабатывать запросы 7-го уровня.

    С помощью Rule можно настроить сложные шаблоны сопоставления и распределения трафика. При поступлении трафика он сопоставляется с внутренними правилами и выполняется соответствующая маршрутизация, а также предоставляются дополнительные функции, такие как cors, url rewrite и др.

    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: kube-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
    • host заканчивается на *.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"

    Изоляция проектов

    Для rule по умолчанию применяется изоляция по проектам: каждый пользователь видит только правила своего проекта.

    Project Mode

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

    Port Project Mode

    Порт ALB может принадлежать разным проектам. Этот режим называется Port Project Mode. Администратор задаёт диапазон портов для каждого проекта. Пользователи проекта могут создавать порты только в пределах этого диапазона и видеть только эти порты.

    Взаимосвязь между ALB, ALB Instance, Frontend/FT, Rule, Ingress и Project

    LoadBalancer — ключевой компонент современных cloud-native архитектур, выступающий в роли интеллектуального маршрутизатора и балансировщика нагрузки.

    Чтобы понять, как работает ALB в Kubernetes кластере, нужно разобраться в нескольких основных понятиях и их взаимосвязях:

    • Сам ALB
    • Frontend (FT)
    • Rules
    • Ресурсы Ingress
    • Проекты

    Эти компоненты работают вместе, обеспечивая гибкое и мощное управление трафиком.

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

    В цепочке вызова запросов:

    1. Клиент отправляет HTTP/HTTPS/другой протокол запрос, который в итоге попадает на pod ALB, и этот pod (экземпляр ALB) начинает обрабатывать запрос.
    2. Экземпляр ALB находит правило, которое может сопоставиться с этим запросом.
    3. При необходимости изменяет/перенаправляет/переписывает запрос согласно правилу.
    4. Находит и выбирает IP pod из сервисов, указанных в правиле, и перенаправляет запрос на pod.

    Ingress

    Ingress — ресурс в Kubernetes, описывающий, какой запрос должен быть направлен в какой сервис.

    Ingress Controller

    Программа, которая понимает ресурс Ingress и проксирует запросы в сервис.

    ALB

    ALB — это Ingress controller.

    В Kubernetes кластере мы используем ресурс alb2 для управления ALB. Вы можете использовать kubectl get alb2 -A для просмотра всех ALB в кластере.

    ALB создаются пользователями вручную. Каждый ALB имеет свой IngressClass. При создании Ingress можно указать поле .spec.ingressClassName, чтобы указать, какой Ingress controller должен обрабатывать этот Ingress.

    ALB Instance

    ALB также представляет собой Deployment (набор pod) в кластере. Каждый pod называется экземпляром ALB.

    Каждый экземпляр ALB обрабатывает запросы независимо, но все экземпляры разделяют Frontend (FT), Rule и другие конфигурации, принадлежащие одному ALB.

    ALB-Operator

    ALB-Operator — компонент по умолчанию, развернутый в кластере, оператор для ALB. Он создаёт/обновляет/удаляет Deployment и другие связанные ресурсы для каждого ALB согласно ресурсу ALB.

    Frontend (сокращённо FT)

    FT — ресурс, определённый самим ALB. Он используется для представления портов прослушивания экземпляра ALB.

    FT может создаваться ALB-Leader или пользователем вручную.

    Случаи создания FT ALB-Leader:

    1. Если у Ingress есть сертификат, создаётся FT 443 (HTTPS).
    2. Если у Ingress нет сертификата, создаётся FT 80 (HTTP).

    RULE

    RULE — ресурс, определённый самим ALB. Он выполняет ту же роль, что и Ingress, но более специфичен. RULE уникально связан с FT.

    RULE может создаваться ALB-Leader или пользователем вручную.

    Случаи создания RULE ALB-Leader:

    1. Синхронизация Ingress в RULE.

    ALB Leader

    Из нескольких экземпляров ALB выбирается один лидер. Лидер отвечает за:

    1. Преобразование Ingress в Rules. Для каждого пути в Ingress создаётся Rule.
    2. Создание FT, необходимых для Ingress. Например, если у Ingress есть сертификат, создаётся FT 443 (HTTPS), если нет — FT 80 (HTTP).

    Project

    С точки зрения ALB, Project — это набор namespace.

    В ALB можно настроить один или несколько Projects. При преобразовании Ingress в Rules ALB Leader игнорирует Ingress в namespace, не принадлежащих проекту.

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