#Понимание 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 и др.) и преобразует их в ALB-специфичные DSL правила. 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-адрес и порт с узлом.

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

В режиме 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

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

• L4/L7 timeout
• Keepalive

#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

#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"

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

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

#Режим проекта

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

#Режим портового проекта

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

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

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

Чтобы понять, как работает 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, не входящих в Project.

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

• Настройка Load Balancer