【提问】Resync 后将 Indexer 本地缓存放入 Delta FIFO 队列中，触发 update 回调，入参的 old 和 new 是一样的吗？

[lianghao208]

问题描述

Resync 机制会定时将 Indexer 本地缓存重新放入 Delta FIFO 队列中，然后触发 controller 的 update 回调。update 函数的入参有 old 和 new，此时 old 和 new 都是指 indexer 缓存中的同一个元素吗？相关代码我贴在下面，也注释说明了 Resync 的回调逻辑。

相关代码

// k8s.io/client-go/tools/cache/shared_informer.go
func (s *sharedIndexInformer) HandleDeltas(obj interface{}) error {
	s.blockDeltas.Lock()
	defer s.blockDeltas.Unlock()

	// from oldest to newest
	for _, d := range obj.(Deltas) {
		// 判断事件类型，看事件是通过新增、更新、替换、删除还是 Resync 重新同步产生的
		switch d.Type {
		case Sync, Replaced, Added, Updated:
			s.cacheMutationDetector.AddObject(d.Object)
			if old, exists, err := s.indexer.Get(d.Object); err == nil && exists {
				if err := s.indexer.Update(d.Object); err != nil {
					return err
				}
				
				isSync := false
				switch {
				case d.Type == Sync:
					// 如果是通过 Resync 重新同步得到的事件则做个标记
					isSync = true
				case d.Type == Replaced:
					...
				}
				// 如果是通过 Resync 重新同步得到的事件，则触发 onUpdate 回调
				s.processor.distribute(updateNotification{oldObj: old, newObj: d.Object}, isSync)
			} else {
				if err := s.indexer.Add(d.Object); err != nil {
					return err
				}
                                // 这里触发 controller 的 update 回调，传入 new 和 old 对象，是否为同一个元素？
				s.processor.distribute(addNotification{newObj: d.Object}, false)
			}
		case Deleted:
			if err := s.indexer.Delete(d.Object); err != nil {
				return err
			}
			s.processor.distribute(deleteNotification{oldObj: d.Object}, false)
		}
	}
	return nil
}

[sundongmin]

传递给oldObj是从indexer取到的
传递给newObj是从deltaFIFOpop出来的

所以不是同一个

[lianghao208]

传递给oldObj是从indexer取到的
传递给newObj是从deltaFIFOpop出来的

所以不是同一个

注意，是 Resync 机制触发的回调，不是通过 Watch apiserver 的 update 事件触发的回调。Resync 机制会将 Indexer 本地缓存重新同步到 Delta FIFO 队列中，如果此时队列存在该对象的 key，则忽略不入队，最后才去触发 update 的回调。

[sundongmin]

好吧, 没看到resync的前提,
又看了下代码, 看样子, 两个参数是一样的.
其他人觉得呢?

[WisWang]

resync 是将最近一次 relist 的结果都传给 deltaFIFO，oldObj 和 newObj 是否一样，主要取决于上次 resync 到这次 resync 的期间发生过 relist 没有。下面就是发生 relist 的场景：

下面引自 programing kubernetes 一书中的第三章 client-go 的 Informers and Caching

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).

[fighterhit]

传递给oldObj是从indexer取到的
传递给newObj是从deltaFIFOpop出来的
所以不是同一个

注意，是 Resync 机制触发的回调，不是通过 Watch apiserver 的 update 事件触发的回调。Resync 机制会将 Indexer 本地缓存重新同步到 Delta FIFO 队列中，如果此时队列存在该对象的 key，则忽略不入队，最后才去触发 update 的回调。

所以如果队列里不存在该对象的 key （也就是没有 relist 过?），那么 oldObj 和 newObj 就是一样的吗？ @WisWang

[WisWang]

传递给oldObj是从indexer取到的
传递给newObj是从deltaFIFOpop出来的
所以不是同一个

注意，是 Resync 机制触发的回调，不是通过 Watch apiserver 的 update 事件触发的回调。Resync 机制会将 Indexer 本地缓存重新同步到 Delta FIFO 队列中，如果此时队列存在该对象的 key，则忽略不入队，最后才去触发 update 的回调。

所以如果队列里不存在该对象的 key （也就是没有 relist 过?），那么 oldObj 和 newObj 就是一样的吗？ @WisWang

@fighterhit 还是没明白你的问题，就这个问题，我找了好久没找到，我就给 kubernetes 提了一个 PR Add compare ResourceVersion process 这个 PR 就有个人回复了一下，但是还没结论，都快三个月了，relist 在 informer 初始化的时候就会发生一次。提完这个 PR 之后我就基本明白了 resync 的作用。

[FinaleH]

传递给oldObj是从indexer取到的
传递给newObj是从deltaFIFOpop出来的
所以不是同一个

注意，是 Resync 机制触发的回调，不是通过 Watch apiserver 的 update 事件触发的回调。Resync 机制会将 Indexer 本地缓存重新同步到 Delta FIFO 队列中，如果此时队列存在该对象的 key，则忽略不入队，最后才去触发 update 的回调。

所以如果队列里不存在该对象的 key （也就是没有 relist 过?），那么 oldObj 和 newObj 就是一样的吗？ @WisWang

@fighterhit 还是没明白你的问题，就这个问题，我找了好久没找到，我就给 kubernetes 提了一个 PR Add compare ResourceVersion process 这个 PR 就有个人回复了一下，但是还没结论，都快三个月了，relist 在 informer 初始化的时候就会发生一次。提完这个 PR 之后我就基本明白了 resync 的作用。

@WisWang 你好，请教一下，如果reSync的作用只是用来处理最近两次relist的不一致问题，考虑到resourceVersion的存在的话，reSync是否是一个不必要的操作？

[callmevincent]

这是来自QQ邮箱的假期自动回复邮件。   您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

[WisWang]

@FinaleH resourceVersion 解决不了最近两次 relist 的不一致问题吧？因为 informer 是走的边缘出发，不是水平触发，不会轮询状态的，可以看下我的这个博客 kubernetes infomer 中的 resync

resync 是将最近一次 relist 的结果都传给 deltaFIFO，oldObj 和 newObj 是否一样，主要取决于上次 resync 到这次 resync 的期间发生过 relist 没有。下面就是发生 relist 的场景：

下面引自 programing kubernetes 一书中的第三章 client-go 的 Informers and Caching

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).

[FinaleH]

感谢你的回复。你的博客我看了，没有看太懂，不好意思。 我现在是这么理解resync的作用的： 1. 生产环境中可能很久才会relist一次，甚至如果不发生故障的话都不会定期relist，所以干脆不考虑relist的因素； 2. 假设一个集群只在init的时候relist一次，之后就不再relist了；若informer的controller调用processor之后的任一环节处理失败且没有反馈失败，将导致资源的最终实际状态与期望状态（即本地缓存中的状态）不一致，此时resync可以重新触发一次资源状态的调整，纠正这个错误。 请问这样理解是否也可以？ 对于resourceVersion解决不了relist不一致的问题，我是直接理解成以resourceVersion大的版本为准的，这个好像是处理不了两次relist间有资源被删除的情况。 ***@***.*** 发件人： Hongzhi 发送时间： 2022-03-24 21:53 收件人： cloudnativeto/sig-kubernetes 抄送： FinaleH; Mention 主题： Re: [cloudnativeto/sig-kubernetes] 【提问】Resync 后将 Indexer 本地缓存放入 Delta FIFO 队列中，触发 update 回调，入参的 old 和 new 是一样的吗？ (#33) @FinaleH resourceVersion 解决不了最近两次 relist 的不一致问题吧？因为 informer 是走的边缘出发，不是水平触发，不会轮询状态的，可以看下我的这个博客 kubernetes infomer 中的 resync resync 是将最近一次 relist 的结果都传给 deltaFIFO，oldObj 和 newObj 是否一样，主要取决于上次 resync 到这次 resync 的期间发生过 relist 没有。下面就是发生 relist 的场景： 下面引自 programing kubernetes 一书中的第三章 client-go 的 Informers and Caching 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). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>