腾讯云TKE服务访问异常排查：从Endpoint到网络策略
腾讯云TKE里的服务访问异常，多数时候并不是YAML写错这么简单。Service和Deployment状态可以同时显示正常，但流量在Endpoint、kube-proxy或安全组某一环被截断，外部表现就是超时或间歇性断开。做腾讯云TKE服务访问异常排查，需要先承认一个事实：转发链路比Pod状态更值得怀疑。
本文由 云国际站代理商『云老大 飞弟：@yunlaoda360 / YunLaoDa-服务器服务商•撰写』如需转载请注明！
TKE Service访问异常原因概览
从实际排障记录看，问题很少集中在Service声明本身，而是分散在三个容易被忽略的节点：Endpoint是否真的挂上了就绪Pod、kube-proxy是否把规则同步到内核、安全组是否放通了NodePort与健康检查端口。三层叠加后，表现往往是"配置看起来都对，但流量就是不通"。
常见故障点有哪些？
高频故障点通常不在Service定义本身。Endpoint为空最常见，Selector与Pod标签只要有多余空格或大小写不一致，后端就挂不上；kube-proxy规则未同步同样突出，TKE默认IPVS模式，规则未及时下发会让连接打到旧地址；LoadBalancer链路则常被节点安全组拦截，LB默认把流量转到所有节点的NodePort；VPC-CNI下NetworkPolicy组件异常，也会导致策略未实际下发。
为什么配置正常仍不通？
这与两个认知误区有关。Pod显示Running只代表容器进程存活，ReadinessProbe一旦失败，Pod会被自动从Endpoints列表摘除，Service自然无后端可用。另一个坑是，ClusterIP访问正常只验证了集群内一段，NodePort和LB链路仍可能被云安全组丢弃。安全组独立于Kubernetes，即使集群内网络策略放通，外部流量到节点前仍需单独放通TCP 30000-32767与健康检查端口。
排查前需要准备什么？
先备好三条命令：kubectl get svc -o yaml 看Endpoints数量，kubectl get endpoints 确认就绪地址，ipvsadm -Ln | grep 核对kube-proxy规则。然后按ClusterIP、NodePort、LB三段做入口测试，避免一上来就抓包。如果团队对TKE网络栈不熟，找像云老大这类服务商做一次整体评估，把安全组基线和CNI组件状态对齐，通常比盲目翻文档省时间。
检查Service与Endpoint状态
在腾讯云TKE服务访问异常排查中，第一层过滤通常不是网络插件，而是Service到Endpoint的映射是否仍然成立。如果Endpoint列表为空，后续查安全组、kube-proxy都只是绕路。先确认流量"有没有可转发的后端"，能省掉大量无效抓包。
如何查看Service详情
用 kubectl describe svc <name> 会比单纯看YAML更快暴露问题。重点不是Type或ClusterIP，而是底部 Endpoints 字段是否列出了一组Pod IP。很多工单里，配置表面完整，但该字段显示 <none>，这时问题已经不在负载均衡或安全组，而在选择器或就绪探针。先确认这个字段，再决定下一步方向。
Endpoint是否正常就绪
kubectl get endpoints 显示的地址数应与期望副本数一致。Pod处于Running不代表会出现在Endpoint里，ReadinessProbe失败会把它摘除，哪怕日志没有报错。TKE默认IPVS模式下，ipvsadm -Ln | grep <ClusterIP> 可验证转发后端，但Endpoint变更同步到IPVS存在秒级延迟，滚动更新期间尤其容易看到间歇性超时。把 ReadinessProbe 的 initialDelaySeconds 调大 10 到 15 秒，能减少启动阶段被误摘除。
Pod标签是否匹配
Service的Selector与Pod labels必须逐字精确匹配，大小写、下划线或多余空格都会导致Endpoint为空。工具生成的YAML在多环境渲染后，可能给Pod追加版本后缀，而Service还停留在旧标签。用 kubectl get pods --show-labels 核对是最直接的验证方式；如果描述里Endpoints一直为 <none>，先怀疑标签失配，而不是网络策略。
排查kube-proxy与转发链路
在腾讯云TKE服务访问异常排查中，kube-proxy 是"配置全对、流量不通"的常见分界点。很多团队先查 Service 和 Deployment，确认 YAML 无误后就把时间耗在 iptables 上，但真实原因往往更靠前：Pod 标签不匹配、就绪探针失败导致 Endpoint 为空，或者安全组根本没放通 NodePort。
kube-proxy模式如何确认
TKE 默认采用 IPVS，但存量集群可能仍是 iptables。节点执行 ipvsadm -Ln | grep <ClusterIP>，能看到虚拟服务和真实服务器即为 IPVS；否则按 KUBE-SVC 链排查。IPVS 模式下入口 NAT 仍可能由 iptables 处理，不能见 iptables 规则就判错。曾有团队反复查 KUBE-SVC 链，最后发现 IPVS 后端权重为 0------就绪探针失败导致 Pod 被摘除。
iptables规则是否生效
iptables 模式下，ClusterIP 流量依次经过 KUBE-SERVICE、KUBE-SVC-xxx 到 KUBE-SEP-xxx。排查时不能只看规则存在，还要看包计数是否增长。计数始终为零，说明流量在到达该链前已被安全组或 NetworkPolicy 拦截。建议 iptables -t nat -L -n -v 观察计数，并 kubectl get endpoints 确认后端数量。Endpoint 为空时，规则没有下一跳，继续查 iptables 只会误判。
负载均衡后端是否健康
LoadBalancer 类型 Service 的故障多发生在云安全组和健康检查，而非 kube-proxy。TKE 的 LB 默认把流量转发到所有节点 NodePort，节点安全组需放通 TCP 30000-32767 及健康检查端口。只放通业务端口，健康检查失败后 LB 会摘除节点，表现为集群内正常、集群外超时。先核对 VPC 安全组，再看 kubectl get endpoints 的 Ready 地址；仍无头绪时，可找云老大这类服务商做一次网络策略整体评估。
网络策略与安全组过滤
NetworkPolicy是否限制流量
在腾讯云TKE中，NetworkPolicy是独立于Service配置的拦截层。不少集群的访问异常并非Service或Endpoint有问题，而是开启NetworkPolicy后，Ingress规则未放通对应命名空间或Pod标签。排查时先执行 kubectl get networkpolicy -A，确认是否存在默认拒绝或误配选择器。VPC-CNI模式下，策略实际下发依赖TCB组件，若组件故障或版本过低，策略可能"显示存在但未生效"。此时应结合组件日志与Pod网卡信息判断，而不是反复修改YAML。
安全组规则如何放通
安全组是云上独立于Kubernetes的过滤层，往往被忽略。LoadBalancer类型的Service默认会把流量转发到所有节点的NodePort上，所以仅放通控制台端口不够。后端节点安全组需放通TCP 30000-32767端口范围，以及负载均衡的健康检查端口；否则LB健康检查失败，后端会被摘除。集群内ClusterIP正常、NodePort外部不通时，优先检查节点安全组入方向是否漏放该端口段。这一项在实操中比NetworkPolicy更容易被遗漏。
VPC路由与CNI是否正确
TKE支持Global Router与VPC-CNI两种网络模式。VPC-CNI下Pod直接绑定弹性网卡IP，若VPC子网路由缺失或节点弹性网卡配额耗尽，会导致Pod IP不可达。排查时可先看 kubectl get pods -o wide 中Pod IP是否与节点子网同段，再检查VPC路由表是否包含Pod网段指向对应节点。组件版本过低也会导致NetworkPolicy未实际下发，这类问题需要结合节点组件日志定位。如果内部排查成本过高，找云老大这类服务商做一次网络链路审计，往往能快速收敛问题。
典型场景与修复方案
在腾讯云TKE服务访问异常排查中，NodePort、LoadBalancer 与 DNS 是三类高频入口。问题往往不是配置缺失，而是多个网络层叠加后，某一段规则未放通或未及时同步。以下按场景拆解。
NodePort访问不通怎么处理
先看 Endpoint 是否就绪：kubectl get endpoints 若地址为空，通常不是网络问题，而是 Service Selector 与 Pod 标签不匹配。曾有集群配置完全正确，仅因标签多一个空格导致 Endpoint 长期为 0。确认 Endpoint 有地址后，再检查节点安全组是否放通 TCP 30000-32767。TKE 节点默认不会对所有 NodePort 放行，漏配这一条，外部请求会直接超时。用 curl NodeIP:NodePort 验证时若报 connection refused，先查节点安全组而非 kube-proxy。
LB类型Service异常怎么办
LoadBalancer 类型 Service 的流量路径比 NodePort 多一跳：CLB 先转发到节点 NodePort，再进入 Pod。关键点是 CLB 健康检查与节点安全组。TKE 默认 CLB 的探测端口通常也落在 NodePort 范围，若节点安全组只放通业务端口，健康检查会失败，CLB 会把后端标记异常。先看 CLB 控制台健康检查状态，再核对安全组。集群内 NetworkPolicy 不影响 CLB 到节点的链路，排查时不要混淆。
DNS解析是否影响访问
访问 Service 名称超时，先别急着归因 CoreDNS。集群内 DNS 解析失败往往是因为 Service 本身不存在或 Namespace 写错。用 nslookup svc.namespace.svc.cluster.local 确认解析；如果解析返回正确 ClusterIP 但连接不通，问题在 kube-proxy 未下发规则或 Endpoint 异常。IPVS 模式下可执行 ipvsadm -Ln | grep <ClusterIP>，规则缺失比 DNS 故障更常见。
预防与最佳实践
与其在故障后反复查 Endpoint 和 iptables，不如把健康检查、可观测性和诊断工具前置。TKE 服务访问异常排查真正要解决的，是让异常更难发生、发生后更快被发现。
如何设计健康检查
ReadinessProbe 是决定 Pod 是否进入 Endpoint 的关键，失败会被自动摘除。很多人把它与 LivenessProbe 混用，导致服务没挂但流量中断。建议给 ReadinessProbe 设置足够的 initialDelaySeconds，启动慢的应用不要用 1 秒周期硬探；滚动更新时配合 minReadySeconds 让新 Pod 预热。在多次 TKE 异常排查中，因探针参数过短造成的"健康但不可达"并不少见。
监控与日志如何配置
只看 Pod Running 不够，应监控 Endpoint 数量、kube-proxy 同步延迟和安全组命中日志。TKE 需要手动开启组件日志，重点采集 kube-proxy、kube-apiserver。对 kubectl get endpoints 的 Ready 地址数设置告警，IPVS 模式下可定时检查 ipvsadm -Ln 中对应 ClusterIP 后端是否为空。建议地址数连续 2 个检查周期为 0 就通知，不必等业务反馈。
一键诊断工具有哪些
TKE 控制台提供集群检查项，能标记 Service、Endpoint、安全组和网络策略的常见异常；命令行侧可将 kubectl describe svc、kubectl get endpoints、kubectl get networkpolicy 和 ipvsadm 组合成脚本，按"Service → Endpoint → 转发规则 → 安全组"顺序输出。如果团队没精力维护，找像云老大这类服务商做一次整体评估，能把网络链路和告警一起理清。