Kubernetes集群基于IP地址的流量分流方案咨询

这个需求有成熟的可落地实现方案，不需要临时单独暴露待测试Pod的IP对外访问，以下是3种不同场景下的常用方案：

方案1：基于Ingress控制器实现（最常用，无额外组件依赖） #

绝大多数主流Ingress控制器（Nginx Ingress、Traefik、HAProxy Ingress等）都原生支持基于来源IP的流量拆分规则，你只需要提前创建两个ClusterIP类型的Service，分别绑定待测试Pod和维护提示Pod，再通过Ingress规则配置流量匹配逻辑即可。
以Nginx Ingress为例，参考配置如下：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-migrate-ingress
  annotations:
    # 开启真实客户端IP获取（如果集群入口有前置代理需要加此配置）
    nginx.ingress.kubernetes.io/enable-real-ip: "true"
    nginx.ingress.kubernetes.io/server-snippet: |
      # 替换为你的内部测试IP段
      set $internal_ip_range "192.168.0.0/16 10.0.0.0/8 172.16.0.0/12";
      if ($remote_addr !~* $internal_ip_range) {
        # 非内部IP全部转发到维护提示服务
        proxy_pass http://maintenance-svc.default.svc.cluster.local:80;
        break;
      }
spec:
  rules:
  - host: your-business-domain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            # 内部IP默认转发到待测试服务
            name: test-target-svc
            port:
              number: 80

测试完成后删除对应annotation、将后端Service替换为正式服务即可完成上线，全程不需要改动业务Pod配置。

方案2：基于服务网格实现（适合已部署Istio/Linkerd的集群） #

如果集群已经部署了服务网格组件，可以直接通过VirtualService配置更灵活的流量规则，后续还可以无缝扩展灰度发布、流量染色等能力：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: app-migrate-vs
spec:
  hosts:
  - your-business-domain.com
  http:
  - match:
    - ip:
        blocks:
        # 替换为内部测试IP段
        - 192.168.0.0/16
        - 10.0.0.0/8
    route:
    - destination:
        host: test-target-svc.default.svc.cluster.local
  - route:
    - destination:
        host: maintenance-svc.default.svc.cluster.local

方案3：基于NetworkPolicy+临时Service实现（适合无Ingress的场景） #

如果集群没有部署Ingress控制器，也可以为待测试Pod创建一个NodePort/LoadBalancer类型的临时Service，同时配置NetworkPolicy限制仅内部IP段可以访问该Service，对外的正式业务入口仍然指向维护提示Pod即可。测试完成后删除临时Service和NetworkPolicy即可，不会对外暴露测试服务。

注意如果集群入口有前置CDN、WAF等七层代理，需要提前配置代理透传真实客户端IP，避免来源IP判断逻辑失效。

内容的提问来源于stack exchange，提问作者Jake Conkerton-Darby