Is your feature request related to a problem? Please describe.
Apollo作为非常底层的基础设施，对可用性要求非常高，所以从设计之初就极力降低对外部的依赖，其中就包括通过内置Eureka来实现服务发现：
上图是Apollo的整体架构，可以看到Eureka在其中担当了非常重要的角色。
该架构在非K8S环境下比较自然，运行良好。不过在K8S环境下，由于需要配置eureka.service.url，所以采用了statefulset来部署config service，一方面带来了运维的复杂度，另一方面也脱离了k8s自身的服务发现体系，无法享受生态红利，社区中对此也有一些讨论：#2666，#2903。
Describe the solution you'd like
当部署在Kubernetes环境中，可以借助于K8S原生的Service、健康检查等来实现服务发现和通信，从而可以一方面简化部署复杂度，另一方面可以享受生态红利，如Istio。
如上图所示，Eureka已经从整体架构中消失，取而代之的是Kubernetes的Service。为了减少对Client和Portal的影响，依然保留了Meta Service角色负责Config Service和Admin Service的寻址，区别在于在K8S环境下，返回的并不是单节点的地址，而是对应的服务内部域名，客户端在DNS解析后最终通过clusterIp来访问服务。
Describe alternatives you've considered
上述方案最终通过clusterIp来访问服务，对客户端而言，访问的始终是同一个IP，客户端不再有负载均衡逻辑，灵活度有所降低，不过优点是能够无缝对接生态体系，如Istio。
另一种方案是使用spring-cloud-kubernetes，优点是客户端能够获取到Pod列表从而保留负载均衡逻辑，不过缺点是对一些生态工具的引入会有影响。
Is your feature request related to a problem? Please describe.
Apollo作为非常底层的基础设施，对可用性要求非常高，所以从设计之初就极力降低对外部的依赖，其中就包括通过内置Eureka来实现服务发现：
上图是Apollo的整体架构，可以看到Eureka在其中担当了非常重要的角色。
该架构在非K8S环境下比较自然，运行良好。不过在K8S环境下，由于需要配置
eureka.service.url，所以采用了statefulset来部署config service，一方面带来了运维的复杂度，另一方面也脱离了k8s自身的服务发现体系，无法享受生态红利，社区中对此也有一些讨论：#2666，#2903。Describe the solution you'd like
当部署在Kubernetes环境中，可以借助于K8S原生的Service、健康检查等来实现服务发现和通信，从而可以一方面简化部署复杂度，另一方面可以享受生态红利，如Istio。
如上图所示，Eureka已经从整体架构中消失，取而代之的是Kubernetes的Service。为了减少对Client和Portal的影响，依然保留了Meta Service角色负责Config Service和Admin Service的寻址，区别在于在K8S环境下，返回的并不是单节点的地址，而是对应的服务内部域名，客户端在DNS解析后最终通过clusterIp来访问服务。
Describe alternatives you've considered
上述方案最终通过clusterIp来访问服务，对客户端而言，访问的始终是同一个IP，客户端不再有负载均衡逻辑，灵活度有所降低，不过优点是能够无缝对接生态体系，如Istio。
另一种方案是使用spring-cloud-kubernetes，优点是客户端能够获取到Pod列表从而保留负载均衡逻辑，不过缺点是对一些生态工具的引入会有影响。