一文搞懂 Traefik Proxy 2.10 新版本特性

本文涉及的产品
可观测监控 Prometheus 版,每月50GB免费额度
简介: Hello folks,我是 Luga,今天我们来分享一下关于 Traefik 最新版本 - v2.10 相关特性。

    Hello folks,我是 Luga,今天我们来分享一下关于 Traefik 最新版本 - v2.10 相关特性。

    其实,从整个版本的规划角度来看,Traefik Proxy 2.10 作为一个过渡版本,但同样丰富了不少内容:比如,提高了我们使用 Traefik Proxy 服务网格的能力,增强了 Prometheus 指标以及并简化了我们的 Nomad 配置等,具体可参考如下解析。

01

新 Prometheus 指标的引入


    为了增强使用 Prometheus 与 Traefik Proxy 时的用户体验,我们现在可以根据一个或多个标头值的值拆分总请求指标的观察结果。此选项允许我们根据标头信息收集有关客户的更多详细信息。

    其实,标头本质上是灵活的,因此我们可以想出许多使用此功能的方式,包括创建自定义标头来披露应用程序版本。

    Traefik 将允许我们为“requests_total”指标和包含分配给每个标签的值的请求标头定义额外的标签,具体如下所示:


metrics:
prometheus:
buckets:
- 0.1
- 0.3
- 1.2
- 5.0
headerlabels:
useragent: "User-Agent"

    需要注意的是:默认情况下未启用此功能,因此默认情况下不会影响性能。当我们启用该功能时,如果请求中不存在标头,它将以空值自动添加。标签必须是普罗米修斯的有效标签名称。


02

原生 Kubernetes 服务负载均衡改进


    截至目前,Traefik 只将传入流量转发到 Pod。这使得很难解决需要使用 Traefik进行本机 Kubernetes 负载平衡的特定用例,因为它需要使用变通方法,例如创建外部服务。这些变通方法不能令人满意,这个缺失的功能是一个阻止者,特别是对于服务网格用户采用 Traefik。

    现在,用户有一个新选项供提供商 Kubernetes Ingress 和 Kubernetes IngressRoute,以决定任何给定负载平衡器的子项是否直接在 Pod IP 中,或者 Kubernetes 服务是否被指定为单个子项。在这种情况下,Kubernetes 服务本身通过入口控制器在上游配置中使用的所有端点的列表来平衡对 Pod 的负载。

    这对使用第三方服务网格(如Cilium)的用户尤为重要。另一个好处是,这种配置通过消除流量被重定向到不存在的客户端或 Pod 的任何机会,加强了 Traefik 对零停机部署的原生支持。

    其工作原理较为简单,我们只需将 “nativeLB” 选项添加到服务中即可,具体如下所示:


apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: whoami
namespace: traefik
spec:
entryPoints:
- web
routes:
- kind: Rule
match: PathPrefix(`/who`)
services:
- kind: Service
name: whoami
namespace: app
port: 80
nativeLB: true # Enable the option

    需要注意的是:

    在已删除 Pod 的特定情况下,当在 Traefik 更新其路由配置之前收到请求时,我们可能会生成 502 坏网关响应,因为 Traefik 配置不反映实际的基础设施。使用 “maxIdleConnectionPerHost” 选项通过与后端服务(Pod)创建新连接来缓解 502 错误,避免连接重用到突然下降的 Pod。


03

Nomad 多个命名空间支持


    Nomad 允许我们在任何给定的集群中使用多个命名空间。然而,我们的原始集成允许我们只使用单个命名空间,并要求我们在集群中为每个命名空间定义 Traefik Proxy 实例。此版本带来了使用 Traefik 的单个实例覆盖给定集群中所有命名空间的能力。

    具体如下所示:


providers:
nomad:
namespaces:
- "ns1"
- "ns2"

    以上为 Traefik 最新版本相关特性,更多关于 Traefik 的技术文章,将在后续文章中讲述,欢迎关注,谢谢!

 Adiós !

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
打赏
0
0
0
0
12
分享
相关文章
5分钟搞懂Ingress / IngressController / IngressClass的区别
先来个一句话总结:Ingress由Ingress规则、IngressController、IngressClass这3部分组成。Ingress资源只是一系列路由转发配置,必须使用IngressController才能让路由规则生效,而IngressClass是IngressController的具体实现。使用原则:先部署IngressController → 再部署Ingress资源。
21533 0
5分钟搞懂Ingress / IngressController / IngressClass的区别
Kubernetes附加组件Dashboard部署实战篇
关于如何在Kubernetes集群中部署和配置Dashboard组件的详细实战指南,涵盖了从创建证书、部署Dashboard、设置服务访问到登录认证的完整流程。
920 0
Kubernetes附加组件Dashboard部署实战篇
Istio架构及工作原理
【2月更文挑战第17天】从 Istio 的设计和实现原理可以看出,它是采用模块化设计,并且各个模块之间高度解耦,Proxy 专注于负责服务之间的通信,Pilot 专注于流量控制,Mixer 专注于策略控制以及监控日志功能,而 Citadel 专注于安全。
Kubernetes网络插件Canal的工作原理和关键功能
Kubernetes(简称 K8s)已经成为容器编排领域的标准,但要使 K8s 集群稳定运行,一个可靠的网络解决方案是至关重要的。在 K8s 中,有多种网络插件可供选择,每种插件都有其独特的特性和优势。在本文中,我们将深入探讨一个叫做 Canal 的 K8s 网络插件,穿插代码示例,以帮助您更好地理解和使用它。
564 0
解析Kubernetes的设计与实现原理
Kubernetes 是一种用于自动化部署、扩展和管理容器化应用程序的开源平台。它通过提供跨主机集群的容器协调和管理服务,实现了高可用性和弹性伸缩的容器集群管理。
BXA
235 0
在 Traefik Proxy 2.5 中使用/开发私有插件(Traefik 官方博客)
在 Traefik Proxy 2.5 中使用/开发私有插件(Traefik 官方博客)
666 1
istio 原理简介
Istio 的架构分为控制平面和数据平面 数据平面:由一组智能代理(Envoy)以 sidecar 模式部署,协调和控制所有服务之间的网络通信。 控制平面:负责管理和配置代理路由流量,以及在运行时执行的政策。
istio 原理简介
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等