前面我們和大家已經(jīng)學(xué)習(xí)了 OpenKruise 的基本概念以及常用的幾個增強(qiáng)控制器，接下來我們來繼續(xù)了解其他高級功能。
SidecarSet
SidecarSet 支持通過 admission webhook 來自動為集群中創(chuàng)建的符合條件的 Pod 注入 sidecar 容器，除了在 Pod 創(chuàng)建時候注入外，SidecarSet 還提供了為 Pod 原地升級其中已經(jīng)注入的 sidecar 容器鏡像的能力。SidecarSet 將 sidecar 容器的定義和生命周期與業(yè)務(wù)容器解耦，它主要用于管理無狀態(tài)的 sidecar 容器，比如監(jiān)控、日志等 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: {}
直接創(chuàng)建這個資源對象即可：
? 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 的標(biāo)簽，這樣可以和上面的 SidecarSet 對象匹配：
apiVersion: v1
kind: Pod
metadata:
labels:
app: nginx # 匹配 SidecarSet 里面指定的標(biāo)簽
name: test-pod
spec:
containers:
- name: app
image: nginx:1.7.9
直接創(chuàng)建上面的資源對象：
? kubectl get pod test-pod
NAME READY STATUS RESTARTS AGE
test-pod 2/2 Running 0 22s
可以看到該 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
# ......
現(xiàn)在我們?nèi)ジ?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 STATUS RESTARTS AGE
test-pod 2/2 Running 1 (67s ago) 28m
? kubectl describe pod test-pod
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
# ......
Normal Created 10m kubelet Created container app
Normal Started 10m kubelet Started container app
Normal Killing 114s kubelet Container sidecar1 definition changed, will be restarted
Normal Pulling 84s kubelet Pulling image "busybox:1.35.0"
Normal Created 77s (x2 over 11m) kubelet Created container sidecar1
Normal Started 77s (x2 over 11m) kubelet Started container sidecar1
Normal Pulled 77s kubelet Successfully 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 了， 對主容器沒有產(chǎn)生任何影響。
基本特性
需要注意的是 sidecar 的注入只會發(fā)生在 Pod 創(chuàng)建階段，并且只有 Pod spec 會被更新，不會影響 Pod 所屬的工作負(fù)載 template 模板。 spec.containers 除了默認(rèn)的 k8s container 字段，還擴(kuò)展了如下一些字段，來方便注入：
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
name: sidecarset
spec:
selector:
matchLabels:
app: sample
containers:
# 默認(rèn)的 K8s 容器字段
- name: nginx
image: nginx:alpine
volumeMounts:
- mountPath: /nginx/conf
name: nginxconf
# 擴(kuò)展的 sidecar 容器字段
podInjectPolicy: BeforeAppContainer
shareVolumePolicy: # 數(shù)據(jù)卷共享
type: disabled | enabled
transferEnv: # 環(huán)境變量共享
- sourceContainerName: main # 會把main容器中的PROXY_IP環(huán)境變量注入到當(dāng)前定義的sidecar容器中
envName: PROXY_IP
volumes:
- Name: nginxconf
hostPath: /data/nginx/conf
- podInjectPolicy? 定義了容器 注入到 pod.spec.containers 中的位置。
- BeforeAppContainer：表示注入到 pod 原 containers 的前面(默認(rèn))。
- AfterAppContainer： 表示注入到 pod 原 containers 的后面。
- 數(shù)據(jù)卷共享。
- 共享指定卷：通過 spec.volumes 來定義 sidecar 自身需要的 volume。
- 共享所有卷：通過 spec.containers[i].shareVolumePolicy.type = enabled | disabled 來控制是否掛載 pod 應(yīng)用容器的卷，常用于日志收集等 sidecar，配置為 enabled 后會把應(yīng)用容器中所有掛載點(diǎn)注入 sidecar 同一路經(jīng)下（sidecar 中本身就有聲明的數(shù)據(jù)卷和掛載點(diǎn)除外）。
- 環(huán)境變量共享：可以通過 spec.containers[i].transferEnv 來從別的容器獲取環(huán)境變量，會把名為 sourceContainerName 容器中名為 envName 的環(huán)境變量拷貝到本容器。
SidecarSet 不僅支持 sidecar 容器的原地升級，而且提供了非常豐富的升級、灰度策略。同樣在 SidecarSet 對象中 updateStrategy? 屬性下面也可以配置 partition? 來定義保留舊版本 Pod 的數(shù)量或百分比，默認(rèn)為 0；同樣還可以配置的有 maxUnavailable 屬性，表示在發(fā)布過程中的最大不可用數(shù)量。
- 當(dāng) {matched pod}=100,partitinotallow=40,maxUnavailable=10，控制器會發(fā)布 100-40=60 個 Pod 到新版本，但是同一時間只會發(fā)布 10 個 Pod，每發(fā)布好一個 Pod 才會再找一個發(fā)布，直到 60 個發(fā)布完成。
- 當(dāng) {matched pod}=100,partitinotallow=80,maxUnavailable=30，控制器會發(fā)布 20 個 Pod 到新版本，因?yàn)闈M足 maxUnavailable 數(shù)量，所以這 20 個 Pod 會同時發(fā)布。
同樣也可以設(shè)置 paused: true 來暫停發(fā)布，此時對于新創(chuàng)建的、擴(kuò)容的 pod 依舊會實(shí)現(xiàn)注入能力，已經(jīng)更新的 pod 會保持更新后的版本不動，還沒有更新的 pod 會暫停更新。
apiVersion: apps.kruise.io/v1alpha1
kind: SidecarSet
metadata:
name: sidecarset
spec:
# ...
updateStrategy:
type: RollingUpdate
maxUnavailable: 20%
partition: 10
paused: true
金絲雀發(fā)布
對于有金絲雀發(fā)布需求的業(yè)務(wù)，可以通過 selector? 來實(shí)現(xiàn)，對于需要率先金絲雀灰度的 pod 打上固定的 [canary.release] = true? 的標(biāo)簽，再通過 selector.matchLabels 來選中該 pod 即可。
比如現(xiàn)在我們有一個 3 副本的 Pod，也具有 app=nginx 的標(biāo)簽，如下所示：
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
創(chuàng)建后現(xiàn)在就具有 4 個 app=nginx? 標(biāo)簽的 Pod 了，由于都匹配上面創(chuàng)建的 SidecarSet 對象，所以都會被注入一個 sidecar1? 的容器，鏡像為 busybox：
? kubectl get pods -l app=nginx
NAME READY STATUS RESTARTS AGE
nginx-6457955f7-7hnjw 2/2 Running 0 51s
nginx-6457955f7-prkgz 2/2 Running 0 51s
nginx-6457955f7-tbtxk 2/2 Running 0 51s
test-pod 2/2 Running 0 4m2s
現(xiàn)在如果我們想為 test-pod? 這個應(yīng)用來執(zhí)行灰度策略，將 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 這個標(biāo)簽：
apiVersion: v1
kind: Pod
metadata:
labels:
app: nginx
canary.release: "true"
name: test-pod
spec:
containers:
- name: app
image: nginx:1.7.9
更新后可以發(fā)現(xiàn) test-pod 的 sidecar 鏡像更新了，其他 Pod 沒有變化，這樣就實(shí)現(xiàn)了 sidecar 的灰度功能：
? kubectl describe pod test-pod
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Killing 7m53s kubelet Container sidecar1 definition changed, will be restarted
Normal Created 7m23s (x2 over 8m17s) kubelet Created container sidecar1
Normal Started 7m23s (x2 over 8m17s) kubelet Started container sidecar1
Normal Pulling 7m23s kubelet Pulling image "busybox"
Normal Pulled 7m23s kubelet Successfully pulled image "busybox" in 603.928658ms
熱升級
SidecarSet 原地升級會先停止舊版本的容器，然后創(chuàng)建新版本的容器，這種方式適合不影響 Pod 服務(wù)可用性的 sidecar 容器，比如說日志收集的 Agent。
但是對于很多代理或運(yùn)行時的 sidecar 容器，例如 Istio Envoy，這種升級方法就有問題了，Envoy 作為 Pod 中的一個代理容器，代理了所有的流量，如果直接重啟，Pod 服務(wù)的可用性會受到影響，如果需要單獨(dú)升級 envoy sidecar，就需要復(fù)雜的優(yōu)雅終止和協(xié)調(diào)機(jī)制，所以我們?yōu)檫@種 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?: 當(dāng)熱升級 sidecar 容器時，業(yè)務(wù)必須要提供一個 empty 容器用于熱升級過程中的容器切換，empty 容器同 sidecar 容器具有相同的配置（除了鏡像地址），例如：command?、lifecycle?、probe 等，但是它不做任何工作。
- lifecycle.postStart: 在 postStart 這個 hook 中完成熱升級過程中的狀態(tài)遷移，該腳本需要由業(yè)務(wù)根據(jù)自身的特點(diǎn)自行實(shí)現(xiàn)，例如：nginx 熱升級需要完成 Listen FD 共享以及流量排水（reload）操作。
整體來說熱升級特性總共包含以下兩個過程：
- Pod 創(chuàng)建時，注入熱升級容器。
- 原地升級時，完成熱升級流程。
注入熱升級容器
Pod 創(chuàng)建時，SidecarSet Webhook 將會注入兩個容器：
- {sidecarContainer.name}-1?: 如下圖所示 envoy-1?，這個容器代表正在實(shí)際工作的 sidecar 容器，例如：envoy:1.16.0。
- {sidecarContainer.name}-2?: 如下圖所示 envoy-2?，這個容器是業(yè)務(wù)配置的 hotUpgradeEmptyImage? 容器，例如：empty:1.0，用于后面的熱升級機(jī)制。
注入熱升級容器
熱升級流程
熱升級流程主要分為三個步驟：
- Upgrade: 將 empty 容器升級為當(dāng)前最新的 sidecar 容器，例如：envoy-2.Image = envoy:1.17.0
- Migration?: lifecycle.postStart 完成熱升級流程中的狀態(tài)遷移，當(dāng)遷移完成后退出
- Reset: 狀態(tài)遷移完成后，熱升級流程將設(shè)置 envoy-1 容器為 empty 鏡像，例如：envoy-1.Image = empty:1.0
上述三個步驟完成了熱升級中的全部流程，當(dāng)對 Pod 執(zhí)行多次熱升級時，將重復(fù)性的執(zhí)行上述三個步驟。
熱升級流程
這里我們以 OpenKruise 的官方示例來進(jìn)行說明，首先創(chuàng)建上面的 hotupgrade-sidecarset 這個 SidecarSet。然后創(chuàng)建一個如下所示的 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
創(chuàng)建完成后，CloneSet 管理的 Pod 已經(jīng)注入 sidecar-1? 和 sidecar-2 兩個容器：
? kubectl get sidecarset hotupgrade-sidecarset
NAME MATCHED UPDATED READY AGE
hotupgrade-sidecarset 1 1 0 58s
? kubectl get pods -l app=hotupgrade
NAME READY STATUS RESTARTS AGE
busybox-nd5bp 3/3 Running 0 31s
? 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:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 50s default-scheduler Successfully assigned default/busybox-nd5bp to node2
Normal Pulling 49s kubelet Pulling image "openkruise/hotupgrade-sample:sidecarv1"
Normal Pulled 41s kubelet Successfully pulled image "openkruise/hotupgrade-sample:sidecarv1" in 7.929984849s (7.929998445s including waiting)
Normal Created 41s kubelet Created container sidecar-1
Normal Started 41s kubelet Started container sidecar-1
Normal Pulling 36s kubelet Pulling image "openkruise/hotupgrade-sample:empty"
Normal Pulled 29s kubelet Successfully pulled image "openkruise/hotupgrade-sample:empty" in 7.434180553s (7.434189239s including waiting)
Normal Created 29s kubelet Created container sidecar-2
Normal Started 29s kubelet Started container sidecar-2
Normal Pulling 29s kubelet Pulling image "openkruise/hotupgrade-sample:busybox"
Normal Pulled 22s kubelet Successfully pulled image "openkruise/hotupgrade-sample:busybox" in 6.583450981s (6.583456512s including waiting)
Normal Created 22s kubelet Created container busybox
Normal Started 22s kubelet Started container busybox
......
busybox 主容器每 100 毫秒會請求一次 sidecar(versinotallow=v1)服務(wù)：
? 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)
......
現(xiàn)在我們?nèi)ド?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 的狀態(tài)，可以看到 sidecar-2 鏡像正常更新了：
? kubectl get pods -l app=hotupgrade
NAME READY STATUS RESTARTS AGE
busybox-nd5bp 3/3 Running 2 (45s ago) 23m
? kubectl describe pods busybox-nd5bp
......
Events:
......
Normal Pulling 33s kubelet Pulling image "openkruise/hotupgrade-sample:sidecarv2"
Normal Killing 33s kubelet Container sidecar-2 definition changed, will be restarted
Normal Started 25s (x2 over 22m) kubelet Started container sidecar-2
Normal Created 25s (x2 over 22m) kubelet Created container sidecar-2
Normal Pulled 25s kubelet Successfully pulled image "openkruise/hotupgrade-sample:sidecarv2" in 8.169453753s (8.16946743s including waiting)
Normal Killing 14s kubelet Container sidecar-1 definition changed, will be restarted
Normal ResetContainerSucceed 14s sidecarset-controller reset sidecar container image empty successfully
Normal Pulling 14s kubelet Pulling image "openkruise/hotupgrade-sample:empty"
Normal Created 12s (x2 over 22m) kubelet Created container sidecar-1
Normal Started 12s (x2 over 22m) kubelet Started container sidecar-1
Normal Pulled 12s kubelet Successfully pulled image "openkruise/hotupgrade-sample:empty" in 1.766097364s (1.766109087s including waiting)
并且在更新過程中觀察 busybox 容器仍然會不斷請求 sidecar 服務(wù)，但是并沒有失敗的請求出現(xiàn)：
? 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)
# ......
整個熱升級示例代碼可以參考倉庫的實(shí)現(xiàn)：https://github.com/openkruise/samples/tree/master/hotupgrade。
Container Restart
ContainerRecreateRequest? 控制器可以幫助用戶重啟/重建存量 Pod 中一個或多個容器。和 Kruise 提供的原地升級類似，當(dāng)一個容器重建的時候，Pod 中的其他容器還保持正常運(yùn)行，重建完成后，Pod 中除了該容器的 restartCount 增加以外不會有什么其他變化。
不過需要注意之前臨時寫到舊容器 rootfs? 中的文件會丟失，但是 volume mount 掛載卷中的數(shù)據(jù)都還存在。這個功能依賴于 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 立即結(jié)束
orderedRecreate: false # 'true' 表示要等前一個容器重建完成了，再開始重建下一個
terminationGracePeriodSeconds: 30 # 等待容器優(yōu)雅退出的時間，不填默認(rèn)用 Pod 中定義的
unreadyGracePeriodSeconds: 3 # 在重建之前先把 Pod 設(shè)為 not ready，并等待這段時間后再開始執(zhí)行重建
minStartedSeconds: 10 # 重建后新容器至少保持運(yùn)行這段時間，才認(rèn)為該容器重建成功
activeDeadlineSeconds: 300 # 如果 CRR 執(zhí)行超過這個時間，則直接標(biāo)記為結(jié)束（未結(jié)束的容器標(biāo)記為失?。?br> ttlSecondsAfterFinished: 1800 # CRR 結(jié)束后，過了這段時間自動被刪除掉
一般來說，列表中的容器會一個個被停止，但可能同時在被重建和啟動，除非 orderedRecreate? 被設(shè)置為 true。unreadyGracePeriodSeconds? 功能依賴于 KruisePodReadinessGate? 這個 feature-gate，后者會在每個 Pod 創(chuàng)建的時候注入一個 readinessGate?，否則，默認(rèn)只會給 Kruise 工作負(fù)載創(chuàng)建的 Pod 注入 readinessGate，也就是說只有這些 Pod 才能在 CRR 重建時使用 unreadyGracePeriodSeconds。
當(dāng)用戶創(chuàng)建了一個 CRR，Kruise webhook 會把當(dāng)時容器的 containerID/restartCount 記錄到 spec.containers[x].statusContext? 之中。 在 kruise-daemon 執(zhí)行的過程中，如果它發(fā)現(xiàn)實(shí)際容器當(dāng)前的 containerID? 與 statusContext? 不一致或 restartCount 已經(jīng)變大，則認(rèn)為容器已經(jīng)被重建成功了（比如可能發(fā)生了一次原地升級）。
容器重啟請求
一般情況下，kruise-daemon 會執(zhí)行 preStop hook 后把容器停掉，然后 kubelet 感知到容器退出，則會新建一個容器并啟動。最后 kruise-daemon 看到新容器已經(jīng)啟動成功超過 minStartedSeconds 時間后，會上報這個容器的 phase 狀態(tài)為 Succeeded。
如果容器重建和原地升級操作同時觸發(fā)了：
- 如果 kubelet 根據(jù)原地升級要求已經(jīng)停止或重建了容器，kruise-daemon 會判斷容器重建已經(jīng)完成。
- 如果 kruise-daemon 先停了容器，Kubelet 會繼續(xù)執(zhí)行原地升級，即創(chuàng)建一個新版本容器并啟動。
- 如果針對一個 Pod 提交了多個 ContainerRecreateRequest 資源，會按時間先后一個個執(zhí)行。
ImagePullJob
NodeImage? 和 ImagePullJob 是從 Kruise v0.8.0 版本開始提供的 CRD。Kruise 會自動為每個節(jié)點(diǎn)創(chuàng)建一個 NodeImage，它包含了哪些鏡像需要在這個 Node 上做預(yù)熱，比如我們這里 3 個節(jié)點(diǎn)，則會自動創(chuàng)建 3 個 NodeImage 對象：
? kubectl get nodeimage
NAME DESIRED PULLING SUCCEED FAILED AGE
master1 0 0 0 0 5d
node1 0 0 0 0 5d
node2 0 0 0 0 5d
比如我們查看 node1 節(jié)點(diǎn)上的 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
比如我們希望在這個節(jié)點(diǎn)上拉去一個 ubuntu:latest 鏡像，則可以按照如下所示的去修改 spec：
......
spec:
images:
ubuntu: # 鏡像 name
tags:
- tag: latest # 鏡像 tag
pullPolicy:
ttlSecondsAfterFinished: 300 # [required] 拉取完成（成功或失?。┏^ 300s 后，將這個任務(wù)從 NodeImage 中清除
timeoutSeconds: 600 # [optional] 每一次拉取的超時時間, 默認(rèn)為 600
backoffLimit: 3 # [optional] 拉取的重試次數(shù)，默認(rèn)為 3
activeDeadlineSeconds: 1200 # [optional] 整個任務(wù)的超時時間，無默認(rèn)值
更新后我們可以從 status 中看到拉取進(jìn)度以及結(jié)果，并且你會發(fā)現(xiàn)拉取完成 600s 后任務(wù)會被清除。
? 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:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal PullImageSucceed 11s kruise-daemon-imagepuller Image ubuntu:latest, ecalpsedTime 10.066193581s
我們可以在 node1 節(jié)點(diǎn)上查看到這個鏡像已經(jīng)被拉取下來了：
ubuntu@node1:~$ sudo ctr -n k8s.io i ls |grep ubuntu
docker.io/library/ubuntu:latest application/vnd.oci.image.index.v1+json sha256:67211c14fa74f070d27cc59d69a7fa9aeff8e28ea118ef3babc295a0428a6d21 28.2 MiB linux/amd64,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/s390x io.cri-containerd.image=managed
docker.io/library/ubuntu@sha256:67211c14fa74f070d27cc59d69a7fa9aeff8e28ea118ef3babc295a0428a6d21 application/vnd.oci.image.index.v1+json sha256:67211c14fa74f070d27cc59d69a7fa9aeff8e28ea118ef3babc295a0428a6d21 28.2 MiB linux/amd64,linux/arm/v7,linux/arm64/v8,linux/ppc64le,linux/s390x io.cri-containerd.image=managed
ubuntu@node1:~$
此外用戶可以創(chuàng)建 ImagePullJob 對象，來指定一個鏡像要在哪些節(jié)點(diǎn)上做預(yù)熱。
比如創(chuàng)建如下所示的 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] 最大并發(fā)拉取的節(jié)點(diǎn)梳理, 默認(rèn)為 1
selector: # [optional] 指定節(jié)點(diǎn)的 名字列表 或 標(biāo)簽選擇器 (只能設(shè)置其中一種)
names:
- node1
- node2
matchLabels:
node-type: xxx
# podSelector: # [optional] pod label 選擇器來在這些 pod 所在節(jié)點(diǎn)上拉取鏡像, 與 selector 不能同時設(shè)置.
# pod-label: xxx
completionPolicy:
type: Always # [optional] 默認(rèn)為 Always
activeDeadlineSeconds: 1200 # [optional] 無默認(rèn)值, 只對 Alway 類型生效
ttlSecondsAfterFinished: 300 # [optional] 無默認(rèn)值, 只對 Alway 類型生效
pullPolicy: # [optional] 默認(rèn) backoffLimit=3, timeoutSecnotallow=600
backoffLimit: 3
timeoutSeconds: 300
pullSecrets:
- secret-name1
- secret-name2
我們可以在 selector? 字段中指定節(jié)點(diǎn)的名字列表或標(biāo)簽選擇器 (只能設(shè)置其中一種)，如果沒有設(shè)置 selector 則會選擇所有節(jié)點(diǎn)做預(yù)熱?；蛘呖梢耘渲?nbsp;podSelector 來在這些 pod 所在節(jié)點(diǎn)上拉取鏡像，podSelector 與 selector 不能同時設(shè)置。
同時，ImagePullJob 有兩種 completionPolicy 類型:
- Always：表示這個 job 是一次性預(yù)熱，不管成功、失敗都會結(jié)束。
- activeDeadlineSeconds：整個 job 的 deadline 結(jié)束時間。
- ttlSecondsAfterFinished：結(jié)束后超過這個時間，自動清理刪除 job。
- Never：表示這個 job 是長期運(yùn)行、不會結(jié)束，并且會每天都會在匹配的節(jié)點(diǎn)上重新預(yù)熱一次指定的鏡像。
同樣如果你要預(yù)熱的鏡像來自私有倉庫，則可以通過 pullSecrets 來指定倉庫的 Secret 信息。
如果這個鏡像來自一個私有倉庫，則可以通過 pullSecrets 來指定倉庫的 Secret 信息。
# ...
spec:
pullSecrets:
- secret-name1
- secret-name2
因?yàn)?nbsp;ImagePullJob? 是一種 namespaced-scope 資源，所以這些 Secret 必須存在 ImagePullJob 所在的 namespace 中。然后你只需要在 pullSecrets 字段中寫上這些 secret 的名字即可。
容器啟動順序
Container Launch Priority 提供了控制一個 Pod 中容器啟動順序的方法。通常來說 Pod 容器的啟動和退出順序是由 Kubelet 管理的，Kubernetes 曾經(jīng)有一個 KEP 計劃在 container 中增加一個 type 字段來標(biāo)識不同類型容器的啟停優(yōu)先級，但是由于sig-node 考慮到對現(xiàn)有代碼架構(gòu)的改動太大，所以將該提案拒絕了。
這個功能作用在 Pod 對象上，不管它的 owner 是什么類型的，因此可以適用于 Deployment、CloneSet 以及其他的工作負(fù)載。
比如我們可以設(shè)置按照容器順序啟動，只需要在 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 這個環(huán)境變量:
apiVersion: v1
kind: Pod
spec:
containers:
- name: main
# ...
- name: sidecar
env:
- name: KRUISE_CONTAINER_PRIORITY
value: "1"
# ...
該環(huán)境變量值的范圍在 [-2147483647, 2147483647]，不寫默認(rèn)是 0，權(quán)重高的容器，會保證在權(quán)重低的容器之前啟動，但是需要注意相同權(quán)重的容器不保證啟動順序。
資源分發(fā)
在對 Secret、ConfigMap 等命名空間級別資源進(jìn)行跨 namespace 分發(fā)及同步的場景中，原生 Kubernetes 目前只支持用戶手動分發(fā)與同步，十分地不方便。比如：
- 當(dāng)用戶需要使用 SidecarSet 的 imagePullSecrets 能力時，要先重復(fù)地在相關(guān) namespaces 中創(chuàng)建對應(yīng)的 Secret，并且需要確保這些 Secret 配置的正確性和一致性。
- 當(dāng)用戶想要采用 ConfigMap 來配置一些通用的環(huán)境變量時，往往需要在多個 namespaces 做 ConfigMap 的下發(fā)，并且后續(xù)的修改往往也要求多 namespaces 之間保持同步。
- 在多個命名空間中的 Ingress 對象需要使用同一個 Secret 對象
面對這些需要跨命名空間進(jìn)行資源分發(fā)和多次同步的場景，OpenKruise 設(shè)計了一個新的 CRD - ResourceDistribution，可以更便捷的自動化分發(fā)和同步這些資源。
ResourceDistribution? 目前支持 Secret? 和 ConfigMap 兩類資源的分發(fā)和同步。
ResourceDistribution? 是全局的 CRD，其主要由 resource? 和 targets? 兩個字段構(gòu)成，其中 resource? 字段用于描述用戶所要分發(fā)的資源，targets 字段用于描述用戶所要分發(fā)的目標(biāo)命名空間。
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: ... ...
用戶可以先在本地某個命名空間中創(chuàng)建相應(yīng)資源并進(jìn)行測試，確認(rèn)資源配置正確后再拷貝過來。
targets? 字段目前支持四種規(guī)則來描述用戶所要分發(fā)的目標(biāo)命名空間，包括 allNamespaces?、includedNamespaces?、namespaceLabelSelector? 以及 excludedNamespaces：
- allNamespaces: bool 值，如果為 true，則分發(fā)至所有命名空間。
- includedNamespaces: 通過 Name 來匹配目標(biāo)命名空間。
- namespaceLabelSelector：通過 LabelSelector 來匹配目標(biāo)命名空間。
- excludedNamespaces: 通過 Name 來排除某些不想分發(fā)的命名空間。
allNamespaces?、includedNamespaces?、namespaceLabelSelector? 之間是**或(OR)**的關(guān)系，而 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? 的目標(biāo)命名空間一定會包含 ns-1? 和 ns-4?，并且 Labels 滿足 namespaceLabelSelector? 的命名空間也會被包含進(jìn)目標(biāo)命名空間，但是，即使 ns-3? 即使?jié)M足 namespaceLabelSelector? 也不會被包含，因?yàn)樗呀?jīng)在 excludedNamespaces 中被顯式地排除了。
如果同步的資源需要更新則可以去更新 resource? 字段，更新后會自動地對所有目標(biāo)命名空間中的資源進(jìn)行同步更新。每一次更新資源時，ResourceDistribution? 都會計算新版本資源的哈希值，并記錄到資源的 Annotations 之中，當(dāng) ResourceDistribution 發(fā)現(xiàn)新版本的資源與目前資源的哈希值不同時，才會對資源進(jìn)行更新。
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
... ...
當(dāng)然非常不建議用戶繞過 ResourceDistribution 直接對資源進(jìn)行修改，除非用戶知道自己在做什么。
- 因?yàn)橹苯有薷馁Y源后，資源的哈希值不會被自動計算，因此，下次 resource 字段被修改后，ResourceDistribution 可能將用戶對這些資源的直接修改覆蓋掉。
- ResourceDistribution? 通過 kruise.io/resourcedistribution.resource.from? 來判斷資源是否由該 ResourceDistribution? 分發(fā)，如果該 Annotation 被修改或刪除，則被修改的資源會被 ResourceDistribution? 當(dāng)成沖突資源，并且無法通過 ResourceDistribution 進(jìn)行同步更新。
除了這些增強(qiáng)控制器之外 OpenKruise 還有很多高級的特性，可以前往官網(wǎng) https://openkruise.io 了解更多信息。
