容器執行階段

您需要在叢集中的每個節點中安裝容器執行階段,以便 Pod 可以在那裡執行。此頁面概述了所涉及的內容,並描述了設定節點的相關任務。

Kubernetes 1.32 版本要求您使用符合容器執行階段介面 (CRI) 的執行階段。

請參閱CRI 版本支援以取得更多資訊。

本頁概述如何在 Kubernetes 中使用幾個常見的容器執行階段。

安裝及設定先決條件

網路設定

預設情況下,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 驅動程式,請編輯 KubeletConfigurationcgroupDriver 選項,並將其設定為 systemd。例如

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
...
cgroupDriver: systemd

如果您為 kubelet 配置 systemd 作為 cgroup 驅動程式,您也必須為容器執行階段配置 systemd 作為 cgroup 驅動程式。請參閱您的容器執行階段的文件以取得指示。例如

在 Kubernetes 1.32 中,啟用 KubeletCgroupDriverFromCRI 功能閘道 和支援 RuntimeConfig CRI RPC 的容器執行階段,kubelet 會自動從執行階段偵測適當的 cgroup 驅動程式,並忽略 kubelet 配置中的 cgroupDriver 設定。

在 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 驅動程式。

如果您套用此變更,請務必重新啟動 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"

一旦您更新了配置檔案,您可能也需要重新啟動 containerdsystemctl 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

  1. 在您的每個節點上,依照 安裝 Docker Engine 的說明,為您的 Linux 發行版安裝 Docker。

  2. 依照說明文件安裝章節中的指示,安裝 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 網站指南

在提出新增額外第三方連結的變更之前,您應該閱讀內容指南

上次修改時間:2024 年 8 月 30 日 凌晨 12:05 PST:移除已關閉 containerd issue 的參考 (0909e130d6)