K8s 系列(四) - 淺談 Informer

熱愛coding的稻草發表於2021-09-09
K8SORM

1. 概述

進入 K8s 的世界，會發現有很多的 Controller，它們都是為了完成某類資源(如 pod 是通過 DeploymentController, ReplicaSetController 進行管理)的調諧，目標是保持使用者期望的狀態。

K8s 中有幾十種型別的資源，如何能讓 K8s 內部以及外部使用者方便、高效的獲取某類資源的變化，就是本文 Informer 要實現的。本文將從 Reflector(反射器)、DeletaFIFO(增量佇列)、Indexer(索引器)、Controller(控制器)、SharedInformer(共享資源通知器)、processorListener(事件監聽處理器)、workqueue(事件處理工作佇列) 等方面進行解析。

本文及後續相關文章都基於 K8s v1.22

K8s-informer

2. 從 Reflector 說起

Reflector 的主要職責是從 apiserver 拉取並持續監聽(ListAndWatch) 相關資源型別的增刪改(Add/Update/Delete)事件，儲存在由 DeltaFIFO 實現的本地快取(local Store) 中。

首先看一下 Reflector 結構體定義：

// staging/src/k8s.io/client-go/tools/cache/reflector.go
type Reflector struct {
	// 通過 file:line 唯一標識的 name
	name string

	// 下面三個為了確認型別
	expectedTypeName string
	expectedType     reflect.Type
	expectedGVK      *schema.GroupVersionKind

	// 儲存 interface: 具體由 DeltaFIFO 實現儲存
	store Store
	// 用來從 apiserver 拉取全量和增量資源
	listerWatcher ListerWatcher

	// 下面兩個用來做失敗重試
	backoffManager         wait.BackoffManager
	initConnBackoffManager wait.BackoffManager

	// informer 使用者重新同步的週期
	resyncPeriod time.Duration
	// 判斷是否滿足可以重新同步的條件
	ShouldResync func() bool
	
	clock clock.Clock
	
	// 是否要進行分頁 List
	paginatedResult bool
	
	// 最後同步的資源版本號，以此為依據，watch 只會監聽大於此值的資源
	lastSyncResourceVersion string
	// 最後同步的資源版本號是否可用
	isLastSyncResourceVersionUnavailable bool
	// 加把鎖控制版本號
	lastSyncResourceVersionMutex sync.RWMutex
	
	// 每頁大小
	WatchListPageSize int64
	// watch 失敗回撥 handler
	watchErrorHandler WatchErrorHandler
}

從結構體定義可以看到，通過指定目標資源型別進行 ListAndWatch，並可進行分頁相關設定。

第一次拉取全量資源(目標資源型別) 後通過 syncWith 函式全量替換(Replace) 到 DeltaFIFO queue/items 中，之後通過持續監聽 Watch(目標資源型別) 增量事件，並去重更新到 DeltaFIFO queue/items 中，等待被消費。

watch 目標型別通過 Go reflect 反射實現如下：

// staging/src/k8s.io/client-go/tools/cache/reflector.go
// watchHandler watches w and keeps *resourceVersion up to date.
func (r *Reflector) watchHandler(start time.Time, w watch.Interface, resourceVersion *string, errc chan error, stopCh <-chan struct{}) error {

	...
	if r.expectedType != nil {
		if e, a := r.expectedType, reflect.TypeOf(event.Object); e != a {
			utilruntime.HandleError(fmt.Errorf("%s: expected type %v, but watch event object had type %v", r.name, e, a))
			continue
		}
	}
	if r.expectedGVK != nil {
		if e, a := *r.expectedGVK, event.Object.GetObjectKind().GroupVersionKind(); e != a {
			utilruntime.HandleError(fmt.Errorf("%s: expected gvk %v, but watch event object had gvk %v", r.name, e, a))
			continue
		}
	}
	...
}
  • 通過反射確認目標資源型別，所以命名為 Reflector 還是比較貼切的；
  • List/Watch 的目標資源型別在 NewSharedIndexInformer.ListerWatcher 進行了確定，但 Watch 還會在 watchHandler 中再次比較一下目標型別；

3. 認識 DeltaFIFO

還是先看下 DeltaFIFO 結構體定義：

// staging/src/k8s.io/client-go/tools/cache/delta_fifo.go
type DeltaFIFO struct {
	// 讀寫鎖、條件變數
	lock sync.RWMutex
	cond sync.Cond

	// kv 儲存：objKey1->Deltas[obj1-Added, obj1-Updated...]
	items map[string]Deltas

	// 只儲存所有 objKeys
	queue []string

	// 是否已經填充：通過 Replace() 介面將第一批物件放入佇列，或者第一次呼叫增、刪、改介面時標記為true
	populated bool
	// 通過 Replace() 介面將第一批物件放入佇列的數量
	initialPopulationCount int

	// keyFunc 用來從某個 obj 中獲取其對應的 objKey
	keyFunc KeyFunc

	// 已知物件，其實就是 Indexer
	knownObjects KeyListerGetter

	// 佇列是否已經關閉
	closed bool

	// 以 Replaced 型別傳送(為了相容老版本的 Sync)
	emitDeltaTypeReplaced bool
}

DeltaType 可分為以下型別：

// staging/src/k8s.io/client-go/tools/cache/delta_fifo.go
type DeltaType string

const (
	Added   DeltaType = "Added"
	Updated DeltaType = "Updated"
	Deleted DeltaType = "Deleted"
	Replaced DeltaType = "Replaced" // 第一次或重新同步
	Sync DeltaType = "Sync" // 老版本重新同步叫 Sync
)

通過上面的 Reflector 分析可以知道，DeltaFIFO 的職責是通過佇列加鎖處理(queueActionLocked)、去重(dedupDeltas)、儲存在由 DeltaFIFO 實現的本地快取(local Store) 中，包括 queue(僅存 objKeys) 和 items(存 objKeys 和對應的 Deltas 增量變化)，並通過 Pop 不斷消費，通過 Process(item) 處理相關邏輯。

K8s-DeltaFIFO

4. 索引 Indexer

上一步 ListAndWatch 到的資源已經儲存到 DeltaFIFO 中，接著呼叫 Pop 從佇列進行消費。實際使用中，Process 處理函式由 sharedIndexInformer.HandleDeltas 進行實現。HandleDeltas 函式根據上面不同的 DeltaType 分別進行 Add/Update/Delete，並同時建立、更新、刪除對應的索引。

具體索引實現如下：

// staging/src/k8s.io/client-go/tools/cache/index.go
// map 索引型別 => 索引函式
type Indexers map[string]IndexFunc

// map 索引型別 => 索引值 map
type Indices map[string]Index

// 索引值 map: 由索引函式計算所得索引值(indexedValue) => [objKey1, objKey2...]
type Index map[string]sets.String

索引函式(IndexFunc)：就是計算索引的函式，這樣允許擴充套件多種不同的索引計算函式。預設也是最常用的索引函式是：MetaNamespaceIndexFunc。
索引值(indexedValue)：有些地方叫 indexKey，表示由索引函式(IndexFunc) 計算出來的索引值(如 ns1)。
物件鍵(objKey)：物件 obj 的 唯一 key(如 ns1/pod1)，與某個資源物件一一對應。

K8s-indexer

可以看到，Indexer 由 ThreadSafeStore 介面整合，最終由 threadSafeMap 實現。

  • 索引函式 IndexFunc(如 MetaNamespaceIndexFunc)、KeyFunc(如 MetaNamespaceKeyFunc) 區別：前者表示如何計算索引，後者表示如何獲取物件鍵(objKey)；
  • 索引鍵(indexKey，有些地方是 indexedValue)、物件鍵(objKey) 區別：前者表示由索引函式(IndexFunc) 計算出來的索引鍵(如 ns1)，後者則是 obj 的 唯一 key(如 ns1/pod1)；

5. 總管家 Controller

Controller 作為核心中樞，整合了上面的元件 Reflector、DeltaFIFO、Indexer、Store，成為連線下游消費者的橋樑。

Controller 由 controller 結構體進行具體實現：

在 K8s 中約定俗成：大寫定義的 interface 介面，由對應小寫定義的結構體進行實現。

// staging/src/k8s.io/client-go/tools/cache/controller.go
type controller struct {
	config         Config
	reflector      *Reflector // 上面已分析的元件
	reflectorMutex sync.RWMutex
	clock          clock.Clock
}

type Config struct {
	// 實際由 DeltaFIFO 實現
	Queue

	// 構造 Reflector 需要
	ListerWatcher

	// Pop 出來的 obj 處理函式
	Process ProcessFunc

	// 目標物件型別
	ObjectType runtime.Object

	// 全量重新同步週期
	FullResyncPeriod time.Duration

	// 是否進行重新同步的判斷函式
	ShouldResync ShouldResyncFunc

	// 如果為 true，Process() 函式返回 err，則再次入隊 re-queue
	RetryOnError bool

	// Watch 返回 err 的回撥函式
	WatchErrorHandler WatchErrorHandler

	// Watch 分頁大小
	WatchListPageSize int64
}

Controller 中以 goroutine 協程方式啟動 Run 方法，會啟動 Reflector 的 ListAndWatch()，用於從 apiserver 拉取全量和監聽增量資源，儲存到 DeltaFIFO。接著，啟動 processLoop 不斷從 DeltaFIFO Pop 進行消費。在 sharedIndexInformer 中 Pop 出來進行處理的函式是 HandleDeltas，一方面維護 Indexer 的 Add/Update/Delete，另一方面呼叫下游 sharedProcessor 進行 handler 處理。

6. 啟動 SharedInformer

SharedInformer 介面由 SharedIndexInformer 進行整合，由 sharedIndexInformer(這裡看到了吧，又是大寫定義的 interface 介面，由對應小寫定義的結構體進行實現) 進行實現。

看一下結構體定義：

// staging/src/k8s.io/client-go/tools/cache/shared_informer.go
type SharedIndexInformer interface {
	SharedInformer
	// AddIndexers add indexers to the informer before it starts.
	AddIndexers(indexers Indexers) error
	GetIndexer() Indexer
}

type sharedIndexInformer struct {
	indexer    Indexer
	controller Controller

	// 處理函式，將是重點
	processor *sharedProcessor

	// 檢測 cache 是否有變化，一把用作除錯，預設是關閉的
	cacheMutationDetector MutationDetector

	// 構造 Reflector 需要
	listerWatcher ListerWatcher

	// 目標型別，給 Reflector 判斷資源型別
	objectType runtime.Object

	// Reflector 進行重新同步週期
	resyncCheckPeriod time.Duration

	// 如果使用者沒有新增 Resync 時間，則使用這個預設的重新同步週期
	defaultEventHandlerResyncPeriod time.Duration
	clock                           clock.Clock

	// 兩個 bool 表達了三個狀態：controller 啟動前、已啟動、已停止
	started, stopped bool
	startedLock      sync.Mutex

	// 當 Pop 正在消費佇列，此時新增的 listener 需要加鎖，防止消費混亂
	blockDeltas sync.Mutex

	// Watch 返回 err 的回撥函式
	watchErrorHandler WatchErrorHandler
}

type sharedProcessor struct {
	listenersStarted bool
	listenersLock    sync.RWMutex
	listeners        []*processorListener
	syncingListeners []*processorListener // 需要 sync 的 listeners
	clock            clock.Clock
	wg               wait.Group
}

從結構體定義可以看到，通過整合的 controller(上面已分析) 進行 Reflector ListAndWatch，並儲存到 DeltaFIFO，並啟動 Pop 消費佇列，在 sharedIndexInformer 中 Pop 出來進行處理的函式是 HandleDeltas。

所有的 listeners 通過 sharedIndexInformer.AddEventHandler 加入到 processorListener 陣列切片中，並通過判斷當前 controller 是否已啟動做不同處理如下：

// staging/src/k8s.io/client-go/tools/cache/shared_informer.go
func (s *sharedIndexInformer) AddEventHandlerWithResyncPeriod(handler ResourceEventHandler, resyncPeriod time.Duration) {
	...

	// 如果還沒有啟動，則直接 addListener 加入即可返回
	if !s.started {
		s.processor.addListener(listener)
		return
	}

	// 加鎖控制
	s.blockDeltas.Lock()
	defer s.blockDeltas.Unlock()

	s.processor.addListener(listener)
	
	// 遍歷所有物件，傳送到剛剛新加入的 listener
	for _, item := range s.indexer.List() {
		listener.add(addNotification{newObj: item})
	}
}

接著，在 HandleDeltas 中，根據 obj 的 Delta 型別(Added/Updated/Deleted/Replaced/Sync) 呼叫 sharedProcessor.distribute 給所有監聽 listeners 處理。

7. 註冊 SharedInformerFactory

SharedInformerFactory 作為使用 SharedInformer 的工廠類，提供了高內聚低耦合的工廠類設計模式，其結構體定義如下：

// staging/src/k8s.io/client-go/informers/factory.go
type SharedInformerFactory interface {
	internalinterfaces.SharedInformerFactory // 重點內部介面
	ForResource(resource schema.GroupVersionResource) (GenericInformer, error)
	WaitForCacheSync(stopCh <-chan struct{}) map[reflect.Type]bool

	Admissionregistration() admissionregistration.Interface
	Internal() apiserverinternal.Interface
	Apps() apps.Interface
	Autoscaling() autoscaling.Interface
	Batch() batch.Interface
	Certificates() certificates.Interface
	Coordination() coordination.Interface
	Core() core.Interface
	Discovery() discovery.Interface
	Events() events.Interface
	Extensions() extensions.Interface
	Flowcontrol() flowcontrol.Interface
	Networking() networking.Interface
	Node() node.Interface
	Policy() policy.Interface
	Rbac() rbac.Interface
	Scheduling() scheduling.Interface
	Storage() storage.Interface
}

// staging/src/k8s.io/client-go/informers/internalinterfaces/factory_interfaces.go
type SharedInformerFactory interface {
	Start(stopCh <-chan struct{}) // 啟動 SharedIndexInformer.Run
	InformerFor(obj runtime.Object, newFunc NewInformerFunc) cache.SharedIndexInformer // 目標型別初始化
}

以 PodInformer 為例，說明使用者如何構建自己的 Informer，PodInformer 定義如下：

// staging/src/k8s.io/client-go/informers/core/v1/pod.go
type PodInformer interface {
	Informer() cache.SharedIndexInformer
	Lister() v1.PodLister
}

由小寫的 podInformer 實現(又看到了吧，大寫介面小寫實現的 K8s 風格)：

type podInformer struct {
	factory          internalinterfaces.SharedInformerFactory
	tweakListOptions internalinterfaces.TweakListOptionsFunc
	namespace        string
}

func (f *podInformer) defaultInformer(client kubernetes.Interface, resyncPeriod time.Duration) cache.SharedIndexInformer {
	return NewFilteredPodInformer(client, f.namespace, resyncPeriod, cache.Indexers{cache.NamespaceIndex: cache.MetaNamespaceIndexFunc}, f.tweakListOptions)
}

func (f *podInformer) Informer() cache.SharedIndexInformer {
	return f.factory.InformerFor(&corev1.Pod{}, f.defaultInformer)
}

func (f *podInformer) Lister() v1.PodLister {
	return v1.NewPodLister(f.Informer().GetIndexer())
}

由使用者傳入目標型別(&corev1.Pod{})、建構函式(defaultInformer)，呼叫 SharedInformerFactory.InformerFor 實現目標 Informer 的註冊，然後呼叫 SharedInformerFactory.Start 進行 Run，就啟動了上面分析的 SharedIndexedInformer -> Controller -> Reflector -> DeltaFIFO 流程。

通過使用者自己傳入目標型別、建構函式進行 Informer 註冊，實現了 SharedInformerFactory 高內聚低耦合的設計模式。

8. 回撥 processorListener

所有的 listerners 由 processorListener 實現，分為兩組：listeners, syncingListeners，分別遍歷所屬組全部 listeners，將資料投遞到 processorListener 進行處理。

  • 因為各 listeners 設定的 resyncPeriod 可能不一致，所以將沒有設定(resyncPeriod = 0) 的歸為 listeners 組，將設定了 resyncPeriod 的歸到 syncingListeners 組；
  • 如果某個 listener 在多個地方(sharedIndexInformer.resyncCheckPeriod, sharedIndexInformer.AddEventHandlerWithResyncPeriod)都設定了 resyncPeriod，則取最小值 minimumResyncPeriod；
// staging/src/k8s.io/client-go/tools/cache/shared_informer.go
func (p *sharedProcessor) distribute(obj interface{}, sync bool) {
	p.listenersLock.RLock()
	defer p.listenersLock.RUnlock()

	if sync {
		for _, listener := range p.syncingListeners {
			listener.add(obj)
		}
	} else {
		for _, listener := range p.listeners {
			listener.add(obj)
		}
	}
}

從程式碼可以看到 processorListener 巧妙地使用了兩個 channel(addCh, nextCh) 和一個 pendingNotifications(由 slice 實現的滾動 Ring) 進行 buffer 緩衝，預設的 initialBufferSize = 1024。既做到了高效傳遞資料，又不阻塞上下游處理，值得學習。

K8s-processorListener

9. workqueue 忙起來

通過上一步 processorListener 回撥函式，交給內部 ResourceEventHandler 進行真正的增刪改(CUD) 處理，分別呼叫 OnAdd/OnUpdate/OnDelete 註冊函式進行處理。

為了快速處理而不阻塞 processorListener 回撥函式，一般使用 workqueue 進行非同步化解耦合處理，其實現如下：

K8s-workqueue.png

從圖中可以看到，workqueue.RateLimitingInterface 整合了 DelayingInterface，DelayingInterface 整合了 Interface，最終由 rateLimitingType 進行實現，提供了 rateLimit 限速、delay 延時入隊(由優先順序佇列通過小頂堆實現)、queue 佇列處理 三大核心能力。

另外，在程式碼中可看到 K8s 實現了三種 RateLimiter：BucketRateLimiter, ItemExponentialFailureRateLimiter, ItemFastSlowRateLimiter，Controller 預設採用了前兩種如下：

// staging/src/k8s.io/client-go/util/workqueue/default_rate_limiters.go
func DefaultControllerRateLimiter() RateLimiter {
	return NewMaxOfRateLimiter(
		NewItemExponentialFailureRateLimiter(5*time.Millisecond, 1000*time.Second),
		// 10 qps, 100 bucket size.  This is only for retry speed and its only the overall factor (not per item)
		&BucketRateLimiter{Limiter: rate.NewLimiter(rate.Limit(10), 100)},
	)
}

這樣，在使用者側可以通過呼叫 workqueue 相關方法進行靈活的佇列處理，比如失敗多少次就不再重試，失敗了延時入隊的時間控制，佇列的限速控制(QPS)等，實現非阻塞非同步化邏輯處理。

10. 小結

本文通過分析 K8s 中 Reflector(反射器)、DeletaFIFO(增量佇列)、Indexer(索引器)、Controller(控制器)、SharedInformer(共享資源通知器)、processorListener(事件監聽處理器)、workqueue(事件處理工作佇列) 等元件，對 Informer 實現機制進行了解析，通過原始碼、圖文方式說明了相關流程處理，以期更好的理解 K8s Informer 執行流程。

可以看到，K8s 為了實現高效、非阻塞的核心流程，大量採用了 goroutine 協程、channel 通道、queue 佇列、index 索引、map 去重等方式；並通過良好的介面設計模式，給使用者開放了很多擴充套件能力；採用了統一的介面與實現的命名方式等，這些都值得深入學習與借鑑。

PS: 更多內容請關注 k8s-club

參考資料

  1. Kubernetes 官方文件
  2. Kubernetes 原始碼
  3. Kubernetes Architectural Roadmap

相關文章