容器執行階段
您需要在叢集中的每個節點中安裝容器執行階段,以便 Pod 可以在那裡執行。此頁面概述了所涉及的內容,並描述了設定節點的相關任務。
Kubernetes 1.32 版本要求您使用符合容器執行階段介面 (CRI) 的執行階段。
請參閱CRI 版本支援以取得更多資訊。
本頁概述如何在 Kubernetes 中使用幾個常見的容器執行階段。
注意
v1.24 之前的 Kubernetes 版本包含與 Docker Engine 的直接整合,使用名為 dockershim 的元件。這種特殊的直接整合已不再是 Kubernetes 的一部分(此移除已在 v1.20 版本公告)。您可以閱讀檢查 Dockershim 移除是否影響您,以了解此移除可能如何影響您。若要了解如何從使用 dockershim 遷移,請參閱從 dockershim 遷移。
如果您執行的 Kubernetes 版本不是 v1.32,請查看該版本的說明文件。
安裝及設定先決條件
網路設定
預設情況下,Linux 核心不允許 IPv4 封包在介面之間路由。大多數 Kubernetes 叢集網路實作會變更此設定(如果需要),但有些可能會期望管理員為他們執行此操作。(有些可能也期望設定其他 sysctl 參數、載入核心模組等等;請參閱您特定網路實作的說明文件。)
啟用 IPv4 封包轉發
手動啟用 IPv4 封包轉發
# sysctl params required by setup, params persist across reboots
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.ipv4.ip_forward = 1
EOF
# Apply sysctl params without reboot
sudo sysctl --system
使用以下命令驗證 net.ipv4.ip_forward
是否設定為 1
sysctl net.ipv4.ip_forward
cgroup 驅動程式
在 Linux 上,控制群組用於約束分配給程序的資源。
kubelet 和底層容器執行階段都需要與控制群組介接,以實施 Pod 和容器的資源管理,並設定 CPU/記憶體請求和限制等資源。為了與控制群組介接,kubelet 和容器執行階段需要使用 cgroup 驅動程式。kubelet 和容器執行階段使用相同的 cgroup 驅動程式並配置相同至關重要。
有兩個可用的 cgroup 驅動程式
cgroupfs 驅動程式
cgroupfs
驅動程式是 kubelet 中的預設 cgroup 驅動程式。當使用 cgroupfs
驅動程式時,kubelet 和容器執行階段直接與 cgroup 檔案系統介接以配置 cgroup。
當 systemd 是初始化系統時,不建議使用 cgroupfs
驅動程式,因為 systemd 期望系統上有單一 cgroup 管理器。此外,如果您使用 cgroup v2,請使用 systemd
cgroup 驅動程式而不是 cgroupfs
。
systemd cgroup 驅動程式
當選擇 systemd 作為 Linux 發行版的初始化系統時,初始化程序會產生和消耗根控制群組 (cgroup
) 並充當 cgroup 管理器。
systemd 與 cgroup 緊密整合,並為每個 systemd 單元分配一個 cgroup。因此,如果您將 systemd
作為初始化系統與 cgroupfs
驅動程式一起使用,系統會獲得兩個不同的 cgroup 管理器。
兩個 cgroup 管理器會導致系統中可用和使用中資源的兩種視圖。在某些情況下,配置為 kubelet 和容器執行階段使用 cgroupfs
,但系統其餘程序使用 systemd
的節點,在資源壓力下會變得不穩定。
緩解這種不穩定性的方法是,當 systemd 是選定的初始化系統時,將 systemd
用作 kubelet 和容器執行階段的 cgroup 驅動程式。
若要將 systemd
設定為 cgroup 驅動程式,請編輯 KubeletConfiguration
的 cgroupDriver
選項,並將其設定為 systemd
。例如
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd
注意
從 v1.22 及更高版本開始,當使用 kubeadm 建立叢集時,如果使用者未在KubeletConfiguration
下設定 cgroupDriver
欄位,kubeadm 會將其預設為 systemd
。如果您為 kubelet 配置 systemd
作為 cgroup 驅動程式,您也必須為容器執行階段配置 systemd
作為 cgroup 驅動程式。請參閱您的容器執行階段的文件以取得指示。例如
在 Kubernetes 1.32 中,啟用 KubeletCgroupDriverFromCRI
功能閘道 和支援 RuntimeConfig
CRI RPC 的容器執行階段,kubelet 會自動從執行階段偵測適當的 cgroup 驅動程式,並忽略 kubelet 配置中的 cgroupDriver
設定。
注意
變更已加入叢集的節點的 cgroup 驅動程式是一項敏感操作。如果 kubelet 已使用一個 cgroup 驅動程式的語意建立 Pod,則將容器執行階段變更為另一個 cgroup 驅動程式可能會在嘗試為此類現有 Pod 重新建立 Pod 沙箱時導致錯誤。重新啟動 kubelet 可能無法解決此類錯誤。
如果您有自動化使其可行,請使用另一個具有更新配置的節點替換該節點,或使用自動化重新安裝它。
在 kubeadm 管理的叢集中遷移到 systemd
驅動程式
如果您希望在現有的 kubeadm 管理的叢集中遷移到 systemd
cgroup 驅動程式,請按照配置 cgroup 驅動程式進行操作。
CRI 版本支援
您的容器執行階段必須至少支援容器執行階段介面的 v1alpha2 版本。
Kubernetes 從 v1.26 開始僅適用於 CRI API 的 v1 版本。較早版本預設為 v1 版本,但是如果容器執行階段不支援 v1 API,則 kubelet 會退回使用(已棄用的)v1alpha2 API。
容器執行階段
containerd
本節概述使用 containerd 作為 CRI 執行階段的必要步驟。
若要在您的系統上安裝 containerd,請按照containerd 入門上的指示進行操作。一旦您建立有效的 config.toml
配置檔案,請返回此步驟。
您可以在路徑 /etc/containerd/config.toml
下找到此檔案。
您可以在路徑 C:\Program Files\containerd\config.toml
下找到此檔案。
在 Linux 上,containerd 的預設 CRI Socket 是 /run/containerd/containerd.sock
。在 Windows 上,預設 CRI 端點是 npipe://./pipe/containerd-containerd
。
配置 systemd
cgroup 驅動程式
若要在 /etc/containerd/config.toml
中使用 systemd
cgroup 驅動程式搭配 runc
,請設定
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
...
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
如果您使用 cgroup v2,建議使用 systemd
cgroup 驅動程式。
注意
如果您從套件(例如,RPM 或 .deb
)安裝 containerd,您可能會發現 CRI 整合外掛程式預設為停用。
您需要啟用 CRI 支援才能將 containerd 與 Kubernetes 一起使用。請確保 cri
未包含在 /etc/containerd/config.toml
中的 disabled_plugins
清單中;如果您對該檔案進行了變更,也請重新啟動 containerd
。
如果您在初始叢集安裝後或安裝 CNI 後遇到容器崩潰迴圈,則套件提供的 containerd 配置可能包含不相容的配置參數。考慮使用 containerd config default > /etc/containerd/config.toml
重設 containerd 配置,如getting-started.md 中指定的那樣,然後相應地設定上面指定的配置參數。
如果您套用此變更,請務必重新啟動 containerd
sudo systemctl restart containerd
當使用 kubeadm 時,手動配置 kubelet 的 cgroup 驅動程式。
在 Kubernetes v1.28 中,您可以啟用 cgroup 驅動程式的自動偵測作為 Alpha 功能。請參閱systemd cgroup 驅動程式以取得更多詳細資訊。
覆寫沙箱 (pause) 映像檔
在您的 containerd 配置中,您可以透過設定以下配置來覆寫沙箱映像檔
[plugins."io.containerd.grpc.v1.cri"]
sandbox_image = "registry.k8s.io/pause:3.2"
一旦您更新了配置檔案,您可能也需要重新啟動 containerd
:systemctl restart containerd
。
CRI-O
本節包含安裝 CRI-O 作為容器執行階段的必要步驟。
若要安裝 CRI-O,請按照CRI-O 安裝指示進行操作。
cgroup 驅動程式
CRI-O 預設使用 systemd cgroup 驅動程式,這很可能對您有效。若要切換到 cgroupfs
cgroup 驅動程式,請編輯 /etc/crio/crio.conf
或在 /etc/crio/crio.conf.d/02-cgroup-manager.conf
中放置一個 drop-in 配置,例如
[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"
您也應該注意已變更的 conmon_cgroup
,當將 CRI-O 與 cgroupfs
一起使用時,必須將其設定為值 pod
。通常有必要保持 kubelet(通常透過 kubeadm 完成)和 CRI-O 的 cgroup 驅動程式配置同步。
在 Kubernetes v1.28 中,您可以啟用 cgroup 驅動程式的自動偵測作為 Alpha 功能。請參閱systemd cgroup 驅動程式以取得更多詳細資訊。
對於 CRI-O,CRI Socket 預設為 /var/run/crio/crio.sock
。
覆寫沙箱 (pause) 映像檔
在您的 CRI-O 配置中,您可以設定以下配置值
[crio.image]
pause_image="registry.k8s.io/pause:3.6"
此配置選項支援即時配置重新載入以套用此變更:systemctl reload crio
或將 SIGHUP
傳送至 crio
程序。
Docker Engine
注意
這些指示假設您正在使用cri-dockerd
介面卡將 Docker Engine 與 Kubernetes 整合。在您的每個節點上,依照 安裝 Docker Engine 的說明,為您的 Linux 發行版安裝 Docker。
依照說明文件安裝章節中的指示,安裝
cri-dockerd
。
對於 cri-dockerd
,CRI Socket 預設為 /run/cri-dockerd.sock
。
Mirantis Container Runtime
Mirantis Container Runtime (MCR) 是一個商業上可用的容器執行階段,以前稱為 Docker Enterprise Edition。
您可以將 Mirantis Container Runtime 與 Kubernetes 一起使用,使用 MCR 隨附的開放原始碼 cri-dockerd
元件。
若要了解更多關於如何安裝 Mirantis Container Runtime 的資訊,請造訪 MCR 部署指南。
檢查名為 cri-docker.socket
的 systemd 單元,以找出 CRI Socket 的路徑。
覆寫沙箱 (pause) 映像檔
cri-dockerd
介面卡接受命令列引數,用於指定要用作 Pod 基礎架構容器(「pause 映像檔」)的容器映像檔。要使用的命令列引數是 --pod-infra-container-image
。
下一步
除了容器執行階段之外,您的叢集還需要一個可運作的網路外掛程式。
本頁上的項目參考了第三方產品或專案,這些產品或專案提供 Kubernetes 所需的功能。Kubernetes 專案作者不對這些第三方產品或專案負責。有關更多詳細資訊,請參閱 CNCF 網站指南。
在提出新增額外第三方連結的變更之前,您應該閱讀內容指南。