#Понимание ALB

ALB (Another Load Balancer) — это Kubernetes Gateway, основанный на OpenResty, с многолетним опытом эксплуатации в продакшене от Alauda.

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

• ALB Operator: оператор, управляющий жизненным циклом экземпляров ALB. Он отслеживает CR 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 Instance, Frontend/FT, Rule, Ingress и Project

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

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

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

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

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

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

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-ов.

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

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

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