#了解 ALB

ALB（Another Load Balancer）是一个由 OpenResty 驱动的 Kubernetes Gateway，凝聚了 Alauda 多年的生产实践经验。

#核心组件

• ALB Operator：负责管理 ALB 实例生命周期的 operator。它会监视 ALB CR，并为不同租户创建/更新实例。
• ALB Instance：一个 ALB 实例包括作为数据平面的 OpenResty，以及作为控制平面的 Go controller。Go controller 会监控各种 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"  # the ip address of node where alb been deployed
    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: 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/其他协议请求，最终请求会到达 ALB 的一个 pod，该 pod（一个 ALB 实例）开始处理此请求。
2. 该 ALB 实例找到一条能够匹配此请求的规则。
3. 如有需要，根据该规则修改/重定向/重写请求。
4. 从该规则配置的 services 中找到并选择一个 pod IP，然后将请求转发到该 pod。

#Ingress

Ingress 是 Kubernetes 中的一个资源，用于描述某个请求应发送到哪个 service。

#Ingress Controller

一种理解 Ingress 资源并将请求代理到 service 的程序。

#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 实例独立处理请求，但所有实例共享属于同一个 ALB 的 Frontend（FT）、Rule 及其他配置。

#ALB-Operator

ALB-Operator 是集群中默认部署的一个组件，是用于 ALB 的 operator。它会根据 ALB 资源为每个 ALB 创建/更新/删除 Deployment 及其他相关资源。

#Frontend（缩写：FT）

FT 是 ALB 自身定义的一个资源。 它用于表示 ALB 实例的监听端口。

FT 可以由 ALB-Leader 创建，也可以由用户手动创建。

ALB-Leader 创建 FT 的场景：

1. 如果 Ingress 有证书，则创建 FT 443（HTTPS）。
2. 如果 Ingress 没有证书，则创建 FT 80（HTTP）。

#RULE

RULE 是 ALB 自身定义的一个资源。 它与 Ingress 具有相同的角色，但更加具体。 一个 RULE 会唯一关联到一个 FT。

RULE 可以由 ALB-Leader 创建，也可以由用户手动创建。

ALB-Leader 创建 RULE 的场景：

1. 将 Ingress 同步为 RULE。

#ALB Leader

在多个 ALB 实例中，会选举出一个作为 leader。 leader 负责：

1. 将 Ingress 转换为 Rules。 我们会为 Ingress 中的每个 path 创建 Rule。
2. 创建 Ingress 所需的 FT。 例如，如果 Ingress 有证书，则创建 FT 443（HTTPS）；如果 Ingress 没有证书，则创建 FT 80（HTTP）。

#Project

从 ALB 的视角来看，Project 是一组 namespaces。

你可以在一个 ALB 中配置一个或多个 Project。 当 ALB Leader 将 Ingress 转换为 Rules 时，它会忽略不属于该 Project 的 namespaces 中的 Ingress。

#其他资源：

• 配置负载均衡器