前言
DeltaFIFO是client-go controller framework的重要环节，它的作用是保证Reflector和Indexer之间对象同步。可以说，DeltaFIFO是连接生产者（Reflector）和消费者（Indexer）的通道。阅读本文前希望读者已阅读《client-go源码分析》前面的系列文章，要求已了解Informer和Reflector。
1 DeltaFIFO介绍
DeltaFIFO的定义及创建：
type DeltaFIFO struct {
。。。
items map[string]Deltas
queue []string
keyFunc KeyFunc
knownObjects KeyListerGetter
。。。
}
func NewDeltaFIFO(keyFunc KeyFunc, knownObjects KeyListerGetter) *DeltaFIFO {
f := &DeltaFIFO{
items: map[string]Deltas{},
queue: []string{},
keyFunc: keyFunc,
knownObjects: knownObjects,
}
f.cond.L = &f.lock
return f
}
以简单的示意图描述DeltaFIFO的结构：
DeltaFIFO的核心结构包括items和queue，对应Delta和FIFO。
1.1 Delta
Delta顾名思义是变化和差异，因此items的作用是缓存某个对象的一系列变更行为（Deltas）。正因为这里保存的是Delta(当前对象和前一个对象的差异)，有序地保存一系列行为才有意义，单独的某个Updated状态无法正确同步对象。
items是map结构，key是由keyfunc计算出来的对象key；value是deltas，即delta列表。delta数据结构如下：
type Delta struct {
Type DeltaType
Object interface{}
}
当前版本DeltaType的值只有Added, Updated, Deleted, Sync；Object即runtime.Object。
1.2 FIFO
FIFO即先进先出队列，这里queue仅把对象键（objkey）入列。消费者通过objkey查找items的Deltas并依次同步所有行为。queue是对象同步处理队列，消费者仅处理queue中存在的objkey。
2 DeltaFIFO
基本功能上述已经提到DeltaType只有四种：Added, Updated, Deleted, Sync。这里仅分析最难理解的Sync函数，Sync是List机制和Resync触发的全量同步；Added，Updated，Deleted是Watch触发的增量同步。
2.1 深入理解Sync: Replace()
Sync是比较特殊的处理，理解了Sync也就不难理解其他行为。Sync是指Reflector全量同步Indexer，从DelaFIFO的实现看是调用Replace函数“重建”Indexer。
DelaFIFO的Replace实现了Sync行为（Resync也调用该函数）。controller第一次启动时，Reflector的List机制触发DeltaFIFO的Sync行为，《Client-Go源码分析--Reflector》会提到r.syncWith(items,resourceVersion)函数，该函数调用func (f *DeltaFIFO) Replace(list []interface{},resourceVersion string) error开始分析Replace代码前，先看一个重要的公共函数queueActionLocked，DeltaFIFO的所有行为都会调用它。queueActionLocked的功能是：仅处理某个动作。若处理一系列动作或多个对象，需要外部调用者重复调用它。
func (f *DeltaFIFO) queueActionLocked(actionType DeltaType, obj interface{}) error {
id, err := f.KeyOf(obj)
if err != nil {
return KeyError{obj, err}
}
// If object is supposed to be deleted (last event is Deleted),
// then we should ignore Sync events, because it would result in
// recreation of this object.
// 上一次是deleted类型，且本次是sync，那么说明该对象已经删除了，直接返回nil
if actionType == Sync && f.willObjectBeDeletedLocked(id) {
return nil
}
newDeltas := append(f.items[id], Delta{actionType, obj})
// delete去重，
newDeltas = dedupDeltas(newDeltas)
// item[id]不存在，加入到queue和items中
if len(newDeltas) > 0 {
if _, exists := f.items[id]; !exists {
f.queue = append(f.queue, id)
}
f.items[id] = newDeltas
f.cond.Broadcast()
} else {
// We need to remove this from our map (extra items in the queue are
// ignored if they are not in the map).
delete(f.items, id)
}
return nil
}
// 外部同步缓存的func (f *DeltaFIFO) Replace(list []interface{}, resourceVersion string) error {
f.lock.Lock()
defer f.lock.Unlock()
keys := make(sets.String, len(list))
// 这里是k8s集群中的实际对象集合keys
for _, item := range list {
key, err := f.KeyOf(item)
if err != nil {
return KeyError{item, err}
}
keys.Insert(key)
if err := f.queueActionLocked(Sync, item); err != nil {
return fmt.Errorf("couldn't enqueue object: %v", err)
}
}
if f.knownObjects == nil {
// Do deletion detection against our own list.
for k, oldItem := range f.items {
if keys.Has(k) {
continue
}
var deletedObj interface{}
if n := oldItem.Newest(); n != nil {
deletedObj = n.Object
}
if err := f.queueActionLocked(Deleted, DeletedFinalStateUnknown{k, deletedObj}); err != nil {
return err
}
}
if !f.populated {
f.populated = true
f.initialPopulationCount = len(list)
}
return nil
}
// Detect deletions not already in the queue.
//knownKeys 是indexers中的对象集合，是缓存中的数据
knownKeys := f.knownObjects.ListKeys()
queuedDeletions := 0
for _, k := range knownKeys {
if keys.Has(k) { // k8s集群和indexers缓存中的obj都存在，不处理
continue
}
// indexers中存在obj，但是k8s集群中不存在，删除该obj
deletedObj, exists, err := f.knownObjects.GetByKey(k)
if err != nil {
deletedObj = nil
klog.Errorf("Unexpected error %v during lookup of key %v, placing DeleteFinalStateUnknown marker without object", err, k)
} else if !exists {
deletedObj = nil
klog.Infof("Key %v does not exist in known objects store, placing DeleteFinalStateUnknown marker without object", k)
}
queuedDeletions++
if err := f.queueActionLocked(Deleted, DeletedFinalStateUnknown{k, deletedObj}); err != nil { // Deleted的加入到DeltaFIFO中，删除indexers中的obj对象
return err
}
}
if !f.populated { // 如果populated还没有设置，说明是第一次 并且 还没有任何修改操作执行过
f.populated = true
f.initialPopulationCount = len(list) + queuedDeletions
}
return nil
}
2.2 queueActionLocked的特殊处理分析
上文提到的queueActionLocked特殊处理针对一种场景：obj的id是objkey1，该对象最后一次动作是Deleted，并且objkey1仍在queue中等待处理。此时周期性被动触发一次Resync（会调用Replace）。k8s集群真实的runtime.Object已删除，但Indexer的同步尚未完成，Indexer缓存里仍有这个对象。
假设queueActionLocked更新了deltas如上图（左）所示，该对象会先删除，然后添加回来！从Pop()函数里的回调函数Process可以看到这个过程。前几篇文章已经提到过，Process的入参obj是Deltas队列，该函数依次处理每个Delta行为。当Process处理到上图（左）Deleted时Index会删除对象；当它处理到最后的Sync时，Index又会添加这个对象。因此，queueActionLocked通过特殊处理规避了这个问题，现有代码的处理方式如上图（右）所示，直接返回不更新deltas。
2.3 sync场景的DeleteFinalStateUnknown分析
// DeletedFinalStateUnknown isplaced into a DeltaFIFO in the case where
// an object was deleted but thewatch deletion event was missed. In this
// case we don't know the final"resting" state of the object, so there's// a chance the included Obj isstale.
这个对象困惑了我许久，从注释上看是针对Watch Deleted事件丢失，导致k8s实际对象和Indexer缓存不一致的场景。我们用图展示两种场景：1. Deleted事件未丢失，只是queue待处理该对象；2. Deleted事件丢失。
上图（左）是Deleted消息丢失的代码处理，queueActionLocked会添加DeleteFinalStateUnknown对象到deltas，并保存到Indexer。DeleteFinalStateUnknown是对runtime.Object的封装。上图（右）是Deleted消息未丢失的代码处理。deltas对象变化过程如下：
从Process回调函数看，是直接调用clientState.Delete(d.Object)删除对象的，Indexer计算对象键是否会异常呢？抱着好奇心看了一眼keyFunc（计算对象键的函数，下一篇文章会讲到）DeletionHandlingMetaNamespaceKeyFunc:
func DeletionHandlingMetaNamespaceKeyFunc(obj interface{}) (string, error) {
if d, ok := obj.(DeletedFinalStateUnknown); ok {
return d.Key, nil
}
return MetaNamespaceKeyFunc(obj)
}
DeletionHandlingMetaNamespaceKeyFunc果然有对DeletedFinalStateUnknown的处理(obj.(DeletedFinalStateUnknown)是类型断言用法)，因此不需要担心获取对象键会异常。如果是我们自己实现keyFunc，一样要考虑到DeletedFinalStateUnknown这个而特殊对象。到此为止DeltaFIFO的主要机制已分析完毕。
866
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
