EKS集群应用同时支持集群内与对等VPC访问的服务选型咨询

你不需要创建2个服务，单个内部Network Load Balancer（Internal NLB）类型的K8s Service即可同时满足集群内、跨VPC访问两种需求，是当前场景下最推荐的实现方式。

各方案可行性分析 #

双服务方案（ClusterIP+公网LoadBalancer）：完全没必要 #

你提到的双服务配置会带来额外的维护成本，还可能出现两套访问入口的权限策略、版本对齐等问题，完全可以用单服务替代，且你原有配置里的external类型LB会生成公网入口，不符合内网跨VPC访问的安全需求。

单服务可选方案对比 #

• ClusterIP类型：仅满足集群内访问需求，跨VPC场景不可用。EKS的ClusterIP网段属于K8s内部网段，默认不会同步到VPC路由表，旧VPC的EC2无法通过对等连接路由到ClusterIP，除非手动配置两个VPC的路由规则、额外做DNS解析适配，配置成本极高，不推荐。
• NodePort类型：虽然旧VPC的EC2可以通过EKS节点的内网IP+NodePort访问，但缺陷非常明显：端口只能使用30000-32767的固定段、需要手动维护节点IP的负载均衡、节点故障会导致访问入口失效、安全组需要放开大范围端口的访问权限，风险高，不推荐。
• Internal NLB类型（推荐）：只需在你原有配置的基础上增加内部LB的注解即可，完整注解配置如下：

annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: external
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
    service.beta.kubernetes.io/aws-load-balancer-internal: "true"

该方案的优势：

• 集群内访问无兼容问题：K8s会自动完成服务域名解析，集群内Pod可以直接通过Service名访问，和普通ClusterIP的使用体验完全一致。
• 跨VPC访问天然支持：两个VPC已经配置了对等连接，只要路由表、安全组规则放通旧VPC到NLB的访问，旧VPC的EC2可以直接通过NLB的内网DNS名访问服务，全程走内网，无公网带宽成本、 latency更低、安全性更高。
• 运维成本低：AWS会自动维护NLB的可用性，无需关注EKS节点的生命周期变化，一套配置覆盖所有访问场景。

额外注意事项 #

确保两个VPC的路由表都配置了对方CIDR指向对等连接的规则，同时NLB关联的安全组需要放通集群内部CIDR、旧VPC CIDR的对应端口访问请求。如果需要旧VPC的EC2可以直接解析K8s Service的域名，可以将EKS所在VPC的Route53私有托管区关联到旧VPC即可。

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