Kubernetes API設計中Conditions怎么用

這篇文章主要介紹了Kubernetes API設計中Conditions怎么用的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇Kubernetes API設計中Conditions怎么用文章都會有所收獲，下面我們一起來看看吧。

導讀

絕大部分Kubernetes資源對象都包含status.conditions字段，用來表示資源狀態，比如deployment資源中的status.conditions如下所示：

  conditions:
  - lastTransitionTime: "2020-12-15T01:52:53Z"
    lastUpdateTime: "2020-12-15T01:52:53Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2020-12-15T01:52:39Z"
    lastUpdateTime: "2020-12-15T01:52:53Z"
    message: ReplicaSet "nginx-deployment-85b45874d9" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing

以上conditions的信息是很容易讀懂的（后面還會詳細解釋），然而有個問題曾經令筆者非常困惑，那就是：

• conditions和status到底有什么區別？

• conditions的設計原則是什么？在設計API擴展時，該如何定義conditions？

本節會先從conditions的設計原則講起，再介紹一些設計conditions時的一些經驗總結。

conditions設計原則

conditions寄居于資源對象的status字段中，與status其他字段值一樣都用來表示資源的狀態。不過conditions的設計初衷是提供一種通用的數據結構表示資源的狀態，它通常能夠提供比status其他字段更詳細的信息（比如狀態切換時間、更新時間），conditions實際上是一種擴展機制，外部監控程序可以根據conditions無差別地監控各種資源的狀態，而不必過分關注資源對象status中的其他信息。

通常status.conditions字段類型為切片，切片中的每個元素表示資源的某個狀態，該狀態由特定的控制器更新，比如Deployment控制器會更新deployment對象的status.conditions信息。conditions作為擴展機制，它還支持第三方控制器增加新的狀態。通常status.conditions中的信息由控制器根據資源的status其他字段計算出來。

condition字段內容

通常一個condition必須包含type（狀態類型）和status（狀態值）兩個信息。在Kubernetes v1.19版之前，關于condition并沒有統一的標準，導致眾多API都自行定義了condition。比如：

• Deployment使用的Condition為type DeploymentCondition struct;

• Pod使用的Condition為type PodCondition struct;

慶幸的是，在Kubernetesv1.19版本社區提供了一個標準的condition類型定義，由于兼容性考慮，Kubernetes既有的API不一定能采用這一標準類型，但對于后續新增的API將會使用這一標準類型，并且筆者建議用戶設計的CRD擴展也應使用這一標準類型。

標準的condition類型定義如下所示：

type ConditionStatus string

const (
	ConditionTrue    ConditionStatus = "True"
	ConditionFalse   ConditionStatus = "False"
	ConditionUnknown ConditionStatus = "Unknown"
)

type Condition struct {
	// 類型（使用駝峰風格），如”Available“。
	Type string
	// 狀態（枚舉值：”True“、”False“和”Unknown“）。
	Status ConditionStatus
	// 觀察到的generation。
	// 如果ObservedGeneration 比metada.generation小，說明不是最新狀態。
	// +optional
	ObservedGeneration int64
	// 上次變化時間
	LastTransitionTime Time
	// 狀態變化原因（使用駝峰風格），如”NewReplicaSetAvailable“
	Reason string
	// 描述信息，如”Deployment has minimum availability“
	Message string `json:"message" protobuf:"bytes,6,opt,name=message"`
}

標準的condition類型定義對condition的各個字段做了進一步約定。除了ObservedGeneration是可選的以外，其他字段都是必填的。

condition設計約定

為了讓condition起到最大的作用，需要遵守一定的設計約定：

約定一：condition定義要有明確的信息

每個condition需要傳遞一個用戶關心的明確信息，用戶讀取到該信息不需要再根據資源的其他狀態來揣測和計算。

約定二：condition需要保持兼容

condition一旦被定義，它就成了API中的一部分，需要跟API一樣提供穩定性保證。如果需要新的condition仍然可以增加（沒有破壞兼容性），但既有的condition是否能夠改變就需要根據API成熟度來決定，比如stable的API不可以改變，alpha的API可以改變。

約定三：condition需要控制器第一次處理資源時更新

控制器需要盡快地更新condition狀態值（condition.status），即便該狀態值為Unknown，這么做的好處是可以讓其他組件了解到控制器正在調諧這個資源。

然而，并不是所有的控制器都能遵守這個約定，即控制器并不會報告特定的condition（此時該condition狀態值可能為Unknown），可能該condition還無法確定，需要在下一次調諧時決定。此種情況下，外部組件無法讀取到特定的condition，可以假設該condition為Unknown。

約定四：condition類型名需要確?？勺x性

condition類型名要使用人類可讀的名稱，而且盡量避免出現雙重否定的語境。例如，類型名Ready比使用Failed要好，因為condition狀態為False時，Failed = False將出現雙重否定，不如Ready = False容易理解。

約定五：condition不要定義成狀態機

condition需要描述當前資源的確定狀態，而不是當前資源狀態機中的狀態。通俗地講，condition類型需要使用形容詞（如Ready）或過去動詞（Succeeded），而不是使用當前運行時（如Deploying）。

關于“Kubernetes API設計中Conditions怎么用”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“Kubernetes API設計中Conditions怎么用”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。