如何強制 Kubernetes 重新拉取鏡像
一、概述
Kubernetes 是一個高度健壯的容器編排平台,廣泛用於有效管理和擴展容器中打包的應用程序。為了確保應用程序的穩定性和安全性,了解如何在必要時強制 Kubernetes 重新拉取鏡像至關重要。在本教程中,我們將探討使我們能夠有效完成此任務的各種技術。
2.鏡像拉取政策
強制 Kubernetes 重新拉取鏡像的一種方法是設置鏡像拉取策略。 Kubernetes 允許我們為 pod 中的每個容器指定鏡像拉取策略。默認情況下,Kubernetes 使用IfNotPresent
策略,該策略僅在圖像不存在於節點上時才拉取該圖像。但是,我們可以通過在部署清單中的容器規範中將拉取策略設置為Always
來強制 Kubernetes 始終重新拉取圖像。
例如,讓我們定義一個名為“my-app”
的 Kubernetes Deployment,它使用一個名為“my-container”
的容器管理 pod 模板的三個副本。容器使用帶有“latest”
標籤的“myregistry/my-image”
Docker 鏡像,並始終從註冊表中拉取鏡像:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
spec:
containers:
- name: my-container
image: myregistry/my-image:latest
imagePullPolicy: Always
3. 圖片標籤
更新鏡像標籤是觸發 Kubernetes 拉取新版本鏡像的一種強大而直接的方法。通過修改與鏡像關聯的標籤,Kubernetes 將其識別為不同的鏡像並啟動拉取更新版本的過程。在部署特定圖像版本或使用使用標籤進行版本控制的圖像存儲庫時,此方法特別有價值。
讓我們考慮一個例子來說明這個過程。
假設我們在 Kubernetes 中定義了一個名為my-app
Deployment,並且在Deployment
中,有一個名為my-container
容器引用了一個名為myregistry/my-image
且標籤為2.0.0
的鏡像。現在,假設我們要將圖像更新到更新的版本,例如2.1.0
。
為此,我們只需將Deployment
定義中的標記值修改為2.1.0
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
spec:
containers:
- name: my-container
image: myregistry/my-image:2.1.0
保存並應用修改後的Deployment
後,Kubernetes 會檢測到圖像標籤中的更改。它識別出鏡像標籤已更新為2.1.0
,並啟動從容器註冊表中拉取新版本鏡像的過程。成功拉取更新後的鏡像後,Kubernetes 會自動將更改應用到與Deployment
關聯的正在運行的 pod,確保應用程序現在正在使用最新的鏡像版本。
這種方法提供了對圖像更新過程的靈活性和控制。它允許將新版本的容器鏡像無縫集成到 Kubernetes 部署中,而不會中斷整體應用程序功能。
通過簡單地修改鏡像標籤,開發人員和運營商可以確保他們的應用程序始終受益於更新後的容器鏡像提供的最新功能、錯誤修復和安全補丁。
4. 鏡像拉取秘訣
在由於訪問私有容器註冊表的憑據發生變化而需要重新拉取鏡像的場景中,Kubernetes 允許我們指定鏡像拉取秘密。當憑據發生變化時,使用更新的憑據創建新的鏡像拉取密鑰並將其與我們的部署相關聯可以觸發 Kubernetes 重新拉取鏡像。
讓我們考慮以下定義機密的YAML
文件示例:
apiVersion: v1
kind: Secret
metadata:
name: my-registry-secret
type: kubernetes.io/dockerconfigjson
data:
.dockerconfigjson: <base64-encoded credentials>
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
template:
spec:
containers:
- name: my-container
image: myregistry/my-image:latest
imagePullSecrets:
- name: my-registry-secret
現在,考慮開發團隊正在構建一個複雜的基於微服務的應用程序的場景,該應用程序依賴於駐留在私有註冊表中的容器鏡像。
為了在 Kubernetes 集群上成功部署此應用程序,團隊將定義一個ImagePullSecret
,其中包含必要的身份驗證詳細信息,例如用戶名和密碼或訪問令牌。隨後,他們會將此機密與負責拉取容器映像的適當 Pod 或服務帳戶相關聯。
通過準確配置ImagePullSecret
,Kubernetes 集群在部署期間自主檢索必要的憑據,與私有註冊表建立安全的身份驗證過程以獲取所需的容器鏡像。
這種強大的方法保證了對受限圖像的無縫訪問,從而確保在 Kubernetes 環境中平穩可靠地運行。
5. OpenShift 中的圖像流
在 OpenShift 中, ImageStream
功能簡化了應用程序部署中容器映像的管理和更新。作為一個抽象層, ImageStream
可以在不改變圖像名稱的情況下修改圖像元數據,從而在不中斷部署過程的情況下促進無縫更新。
當關聯的標籤被修改時,OpenShift 和 Kubernetes 將被提示獲取更新後的圖像。將新映像推送到註冊表時,OpenShift 會將元數據與現有版本進行比較。如果標記已更改,OpenShift 會將其識別為新的迭代並自動更新ImageStream
。因此,任何引用ImageStream
的部署都將在後續部署或推出期間包含最新的圖像版本。
ImageStream
的好處是多方面的。它通過只需要修改ImageStream
標籤來簡化圖像更新,最大限度地減少配置錯誤並節省時間。此外,它確保跨部署的一致性,保證依賴於ImageStream
所有應用程序都採用相同的更新圖像版本。
回滾和自動修剪等其他高級功能進一步增強了管理流程。回滾有助於輕鬆恢復到以前的圖像版本,而自動修剪通過刪除較舊的迭代來優化存儲使用。
為了說明它的用法,讓我們考慮另一個示例YAML
文件:
apiVersion: image.openshift.io/v1
kind: ImageStream
metadata:
name: my-image-stream
spec:
tags:
- name: latest
from:
kind: DockerImage
name: myregistry/my-image:2.1.0
在此示例中,YAML 文件定義了一個名為my-app-image
的ImageStream
,其標籤名為latest
。該標記將源指定為位於registry.example.com/my-app:latest
的 Docker 映像。將ImageStream's
標籤更新為新版本會觸發 OpenShift 拉取更新後的圖像並自動將其部署到集群中。
總而言之,OpenShift 中的ImageStream
通過抽像圖像名稱和支持輕鬆修改元數據來簡化圖像管理。它簡化了更新過程,確保跨部署的一致性,並提供回滾和自動修剪等功能。
6.使用滾動更新
Kubernetes 支持滾動更新,它提供了一種逐步更新我們的應用程序部署的機制。在滾動更新期間,Kubernetes 使用更新後的鏡像創建一個新的副本集,同時逐漸縮小舊的副本集。這種方法確保我們應用程序的所有實例都使用最新的圖像。如果在更新過程中出現任何問題,滾動更新還提供回滾到以前版本的能力。
下面的命令說明了我們如何通過滾動更新來編輯部署:
$ kubectl set image deployment/my-app my-container=myregistry/my-image:2.1.0
deployment/my-app image updated
七、結論
在本文中,我們探索了幾種強制 Kubernetes 重新拉取鏡像的方法。通過了解鏡像重新拉取的重要性並應用適當的技術,我們可以確保我們的應用程序與最新版本保持同步,並包含關鍵錯誤修復或安全補丁。
我們討論了ImagePullPolicy
的用法、更新圖像標籤、使用ImagePullSecrets
、利用 OpenShift 中的ImageStream
以及利用滾動更新。
通過將鏡像拉取策略設置為Always
或更新鏡像標籤,我們可以提示 Kubernetes 從容器註冊表中獲取最新的鏡像。此外,如果訪問註冊表所需的憑據發生變化,使用鏡像拉取密碼是觸發重新拉取的有效方法。
OpenShift 用戶可以利用 ImageStream 功能來管理圖像更新,而無需修改圖像名稱。最後,滾動更新提供了一個可控的漸進過程來更新部署,同時確保應用程序可用性。
我們需要選擇符合我們特定要求和環境的方法。通過遵循這些技術,我們可以保持 Kubernetes 中容器化應用程序的可靠性、安全性和效率。