注册中⼼作为一般的RPC/Web服务中的底层设施提供了服务进程元数据(IP, Port, Interface, Group,Method等)存储,被Watch的功能,每个服务进程均需接⼊同⼀组持久化的K/V介质集群(⽐如: zookeeper,etcdv3等)。各进程均需将本进程的元数据存储于注册中⼼,并且能够Watch到其他服务进程的元数据变化(包括创建,更新等)。
Kubernetes作为容器集群化管理⽅案管理资源的维度可主观的分为服务进程管理和服务接⼊管理。服务进程管理,主要体现⽅式为Pod设计模式加控制器模式,控制器保证具有特定标签(Kubernetes-Label)的Pod保持在恒定的数量(多删,少补)。服务接⼊管理,主要为Kubernetes-Service,该Service默认为具有特定标签(KubernetesLabel)的Pod统⼀提供⼀个VIP(Kubernetes-ClusterIP)所有需要请求该组Pod的请求都会按照round-robin的负载策略转发到真正提供服务的Pod。并且CoreDNS为该Kubernetes-Service提供集群内唯⼀的域名。
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通知建⽴在注册中⼼之上的服务集群管理,或者其他功能。
Kubernetes已经为其承载的服务提供了⼀套服务发现,服务注册,以及服务集群管理机制,⽽传统基于注册中心的服务,同时也拥有⾃成体系的服务集群管理。这两个功能点形成了冲突,在⽆法调谐两者的情况,如果选择保持⾃有的服务集群管理系,放弃Kubernetes-Service功能,将元数据直接写⼊到Kubernetes Pod内,依赖Kubernetes提供的Watch功能提供维护服务集群状态,也是不错的选择。