1. 程式人生 > >如何基於Kubernetes開發自定義的Controller_Kubernetes中文社群

如何基於Kubernetes開發自定義的Controller_Kubernetes中文社群

繼上次分享Kubernetes原始碼編譯除錯之後,一直想寫些對scheduler,controller-manager,kubelete等元件的深入介紹,今天先介紹下Controller部分,在kubernetes內部提供了大量的controller,比如node controller,pod controller,endpoint controller等等。這些controller都是由controller-manager進行管理。每個Controller通過API Server提供的介面實時監控整個叢集的每個資源物件的當前狀態,當發生各種故障導致系統狀態發生變化時,會嘗試通過CRUD操作將系統狀態修復到“期望狀態”。

在kubernetes中一切皆資源,Kubernetes 1.7之後,提供了CRD(CustomResourceDefinitions)的自定義資源二次開發能力來擴充套件kubernetes API,通過此擴充套件,可以向kubernetes API中增加新型別,會比修改kubernetes的原始碼或者是建立自定義的API server來的更加的簡潔和容易,並且不會隨著kuberntetes核心版本的升級,而出現需要程式碼重新merger的需要,以及相容性方面的問題。這一功能特性的提供大大提升了kubernetes的擴充套件能力。

具體使用建議見:請參考Should I add a custom resource to my Kubernetes Cluster?

Kube – Controller的內部大致實現邏輯:

主要使用到 Informer和workqueue兩個核心元件。Controller可以有一個或多個informer來跟蹤某一個resource。Informter跟API server保持通訊獲取資源的最新狀態並更新到本地的cache中,一旦跟蹤的資源有變化,informer就會呼叫callback。把關心的變更的Object放到workqueue裡面。然後woker執行真正的業務邏輯,計算和比較workerqueue裡items的當前狀態和期望狀態的差別,然後通過client-go向API server傳送請求,直到驅動這個叢集向用戶要求的狀態演化。

具體對client-go的使用,可參考《client-go的使用和原始碼分析》,在編寫自定義的Controller的時候,需要大量使用client-go元件。上圖中的藍色部分全部是client-go已經包含的部分,不需要重新開發可以直接使用。紅色的部分是自己的業務邏輯,需要自己開發。可見基於CRD開發一個自定義的資源管理API 來擴充套件kubernetes的底層能力還是非常簡潔的。比如在kubernetes中目前還是沒有辦法可以做到通過pod直接查詢到對應的service是誰。為了實現這個定製化的能力,為上層操作提供介面,就可以來擴充套件這個能力,寫一個pod-service-controller。這個controller中提供兩個informer,一個informer關注pod資源,一個informer關注service資源。把各自的變化情況通過回撥的方式放到workerqueue中。然後在worker中併發的去處理queue中的item。整理出pod和service的對映關係。這樣上層就可以直接通過該controller的RESTful API 查詢到他們之間的對映關係。而不需要在上層哐哐的寫一堆業務處理邏輯。

下面以sample-controller為例,來講解開發自定義Controller的關鍵步驟和注意點。

1. 根據CRD的模板定義出自己的資源管理物件。比如crd.yaml檔案

apiVersion: apiextensions.k8s.io/v1beta1

kind: CustomResourceDefinition

metadata:

#名稱必須符合下面的格式:<plural>.<group>

name: foos.samplecontroller.k8s.io

spec:

# REST API使用的組名稱:/apis/<group>/<version>

group: samplecontroller.k8s.io

# REST API使用的版本號:/apis/<group>/<version>

version: v1alpha1

names:

# CamelCased格式的單數型別。在清單檔案中使用

kind: Foo

# URL中使用的複數名稱: /apis/<group>/<version>/<plural>

plural: foos



# Namespaced或Cluster

scope: Namespaced



validation:

openAPIV3Schema:

properties:

spec:

properties:

replicas:

type: integer

minimum: 1

maximum: 10

2. Kubectl create  –f  crd.yaml  執行完成後就建立了Foo這個資源物件。沒有修改任何kubernetes核心程式碼,僅通過定義CustomResourceDefinition型別的yaml檔案就可以直接建立新的資源物件,非常的簡單和方便

一旦你建立CRD後,可以使用如下命令來驗證CRD是否建立成功

kubectl get crd -o 'custom-columns=NAME:{.metadata.name},ESTABLISHED:{.status.conditions[?(@.type=="Established")].status}'

執行後輸出如下:

NAME ESTABLISHED

foos.samplecontroller.k8s.io True

3. 使用Foo這個新建立的型別,建立一個pod。

apiVersion: samplecontroller.k8s.io/v1alpha1

kind: Foo

metadata:

name: example-foo

spec:

deploymentName: example-foo

replicas: 1



使用kubectl create –f example-foo.yaml

NAME                           READY     STATUS    RESTARTS   AGE

example-foo-86ccd54874-9ctfm        1/1       Running   0          3h

4. Foo型別的Pod物件建立成功後,結合上對Foo型別資源的控制才會讓資源物件有意義。所以還需要開發一個自定義的Foo-Controller。

5. 定義一個Controller結構體

6. 構造出workqueue和Informer物件用於初始化Controller物件

7. 通過informer監控資源CRUD的操作的回撥函式

8. 啟動Controller

在run函式中在worker執行前,必須要等待狀態的同步完成。使用go啟動多個worker協程併發的從queue中一個個的獲取待處理的Item。其中的runwoker是包含真正的業務邏輯的函式。

9.

以上便是一個完整的編寫自定義Controller的完整過程。比如推薦大家一個比較好的Controller學習參考實現就是kubewatch,事件探測器。

https://github.com/bitnami-labs/kubewatch