阿里云原生应用网关ALB Ingress Controller全面升级

阿里云ALB Ingress Controller升级,支持AScript自定义脚本、配置校验及多集群容灾部署,提升用户体验和可靠性。

原文标题:全能增强!云原生应用网关进阶

原文作者:阿里云开发者

冷月清谈:

阿里云ALB Ingress Controller 近期进行了全面升级,提升了用户体验和功能性。主要更新包括:

1. 产品功能增强:
* 支持AScript自定义编程脚本,实现精细化的流量管理。
* 服务器组支持慢启动和连接优雅中断,增强了应用部署和更新的稳定性。

2. 配置迁移便捷:
* 提供ingress2Albconfig工具,简化从Nginx Ingress到ALB Ingress的迁移过程。

3. 配置校验智能化:
* 集成webhook服务,能够提前拦截错误的Yaml配置,减少集群调谐失败。

4. 容灾部署更全面:
* 支持多集群部署模式,提供全面的容灾方案,增强了应用的可靠性。

怜星夜思:

1、AScript自定义脚本功能很强大,但实际应用中,大家觉得哪些场景会比较常用?
2、从Nginx Ingress迁移到ALB Ingress,除了使用官方提供的ingress2Albconfig工具外,还有哪些需要注意的地方?
3、多集群部署模式下,如何选择合适的容灾策略?有没有一些最佳实践可以参考?

原文内容

阿里妹导读


ALB Ingress Controller立足用户需求,全面升级:更便捷的配置切换,更智能的错误拦截校验,更全面的容灾部署场景,持续提升用户体验。

在过去半年中,ALB Ingress Controller立足用户需求,推出了一系列高级产品特性,致力于为用户提供更丰富的产品功能,更便捷的配置切换,更智能的错误拦截校验,更全面的容灾部署场景,持续提升用户体验,为用户业务保驾护航:

  • 在产品功能和用户体验方面,通过支持AScript自定义编程脚本,服务器组支持慢启动/连接优雅中断等特性,进一步丰富ALB Ingress功能矩阵。
  • 在配置迁移方面,支持了ingress2Albconfig工具以便用户更加快捷地从Nginx Ingress迁移至ALB Ingress。
  • 在配置校验方面,通过集成webhook服务拦截问题Yaml,便于客户更快更细粒度感知配置错误,减少集群调谐失败事件。
  • 在容灾部署方面,通过集成多集群部署模式,提供了全方位的容灾部署方案。

一、更丰富的产品功能


1.1 支持AScript自定义编程脚本

可编程脚本AScript是阿里云应用型负载均衡ALB (Application Load Balancer) 推出的突出灵活性和功能性的脚本语言,使得ALB实例能够突破传统负载均衡的局限,以自定义脚本的方式精确地控制和调整流量管理策略。

AScript支持自定义规则的执行,这些规则在处理客户端请求的不同阶段自动触发,确保实现高度自定义化的流量管理。无论是内容交付、安全性增强,还是性能优化,AScript都能灵活应对,实现负载均衡的智能化和个性化。新版本ALB Ingress Controller支持在Albconfig上配置AScript脚本,从而实现精细的业务管理,助您在复杂多变的业务环境中持续优化服务性能和用户体验。要使用AScript自定义编程脚本,您可以按照以下流程配置:

  1. 在ascript_configmap.yaml文件中创建AScript脚本对应的ConfigMap资源

apiVersion: v1
kind: ConfigMap
metadata:
 name: ascript-rule
 namespace: default
data:
 scriptContent: |
   if match($remote_addr, '127.0.0.1|10.0.0.1') {
     add_rsp_header('X-IPBLOCK-DEBUG', 'hit')
     exit(403)
   }
  1. 在Albconfig yaml监听配置中配置AScript脚本需要配置的位置及相关参数
apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
 name: default
spec:
 config:
   name: xiaosha-alb-test-1
   addressType: Intranet
 listeners:
 - port: 80
   protocol: HTTP
   aScriptConfig:
   - aScriptName: ascript-rule
     enabled: true
     position: RequestFoot
     configMapNamespace: default
     extAttributeEnabled: true
     extAttributes:
     - attributeKey: EsDebug
       attributeValue: test1

更多AScript 相关文档参考:

什么是可编程脚本AScript_负载均衡(SLB)-阿里云帮助中心:https://help.aliyun.com/zh/slb/application-load-balancer/user-guide/programmable-script/

AScript场景示例_负载均衡(SLB)-阿里云帮助中心:

https://help.aliyun.com/zh/slb/application-load-balancer/user-guide/ascript-common-scenarios


1.2 支持慢启动

在新增Pod加入Service后端后,如果ALB Ingress立即将流量分配至新增Pod,可能会造成瞬时的CPU或内存高压,导致访问异常。通过使用慢启动,ALB Ingress可以逐步将流量转移至新增Pod,缓解突发流量造成的影响。配置示例如下:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 annotations:
   alb.ingress.kubernetes.io/slow-start-enabled: "true"
   alb.ingress.kubernetes.io/slow-start-duration: "100"
 name: alb-ingress
spec:
 ingressClassName: alb
 rules:
 - host: alb.ingress.alibaba.com
   http:
     paths:
     - path: /
       pathType: Prefix
       backend:
         service:
           name: tea-svc
           port:
             number: 80


1.3 支持连接优雅中断

在Pod进入Terminating状态时,ALB Ingress会将Pod从后端移除。在这种情况下,Pod已建立的连接中可能还有进行中的请求。如果ALB Ingress立即关闭所有连接,可能造成业务出现错误。通过使用连接优雅中断能力,ALB Ingress可以在Pod被从后端移除后,在特定时间中保持连接的开启,保证业务在当前请求处理完成后平滑下线。连接优雅中断的具体工作模式如下:

  • 连接优雅中断不开启时,在移除Pod或者健康检查失败后,ALB Ingress会处理完连接中的所有请求后关闭会话。

  • 连接优雅中断开启时,在移除Pod或者健康检查失败后,ALB Ingress与Pod现有连接在一定时间内会保持正常传输,到达中断时间后主动断开连接,保障业务平稳下线。但不再接受新的请求:

    • 如果Pod有进行中的请求,ALB Ingress会在优雅中断超时时间到达时关闭所有连接并移除Pod。

    • 如果Pod在超时时间到达前处理完所有请求,ALB Ingress将会立即将Pod移除。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 annotations:
   alb.ingress.kubernetes.io/connection-drain-enabled: "true"
   alb.ingress.kubernetes.io/connection-drain-timeout: "199"
 name: alb-ingress
spec:
 ingressClassName: alb
 rules:
 - host: alb.ingress.alibaba.com
   http:
     paths:
     - path: /test
       pathType: Prefix
       backend:
         service:
           name: tea-svc
           port:
             number: 80

二、更便捷的配置切换(ingress2Albconfig)

随着ALB Ingress功能不断完善,在Ingress场景中提供了丰富多样的特性,且作为一项全托管服务,ALB Ingress不仅免去了用户的运维负担,还提供了强大的弹性能力,受到用户一致认可。但是因为Ingress配置在长期维护下已经相当复杂,将这些配置一一修改为ALB Ingress的描述复杂度较高,所产生的工作量导致不得不放弃使用ALB Ingress。

基于这部分使用诉求,ALB Ingress团队推出一款小工具来帮助配置快速转换,无论是运维还是开发团队,都可以通过工具将现有Nginx Ingress配置转换为ALB Ingress配置,同时可以在不影响现有流量的情况下,灰度到ALB Ingress当中,其整体过程类似于下图:

通过DNS的方式,来将流量灰度到ALB上,可以确保流量正常的情况下具备恢复和容灾能力,具体到转发工具上,目前推送了工具镜像到官方仓库中,用户可以使用如下的Job来进行一次性转换工作,也可以以工具容器的形态长期运行,在功能进一步完善后会以更加通用的方式进行工具发布。

apiVersion: batch/v1
kind: Job
metadata:
 name: ingress2albconfig
 namespace: default
spec:
 template:
   spec:
     containers:
     - name: ingress2albconfig
       image: registry.cn-hangzhou.aliyuncs.com/acs/ingress2albconfig:latest
       command: ["/bin/ingress2albconfig", "print"]
     restartPolicy: Never
     serviceAccount: ingress2albconfig
     serviceAccountName: ingress2albconfig
 backoffLimit: 4
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: system:ingress2albconfig
rules:
- apiGroups:
 - networking.k8s.io
 resources:
 - ingresses
 - ingressclasses
 verbs:
 - get
 - list
 - watch
---
apiVersion: v1
kind: ServiceAccount
metadata:
 name: ingress2albconfig
 namespace: default
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: system:ingress2albconfig
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: system:ingress2albconfig
subjects:
 - kind: ServiceAccount
   name: ingress2albconfig
   namespace: default
在上述一次性任务中,使用了官方镜像的print指令,因为是在集群内部使用,所以需要配合授权RBAC使用,在示例中开启了对全部ingress资源的读权限,生成的资源会和原始资源在同一个Namespace,转换后配置的对应Name以from_为前缀表示。
apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
 creationTimestamp: null
 name: from_nginx
spec:
 config:
   accessLogConfig: {}
   edition: Standard
   name: from_nginx
   tags:
   - key: converted/ingress2albconfig
     value: "true"
   zoneMappings:
   - vSwitchId: vsw-xxx #替换为VPC中的虚拟交换机ID
   - vSwitchId: vsw-xxx #替换为VPC中的虚拟交换机ID
 listeners:
 - port: 80
   protocol: HTTP
---
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
 creationTimestamp: null
 name: from_nginx
spec:
 controller: ingress.k8s.alibabacloud/alb
 parameters:
   apiGroup: alibabacloud.com
   kind: AlbConfig
   name: from_nginx
   scope: null
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 annotations:
   alb.ingress.kubernetes.io/listen-ports: '[{"HTTP":80}]'
 creationTimestamp: null
 name: from_ingress1
 namespace: default
spec:
 ingressClassName: from_nginx
 rules:
 - http:
     paths:
     - backend:
         service:
           name: nginx-svc-g1msr
           port:
             number: 80
       path: /
       pathType: Prefix
status:
 loadBalancer: {}
在上述生成资源中,并不能直接使用,需要填写对应VPC中的虚拟交换机ID,这是因为ALB的使用需要依赖底层可用区并使用交换机上IP来提供服务,需要在使用过程中进行符合预期的网络规划。

目前ingress2Albconfig工具还处于早期阶段,后续会不断迭代,补充更多转换功能。如您在使用中发现还未支持的功能,欢迎联系我们提供反馈,我们会在之后的版本中优先实现对应功能。

三、更智能的配置校验

ALB Ingress Controller 配置Albconfig / Ingress 时存在参数格式/类型错误造成的调谐失败。用户不对问题Albconfig/Ingress 进行调整时,调谐失败事件会一直存在,且Albconfig / Ingress 配置始终无法与ALB配置达成一致。同时,对于部分低版本Controller,Albconfig 格式错误可能导致Controller Pod Crash,影响用户正常变配。

在 K8S v1.9版本 中,kubernetes 的动态准入控制器功能中支持了 Admission Webhooks,用户可以以插件的方式对 ApiServer 的请求进行访问控制,ApiServer 会在请求通过认证和授权之后、对象被持久化之前拦截该请求,并调用 Webhook 服务达到准入控制。2.15.0版本ALB Ingress Controller 支持了Webhook校验服务,对比调谐时发现配置错误问题并返回失败事件,Webhook校验有如下几点优势:

  • 尽早拦截:通过Webhook在API层面早期拦截错误或不合规的配置,可以减少不必要的资源创建尝试和潜在的集群状态混乱。这种方式比等到Ingress Controller的调谐阶段,才发现错误再返回调谐失败事件更为高效,避免了资源调度、网络配置等后续步骤的浪费。

  • 解耦逻辑:将验证逻辑放在Webhook中,使得Ingress Controller的逻辑更加专注于资源的实际部署和管理,而不用关心配置的有效性检查。这样的设计遵循了单一职责原则,使得系统各部分更加模块化,易于维护和扩展。

  • 安全性增强:将Yaml验证逻辑放在独立的Webhook服务中,允许对进入集群的资源请求进行集中管理和控制,减少了恶意或错误配置的风险。

  • 错误配置感知:在参数错误时,webhook拦截可以尽早为用户透出清晰的提示快速定位问题,对比之前需要用户关注Event事件感知参数错误造成的调谐失败,更加明确的透出问题参数及错误原因。

Webhook主要组件

ValidatingAdmissionWebhook:定义了 Kubernetes API 服务器在接收到对 Ingress 资源的创建或更新请求时应该调用的 Webhook URL,及哪些操作/资源会触发webhook校验,在alb ingress controller部署时会一起部署。

TLS证书:APIServer 与 Webhook 服务之间的通信必须通过 TLS 进行加密。

Webhook Service:Webhook服务能够解析传入的 AdmissionReview 请求,对 Ingress 资源定义进行校验,并生成一个 AdmissionResponse。

以如下ingress配置为例,在ACK控制台配置ingress时,listen-ports注解项配置错误,Webhook校验服务会发现注解项中错误的配置并直接返回报错,便于用户感知错误配置并及时修改。

四、更全面的容灾部署

随着云原生技术在各个领域的不断推广与应用,单一集群越来越难以满足容灾和高可用方面的需求,在碰到集群基础组件升级故障或可用区级别故障时往往难以快速进行服务恢复;在这样的背景下,ALB Ingress支持在分布式云容器平台ACK One提供的多集群舰队模式下支持多集群网关能力,ACK One舰队管理的Fleet实例是由ACK托管的,可以管理任意环境的Kubernetes集群,为企业提供一致的云原生应用管理体验。

ALB Ingress多集群网关是阿里云面向混合云、多集群的应用容灾和南北向流量管理推出的解决方案,帮助用户快速实现混合云、多集群的应用同城/异地容灾系统,及流量的管理和治理。

多集群网关具有以下优势:

  • 网关全托管,免运维。
  • 减少网关数量,降低成本。地域级别的多集群Global Ingress,统一管理多集群南北七层流量。
  • 简化多集群流量管理,在舰队中统一完成多个集群Ingress规则设置,无需单独操作每个子集群。
  • 多集群网关自身跨AZ高可用。
  • 毫秒级/秒级Fallback,在某个集群后端发生故障时,多集群网关能够平滑地将流量迁移至其他后端。

无论是构建同城容灾系统还是混合云容灾系统,在多集群模式下ALB Ingress都可以助力实现更加高可用的系统架构。

更多文档:

基于ACK One ALB多集群网关实现同城容灾

https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/use-cases/implementation-of-same-city-disaster-recovery-with-ack-one-alb-multi-cluster-gateway

基于ACK One ALB多集群网关实现混合云容灾

https://help.aliyun.com/zh/ack/distributed-cloud-container-platform-for-kubernetes/use-cases/implementation-of-hybrid-cloud-disaster-tolerance-based-on-ack-one-alb-multi-cluster-gateway

五、总结与规划

在过去半年里,ALB Ingress在各领域持续发力,致力于为用户提供更加灵活的部署方案,更加精确有效的问题定位能力,更加安全可靠的网络环境。后续我们会立足客户需求,持续保持快速迭代,扩展更多云原生使用场景,为客户提供更安全可靠的云原生网关。

欢迎关注ALB Ingress最新动态,并对我们的产品提出宝贵建议。

联系我们:

https://help.aliyun.com/zh/slb/application-load-balancer/support/contact-us

除了技术方面的考虑,还需要考虑管理和运维的复杂度。多集群部署模式下,管理和运维的复杂度会增加,需要有相应的管理工具和流程来支撑。可以参考一些成熟的解决方案,比如阿里云的 ACK One。

我想到的是结合监控和告警。比如在AScript中自定义一些指标的采集和计算,然后根据计算结果触发告警。这样可以更灵活地监控业务状态。

选择容灾策略时,还要考虑 RTO 和 RPO 的指标。RTO 指的是系统恢复的时间,RPO 指的是数据丢失的范围。不同的容灾策略对应的 RTO 和 RPO 也不一样,需要根据业务需求进行权衡。

迁移过程中,最好先进行灰度测试,逐步将流量切换到 ALB Ingress,确保迁移过程平滑,避免对线上业务造成影响。毕竟稳定性最重要。

还有就是 ALB Ingress 是阿里云的产品,需要考虑与其他阿里云服务的集成。如果你的应用使用了其他阿里云服务,可以考虑利用 ALB Ingress 的优势,进一步优化应用架构。

除了IP控制,还可以根据请求头信息做一些个性化的处理,比如根据User-Agent判断客户端类型,返回不同的内容,或者根据Referer做防盗链处理。感觉可以玩出很多花样。

关于“多集群部署模式下,如何选择合适的容灾策略?”这个问题,我觉得要根据实际业务需求和预算来选择。比如,如果业务对可用性要求非常高,可以考虑采用双活或者多活的方案,但成本也会相应提高。如果预算有限,可以考虑采用冷备或者温备的方案。

我觉得根据客户端IP做一些访问控制或者限流,应该是比较常见的场景。比如针对某些恶意IP直接拦截,或者对特定地区的访问做限速。

需要注意的是,Nginx Ingress 和 ALB Ingress 的注解规范不一样,有一些注解需要修改或者删除。建议仔细阅读官方文档,做好迁移前的准备工作。