[Feature Proposal] Apollo with Kubernetes Service Discovery

[nobodyiam]

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列表从而保留负载均衡逻辑，不过缺点是对一些生态工具的引入会有影响。

[JaredTan95]

原来的 Eureka 方式是否兼容还是直接转向 Kubernetes？

[nobodyiam]

非 K8S 环境下仍然使用 Eureka，在 K8S 环境下建议使用原生的方式，不过用户应该也可以继续使用statefulset 来实现 Eureka 作为服务注册中心

[JaredTan95]

简单地理解为Apollo 通过SPI 的方式选择 Eureka 还是 Kubernetes 来切换 Apollo 内部服务发现逻辑？

[nobodyiam]

是的

[helloworldtang]

期待

[qixiaobo]

So glad to hear about this~

[lianfulei]

ok，我在k8s部署一下

[kayyellow]

所以k8s部署还需要配置 eureka.service.url吗，根据 apollo-on-kubernetes 这个部署好服务后，去掉eureka.service.url后服务是不能正常工作的

[nobodyiam]

@kayyellow 可以参考基于Kubernetes原生服务发现

[kayyellow]

@kayyellow 可以参考基于Kubernetes原生服务发现

ok，已成功

[kayyellow]

”为了减少对Client和Portal的影响，依然保留了Meta Service角色负责Config Service和Admin Service的寻址“， 请问 k8s部署方式，这里的影响主要是哪些呢，兼容？

[nobodyiam]

@kayyellow client 和 portal 始终从 meta service 获取 config service 和 admin service 的地址，所以保留了 meta service 这一角色，如果不保留该角色的话，client 和 portal 就要修改寻址方式了（比如直接配置 Service 地址）

[kayyellow]

@kayyellow client 和 portal 始终从 meta service 获取 config service 和 admin service 的地址，所以保留了 meta service 这一角色，如果不保留该角色的话，client 和 portal 就要修改寻址方式了（比如直接配置 Service 地址）

明白了，thx