Kubernetes(k8s)中如何调整Service和Pod之间的流量分配？

在Kubernetes中，Service与Pod之间的流量分配可通过以下方式实现：

1. Service默认负载均衡：Service通过kube-proxy使用轮询（Round Robin）算法分发流量到所有Endpoint Pod。
2. 会话亲和性：设置service.spec.sessionAffinity为ClientIP，使同一客户端IP的请求固定到同一Pod。
3. Ingress控制器：如Nginx Ingress通过注解（nginx.ingress.kubernetes.io/canary-weight）实现基于权重的流量切分。
4. 服务网格（如Istio）：通过VirtualService配置目标子集的流量权重（如80%到v1, 20%到v2），支持动态调整。
5. Pod副本数调整：通过扩缩Deployment的Pod数量间接影响流量比例（需配合无状态服务）。
6. 云服务商方案：如AWS ALB Ingress支持基于权重的路由策略。 高级场景（如金丝雀发布）推荐使用Istio或Ingress控制器进行细粒度控制，原生Service适用于简单负载均衡。

在Kubernetes中调整Service与Pod之间的流量分配，主要依赖以下实践方法及挑战：

1. Service流量分发机制

   • Service通过kube-proxy的iptables/ipvs规则默认采用Round Robin轮询策略。实践中可通过调整EndpointSlice中Pod的权重（需结合自定义控制器），或使用支持动态权重的CNI插件（如Cilium）实现细粒度控制。

2. Ingress控制器扩展

   • Nginx Ingress通过nginx.ingress.kubernetes.io/canary-weight注解实现按百分比分发流量，适用于金丝雀发布。挑战在于需配合Prometheus监控确保流量切换时异常率可控。

3. 服务网格方案

   • Istio的VirtualService可定义精确的subset流量比例（如80%/20%），配合DestinationRule进行版本隔离。实践中需注意Envoy sidecar资源消耗增加对Pod密度的影响，曾遇到因未配置Resource Limits导致节点OOM的案例。

4. Pod反亲和性与拓扑分布

   • 通过PodAntiAffinity与topologySpreadConstraints控制Pod分布，间接影响跨可用区的流量分配。挑战在于多集群场景下需与Cluster API配合确保流量本地化。

5. 自定义Endpoint API

   • 高级场景下可编程修改Endpoints对象，动态调整Pod接收流量的优先级。需注意kube-proxy的更新延迟（实测默认1秒间隔可能造成短时流量倾斜）。

关键经验：

• 生产环境必须结合Pod Readiness Gates和PreStop Hook确保流量无损切换
• 使用Argo Rollouts等渐进式交付工具实现自动化流量迁移
• 必须通过Service Level Indicators(SLI)验证流量分配效果，避免仅依赖配置声明

典型故障案例： 曾遇到因未清理旧版Deployment的Pod标签，导致Service同时选中新旧Pod，流量被错误分配到已下线的旧实例。解决方案是采用immutable标签策略并增加变更预检Hook。

在Kubernetes中，Service默认通过轮询（Round Robin）算法均衡流量到后端Pod。要调整流量分配，可通过调整Pod副本数间接影响流量比例，或使用服务网格（如Istio）配置精确的流量权重。

延伸知识点：Istio流量分割配置 Istio通过VirtualService和DestinationRule实现细粒度流量控制。例如，将80%流量路由到v1，20%到v2：

1. DestinationRule定义子集：

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
   name: my-service
   spec:
   host: my-service
   subsets:
   - name: v1
   labels:
     version: v1
   - name: v2
   labels:
     version: v2

2. VirtualService设置权重：

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
   name: my-service
   spec:
   hosts:
   - my-service
   http:
   - route:
   - destination:
       host: my-service
       subset: v1
     weight: 80
   - destination:
       host: my-service
       subset: v2
     weight: 20

   该配置将请求按比例分发到不同版本的Pod，适用于金丝雀发布和A/B测试场景。

通过调整Service的selector匹配不同Pod标签，结合Deployment的副本数或使用Ingress控制器实现流量权重分配；利用Service Mesh（如Istio）可细粒度控制流量比例。