为什么选择 Traefik Ingress ？

何为 Traefik Ingress ？

在解析此概念之前，我们回顾下 Kubernetes 生态组件 Ingress Controller （中文释义：入口控制器）的概念。

依据 Kubernetes官方文件所述，入口 “ Ingress ” 被定义为：

1、一种 API 对象，用于管理 集 群中服务（通常为HTTP）的外部访问。

2、可以提供负载平衡、SSL终止和基于名称的虚拟主机。

在云原生生态体系中，通常，入口 “ Ingress ” 可以被视为类似于反向代理和负载平衡器，除了 Kubernetes 采用 BYOS（自带软件）方法外，并且不提供支持这些功能的软件。其仅提供 API 接口作为定义规则的标准化方法，这些规则定定义了哪些流量流向哪个服务。 此处则为入口控制器 “ Ingress Controller ”的功能所在。 Ingress Controller 是我们部署的集群内应用程序，其能够实现以下功能：

1、插入 Kubernetes API

2、监视入口对象

3、读取内部的入口规则

4、将自身配置为根据这些规则路由接收的流量

通常来讲，在实际的业务场景下， Ingress Controller 服务本身通常配置为接收整个集群的所有流量。在 HTTP/HTTPS 流量的上下文中，这意味着侦听集群将从中接收流量的公共 IP 地址上的端口 80 和 443。

那么，什么是 Traefik ?

依据官方的定义：Traefik 是一种基于现代 HTTP 反向代理和负载均衡器，可以轻松部署微服务。Traefik 与当前所流行现有的基础设施组件（Docker、Swarm 模式、Kubernetes、Marathon、Consul、Etcd、Rancher、Amazon ECS 等）集成，并自动和动态地自适应性配置。将 Traefik 指向我们的编排器应该是我们需要的唯一配置步骤。因此，利用 Traefik 可以使得微服务部署更加容易。

Traefik 是一种开放式 SourceEdge 路由器，它使发布服务成为一种有趣而简单的体验。它管理相关系统请求的接收，并动态识别出负责处理该请求的组件。

Traefik 除了具有许多基础功能外，还有一点与众不同，那便是：能够自动识别，依据服务特性进而为其发现正确的配置。当 Traefik 检查基础设施时，它会发现相关信息，并发现哪个服务为哪个请求服务，这一神奇的现象将会在 Traefik 这个路由器身上发挥的淋漓尽致。

基于 Traefik，我们通常无需刻意去维护和同步单独的配置文件：所有操作都会自动实时进行（热加载）。因此，基于 Traefik，我们仅需要将绝大部分精力聚焦在开发新功能组件并将其部署到系统中，而不非将时间浪费在无所事事的配置和维护工作状态上。

正如前面已经提到的，Traefik 是 Kubernetes 入口控制器的实现。它最初设计为一个可扩展的、轻量级的反向代理，但后来获得了与 Kubernetes 集群完全集成的能力，同时保留了与 Docker 和其他接口的兼容性，使得其具备更为强大的功能。其作为一个外部守护者，拦截并路由每一个进入此平台的所有请求，并依据相关逻辑和规则以指定对应的服务来处理。 基于 Traefik 的实时检测并自动更新路由规则以及自动服务发现相关特性，使得在进行流量接入过程中性能得到高效的提升。

截止当前，Traefik 最新版本为 V2.4.14。本文以 Traefik V2.x 为例，其基本架构及组件结构，如下示意图所示：

基于上述参考示意图，我们可以看到，对于整个 Traefik 体系而言，其核心的组件通常主要包括如下：

1、Entrypoints ， 网 络入口点 ，监听接入的流量（端口），其主要定义了接收请求的端口（HTTP 或者 TCP）。 其工作流架构如下图所示：

其配置示例如下所示：

## 静态配置
## 定义了两个 entrypoints：一个叫 web，另一个加 web-secure；web 监听 80 端口, web-secure 监听 443 端口。
entryPoints:  
    web:    
         address: ":80"  
         
    web-secure:   
         address: ":443"

2、Routers ，分析请求（Host、Path、Headers、SSL 及相关），其主要负责将接入请求连接到可以处理这些请求的服务上去。 其工作流架构如下图所示：

其配置示例如下所示：

## 动态配置
## 使用 File Provider 将 /foo 请求被 service-foo 服务处理
http:  
   routers:    
       my-router:    
            rule: "Path(`/foo`)"      
            service: service-foo

3、Services ，将请求转发给对应的应用（Load Balancing 等），其主要负责配置如何获取最终将处理传入请求的实际服务。 其工作流架构如下图所示：

其配置示例如下所示：

## 动态配置
## 使用 File Provider 为一个 HTTP 服务声明两个实例
http:  
   services:  
       my-service:     
            loadBalancer:       
               servers:       
               - url: "http://private-ip-server-1/"       
               - url: "http://private-ip-server-2/"
----------------------------------------------------------------------------
## 使用 File Provider 为一个 TCP 服务声明两个实例
tcp: 
   services:   
       my-service:    
            loadBalancer:               
                servers:      
                - address: "10.10.10.10"     
                - address: "10.10.10.11"

4、Middlewares ，用来修改请求或者根据请求来做出一些判断（Authentication、Rate Limiting、Headers 及其他），Traefik 内置了许多不同功能的中间件，其中一些可以修改请求，头信息，一些负责重定向，一些添加身份验证等等。中间件可以通过链式组合的方式来适用各种情况。其工作流架构如下图所示：

5、Providers ，用来自动发现平台上的服务，可以是编排工具、容器引擎或者 Key-Value 存储等，比如 Docker、Kubernetes、File 等。

除上述所述之外，在 Traefik v2.4 版本中增加了对 Kubernetes Gateway API 的支持。Gateway API 是由 SIG-NETWORK 社区管理的一个开源项目。该项目的目标旨在 Kubernetes 生态系统内发展服务网络 API。网关 API 提供了用于暴露 Kubernetes 应用程序的 Service、Ingress 等。Gateway API 旨在通过提供可表达的，可扩展的，面向角色的接口来改善服务网络，这些接口已由许多供应商实施并获得了广泛的行业支持。网关 API 是 API 资源（服务、网关类、网关、HTTPRoute、TCPRoute 等）的集合。这些资源共同为各种网络用例进行建模等等。

相比当前云原生生态中所落地的其他 Ingress 组件， T raefik 组件的优势体现在哪些地方呢？

Traefik 是 Traefiklabs（以前称为 Containeous ）开发的反向代理解决方案，2016年首次稳定发布，2015年9月首次开源，Github Stars 在反向代理框架中的数量最多，为34.1K。尽管历史悠久，但它仍在积极开发中，最后一次提交是在16小时前。 这些令人印象深刻的数字巩固了该框架在社区中的受欢迎程度，并为其在未来很长一段时间内保持活跃的开发提供了一 些保证，在选择使用开源框架时，这是一个不容低估的重要的考量点。

从可用性角度而言，Traefik 所具备的“核心”优势具体可以体现在以下几处：

1、 通过 Middlewares 中间件自定义扩展

2、具有可观测的 GUI 仪表板

3、轻松处理 TLS 证书自动续订

4、文档中充斥着每种提供者类型、 每种功能的配置示例

扩展性

Traefik 支持大量的中间件功能。他们有大量的内置中间件，我们可以依据不同的业务场景逻辑处理进行立即配置和使用。

这些中间件的完整列表可以在这里找到：https://doc.traefik.io/traefik/middlewares/overview/，这里主要列一些目前在集群中使用广泛的、值得关注的中间件，具体如下所示：

1、BasicAuth，用于在不安全的本地端点（例如 Traefik 仪表板本身）上提供基本身份验证

2、ForwardAuth，为集群中不支持 OpenLDAP 身份验证的应用程序提供单一登录前端

3、RateLimit，为所有端点提供 DDoS 攻击的基本保护

基于官方给予的相关文档所述，中间件功能也很容易使用，并且可以配置为 Kubernetes 自定义资源规范。例如，如下为简要的 BasicAuth 中间件应用 配 置示例 ：

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:  
     name: admin-auth  
     namespace: traefik-system
spec:  
    basicAuth:    
        secret: traefik-admin-auth-secret

除此之外，我们可以从示例中所定义的中间件定义中了解到的，它与 Kubernetes Secrets 集成，并从名为 traefik admin Auth secret 的 Kubernetes Secret 中获得基本的身份验证密钥，这意味着无需在任何文件中硬编码任何密码，允许对其进行创建、修改、或者删除。

观测性

Traefik 内置了一个非常漂亮的仪表板，基于此，我们可以使用它检查应用程序和中间件的运行状况。

在 Traefik V2.x 的生态里，从架构维度而言，将可观测性分成了如下几部分：

1、服务日志: Traefik 进程本身相关的操作日志

2、访 问日志: 由 Traefik 接管的代理服务的访问日志

3、Metrics: Traefik 提供的自身详细的 Metrics数据

4、T racing: Traefik 也提供了链路追踪相关接口，可用来可视化分布式或微服务中的调用情况

以下为 Traefi k Dashboard 参考示意图：

在详细视图中，我们还可以看到入口规则、Pod 名称、TLS 配置以及正在使用的任何中间件，这为我们提供了整个集群中当前配置的所有入口路由的巨大透明度。使得我们能够结合实际的业务场景对流量的调度情况进行全方位追踪、观测等，从而提升运维效能。

TLS 证书自动更新

自从设置 Traefik 以来，我完全忘记了我的 TLS 证书的存在，这表明 Traefik 在管理我的 Let's Encrypt TLS 证书方面是多么成功，这些证书需要每90天更新一次。

在我的设置中，我使用通过 DNS-01 ACME（自动证书管理环境）挑战设置的通配符TLS 证书，允许 Https 自动按需访问我的所有入口。Traefik 在其管理的每个 TLS 证书到期前几天自动续订证书，使我们完全忘记 TLS 证书续订过程。

通过 Let's Encrypt ACME TLS-ALPN-01 challenge 配置 Traefik 以获取 TLS 证书非常简单，只需在静态配置文件中指定以下内容即可：

certificatesResolvers: 
    default:   
        acme:      
             email: demo-email-address@email-demo.com     
             tlsChallenge: {}

配置示例

在 Traefik 中，我非常欣赏的一点是，尽管它们支持大量路由规则配置提供程序，如Docker、Kubernetes、Concur 等，但它们的示例从未松懈过。 对于他们拥有的每个特性，他们提供了他们支持的所有配置提供程序的示例。以 BasicAuth 为例，BasicAuth 中间件限制已知用户访问我们的服务。其处理工作流如下所示：

以 Kubernetes 平台为例，其对应的文件配置样例如下所示：

# Declaring the user list
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:  
     name: demo-auth
spec:  
    basicAuth:   
        secret: secretName

对于 Yaml 文件而言，其对应 的 文件配置 样例 如下所示：

# Declaring the user list
http:  
   middlewares:   
       demo-auth:      
            basicAuth:        
                users:         
                - "demo1:$apr1$H6usqqqW$IgXLP6ewTrSuBkTrqE8wj/"          
                - "demo2:$apr1$d9hr9POO$4HxwgUir3HP4EsggP/QNo0"

当然，除了上述的“核心”优势之外，在实际的业务场景中，Traefik 也具备如下优势：例如，借助其云原生特性，其能够完全 支持 Metrics，与 Prometheus 和 Kubernetes 无缝集成等；其还能够具备 更丰富的高级功能。例如，多版本的灰度发布、流量复制、自动生成 HTTPS 免费证书以及其他相关特性等。

诚然，Traefik 可能当前并不完美，但其发展势头依然迅猛，相对于同类型 的其他 组件而言，其非常值得推荐及应用，毕竟，随着其版本的不断快速迭代，无论是从流量拓扑的入口层，还是网关路由层，其都能够对 2 者进行无缝兼顾。除此之外，基于业务落地角度，其已经作为越来越多企业在进行云原生流量入口层组件的首选。

除此之外，基于云原生生态体系的不断成熟，微服务架构以及容器技术（ Docker 技术和 K8S 编排工具）最近几年的不断火热，因此，传统的反向代理技术体系，比如 Nginx、Apache 等在云原生生态环境面前显得捉襟见肘、苍白无力，再加上它们的骨髓中并未刻意提供对云原生生态的支持。所以才会出现 Ingress Controller 这种组件来实现 K8S 和 Nginx 之间的衔接。而 Traefik 天生就提供了与 Docker、K8S 的支持，也就是说 Traefik 本身就能跟 K8S API 交互感知后端变化，因此在使用基于云原生生态 Traefik 组件时，Ingress Controller 和 Nginx 这类组件就失去了其存在的意义。