数据一致性

List-Watch保证数据的最终一致性。
List-Watch机制通过以下几点来保证数据的一致性：

  1. Periodic Resync: 定期重新同步。客户端定期(默认5分钟)调用list接口获取API Server的完整资源列表,并与本地缓存进行对比,修复任何不一致状态。这可以解决因网络问题导致的事件丢失和同步状态不一致的问题。
  2. Resource Version: 资源版本。watch接口可以通过resourceVersion参数指定从哪个版本开始观察变化。如果客户端观察到 clearly 超出资源版本的事件,意味着有事件丢失,此时应重新list以修复同步状态。
  3. Reconnecting: 重新连接。如果watch接口出现故障,客户端将自动进行重连。重连时会重新指定正确的resourceVersion,以避免重复观察之前的事件。
  4. Cache Timeouts: 缓存超时。客户端会为其本地缓存对象设置超时时间。如果在超时时间内未收到对象的更新事件,意味着对象可能被删除,此时应重新list以确定对象的最新状态。
  5. 丢弃 clearly 超出对象以知版本的事件。如果客户端观察到 resourceVersion 遥遥领先的事件,意味着中间有大量事件丢失,此时不应应用该事件,而是重新list以修复同步状态。
  6. 只同步最近的事件。即使list返回了全部历史对象,客户端也只将资源列表更新为最近的那个“快照”版本,而非重放完整的历史修改。只同步最近版本可以避免产生与当前API Server状态不一致的本地缓存。通过上述几点机制,List-Watch能够尽量避免和修复不同步状态,保证客户端本地缓存与API Server的数据一致性。但同时也要认识到,这只是一种“最终一致性”(Eventually Consistent)模型,不能绝对保证100%的强一致性。

Informer实现

[Pasted image 20230529110721.png]

Resync

Informer启动时只会从etcd list一次全量数据，后面缓存全部都只走watch来更新，resync其实也只是将本地缓存的数据再构造成事件再次同步到队列一次

参考文档

  1. Informer 中为什么需要引入 Resync 机制？
  2. Kubernetes Informer 详解
  3. 理解 K8S 的设计精髓之 List-Watch机制和Informer模块