Deploy High Available VIP for ALB

The high availability of the ALB requires a VIP. There are two ways to obtain a VIP.

Method 1: Use LoadBalancer type Service to provide VIP

When creating an ALB in container network mode, the system automatically creates a LoadBalancer Service to provide a VIP for that ALB.

Before using this, ensure the cluster supports LoadBalancer Services. You can use the platform built‑in implementation. For setup, see Configure MetalLB.

After MetalLB is ready, you can add the following annotations to alb.spec.config.vip.lbSvcAnnotations to tweak MetalLB behavior. See ALB networking configuration.

AnnotationDescription
metallb.universe.tf/loadBalancerIPsComma‑separated VIPs to allocate to the Service. Use multiple entries for multi‑VIP or dual‑stack, for example: 192.0.2.10,2001:db8::10.
metallb.universe.tf/address-poolThe MetalLB address pool to allocate from.

Method 2: Use external ALB device to provide VIP

  • Please confirm with the network engineer the IP address (public IP, private IP, VIP) or domain name of the ALB service before deployment. If you want to use a domain name as the address for external traffic to access the ALB, you need to apply for a domain name in advance and configure domain name resolution. It is recommended to use a commercial Load Balancer device to provide a VIP, if not, you can use the Pure Software Data Center LB Solution (Alpha)

  • According to the business scenario, the external ALB needs to configure health checks for all the ports in use to reduce the downtime of ALB upgrade. The health check configuration is as follows:

    Health Check ParametersDescription
    Port
    • For global clusters, fill in: 11782.
    • For business clusters, fill in: 1936.
    ProtocolThe protocol type of the health check, it is recommended to use TCP.
    Response TimeoutThe time required to receive the health check response, it is recommended to configure it to 2 seconds.
    Check IntervalThe time interval for the health check, it is recommended to configure it to 5 seconds.
    Unhealthy ThresholdThe number of consecutive failures after which the health check status of the backend server is determined to be failed, it is recommended to configure it to 3 times.