理解 K8s 資源更新機制，從一個 OpenKruise 用戶疑問開始

背景

OpenKruise 是阿里云開源的大規(guī)模應(yīng)用自動化管理引擎，在功能上對標了 Kubernetes 原生的 Deployment / StatefulSet 等控制器，但 OpenKruise 提供了更多的增強功能如：優(yōu)雅原地升級、發(fā)布優(yōu)先級/打散策略、多可用區(qū)workload抽象管理、統(tǒng)一 sidecar 容器注入管理等，都是經(jīng)歷了阿里巴巴超大規(guī)模應(yīng)用場景打磨出的核心能力。這些 feature 幫助我們應(yīng)對更加多樣化的部署環(huán)境和需求、為集群維護者和應(yīng)用開發(fā)者帶來更加靈活的部署發(fā)布組合策略。

目前在阿里巴巴內(nèi)部云原生環(huán)境中，絕大部分應(yīng)用都統(tǒng)一使用 OpenKruise 的能力做 Pod 部署、發(fā)布管理，而不少業(yè)界公司和阿里云上客戶由于 K8s 原生 Deployment 等負載不能完全滿足需求，也轉(zhuǎn)而采用 OpenKruise 作為應(yīng)用部署載體。

今天的分享文章就從一個阿里云上客戶對接 OpenKruise 的疑問開始。這里還原一下這位同學(xué)的用法（以下 YAML 數(shù)據(jù)僅為 demo）：

準備一份 Advanced StatefulSet 的 YAML 文件，并提交創(chuàng)建。如：

apiVersion: apps.kruise.io/v1alpha1
kind: StatefulSet
metadata:
name: sample
spec:
# ...
template:

# ...spec:
  containers:
    - name: main
      image: nginx:alpine

updateStrategy:

type: RollingUpdaterollingUpdate:  podUpdatePolicy: InPlaceIfPossible

然后，修改了 YAML 中的 image 鏡像版本，然后調(diào)用 K8s api 接口做更新。結(jié)果收到報錯如下：

metadata.resourceVersion: Invalid value: 0x0: must be specified for an update

而如果使用 kubectl apply 命令做更新，則返回成功：

statefulset.apps.kruise.io/sample configured

問題在于，為什么同一份修改后的 YAML 文件，調(diào)用 api 接口更新是失敗的，而用 kubectl apply 更新是成功的呢？這其實并不是 OpenKruise 有什么特殊校驗，而是由 K8s 自身的更新機制所決定的。

從我們的接觸來看，絕大多數(shù)用戶都有通過 kubectl 命令或是 sdk 來更新 K8s 資源的經(jīng)驗，但真正理解這些更新操作背后原理的人卻并不多。本文將著重介紹 K8s 的資源更新機制，以及一些我們常用的更新方式是如何實現(xiàn)的。

更新原理

不知道你有沒有想過一個問題：對于一個 K8s 資源對象比如 Deployment，我們嘗試在修改其中 image 鏡像時，如果有其他人同時也在對這個 Deployment 做修改，會發(fā)生什么？

當然，這里還可以引申出兩個問題：

• 如果雙方修改的是同一個字段，比如 image 字段，結(jié)果會怎樣？
• 如果雙方修改的是不同字段，比如一個修改 image，另一個修改 replicas，又會怎么樣？

其實，對一個 Kubernetes 資源對象做“更新”操作，簡單來說就是通知 kube-apiserver 組件我們希望如何修改這個對象。而 K8s 為這類需求定義了兩種“通知”方式，分別是 update 和 patch。在 update 請求中，我們需要將整個修改后的對象提交給 K8s；而對于 patch 請求，我們只需要將對象中某些字段的修改提交給 K8s。

那么回到背景問題，為什么用戶提交修改后的 YAML 文件做 update 會失敗呢？這其實是被 K8s 對 update 請求的版本控制機制所限制的。

Update 機制

Kubernetes 中的所有資源對象，都有一個全局唯一的版本號（metadata.resourceVersion）。每個資源對象從創(chuàng)建開始就會有一個版本號，而后每次被修改（不管是 update 還是 patch 修改），版本號都會發(fā)生變化。

官方文檔告訴我們，這個版本號是一個 K8s 的內(nèi)部機制，用戶不應(yīng)該假設(shè)它是一個數(shù)字或者通過比較兩個版本號大小來確定資源對象的新舊，唯一能做的就是通過比較版本號相等來確定對象是否是同一個版本（即是否發(fā)生了變化）。而 resourceVersion 一個重要的用處，就是來做 update 請求的版本控制。

K8s 要求用戶 update 請求中提交的對象必須帶有 resourceVersion，也就是說我們提交 update 的數(shù)據(jù)必須先來源于 K8s 中已經(jīng)存在的對象。因此，一次完整的 update 操作流程是：

• 首先，從 K8s 中拿到一個已經(jīng)存在的對象（可以選擇直接從 K8s 中查詢；如果在客戶端做了 list watch，推薦從本地 informer 中獲?。?；
• 然后，基于這個取出來的對象做一些修改，比如將 Deployment 中的 replicas 做增減，或是將 image 字段修改為一個新版本的鏡像；
• 最后，將修改后的對象通過 update 請求提交給 K8s；
• 此時，kube-apiserver 會校驗用戶 update 請求提交對象中的 resourceVersion 一定要和當前 K8s 中這個對象最新的 resourceVersion 一致，才能接受本次 update。否則，K8s 會拒絕請求，并告訴用戶發(fā)生了版本沖突（Conflict）。

上圖展示了多個用戶同時 update 某一個資源對象時會發(fā)生的事情。而如果如果發(fā)生了 Conflict 沖突，對于 User A 而言應(yīng)該做的就是做一次重試，再次獲取到最新版本的對象，修改后重新提交 update。

因此，我們上面的兩個問題也都得到了解答：

• 用戶修改 YAML 后提交 update 失敗，是因為 YAML 文件中沒有包含 resourceVersion 字段。對于 update 請求而言，應(yīng)該取出當前 K8s 中的對象做修改后提交；
• 如果兩個用戶同時對一個資源對象做 update，不管操作的是對象中同一個字段還是不同字段，都存在版本控制的機制確保兩個用戶的 update 請求不會發(fā)生覆蓋。

Patch 機制

相比于 update 的版本控制，K8s 的 patch 機制則顯得更加簡單。

當用戶對某個資源對象提交一個 patch 請求時，kube-apiserver 不會考慮版本問題，而是“無腦”地接受用戶的請求（只要請求發(fā)送的 patch 內(nèi)容合法），也就是將 patch 打到對象上、同時更新版本號。

不過，patch 的復(fù)雜點在于，目前 K8s 提供了 4 種 patch 策略：json patch、merge patch、strategic merge patch、apply patch（從 K8s 1.14 支持 server-side apply 開始）。通過 kubectl patch -h 命令我們也可以看到這個策略選項（默認采用 strategic）：

$ kubectl patch -h

...

--type='strategic': The type of patch being provided; one of [json merge strategic]
篇幅限制這里暫不對每個策略做詳細的介紹了，我們就以一個簡單的例子來看一下它們的差異性。如果針對一個已有的 Deployment 對象，假設(shè) template 中已經(jīng)有了一個名為 app 的容器：

• 如果要在其中新增一個 nginx 容器，如何 patch 更新？
• 如果要修改 app 容器的鏡像，如何 patch 更新？

json patch（[RFC 6902]()）

新增容器：

kubectl patch deployment/foo --type='json' -p \
'[{"op":"add","path":"/spec/template/spec/containers/1","value":{"name":"nginx","image":"nginx:alpine"}}]'
修改已有容器 image：

kubectl patch deployment/foo --type='json' -p \
'[{"op":"replace","path":"/spec/template/spec/containers/0/image","value":"app-image:v2"}]'

可以看到，在 json patch 中我們要指定操作類型，比如 add 新增還是 replace 替換，另外在修改 containers 列表時要通過元素序號來指定容器。

這樣一來，如果我們 patch 之前這個對象已經(jīng)被其他人修改了，那么我們的 patch 有可能產(chǎn)生非預(yù)期的后果。比如在執(zhí)行 app 容器鏡像更新時，我們指定的序號是 0，但此時 containers 列表中第一個位置被插入了另一個容器，則更新的鏡像就被錯誤地插入到這個非預(yù)期的容器中。

merge patch（RFC 7386）

merge patch 無法單獨更新一個列表中的某個元素，因此不管我們是要在 containers 里新增容器、還是修改已有容器的 image、env 等字段，都要用整個 containers 列表來提交 patch：

kubectl patch deployment/foo --type='merge' -p \
'{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"app-image:v2"},{"name":"nginx","image":"nginx:alpline"}]}}}}'

顯然，這個策略并不適合我們對一些列表深層的字段做更新，更適用于大片段的覆蓋更新。

不過對于 labels/annotations 這些 map 類型的元素更新，merge patch 是可以單獨指定 key-value 操作的，相比于 json patch 方便一些，寫起來也更加直觀：

kubectl patch deployment/foo --type='merge' -p '{"metadata":{"labels":{"test-key":"foo"}}}'

strategic merge patch

這種 patch 策略并沒有一個通用的 RFC 標準，而是 K8s 獨有的，不過相比前兩種而言卻更為強大的。

我們先從 K8s 源碼看起，在 K8s 原生資源的數(shù)據(jù)結(jié)構(gòu)定義中額外定義了一些的策略注解。比如以下這個截取了 podSpec 中針對 containers 列表的定義，參考 Github：

// ...
// +patchMergeKey=name
// +patchStrategy=merge
Containers []Container  json:"containers" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,2,rep,name=containers"

可以看到其中有兩個關(guān)鍵信息：patchStrategy:"merge" patchMergeKey:"name" 。這就代表了，containers 列表使用 strategic merge patch 策略更新時，會把下面每個元素中的 name 字段看作 key。

簡單來說，在我們 patch 更新 containers 不再需要指定下標序號了，而是指定 name 來修改，K8s 會把 name 作為 key 來計算 merge。比如針對以下的 patch 操作：

kubectl patch deployment/foo -p \
'{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:mainline"}]}}}}'

如果 K8s 發(fā)現(xiàn)當前 containers 中已經(jīng)有名字為 nginx 的容器，則只會把 image 更新上去；而如果當前 containers 中沒有 nginx 容器，K8s 會把這個容器插入 containers 列表。

此外還要說明的是，目前 strategic 策略只能用于原生 K8s 資源以及 Aggregated API 方式的自定義資源，對于 CRD 定義的資源對象，是無法使用的。這很好理解，因為 kube-apiserver 無法得知 CRD 資源的結(jié)構(gòu)和 merge 策略。如果用 kubectl patch 命令更新一個 CR，則默認會采用 merge patch 的策略來操作。

kubectl 封裝

了解完了 K8s 的基礎(chǔ)更新機制，我們再次回到最初的問題上。為什么用戶修改 YAML 文件后無法直接調(diào)用 update 接口更新，卻可以通過 kubectl apply 命令更新呢？

其實 kubectl 為了給命令行用戶提供良好的交互體感，設(shè)計了較為復(fù)雜的內(nèi)部執(zhí)行邏輯，諸如 apply、edit 這些常用操作其實背后并非對應(yīng)一次簡單的 update 請求。畢竟 update 是有版本控制的，如果發(fā)生了更新沖突對于普通用戶并不友好。以下簡略介紹下 kubectl 幾種更新操作的邏輯，有興趣可以看一下 kubectl 封裝的源碼。

apply

在使用默認參數(shù)執(zhí)行 apply 時，觸發(fā)的是 client-side apply。kubectl 邏輯如下：

首先解析用戶提交的數(shù)據(jù)（YAML/JSON）為一個對象 A；然后調(diào)用 Get 接口從 K8s 中查詢這個資源對象：

如果查詢結(jié)果不存在，kubectl 將本次用戶提交的數(shù)據(jù)記錄到對象 A 的 annotation 中（key 為 kubectl.kubernetes.io/last-applied-configuration），最后將對象 A提交給 K8s 創(chuàng)建；

如果查詢到 K8s 中已有這個資源，假設(shè)為對象 B：1. kubectl 嘗試從對象 B 的 annotation 中取出 kubectl.kubernetes.io/last-applied-configuration 的值（對應(yīng)了上一次 apply 提交的內(nèi)容）；2. kubectl 根據(jù)前一次 apply 的內(nèi)容和本次 apply 的內(nèi)容計算出 diff（默認為 strategic merge patch 格式，如果非原生資源則采用 merge patch）；3. 將 diff 中添加本次的 kubectl.kubernetes.io/last-applied-configuration annotation，最后用 patch 請求提交給 K8s 做更新。
這里只是一個大致的流程梳理，真實的邏輯會更復(fù)雜一些，而從 K8s 1.14 之后也支持了 server-side apply，有興趣的同學(xué)可以看一下源碼實現(xiàn)。

edit

kubectl edit 邏輯上更簡單一些。在用戶執(zhí)行命令之后，kubectl 從 K8s 中查到當前的資源對象，并打開一個命令行編輯器（默認用 vi）為用戶提供編輯界面。

當用戶修改完成、保存退出時，kubectl 并非直接把修改后的對象提交 update（避免 Conflict，如果用戶修改的過程中資源對象又被更新），而是會把修改后的對象和初始拿到的對象計算 diff，最后將 diff 內(nèi)容用 patch 請求提交給 K8s。

總結(jié)
看了上述的介紹，大家應(yīng)該對 K8s 更新機制有了一個初步的了解了。接下來想一想，既然 K8s 提供了兩種更新方式，我們在不同的場景下怎么選擇 update 或 patch 來使用呢？這里我們的建議是：

如果要更新的字段只有我們自己會修改（比如我們有一些自定義標簽，并寫了 operator 來管理），則使用 patch 是最簡單的方式；
如果要更新的字段可能會被其他方修改（比如我們修改的 replicas 字段，可能有一些其他組件比如 HPA 也會做修改），則建議使用 update 來更新，避免出現(xiàn)互相覆蓋。
最終我們的客戶改為基于 get 到的對象做修改后提交 update，終于成功觸發(fā)了 Advanced StatefulSet 的原地升級。此外，我們也歡迎和鼓勵更多的同學(xué)參與到 OpenKruise 社區(qū)中，共同合作打造一款面向規(guī)模化場景、高性能的應(yīng)用交付解決方案。（歡迎加入釘釘交流群：23330762）

課程推薦

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結(jié)了 10+ 位阿里巴巴 Serverless 領(lǐng)域技術(shù)專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學(xué)即用，輕松擁抱云計算的新范式——Serverless。

點擊即可免費觀看課程： https://developer.aliyun.com/...

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號?！?/p>