kube-watch概要设计

未分类

选型及可靠性分析

为什么监听etcd而不是k8s?
-当前k8s watch机制在发生异常(网络闪断、进程挂掉等)的时候，再次重连时会拿到全量版本，因此会出现两次全量版本merge的问题，与此同时k8s又没有提供部分同步(增量同步)的机制，导致问题难以解决。而在etcd的watch api中，可以制定afterIndex参数同时etcd默认保存1000个历史event，在一定程度上解决了部分同步的问题。
kubeWatch服务的功能定位？
-类似于etcd的代理，本身是无状态的，由client端来决定如何使用etcd watch watch的api(进行存储或者其他)，kubewatch可以被认为是增强k8s能力的系统服务，与k8s本身形成闭环。
如何做HA？
-和架构图中api-server的HA方式类似，采用lease机制，这一点可以直接使用etcd的api或者借鉴k8s是如何实现的。

可靠性分析

1. 单节点master的情况下，kubewatch不存在HA，如果kubewatch挂了，由master保证其一定程度上的可靠性，由于其本身无状态因此也比较好处理，而由于一般重启比较快速，也不会超过etcd保存1000条历史event的限制。
2. 多节点HA的情况下，当主kubewatch服务挂了，其他服务不受影响，在主服务lease时间过后，kubewatch服务对client端来说仍然可用。

主要流程

1. kubewatch服务的配置通过k8s的yaml文件配置即可，作为系统服务由master节点进行管理。
2. kubewatch调用etcd watch api去获取k8s中资源的变化
3. Client通过kubewatch提供的HTTP API去获取某段时间后的event进行自己的逻辑处理。

设计到的API

kubewatch本身是无状态的，其本身主要完成etcd watch到的数据模型到k8s watch模型的转换工作。
1. Kubernetes使用etcd v3的API操作etcd中的数据。所有的资源对象都保存在/registry路径下，如下：

ThirdPartyResourceData
apiextensions.k8s.io
apiregistration.k8s.io
certificatesigningrequests
clusterrolebindings
clusterroles
configmaps
controllerrevisions
controllers
daemonsets
deployments
events
horizontalpodautoscalers
ingress
limitranges
minions
monitoring.coreos.com
namespaces
persistentvolumeclaims
persistentvolumes
poddisruptionbudgets
pods
ranges
replicasets
resourcequotas
rolebindings
roles
secrets
serviceaccounts
services
statefulsets
storageclasses
thirdpartyresources

kubewatch根据自身需要watch不同路径，具体可以在yaml文件中配置监听哪种资源类型。
依赖watch来增量同步，需要保证watch不丢掉中间改动。这个可以通过WatcherOptions上的AfterIndex属性来实现，Index就是etcd node的版本。etcd v2 只有节点级别的版本，v3 才有全仓库的版本。
2. lease机制：单master部署时不需要，参考k8s如何实现
3. 探活机制: 与etcd之间的网络连接，当网络断开时，定制自己的重连策略。
4. func HTTP Get:->(afterIndex, "查询此时间戳之后的数据", type, "查询的资源类型")