主頁 >  其他 > 深入決議 Kubebuilder：讓撰寫 CRD 變得更簡單

深入決議 Kubebuilder：讓撰寫 CRD 變得更簡單

2020-09-17 12:21:15 其他

file
作者 | 劉洋(炎尋) 阿里云高級開發工程師

導讀：自定義資源 CRD（Custom Resource Definition）可以擴展 Kubernetes API，掌握 CRD 是成為 Kubernetes 高級玩家的必備技能，本文將介紹 CRD 和 Controller 的概念，并對 CRD 撰寫框架 Kubebuilder 進行深入分析，讓您真正理解并能快速開發 CRD，

概覽

控制器模式與宣告式 API


在正式介紹 Kubebuidler 之前，我們需要先了解下 K8s 底層實作大量使用的控制器模式，以及讓用戶大呼過癮的宣告式 API，這是介紹 CRDs 和 Kubebuidler 的基礎，

控制器模式


K8s 作為一個“容器編排”平臺，其核心的功能是編排，Pod 作為 K8s 調度的最小單位,具備很多屬性和欄位，K8s 的編排正是通過一個個控制器根據被控制物件的屬性和欄位來實作，


下面我們看一個例子：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
spec:
  selector:
    matchLabels:
      app: test
  replicas: 2
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80


K8s 集群在部署時包含了 Controllers 組件，里面對于每個 build-in 的資源型別（比如 Deployments, Statefulset, CronJob, ...）都有對應的 Controller，基本是 1:1 的關系，上面的例子中，Deployment 資源創建之后，對應的 Deployment Controller 編排動作很簡單，確保攜帶了 app=test 的 Pod 個數永遠等于 2，Pod 由 template 部分定義，具體來說，K8s 里面是 kube-controller-manager 這個組件在做這件事，可以看下 K8s 專案的 pkg/controller 目錄，里面包含了所有控制器，都以獨有的方式負責某種編排功能，但是它們都遵循一個通用編排模式，即：調諧回圈（Reconcile loop），其偽代碼邏輯為：

for {
actualState := GetResourceActualState(rsvc)
expectState := GetResourceExpectState(rsvc)
if actualState == expectState {
// do nothing
} else {
Reconcile(rsvc)
}
}


就是一個無限回圈（實際是事件驅動+定時同步來實作，不是無腦回圈）不斷地對比期望狀態和實際狀態，如果有出入則進行 Reconcile（調諧）邏輯將實際狀態調整為期望狀態，期望狀態就是我們的物件定義（通常是 YAML 檔案），實際狀態是集群里面當前的運行狀態（通常來自于 K8s 集群內外相關資源的狀態匯總），控制器的編排邏輯主要是第三步做的，這個操作被稱為調諧（Reconcile），整個控制器調諧的程序稱為“Reconcile Loop”，調諧的最終結果一般是對被控制物件的某種寫操作，比如增/刪/改 Pod，


在控制器中定義被控制物件是通過“模板”完成的，比如 Deployment 里面的 template 欄位里的內容跟一個標準的 Pod 物件的 API 定義一樣，所有被這個 Deployment 管理的 Pod 實體，都是根據這個 template 欄位的創建的，這就是 PodTemplate，一個控制物件的定義一般是由上半部分的控制定義（期望狀態），加上下半部分的被控制物件的模板組成，

宣告式 API

所謂宣告式就是“告訴 K8s 你要什么，而不是告訴它怎么做的命令”，一個很熟悉的例子就是 SQL，你“告訴 DB 根據條件和各類算子回傳資料，而不是告訴它怎么遍歷，過濾，聚合”，在 K8s 里面，宣告式的體現就是 kubectl apply 命令，在物件創建和后續更新中一直使用相同的 apply 命令，告訴 K8s 物件的終態即可，底層是通過執行了一個對原有 API 物件的 PATCH 操作來實作的，可以一次性處理多個寫操作，具備 Merge 能力 diff 出最終的 PATCH，而命令式一次只能處理一個寫請求，

宣告式 API 讓 K8s 的“容器編排”世界看起來溫柔美好，而控制器（以及容器運行時，存盤，網路模型等）才是這太平盛世的幕后英雄，說到這里，就會有人希望也能像 build-in 資源一樣構建自己的自定義資源（CRD-Customize Resource Definition），然后為自定義資源寫一個對應的控制器，推出自己的宣告式 API，K8s 提供了 CRD 的擴展方式來滿足用戶這一需求，而且由于這種擴展方式十分靈活，在最新的 1.15 版本對 CRD 做了相當大的增強，對于用戶來說，實作 CRD 擴展主要做兩件事：

  1. 撰寫 CRD 并將其部署到 K8s 集群里；

這一步的作用就是讓 K8s 知道有這個資源及其結構屬性，在用戶提交該自定義資源的定義時（通常是 YAML 檔案定義），K8s 能夠成功校驗該資源并創建出對應的 Go struct 進行持久化，同時觸發控制器的調諧邏輯，

  1. 撰寫 Controller 并將其部署到 K8s 集群里，

這一步的作用就是實作調諧邏輯，


Kubebuilder 就是幫我們簡化這兩件事的工具，現在我們開始介紹主角，

Kubebuilder 是什么？

摘要

Kubebuilder 是一個使用 CRDs 構建 K8s API 的 SDK，主要是：

  • 提供腳手架工具初始化 CRDs 工程，自動生成 boilerplate 代碼和配置；
  • 提供代碼庫封裝底層的 K8s go-client；


方便用戶從零開始開發 CRDs，Controllers 和 Admission Webhooks 來擴展 K8s，

核心概念

GVKs&GVRs

GVK = GroupVersionKind，GVR = GroupVersionResource，

API Group & Versions（GV）

API Group 是相關 API 功能的集合，每個 Group 擁有一或多個 Versions，用于介面的演進，

Kinds & Resources

每個 GV 都包含多個 API 型別，稱為 Kinds，在不同的 Versions 之間同一個 Kind 定義可能不同， Resource 是 Kind 的物件標識（resource type），一般來說 Kinds 和 Resources 是 1:1 的，比如 pods Resource 對應 Pod Kind，但是有時候相同的 Kind 可能對應多個 Resources，比如 Scale Kind 可能對應很多 Resources：deployments/scale，replicasets/scale，對于 CRD 來說，只會是 1:1 的關系，

每一個 GVK 都關聯著一個 package 中給定的 root Go type，比如 apps/v1/Deployment 就關聯著 K8s 原始碼里面 k8s.io/api/apps/v1 package 中的 Deployment struct，我們提交的各類資源定義 YAML 檔案都需要寫：

  • apiVersion：這個就是 GV ，
  • kind：這個就是 K，


根據 GVK K8s 就能找到你到底要創建什么型別的資源，根據你定義的 Spec 創建好資源之后就成為了 Resource，也就是 GVR，GVK/GVR 就是 K8s 資源的坐標，是我們創建/洗掉/修改/讀取資源的基礎，

Scheme

每一組 Controllers 都需要一個 Scheme，提供了 Kinds 與對應 Go types 的映射，也就是說給定 Go type 就知道他的 GVK，給定 GVK 就知道他的 Go type，比如說我們給定一個 Scheme: "tutotial.kubebuilder.io/api/v1".CronJob{} 這個 Go type 映射到 batch.tutotial.kubebuilder.io/v1 的 CronJob GVK，那么從 Api Server 獲取到下面的 JSON:

{
    "kind": "CronJob",
    "apiVersion": "batch.tutorial.kubebuilder.io/v1",
    ...
}


就能構造出對應的 Go type了，通過這個 Go type 也能正確地獲取 GVR 的一些資訊，控制器可以通過該 Go type 獲取到期望狀態以及其他輔助資訊進行調諧邏輯，

Manager

Kubebuilder 的核心組件，具有 3 個職責：

  • 負責運行所有的 Controllers；
  • 初始化共享 caches，包含 listAndWatch 功能；
  • 初始化 clients 用于與 Api Server 通信，

Cache

Kubebuilder 的核心組件，負責在 Controller 行程里面根據 Scheme 同步 Api Server 中所有該 Controller 關心 GVKs 的 GVRs，其核心是 GVK -> Informer 的映射，Informer 會負責監聽對應 GVK 的 GVRs 的創建/洗掉/更新操作，以觸發 Controller 的 Reconcile 邏輯，

Controller

Kubebuidler 為我們生成的腳手架檔案，我們只需要實作 Reconcile 方法即可，

Clients

在實作 Controller 的時候不可避免地需要對某些資源型別進行創建/洗掉/更新，就是通過該 Clients 實作的，其中查詢功能實際查詢是本地的 Cache，寫操作直接訪問 Api Server，

Index

由于 Controller 經常要對 Cache 進行查詢，Kubebuilder 提供 Index utility 給 Cache 加索引提升查詢效率，

Finalizer

在一般情況下，如果資源被洗掉之后，我們雖然能夠被觸發洗掉事件，但是這個時候從 Cache 里面無法讀取任何被洗掉物件的資訊，這樣一來，導致很多垃圾清理作業因為資訊不足無法進行，K8s 的 Finalizer 欄位用于處理這種情況，在 K8s 中，只要物件 ObjectMeta 里面的 Finalizers 不為空，對該物件的 delete 操作就會轉變為 update 操作，具體說就是 update deletionTimestamp 欄位，其意義就是告訴 K8s 的 GC“在deletionTimestamp 這個時刻之后，只要 Finalizers 為空，就立馬洗掉掉該物件”，


所以一般的使用姿勢就是在創建物件時把 Finalizers 設定好（任意 string），然后處理 DeletionTimestamp 不為空的 update 操作（實際是 delete），根據 Finalizers 的值執行完所有的 pre-delete hook（此時可以在 Cache 里面讀取到被洗掉物件的任何資訊）之后將 Finalizers 置為空即可，

OwnerReference

K8s GC 在洗掉一個物件時，任何 ownerReference 是該物件的物件都會被清除，與此同時，Kubebuidler 支持所有物件的變更都會觸發 Owner 物件 controller 的 Reconcile 方法，


所有概念集合在一起如圖 1 所示：

file

圖 1-Kubebuilder 核心概念

Kubebuilder 怎么用？

1. 創建腳手架工程

kubebuilder init --domain edas.io

這一步創建了一個 Go module 工程，引入了必要的依賴，創建了一些模板檔案，

2. 創建 API

kubebuilder create api --group apps --version v1alpha1 --kind Application


這一步創建了對應的 CRD 和 Controller 模板檔案，經過 1、2 兩步，現有的工程結構如圖 2 所示：

file

圖 2-Kubebuilder 生成的工程結構說明

3. 定義 CRD

在圖 2 中對應的檔案定義 Spec 和 Status，

4. 撰寫 Controller 邏輯

在圖 3 中對應的檔案實作 Reconcile 邏輯，

5. 測驗發布

本地測驗完之后使用 Kubebuilder 的 Makefile 構建鏡像，部署我們的 CRDs 和 Controller 即可，

Kubebuilder 出現的意義？

讓擴展 K8s 變得更簡單，K8s 擴展的方式很多，Kubebuilder 目前專注于 CRD 擴展方式，

深入

在使用 Kubebuilder 的程序中有些問題困擾著我：

  • 如何同步自定義資源以及 K8s build-in 資源？
  • Controller 的 Reconcile 方法是如何被觸發的？
  • Cache 的作業原理是什么？
  • ...


帶著這些問題我們去看看原始碼 ??，

原始碼閱讀

從 main.go 開始

Kubebuilder 創建的 main.go 是整個專案的入口，邏輯十分簡單：

var (
	scheme   = runtime.NewScheme()
	setupLog = ctrl.Log.WithName("setup")
)
func init() {
	appsv1alpha1.AddToScheme(scheme)
	// +kubebuilder:scaffold:scheme
}
func main() {
	...
        // 1、init Manager
	mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{Scheme: scheme, MetricsBindAddress: metricsAddr})
	if err != nil {
		setupLog.Error(err, "unable to start manager")
		os.Exit(1)
	}
        // 2、init Reconciler（Controller）
	err = (&controllers.ApplicationReconciler{
		Client: mgr.GetClient(),
		Log:    ctrl.Log.WithName("controllers").WithName("Application"),
		Scheme: mgr.GetScheme(),
	}).SetupWithManager(mgr)
	if err != nil {
		setupLog.Error(err, "unable to create controller", "controller", "EDASApplication")
		os.Exit(1)
	}
	// +kubebuilder:scaffold:builder
	setupLog.Info("starting manager")
        // 3、start Manager
	if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
		setupLog.Error(err, "problem running manager")
		os.Exit(1)
	}


可以看到在 init 方法里面我們將 appsv1alpha1 注冊到 Scheme 里面去了，這樣一來 Cache 就知道 watch 誰了，main 方法里面的邏輯基本都是 Manager 的：

  1. 初始化了一個 Manager；
  2. 將 Manager 的 Client 傳給 Controller，并且呼叫 SetupWithManager 方法傳入 Manager 進行 Controller 的初始化；
  3. 啟動 Manager，


我們的核心就是看這 3 個流程，

Manager 初始化

Manager 初始化代碼如下：

// New returns a new Manager for creating Controllers.
func New(config *rest.Config, options Options) (Manager, error) {
	...
	// Create the cache for the cached read client and registering informers
	cache, err := options.NewCache(config, cache.Options{Scheme: options.Scheme, Mapper: mapper, Resync: options.SyncPeriod, Namespace: options.Namespace})
	if err != nil {
		return nil, err
	}
	apiReader, err := client.New(config, client.Options{Scheme: options.Scheme, Mapper: mapper})
	if err != nil {
		return nil, err
	}
	writeObj, err := options.NewClient(cache, config, client.Options{Scheme: options.Scheme, Mapper: mapper})
	if err != nil {
		return nil, err
	}
	...
	return &controllerManager{
		config:           config,
		scheme:           options.Scheme,
		errChan:          make(chan error),
		cache:            cache,
		fieldIndexes:     cache,
		client:           writeObj,
		apiReader:        apiReader,
		recorderProvider: recorderProvider,
		resourceLock:     resourceLock,
		mapper:           mapper,
		metricsListener:  metricsListener,
		internalStop:     stop,
		internalStopper:  stop,
		port:             options.Port,
		host:             options.Host,
		leaseDuration:    *options.LeaseDuration,
		renewDeadline:    *options.RenewDeadline,
		retryPeriod:      *options.RetryPeriod,
	}, nil
}


可以看到主要是創建 Cache 與 Clients：

創建 Cache

Cache 初始化代碼如下：

// New initializes and returns a new Cache.
func New(config *rest.Config, opts Options) (Cache, error) {
	opts, err := defaultOpts(config, opts)
	if err != nil {
		return nil, err
	}
	im := internal.NewInformersMap(config, opts.Scheme, opts.Mapper, *opts.Resync, opts.Namespace)
	return &informerCache{InformersMap: im}, nil
}
// newSpecificInformersMap returns a new specificInformersMap (like
// the generical InformersMap, except that it doesn't implement WaitForCacheSync).
func newSpecificInformersMap(...) *specificInformersMap {
	ip := &specificInformersMap{
		Scheme:            scheme,
		mapper:            mapper,
		informersByGVK:    make(map[schema.GroupVersionKind]*MapEntry),
		codecs:            serializer.NewCodecFactory(scheme),
		resync:            resync,
		createListWatcher: createListWatcher,
		namespace:         namespace,
	}
	return ip
}
// MapEntry contains the cached data for an Informer
type MapEntry struct {
	// Informer is the cached informer
	Informer cache.SharedIndexInformer
	// CacheReader wraps Informer and implements the CacheReader interface for a single type
	Reader CacheReader
}
func createUnstructuredListWatch(gvk schema.GroupVersionKind, ip *specificInformersMap) (*cache.ListWatch, error) {
        ...
	// Create a new ListWatch for the obj
	return &cache.ListWatch{
		ListFunc: func(opts metav1.ListOptions) (runtime.Object, error) {
			if ip.namespace != "" && mapping.Scope.Name() != meta.RESTScopeNameRoot {
				return dynamicClient.Resource(mapping.Resource).Namespace(ip.namespace).List(opts)
			}
			return dynamicClient.Resource(mapping.Resource).List(opts)
		},
		// Setup the watch function
		WatchFunc: func(opts metav1.ListOptions) (watch.Interface, error) {
			// Watch needs to be set to true separately
			opts.Watch = true
			if ip.namespace != "" && mapping.Scope.Name() != meta.RESTScopeNameRoot {
				return dynamicClient.Resource(mapping.Resource).Namespace(ip.namespace).Watch(opts)
			}
			return dynamicClient.Resource(mapping.Resource).Watch(opts)
		},
	}, nil
}


可以看到 Cache 主要就是創建了 InformersMap，Scheme 里面的每個 GVK 都創建了對應的 Informer，通過 informersByGVK 這個 map 做 GVK 到 Informer 的映射，每個 Informer 會根據 ListWatch 函式對對應的 GVK 進行 List 和 Watch，

創建 Clients

創建 Clients 很簡單：

// defaultNewClient creates the default caching client
func defaultNewClient(cache cache.Cache, config *rest.Config, options client.Options) (client.Client, error) {
	// Create the Client for Write operations.
	c, err := client.New(config, options)
	if err != nil {
		return nil, err
	}
	return &client.DelegatingClient{
		Reader: &client.DelegatingReader{
			CacheReader:  cache,
			ClientReader: c,
		},
		Writer:       c,
		StatusClient: c,
	}, nil
}


讀操作使用上面創建的 Cache，寫操作使用 K8s go-client 直連，

Controller 初始化

下面看看 Controller 的啟動：

func (r *EDASApplicationReconciler) SetupWithManager(mgr ctrl.Manager) error {
	err := ctrl.NewControllerManagedBy(mgr).
		For(&appsv1alpha1.EDASApplication{}).
		Complete(r)
return err
}


使用的是 Builder 模式，NewControllerManagerBy 和 For 方法都是給 Builder 傳參，最重要的是最后一個方法 Complete，其邏輯是：

func (blder *Builder) Build(r reconcile.Reconciler) (manager.Manager, error) {
...
	// Set the Manager
	if err := blder.doManager(); err != nil {
		return nil, err
	}
	// Set the ControllerManagedBy
	if err := blder.doController(r); err != nil {
		return nil, err
	}
	// Set the Watch
	if err := blder.doWatch(); err != nil {
		return nil, err
	}
...
	return blder.mgr, nil
}


主要是看看 doController 和 doWatch 方法：

doController 方法

func New(name string, mgr manager.Manager, options Options) (Controller, error) {
	if options.Reconciler == nil {
		return nil, fmt.Errorf("must specify Reconciler")
	}
	if len(name) == 0 {
		return nil, fmt.Errorf("must specify Name for Controller")
	}
	if options.MaxConcurrentReconciles <= 0 {
		options.MaxConcurrentReconciles = 1
	}
	// Inject dependencies into Reconciler
	if err := mgr.SetFields(options.Reconciler); err != nil {
		return nil, err
	}
	// Create controller with dependencies set
	c := &controller.Controller{
		Do:                      options.Reconciler,
		Cache:                   mgr.GetCache(),
		Config:                  mgr.GetConfig(),
		Scheme:                  mgr.GetScheme(),
		Client:                  mgr.GetClient(),
		Recorder:                mgr.GetEventRecorderFor(name),
		Queue:                   workqueue.NewNamedRateLimitingQueue(workqueue.DefaultControllerRateLimiter(), name),
		MaxConcurrentReconciles: options.MaxConcurrentReconciles,
		Name:                    name,
	}
	// Add the controller as a Manager components
	return c, mgr.Add(c)
}


該方法初始化了一個 Controller，傳入了一些很重要的引數：

  • Do：Reconcile 邏輯；
  • Cache：找 Informer 注冊 Watch；
  • Client：對 K8s 資源進行 CRUD；
  • Queue：Watch 資源的 CUD 事件快取；
  • Recorder：事件收集，

doWatch 方法

func (blder *Builder) doWatch() error {
	// Reconcile type
	src := &source.Kind{Type: blder.apiType}
	hdler := &handler.EnqueueRequestForObject{}
	err := blder.ctrl.Watch(src, hdler, blder.predicates...)
	if err != nil {
		return err
	}
	// Watches the managed types
	for _, obj := range blder.managedObjects {
		src := &source.Kind{Type: obj}
		hdler := &handler.EnqueueRequestForOwner{
			OwnerType:    blder.apiType,
			IsController: true,
		}
		if err := blder.ctrl.Watch(src, hdler, blder.predicates...); err != nil {
			return err
		}
	}
	// Do the watch requests
	for _, w := range blder.watchRequest {
		if err := blder.ctrl.Watch(w.src, w.eventhandler, blder.predicates...); err != nil {
			return err
		}
	}
	return nil
}


可以看到該方法對本 Controller 負責的 CRD 進行了 watch，同時底下還會 watch 本 CRD 管理的其他資源，這個 managedObjects 可以通過 Controller 初始化 Buidler 的 Owns 方法傳入，說到 Watch 我們關心兩個邏輯：

  1. 注冊的 handler
type EnqueueRequestForObject struct{}
// Create implements EventHandler
func (e *EnqueueRequestForObject) Create(evt event.CreateEvent, q workqueue.RateLimitingInterface) {
        ...
	q.Add(reconcile.Request{NamespacedName: types.NamespacedName{
		Name:      evt.Meta.GetName(),
		Namespace: evt.Meta.GetNamespace(),
	}})
}
// Update implements EventHandler
func (e *EnqueueRequestForObject) Update(evt event.UpdateEvent, q workqueue.RateLimitingInterface) {
	if evt.MetaOld != nil {
		q.Add(reconcile.Request{NamespacedName: types.NamespacedName{
			Name:      evt.MetaOld.GetName(),
			Namespace: evt.MetaOld.GetNamespace(),
		}})
	} else {
		enqueueLog.Error(nil, "UpdateEvent received with no old metadata", "event", evt)
	}
	if evt.MetaNew != nil {
		q.Add(reconcile.Request{NamespacedName: types.NamespacedName{
			Name:      evt.MetaNew.GetName(),
			Namespace: evt.MetaNew.GetNamespace(),
		}})
	} else {
		enqueueLog.Error(nil, "UpdateEvent received with no new metadata", "event", evt)
	}
}
// Delete implements EventHandler
func (e *EnqueueRequestForObject) Delete(evt event.DeleteEvent, q workqueue.RateLimitingInterface) {
        ...
	q.Add(reconcile.Request{NamespacedName: types.NamespacedName{
		Name:      evt.Meta.GetName(),
		Namespace: evt.Meta.GetNamespace(),
	}})
}


可以看到 Kubebuidler 為我們注冊的 Handler 就是將發生變更的物件的 NamespacedName 入佇列，如果在 Reconcile 邏輯中需要判斷創建/更新/洗掉，需要有自己的判斷邏輯，

  1. 注冊的流程
// Watch implements controller.Controller
func (c *Controller) Watch(src source.Source, evthdler handler.EventHandler, prct ...predicate.Predicate) error {
	...
	log.Info("Starting EventSource", "controller", c.Name, "source", src)
	return src.Start(evthdler, c.Queue, prct...)
}
// Start is internal and should be called only by the Controller to register an EventHandler with the Informer
// to enqueue reconcile.Requests.
func (is *Informer) Start(handler handler.EventHandler, queue workqueue.RateLimitingInterface,
	...
	is.Informer.AddEventHandler(internal.EventHandler{Queue: queue, EventHandler: handler, Predicates: prct})
	return nil
}


我們的 Handler 實際注冊到 Informer 上面，這樣整個邏輯就串起來了，通過 Cache 我們創建了所有 Scheme 里面 GVKs 的 Informers，然后對應 GVK 的 Controller 注冊了 Watch Handler 到對應的 Informer，這樣一來對應的 GVK 里面的資源有變更都會觸發 Handler，將變更事件寫到 Controller 的事件佇列中，之后觸發我們的 Reconcile 方法，

Manager 啟動

func (cm *controllerManager) Start(stop <-chan struct{}) error {
	...
	go cm.startNonLeaderElectionRunnables()
	...
}
func (cm *controllerManager) startNonLeaderElectionRunnables() {
	...
	// Start the Cache. Allow the function to start the cache to be mocked out for testing
	if cm.startCache == nil {
		cm.startCache = cm.cache.Start
	}
	go func() {
		if err := cm.startCache(cm.internalStop); err != nil {
			cm.errChan <- err
		}
	}()
        ...
        // Start Controllers
	for _, c := range cm.nonLeaderElectionRunnables {
		ctrl := c
		go func() {
			cm.errChan <- ctrl.Start(cm.internalStop)
		}()
	}
	cm.started = true
}


主要就是啟動 Cache，Controller，將整個事件流運轉起來，我們下面來看看啟動邏輯，

Cache 啟動

func (ip *specificInformersMap) Start(stop <-chan struct{}) {
	func() {
		...
		// Start each informer
		for _, informer := range ip.informersByGVK {
			go informer.Informer.Run(stop)
		}
	}()
}
func (s *sharedIndexInformer) Run(stopCh <-chan struct{}) {
        ...
        // informer push resource obj CUD delta to this fifo queue
	fifo := NewDeltaFIFO(MetaNamespaceKeyFunc, s.indexer)
	cfg := &Config{
		Queue:            fifo,
		ListerWatcher:    s.listerWatcher,
		ObjectType:       s.objectType,
		FullResyncPeriod: s.resyncCheckPeriod,
		RetryOnError:     false,
		ShouldResync:     s.processor.shouldResync,
                // handler to process delta
		Process: s.HandleDeltas,
	}
	func() {
		s.startedLock.Lock()
		defer s.startedLock.Unlock()
                // this is internal controller process delta generate by reflector
		s.controller = New(cfg)
		s.controller.(*controller).clock = s.clock
		s.started = true
	}()
        ...
	wg.StartWithChannel(processorStopCh, s.processor.run)
	s.controller.Run(stopCh)
}
func (c *controller) Run(stopCh <-chan struct{}) {
	...
	r := NewReflector(
		c.config.ListerWatcher,
		c.config.ObjectType,
		c.config.Queue,
		c.config.FullResyncPeriod,
	)
	...
        // reflector is delta producer
	wg.StartWithChannel(stopCh, r.Run)
        // internal controller's processLoop is comsume logic
	wait.Until(c.processLoop, time.Second, stopCh)
}


Cache 的初始化核心是初始化所有的 Informer，Informer 的初始化核心是創建了 reflector 和內部 controller，reflector 負責監聽 Api Server 上指定的 GVK，將變更寫入 delta 佇列中，可以理解為變更事件的生產者，內部 controller 是變更事件的消費者，他會負責更新本地 indexer，以及計算出 CUD 事件推給我們之前注冊的 Watch Handler，

Controller 啟動

// Start implements controller.Controller
func (c *Controller) Start(stop <-chan struct{}) error {
	...
	for i := 0; i < c.MaxConcurrentReconciles; i++ {
		// Process work items
		go wait.Until(func() {
			for c.processNextWorkItem() {
			}
		}, c.JitterPeriod, stop)
	}
	...
}
func (c *Controller) processNextWorkItem() bool {
	...
	obj, shutdown := c.Queue.Get()
	...
	var req reconcile.Request
	var ok bool
	if req, ok = obj.(reconcile.Request); 
        ...
	// RunInformersAndControllers the syncHandler, passing it the namespace/Name string of the
	// resource to be synced.
	if result, err := c.Do.Reconcile(req); err != nil {
		c.Queue.AddRateLimited(req)
		...
	} 
        ...
}


Controller 的初始化是啟動 goroutine 不斷地查詢佇列，如果有變更訊息則觸發到我們自定義的 Reconcile 邏輯，

整體邏輯串連


上面我們通過原始碼閱讀已經十分清楚整個流程，但是正所謂一圖勝千言，我制作了一張整體邏輯串連圖（圖 3）來幫助大家理解：

file

圖 3-Kubebuidler 整體邏輯串連圖


Kubebuilder 作為腳手架工具已經為我們做了很多，到最后我們只需要實作 Reconcile 方法即可，這里不再贅述，

守得云開見月明

剛開始使用 Kubebuilder 的時候，因為封裝程度很高，很多事情都是懵逼狀態，剖析完之后很多問題就很明白了，比如開頭提出的幾個：

  • 如何同步自定義資源以及 K8s build-in 資源？

需要將自定義資源和想要 Watch 的 K8s build-in 資源的 GVKs 注冊到 Scheme 上，Cache 會自動幫我們同步，

  • Controller 的 Reconcile 方法是如何被觸發的？

通過 Cache 里面的 Informer 獲取資源的變更事件，然后通過兩個內置的 Controller 以生產者消費者模式傳遞事件，最終觸發 Reconcile 方法，

  • Cache 的作業原理是什么？

GVK -> Informer 的映射，Informer 包含 Reflector 和 Indexer 來做事件監聽和本地快取，


還有很多問題我就不一一說了，總之，現在 Kubebuilder 現在不再是黑盒，

同類工具對比

Operator Framework 與 Kubebuilder 很類似，這里因為篇幅關系不再展開，

最佳實踐

模式

  1. 使用 OwnerRefrence 來做資源關聯，有兩個特性：
  • Owner 資源被洗掉，被 Own 的資源會被級聯洗掉，這利用了 K8s 的 GC；
  • 被 Own 的資源物件的事件變更可以觸發 Owner 物件的 Reconcile 方法；
  1. 使用 Finalizer 來做資源的清理，

注意點

  • 不使用 Finalizer 時，資源被洗掉無法獲取任何資訊；
  • 物件的 Status 欄位變化也會觸發 Reconcile 方法；
  • Reconcile 邏輯需要冪等；

優化

使用 IndexFunc 來優化資源查詢的效率

總結

通過深入分析，我們可以看到 Kubebuilder 提供的功能對于快速撰寫 CRD 和 Controller 是十分有幫助的，無論是 Istio、Knative 等知名專案還是各種自定義 Operators，都大量使用了 CRD，將各種組件抽象為 CRD，Kubernetes 變成控制面板將成為一個趨勢，希望本文能夠幫助大家理解和把握這個趨勢，


“ 阿里巴巴云原生微信公眾號（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術公眾號，”

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/65576.html

標籤：其他

上一篇：本機到本地網路運營商的接入帶寬速度是如何測驗出來的？

下一篇：求助大神解答！！

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C＃(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 網閘典型架構簡述

    網閘架構一般分為兩種：三主機的三系統架構網閘和雙主機的2+1架構網閘。 三主機架構分別為內端機、外端機和仲裁機。三機無論從軟體和硬體上均各自獨立。首先從硬體上來看，三機都用各自獨立的主板、記憶體及存盤設備。從軟體上來看，三機有各自獨立的作業系統。這樣能達到完全的三機獨立。對于“2+1”系統，“2”分為 ......

    uj5u.com 2020-09-10 02:00:44 more
  • 如何從xshell上傳檔案到centos linux虛擬機里

    如何從xshell上傳檔案到centos linux虛擬機里及：虛擬機CentOs下執行 yum -y install lrzsz命令，出現錯誤：鏡像無法找到軟體包 前言 一、安裝lrzsz步驟 二、上傳檔案 三、遇到的問題及解決方案 總結 前言 提示：其實很簡單，往虛擬機上安裝一個上傳檔案的工具 ......

    uj5u.com 2020-09-10 02:00:47 more
  • 一、SQLMAP入門

    一、SQLMAP入門 1、判斷是否存在注入 sqlmap.py -u 網址/id=1 id=1不可缺少。當注入點后面的引數大于兩個時。需要加雙引號， sqlmap.py -u "網址/id=1&uid=1" 2、判斷文本中的請求是否存在注入 從文本中加載http請求，SQLMAP可以從一個文本檔案中 ......

    uj5u.com 2020-09-10 02:00:50 more
  • Metasploit 簡單使用教程

    metasploit 簡單使用教程 浩先生， 2020-08-28 16:18:25 分類專欄： kail 網路安全 linux 文章標簽： linux資訊安全 編輯 著作權 metasploit 使用教程 前言 一、Metasploit是什么？ 二、準備作業 三、具體步驟 前言 Msfconsole ......

    uj5u.com 2020-09-10 02:00:53 more
  • 游戲逆向之驅動層與用戶層通訊

    驅動層代碼： #pragma once #include <ntifs.h> #define add_code CTL_CODE(FILE_DEVICE_UNKNOWN,0x800,METHOD_BUFFERED,FILE_ANY_ACCESS) /* 更多游戲逆向視頻www.yxfzedu.com ......

    uj5u.com 2020-09-10 02:00:56 more
  • 北斗電力時鐘（北斗授時服務器）讓網路資料更精準

    北斗電力時鐘（北斗授時服務器）讓網路資料更精準 北斗電力時鐘（北斗授時服務器）讓網路資料更精準 京準電子科技官微——ahjzsz 近幾年，資訊技術的得了快速發展，互聯網在逐漸普及，其在人們生活和生產中都得到了廣泛應用，并且取得了不錯的應用效果。計算機網路資訊在電力系統中的應用，一方面使電力系統的運行 ......

    uj5u.com 2020-09-10 02:01:03 more
  • 【CTF】CTFHub 技能樹 彩蛋 writeup

    ?碎碎念 CTFHub：https://www.ctfhub.com/ 筆者入門CTF時時剛開始刷的是bugku的舊平臺，后來才有了CTFHub。 感覺不論是網頁UI設計，還是題目質量，賽事跟蹤，工具軟體都做得很不錯。 而且因為獨到的金幣制度的確讓人有一種想去刷題賺金幣的感覺。 個人還是非常喜歡這個 ......

    uj5u.com 2020-09-10 02:04:05 more
  • 02windows基礎操作

    我學到了一下幾點 Windows系統目錄結構與滲透的作用 常見Windows的服務詳解 Windows埠詳解 常用的Windows注冊表詳解 hacker DOS命令詳解（net user / type /md /rd/ dir /cd /net use copy、批處理 等） 利用dos命令制作 ......

    uj5u.com 2020-09-10 02:04:18 more
  • 03.Linux基礎操作

    我學到了以下幾點 01Linux系統介紹02系統安裝，密碼啊破解03Linux常用命令04LAMP 01LINUX windows： win03 8 12 16 19 配置不繁瑣 Linux：redhat,centos(紅帽社區版)，Ubuntu server,suse unix:金融機構，證券，銀 ......

    uj5u.com 2020-09-10 02:04:30 more
  • 05HTML

    01HTML介紹 02頭部標簽講解03基礎標簽講解04表單標簽講解 HTML前段語言 js1.了解代碼2.根據代碼 懂得挖掘漏洞 （POST注入/XSS漏洞上傳）3.黑帽seo 白帽seo 客戶網站被黑帽植入劫持代碼如何處理4.熟悉html表單 <html><head><title>TDK標題，描述 ......

    uj5u.com 2020-09-10 02:04:36 more
最新发布
  • 2023年最新微信小程式抓包教程

    01 開門見山 隔一個月發一篇文章，不過分。 首先回顧一下《微信系結手機號資料庫被脫庫事件》，我也是第一時間得知了這個訊息，然后跟蹤了整件事情的經過。下面是這起事件的相關截圖以及近日流出的一萬條資料樣本： 個人認為這件事也沒什么，還不如關注一下之前45億快遞資料查詢渠道疑似在近日復活的訊息。 訊息是 ......

    uj5u.com 2023-04-20 08:48:24 more
  • web3 產品介紹：metamask 錢包 使用最多的瀏覽器插件錢包

    Metamask錢包是一種基于區塊鏈技術的數字貨幣錢包，它允許用戶在安全、便捷的環境下管理自己的加密資產。Metamask錢包是以太坊生態系統中最流行的錢包之一，它具有易于使用、安全性高和功能強大等優點。 本文將詳細介紹Metamask錢包的功能和使用方法。 一、 Metamask錢包的功能 數字資 ......

    uj5u.com 2023-04-20 08:47:46 more
  • vulnhub_Earth

    前言 靶機地址->>>vulnhub_Earth 攻擊機ip：192.168.20.121 靶機ip：192.168.20.122 參考文章 https://www.cnblogs.com/Jing-X/archive/2022/04/03/16097695.html https://www.cnb ......

    uj5u.com 2023-04-20 07:46:20 more
  • 從4k到42k，軟體測驗工程師的漲薪史，給我看哭了

    清明節一過，盲猜大家已經無心上班，在數著日子準備過五一，但一想到銀行卡里的余額……瞬間心情就不美麗了。最近，2023年高校畢業生就業調查顯示，本科畢業月平均起薪為5825元。調查一出，便有很多同學表示自己又被平均了。看著這一資料，不免讓人想到前不久中國青年報的一項調查：近六成大學生認為畢業10年內會 ......

    uj5u.com 2023-04-20 07:44:00 more
  • 最新版本 Stable Diffusion 開源 AI 繪畫工具之中文自動提詞篇

    🎈 標簽生成器 由于輸入正向提示詞 prompt 和反向提示詞 negative prompt 都是使用英文，所以對學習母語的我們非常不友好 使用網址：https://tinygeeker.github.io/p/ai-prompt-generator 這個網址是為了讓大家在使用 AI 繪畫的時候 ......

    uj5u.com 2023-04-20 07:43:36 more
  • 漫談前端自動化測驗演進之路及測驗工具分析

    隨著前端技術的不斷發展和應用程式的日益復雜，前端自動化測驗也在不斷演進。隨著 Web 應用程式變得越來越復雜，自動化測驗的需求也越來越高。如今，自動化測驗已經成為 Web 應用程式開發程序中不可或缺的一部分，它們可以幫助開發人員更快地發現和修復錯誤，提高應用程式的性能和可靠性。 ......

    uj5u.com 2023-04-20 07:43:16 more
  • CANN開發實踐：4個DVPP記憶體問題的典型案例解讀

    摘要：由于DVPP媒體資料處理功能對存放輸入、輸出資料的記憶體有更高的要求（例如，記憶體首地址128位元組對齊），因此需呼叫專用的記憶體申請介面，那么本期就分享幾個關于DVPP記憶體問題的典型案例，并給出原因分析及解決方法。 本文分享自華為云社區《FAQ_DVPP記憶體問題案例》，作者：昇騰CANN。 DVPP ......

    uj5u.com 2023-04-20 07:43:03 more
  • msf學習

    msf學習 以kali自帶的msf為例 一、msf核心模塊與功能 msf模塊都放在/usr/share/metasploit-framework/modules目錄下 1、auxiliary 輔助模塊，輔助滲透（埠掃描、登錄密碼爆破、漏洞驗證等） 2、encoders 編碼器模塊，主要包含各種編碼 ......

    uj5u.com 2023-04-20 07:42:59 more
  • Halcon軟體安裝與界面簡介

    1. 下載Halcon17版本到到本地 2. 雙擊安裝包后 3. 步驟如下 1.2 Halcon軟體安裝 界面分為四大塊 1. Halcon的五個助手 1) 影像采集助手：與相機連接，設定相機引數，采集影像 2) 標定助手：九點標定或是其它的標定，生成標定檔案及內參外參，可以將像素單位轉換為長度單位 ......

    uj5u.com 2023-04-20 07:42:17 more
  • 在MacOS下使用Unity3D開發游戲

    第一次發博客，先發一下我的游戲開發環境吧。 去年2月份買了一臺MacBookPro2021 M1pro(以下簡稱mbp)，這一年來一直在用mbp開發游戲。我大致分享一下我的開發工具以及使用體驗。 1、Unity 官網鏈接： https://unity.cn/releases 我一般使用的Apple ......

    uj5u.com 2023-04-20 07:40:19 more

Copyright © 2010-2020 有解無憂