tencent cloud

容器服务

文档容器服务故障处理CLB 回环现象指南

CLB 回环现象指南

下载
聚焦模式
字号
最后更新时间： 2026-11-11 10:00:03
本文档已由 AI 辅助审校

什么是回环现象

在 TKE 集群中，iptables 或 IPVS 模式下，访问本集群内网 Ingress 会出现4秒延时或不通。IPVS 模式下，集群内访问本集群 LoadBalancer 类型的内网 Service 出现完全不通，或者连通不稳定。

回环现象场景速查

1. 快速判断

通过下表判断连接访问是否受到回环现象的影响：
集群场景
是否有回环风险
需要处理吗
超级节点 + 内网 CLB + CLB Service
无风险
无需处理
超级节点 + 内网 CLB + CLB Ingress
无风险
无需处理
iptables 模式 + 内网 CLB + CLB Service
无风险
无需处理
使用 Service 名称或 ClusterIP 访问 Service
无风险
无需处理
公网 CLB + CLB Service / CLB Ingress
无风险
无需处理
普通节点/原生节点 + IPVS 模式 + 内网 CLB + CLB Service + 访问 LoadBalancer IP
有风险
需要处理
普通节点/原生节点 + 内网 CLB + CLB Ingress + 访问 LoadBalancer IP
有风险
需要处理
说明：
为什么集群内用 Service 名称访问没有回环风险？
使用 Service 名称（如 my-svc.default.svc.cluster.local）或 ClusterIP 时，流量在集群内直接转发到目标 Pod，不经过 CLB，因此不存在回环问题。

2. IPVS 模式下不同节点类型对 CLB Service 的默认行为

CLB 类型
节点类型
默认是否拦截 CLB VIP
回环风险
说明
内网 CLB
普通节点
不拦截（流量走 CLB）
有风险
默认不在集群内拦截 CLB VIP，流量经过 CLB 转发，同节点时可能回环。
内网 CLB
原生节点
不拦截（流量走 CLB）
有风险
行为与普通节点一致。
内网 CLB
超级节点
拦截（流量集群内闭环）
无风险
默认在集群内拦截 CLB VIP，流量直接转发到目标 Pod，不经过 CLB。
公网 CLB
-
-
无风险
-
说明：
什么是“拦截 CLB VIP”？
当 Pod 访问 CLB VIP 时，集群网络组件在本节点直接将 VIP 转换为后端 Pod IP，流量在集群内完成转发，不需要经过 CLB。这样就避免了 CLB 将流量转发回同节点的问题。

3. 四层场景（Service）速查

场景
流量路径
回环风险
解决方案
普通节点/原生节点 + 内网 CLB + IPVS
经过 CLB
有回环风险
普通节点/原生节点 + 内网 CLB + IPVS + 已启用集群内转发
集群内闭环，不经过 CLB
无
已解决
普通节点/原生节点 + 内网 CLB + IPVS + CLB 已开启 SNAT
经过 CLB
无
已解决
超级节点
集群内闭环，不经过 CLB
无
无需处理
iptables 模式
集群内闭环，不经过 CLB
无
无需处理

4. 七层场景（Ingress）速查

场景
流量路径
回环风险
解决方案
内网 CLB + CLB 未开启 SNAT
经过 CLB
有回环风险
内网 CLB + CLB 已开启 SNAT
经过 CLB
无
已解决
注意：
七层回环只能通过 CLB 开启 SNAT 解决，集群内转发方案不适用于七层场景。

解决方案

方案一：集群内转发

适用场景：普通节点/原生节点 + 内网 CLB + IPVS + 4 层 Service
原理：通过添加 annotation，让集群网络组件在节点上拦截对 CLB VIP 的访问，将流量在集群内直接转发到目标 Pod，不再经过外部 CLB，从根本上避免回环。
配置方法：
apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    # 启用集群内转发，避免流量走 CLB
    service.cloud.tencent.com/prevent-loopback: "true"
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
注意事项：
启用后，流量不再经过 CLB，因此无法使用 CLB 的能力。
健康探测 IP 会自动改为 100.64 网段，无需额外配置。
对存量长连接无影响，存量连接继续走 CLB；新建连接走集群内转发。
在 TKE Kubernetes Revision 版本历史 检查 kube-proxy 版本，确认版本“支持把 LB 地址绑定到 IPVS 网卡”。

方案二：Service 开启 CLB 4 层监听器 SNAT

适用场景：普通节点/原生节点 + 内网 CLB + IPVS + 4 层 Service + 需要流量经过 CLB
原理：在 CLB 侧开启 SNAT 后，CLB 转发请求到后端时会将源 IP 替换为 CLB 自身 IP。这样后端 Pod 回包时目标地址是 CLB IP，回包必须经过 CLB，不会在节点内部回环。
配置方法：
1. 申请白名单，通过 提交工单 申请开通：
CLB 4 层 SNAT 能力
2. 配置 SNAT：
通过 TkeServiceConfig 配置 spec.loadBalancer.l4Listeners.snatEnable: true ，开启 CLB 4 层监听器的 SNAT 功能。
注意事项：
TCP 协议可以通过 Proxy Protocol 获取真实客户端 IP。
UDP 协议无法获取真实源 IP。

方案一与方案二对比（四层回环）

维度
集群内转发（拦截 CLB VIP）
CLB 开启 SNAT
原理
在节点上拦截 CLB VIP，流量集群内闭环
CLB 替换源 IP，使回包必须经过 CLB
流量是否经过 CLB
不经过
经过
回环风险
无
无
CLB 高级能力
不可用（流量不经过 CLB）
可用
获取真实源 IP
可以获取
TCP 可通过 Proxy Protocol 获取，UDP 无法获取

方案三：七层 Ingress 开启 CLB SNAT

适用场景：内网 CLB + 7 层 Ingress
原理：在 CLB 侧开启 SNAT 后，CLB 转发请求到后端时会将源 IP 替换为 CLB 自身 IP。这样后端 Pod 回包时目标地址是 CLB IP，回包必须经过 CLB，不会在节点内部回环。
配置方法：
1. 申请白名单，通过 提交工单 申请开通：
CLB 7 层 SNAT 能力
Keep Alive 能力
2. 配置 SNAT：
当 ingress-controller 版本大于等于 v2.9.0 时，通过 TkeServiceConfig 配置 spec.loadBalancer.l7Listeners.snatEnable: true ，开启 CLB 7 层监听器的 SNAT 功能。
当 ingress-controller 版本小于 v2.9.0 时，通过 TkeServiceConfig 配置 spec.loadBalancer.l7Listeners.keepaliveEnable: 1 ，开启 CLB 7 层监听器的 SNAT 功能。
注意事项：
开启后，需从 X-Forwarded-For HTTP Header 获取真实源 IP。
注意节点配置放通 LoadBalancer IP 网段的访问。

常见问题

Q1: 为什么超级节点下 Service 没有回环问题？

超级节点默认会在集群内拦截 Service 关联 CLB 的 VIP，流量直接转发到目标 Pod，不经过 CLB，因此不存在回环问题。

Q2: 为什么 iptables 模式下 Service 没有回环问题？

iptables 模式下，数据包在路由之前就完成了目标地址转换，流量直接在集群内闭环转发到目标 Pod，不经过 CLB，因此不存在回环问题。

Q3: 添加 service.cloud.tencent.com/prevent-loopback: "true" annotation 后对现有业务有影响吗？

存量长连接：不受影响，继续走 CLB。原因是 conntrack 条目已存在，优先匹配，沿用原路径。
新建连接：改为集群内转发，不走 CLB。原因是新 SYN 包走路由决策，命中 local 表，被 IPVS 拦截。

上一篇: CLB 回环问题下一篇: 更新历史

帮助和支持

本页内容是否解决了您的问题？

填写满意度调查问卷，共创更好文档体验。

文档反馈

搜索
    请输入关键词搜索文档