前言
最早是认为 kubernetes 中 controller 模式 informer 中 resync 是 controller 定时和 api-server 去同步，保证数据的一致性的。后来发现其实不是。下面我们来一一说下。
controller 和 api-server 是不需要定期同步来保证数据的一致性的
参考下面这段话：
Programming Kubernetes 第三章 client-go 的 Informers and Caching
The resync is purely in-memory and does not trigger a call to the server. This used to be different but was eventually changed because the error behavior of the watch mechanism had been improved enough to make relists unnecessary.
Informers also have advanced error behavior: when the long-running watch connection breaks down, they recover from it by trying another watch request, picking up the event stream without losing any events. If the outage is long, and the API server lost events because etcd purged them from its database before the new watch request was successful, the informer will relist all objects.
Next to relists, there is a configurable resync period for reconciliation between the in-memory cache and the business logic: the registered event handlers will be called for all objects each time this period has passed. Common values are in minutes (e.g., 10 or 30 minutes).
我记得之前也看过 blog ，最早 kubernetes controller 是有定期和 api-server 同步来保证数据一致性的，但是现在 watch 机制已经改良了，定期同步这个机制是没有必要的。
上面文字也说了，resync 是为了 reconcile 业务逻辑和内存缓存（ 最近一次 relist 的结果 ）的。
如果resync 是为了 reconcile 业务逻辑和内存缓存，那么为什么有的 controller 会有对比 ResourceVersion 的步骤
我觉得如果要 reconcile 业务逻辑和内存缓存，就应该把所有的 event 都放到 workqueue 中，但是实际查看有的 controller 中是会比较一下 ResourceVersion，可以先看下我提的这个 issue