K3D/K3S环境下curl与浏览器访问LoadBalancer服务的差异问题

核心差异：TCP连接的复用策略 #

• curl 每次请求都会新建独立的TCP连接，请求完成后立刻断开。K3S的Service默认采用**轮询（Round Robin）**策略分配后端Pod，每个新连接都会被导向下一个Pod，所以每次返回的Pod IP都不一样。
• 浏览器默认开启HTTP/1.1的Keep-Alive（持久连接），刷新页面时会复用已建立的TCP连接，同一个连接里的所有请求都会被转发到同一个Pod。只有当这个连接因闲置超时（通常几分钟）被服务器或浏览器关闭，或者浏览器重启后新建连接时，才会被分配到新的Pod，这就是你看到偶尔变更的原因。

底层逻辑：K3D与K3S的负载均衡协同 #

K3D的负载均衡器把外部请求转发给K3S的Service，K3S的kube-proxy负责Service层面的负载均衡：

• 遇到新TCP连接时，kube-proxy按轮询规则挑选后端Pod；
• 对于已建立的长连接，kube-proxy不会重新分配Pod，会一直将该连接的请求导向同一个后端，直到连接终止。

浏览器端的具体行为 #

浏览器自动启用了持久连接机制，刷新页面时不会每次新建TCP连接，而是复用之前的连接。只有当连接长时间无活动被自动关闭，或者浏览器进程重启时，才会创建新的TCP连接，此时kube-proxy才会重新轮选Pod处理请求。

内容的提问来源于stack exchange，提问作者dash1e