建站
咨詢
售后
建站咨詢
新聞中心
鏡像
容器鏡像（Image）所承載的是封裝了應(yīng)用程序及其所有軟件依賴的二進制數(shù)據(jù)。 容器鏡像是可執(zhí)行的軟件包，可以單獨運行；該軟件包對所處的運行時環(huán)境具有 良定（Well Defined）的假定。
為武邑等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及武邑網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為網(wǎng)站制作、成都網(wǎng)站建設(shè)、武邑網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認(rèn)可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
你通常會創(chuàng)建應(yīng)用的容器鏡像并將其推送到某倉庫（Registry），然后在 Pod 中引用它。
本頁概要介紹容器鏡像的概念。
鏡像名稱
容器鏡像通常會被賦予 ?pause?、?example/mycontainer? 或者 ?kube-apiserver? 這類的名稱。 鏡像名稱也可以包含所在倉庫的主機名。例如：?fictional.registry.example/imagename?。 還可以包含倉庫的端口號，例如：?fictional.registry.example:10443/imagename?。
如果你不指定倉庫的主機名，Kubernetes 認(rèn)為你在使用 Docker 公共倉庫。
在鏡像名稱之后，你可以添加一個標(biāo)簽（Tag）（與使用 ?docker ?或 ?podman ?等命令時的方式相同）。 使用標(biāo)簽?zāi)茏屇惚孀R同一鏡像序列中的不同版本。
鏡像標(biāo)簽可以包含小寫字母、大寫字母、數(shù)字、下劃線（?_?）、句點（?.?）和連字符（?-?）。 關(guān)于在鏡像標(biāo)簽中何處可以使用分隔字符（?_?、?-? 和 ?.?）還有一些額外的規(guī)則。 如果你不指定標(biāo)簽，Kubernetes 認(rèn)為你想使用標(biāo)簽 ?latest?。
更新鏡像
當(dāng)你最初創(chuàng)建一個 Deployment、 StatefulSet、Pod 或者其他包含 Pod 模板的對象時，如果沒有顯式設(shè)定的話，Pod 中所有容器的默認(rèn)鏡像 拉取策略是 ?IfNotPresent?。這一策略會使得 kubelet 在鏡像已經(jīng)存在的情況下直接略過拉取鏡像的操作。
鏡像拉取策略
容器的 ?imagePullPolicy ?和鏡像的標(biāo)簽會影響 kubelet 嘗試?yán)。ㄏ螺d）指定的鏡像。
以下列表包含了 ?imagePullPolicy ?可以設(shè)置的值，以及這些值的效果：
- IfNotPresent
- Always
- Never
只有當(dāng)鏡像在本地不存在時才會拉取。
每當(dāng) kubelet 啟動一個容器時，kubelet 會查詢?nèi)萜鞯溺R像倉庫， 將名稱解析為一個鏡像摘要。 如果 kubelet 有一個容器鏡像，并且對應(yīng)的摘要已在本地緩存，kubelet 就會使用其緩存的鏡像； 否則，kubelet 就會使用解析后的摘要拉取鏡像，并使用該鏡像來啟動容器。
Kubelet 不會嘗試獲取鏡像。如果鏡像已經(jīng)以某種方式存在本地， kubelet 會嘗試啟動容器；否則，會啟動失敗。
只要能夠可靠地訪問鏡像倉庫，底層鏡像提供者的緩存語義甚至可以使 imagePullPolicy: Always 高效。 你的容器運行時可以注意到節(jié)點上已經(jīng)存在的鏡像層，這樣就不需要再次下載。
在生產(chǎn)環(huán)境中部署容器時，你應(yīng)該避免使用 ?
:latest? 標(biāo)簽，因為這使得正在運行的鏡像的版本難以追蹤，并且難以正確地回滾。相反，應(yīng)指定一個有意義的標(biāo)簽，如 ?
v1.42.0?。
為了確保 Pod 總是使用相同版本的容器鏡像，你可以指定鏡像的摘要； 將 ?image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2?。
當(dāng)使用鏡像標(biāo)簽時，如果鏡像倉庫修改了代碼所對應(yīng)的鏡像標(biāo)簽，可能會出現(xiàn)新舊代碼混雜在 Pod 中運行的情況。 鏡像摘要唯一標(biāo)識了鏡像的特定版本，因此 Kubernetes 每次啟動具有指定鏡像名稱和摘要的容器時，都會運行相同的代碼。 通過摘要指定鏡像可固定你運行的代碼，這樣鏡像倉庫的變化就不會導(dǎo)致版本的混雜。
有一些第三方的準(zhǔn)入控制器 在創(chuàng)建 Pod（和 Pod 模板）時產(chǎn)生變更，這樣運行的工作負(fù)載就是根據(jù)鏡像摘要，而不是標(biāo)簽來定義的。 無論鏡像倉庫上的標(biāo)簽發(fā)生什么變化，你都想確保你所有的工作負(fù)載都運行相同的代碼，那么指定鏡像摘要會很有用。
默認(rèn)鏡像拉取策略
當(dāng)你（或控制器）向 API 服務(wù)器提交一個新的 Pod 時，你的集群會在滿足特定條件時設(shè)置 ?imagePullPolicy ?字段：
- 如果你省略了 ?
imagePullPolicy?字段，并且容器鏡像的標(biāo)簽是 ?:latest?， ?imagePullPolicy?會自動設(shè)置為 ?Always?。 - 如果你省略了 ?
imagePullPolicy?字段，并且沒有指定容器鏡像的標(biāo)簽， ?imagePullPolicy?會自動設(shè)置為 ?Always?。 - 如果你省略了 ?
imagePullPolicy?字段，并且為容器鏡像指定了非 ?:latest? 的標(biāo)簽， ?imagePullPolicy?就會自動設(shè)置為 ?IfNotPresent?。
容器的 ?
imagePullPolicy?的值總是在對象初次 創(chuàng)建 時設(shè)置的，如果后來鏡像的標(biāo)簽發(fā)生變化，則不會更新。例如，如果你用一個 非 ?
:latest? 的鏡像標(biāo)簽創(chuàng)建一個 Deployment， 并在隨后更新該 Deployment 的鏡像標(biāo)簽為 ?
:latest?，則 ?
imagePullPolicy?字段 不會 變成 ?
Always?。 你必須手動更改已經(jīng)創(chuàng)建的資源的拉取策略。
必要的鏡像拉取
如果你想總是強制執(zhí)行拉取，你可以使用下述的一中方式：
- 設(shè)置容器的 ?
imagePullPolicy?為 ?Always?。 - 省略 ?
imagePullPolicy?，并使用 ?:latest? 作為鏡像標(biāo)簽； 當(dāng)你提交 Pod 時，Kubernetes 會將策略設(shè)置為 ?Always?。 - 省略 ?
imagePullPolicy?和鏡像的標(biāo)簽； 當(dāng)你提交 Pod 時，Kubernetes 會將策略設(shè)置為 ?Always?。 - 啟用準(zhǔn)入控制器 AlwaysPullImages。
ImagePullBackOff
當(dāng) kubelet 使用容器運行時創(chuàng)建 Pod 時，容器可能因為 ?ImagePullBackOff ?導(dǎo)致狀態(tài)為 Waiting。
?ImagePullBackOff ?狀態(tài)意味著容器無法啟動， 因為 Kubernetes 無法拉取容器鏡像（原因包括無效的鏡像名稱，或從私有倉庫拉取而沒有 ?imagePullSecret?）。 ?BackOff ?部分表示 Kubernetes 將繼續(xù)嘗試?yán)＄R像，并增加回退延遲。
Kubernetes 會增加每次嘗試之間的延遲，直到達到編譯限制，即 300 秒（5 分鐘）。
帶鏡像索引的多架構(gòu)鏡像
除了提供二進制的鏡像之外，容器倉庫也可以提供 容器鏡像索引。 鏡像索引可以根據(jù)特定于體系結(jié)構(gòu)版本的容器指向鏡像的多個 鏡像清單。 這背后的理念是讓你可以為鏡像命名（例如：?pause?、?example/mycontainer?、?kube-apiserver?） 的同時，允許不同的系統(tǒng)基于它們所使用的機器體系結(jié)構(gòu)取回正確的二進制鏡像。
Kubernetes 自身通常在命名容器鏡像時添加后綴 ?-$(ARCH)?。 為了向前兼容，請在生成較老的鏡像時也提供后綴。 這里的理念是為某鏡像（如 ?pause?）生成針對所有平臺都適用的清單時， 生成 ?pause-amd64? 這類鏡像，以便較老的配置文件或者將鏡像后綴影編碼到其中的 YAML 文件也能兼容。
使用私有倉庫
從私有倉庫讀取鏡像時可能需要密鑰。 憑證可以用以下方式提供:
- 配置節(jié)點向私有倉庫進行身份驗證
- 所有 Pod 均可讀取任何已配置的私有倉庫
- 需要集群管理員配置節(jié)點
- 預(yù)拉鏡像
- 所有 Pod 都可以使用節(jié)點上緩存的所有鏡像
- 需要所有節(jié)點的 root 訪問權(quán)限才能進行設(shè)置
- 在 Pod 中設(shè)置 ImagePullSecrets
- 只有提供自己密鑰的 Pod 才能訪問私有倉庫
- 特定于廠商的擴展或者本地擴展
- 如果你在使用定制的節(jié)點配置，你（或者云平臺提供商）可以實現(xiàn)讓節(jié)點 向容器倉庫認(rèn)證的機制
配置 Node 對私有倉庫認(rèn)證
設(shè)置憑據(jù)的具體說明取決于你選擇使用的容器運行時和倉庫。
Kubernetes 默認(rèn)僅支持 Docker 配置中的 ?
auths?和 ?HttpHeaders?部分， 不支持 Docker 憑據(jù)輔助程序（?credHelpers?或 ?credsStore?）。
config.json 說明
對于 ?config.json? 的解釋在原始 Docker 實現(xiàn)和 Kubernetes 的解釋之間有所不同。 在 Docker 中，?auths ?鍵只能指定根 URL ，而 Kubernetes 允許 glob URLs 以及 前綴匹配的路徑。這意味著，像這樣的 ?config.json? 是有效的：
{
"auths": {
"*my-registry.io/images": {
"auth": "…"
}
}
}
使用以下語法匹配根 URL （?*my-registry.io?）：
pattern:
{ term }
term:
'*' 匹配任何無分隔符字符序列
'?' 匹配任意單個非分隔符
'[' [ '^' ] 字符范圍
字符集（必須非空）
c 匹配字符 c （c 不為 '*','?','\\','['）
'\\' c 匹配字符 c
字符范圍:
c 匹配字符 c （c 不為 '\\','?','-',']'）
'\\' c 匹配字符 c
lo '-' hi 匹配字符范圍在 lo 到 hi 之間字符現(xiàn)在鏡像拉取操作會將每種有效模式的憑據(jù)都傳遞給 CRI 容器運行時。例如下面的容器鏡像名稱會匹配成功：
- ?
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 為每個找到的憑證的鏡像按順序拉取。 這意味著在 ?config.json? 中可能有多項：
{
"auths": {
"my-registry.io/images": {
"auth": "…"
},
"my-registry.io/images/subpath": {
"auth": "…"
}
}
}如果一個容器指定了要拉取的鏡像 ?my-registry.io/images/subpath/my-image?， 并且其中一個失敗，kubelet 將嘗試從另一個身份驗證源下載鏡像。
提前拉取鏡像
該方法適用于你能夠控制節(jié)點配置的場合。 如果你的云供應(yīng)商負(fù)責(zé)管理節(jié)點并自動置換節(jié)點，這一方案無法可靠地工作。
默認(rèn)情況下，?kubelet ?會嘗試從指定的倉庫拉取每個鏡像。 但是，如果容器屬性 ?imagePullPolicy ?設(shè)置為 ?IfNotPresent ?或者 ?Never?， 則會優(yōu)先使用（對應(yīng) ?IfNotPresent?）或者一定使用（對應(yīng) ?Never?）本地鏡像。
如果你希望使用提前拉取鏡像的方法代替?zhèn)}庫認(rèn)證，就必須保證集群中所有節(jié)點提前拉取的鏡像是相同的。
這一方案可以用來提前載入指定的鏡像以提高速度，或者作為向私有倉庫執(zhí)行身份認(rèn)證的一種替代方案。
所有的 Pod 都可以使用節(jié)點上提前拉取的鏡像。
在 Pod 上指定 ImagePullSecrets
運行使用私有倉庫中鏡像的容器時，建議使用這種方法。
Kubernetes 支持在 Pod 中設(shè)置容器鏡像倉庫的密鑰。
使用 Docker Config 創(chuàng)建 Secret
你需要知道用于向倉庫進行身份驗證的用戶名、密碼和客戶端電子郵件地址，以及它的主機名。 運行以下命令，注意替換適當(dāng)?shù)拇髮懼担?/p>
kubectl create secret docker-registry --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í)行上面的命令。
如果你在使用多個私有容器倉庫，這種技術(shù)將特別有用。 原因是 ?kubectl create secret docker-registry? 創(chuàng)建的是僅適用于某個私有倉庫的 Secret。
Pod 只能引用位于自身所在名字空間中的 Secret，因此需要針對每個名字空間 重復(fù)執(zhí)行上述過程。
在 Pod 中引用 ImagePullSecrets
現(xiàn)在，在創(chuàng)建 Pod 時，可以在 Pod 定義中增加 ?imagePullSecrets ?部分來引用該 Secret。
例如：
cat < pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: foo
namespace: awesomeapps
spec:
containers:
- name: foo
image: janedoe/awesomeapp:v1
imagePullSecrets:
- name: myregistrykey
EOF
cat <> ./kustomization.yaml
resources:
- pod.yaml
EOF 你需要對使用私有倉庫的每個 Pod 執(zhí)行以上操作。 不過，設(shè)置該字段的過程也可以通過為 服務(wù)賬號 資源設(shè)置 ?imagePullSecrets ?來自動完成。
你也可以將此方法與節(jié)點級別的 ?.docker/config.json? 配置結(jié)合使用。 來自不同來源的憑據(jù)會被合并。
使用案例
配置私有倉庫有多種方案，以下是一些常用場景和建議的解決方案。
- 集群運行非專有鏡像（例如，開源鏡像）。鏡像不需要隱藏。
- 使用 Docker hub 上的公開鏡像
- 無需配置
- 某些云廠商會自動為公開鏡像提供高速緩存，以便提升可用性并縮短拉取鏡像所需時間
- 集群運行一些專有鏡像，這些鏡像需要對公司外部隱藏，對所有集群用戶可見
- 使用托管的私有 Docker 倉庫。
- 可以托管在 Docker Hub 或者其他地方
- 按照上面的描述，在每個節(jié)點上手動配置 .docker/config.json 文件
- 或者，在防火墻內(nèi)運行一個組織內(nèi)部的私有倉庫，并開放讀取權(quán)限
- 不需要配置 Kubenretes
- 使用控制鏡像訪問的托管容器鏡像倉庫服務(wù)
- 與手動配置節(jié)點相比，這種方案能更好地處理集群自動擴縮容
- 或者，在不方便更改節(jié)點配置的集群中，使用 imagePullSecrets
- 集群使用專有鏡像，且有些鏡像需要更嚴(yán)格的訪問控制
- 確保 AlwaysPullImages 準(zhǔn)入控制器被啟用。否則，所有 Pod 都可以使用所有鏡像。
- 確保將敏感數(shù)據(jù)存儲在 Secret 資源中，而不是將其打包在鏡像里
- 集群是多租戶的并且每個租戶需要自己的私有倉庫
- 確保 AlwaysPullImages 準(zhǔn)入控制器。否則，所有租戶的所有的 Pod 都可以使用所有鏡像。
- 為私有倉庫啟用鑒權(quán)
- 為每個租戶生成訪問倉庫的憑據(jù)，放置在 Secret 中，并將 Secrert 發(fā)布到各租戶的命名空間下。
- 租戶將 Secret 添加到每個名字空間中的 imagePullSecrets
如果你需要訪問多個倉庫，可以為每個倉庫創(chuàng)建一個 Secret。 ?kubelet ?將所有 ?imagePullSecrets ?合并為一個虛擬的 ?.docker/config.json? 文件。
當(dāng)前名稱：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes鏡像
網(wǎng)頁網(wǎng)址：http://www.5511xx.com/article/dhgecop.html
