一文搞懂 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搭建和管理企业级网站应用
相关文章
|
存储 网络协议 中间件
在 Traefik Proxy 2.5 中使用/开发私有插件(Traefik 官方博客)
在 Traefik Proxy 2.5 中使用/开发私有插件(Traefik 官方博客)
626 1
|
负载均衡 应用服务中间件 nginx
5分钟搞懂Ingress / IngressController / IngressClass的区别
先来个一句话总结:Ingress由Ingress规则、IngressController、IngressClass这3部分组成。Ingress资源只是一系列路由转发配置,必须使用IngressController才能让路由规则生效,而IngressClass是IngressController的具体实现。使用原则:先部署IngressController → 再部署Ingress资源。
21504 0
5分钟搞懂Ingress / IngressController / IngressClass的区别
|
10月前
|
Kubernetes 安全 网络协议
基于 Traefik 的激进 TLS 安全配置实践
基于 Traefik 的激进 TLS 安全配置实践
|
Kubernetes 容器
目前为止最全的Kubernetes最新版核心命令
目前为止最全的Kubernetes最新版核心命令
|
Kubernetes 负载均衡 监控
kube-proxy源码分析:深入浅出理解k8s的services工作原理
在进行k8s实践中, services 是经常碰到的资源对象,services 充当了 k8s 集群 pod 服务抽象的功能,为后端pod 提供了负载均衡和服务发现,那他到底是如何工作的呢,这里从 services 的具体实现 kube-proxy 出发解读 services 的工作机制。
2414 1
kube-proxy源码分析:深入浅出理解k8s的services工作原理
|
存储 Kubernetes 容器
利用NFS client provisioner动态提供Kubernetes后端存储卷–安装指南与实践
本文翻译自nfs-client-provisioner的说明文档,本文将介绍使用nfs-client-provisioner这个应用,利用NFS Server给Kubernetes作为持久存储的后端,并且动态提供PV。
3391 0
|
Kubernetes 网络协议 Linux
【Kubernetes系列】第10篇 网络原理解析(下篇)
3. 覆盖网络 - Overlay Network 覆盖网络(overlay network)是将TCP数据包装在另一种网络包里面进行路由转发和通信的技术。Overlay网络不是默认必须的,但是它们在特定场景下非常有用。
1383 0
|
Kubernetes 前端开发 Cloud Native
React Server Components 遇上 Kubernetes,官方 Demo 改造之上云试玩
React Server Components 遇上 Kubernetes,官方 Demo 改造之上云试玩
161 0
React Server Components 遇上 Kubernetes,官方 Demo 改造之上云试玩
|
Kubernetes 网络协议 Linux
【Kubernetes系列】第9篇 网络原理解析(上篇)
1. Linux网络基础 1.1 名词解释 Network Namespace(网络命名空间):Linux在网络栈中引入网络命名空间,将独立的网络协议栈隔离到不同的命令空间中,彼此间无法通信;docker利用这一特性,实现不容器间的网络隔离。
1584 0