一文了解 Traefik Proxy 2.7 新特性

技术

 Hello folks,距离上一个版本也有一段时间了,每一次的革新都带了相关特性的升级与优化,无论是基于开源社区支持者的反哺或是业务的诉求。



在最新的 Traefik Proxy v2.7 版本中,更新了

一系列全新的功能,包括服务故障转移支持、TCP 路由器、客户端 IP 匹配器以及用于 TCP 路由器的 SNI 正则表达式匹配器等。基于上述特性,以支撑和改进云原生生态系统所涉及的相关应用服务。下面,我们针对核心的功能特性进行简要解析。

服务故障转移

 通常而言,故障转移是业务系统高可用架构中不可或缺的一个重要关键点,毕竟,其能够减少单点架构所隐藏的潜在风险。在之前的 Traefik Proxy 组件中,其自身并不具备应用程序服务故障转移。作为

Traefik Proxy v2.7 中的一项全新功能,其 允许我们在实际的业务架构中,能够自定义配置并维护备份服务,从而使得业务可持续性。

 针对新引入的此项功能,若应用程序出现问题,无需担心,毕竟,应用程序的副本正在其他地方运行。我们所需要做的便是进行开关切换,使得所流经的流量能够快速重定向至备份服务。需要注意的是,应用程序服务故障转移既不是强制性的,也不是默认启用,需要结合自身的业务场景和架构特性而定。




 在 Traefik Proxy v2.7 中,基于此项功能,能够确保我们的业务服务受到持续监测,一旦出现故障,那么,流经的请求会则会依据所配置的规则进行自动切换至备份服务。以下为 Traefik Proxy v2.7 故障转移处理逻辑,具体如下所示:

          
## Dynamic configuration
          
http:
          
  services:
          
    app:
          
      failover:
          
        healthCheck: {}
          
        service: main
          
        fallback: backup
          
 
          
    main:
          
      loadBalancer:
          
        healthCheck:
          
          path: /status
          
          interval: 10s
          
          timeout: 3s
          
        servers:
          
        - url: "http://private-app-server-01/"
          
        - url: "http://private-app-server-02/"
          
 
          
    backup:
          
      loadBalancer:
          
        healthCheck:
          
          path: /status
          
          interval: 10s
          
          timeout: 3s
          
        servers:
          
        - url: "http://private-app-server-03/"
      
 通常来讲,应用程序服务故障转移是基于“

服务级别” 实现,这也意味着路由器可以随时引用它。因此,我们可以将其与现有的部署策略结合和匹配使用,例如, 循环 和 加权循环 负载均衡等。

 在下面的示例中,我们将展示 Traefik Proxy 将应用程序服务故障转移与加权循环集成场景,具体如下:

          
## Dynamic configuration
          
http:
          
  services:
          
    app-fallback:
          
      failover:
          
        healthCheck: {}
          
        service: app-main-region
          
        fallback: app-region-c
          
 
          
    app-main-region:
          
      weighted:
          
        services:
          
        - name: app-region-a
          
          weight: 3
          
        - name: app-region-b
          
          weight: 1
          
       
          
    app-region-a:
          
      loadBalancer:
          
        healthCheck:
          
          path: /status
          
          interval: 10s
          
          timeout: 3s
          
        servers:
          
        - url: "http://private-app-server-a01/"
          
        - url: "http://private-app-server-a02/"
          
 
          
    app-region-b:
          
      loadBalancer:
          
        healthCheck:
          
          path: /status
          
          interval: 10s
          
          timeout: 3s
          
        servers:
          
        - url: "http://private-app-server-b01/"
          
        - url: "http://private-app-server-b02/"
          
 
          
    app-region-c:
          
      loadBalancer:
          
        healthCheck:
          
          path: /status
          
          interval: 10s
          
          timeout: 3s
          
        servers:
          
        - url: "http://private-app-server-c01/"
      
 在上述的场景中,应用程序均部署在两个独立的中心区域,这些区域共同构成了核心的生产工作负载,有主、备份区域,运行相同的应用程序服务。备份区域存在的目的便是为了防止应用程序在发生灾难时失败,并且只有在主区域没有正常工作的服务器时才应激活它。






 然而,若网络状态足够顺畅、稳定,那么,用户可以在区域之间快速无缝地传输流量时,分布式应用程序可以更具弹性,应用程序服务故障转移更高效。

TCP 路由规则

 若对 Traefik 有所了解的话,我们都知道,当部署完后启动 Traefik 时,定义了入口点(端口号和对应的端口名称),然后 Kubernetes 集群外部就可以通过访问 Traefik 服务器地址和配置的入口点对 Traefik 服务进行访问,在访问时一般会带上 “域名” + “入口点端口”,然后 Traefik 会根据域名和入口点端口在 Traefik 路由规则表中进行匹配,如果匹配成功,则将流量发送到 Kubernetes 内部应用中与外界进行交互。这里面的域名与入口点与对应后台服务关联的规则,即是 Traefik 路由规则。                  




 在 Traefik Proxy 中,TCP 路由的默认规则是将传入的 TCP 请求与 hostSNI 或试图访问的服务器的别名进行匹配。若指定域名,请求将与该单个域名匹配。虽然如果在每个子域后面运行一个 TCP 服务,此选项效果很好,但当多个 TCP 服务在单个域后面运行时,它具有其用例的限制(我们需要将所有流量路由到特定端口,并为每个服务公开一个端口)。




Traefik Proxy v2.7 为现有的 TCP 路由规则带来了几项补充,其彻底修复了 TCP 多路复用器(简称 muxer 或 mux ),这是负责根据配置的路由规则选择哪个服务应该处理哪个传入请求的软件。




 除此之外,其还扩展了现有的 TCP 路由规则,为我们带来两个新的匹配器:客户端 IP 和具有正则表达式支持的 hostSNI。

‍客户端 IP 匹配器

 基于 Traefik Proxy v2.7,大家可以将请求与客户端的传入 IP/CIDR 地址进行匹配。这在内部网络中非常有用,因为它允许我们限制 IP 地址可以访问的范围。以下是匹配目标主机名和源客户端地址的示例:

          
## Dynamic configuration
          
tcp:
          
  routers:
          
    app:
          
      rule: HostSNI(`example.org`) && ClientIP(`10.10.10.10`)
      

带正则表达式的 HostSNI

 服务器名称标识(SNI),通常称为主机名,是 SSL标准的扩展,允许客户端指定它在连接中查找的资源的名称。




 以前在 TCP 路由器中,它只允许使用特殊的通配符符号与单个服务器名称标识匹配或匹配任何服务器名称。




 Traefik Proxy v2.7 在新的 TCP 匹配器中引入了对正则表达式的支持,允许更宽泛和动态的匹配规则。我们可以运行与请求匹配的正则表达式,而不是针对 TCP 应用程序的单个子域。例如,我们可以提及多个子域,这些子域都将重定向到 TCP 应用程序。




 以下是一个示例,展示了接受流量的基本域名的任何子域。

          
## Dynamic configuration
          
tcp:
          
  routers:
          
    app:
          
      rule: HostSNIRegexp(`{subdomain:[a-z]+}.example.com`)
      
 除了上述的核心特性外,Traefik Proxy v2.7 在其他层面也进行了改进与增强,例如,改进了路由器详细信息页面上的 UI、增加对 InfluxDB v2 指标的支持、增强了配置重载机制以及将 HTTP 3 库提升至最新版本等。具体详情大家可以参考如下所示:




   **增强功能:**
  • [领事目录]关注领事事件以重建动态配置

  • [健康检查]添加故障转移服务

  • [http3]使用 h3 服务器选项配置广告端口

  • [http3]将 quic-go 升级到 v0.25.0

  • [hub]添加 Traefik Hub 集成(实验功能)

  • [k8s/crd,k8s]允许 Kubernetes CRD 中的空服务

  • [指标]支持 InfluxDB v2 指标后端

  • [插件]删除使用插件的试点令牌设置约束

  • [提供商]重构配置重新加载/节流

  • [rules,tcp]为 TCP 添加 HostSNIRegexp 规则匹配器

  • [tcp]为 TCP 路由器添加 muxer

  • [webui,pilot]添加 Traefik Hub 访问权限并删除 Pilot 访问权限

  • [webui]在路由器详细信息视图上添加服务链接

     **错误修复:**
    
  • [hub]当 TLS 为零时跳过提供

  • [tcp]修复 TCP-TLS/HTTPS 路由优先级

  • [webui,hub]使用隧道专用入口点

    如上为 Trae fik Proxy v2.7 最新版相关特性,希望对大家有用。关于 Traefik Proxy v2.7 更多需要了解的信息,有兴趣的话,大家可以查看发布说明或者官方文档以及访问论坛,探索所有最新的社区主题。

    Adiós !

参考资料

picture.image

  • EOF -

如果您喜欢本文,欢迎 点赞 、 在看 、 留言 ,或者点击 右上角 ,把文章分享到朋友圈~~~

picture.image

0
0
0
0
关于作者
关于作者

文章

0

获赞

0

收藏

0

相关资源
云原生机器学习系统落地和实践
机器学习在字节跳动有着丰富业务场景:推广搜、CV/NLP/Speech 等。业务规模的不断增大对机器学习系统从用户体验、训练效率、编排调度、资源利用等方面也提出了新的挑战,而 Kubernetes 云原生理念的提出正是为了应对这些挑战。本次分享将主要介绍字节跳动机器学习系统云原生化的落地和实践。
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论