Kubernetes 容器運(yùn)行時(shí)

容器運(yùn)行時(shí)

你需要在集群內(nèi)每個(gè)節(jié)點(diǎn)上安裝一個(gè) 容器運(yùn)行時(shí) 以使 Pod 可以運(yùn)行在上面。本文概述了所涉及的內(nèi)容并描述了與節(jié)點(diǎn)設(shè)置相關(guān)的任務(wù)。

Kubernetes 1.24 要求你使用符合容器運(yùn)行時(shí)接口 (CRI)的運(yùn)行時(shí)。

有關(guān)詳細(xì)信息，請(qǐng)參閱該文的 CRI 版本支持。 本頁(yè)簡(jiǎn)要介紹在 Kubernetes 中幾個(gè)常見的容器運(yùn)行時(shí)的用法。

• ?containerd ?
• ?CRI-O ?
• ?Docker Engine ?
• ?Mirantis Container Runtime?

Note:
提示：v1.24 之前的 Kubernetes 版本包括與 Docker Engine 的直接集成，使用名為 dockershim 的組件。 這種特殊的直接整合不再是 Kubernetes 的一部分 （這次刪除被作為 v1.20 發(fā)行版本的一部分宣布）。 
如果你正在運(yùn)行 v1.24 以外的 Kubernetes 版本，檢查該版本的文檔。

安裝和配置先決條件

以下步驟將通用設(shè)置應(yīng)用于 Linux 上的 Kubernetes 節(jié)點(diǎn)。

如果你確定不需要某個(gè)特定設(shè)置，則可以跳過它。

轉(zhuǎn)發(fā) IPv4 并讓 iptables 看到橋接流量

通過運(yùn)行 ?lsmod | grep br_netfilter? 來驗(yàn)證 ?br_netfilter? 模塊是否已加載。

若要顯式加載此模塊，請(qǐng)運(yùn)行 ?sudo modprobe br_netfilter?。

為了讓 Linux 節(jié)點(diǎn)的 iptables 能夠正確查看橋接流量，請(qǐng)確認(rèn) ?sysctl ?配置中的 ?net.bridge.bridge-nf-call-iptables? 設(shè)置為 1。 例如：

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# 設(shè)置所需的 sysctl 參數(shù)，參數(shù)在重新啟動(dòng)后保持不變
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# 應(yīng)用 sysctl 參數(shù)而不重新啟動(dòng)
sudo sysctl --system

Cgroup 驅(qū)動(dòng)程序 

在 Linux 上，控制組（CGroup）用于限制分配給進(jìn)程的資源。

當(dāng)某個(gè) Linux 系統(tǒng)發(fā)行版使用 systemd 作為其初始化系統(tǒng)時(shí)，初始化進(jìn)程會(huì)生成并使用一個(gè) root 控制組（?cgroup?），并充當(dāng) cgroup 管理器。 Systemd 與 cgroup 集成緊密，并將為每個(gè) systemd 單元分配一個(gè) cgroup。 你也可以配置容器運(yùn)行時(shí)和 kubelet 使用 ?cgroupfs?。 連同 systemd 一起使用 ?cgroupfs ?意味著將有兩個(gè)不同的 cgroup 管理器。

單個(gè) cgroup 管理器將簡(jiǎn)化分配資源的視圖，并且默認(rèn)情況下將對(duì)可用資源和使用 中的資源具有更一致的視圖。 當(dāng)有兩個(gè)管理器共存于一個(gè)系統(tǒng)中時(shí)，最終將對(duì)這些資源產(chǎn)生兩種視圖。 在此領(lǐng)域人們已經(jīng)報(bào)告過一些案例，某些節(jié)點(diǎn)配置讓 kubelet 和 docker 使用 ?cgroupfs?，而節(jié)點(diǎn)上運(yùn)行的其余進(jìn)程則使用 systemd; 這類節(jié)點(diǎn)在資源壓力下 會(huì)變得不穩(wěn)定。

更改設(shè)置，令容器運(yùn)行時(shí)和 kubelet 使用 ?systemd ?作為 cgroup 驅(qū)動(dòng)，以此使系統(tǒng)更為穩(wěn)定。 對(duì)于 Docker, 設(shè)置 ?native.cgroupdriver=systemd? 選項(xiàng)。

注意：更改已加入集群的節(jié)點(diǎn)的 cgroup 驅(qū)動(dòng)是一項(xiàng)敏感的操作。 如果 kubelet 已經(jīng)使用某 cgroup 驅(qū)動(dòng)的語(yǔ)義創(chuàng)建了 pod，更改運(yùn)行時(shí)以使用 別的 cgroup 驅(qū)動(dòng)，當(dāng)為現(xiàn)有 Pods 重新創(chuàng)建 PodSandbox 時(shí)會(huì)產(chǎn)生錯(cuò)誤。 重啟 kubelet 也可能無(wú)法解決此類問題。 如果你有切實(shí)可行的自動(dòng)化方案，使用其他已更新配置的節(jié)點(diǎn)來替換該節(jié)點(diǎn)， 或者使用自動(dòng)化方案來重新安裝。

Cgroup v2

Cgroup v2 是 cgroup Linux API 的下一個(gè)版本。與 cgroup v1 不同的是， Cgroup v2 只有一個(gè)層次結(jié)構(gòu)，而不是每個(gè)控制器有一個(gè)不同的層次結(jié)構(gòu)。

新版本對(duì) cgroup v1 進(jìn)行了多項(xiàng)改進(jìn)，其中一些改進(jìn)是：

• 更簡(jiǎn)潔、更易于使用的 API
• 可將安全子樹委派給容器
• 更新的功能，如壓力失速信息（Pressure Stall Information）

盡管內(nèi)核支持混合配置，即其中一些控制器由 cgroup v1 管理，另一些由 cgroup v2 管理， Kubernetes 僅支持使用同一 cgroup 版本來管理所有控制器。

如果 systemd 默認(rèn)不使用 cgroup v2，你可以通過在內(nèi)核命令行中添加 ?systemd.unified_cgroup_hierarchy=1? 來配置系統(tǒng)去使用它。

# 此示例適用于使用 DNF 包管理器的 Linux 操作系統(tǒng)
# 你的系統(tǒng)可能使用不同的方法來設(shè)置 Linux 內(nèi)核使用的命令行。
sudo dnf install -y grubby && \
  sudo grubby \
  --update-kernel=ALL \
  --args="systemd.unified_cgroup_hierarchy=1"

如果更改內(nèi)核的命令行，則必須重新啟動(dòng)節(jié)點(diǎn)才能使更改生效。

切換到 cgroup v2 時(shí)，用戶體驗(yàn)不應(yīng)有任何明顯差異， 除非用戶直接在節(jié)點(diǎn)上或在容器內(nèi)訪問 cgroup 文件系統(tǒng)。 為了使用它，CRI 運(yùn)行時(shí)也必須支持 cgroup v2。

將 kubeadm 托管的集群遷移到 systemd 驅(qū)動(dòng)

如果你希望將現(xiàn)有的由 kubeadm 管理的集群遷移到 systemd cgroup 驅(qū)動(dòng)程序， 請(qǐng)按照配置 cgroup 驅(qū)動(dòng)程序操作。

CRI 版本支持

你的容器運(yùn)行時(shí)必須至少支持容器運(yùn)行時(shí)接口的 v1alpha2。

Kubernetes 1.24 默認(rèn)使用 v1 的 CRI API。如果容器運(yùn)行時(shí)不支持 v1 API， 則 kubelet 會(huì)回退到使用（已棄用的）v1alpha2 API。

容器運(yùn)行時(shí) 

containerd

本節(jié)概述了使用 containerd 作為 CRI 運(yùn)行時(shí)的必要步驟。

使用以下命令在系統(tǒng)上安裝 Containerd：

按照開始使用 containerd 的說明進(jìn)行操作。 創(chuàng)建有效的配置文件 ?config.toml? 后返回此步驟。

• Linux

你可以在路徑 ?/etc/containerd/config.toml? 下找到此文件。

• Windows

你可以在路徑 `?C:\Program Files\containerd\config.toml?` 下找到此文件。

在 Linux 上，containerd 的默認(rèn) CRI 套接字是 ?/run/containerd/containerd.sock?。 在 Windows 上，默認(rèn) CRI 端點(diǎn)是 ?npipe://./pipe/containerd-containerd?。

配置 systemd cgroup 驅(qū)動(dòng)程序

結(jié)合 ?runc ?使用 ?systemd ?cgroup 驅(qū)動(dòng)，在 ?/etc/containerd/config.toml? 中設(shè)置

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
  ...
  [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
    SystemdCgroup = true

如果你應(yīng)用此更改，請(qǐng)確保重新啟動(dòng) containerd：

sudo systemctl restart containerd

當(dāng)使用 kubeadm 時(shí)，請(qǐng)手動(dòng)配置 kubelet 的 cgroup 驅(qū)動(dòng).

CRI-O

本節(jié)包含安裝 CRI-O 作為容器運(yùn)行時(shí)的必要步驟。

要安裝 CRI-O，請(qǐng)按照 CRI-O 安裝說明執(zhí)行操作。

cgroup 驅(qū)動(dòng)程序

CRI-O 默認(rèn)使用 systemd cgroup 驅(qū)動(dòng)程序，這對(duì)你來說可能工作得很好。要切換到 ?cgroupfs ?cgroup 驅(qū)動(dòng)程序， 請(qǐng)編輯 ?/etc/crio/crio.conf? 或在 ?/etc/crio/crio.conf.d/02-cgroup-manager.conf? 中放置一個(gè)插入式配置 ，例如：

[crio.runtime]
conmon_cgroup = "pod"
cgroup_manager = "cgroupfs"

你還應(yīng)該注意到 ?conmon_cgroup ?被更改，當(dāng)使用 CRI-O 和 ?cgroupfs ?時(shí)，必須將其設(shè)置為值 ?pod?。 通常需要保持 kubelet 的 cgroup 驅(qū)動(dòng)配置（通常通過 kubeadm 完成）和 CRI-O 同步。

對(duì)于 CRI-O，CRI 套接字默認(rèn)為 ?/var/run/crio/crio.sock?。

Docker Engine

Note: 以下操作假設(shè)你使用 cri-dockerd 適配器來將 Docker Engine 與 Kubernetes 集成。

1. 在你的每個(gè)節(jié)點(diǎn)上，遵循安裝 Docker 引擎指南為你的 Linux 發(fā)行版安裝 Docker。
2. 按照源代碼倉(cāng)庫(kù)中的說明安裝 cri-dockerd。

對(duì)于 ?cri-dockerd?，默認(rèn)情況下，CRI 套接字是 ?/run/cri-dockerd.sock?。

Mirantis 容器運(yùn)行時(shí)

Mirantis Container Runtime (MCR) 是一種商用容器運(yùn)行時(shí)，以前稱為 Docker 企業(yè)版。 你可以使用 MCR 中包含的開源 ?cri-dockerd? 組件將 Mirantis Container Runtime 與 Kubernetes 一起使用。

要了解有關(guān)如何安裝 Mirantis Container Runtime 的更多信息，請(qǐng)?jiān)L問 MCR 部署指南。

檢查名為 ?cri-docker.socket? 的 systemd 單元以找出 CRI 套接字的路徑。