#Configure ALB

#ALB

ALB is a custom resource that represents a load balancer. The alb-operator, which is embedded by default in all clusters, watches for create/update/delete operations on ALB resources and creates corresponding deployments and services in response.

For each ALB, a corresponding Deployment watches all Frontends and Rules attached to that ALB and routes requests to backends based on those configurations.

#Prerequisites

The high availability of the Load Balancer requires a VIP. Please refer to Configure VIP.

#Configure ALB

There are three parts to an ALB configuration.

# test-alb.yaml
apiVersion: crd.alauda.io/v2beta1
kind: ALB2
metadata:
  name: alb-demo
  namespace: cpaas-system
spec:
  address: 192.168.66.215
  config:
    vip:
      enableLbSvc: false
      lbSvcAnnotations: {}
    networkMode: host
    nodeSelector:
      cpu-model.node.kubevirt.io/Nehalem: 'true'
    replicas: 1
    resources:
      alb:
        limits:
          cpu: 200m
          memory: 256Mi
        requests:
          cpu: 200m
          memory: 256Mi
      limits:
        cpu: 200m
        memory: 256Mi
      requests:
        cpu: 200m
        memory: 256Mi
    projects:
      - ALL_ALL
  type: nginx

#Resource-Related Configuration

resource related field describes the deployment configuration for the alb.

#Networking Configuration

Networking fields describe how to access the ALB. For example, in host mode, alb will use hostnetwork, and you can access the ALB via the node IP.

#project configuration

Adding an ALB to a project means:

1. In the web UI, only users in the given project can find and configure this ALB.
2. This ALB will handle ingress resources belonging to this project. Please refer to ingress-sync.
3. In the web UI, rules created in project X cannot be found or configured under project Y.

If you enable port project and assign a port range to a project, this means:

1. You cannot create ports that do not belong to the port range assigned to the project.

#tweak configuration

there are some global config which can be tweaked in alb cr.

• Bind NIC
• Ingress sync

#Operation On ALB

#Creating

#Using the web console.

Some common configuration is exposed in the web UI. Follow these steps to create a load balancer:

1. Navigate to Administrator.
2. In the left sidebar, click on Network Management > Load Balancer.
3. Click on Create Load Balancer.

Each input item in the web UI corresponds to a field of the CR:

#Using the CLI.

kubectl apply -f test-alb.yaml -n cpaas-system

#Update

#Using the web console

1. Enter Administrator.

2. In the left navigation bar, click Network Management > Load Balancer.

3. Click ⋮ > Update.

4. Update the network and resource configuration as needed.

   • Please set specifications reasonably according to business needs. You can also refer to the relevant How to properly allocate CPU and memory resources for guidance.

   • Internal routing only supports updating from Disabled state to Enabled state.

5. Click Update.

#Delete

#Using the web console

1. Enter Administrator.

2. In the left navigation bar, click Network Management > Load Balancer.

3. Click ⋮ > Delete, and confirm.

#Using the CLI

kubectl delete alb2 alb-demo -n cpaas-system

#Frontend

Frontend is a custom resource that defines the listener port and protocol for an ALB. Supported protocols: L7 (http|https|grpc|grpcs) and L4 (tcp|udp).

• In L4 Proxy use frontend to configure backend service directly.
• In L7 Proxy use frontend to configure listener ports, and use rule to configure backend service.

If you need to add an HTTPS listener port, you should also contact the administrator to assign a TLS certificate to the current project for encryption.

#Prerequisites

Create a ALB first.

#Configure Frontend

# 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:
  port: 80
  protocol: http
  certificate_name: ''
  backendProtocol: 'http'
  serviceGroup:
    session_affinity_policy: ''
    services:
      - name: hello-world
        namespace: default
        port: 80
        weight: 100

#Operation On Frontend

#Creating

#using the web console

1. Go to Container Platform.

2. In the left navigation bar, click Network > Load Balancing.

3. Click the name of the load balancer to enter the details page.

4. Click Add Port.

Each input item on the web UI corresponds to a field of the CR

#using the CLI

kubectl apply -f alb-frontend-demo.yaml -n cpaas-system

#Subsequent Actions

For traffic from HTTP, gRPC, and HTTPS ports, in addition to the default internal routing group, you can set more varied back-end service matching rules. The load balancer will initially match the corresponding backend service according to the set rules; if the rule match fails, it will then match the backend services corresponding to the aforementioned internal routing group.

#Related Operations

You can click the ⋮ icon on the right side of the list page or click Actions in the upper right corner of the details page to update the default route or delete the listener port as needed.

#Rule

Rule is a Custom Resource(CR) that defines how incoming requests are matched and processed by the ALB.

Ingresses handled by ALB can be auto-translated to rules.

#Prerequisites

• Configure ALB
• Configure Frontend

Here is a demo rule to give you a quick first impression of how to use rules.

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: 'https'
  certificate_name: 'a/b'
  dslx:
    - type: URL
      values:
        - - STARTS_WITH
          - /
  priority: 4
  serviceGroup:
    services:
      - name: hello-world
        namespace: default
        port: 80
        weight: 100

#match request with dslx and priority

#dslx

DSLX is a domain-specific language used to describe the matching criteria. For example, the rule below matches a request that satisfies all the following criteria:

• url starts with /app-a or /app-b
• method is post
• url param's group is vip
• host is *.app.com
• header's location is east-1 or east-2
• has a cookie name is uid
• source IPs come from 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'

#priority

Priority is an integer ranging from 0 to 10, where lower values indicate higher priority. To configure the priority of a rule in ingress, you can use the following annotation format:

# alb.cpaas.io/ingress-rule-priority-$rule_index-$path_index
alb.cpaas.io/ingress-rule-priority-0-0: '10'

For rules, simply set the priority directly in .spec.priority using an integer value.

#Action

After a request matches a rule, you can apply the following actions to the request

#Backend

#backend protocol

By default, the backend protocol is set to HTTP. If you want to use TLS re-encryption, you can configure it as HTTPS.

#Service Group and Session Affinity Policy

You can configure one or more services within a rule.

By default, the ALB uses a round-robin (RR) algorithm to distribute requests among backend services. However, you can assign weights to individual services or choose a different load-balancing algorithm.

For more details, refer to Balance Algorithm.

#Operation On Rule

#Using web console

1. Go to Container Platform.
2. Click on Network > Load Balancing in the left navigation bar.
3. Click on the name of the load balancer.
4. Select the listener port name.
5. Click Add Rule.
6. Refer to the following descriptions to configure the relevant parameters.
7. Click Add.

Each input item on the webui corresponds to a field of the CR

#using the CLI

kubectl apply -f alb-rule-demo.yaml -n cpaas-system

#Https

If the frontend protocol (ft) is HTTPS or GRPCS, the rule can also be configured to use HTTPS.

You can specify the certificate either in the rule or in the ingress to match the certificate for that specific port.

Termination is supported, and re-encryption is possible if the backend protocol is HTTPS. However, you cannot specify a certificate for communication with the backend service.

#Certificate Annotation in Ingress

Certificates can be referenced across namespaces via annotation.

alb.networking.cpaas.io/tls: qq.com=cpaas-system/dex.tls,qq1.com=cpaas-system/dex1.tls

#Certificate in Rule

In .spec.certificate_name, the format is $secret_namespace/$secret_name

#TLS Mode

#Edge Mode

In edge mode, the client communicates with the ALB using HTTPS, and ALB communicates with backend services using HTTP protocol. To achieve this:

1. create ft use https protocol
2. create rule with backend protocol http, and specify cert via .spec.certificate_name

#Re-encrypt Mode

In re-encrypt mode, the client communicates with the ALB using HTTPS, and ALB communicates with backend services using HTTPS protocol. To achieve this:

1. create ft use https protocol
2. create rule with backend protocol https, and specify cert via .spec.certificate_name

#Ingress

#Ingress sync

Each ALB creates an IngressClass with the same name and handles ingresses within the same project.

When an ingress namespace has a label like cpaas.io/project: demo, it indicates that the ingress belongs to the demo project.

ALBs that have the project name demo in their .spec.config.projects configuration will automatically translate these ingresses into rules.

#SSL strategy

For ingresses that do not have certificates configured, ALB provides a strategy to use a default certificate.

You can configure the ALB custom resource with the following settings:

• .spec.config.defaultSSLStrategy: Defines the SSL strategy for ingresses without certificates
• .spec.config.defaultSSLCert: Sets the default certificate in the format $secret_ns/$secret_name

Available SSL strategies:

• Never: Do not create rules on HTTPS ports (default behavior)
• Always: Create rules on HTTPS ports using the default certificate

#Logs and Monitoring

By combining logs and monitoring data, you can quickly identify and resolve load balancer issues.

#Viewing Logs

1. Go to Administrator.

2. In the left navigation bar, click on Network Management > Load Balancer.

3. Click on Load Balancer Name.

4. In the Logs tab, view the logs of the load balancer's runtime from the container's perspective.

#Monitoring Metrics

1. Go to Administrator.

2. In the left navigation bar, click on Network Management > Load Balancer.

3. Click on Load Balancer Name.

4. In the Monitoring tab, view the metric trend information of the load balancer from the node's perspective.

   • Usage Rate: The real-time usage of CPU and memory by the load balancer on the current node.

   • Throughput: The overall incoming and outgoing traffic of the load balancer instance.

For more detailed information about monitoring metrics please refer to ALB Monitoring.