阿里云网络发布云原生网关 alibaba-load-balancer-controller v1.2.0，持续拥抱开源生态-阿里云开发者社区

阿里云网络发布云原生网关 alibaba-load-balancer-controller v1.2.0，持续拥抱开源生态

2024-06-21 2085

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： alibaba-load-balancer-controller开源版本正式推出v1.2.0，能力对齐ALB Ingress Controller商业版v2.10.0。

【阅读原文】戳：阿里云网络发布云原生网关 alibaba-load-balancer-controller v1.2.0，持续拥抱开源生态

引言：ALB Ingress作为阿里云官方推荐的云原生Ingress网关解决方案，已在包括阿里云容器服务ACK和ACK Serverless在内的多个Kubernetes部署场景中广泛应用。

为更好地服务于在阿里云上自建Kubernetes集群的用户，帮助用户更方便快捷地利用ALB产品的优势，阿里云网络基于ALB Ingress Controller商业版特性，推出了开源版本的alibaba-load-balancer-controller。自alibaba-load-balancer-controller v1.1.2发布以来，阿里云网络不断收集到来自用户的反馈及新的市场需求，在此基础上持续迭代产品，正式推出全新开源版本alibaba-load-balancer-controller v1.2.0，能力对齐阿里云洛神云网络ALB Ingress Controller商业版v2.10.0。

功能革新、体验升级与最佳实践

alibaba-load-balancer-controller v1.2.0在产品功能拓展、用户体验提升以及稳定性保障等方面均做出了显著改进。同时，云网络积极响应用户需求，持续针对高使用率场景推出最佳实践方案，助力用户高效快捷地掌握ALB Ingress在不同业务场景下的配置与使用。

1.1. 功能特性，强大而全面

相较于alibaba-load-balancer-controller v1.1.0，在最新推出的v1.2.0版本中，阿里云网络产品团队紧紧围绕云原生场景下客户的重点需求进行了深入的优化和创新，对实例管理、监听机制、转发规则、服务器组以及安全管理等关键部分进行了全面升级，力求不断丰富产品功能特性，包括：

•新增更多定制化选项，如自定义标签、资源组指定

•新增监听支持QUIC协议

•新增转发条件支持匹配自定义header、cookie、支持path字段的正则匹配；转发动作支持跨域、流量镜像以及更多自定义action

•新增支持ACL，并提供基于ACL ID和ACL Entry的管理方式

•新增支持secret证书

1.2. 体验优化，简单而专业

在alibaba-load-balancer-controller v1.2.0中，阿里云网络产品团队还重点进行了开发使用的体验优化，包括：

•优化Event通知机制、异常事件反馈和调谐流程等，有助于开发者更快地定位和解决问题，开发者可以通过kubectl describe ingress -n 查看异常事件报出。

•优化Ingress资源的无阻塞删除、监听错误隔离等，不同监听之间的异常事件不再互相阻塞，有助于开发者降低运维复杂度和成本。

•优化异步调用API、资源哈希等，提升响应速度并避免了预期外调谐行为。

1.3. 最佳实践，简明而高效

如何实现混合挂载、跨地域挂载和本地IDC挂载_容器服务Kubernetes版ACK(ACK)-阿里云帮助中心等最佳实践推出以来不断收获积极反馈，这也推动我们不断探索和总结，推出一系列新的最佳实践：

1.3.1 实践1：使用ReadinessGate实现ALB Ingress后端Pod滚动升级时平滑上线

在Pod上线阶段，需要确保Pod在接收流量之前真正达到可服务状态，开发者可以通过配置ReadinessGate来保证Pod上线阶段的可用性。ALB Ingress Controller支持启用ReadinessGate功能，持续监控ACK集群Pod的状态，等待Pod状态变为可用状态后再将完全启动的Pod挂载到后端服务器组，并向该Pod转发流量。

通过在Deployment中配置ReadinessGate自定义Condition：target-health.alb.k8s.alibabacloud，使ACK集群持续监控Pod的状态，直到状态为可用状态才认为Pod已经启动并挂载到后端服务器组上：

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
# 配置readinessGate
      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

您可以执行以下命令，检查ReadinessGate配置是否生效：

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

预期输出_：

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

1.3.2 实践2：使用preStop Hook实现ALB Ingress后端Pod滚动升级时平滑下线

在使用Pod节点作为应用承载平台时，对应用重新部署或对Deployment中Image镜像地址进行修改，会触发Kubernetes滚动更新，旧的Pod会终止服务，新的Pod节点会部署。在Pod滚动升级过程中如果旧的Pod没有平滑退出，会导致应用无法关闭业务请求，访问出现大量5xx状态码，影响业务持续性。通过为Pod设置平滑退出机制，能够保证流量停止/ALB Ingress Controller将Pod从后端服务器组移除后再平滑下线Pod，保证滚动升级过程中流量不中断。

您可以通过在Deployment配置内添加preStop Hook，为容器设置一个"Sleep"暂停期。这个暂停期是让容器有时间在收到SIGTERM之前完成网络规则的更新，并等待ALB Ingress Controller完成Server调谐事件并确保Pod已从后端服务器组中移除。这一步骤对于保障Pod的平稳下线至关重要，避免在滚动更新或服务重启期间造成流量中断。

同时，Kubernetes为容器设定了在接收到SIGTERM后能持续运行的最大宽限期（terminationGracePeriodSeconds）为30秒。当程序关闭时间与preStop Hook指定的操作时间之和超过了30秒时，默认宽限期将不足以让容器完成所有的关闭步骤。kubelet会在等待2秒后直接给容器发送立即终止（SIGKILL）信号，导致容器强制退出。如果程序的关闭时间和在Deployment配置的preStop Hook之和超过30秒，您也可以将terminationGracePeriodSeconds重新设置，调整为大于30秒，确保容器优雅退出。

在应用Deployment中添加preStop Hook，并修改终止terminationGracePeriodSeconds时间，配置示例如下：

...
spec:
      containers:
        lifecycle:
          preStop:
            exec:
              command:
# 设置pre Stop Hook函数，使kube-apiserver等待10s
              - /bin/sh
              - -c
              - "sleep 10"
# 设置Pod删除宽限期
      terminationGracePeriodSeconds: 45
...

您可以在应用Deployment中添加preStopHook并修改terminationGracePeriodSeconds后，持续访问业务，在此期间重新部署应用，实现Pod滚动升级，测试验证平滑下线的有效性。测试脚本示例如下：

#!/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