Traefik 在 Kubernetes 中使用 MiddlewareTCP CRD 配置 TCP 流量中间件【免费下载链接】traefikThe Cloud Native Application Proxy项目地址: https://gitcode.com/GitHub_Trending/tr/traefikMiddlewareTCP是 Traefik 中 TCP 中间件在 Kubernetes CRD 体系下的落地形态它让用户以kubectl apply声明式资源的方式在IngressRouteTCP的每条 TCP 路由上挂载ipAllowList来源 IP 白名单、inFlightConn并发连接数限制等中间件实现对经过 Traefik 的四层流量进行安全与限流控制。读完本文你将掌握 MiddlewareTCP 资源的结构与注册前提、如何在 IngressRouteTCP 中正确引用它以及它与 Provider Namespace、Kubernetes Namespace 之间的关系。什么是 MiddlewareTCP在 Traefik 的动态配置模型中中间件被挂载到路由上用于在流量被转发给后端服务之前对请求/连接进行加工处理如做鉴权、改写头、限流等。对于 TCP四层流量Traefik 提供了一套独立的 TCP 中间件其完整概念与列表参见 TCP Middleware Overview。MiddlewareTCP正是这套 TCP 中间件的CRDCustom Resource Definition实现。它把 TCP 中间件的能力以 Kubernetes 原生对象的形式暴露出来结构定义在 middlewaretcp.gotype MiddlewareTCP struct { metav1.TypeMeta json:,inline metav1.ObjectMeta json:metadata Spec MiddlewareTCPSpec json:spec } type MiddlewareTCPSpec struct { // InFlightConn defines the InFlightConn middleware configuration. InFlightConn *dynamic.TCPInFlightConn json:inFlightConn,omitempty // Deprecated: please use IPAllowList instead. IPWhiteList *dynamic.TCPIPWhiteList json:ipWhiteList,omitempty // IPAllowList defines the IPAllowList middleware configuration. IPAllowList *dynamic.TCPIPAllowList json:ipAllowList,omitempty }从源码结构可以清晰看到MiddlewareTCP的spec目前支持三个子块spec字段作用状态ipAllowList.sourceRange根据客户端 IP 允许/拒绝连接IP 白名单推荐使用inFlightConn.amount限制单个 IP 允许的最大并发连接数可用ipWhiteList.sourceRangeIP 白名单的旧命名已废弃请改用ipAllowList需要特别留意的是这三个子块在类型定义上直接复用了动态配置结构体dynamic.TCPInFlightConn、dynamic.TCPIPWhiteList与dynamic.TCPIPAllowList见 tcp_middlewares.go。也就是说CRD 只是把静态/文件配置中的同一条 TCP 中间件定义换成了 Kubernetes 对象的写法底层语义完全一致。前置条件先安装 Traefik Kubernetes CRDs在创建任何MiddlewareTCP对象之前必须先在你的 Kubernetes 集群中安装 Traefik 的 Kubernetes CRD 定义。安装后集群才会注册MiddlewareTCP这一 kind以及其他 Traefik 专属资源如IngressRouteTCP、IngressRouteUDP、TLSOption等。安装 CRD 通常通过kubectl apply应用 Traefik 官方提供的 CRD 清单完成具体文件与完整命令见当前仓库的 Kubernetes 参考文档docs/content/reference/install-configuration/providers/kubernetes-crd.md。仓库中也包含可直接用于集成测试的 CRD 清单例如 01-traefik-crd.yml 与 00-experimental-v1.5.1.yml可作为学习对象结构时的参考。CRD 一旦注册Kubernetes API Server 就会对MiddlewareTCP对象执行 OpenAPI 校验例如inFlightConn.amount的字段约束要求最小值不小于 0对应源码中的kubebuilder:validation:Minimum0标注从源头避免写入非法配置。配置示例MiddlewareTCP IngressRouteTCP下面的示例展示了 TCP 中间件在 Kubernetes 下的完整闭环先声明一个只允许本机与内网来源 IP 连接的MiddlewareTCP再通过IngressRouteTCP把它挂到一条基于 SNI 匹配的 TCP 路由上。# MiddlewareTCP定义中间件本身 apiVersion: traefik.io/v1alpha1 kind: MiddlewareTCP metadata: name: ipallowlist spec: ipAllowList: sourceRange: - 127.0.0.1/32 - 192.168.1.7# IngressRouteTCP在 TCP 路由上引用中间件 apiVersion: traefik.io/v1alpha1 kind: IngressRouteTCP metadata: name: ingressroutebar spec: entryPoints: - web routes: - match: HostSNI(example.com) kind: Rule services: - name: whoami port: 80 middlewares: - name: ipallowlist namespace: foo解析这个示例可以梳理出几条关键信息资源分组与版本两类资源均属于traefik.io/v1alpha1API 组。IngressRouteTCP的routes[].match使用HostSNI(...)表达式这也是 TCP 路由最典型的匹配方式四层没有 HTTP Host 头只能基于 TLS SNI 或原始 TCP 属性路由。中间件通过名称引用middlewares数组里的每一项是一个ObjectReference包含name与可选的namespace两个字段对应 objectreference.go。引用时namespace指的是MiddlewareTCP 资源所在的 Kubernetes Namespace。命名空间默认值省略namespace时Traefik 会默认把它解析为与当前IngressRouteTCP同 Namespace 下的同名中间件。跨 Provider 命名空间提示MiddlewareTCP的文档专门强调了一个极易混淆的概念Kubernetes Namespace 与 Provider Namespace 不是一回事。Kubernetes 资源引用中的namespace字段含义始终是该资源所在集群里的命名空间而 Provider Namespace 是 Traefik Provider 体系内的概念——它表示中间件定义来自哪个 Provider例如foodocker表示来自 Docker Provider 的foo中间件。因此请注意这两条规则当中间件定义来自其他 Provider如文件、Docker时在资源引用中指定namespace没有意义该字段会被忽略。因为其他 Provider 根本没有 Kubernetes 命名空间的概念此时只需在引用名后面用标注来源 Provider。当你要引用 CRD Provider 自己管理的 Middleware 时必须把资源所在的 Kubernetes Namespace 拼进资源名中——因为 Traefik 在内部处理时会自动追加 namespace。从实现上看CRD Provider 在构建中间件键时调用makeMiddlewareTCPKeys见 kubernetes_tcp.go内部通过resolveReference结合 IngressRoute 自身所在的 namespace 与跨命名空间策略CrossProviderNamespaces/AllowCrossNamespace解析出形如namespace-name的中间件引用。这种命名空间的内部自动拼接正是示例中MiddlewareTCP名为ipallowlist、被引用时却需要namespace: foo或名称形如foo-ipallowlist的根本原因。支持的具体中间件与用法MiddlewareTCP对应的 TCP 中间件目前只有两类一个已废弃的旧名等价类两者的详细配置说明如下。更多场景的组合参考仍以 TCP Middleware Overview 为准。中间件用途领域InFlightConn限制允许的最大并发连接数防止服务被高负载压垮安全、请求生命周期IPAllowList限制允许的客户端 IP安全、请求生命周期IPAllowList按客户端 IP 过滤连接iPAllowList依据客户端 IP 决定是否放行连接典型用法是只允许可信来源如公司出口 IP、运维网段访问数据库、内部 RPC 等不对外暴露的 TCP 服务。apiVersion: traefik.io/v1alpha1 kind: MiddlewareTCP metadata: name: test-ipallowlist spec: ipAllowList: sourceRange: - 127.0.0.1/32 - 192.168.1.7字段说明默认值是否必填sourceRange允许的 IP 列表通过 CIDR 记法支持 IP 段如192.168.1.0/24也支持不带掩码的单 IP如192.168.1.7等价于/32或/128无是该中间件的运行期实现位于 ip_allowlist.go其构造器New接收dynamic.TCPIPAllowList配置与 CRD 中spec.ipAllowList解出的配置一一对应。废弃提示旧版本中该能力叫ipWhiteList见 ip_whitelist.go 与类型定义中的Deprecated注释。新配置请一律使用ipAllowList两者功能等价。InFlightConn限制并发连接数inFlightConn用于主动防止后端服务被瞬时大流量压垮当已建立的并发连接数达到上限时新的连接会被中间件直接关闭。apiVersion: traefik.io/v1alpha1 kind: MiddlewareTCP metadata: name: test-inflightconn spec: inFlightConn: amount: 10字段说明默认值是否必填amount允许的最大并发连接数。当已有amount条连接打开时中间件会关闭新来的连接0是amount的最小取值在 CRD 校验层被约束为 0源码kubebuilder:validation:Minimum0。在运行期inflight_conn.go 的New会把config.Amount装载进计数器的maxConnections字段逐连接维护计数并在超限时拒绝服务。与其他配置来源的关系值得强调的是MiddlewareTCP并非唯一声明 TCP 中间件的途径。同一套配置在 Traefik 的不同 Provider 下有等价的写法详见 TCP Middleware Overview静态/动态配置文件在tcp.middlewares.name.ipAllowList或tcp.middlewares.name.inFlightConn下声明TOML/YAML容器标签通过traefik.tcp.middlewares.foo-ip-allowlist.ipallowlist.sourcerange...之类的标签声明并挂载Consul Catalog以traefik.tcp.middlewares...为前缀的 Tag 声明Kubernetes即以本文的MiddlewareTCPIngressRouteTCP方式声明。无论走哪条路径最终都会被汇聚为同一份dynamic.TCPMiddleware动态配置类型定义见 tcp_middlewares.go因此MiddlewareTCP学到的一切字段语义都可以平移到其他 Provider 场景中使用。这也解释了为何其spec能直接复用dynamic包中的结构体类型。总结MiddlewareTCP是 Traefik TCP 中间件的 CRD 形态前置条件是集群中已安装 Traefik Kubernetes CRDs其spec当前支持ipAllowList、inFlightConn与已废弃的ipWhiteList分别对应来源 IP 白名单与并发连接数限制两类安全能力在IngressRouteTCP.routes[].middlewares中通过namenamespace可选引用namespace指 Kubernetes Namespace与其他 Provider 无关引用跨 Provider 的中间件时该字段会被忽略由于 Traefik 内部自动追加 NamespaceCRD Provider 场景下的中间件引用名实际会被解析为namespace-name的形式理解这一点有助于排查引用不到中间件的常见问题。【免费下载链接】traefikThe Cloud Native Application Proxy项目地址: https://gitcode.com/GitHub_Trending/tr/traefik创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考