×
Community Blog Embrace Open Source Ecosystem with Alibaba Load Balancer Controller V1.2.0

Embrace Open Source Ecosystem with Alibaba Load Balancer Controller V1.2.0

The article introduces the release of the open source version of alibaba-load-balancer-controller, including its features and best practices.

By ALB product team

As a cloud-native Ingress gateway solution officially recommended by Alibaba Cloud, ALB Ingress has been widely adopted in various Kubernetes deployment scenarios, including Container Service for Kubernetes (ACK) and ACK Serverless clusters.

To better serve users with self-managed Kubernetes clusters on Alibaba Cloud and help them quickly and conveniently leverage the benefits of the Application Load Balancer (ALB) product, the Alibaba Cloud Networking Team has released an open source version of the alibaba-load-balancer-controller based on the features of the commercial version of the ALB Ingress controller. Since the release of alibaba-load-balancer-controller v1.1.2, the Alibaba Cloud Networking Team has continuously collected user feedback and new market demands to iterate on the product, and has now officially launched the new open source version alibaba-load-balancer-controller v1.2.0, which aligns with the capabilities of the commercial version of the ALB Ingress controller v2.10.0 by the Alibaba Cloud Networking Team.

1. Feature Innovations, Upgraded Experience, and Best Practices

Alibaba Load Balancer Controller V1.2.0 delivers significant improvements in extending product capabilities, enhancing user experience, and ensuring stability. In addition, the Alibaba Cloud Networking Team actively responds to user needs and continues to provide best practices for solutions in common scenarios to help users efficiently and effectively master the configuration and use of ALB Ingress in different business scenarios.

_1

1.1. Powerful and Comprehensive Features

Compared with Alibaba Load Balancer Controller V1.1.0, in the latest version of V1.2.0, the Alibaba Cloud Networking Team has made in-depth optimizations and innovations based on key user needs in cloud-native scenarios, including comprehensive upgrades to key features such as instance management, listening mechanism, forwarding rules, server groups, and security management, as well as the following new features:

• More custom configurations are supported, such as custom tags and resource groups.

• QUIC listeners are supported.

• Custom headers and cookies are supported in forwarding conditions. Regular expression match is supported for the path field. Cross-origin Resource Sharing (CORS), traffic mirroring, and more custom actions can be configured as forwarding actions.

• Network access control lists (ACLs) are supported. They can be managed based on IDs and entries.

• Management of certificates as Kubernetes Secrets is supported.

1.2. Simple and Professional Use Experience

In Alibaba Load Balancer Controller V1.2.0, the Alibaba Cloud Networking Team has also optimized development and use experience.

• The event notification mechanism, exception feedback, and reconciliation process are optimized to help developers locate and troubleshoot problems more quickly. Developers can view reported exceptions by running this command: kubectl describe ingress -n .

• Non-blocking Ingress deletions and error isolation by listeners are optimized. Exceptions that occur on different listening ports no longer block each other. This helps reduce O&M difficulties and costs for developers.

• Asynchronous API operations and resource hashing are optimized, speeding up responses and preventing unexpected reconciliations.

1.3. Concise and Efficient Best Practices

Best practices such as Use ALB Ingresses to configure hybrid server groups, associate ECS instances with an ALB instance deployed in a different region, and associate on-premises servers with an ALB instance have already received a lot of positive feedback from users, which encourages us to continue to provide more best practices.

1.3.1 Case 1: Use readiness gates to seamlessly launch pods that are associated with ALB Ingresses during rolling updates

During a rolling update, you need to ensure that the updated pods are ready before they are launched to receive traffic. You can configure readiness gates to ensure the readiness of pods before they are launched. The ALB Ingress controller allows you to enable readiness gates to continuously monitor the status of pods in an ACK cluster. After the status of the pods changes to Ready, the pods are launched and added to a backend server group. Then, traffic is forwarded to the pods.

Configure custom conditions for readiness gates in the Deployment: target-health.alb.k8s.alibabacloud. This allows the ACK cluster to continuously monitor the status of pods. A pod is not considered started until it enters the Ready state. The started pods are added to a backend server group.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tea
spec:
  replicas: 3
  selector:
    matchLabels:
      app: tea
  template:
    metadata:
      labels:
        app: tea
    spec:
      containers:
      - name: tea
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
# Configure readiness gates
      readinessGates:
        - conditionType: target-health.alb.k8s.alibabacloud
---
apiVersion: v1
kind: Service
metadata:
  name: tea-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: tea
  type: NodePort

Run the following command to check whether the configuration of readiness gates takes effect:

kubectl get pods -o yaml |grep 'target-health'

Expected output:

    -conditionType: target-health.alb.k8s.alibabacloud
     message: correspondingconditionofpodreadinessgate"target-health.alb.k8s.alibabacLoud"

1.3.2 Case 2: Use preStop hooks to enable seamless pod termination during rolling updates of backend pods of ALB Ingresses

When an application is deployed in Kubernetes pods, redeployment of the application or modifications to the image address in the Deployment will trigger rolling updates of the pods. The service will be terminated in the old pods and deployed in new pods. During a rolling update, if the old pods are not seamlessly terminated, the application may not be able to process business requests and may return a number of 5xx status codes. This compromises business continuity. In this case, you can configure a seamless termination mechanism for the old pods to ensure that the pods are terminated only after traffic stops and the ALB Ingress controller removes the pods from the backend server group. This ensures uninterrupted traffic during the rolling update.

Add a preStop hook to the Deployment to specify a sleep duration. The sleep duration ensures a sufficient period of time for the container to update traffic routing rules and the ALB Ingress controller to reconcile the backend servers and remove the old pod from the backend server group before the pod receives the SIGTERM signal. This way, the pod can be seamlessly terminated to prevent service interruptions during rolling updates and restarts.

The default grace period (terminationGracePeriodSeconds) of a pod is 30 seconds. This indicates that the pod can continue to run for 30 seconds after it receives the SIGTERM signal. If the sum of the program shutdown duration and amount of time required to complete the operations defined by the preStop hook exceeds 30 seconds, the graceful shutdown of the pod times out. After the grace period ends, the kubelet waits 2 seconds and sends a SIGKILL signal to the pod to forcefully terminate the pod. In this case, we recommend that you increase the grace period (terminationGracePeriodSeconds) to ensure a sufficient period of time to complete the preceding operations.

Add a preStop hook to the Deployment of the application and set the terminationGracePeriodSeconds parameter. Sample configuration:

...
spec:
      containers:
        lifecycle:
          preStop:
            exec:
              command:
# Specify a preStop hook function that requires kube-apiserver to wait 10 seconds.
              - /bin/sh
              - -c
              - "sleep 10"
# Specify the grace period of the pod.
      terminationGracePeriodSeconds: 45
...

After you add a preStopHook to the Deployment of the application and set the terminationGracePeriodSeconds parameter, send continuous requests to the business. During the process, redeploy the application and perform a rolling update. Then, test the results of seamless pod termination.

Sample test script:

#!/bin/bash
HOST="demo.ingress.top"
DNS="alb-kwha5cxwhuiis****.cn-beijing.alb.aliyuncs.com"
printf "Response Code|| TIME \n" >> log.txt

while true
do
  curl -H Host:$HOST  -s -o /dev/null -w "%{http_code}  " -m 1  http://$DNS/ >> log.txt
  date +%Y-%m-%d_%H:%M:%S >> log.txt
sleep 1
done

Expected test results:

• The number of replicated pods before the rolling update is performed is three.

2

• During the redeployment, two old pods still run when new pods are not ready to process requests.

3

• After the new pods are ready to process requests and added to the backend server group of the ALB instance, the old pods are terminated.

4

• After the preStop hook function is executed in all old pods or the grace period is over, the kubelet sends signals to the old pods to terminate the pods. The rolling update is complete.

5

• If 200 is returned for each request, no service interruption occurs during the rolling update.

6

2. Get Started with Alibaba Load Balancer Controller V1.2.0

Start your Kubernetes cluster now and try Alibaba Load Balancer Controller V1.2.0 to experience the new heights of cloud-native open source gateways. Detailed documentation and user guides are available to help you get started easily.

URL of open source code: https://github.com/alibaba/alibaba-load-balancer-controller

_2

1.  You can build an image or pull an official image from Docker Hub and then deploy the image to your Kubernetes cluster.

Build an image: https://github.com/alibaba/alibaba-load-balancer-controller/blob/v1.2.0/docs/dev.md

Pull an image from Docker Hub: docker pull alibabacloudslb/alibaba-load-balancer-controller:v1.2.0

2.  Our quick-start guide shows you how to create AlbConfigs, IngressClasses, and Ingresses. This is a best practice for using ALB Ingresses to route traffic to the backend service.

Quick-start guide and resource creation: https://github.com/alibaba/alibaba-load-balancer-controller/blob/main/docs/getting-started.md

3.  Learn the ALB Ingress GlobalConfiguration dictionary to fully understand how to define custom forwarding rules to optimize service traffic distribution based on business requirements.

GlobalConfiguration dictionary: https://github.com/alibaba/alibaba-load-balancer-controller/blob/v1.2.0/docs/usage.md

4.  For more usage guidelines and configuration samples, you can refer to the official documentation about ALB Ingress-related operations.

Official documentation: https://www.alibabacloud.com/help/en/slb/application-load-balancer/user-guide/functions-and-features-of-alb-ingresses

3. Outlook

The launch of Alibaba Load Balancer Controller V1.2.0 embodies the continuous fulfillment of the Alibaba Cloud Networking Team's commitment to users and relentless pursuit of product excellence. Alibaba Load Balancer Controller is committed to becoming a trusted partner for developers in the process of developing cloud-native applications.

If you have any problems or improvement suggestions during the use of Alibaba Cloud network products, please feel free to visit the Alibaba Cloud network product community, contact technical support, or post your problems using this URL: https://github.com/alibaba/alibaba-load-balancer-controller/issues

0 1 0
Share on

Alibaba Cloud Community

1,076 posts | 263 followers

You may also like

Comments

Alibaba Cloud Community

1,076 posts | 263 followers

Related Products