@myecho
2018-10-12T19:55:14.000000Z
字数 1615
阅读 951
未分类
为什么监听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是如何实现的。
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, "查询的资源类型")