容器鏡像可以被視為是一個(gè)封裝了應(yīng)用程序和其所需軟件依賴的可執(zhí)行軟件包。它是一個(gè)獨(dú)立運(yùn)行的軟件包，可以放置在任何支持容器技術(shù)的環(huán)境中。容器鏡像對(duì)于其運(yùn)行時(shí)環(huán)境有明確的要求和假設(shè)。

通常情況下會(huì)創(chuàng)建應(yīng)用程序的容器鏡像，并將其存儲(chǔ)在一個(gè)倉(cāng)庫(kù)中（稱為Registry）。然后可以在Kubernetes中的Pod中引用這個(gè)容器鏡像。如果需要獲取特定版本的Kubernetes容器鏡像，比如最新的次要版本v1.28，可以訪問(wèn)Kubernetes官方網(wǎng)站下載相應(yīng)的鏡像。容器鏡像就是一個(gè)打包了應(yīng)用程序和它所需的所有軟件依賴的可執(zhí)行軟件包。它能夠獨(dú)立運(yùn)行，并且具備在特定環(huán)境中運(yùn)行的預(yù)設(shè)條件?？梢栽贙ubernetes中使用容器鏡像來(lái)部署應(yīng)用程序。

一、鏡像名稱

容器鏡像通常會(huì)被賦予 pause、example/mycontainer 或者 kube-apiserver 這類的名稱， 鏡像名稱也可以包含所在倉(cāng)庫(kù)的主機(jī)名， 還可以包含倉(cāng)庫(kù)的端口號(hào)。如果不指定倉(cāng)庫(kù)的主機(jī)名，Kubernetes 認(rèn)為使用的Docker 公共倉(cāng)庫(kù)。

在鏡像名稱之后，可以添加一個(gè)標(biāo)簽（Tag）（與使用 docker 或 podman 等命令時(shí)的方式相同）。 使用標(biāo)簽?zāi)鼙孀R(shí)同一鏡像序列中的不同版本。鏡像標(biāo)簽可以包含小寫字母、大寫字母、數(shù)字、下劃線（_）、句點(diǎn)（.）和連字符（-）。 關(guān)于在鏡像標(biāo)簽中何處可以使用分隔字符（_、- 和 .）還有一些額外的規(guī)則。 如果不指定標(biāo)簽，Kubernetes 會(huì)認(rèn)為想使用標(biāo)簽 latest。

二、更新鏡像

當(dāng)最初創(chuàng)建一個(gè) Deployment、 StatefulSet、Pod 或者其他包含 Pod 模板的對(duì)象時(shí)，如果沒(méi)有顯式設(shè)定的話， Pod 中所有容器的默認(rèn)鏡像拉取策略是 IfNotPresent，會(huì)使kubelet 在鏡像已經(jīng)存在的情況下直接略過(guò)拉取鏡像的操作。

1、鏡像拉取策略

容器的 imagePullPolicy 和鏡像的標(biāo)簽會(huì)影響 kubelet 嘗試?yán)。ㄏ螺d）指定的鏡像。以下列表包含了 imagePullPolicy 可以設(shè)置的值，以及這些值的效果：

• IfNotPresent：只有當(dāng)鏡像在本地不存在時(shí)才會(huì)拉取；
• Always：每當(dāng) kubelet 啟動(dòng)一個(gè)容器時(shí)，kubelet 會(huì)查詢?nèi)萜鞯溺R像倉(cāng)庫(kù)， 將名稱解析為一個(gè)鏡像摘要。 如果 kubelet 有一個(gè)容器鏡像，并且對(duì)應(yīng)的摘要已在本地緩存，kubelet 就會(huì)使用其緩存的鏡像； 否則，kubelet 就會(huì)使用解析后的摘要拉取鏡像，并使用該鏡像來(lái)啟動(dòng)容器；
• Never：Kubelet 不會(huì)嘗試獲取鏡像。如果鏡像已經(jīng)以某種方式存在本地， kubelet 會(huì)嘗試啟動(dòng)容器；否則，會(huì)啟動(dòng)失敗。 更多細(xì)節(jié)見(jiàn)提前拉取鏡像。

只要能夠可靠地訪問(wèn)鏡像倉(cāng)庫(kù)，底層鏡像提供者的緩存語(yǔ)義甚至可以使 imagePullPolicy: Always 高效。 容器運(yùn)行時(shí)可以注意到節(jié)點(diǎn)上已經(jīng)存在的鏡像層，這樣就不需要再次下載。

注意：在生產(chǎn)環(huán)境中部署容器時(shí)，應(yīng)該避免使用 :latest 標(biāo)簽，因?yàn)檫@使得正在運(yùn)行的鏡像的版本難以追蹤，并且難以正確地回滾。相反，應(yīng)指定一個(gè)有意義的標(biāo)簽，如 v1.42.0，和/或者一個(gè)摘要。

為了確保 Pod 總是使用相同版本的容器鏡像，可以指定鏡像的摘要； 將 <image-name>:<tag> 替換為 <image-name>@<digest>，例如 image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2。當(dāng)使用鏡像標(biāo)簽時(shí)，如果鏡像倉(cāng)庫(kù)修改了代碼所對(duì)應(yīng)的鏡像標(biāo)簽，可能會(huì)出現(xiàn)新舊代碼混雜在 Pod 中運(yùn)行的情況。 鏡像摘要唯一標(biāo)識(shí)了鏡像的特定版本，因此 Kubernetes 每次啟動(dòng)具有指定鏡像名稱和摘要的容器時(shí)，都會(huì)運(yùn)行相同的代碼。 通過(guò)摘要指定鏡像可固定運(yùn)行的代碼，這樣鏡像倉(cāng)庫(kù)的變化就不會(huì)導(dǎo)致版本的混雜。有一些第三方的準(zhǔn)入控制器 在創(chuàng)建 Pod（和 Pod 模板）時(shí)產(chǎn)生變更，這樣運(yùn)行的工作負(fù)載就是根據(jù)鏡像摘要，而不是標(biāo)簽來(lái)定義的。 總之，無(wú)論鏡像倉(cāng)庫(kù)上的標(biāo)簽發(fā)生什么變化，都想確保所有的工作負(fù)載都運(yùn)行相同的代碼，那么指定鏡像摘要會(huì)很有用。

2、默認(rèn)鏡像拉取策略

當(dāng)（或控制器）向 API 服務(wù)器提交一個(gè)新的 Pod 時(shí)，集群會(huì)在滿足特定條件時(shí)設(shè)置 imagePullPolicy 字段：

• 如果省略了 imagePullPolicy 字段，并且為容器鏡像指定了摘要， 那么 imagePullPolicy 會(huì)自動(dòng)設(shè)置為 IfNotPresent；
• 如果省略了 imagePullPolicy 字段，并且容器鏡像的標(biāo)簽是 :latest， imagePullPolicy 會(huì)自動(dòng)設(shè)置為 Always；
• 如果省略了 imagePullPolicy 字段，并且沒(méi)有指定容器鏡像的標(biāo)簽， imagePullPolicy 會(huì)自動(dòng)設(shè)置為 Always；
• 如果省略了 imagePullPolicy 字段，并且為容器鏡像指定了非 :latest 的標(biāo)簽， imagePullPolicy 就會(huì)自動(dòng)設(shè)置為 IfNotPresent。

注意：容器的 imagePullPolicy 的值總是在對(duì)象初次創(chuàng)建時(shí)設(shè)置的， 如果后來(lái)鏡像的標(biāo)簽或摘要發(fā)生變化，則不會(huì)更新。例如，如果用一個(gè) 非 :latest 的鏡像標(biāo)簽創(chuàng)建一個(gè) Deployment， 并在隨后更新該 Deployment 的鏡像標(biāo)簽為 :latest，則 imagePullPolicy 字段 不會(huì) 變成 Always，因此必須手動(dòng)更改已經(jīng)創(chuàng)建的資源的拉取策略。

3、必要鏡像拉取

如果想總是強(qiáng)制執(zhí)行拉取，可以使用下述的一中方式：

• 設(shè)置容器的 imagePullPolicy 為 Always；
• 省略 imagePullPolicy，并使用 :latest 作為鏡像標(biāo)簽； 當(dāng)提交 Pod 時(shí)，Kubernetes 會(huì)將策略設(shè)置為 Always；
• 省略 imagePullPolicy 和鏡像的標(biāo)簽； 當(dāng)提交 Pod 時(shí)，Kubernetes 會(huì)將策略設(shè)置為 Always；
• 啟用準(zhǔn)入控制器 AlwaysPullImages。

4、ImagePullBackOff

在使用容器運(yùn)行時(shí)創(chuàng)建Pod時(shí)，有時(shí)候容器的狀態(tài)可能會(huì)顯示為”Waiting”且出現(xiàn)”ImagePullBackOff”錯(cuò)誤。當(dāng)容器出現(xiàn)”ImagePullBackOff”狀態(tài)時(shí)，意味著Kubernetes無(wú)法成功獲取容器鏡像，導(dǎo)致無(wú)法啟動(dòng)容器。這可能是由于鏡像名稱無(wú)效或由于沒(méi)有正確配置私有倉(cāng)庫(kù)的imagePullSecret。

在出現(xiàn)”ImagePullBackOff”狀態(tài)后，Kubernetes會(huì)嘗試?yán)^續(xù)拉取鏡像，并在每次嘗試之間增加一定的延遲時(shí)間（即回退延遲）。Kubernetes會(huì)逐漸增加延遲時(shí)間，直到達(dá)到最大限制，也就是300秒（即5分鐘）的編譯限制。

簡(jiǎn)而言之，當(dāng)kubelet在創(chuàng)建Pod時(shí)發(fā)現(xiàn)無(wú)法拉取容器鏡像時(shí)，容器的狀態(tài)會(huì)顯示為”Waiting”和”ImagePullBackOff”。Kubernetes會(huì)持續(xù)嘗試?yán)＄R像，并根據(jù)設(shè)定的回退延遲進(jìn)行重試，直到達(dá)到最大限制。這通常是由于鏡像名稱無(wú)效或缺少正確的私有倉(cāng)庫(kù)認(rèn)證信息所引起的問(wèn)題。

三、串行和并行鏡像拉取

默認(rèn)情況下，kubelet會(huì)以串行方式拉取鏡像，也就是說(shuō)，在處理一個(gè)鏡像拉取請(qǐng)求時(shí)，kubelet不會(huì)同時(shí)發(fā)送其他鏡像拉取請(qǐng)求，而是等待當(dāng)前請(qǐng)求完成后再發(fā)送下一個(gè)請(qǐng)求。每個(gè)節(jié)點(diǎn)獨(dú)立地決定鏡像的拉取操作。即使使用串行的鏡像拉取方式，兩個(gè)不同的節(jié)點(diǎn)仍然可以并行地拉取相同的鏡像。

如果想啟用并行鏡像拉取，可以在kubelet的配置中將serializeImagePulls字段設(shè)置為false。當(dāng)serializeImagePulls被設(shè)置為false時(shí)，kubelet會(huì)立即向鏡像服務(wù)發(fā)送鏡像拉取請(qǐng)求，從而可以同時(shí)拉取多個(gè)鏡像。但在啟用并行鏡像拉取時(shí)，請(qǐng)確保容器運(yùn)行時(shí)的鏡像服務(wù)能夠處理并行的鏡像拉取請(qǐng)求。

kubelet不會(huì)并行地拉取同一個(gè)Pod中的多個(gè)容器的鏡像。例如，如果一個(gè)Pod有一個(gè)初始容器和一個(gè)應(yīng)用容器，那么這兩個(gè)容器的鏡像拉取將不會(huì)并行進(jìn)行。然而，如果有兩個(gè)使用不同鏡像的Pod，并且啟用了并行鏡像拉取，kubelet將代表這兩個(gè)不同的Pod并行地拉取鏡像。

最大并行鏡像拉取數(shù)量：

特性狀態(tài)： Kubernetes v1.27 [alpha]

當(dāng)serializeImagePulls被設(shè)置為false時(shí)，kubelet默認(rèn)沒(méi)有限制同時(shí)拉取的最大鏡像數(shù)量。如果想要限制并行鏡像拉取的數(shù)量，可以在kubelet的配置中設(shè)置maxParallelImagePulls字段。當(dāng)maxParallelImagePulls被設(shè)置為n時(shí)，只能同時(shí)拉取n個(gè)鏡像，超過(guò)n的任何鏡像都必須等到至少一個(gè)正在進(jìn)行拉取的鏡像拉取完成后，才能拉取。通過(guò)限制并行鏡像拉取的數(shù)量，可以防止鏡像拉取消耗過(guò)多的網(wǎng)絡(luò)帶寬或磁盤I/O。

注意：maxParallelImagePulls必須設(shè)置為大于或等于1的正整數(shù)。如果將maxParallelImagePulls設(shè)置為大于等于2，則必須將serializeImagePulls設(shè)置為false。在無(wú)效的maxParallelImagePulls設(shè)置下，kubelet將會(huì)啟動(dòng)失敗。

四、索引多架構(gòu)鏡像

除了提供二進(jìn)制的鏡像之外， 容器倉(cāng)庫(kù)也可以提供容器鏡像索引。 鏡像索引可以指向鏡像的多個(gè)鏡像清單， 提供特定于體系結(jié)構(gòu)版本的容器。 這背后的理念是讓可以為鏡像命名（例如：pause、example/mycontainer、kube-apiserver） 的同時(shí)，允許不同的系統(tǒng)基于它們所使用的機(jī)器體系結(jié)構(gòu)取回正確的二進(jìn)制鏡像。

Kubernetes 自身通常在命名容器鏡像時(shí)添加后綴 -$(ARCH)。 為了向前兼容，請(qǐng)?jiān)谏奢^老的鏡像時(shí)也提供后綴。 這里的理念是為某鏡像（如 pause）生成針對(duì)所有平臺(tái)都適用的清單時(shí)， 生成 pause-amd64 這類鏡像，以便較老的配置文件或者將鏡像后綴硬編碼到其中的 YAML 文件也能兼容。

五、使用私有倉(cāng)庫(kù)

從私有倉(cāng)庫(kù)讀取鏡像時(shí)可能需要密鑰。 憑據(jù)可以用以下方式提供:

• 配置節(jié)點(diǎn)向私有倉(cāng)庫(kù)進(jìn)行身份驗(yàn)證：所有 Pod 均可讀取任何已配置的私有倉(cāng)庫(kù)；需要集群管理員配置節(jié)點(diǎn)；

• kubelet 憑據(jù)提供程序，動(dòng)態(tài)獲取私有倉(cāng)庫(kù)的憑據(jù)：kubelet 可以被配置為使用憑據(jù)提供程序 exec 插件來(lái)訪問(wèn)對(duì)應(yīng)的私有鏡像庫(kù)；

• 預(yù)拉鏡像：所有 Pod 都可以使用節(jié)點(diǎn)上緩存的所有鏡像；需要所有節(jié)點(diǎn)的 root 訪問(wèn)權(quán)限才能進(jìn)行設(shè)置；

• 在 Pod 中設(shè)置 ImagePullSecrets：只有提供自己密鑰的 Pod 才能訪問(wèn)私有倉(cāng)庫(kù)；

• 特定于廠商的擴(kuò)展或者本地?cái)U(kuò)展：如果在使用定制的節(jié)點(diǎn)配置，（或者云平臺(tái)提供商）可以實(shí)現(xiàn)讓節(jié)點(diǎn)向容器倉(cāng)庫(kù)認(rèn)證的機(jī)制。

下面將詳細(xì)描述每一項(xiàng)。

1、config.json說(shuō)明

對(duì)于 config.json 的解釋在原始 Docker 實(shí)現(xiàn)和 Kubernetes 的解釋之間有所不同。 在 Docker 中，auths 鍵只能指定根 URL，而 Kubernetes 允許 glob URLs 以及前綴匹配的路徑。 這意味著，像這樣的 config.json 是有效的：

{
"auths": {
"*my-registry.io/images": {
"auth": "…"
}
}
}

使用以下語(yǔ)法匹配根 URL （*my-registry.io）：

pattern:
{ term }
term:
'*' 匹配任何無(wú)分隔符字符序列
'?' 匹配任意單個(gè)非分隔符
'[' [ '^' ] 字符范圍
字符集（必須非空）
c 匹配字符 c （c 不為 '*', '?', '\\', '['）
'\\' c 匹配字符 c
字符范圍:
c 匹配字符 c （c 不為 '\\', '?', '-', ']'）
'\\' c 匹配字符 c
lo '-' hi 匹配字符范圍在 lo 到 hi 之間字符

現(xiàn)在鏡像拉取操作會(huì)將每種有效模式的憑據(jù)都傳遞給 CRI 容器運(yùn)行時(shí)。例如下面的容器鏡像名稱會(huì)匹配成功：

my-registry.io/images
my-registry.io/images/my-image
my-registry.io/images/another-image
sub.my-registry.io/images/my-image
a.sub.my-registry.io/images/my-image

kubelet 為每個(gè)找到的憑據(jù)的鏡像按順序拉取。這意味著在 config.json 中可能有多項(xiàng)：

{
"auths": {
"my-registry.io/images": {
"auth": "…"
},
"my-registry.io/images/subpath": {
"auth": "…"
}
}
}

如果一個(gè)容器指定了要拉取的鏡像 my-registry.io/images/subpath/my-image， 并且其中一個(gè)失敗，kubelet 將嘗試從另一個(gè)身份驗(yàn)證源下載鏡像。

2、提前拉取鏡像

注意：該方法適用于能夠控制節(jié)點(diǎn)配置的場(chǎng)合。 如果云供應(yīng)商負(fù)責(zé)管理節(jié)點(diǎn)并自動(dòng)置換節(jié)點(diǎn)，這一方案無(wú)法可靠地工作。

默認(rèn)情況下，kubelet 會(huì)嘗試從指定的倉(cāng)庫(kù)拉取每個(gè)鏡像。 但是，如果容器屬性 imagePullPolicy 設(shè)置為 IfNotPresent 或者 Never， 則會(huì)優(yōu)先使用（對(duì)應(yīng) IfNotPresent）或者一定使用（對(duì)應(yīng) Never）本地鏡像。如果希望使用提前拉取鏡像的方法代替?zhèn)}庫(kù)認(rèn)證，就必須保證集群中所有節(jié)點(diǎn)提前拉取的鏡像是相同的。這一方案可以用來(lái)提前載入指定的鏡像以提高速度，或者作為向私有倉(cāng)庫(kù)執(zhí)行身份認(rèn)證的一種替代方案。所有的 Pod 都可以使用節(jié)點(diǎn)上提前拉取的鏡像。

3、指定ImagePullSecrets

注意：建議運(yùn)行使用私有倉(cāng)庫(kù)中鏡像的容器時(shí)使用。

Kubernetes 支持在 Pod 中設(shè)置容器鏡像倉(cāng)庫(kù)的密鑰。 imagePullSecrets 必須全部與 Pod 位于同一個(gè)名字空間中。 引用的 Secret 必須是 kubernetes.io/dockercfg 或 kubernetes.io/dockerconfigjson 類型。

4、創(chuàng)建Secret

首先需要知道用于向倉(cāng)庫(kù)進(jìn)行身份驗(yàn)證的用戶名、密碼和客戶端電子郵件地址，以及它的主機(jī)名。 運(yùn)行以下命令，注意替換適當(dāng)?shù)拇髮懼担?/p>

kubectl create secret docker-registry <name> \
--docker-server=DOCKER_REGISTRY_SERVER \
--docker-username=DOCKER_USER \
--docker-password=DOCKER_PASSWORD \
--docker-email=DOCKER_EMAIL

如果已經(jīng)有 Docker 憑據(jù)文件，則可以將憑據(jù)文件導(dǎo)入為 Kubernetes Secret， 而不是執(zhí)行上面的命令。 基于已有的 Docker 憑據(jù)創(chuàng)建 Secret 解釋了如何完成這一操作；如果在使用多個(gè)私有容器倉(cāng)庫(kù)，這種技術(shù)將特別有用。 原因是 kubectl create secret docker-registry 創(chuàng)建的是僅適用于某個(gè)私有倉(cāng)庫(kù)的 Secret。

注意：Pod 只能引用位于自身所在名字空間中的 Secret，因此需要針對(duì)每個(gè)名字空間重復(fù)執(zhí)行上述過(guò)程。

5、Pod引用ImagePullSecrets

在創(chuàng)建 Pod 時(shí)，可以在 Pod 定義中增加 imagePullSecrets 部分來(lái)引用該 Secret。 imagePullSecrets 數(shù)組中的每一項(xiàng)只能引用同一名字空間中的 Secret。例如：

cat <<EOF > pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
- name: foo
image: janedoe/awesomeapp:v1
imagePullSecrets:
- name: myregistrykey
EOF
cat <<EOF >> ./kustomization.yaml
resources:
- pod.yaml
EOF

對(duì)使用私有倉(cāng)庫(kù)的每個(gè) Pod 執(zhí)行以上操作， 設(shè)置該字段的過(guò)程也可以通過(guò)為服務(wù)賬號(hào)資源設(shè)置 imagePullSecrets 來(lái)自動(dòng)完成。 有關(guān)詳細(xì)指令， 可參見(jiàn)將 ImagePullSecrets 添加到服務(wù)賬號(hào)。也可以將此方法與節(jié)點(diǎn)級(jí)別的 .docker/config.json 配置結(jié)合使用。 來(lái)自不同來(lái)源的憑據(jù)會(huì)被合并。

四、使用案例

配置私有倉(cāng)庫(kù)有多種方案，以下是一些常用場(chǎng)景和建議的解決方案。

1、集群運(yùn)行非專有鏡像（例如，開(kāi)源鏡像）。鏡像不需要隱藏。

• 使用來(lái)自公共倉(cāng)庫(kù)的公共鏡像：無(wú)需配置；某些云廠商會(huì)自動(dòng)為公開(kāi)鏡像提供高速緩存，以便提升可用性并縮短拉取鏡像所需時(shí)間。

2、集群運(yùn)行一些專有鏡像，這些鏡像需要對(duì)公司外部隱藏，對(duì)所有集群用戶可見(jiàn)。

• 使用托管的私有倉(cāng)庫(kù)，在需要訪問(wèn)私有倉(cāng)庫(kù)的節(jié)點(diǎn)上可能需要手動(dòng)配置。
• 或者，在防火墻內(nèi)運(yùn)行一個(gè)組織內(nèi)部的私有倉(cāng)庫(kù)，并開(kāi)放讀取權(quán)限，不需要配置 Kubernetes。
• 使用控制鏡像訪問(wèn)的托管容器鏡像倉(cāng)庫(kù)服務(wù)，與手動(dòng)配置節(jié)點(diǎn)相比，這種方案能更好地處理集群自動(dòng)擴(kuò)縮容。
• 或者，在不方便更改節(jié)點(diǎn)配置的集群中，使用 imagePullSecrets

3、集群使用專有鏡像，且有些鏡像需要更嚴(yán)格的訪問(wèn)控制

• 確保 AlwaysPullImages 準(zhǔn)入控制器被啟用。否則，所有 Pod 都可以使用所有鏡像。
• 確保將敏感數(shù)據(jù)存儲(chǔ)在 Secret 資源中，而不是將其打包在鏡像里

4、集群是多租戶的并且每個(gè)租戶需要自己的私有倉(cāng)庫(kù)

• 確保 AlwaysPullImages 準(zhǔn)入控制器。否則，所有租戶的所有的 Pod 都可以使用所有鏡像。
• 為私有倉(cāng)庫(kù)啟用鑒權(quán)。
• 為每個(gè)租戶生成訪問(wèn)倉(cāng)庫(kù)的憑據(jù)，放置在 Secret 中，并將 Secret 發(fā)布到各租戶的名字空間下。
• 租戶將 Secret 添加到每個(gè)名字空間中的 imagePullSecrets。

如果需要訪問(wèn)多個(gè)倉(cāng)庫(kù)，可以為每個(gè)倉(cāng)庫(kù)創(chuàng)建一個(gè) Secret。

五、舊版憑據(jù)提供程序

在舊版本的 Kubernetes 中，kubelet 與云提供商憑據(jù)直接集成。 這使它能夠動(dòng)態(tài)獲取鏡像倉(cāng)庫(kù)的憑據(jù)。kubelet 憑據(jù)提供程序集成存在三個(gè)內(nèi)置實(shí)現(xiàn)： ACR（Azure 容器倉(cāng)庫(kù)）、ECR（Elastic 容器倉(cāng)庫(kù)）和 GCR（Google 容器倉(cāng)庫(kù)）。 從 Kubernetes v1.26 到 v1.28 不再包含該舊版機(jī)制，因此需要：

• 在每個(gè)節(jié)點(diǎn)上配置一個(gè) kubelet 鏡像憑據(jù)提供程序。
• 使用 imagePullSecrets 和至少一個(gè) Secret 指定鏡像拉取憑據(jù)。