Kubernetes on Yeqown

Kubernetes 拓扑感知调度与就近访问

Wed, 08 Jul 2026 09:38:56 +0800

topologySpreadConstraints 和 trafficDistribution 都在解决 Kubernetes 集群里的拓扑感知问题，但它们所在的层次不同：

topologySpreadConstraints 作用在调度阶段，决定 Pod 应该如何分散到不同的可用区（zone）、节点（node）或自定义拓扑域。
trafficDistribution 作用在 Service 转发阶段，决定客户端访问 Service 时是否优先选择同可用区或同节点的 Endpoint。

前者解决“后端是否按拓扑域铺开”，后者解决“流量是否优先走近端后端”。如果只配置就近访问，而没有保证各个拓扑域内都有足够 Endpoint，最终很容易把局部流量压到少量 Pod 上。

本文基于 Kubernetes v1.36 的文档和上游源码，先从使用方式讲起，再进入实现细节。

阅读说明

为了避免把不同版本和不同转发实现混在一起，本文先约定几个边界：

Kubernetes 版本以 v1.36.0 为准，源码片段也对应这个版本。其他小版本的字段状态、feature gate 和源码路径可能存在差异。

trafficDistribution 依赖 EndpointSlice hints，以及 kube-proxy 或兼容实现对这些 hints 的支持。若集群使用 eBPF dataplane、第三方 Service 实现或云厂商托管代理，需要以对应实现和实测结果为准。

本文主要讨论 Kubernetes 原生的 Service 转发路径；Service Mesh 场景会单独说明，因为 mesh 数据面可能绕过 kube-proxy 自行选择 Endpoint。

下文中的 API 字段和值保留英文，例如 topologySpreadConstraints、PreferSameZone；概念性表述优先使用中文，例如“可用区”“节点”“同可用区”“同节点”。第一次出现时会保留常见英文缩写，便于和官方文档对应。

1. 背景：可用区和跨区流量#

1.1 可用区是什么#

在云厂商的基础设施里，Region 通常表示一个地理区域，Availability Zone 表示 Region 内相互隔离的一组机房资源。不同可用区之间一般具备独立的供电、网络和故障边界，但仍然可以通过区域内网络互通。

在 Kubernetes 中实现 gRPC 流量的镜像和对比

Thu, 08 May 2025 09:35:14 +0800

本文主要解决在服务重构过程中如何保证新旧服务行为一致性的问题。

场景描述#

现有一个 python 开发的 gRPC 微服务提供了一些 数据查询 接口供上层应用使用，随着业务流量的增加运维这个服务的成本也逐渐增加，为了降低运维成本和提高性能 (木有擅长 python 高性能的开发)，因此选择了使用 go 语言对这个服务进行重写。在开发完成之后，需要对新服务的 gRPC 接口进行验证。

这种场景对测试开发人员来说，实在是太熟悉了吧？典型的 重放验证，马上能想到的验证手段就是：

如果有存量的单元测试，那么直接重新跑一遍单元测试就能快速的完成验证。
没有单元测试的情况，那么可以将新服务部署起来，通过流量复制的方式将旧服务的流量复制到新服务上，然后对比两个服务的返回结果是否一致。

flowchart LR
    %% 定义布局方向和间距
    subgraph s1["方案一: 单元测试验证"]
        direction TB
        UT[单元测试] -->|执行| NS1[新服务]
    end
    
    subgraph s2["方案二: 流量复制验证"]
        direction TB
        C[客户端] -->|请求| OS[旧服务]
        OS -->|响应| C
        OS -->|复制流量| NS2[新服务]
        NS2 -->|对比响应| OS
    end

    %% 设置布局方向和对齐方式
    s1 ~~~ s2

但是很遗憾 😭，并没有成熟的单元测试；测试人员也都是人肉测试，对于内部服务的接口验证帮助不大，因此这里采用第二种方式进行验证。

服务均采用 Kubernetes 部署。

方案介绍#

HTTP 流量的复制重放工具就很多很成熟了，而且往往在网关/代理一侧就能实现流量复制甚至对比。

工具	分类	文档链接
Nginx mirror	网关/代理	https://nginx.org/en/docs/http/ngx_http_mirror_module.html
APISIX	网关/代理	https://apisix.apache.org/docs/apisix/plugins/proxy-mirror/
Istio: Virtual Service mirror	Service Mesh	https://istio.io/latest/docs/tasks/traffic-management/mirroring/
GoReplay	流量镜像	https://github.com/buger/goreplay
tcpcopy	流量镜像	https://github.com/session-replay-tools/tcpcopy

tcpcopy 相比于其他工具方案，虽然不能直接使用，但是其作用于 TCP 传输层，功能会更丰富。相比之下，gRPC 流量复制工具就没有那么成熟了。

Istio Idle Timeout问题复现和解决

Mon, 25 Mar 2024 09:37:25 +0800

更新#

更新 2024-04-01#

通过调整 tcp_proxy 的 idle_timeout 参数后，部分中间件（redis, mongo）的异常问题不再出现，但是 mysql(sharding-spere) 和 memcached 仍然存在 “invalid connection” 错误，所以还需要找到能够解决 mysql(sharding-spere) 和 memcached 的方法。

上述描述的现象非常主观，不一定正确也不能作为最终结论，但是 idle_timeout 配置确实没有解决所有的问题。

这里，需要知道 istio 在 inject 时会通过 iptables 对应用的流量进行劫持，对于 outbound 的流量 iptables 规则拦截转发到 OUTPUT 链。OUTPUT 的链转发流量到 ISTIO_OUTPUT，这个链会决定服务访问外部服务的流量发往何处。

这样产生的效果是，除了应用自己建立的连接之外 envoy 也会创建一个代理连接。

$ netstat -notp | grep 3307
tcp         0             172.23.105.25:41030        x.x.x.x:3307         ESTABLISHED -      off(0.00/0/0)
tcp         0             172.23.105.25:41022        x.x.x.x:3307         ESTABLISHED 1/./app      keepalive(0.88/0/0)

我遇到的问题可以确定问题就出在 envoy 建立的连接上，因为应用自己建立的连接是正常的，同时还可以看到应用自己的连接开启了 keepalive, 而 envoy 建立的连接没有开启。这样可能会出现这个连接会因为超时而被关闭的情况，或者其他原因导致连接被释放。那如果可以避免将中间件的流量通过 envoy 代理，这样就可以避免这个问题。

在官方的文档中也提到，https://istio.io/latest/zh/docs/tasks/traffic-management/egress/egress-control/ 对于外部服务，可以通过配置 excludeOutboundPorts 或者 excludeOutboundIPRanges 来使得某些服务的流量不经过 istio sidecar。其背后的原理是通过 iptables 的规则中排除这些端口或者 IP 地址。

Kubernetes中gRPC Load Balancing分析和解决

Tue, 22 Sep 2020 13:33:20 +0800

背景#

第一次，线上遇到大量接口RT超过10s触发了系统告警，运维反馈k8s集群无异常，负载无明显上升。将报警接口相关的服务重启一番后发现并无改善。但是开发人员使用链路追踪系统发现，比较慢的请求总是某个gRPC服务中的几个POD导致，由其他POD处理的请求并不会出现超时告警。

第二次，同样遇到接口RT超过阈值触发告警，从k8s中查到某个gRPC服务（关键服务）重启次数异常，查看重启原因时发现是OOM Killed，OOM killed并不是负载不均衡直接导致的，但是也有一定的关系，这个后面再说。前两次由于监控不够完善（于我而言，运维的很多面板都没有权限，没办法排查）。期间利用pprof分析了该服务内存泄漏点，并修复上线观察。经过第二次问题并解决之后，线上超时告警恢复正常水平，但是该 deployment 下的几个POD占用资源（Mem / CPU / Network-IO），差距甚大。

第二张图是运维第一次发现该服务OOM killed 之后调整了内存上限从 512MB => 1G，然而只是让它死得慢一点而已。从上面两张图能够石锤的是该服务一定存在内存泄漏。Go项目内存占用的分析，我总结了如下的排查步骤：

1. 代码泄漏（pprof）（可能原因 goroutine泄漏；闭包）
2. Go Runtime + Linux 内核（RSS虚高导致OOM）https://github.com/golang/go/issues/23687
3. 采集指标不正常（container_memory_working_set_bytes）

2，3 是基于第1点能基本排除代码问题的后续步骤。

解决和排查手段：

1. pprof 通过heap + goroutine 是否异常，来定位泄漏点
运行`go tool pprof`命令时加上--nodefration=0.05参数，表示如果调用的子函数使用的CPU、memory不超过 5%，就忽略它。

2. 确认go版本和内核版本，确认是否开启了MADV_FREE，导致RSS下降不及时(1.12+ 和 linux内核版本大于 4.5)。

3.  RSS + Cache 内存检查

> Cache 过大的原因 https://www.cnblogs.com/zh94/p/11922714.html 
// IO密集：手动释放或者定期重启

查看服务器内存使用情况： `free -g`
查看进程内存情况：      `pidstat -rI -p 13744`
查看进程打开的文件：    `lsof -p 13744`
查看容器内的PID：      `docker inspect --format "{{ .State.Pid}}" 6e7efbb80a9d`
查看进程树，找到目标:   `pstree -p 13744`

参考：https://eddycjy.com/posts/why-container-memory-exceed/

通过上述步骤，我发现了该POD被OOM killed还有另一个元凶就是，日志文件占用。这里就不过多的详述了，搜索方向是 “一个运行中程序在内存中如何组织 + Cache内存是由哪些部分构成的”。这部分要达到的目标是：一个程序运行起来它为什么占用了这么些内存，而不是更多或者更少。