基于Kubernetes服务发现机制的探讨Non Service

服务注册

注册中⼼作为一般的RPC/Web服务中的底层设施提供了服务进程元数据（IP, Port, Interface, Group,Method等）存储，被Watch的功能，每个服务进程均需接⼊同⼀组持久化的K/V介质集群（⽐如: zookeeper,etcdv3等)。各进程均需将本进程的元数据存储于注册中⼼，并且能够Watch到其他服务进程的元数据变化（包括创建，更新等）。

Kubernetes

Kubernetes作为容器集群化管理⽅案管理资源的维度可主观的分为服务进程管理和服务接⼊管理。服务进程管理，主要体现⽅式为Pod设计模式加控制器模式，控制器保证具有特定标签（Kubernetes-Label）的Pod保持在恒定的数量（多删，少补）。服务接⼊管理，主要为Kubernetes-Service，该Service默认为具有特定标签（KubernetesLabel）的Pod统⼀提供⼀个VIP（Kubernetes-ClusterIP）所有需要请求该组Pod的请求都会按照round-robin的负载策略转发到真正提供服务的Pod。并且CoreDNS为该Kubernetes-Service提供集群内唯⼀的域名。

Service 与 RPC/Web服务存在的冲突点

• Kubernetes-Service标准的资源对象具有的服务描述字段 中并未提供完整的服务进程元数据字段因此，⽆法直接使⽤Kubernetes-Service进⾏服务注册与发现。
• RPC/Web服务的服务注册是基于每个进程的，每个服务进程均需进⾏独⽴的注册。
• Kubernetes-Service默认为服务创建VIP，提供round-robin的负载策略也与RPC/Web服务⾃有的负载策略形成了冲突。

抛弃Service对象，选择Pod对象进⾏注册

• Kubernetes-Service与RPC/Web服务现有架构的冲突导致RPC/Web服务在选择服务注册与发现的时候只能选择放弃该资源对象。
• RPC/Web服务既然选择了每个RPC/Web服务进程独⽴注册，因此RPC/Web服务选择将该进程具有的独有的元数据写⼊运⾏该RPC/Web服务进程的Pod在Kubernetes中的Pod资源对象的描述信息中。
• 每个运⾏RPC/Web服务进程的Pod将本进程的元数据写⼊Kubernetes-Pod Annotations字段。为了避免与其他使⽤Annotations字段的Operator或者其他类型的控制器（Istio）的字段冲突，使⽤Key为 app.io/annotation value为具体存储的K/V对的数组的json编码后的base64
  
  编码。

样例：

apiVersion: v1
kind: Pod
metadata:
 annotations:
    app.io/annotation: 5LiN55So55yL5LqG5bCx5piv5LiA5Liq5paH5pys5Y2P6K6u

由于每个RPC/Web服务的Pod均只负责注册本进程的元数据，因此Annotations字段⻓度也不会因为运⾏RPC/Web服务进程的Pod数量增加⽽增加。

服务发现

解决掉了服务注册问题，接下来需要解决的是服务发现的问题。Kubernetes Api-Server提供了Watch的功能，可以观察特定namespace甚⾄整个集群内各类资源的变化。RPC/Web服务为了避免RPC/Web服务进程watch到与RPC/Web服务进程⽆关的Pod的变化，RPC/Web服务将watch的条件限制在当前Pod所在的namespace，以及 watch 具有 app.io/label Value为app.io-value 的Pod。在Watch到对应Pod的变化后实时更新本地Cache，并通过Registry提供的Subscribe通知建⽴在注册中⼼之上的服务集群管理，或者其他功能。

⼯作流程

• 启动RPC/Web服务的Deployment或其他类型控制器使⽤Kubernetes Downward-Api将本Pod所在namespace通过环境变量的形式注⼊RPC/Web服务进程。

• RPC/Web服务进程的Pod启动后通过环境变量获得当前的namespace以及该Pod名称， 调⽤
  
  Kubernetes-Apiserver PATCH 功能为本Pod添加Key为app.io/label Value为app.io-value的label。

• RPC/Web服务进程调⽤Kubernetes-Apiserver 将本进程的元数据通过PATCH接⼝写⼊当前Pod的Annotations字段。

• RPC/Web服务进程 LIST 当前namespace下其他具有同样标签的Pod，并解码对应的Annotations字段获取其他Pod的信息。

• RPC/Web服务进程 WATCH 当前namespace下其他具有同样标签的Pod的Annotations的字段变化。

总结

Kubernetes已经为其承载的服务提供了⼀套服务发现，服务注册，以及服务集群管理机制,⽽传统基于注册中心的服务，同时也拥有⾃成体系的服务集群管理。这两个功能点形成了冲突，在⽆法调谐两者的情况，如果选择保持⾃有的服务集群管理系，放弃Kubernetes-Service功能，将元数据直接写⼊到Kubernetes Pod内，依赖Kubernetes提供的Watch功能提供维护服务集群状态，也是不错的选择。