共計 3187 個字符，預(yù)計需要花費 8 分鐘才能閱讀完成。
這篇文章主要介紹了 Kubernetes API 設(shè)計中 Conditions 怎么用的相關(guān)知識，內(nèi)容詳細(xì)易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇 Kubernetes API 設(shè)計中 Conditions 怎么用文章都會有所收獲，下面我們一起來看看吧。
導(dǎo)讀
絕大部分 Kubernetes 資源對象都包含 status.conditions 字段，用來表示資源狀態(tài)，比如 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 的信息是很容易讀懂的（后面還會詳細(xì)解釋），然而有個問題曾經(jīng)令筆者非常困惑，那就是：
conditions 和 status 到底有什么區(qū)別？
conditions 的設(shè)計原則是什么？在設(shè)計 API 擴展時，該如何定義 conditions？
本節(jié)會先從 conditions 的設(shè)計原則講起，再介紹一些設(shè)計 conditions 時的一些經(jīng)驗總結(jié)。
conditions 設(shè)計原則
conditions 寄居于資源對象的 status 字段中，與 status 其他字段值一樣都用來表示資源的狀態(tài)。不過 conditions 的設(shè)計初衷是提供一種通用的數(shù)據(jù)結(jié)構(gòu)表示資源的狀態(tài)，它通常能夠提供比 status 其他字段更詳細(xì)的信息（比如狀態(tài)切換時間、更新時間），conditions 實際上是一種擴展機制，外部監(jiān)控程序可以根據(jù) conditions 無差別地監(jiān)控各種資源的狀態(tài)，而不必過分關(guān)注資源對象 status 中的其他信息。
通常 status.conditions 字段類型為切片，切片中的每個元素表示資源的某個狀態(tài)，該狀態(tài)由特定的控制器更新，比如 Deployment 控制器會更新 deployment 對象的 status.conditions 信息。conditions 作為擴展機制，它還支持第三方控制器增加新的狀態(tài)。通常 status.conditions 中的信息由控制器根據(jù)資源的 status 其他字段計算出來。
condition 字段內(nèi)容
通常一個 condition 必須包含 type（狀態(tài)類型）和 status（狀態(tài)值）兩個信息。在 Kubernetes v1.19 版之前，關(guān)于 condition 并沒有統(tǒng)一的標(biāo)準(zhǔn)，導(dǎo)致眾多 API 都自行定義了 condition。比如：
Deployment 使用的 Condition 為 type DeploymentCondition struct;
Pod 使用的 Condition 為 type PodCondition struct;
慶幸的是，在 Kubernetesv1.19 版本社區(qū)提供了一個標(biāo)準(zhǔn)的 condition 類型定義，由于兼容性考慮，Kubernetes 既有的 API 不一定能采用這一標(biāo)準(zhǔn)類型，但對于后續(xù)新增的 API 將會使用這一標(biāo)準(zhǔn)類型，并且筆者建議用戶設(shè)計的 CRD 擴展也應(yīng)使用這一標(biāo)準(zhǔn)類型。
標(biāo)準(zhǔn)的 condition 類型定義如下所示：
type ConditionStatus string
const (
ConditionTrue ConditionStatus = True
ConditionFalse ConditionStatus = False
ConditionUnknown ConditionStatus = Unknown
type Condition struct {
// 類型（使用駝峰風(fēng)格），如”Available“。Type string
// 狀態(tài)（枚舉值：”True“、”False“和”Unknown“）。Status ConditionStatus
// 觀察到的 generation。// 如果 ObservedGeneration 比 metada.generation 小，說明不是最新狀態(tài)。// +optional
ObservedGeneration int64
// 上次變化時間
LastTransitionTime Time
// 狀態(tài)變化原因（使用駝峰風(fēng)格），如”NewReplicaSetAvailable“Reason string
// 描述信息，如”Deployment has minimum availability“Message string `json: message protobuf: bytes,6,opt,name=message `
}標(biāo)準(zhǔn)的 condition 類型定義對 condition 的各個字段做了進一步約定。除了 ObservedGeneration 是可選的以外，其他字段都是必填的。
condition 設(shè)計約定
為了讓 condition 起到最大的作用，需要遵守一定的設(shè)計約定：
約定一：condition 定義要有明確的信息
每個 condition 需要傳遞一個用戶關(guān)心的明確信息，用戶讀取到該信息不需要再根據(jù)資源的其他狀態(tài)來揣測和計算。
約定二：condition 需要保持兼容
condition 一旦被定義，它就成了 API 中的一部分，需要跟 API 一樣提供穩(wěn)定性保證。如果需要新的 condition 仍然可以增加（沒有破壞兼容性），但既有的 condition 是否能夠改變就需要根據(jù) API 成熟度來決定，比如 stable 的 API 不可以改變，alpha 的 API 可以改變。
約定三：condition 需要控制器第一次處理資源時更新
控制器需要盡快地更新 condition 狀態(tài)值（condition.status），即便該狀態(tài)值為 Unknown，這么做的好處是可以讓其他組件了解到控制器正在調(diào)諧這個資源。
然而，并不是所有的控制器都能遵守這個約定，即控制器并不會報告特定的 condition（此時該 condition 狀態(tài)值可能為 Unknown），可能該 condition 還無法確定，需要在下一次調(diào)諧時決定。此種情況下，外部組件無法讀取到特定的 condition，可以假設(shè)該 condition 為 Unknown。
約定四：condition 類型名需要確保可讀性
condition 類型名要使用人類可讀的名稱，而且盡量避免出現(xiàn)雙重否定的語境。例如，類型名 Ready 比使用 Failed 要好，因為 condition 狀態(tài)為 False 時，F(xiàn)ailed = False 將出現(xiàn)雙重否定，不如 Ready = False 容易理解。
約定五：condition 不要定義成狀態(tài)機
condition 需要描述當(dāng)前資源的確定狀態(tài)，而不是當(dāng)前資源狀態(tài)機中的狀態(tài)。通俗地講，condition 類型需要使用形容詞（如 Ready）或過去動詞（Succeeded），而不是使用當(dāng)前運行時（如 Deploying）。
關(guān)于“Kubernetes API 設(shè)計中 Conditions 怎么用”這篇文章的內(nèi)容就介紹到這里，感謝各位的閱讀！相信大家對“Kubernetes API 設(shè)計中 Conditions 怎么用”知識都有一定的了解，大家如果還想學(xué)習(xí)更多知識，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。
