前面我們和大家已經學習了?OpenKruise?的基本概念以及常用的幾個增強控制器，接下來我們來繼續了解其他高級功能。
SidecarSet
SidecarSet 支持通過 admission webhook 來自動為集群中創建的符合條件的 Pod 注入 sidecar 容器，除了在 Pod 創建時候注入外，SidecarSet 還提供了為 Pod 原地升級其中已經注入的 sidecar 容器鏡像的能力。SidecarSet 將 sidecar 容器的定義和生命周期與業務容器解耦，它主要用于管理無狀態的 sidecar 容器，比如監控、日志等 agent。
比如我們定義一個如下所示的 SidecarSet 資源對象：
# sidecarset-demo.yaml apiVersion: apps.kruise.io/v1alpha1 kind: SidecarSet metadata: name: scs-demo spec: selector: matchLabels: # 非常重要的屬性，會去匹配具有 app=nginx 的 Pod app: nginx updateStrategy: type: RollingUpdate maxUnavailable: 1 containers: - name: sidecar1 image: busybox command: ["sleep", "999d"] volumeMounts: - name: log-volume mountPath: /var/log volumes: # 該屬性會被合并到 pod.spec.volumes 去 - name: log-volume emptyDir: {}
直接創建這個資源對象即可：
? kubectl get sidecarset NAME MATCHED UPDATED READY AGE scs-demo 0 0 0 6s
需要注意上面我們在定義 SidecarSet 對象的時候里面有一個非常重要的屬性就是 label selector，會去匹配具有?app=nginx??的 Pod，然后向其中注入下面定義的?sidecar1??這個容器，比如定義如下所示的一個 Pod，該 Pod 中包含?app=nginx?的標簽，這樣可以和上面的 SidecarSet 對象匹配：
apiVersion: v1 kind: Pod metadata: labels: app: nginx # 匹配 SidecarSet 里面指定的標簽 name: test-pod spec: containers: - name: app image: nginx:1.7.9
直接創建上面的資源對象：
? kubectl get pod test-pod NAME READY STATUSRESTARTS AGE test-pod 2/2 Running 022s
可以看到該 Pod 中有 2 個容器，被自動注入了上面定義的?sidecar1?容器：
? kubectl get pod test-pod -o yaml apiVersion: v1 kind: Pod metadata: labels: app: nginx name: test-pod namespace: default spec: containers: - command: - sleep - 999d env: - name: IS_INJECTED value: "true" image: busybox imagePullPolicy: Always name: sidecar1 resources: {} volumeMounts: - mountPath: /var/log name: log-volume - image: nginx:1.7.9 imagePullPolicy: IfNotPresent name: app # ...... volumes: - emptyDir: {} name: log-volume # ......
現在我們去更新 SidecarSet 中的 sidecar 容器鏡像替換成?busybox:1.35.0：
? kubectl patch sidecarset scs-demo --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value": "busybox:1.35.0"}]' sidecarset.apps.kruise.io/scs-demo patched
更新后再去查看 Pod 中的 sidecar 容器：
? kubectl get pod test-pod NAME READY STATUSRESTARTSAGE test-pod 2/2 Running 1 (67s ago) 28m ? kubectl describe pod test-pod ...... Events: TypeReason AgeFrom Message ---------- ---- ---- ------- # ...... NormalCreated10mkubeletCreated container app NormalStarted10mkubeletStarted container app NormalKilling114s kubeletContainer sidecar1 definition changed, will be restarted NormalPulling84skubeletPulling image "busybox:1.35.0" NormalCreated77s (x2 over 11m)kubeletCreated container sidecar1 NormalStarted77s (x2 over 11m)kubeletStarted container sidecar1 NormalPulled 77skubeletSuccessfully pulled image "busybox:1.35.0" in 6.901558972s (6.901575894s including waiting) ? kubectl get pod test-pod -o yaml |grep busybox kruise.io/sidecarset-inplace-update-state: '{"scs-demo":{"revision":"f78z4854d9855xd6478fzx9c84645z2548v24z26455db46bdfzw44v49v98f2cw","updateTimestamp":"2023-04-04T08:05:18Z","lastContainerStatuses":{"sidecar1":{"imageID":"docker.io/library/busybox@sha256:b5d6fe0712636ceb7430189de28819e195e8966372edfc2d9409d79402a0dc16"}}}}' image: busybox:1.35.0 image: docker.io/library/busybox:1.35.0 imageID: docker.io/library/busybox@sha256:223ae047b1065bd069aac01ae3ac8088b3ca4a527827e283b85112f29385fb1b
可以看到 Pod 中的 sidecar 容器鏡像被原地升級成?busybox:1.35.0?了， 對主容器沒有產生任何影響。
基本特性
需要注意的是 sidecar 的注入只會發生在 Pod 創建階段，并且只有 Pod spec 會被更新，不會影響 Pod 所屬的工作負載 template 模板。?spec.containers?除了默認的 k8s container 字段，還擴展了如下一些字段，來方便注入：
apiVersion: apps.kruise.io/v1alpha1 kind: SidecarSet metadata: name: sidecarset spec: selector: matchLabels: app: sample containers: # 默認的 K8s 容器字段 - name: nginx image: nginx:alpine volumeMounts: - mountPath: /nginx/conf name: nginxconf # 擴展的 sidecar 容器字段 podInjectPolicy: BeforeAppContainer shareVolumePolicy: # 數據卷共享 type: disabled | enabled transferEnv: # 環境變量共享 - sourceContainerName: main # 會把main容器中的PROXY_IP環境變量注入到當前定義的sidecar容器中 envName: PROXY_IP volumes: - Name: nginxconf hostPath: /data/nginx/conf
- podInjectPolicy??定義了容器 注入到?pod.spec.containers?中的位置。
- BeforeAppContainer：表示注入到 pod 原 containers 的前面(默認)。
- AfterAppContainer： 表示注入到 pod 原 containers 的后面。
- 數據卷共享。
- 共享指定卷：通過?spec.volumes?來定義 sidecar 自身需要的 volume。
- 共享所有卷：通過?spec.containers[i].shareVolumePolicy.type = enabled | disabled?來控制是否掛載 pod 應用容器的卷，常用于日志收集等 sidecar，配置為?enabled?后會把應用容器中所有掛載點注入 sidecar 同一路經下（sidecar 中本身就有聲明的數據卷和掛載點除外）。
- 環境變量共享：可以通過?spec.containers[i].transferEnv?來從別的容器獲取環境變量，會把名為?sourceContainerName?容器中名為?envName?的環境變量拷貝到本容器。
SidecarSet 不僅支持 sidecar 容器的原地升級，而且提供了非常豐富的升級、灰度策略。同樣在 SidecarSet 對象中?updateStrategy??屬性下面也可以配置?partition??來定義保留舊版本 Pod 的數量或百分比，默認為 0；同樣還可以配置的有?maxUnavailable?屬性，表示在發布過程中的最大不可用數量。
- 當?{matched pod}=100,partitinotallow=40,maxUnavailable=10，控制器會發布 100-40=60 個 Pod 到新版本，但是同一時間只會發布 10 個 Pod，每發布好一個 Pod 才會再找一個發布，直到 60 個發布完成。
- 當?{matched pod}=100,partitinotallow=80,maxUnavailable=30，控制器會發布 20 個 Pod 到新版本，因為滿足 maxUnavailable 數量，所以這 20 個 Pod 會同時發布。
同樣也可以設置?paused: true?來暫停發布，此時對于新創建的、擴容的 pod 依舊會實現注入能力，已經更新的 pod 會保持更新后的版本不動，還沒有更新的 pod 會暫停更新。
apiVersion: apps.kruise.io/v1alpha1 kind: SidecarSet metadata: name: sidecarset spec: # ... updateStrategy: type: RollingUpdate maxUnavailable: 20% partition: 10 paused: true
金絲雀發布
對于有金絲雀發布需求的業務，可以通過?selector??來實現，對于需要率先金絲雀灰度的 pod 打上固定的?[canary.release] = true??的標簽，再通過?selector.matchLabels?來選中該 pod 即可。
比如現在我們有一個 3 副本的 Pod，也具有?app=nginx?的標簽，如下所示：
apiVersion: apps/v1 kind: Deployment metadata: name: nginx namespace: default spec: replicas: 3 revisionHistoryLimit: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: ngx image: nginx:1.7.9 ports: - containerPort: 80
創建后現在就具有 4 個?app=nginx??標簽的 Pod 了，由于都匹配上面創建的 SidecarSet 對象，所以都會被注入一個?sidecar1??的容器，鏡像為?busybox：
? kubectl get pods -l app=nginx NAMEREADY STATUSRESTARTS AGE nginx-6457955f7-7hnjw 2/2 Running 051s nginx-6457955f7-prkgz 2/2 Running 051s nginx-6457955f7-tbtxk 2/2 Running 051s test-pod2/2 Running 04m2s
現在如果我們想為?test-pod??這個應用來執行灰度策略，將 sidecar 容器鏡像更新成?busybox:1.35.0?，則可以在?updateStrategy??下面添加?selector.matchLabels??屬性?canary.release: “true”：
piVersion: apps.kruise.io/v1alpha1 kind: SidecarSet metadata: name: test-sidecarset spec: updateStrategy: type: RollingUpdate selector: matchLabels: canary.release: "true" containers: - name: sidecar1 image: busybox:1.35.0 # ......
然后同樣需要給 test-pod 添加上?canary.release=true?這個標簽：
apiVersion: v1 kind: Pod metadata: labels: app: nginx canary.release: "true" name: test-pod spec: containers: - name: app image: nginx:1.7.9
更新后可以發現 test-pod 的 sidecar 鏡像更新了，其他 Pod 沒有變化，這樣就實現了 sidecar 的灰度功能：
? kubectl describe pod test-pod Events: TypeReason AgeFrom Message ---------- ---- ---- ------- NormalKilling7m53skubeletContainer sidecar1 definition changed, will be restarted NormalCreated7m23s (x2 over 8m17s)kubeletCreated container sidecar1 NormalStarted7m23s (x2 over 8m17s)kubeletStarted container sidecar1 NormalPulling7m23skubeletPulling image "busybox" NormalPulled 7m23skubeletSuccessfully pulled image "busybox" in 603.928658ms
熱升級
SidecarSet 原地升級會先停止舊版本的容器，然后創建新版本的容器，這種方式適合不影響 Pod 服務可用性的 sidecar 容器，比如說日志收集的 Agent。
但是對于很多代理或運行時的 sidecar 容器，例如 Istio Envoy，這種升級方法就有問題了，Envoy 作為 Pod 中的一個代理容器，代理了所有的流量，如果直接重啟，Pod 服務的可用性會受到影響，如果需要單獨升級 envoy sidecar，就需要復雜的優雅終止和協調機制，所以我們為這種 sidecar 容器的升級提供了一種新的解決方案。
# hotupgrade-sidecarset.yaml apiVersion: apps.kruise.io/v1alpha1 kind: SidecarSet metadata: name: hotupgrade-sidecarset spec: selector: matchLabels: app: hotupgrade containers: - name: sidecar image: openkruise/hotupgrade-sample:sidecarv1 imagePullPolicy: Always lifecycle: postStart: exec: command: - /bin/sh - /migrate.sh upgradeStrategy: upgradeType: HotUpgrade hotUpgradeEmptyImage: openkruise/hotupgrade-sample:empty
- upgradeType?:?HotUpgrade?代表該 sidecar 容器的類型是熱升級方案。
- hotUpgradeEmptyImage?: 當熱升級 sidecar 容器時，業務必須要提供一個 empty 容器用于熱升級過程中的容器切換，empty 容器同 sidecar 容器具有相同的配置（除了鏡像地址），例如：command?、lifecycle?、probe?等，但是它不做任何工作。
- lifecycle.postStart: 在 postStart 這個 hook 中完成熱升級過程中的狀態遷移，該腳本需要由業務根據自身的特點自行實現，例如：nginx 熱升級需要完成 Listen FD 共享以及流量排水（reload）操作。
整體來說熱升級特性總共包含以下兩個過程：
- Pod 創建時，注入熱升級容器。
- 原地升級時，完成熱升級流程。
注入熱升級容器
Pod 創建時，SidecarSet Webhook 將會注入兩個容器：
- {sidecarContainer.name}-1?: 如下圖所示?envoy-1?，這個容器代表正在實際工作的 sidecar 容器，例如：envoy:1.16.0。
- {sidecarContainer.name}-2?: 如下圖所示?envoy-2?，這個容器是業務配置的?hotUpgradeEmptyImage??容器，例如：empty:1.0，用于后面的熱升級機制。
注入熱升級容器
熱升級流程
熱升級流程主要分為三個步驟：
- Upgrade: 將 empty 容器升級為當前最新的 sidecar 容器，例如：envoy-2.Image = envoy:1.17.0
- Migration?:?lifecycle.postStart?完成熱升級流程中的狀態遷移，當遷移完成后退出
- Reset: 狀態遷移完成后，熱升級流程將設置 envoy-1 容器為 empty 鏡像，例如：envoy-1.Image = empty:1.0
上述三個步驟完成了熱升級中的全部流程，當對 Pod 執行多次熱升級時，將重復性的執行上述三個步驟。
熱升級流程
這里我們以 OpenKruise 的官方示例來進行說明，首先創建上面的?hotupgrade-sidecarset?這個 SidecarSet。然后創建一個如下所示的 CloneSet 對象：
# hotupgrade-cloneset.yaml apiVersion: apps.kruise.io/v1alpha1 kind: CloneSet metadata: name: busybox labels: app: hotupgrade spec: replicas: 1 selector: matchLabels: app: hotupgrade template: metadata: labels: app: hotupgrade spec: containers: - name: busybox image: openkruise/hotupgrade-sample:busybox
創建完成后，CloneSet 管理的 Pod 已經注入?sidecar-1??和?sidecar-2?兩個容器：
? kubectl get sidecarset hotupgrade-sidecarset NAMEMATCHED UPDATED READY AGE hotupgrade-sidecarset 1 1 0 58s ? kubectl get pods -l app=hotupgrade NAMEREADY STATUSRESTARTS AGE busybox-nd5bp 3/3 Running 031s ? kubectl describe pod busybox-nd5bp Name: busybox-nd5bp Namespace:default Node: node2/10.206.16.10 # ...... Controlled By:CloneSet/busybox Containers: sidecar-1: Container ID: containerd://511aa4b60d36483177e92805653c1b618495e47d8d5de331008259f78b3be89e Image:openkruise/hotupgrade-sample:sidecarv1 Image ID: docker.io/openkruise/hotupgrade-sample@sha256:3d677ca19712b67d2c264374736d71089d21e100eff341f6b4bb0f5288ec6f34 Environment: IS_INJECTED: true SIDECARSET_VERSION: (v1:metadata.annotations['version.sidecarset.kruise.io/sidecar-1']) SIDECARSET_VERSION_ALT: (v1:metadata.annotations['versionalt.sidecarset.kruise.io/sidecar-1']) # ...... sidecar-2: Container ID: containerd://6b0678695ccb977695248e41108606b409ad0c7e3e4fe1ba9b48e839e3c235ef Image:openkruise/hotupgrade-sample:empty Image ID: docker.io/openkruise/hotupgrade-sample@sha256:606be602967c9f91c47e4149af4336c053e26225b717a1b5453ac8fa9a401cc5 Environment: IS_INJECTED: true SIDECARSET_VERSION: (v1:metadata.annotations['version.sidecarset.kruise.io/sidecar-2']) SIDECARSET_VERSION_ALT: (v1:metadata.annotations['versionalt.sidecarset.kruise.io/sidecar-2']) # ...... busybox: Container ID: containerd://da7eebb0161bab37f7de75635e68c5284a973a21f6d3f095bb5e8212ac8ce908 Image:openkruise/hotupgrade-sample:busybox Image ID: docker.io/openkruise/hotupgrade-sample@sha256:08f9ede05850686e1200240e5e376fc76245dd2eb56299060120b8c3dba46dc9 # ...... # ...... Events: TypeReason Age From Message ---------- -------- ------- NormalScheduled50s default-schedulerSuccessfully assigned default/busybox-nd5bp to node2 NormalPulling49s kubeletPulling image "openkruise/hotupgrade-sample:sidecarv1" NormalPulled 41s kubeletSuccessfully pulled image "openkruise/hotupgrade-sample:sidecarv1" in 7.929984849s (7.929998445s including waiting) NormalCreated41s kubeletCreated container sidecar-1 NormalStarted41s kubeletStarted container sidecar-1 NormalPulling36s kubeletPulling image "openkruise/hotupgrade-sample:empty" NormalPulled 29s kubeletSuccessfully pulled image "openkruise/hotupgrade-sample:empty" in 7.434180553s (7.434189239s including waiting) NormalCreated29s kubeletCreated container sidecar-2 NormalStarted29s kubeletStarted container sidecar-2 NormalPulling29s kubeletPulling image "openkruise/hotupgrade-sample:busybox" NormalPulled 22s kubeletSuccessfully pulled image "openkruise/hotupgrade-sample:busybox" in 6.583450981s (6.583456512s including waiting) NormalCreated22s kubeletCreated container busybox NormalStarted22s kubeletStarted container busybox ......
busybox 主容器每 100 毫秒會請求一次 sidecar(versinotallow=v1)服務：
? kubectl logs -f busybox-nd5bp -c busybox I0404 09:12:26.513128 1 main.go:39] request sidecar server success, and response(body=This is version(v1) sidecar) I0404 09:12:26.623496 1 main.go:39] request sidecar server success, and response(body=This is version(v1) sidecar) I0404 09:12:26.733958 1 main.go:39] request sidecar server success, and response(body=This is version(v1) sidecar) ......
現在我們去升級 sidecar 容器，將鏡像修改為?openkruise/hotupgrade-sample:sidecarv2：
? kubectl patch sidecarset hotupgrade-sidecarset --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value": "openkruise/hotupgrade-sample:sidecarv2"}]'
更新后再去觀察 pod 的狀態，可以看到 sidecar-2 鏡像正常更新了：
? kubectl get pods -l app=hotupgrade NAMEREADY STATUSRESTARTSAGE busybox-nd5bp 3/3 Running 2 (45s ago) 23m ? kubectl describe pods busybox-nd5bp ...... Events: ...... NormalPulling33skubeletPulling image "openkruise/hotupgrade-sample:sidecarv2" NormalKilling33skubeletContainer sidecar-2 definition changed, will be restarted NormalStarted25s (x2 over 22m)kubeletStarted container sidecar-2 NormalCreated25s (x2 over 22m)kubeletCreated container sidecar-2 NormalPulled 25skubeletSuccessfully pulled image "openkruise/hotupgrade-sample:sidecarv2" in 8.169453753s (8.16946743s including waiting) NormalKilling14skubeletContainer sidecar-1 definition changed, will be restarted NormalResetContainerSucceed14ssidecarset-controllerreset sidecar container image empty successfully NormalPulling14skubeletPulling image "openkruise/hotupgrade-sample:empty" NormalCreated12s (x2 over 22m)kubeletCreated container sidecar-1 NormalStarted12s (x2 over 22m)kubeletStarted container sidecar-1 NormalPulled 12skubeletSuccessfully pulled image "openkruise/hotupgrade-sample:empty" in 1.766097364s (1.766109087s including waiting)
并且在更新過程中觀察 busybox 容器仍然會不斷請求 sidecar 服務，但是并沒有失敗的請求出現：
? kubectl logs -f busybox-nd5bp -c busybox I0306 11:08:47.587727 1 main.go:39] request sidecar server success, and response(body=This is version(v1) sidecar) I0404 09:14:28.588973 1 main.go:39] request sidecar server success, and response(body=This is version(v2) sidecar) # ......
整個熱升級示例代碼可以參考倉庫的實現：https://github.com/openkruise/samples/tree/master/hotupgrade。
Container Restart
ContainerRecreateRequest??控制器可以幫助用戶重啟/重建存量 Pod 中一個或多個容器。和 Kruise 提供的原地升級類似，當一個容器重建的時候，Pod 中的其他容器還保持正常運行，重建完成后，Pod 中除了該容器的?restartCount?增加以外不會有什么其他變化。
不過需要注意之前臨時寫到舊容器?rootfs??中的文件會丟失，但是 volume mount 掛載卷中的數據都還存在。這個功能依賴于?kruise-daemon?組件來停止 Pod 容器。
為要重建容器的 Pod 提交一個?ContainerRecreateRequest?自定義資源（縮寫 CRR）：
# crr-demo.yaml apiVersion: apps.kruise.io/v1alpha1 kind: ContainerRecreateRequest metadata: name: crr-dmo spec: podName: pod-name containers: # 要重建的容器名字列表，至少要有 1 個 - name: app - name: sidecar strategy: failurePolicy: Fail # 'Fail' 或 'Ignore'，表示一旦有某個容器停止或重建失敗， CRR 立即結束 orderedRecreate: false # 'true' 表示要等前一個容器重建完成了，再開始重建下一個 terminationGracePeriodSeconds: 30 # 等待容器優雅退出的時間，不填默認用 Pod 中定義的 unreadyGracePeriodSeconds: 3 # 在重建之前先把 Pod 設為 not ready，并等待這段時間后再開始執行重建 minStartedSeconds: 10 # 重建后新容器至少保持運行這段時間，才認為該容器重建成功 activeDeadlineSeconds: 300 # 如果 CRR 執行超過這個時間，則直接標記為結束（未結束的容器標記為失敗） ttlSecondsAfterFinished: 1800 # CRR 結束后，過了這段時間自動被刪除掉
一般來說，列表中的容器會一個個被停止，但可能同時在被重建和啟動，除非?orderedRecreate??被設置為 true。unreadyGracePeriodSeconds??功能依賴于?KruisePodReadinessGate??這個 feature-gate，后者會在每個 Pod 創建的時候注入一個?readinessGate?，否則，默認只會給 Kruise 工作負載創建的 Pod 注入 readinessGate，也就是說只有這些 Pod 才能在 CRR 重建時使用?unreadyGracePeriodSeconds。
當用戶創建了一個 CRR，Kruise webhook 會把當時容器的 containerID/restartCount 記錄到?spec.containers[x].statusContext??之中。 在 kruise-daemon 執行的過程中，如果它發現實際容器當前的?containerID??與?statusContext??不一致或?restartCount?已經變大，則認為容器已經被重建成功了（比如可能發生了一次原地升級）。
容器重啟請求
一般情況下，kruise-daemon 會執行 preStop hook 后把容器停掉，然后 kubelet 感知到容器退出，則會新建一個容器并啟動。最后 kruise-daemon 看到新容器已經啟動成功超過?minStartedSeconds?時間后，會上報這個容器的 phase 狀態為 Succeeded。
如果容器重建和原地升級操作同時觸發了：
- 如果 kubelet 根據原地升級要求已經停止或重建了容器，kruise-daemon 會判斷容器重建已經完成。
- 如果 kruise-daemon 先停了容器，Kubelet 會繼續執行原地升級，即創建一個新版本容器并啟動。
- 如果針對一個 Pod 提交了多個?ContainerRecreateRequest?資源，會按時間先后一個個執行。
ImagePullJob
NodeImage??和?ImagePullJob?是從 Kruise v0.8.0 版本開始提供的 CRD。Kruise 會自動為每個節點創建一個 NodeImage，它包含了哪些鏡像需要在這個 Node 上做預熱，比如我們這里 3 個節點，則會自動創建 3 個 NodeImage 對象：
? kubectl get nodeimage NAMEDESIRED PULLING SUCCEED FAILED AGE master1 0 0 0 05d node1 0 0 0 05d node2 0 0 0 05d
比如我們查看 node1 節點上的 NodeImage 對象：
? kubectl get nodeimage node1 -o yaml apiVersion: apps.kruise.io/v1alpha1 kind: NodeImage metadata: name: node1 # ...... spec: {} status: desired: 0 failed: 0 pulling: 0 succeeded: 0
比如我們希望在這個節點上拉去一個?ubuntu:latest?鏡像，則可以按照如下所示的去修改 spec：
...... spec: images: ubuntu:# 鏡像 name tags: - tag: latest# 鏡像 tag pullPolicy: ttlSecondsAfterFinished: 300# [required] 拉取完成（成功或失敗）超過 300s 后，將這個任務從 NodeImage 中清除 timeoutSeconds: 600 # [optional] 每一次拉取的超時時間, 默認為 600 backoffLimit: 3 # [optional] 拉取的重試次數，默認為 3 activeDeadlineSeconds: 1200 # [optional] 整個任務的超時時間，無默認值
更新后我們可以從 status 中看到拉取進度以及結果，并且你會發現拉取完成 600s 后任務會被清除。
? kubectl describe nodeimage node1 Name: node1 Namespace: # ...... Spec: Images: Ubuntu: Tags: Created At:2023-04-04T09:29:18Z Pull Policy: Active Deadline Seconds: 1200 Backoff Limit: 3 Timeout Seconds: 600 Ttl Seconds After Finished:300 Tag: latest Status: Desired:1 Failed: 0 Image Statuses: Ubuntu: Tags: Completion Time:2023-04-04T09:29:28Z Phase:Succeeded Progress: 100 Start Time: 2023-04-04T09:29:18Z Tag:latest Pulling:0 Succeeded:1 Events: TypeReasonAge From Message ------------------ ------- NormalPullImageSucceed11s kruise-daemon-imagepullerImage ubuntu:latest, ecalpsedTime 10.066193581s
我們可以在 node1 節點上查看到這個鏡像已經被拉取下來了：
ubuntu@node1:~$ sudo ctr -n k8s.io i ls|grep ubuntu docker.io/library/ubuntu:latestapplication/vnd.oci.image.index.v1+json sha256:67211c14fa74f070d27cc59d69a7fa9aeff8e28ea118ef3babc295a0428a6d21 28.2 MiBlinux/amd64,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/s390xio.cri-containerd.image=managed docker.io/library/ubuntu@sha256:67211c14fa74f070d27cc59d69a7fa9aeff8e28ea118ef3babc295a0428a6d21 application/vnd.oci.image.index.v1+json sha256:67211c14fa74f070d27cc59d69a7fa9aeff8e28ea118ef3babc295a0428a6d21 28.2 MiBlinux/amd64,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/s390xio.cri-containerd.image=managed ubuntu@node1:~$
此外用戶可以創建?ImagePullJob?對象，來指定一個鏡像要在哪些節點上做預熱。
比如創建如下所示的?ImagePullJob?資源對象：
apiVersion: apps.kruise.io/v1alpha1 kind: ImagePullJob metadata: name: job-with-always spec: image: nginx:1.9.1 # [required] 完整的鏡像名 name:tag parallelism: 10 # [optional] 最大并發拉取的節點梳理, 默認為 1 selector: # [optional] 指定節點的 名字列表 或 標簽選擇器 (只能設置其中一種) names: - node1 - node2 matchLabels: node-type: xxx # podSelector: # [optional] pod label 選擇器來在這些 pod 所在節點上拉取鏡像, 與 selector 不能同時設置. #pod-label: xxx completionPolicy: type: Always # [optional] 默認為 Always activeDeadlineSeconds: 1200 # [optional] 無默認值, 只對 Alway 類型生效 ttlSecondsAfterFinished: 300 # [optional] 無默認值, 只對 Alway 類型生效 pullPolicy: # [optional] 默認 backoffLimit=3, timeoutSecnotallow=600 backoffLimit: 3 timeoutSeconds: 300 pullSecrets: - secret-name1 - secret-name2
我們可以在?selector??字段中指定節點的名字列表或標簽選擇器 (只能設置其中一種)，如果沒有設置 selector 則會選擇所有節點做預熱。或者可以配置?podSelector?來在這些 pod 所在節點上拉取鏡像，podSelector 與 selector 不能同時設置。
同時，ImagePullJob 有兩種?completionPolicy?類型:
- Always：表示這個 job 是一次性預熱，不管成功、失敗都會結束。
- activeDeadlineSeconds：整個 job 的 deadline 結束時間。
- ttlSecondsAfterFinished：結束后超過這個時間，自動清理刪除 job。
- Never：表示這個 job 是長期運行、不會結束，并且會每天都會在匹配的節點上重新預熱一次指定的鏡像。
同樣如果你要預熱的鏡像來自私有倉庫，則可以通過?pullSecrets?來指定倉庫的 Secret 信息。
如果這個鏡像來自一個私有倉庫，則可以通過?pullSecrets?來指定倉庫的 Secret 信息。
# ... spec: pullSecrets: - secret-name1 - secret-name2
因為?ImagePullJob??是一種 namespaced-scope 資源，所以這些 Secret 必須存在?ImagePullJob?所在的 namespace 中。然后你只需要在 pullSecrets 字段中寫上這些 secret 的名字即可。
容器啟動順序
Container Launch Priority?提供了控制一個 Pod 中容器啟動順序的方法。通常來說 Pod 容器的啟動和退出順序是由 Kubelet 管理的，Kubernetes 曾經有一個 KEP 計劃在 container 中增加一個 type 字段來標識不同類型容器的啟停優先級，但是由于sig-node 考慮到對現有代碼架構的改動太大，所以將該提案拒絕了。
這個功能作用在 Pod 對象上，不管它的 owner 是什么類型的，因此可以適用于 Deployment、CloneSet 以及其他的工作負載。
比如我們可以設置按照容器順序啟動，只需要在 Pod 中定義一個?apps.kruise.io/container-launch-priority?的注解即可：
apiVersion: v1 kind: Pod annotations: apps.kruise.io/container-launch-priority: Ordered spec: containers: - name: sidecar # ... - name: main # ...
Kruise 會保證前面的容器（sidecar）會在后面容器（main）之前啟動。
此外我們還可以按自定義順序啟動，但是需要在 Pod 容器中添加?KRUISE_CONTAINER_PRIORITY?這個環境變量:
apiVersion: v1 kind: Pod spec: containers: - name: main # ... - name: sidecar env: - name: KRUISE_CONTAINER_PRIORITY value: "1" # ...
該環境變量值的范圍在?[-2147483647, 2147483647]，不寫默認是 0，權重高的容器，會保證在權重低的容器之前啟動，但是需要注意相同權重的容器不保證啟動順序。
資源分發
在對 Secret、ConfigMap 等命名空間級別資源進行跨 namespace 分發及同步的場景中，原生 Kubernetes 目前只支持用戶手動分發與同步，十分地不方便。比如：
- 當用戶需要使用 SidecarSet 的?imagePullSecrets?能力時，要先重復地在相關 namespaces 中創建對應的 Secret，并且需要確保這些 Secret 配置的正確性和一致性。
- 當用戶想要采用 ConfigMap 來配置一些通用的環境變量時，往往需要在多個 namespaces 做 ConfigMap 的下發，并且后續的修改往往也要求多 namespaces 之間保持同步。
- 在多個命名空間中的 Ingress 對象需要使用同一個 Secret 對象
面對這些需要跨命名空間進行資源分發和多次同步的場景，OpenKruise 設計了一個新的 CRD –?ResourceDistribution，可以更便捷的自動化分發和同步這些資源。
ResourceDistribution??目前支持?Secret??和?ConfigMap?兩類資源的分發和同步。
ResourceDistribution??是全局的 CRD，其主要由?resource??和?targets??兩個字段構成，其中?resource??字段用于描述用戶所要分發的資源，targets?字段用于描述用戶所要分發的目標命名空間。
apiVersion: apps.kruise.io/v1alpha1 kind: ResourceDistribution metadata: name: sample spec: resource: ... ... targets: ... ...
其中?resource?字段必須是一個完整、正確的資源描述，如下所示：
apiVersion: apps.kruise.io/v1alpha1 kind: ResourceDistribution metadata: name: sample spec: resource: apiVersion: v1 kind: ConfigMap metadata: name: game-demo data: game.properties: | enemy.types=aliens,monsters player.maximum-lives=5 player_initial_lives: "3" ui_properties_file_name: user-interface.properties user-interface.properties: | color.good=purple color.bad=yellow allow.textmode=true targets: ... ...
用戶可以先在本地某個命名空間中創建相應資源并進行測試，確認資源配置正確后再拷貝過來。
targets??字段目前支持四種規則來描述用戶所要分發的目標命名空間，包括?allNamespaces?、includedNamespaces?、namespaceLabelSelector??以及?excludedNamespaces：
- allNamespaces: bool 值，如果為 true，則分發至所有命名空間。
- includedNamespaces: 通過 Name 來匹配目標命名空間。
- namespaceLabelSelector：通過 LabelSelector 來匹配目標命名空間。
- excludedNamespaces: 通過 Name 來排除某些不想分發的命名空間。
allNamespaces?、includedNamespaces?、namespaceLabelSelector??之間是**或(OR)**的關系，而?excludedNamespaces??一旦被配置，則會顯式地排除掉這些命名空間。另外，targets??還將自動忽略?kube-system??和?kube-public?兩個命名空間。
一個配置正確的 targets 字段如下所示：
apiVersion: apps.kruise.io/v1alpha1 kind: ResourceDistribution metadata: name: sample spec: resource: ... ... targets: includedNamespaces: list: - name: ns-1 - name: ns-4 namespaceLabelSelector: matchLabels: group: test excludedNamespaces: list: - name: ns-3
該配置表示該?ResourceDistribution??的目標命名空間一定會包含?ns-1??和?ns-4?，并且 Labels 滿足?namespaceLabelSelector??的命名空間也會被包含進目標命名空間，但是，即使?ns-3??即使滿足?namespaceLabelSelector??也不會被包含，因為它已經在?excludedNamespaces?中被顯式地排除了。
如果同步的資源需要更新則可以去更新?resource??字段，更新后會自動地對所有目標命名空間中的資源進行同步更新。每一次更新資源時，ResourceDistribution??都會計算新版本資源的哈希值，并記錄到資源的 Annotations 之中，當?ResourceDistribution?發現新版本的資源與目前資源的哈希值不同時，才會對資源進行更新。
apiVersion: v1 kind: ConfigMap metadata: name: demo annotations: kruise.io/resourcedistribution.resource.from: sample kruise.io/resourcedistribution.resource.distributed.timestamp: 2021-09-06 08:44:52.7861421 +0000 UTC m=+12896.810364601 kruise.io/resourcedistribution.resource.hashcode: 0821a13321b2c76b5bd63341a0d97fb46bfdbb2f914e2ad6b613d10632fa4b63 ... ...
當然非常不建議用戶繞過?ResourceDistribution?直接對資源進行修改，除非用戶知道自己在做什么。
- 因為直接修改資源后，資源的哈希值不會被自動計算，因此，下次 resource 字段被修改后，ResourceDistribution?可能將用戶對這些資源的直接修改覆蓋掉。
- ResourceDistribution??通過?kruise.io/resourcedistribution.resource.from??來判斷資源是否由該?ResourceDistribution??分發，如果該 Annotation 被修改或刪除，則被修改的資源會被?ResourceDistribution??當成沖突資源，并且無法通過?ResourceDistribution?進行同步更新。
除了這些增強控制器之外 OpenKruise 還有很多高級的特性，可以前往官網 https://openkruise.io 了解更多信息。
