引言

這兩天也不知道分享什么好了，其實有很多面試題都可以分享，學(xué)習(xí)，今天的文章也可以讓你有更多的成長。

最后有面試群，大家有興趣可以加入。

開始

1. 什么是 CRI（Container Runtime Interface）？

CRI（Container Runtime Interface）是 Kubernetes 定義的一個接口，目的是為了實現(xiàn)容器的運行時抽象，使得 Kubernetes 能夠支持多種不同的容器運行時（如 Docker、containerd、CRI-O 等）。CRI 是 Kubernetes 的一個關(guān)鍵組件，它提供了一種標(biāo)準(zhǔn)化的方式來讓 Kubernetes 與不同的容器運行時交互。

? 容器運行時（Container Runtime）： 負(fù)責(zé)創(chuàng)建和管理容器的組件，它直接與操作系統(tǒng)交互，執(zhí)行容器的生命周期管理。

? CRI 的作用： 通過定義一個統(tǒng)一的接口，允許 Kubernetes 與容器運行時之間進(jìn)行通信和交互，從而支持不同類型的容器運行時。

2. CRI 的常見實現(xiàn)有哪些？

常見的實現(xiàn)包括：

? Docker： 雖然 Docker 在 Kubernetes 中被逐漸替代，但它曾是最常用的容器運行時之一。Docker 支持通過 dockershim 實現(xiàn)與 Kubernetes 的 CRI 兼容。

? containerd： 這是一個由 Docker 提供的容器運行時，后成為獨立項目，并成為 Kubernetes 推薦的容器運行時之一。它提供了基礎(chǔ)的容器生命周期管理功能，如容器的創(chuàng)建、啟動、停止等。

? CRI-O： 這是一個專門為 Kubernetes 設(shè)計的容器運行時，遵循 CRI 規(guī)范。CRI-O 通過提供與 Kubernetes 的直接集成，簡化了容器運行時的功能，去除了 Docker 中的許多非必需功能。

? Frakti： 這是一個為 Kubernetes 提供容器和虛擬機(jī)支持的容器運行時，通過 KVM 提供虛擬化支持。

3. CRI 與 Docker 之間的關(guān)系是什么？

在 Kubernetes 中，Docker 以前通過 dockershim 提供了對 CRI 的支持，但隨著 Kubernetes 1.20 版本的發(fā)布，Docker 支持逐漸被棄用。原因是 Docker 不完全符合 Kubernetes 對容器運行時的要求，尤其是在性能和資源管理方面的靈活性。Kubernetes 推薦使用 containerd 或 CRI-O 來作為容器運行時。

? dockershim： Kubernetes 使用 dockershim 將 Docker 與 Kubernetes 連接在一起，使得 Kubernetes 能夠通過 CRI 與 Docker 進(jìn)行通信。然而，dockershim 在 Kubernetes 1.24 中被完全移除，因此 Kubernetes 現(xiàn)在不再直接支持 Docker 作為容器運行時。

? containerd 和 CRI-O： 這兩個容器運行時符合 CRI 規(guī)范，因此可以直接與 Kubernetes 進(jìn)行集成并作為容器運行時使用。

4. CRI 的工作流程是怎樣的？

CRI 的工作流程可以分為以下幾個步驟：

• Kubernetes 請求容器運行時： Kubernetes 向 CRI 發(fā)出請求，通過 CRI 調(diào)用容器運行時的接口（如創(chuàng)建、啟動、停止容器等）。
•  CRI 調(diào)用容器運行時 API： CRI 通過容器運行時的 API 與容器運行時（如 containerd 或 CRI-O）進(jìn)行交互，管理容器的生命周期。
• 容器運行時操作系統(tǒng)： 容器運行時與操作系統(tǒng)的內(nèi)核進(jìn)行交互，直接管理容器的進(jìn)程和資源，啟動和停止容器。
• 返回結(jié)果給 Kubernetes： 容器運行時完成任務(wù)后，返回狀態(tài)或執(zhí)行結(jié)果給 Kubernetes。

這個流程確保了 Kubernetes 可以在不同的容器運行時之間進(jìn)行無縫切換。

5. Kubernetes 通過 CRI 啟動容器時，哪些信息是必需的？

當(dāng) Kubernetes 通過 CRI 啟動容器時，必須提供以下信息：

? 容器鏡像： 容器運行時需要知道要拉取并使用哪個鏡像。

? 容器的資源需求： 包括 CPU、內(nèi)存等資源的限制。

? 網(wǎng)絡(luò)配置： 如容器的 IP 地址、端口映射等。

? 存儲卷： 容器可能需要掛載一些持久化存儲卷。

? 命令和參數(shù)： 容器啟動時需要執(zhí)行的命令和參數(shù)。

? 容器運行時配置： 如環(huán)境變量、日志、PID 控制等配置項。

6. CRI 的接口包括哪些主要的功能？

CRI 提供了多個功能接口，主要包括：

容器創(chuàng)建和啟動：

? CreateContainer： 創(chuàng)建一個容器。

? StartContainer： 啟動一個已經(jīng)創(chuàng)建的容器。

容器管理：

? StopContainer： 停止一個容器。

? RemoveContainer： 刪除一個容器。

容器狀態(tài)查詢：

? ContainerStatus： 獲取容器的當(dāng)前狀態(tài)。

? ListContainers： 列出當(dāng)前所有運行的容器。

容器日志：

? ContainerLogs： 獲取容器的日志。

容器的健康檢查：

? UpdateContainerResources： 更新容器的資源配置。

? ContainerStats： 獲取容器的資源使用情況，如 CPU、內(nèi)存、磁盤等。

7. Kubernetes 支持哪些容器運行時？

Kubernetes 支持多種容器運行時，主要包括：

? Docker（通過 dockershim，已逐步棄用）

? containerd

? CRI-O

? Frakti（支持虛擬機(jī)容器）

? gVisor（提供額外的安全性，類似沙箱）

? Kata Containers（通過虛擬化實現(xiàn)容器）

從 Kubernetes 1.24 版本開始，Docker 支持逐漸被移除，Kubernetes 推薦使用 containerd 或 CRI-O 作為容器運行時。

8. 為什么 Kubernetes 不再推薦使用 Docker 作為容器運行時？

Kubernetes 不再推薦使用 Docker 作為容器運行時，主要原因有：

? 性能問題： Docker 包含了很多不必要的功能，Kubernetes 只需要容器運行時的基礎(chǔ)功能，如容器的創(chuàng)建、運行和停止，而 Docker 提供了很多額外的功能（如構(gòu)建鏡像、網(wǎng)絡(luò)配置等），這增加了 Kubernetes 的復(fù)雜性。

? 復(fù)雜性： Docker 本身包含很多與 Kubernetes 無關(guān)的組件，如鏡像構(gòu)建、Docker CLI 等，Kubernetes 只需要與容器運行時交互。containerd 和 CRI-O 是更加輕量和專注的容器運行時，它們?nèi)コ伺c容器編排無關(guān)的部分，更適合 Kubernetes 的需求。

? 維護(hù)問題： Docker 是一個完整的容器平臺，包含了從構(gòu)建到運行的完整生命周期，而 containerd 和 CRI-O 僅專注于容器的運行時部分，避免了不必要的復(fù)雜性和依賴。

9. CRI 是如何與 Kubernetes 中的 kubelet 交互的？

kubelet 是 Kubernetes 的一個組件，負(fù)責(zé)與容器運行時交互，確保容器的生命周期管理。kubelet 通過 CRI 與容器運行時進(jìn)行通信，以下是交互過程：

• 創(chuàng)建容器： kubelet 向 CRI 發(fā)起請求，要求創(chuàng)建容器。
• 啟動容器： kubelet 通過 CRI 啟動容器并進(jìn)行管理。
• 監(jiān)控容器： kubelet 通過 CRI 獲取容器的狀態(tài)、資源使用情況等信息。
• 容器健康檢查： kubelet 可以定期向容器運行時請求容器的健康檢查信息，并在容器失敗時采取恢復(fù)操作。

kubelet 作為 Kubernetes 節(jié)點的核心組件，利用 CRI 來實現(xiàn)容器的高效管理與調(diào)度。

10. CRI 是如何與 Kubernetes 中的 Pod 和容器生命周期管理交互的？

CRI（Container Runtime Interface）與 Kubernetes 中的 Pod 和容器生命周期管理緊密結(jié)合。Kubernetes 的 kubelet 通過 CRI 與容器運行時進(jìn)行交互來管理容器的生命周期。主要交互步驟如下：

? Pod 創(chuàng)建： kubelet 通過 CRI 請求容器運行時創(chuàng)建容器。容器運行時會根據(jù) Pod 的配置文件（如容器鏡像、資源限制等）啟動容器。

? 容器啟動： 一旦 Pod 被調(diào)度到節(jié)點，kubelet 會調(diào)用 CRI 中的 CreateContainer 和 StartContainer 接口來啟動容器。

? 資源管理： kubelet 會通過 CRI 獲取容器的資源使用情況（如 CPU、內(nèi)存等），并根據(jù) Pod 的資源請求進(jìn)行調(diào)度和限制。

? 容器停止和刪除： kubelet 會通過 CRI 調(diào)用容器運行時的 StopContainer 和 RemoveContainer 接口，停止并刪除容器。

? 健康檢查： kubelet 使用 CRI 接口中的 ContainerStatus 和 ContainerLogs 來獲取容器的健康狀態(tài)，并進(jìn)行故障恢復(fù)操作。

11. CRI-O 與 containerd 之間有什么區(qū)別，為什么 Kubernetes 推薦使用它們？

CRI-O 和 containerd 都是符合 CRI 規(guī)范的容器運行時，常用于 Kubernetes 集群中。它們的主要區(qū)別和 Kubernetes 推薦使用它們的原因如下：

12. 如何配置 Kubernetes 使用 CRI-O 作為容器運行時？

要將 Kubernetes 配置為使用 CRI-O 作為容器運行時，通常需要進(jìn)行以下步驟：

• 安裝 CRI-O：安裝 CRI-O 并確保它在 Kubernetes 節(jié)點上運行。可以使用發(fā)行版的包管理工具（如 apt、yum）或直接從 GitHub 上安裝預(yù)編譯的二進(jìn)制文件。
• 安裝 CRI-O 之后，啟動并確保它運行正常：

systemctl start crio
systemctl enable crio

• 配置 Kubernetes 使用 CRI-O： Kubernetes 的 kubelet 通過 --container-runtime 參數(shù)指定容器運行時。如果要使用 CRI-O，可以在 kubelet 配置中設(shè)置為 cri-o：
• 編輯 kubelet 的啟動配置文件（如 /etc/default/kubelet）：

KUBELET_EXTRA_ARGS="--container-runtime=remote --container-runtime-endpoint=/var/run/crio/crio.sock"

• 如果你使用的是 kubeadm 來安裝 Kubernetes，可以通過 kubeadm 的配置文件進(jìn)行配置：

apiServer:
  extraArgs:
    container-runtime: remote
    container-runtime-endpoint: /var/run/crio/crio.sock

• 重啟 kubelet 服務(wù)： 配置完成后，重啟 kubelet 服務(wù)，使其使用 CRI-O 作為容器運行時：

systemctl restart kubelet

• 驗證配置： 使用以下命令驗證容器運行時配置是否正確：

kubectl get nodes -o wide

• 如果配置成功，kubelet 會使用 CRI-O 來管理容器。

13. CRI 在容器調(diào)度中的作用是什么？

CRI 在 Kubernetes 中的容器調(diào)度過程中起到了以下作用：

? 容器生命周期管理： CRI 負(fù)責(zé)容器的生命周期管理，包括容器的創(chuàng)建、啟動、停止和刪除等。當(dāng) Kubernetes 調(diào)度一個 Pod 到某個節(jié)點時，kubelet 會通過 CRI 啟動容器，并監(jiān)控其健康狀態(tài)。

? 容器狀態(tài)監(jiān)控： 通過 CRI，kubelet 能夠獲取容器的狀態(tài)和資源使用情況（如 CPU、內(nèi)存等），并將這些信息反饋給 Kubernetes，以便進(jìn)行調(diào)度決策。

? 資源分配與限制： CRI 協(xié)調(diào)容器資源（如內(nèi)存、CPU、存儲等）的分配和限制。kubelet 會通過 CRI 來確保容器不會超出節(jié)點的資源配額。

? 容器健康檢查： CRI 提供了容器健康檢查接口，kubelet 可以定期檢查容器的健康狀態(tài)，并在容器失敗時進(jìn)行重啟或遷移。

14. 什么是 Kubernetes 中的 kubelet 與 CRI 的交互方式？

在 Kubernetes 中，kubelet 是管理容器生命周期的關(guān)鍵組件，它與 CRI 容器運行時接口直接交互，確保容器的啟動、管理和停止等操作。kubelet 通過以下方式與 CRI 進(jìn)行交互：

• 容器創(chuàng)建和啟動： kubelet 會向 CRI 請求創(chuàng)建和啟動容器。它將 Pod 的規(guī)范（如容器鏡像、資源要求等）傳遞給 CRI，CRI 根據(jù)這些信息啟動容器。
• 容器監(jiān)控： kubelet 會定期通過 CRI 獲取容器的狀態(tài)、資源使用情況和健康狀況?；谶@些數(shù)據(jù)，kubelet 會判斷容器是否需要重啟、停止或刪除。
• 容器日志： kubelet 可以通過 CRI 獲取容器的日志信息，并將日志記錄在 Kubernetes 的日志系統(tǒng)中，供用戶調(diào)試和監(jiān)控。
• 健康檢查： kubelet 使用 CRI 的健康檢查功能來檢測容器的健康狀態(tài)，并根據(jù)結(jié)果決定是否需要重新調(diào)度容器。
• 容器停止與刪除： kubelet 會在容器運行完成后，通過 CRI 請求停止并刪除容器，釋放資源。

15. 如何在 Kubernetes 中實現(xiàn)容器的資源限制和 QoS（Quality of Service）？

在 Kubernetes 中，容器的資源限制是通過 Pod 的資源請求和限制來實現(xiàn)的。資源請求和限制會影響容器的 QoS 級別，具體步驟如下：

16. CRI-O 和 containerd 的性能優(yōu)化和調(diào)優(yōu)策略有哪些？

CRI-O 和 containerd 都是符合 CRI 規(guī)范的容器運行時，它們的性能優(yōu)化和調(diào)優(yōu)策略包括：

優(yōu)化容器鏡像拉取

? 鏡像緩存： 通過鏡像緩存機(jī)制，減少重復(fù)拉取相同鏡像的次數(shù)。在 containerd 和 CRI-O 中，可以設(shè)置鏡像拉取的緩存策略，避免每次啟動時都需要從頭開始拉取鏡像。

? 鏡像代理： 使用鏡像代理服務(wù)（如 Harbor 或 Nexus）來緩存常用鏡像，減少對遠(yuǎn)程鏡像倉庫的依賴，提升拉取速度。

容器調(diào)度優(yōu)化

? 資源預(yù)留和限制： 在 containerd 或 CRI-O 配置中，合理設(shè)置容器的資源限制（如 CPU、內(nèi)存、I/O）和優(yōu)先級，避免因資源爭搶導(dǎo)致的容器性能下降。

? CPU 配額： 通過配置容器的 CPU 配額和親和性（cpu-shares, cpuset），確保容器在多節(jié)點集群中高效調(diào)度，減少 CPU 資源的浪費。

性能優(yōu)化

? 存儲優(yōu)化： 使用高效的存儲插件，如 overlay2 文件系統(tǒng)，減少容器 I/O 負(fù)擔(dān)，提高磁盤訪問速度。

? 網(wǎng)絡(luò)性能： 通過調(diào)整容器運行時的網(wǎng)絡(luò)配置（如使用 HostNetwork 模式），減少容器間的網(wǎng)絡(luò)開銷，優(yōu)化網(wǎng)絡(luò)帶寬和延遲。

垃圾回收與清理

? 鏡像垃圾回收： 定期清理不再使用的鏡像和容器，釋放存儲空間，避免磁盤空間的浪費。

? 容器日志管理： 通過日志輪轉(zhuǎn)機(jī)制（如設(shè)置 max-size 和 max-file）避免日志文件過大，影響性能。

容器啟動優(yōu)化

? 使用 Pod 優(yōu)先級 和 調(diào)度策略 來確保關(guān)鍵服務(wù)能夠盡早啟動。

? 配置容器的 init 容器（初始化容器），避免主容器啟動時的阻塞，確保初始化任務(wù)并行執(zhí)行。

17. 如何處理 Kubernetes 中的 CRI 運行時與容器運行時之間的兼容性問題？

Kubernetes 中的容器運行時和 CRI 的兼容性問題可能會在多種情況下出現(xiàn)，例如 Kubernetes 版本升級、容器運行時更新或配置不當(dāng)?shù)?。處理這些問題的策略包括：

使用 kubelet 配置文件

? Kubernetes 提供了 kubelet 配置文件，其中包括關(guān)于 CRI 運行時的詳細(xì)配置項，如 --container-runtime、--container-runtime-endpoint、--image-service-endpoint 等。通過精確設(shè)置這些參數(shù)，可以確保 kubelet 與指定的容器運行時兼容。

版本匹配

? 確保 Kubernetes 版本和容器運行時的版本兼容。例如，containerd 和 CRI-O 的新版本可能會支持新的 CRI 特性，因此需要在 Kubernetes 中確保配置正確的 CRI 版本。

CRIO 和 containerd 的插件機(jī)制

? CRI-O 和 containerd 都提供了插件機(jī)制，可以通過加載不同的插件來擴(kuò)展或修改容器運行時的行為。通過正確配置這些插件，可以解決與容器運行時的兼容性問題。

? 例如，containerd 使用 snapshotter 插件來處理文件系統(tǒng)層（如 overlay2 或 aufs），根據(jù)不同的文件系統(tǒng)來調(diào)整容器運行時的性能。

集成與測試

? 對于多容器運行時環(huán)境（例如同時使用 containerd 和 CRI-O），定期進(jìn)行集成測試，確保 Kubernetes 和容器運行時之間的兼容性。在生產(chǎn)環(huán)境中，進(jìn)行壓力測試來發(fā)現(xiàn)潛在的兼容性問題，并及時修復(fù)。

監(jiān)控與日志

? 利用 Kubernetes 的日志系統(tǒng)和容器運行時日志，快速定位和解決容器運行時與 CRI 的兼容性問題。例如，使用 kubectl logs 查看容器日志，查看 kubelet 和 CRI-O、containerd 等日志，找到潛在的配置或兼容性問題。

18. 如何實現(xiàn) CRI 與 Kubernetes 中的調(diào)度器（Scheduler）的高效集成？

為了確保 CRI 與 Kubernetes 調(diào)度器（Scheduler）高效集成，涉及多個方面的配置和優(yōu)化：

資源請求與調(diào)度優(yōu)化

? Kubernetes 調(diào)度器基于容器的資源請求（如 CPU、內(nèi)存）來進(jìn)行調(diào)度。CRI 需要向 kubelet 提供容器的資源請求信息，調(diào)度器根據(jù)這些信息將容器調(diào)度到適合的節(jié)點上。

? 為了實現(xiàn)高效調(diào)度，容器運行時（如 CRI-O 或 containerd）需要與 kubelet 緊密協(xié)作，確保容器的資源限制與請求正確地傳遞給調(diào)度器。

Pod Affinity/Anti-Affinity

? 在調(diào)度 Pod 時，使用 Pod Affinity 和 Anti-Affinity 配置來確保相關(guān)容器運行在相同節(jié)點或不同節(jié)點上。容器運行時通過支持節(jié)點親和性和拓?fù)渑渲?，幫助調(diào)度器做出高效的決策。

調(diào)度策略與 QoS（Quality of Service）

? Kubernetes 中的 QoS 級別（如 Guaranteed、Burstable、BestEffort）直接影響容器的優(yōu)先級。CRI 需要根據(jù)容器的 QoS 配置來優(yōu)化資源的分配和管理。

? 對于關(guān)鍵業(yè)務(wù)服務(wù)，容器運行時應(yīng)支持資源優(yōu)先級的配置，確保這些容器能夠優(yōu)先獲得資源。

動態(tài)資源調(diào)整與 Pod 重新調(diào)度

? Kubernetes 支持基于資源使用的動態(tài)調(diào)度，容器運行時通過 CRI 接口提供容器的實時資源使用數(shù)據(jù)，幫助調(diào)度器根據(jù)集群的負(fù)載動態(tài)調(diào)整容器調(diào)度。

? 例如，containerd 和 CRI-O 可以提供容器的實時資源使用情況，通過 CRI 接口將其反饋給 kubelet 和調(diào)度器，進(jìn)而執(zhí)行容器的遷移或重調(diào)度。

19. 如何在 CRI 中實現(xiàn)容器運行時的高可用性（HA）？

為了確保容器運行時的高可用性（HA），需要從以下幾個方面入手：

容器運行時的多節(jié)點部署

? 將 CRI 運行時的容器管理服務(wù)（如 containerd、CRI-O）部署在多個節(jié)點上，通過高可用集群架構(gòu)來保證容器運行時的可用性。

? 配置集群級別的負(fù)載均衡，確保容器運行時的請求可以在集群內(nèi)多個節(jié)點間分發(fā)，避免單點故障。

容器運行時的狀態(tài)同步

? 容器運行時應(yīng)支持跨節(jié)點的狀態(tài)同步。例如，containerd 提供了對分布式存儲的支持，確保多個節(jié)點上容器的狀態(tài)信息一致，以便在節(jié)點發(fā)生故障時能夠恢復(fù)容器的運行狀態(tài)。

? 配置共享存儲卷（如 NFS、Ceph），確保容器的持久化數(shù)據(jù)在節(jié)點故障時能夠恢復(fù)。

故障恢復(fù)與自動重啟

? CRI 運行時可以通過支持容器的健康檢查和自動重啟機(jī)制來提高容器的可用性。kubelet 會監(jiān)控容器狀態(tài)，通過 CRI 接口獲取容器健康狀況，自動重啟失敗的容器。

? 配置容器運行時的故障檢測機(jī)制，當(dāng)容器出現(xiàn)故障或不可用時，及時重啟容器并將其恢復(fù)到預(yù)期狀態(tài)。

動態(tài)容器調(diào)度與節(jié)點擴(kuò)展

? 配置 Kubernetes 的自動擴(kuò)容功能，結(jié)合容器運行時的高可用性設(shè)置，當(dāng)集群資源緊張時，自動擴(kuò)展節(jié)點并將負(fù)載均衡到新節(jié)點上。

? 在容器運行時支持容器的動態(tài)遷移和調(diào)度，確保容器在集群中故障恢復(fù)時能夠快速遷移到其他節(jié)點。

20. 如何優(yōu)化 CRI 中容器運行時的 I/O 性能？

優(yōu)化容器運行時的 I/O 性能可以從以下幾個方面著手：

文件系統(tǒng)選擇

? 選擇高性能的存儲驅(qū)動，如 overlay2，該驅(qū)動提供了較高的文件系統(tǒng)性能，特別是在容器鏡像和容器數(shù)據(jù)的 I/O 操作時。

? 使用支持高性能 I/O 操作的存儲插件，如 device-mapper 和 btrfs。

存儲卷優(yōu)化

? 對于需要高性能存儲的容器，使用本地存儲卷（如 local 存儲插件）可以減少 I/O 延遲，提供更高的吞吐量。

? 配置適當(dāng)?shù)木眍愋?，例如使?NFS 協(xié)議的遠(yuǎn)程存儲系統(tǒng)來支持共享存儲需求。

容器磁盤配額與分配

? 配置磁盤 I/O 限制（如 --blkio-weight）來確保容器不會因 I/O 操作過多而影響其他容器的性能。

? 使用 磁盤配額 來分配每個容器的磁盤空間，避免磁盤資源過度占用。

優(yōu)化日志處理

? 對容器日志進(jìn)行優(yōu)化，避免過多的日志寫入影響容器性能。使用外部日志處理系統(tǒng)（如 Fluentd、ELK）來集中管理容器日志。

21. CRI 的配置文件通常位于哪里？如何修改其參數(shù)？

? 路徑：/etc/containerd/config.toml（containerd）或 /etc/crio/crio.conf（CRI-O）。

? 修改后重啟服務(wù)：

systemctl restart containerd  # 或 crio

22. Kubernetes 1.24 移除了 dockershim，如何確保舊集群兼容 Docker？

方案：

? 使用 Mirantis Container Runtime（替代 dockershim）。

? 遷移到 containerd，并確保 Docker 容器鏡像兼容。

23. 如何通過 CRI 查看容器的底層日志？

ctr --namespace=k8s.io containers ls  # 列出容器
ctr --namespace=k8s.io logs <容器ID>

crictl logs <容器ID>

24. 當(dāng) Pod 處于 ContainerCreating 狀態(tài)時，如何排查 CRI 相關(guān)問題？

步驟：

• 查看 Pod 事件：kubectl describe pod <pod-name>。
• 檢查容器運行時日志：

journalctl -u containerd  # 或 crio

• 驗證鏡像拉?。篶rictl pull <image>。
• 如何限制容器運行時的資源使用（如 CPU、內(nèi)存）？

a. Kubernetes 層面： 通過 Pod 的 resources 字段限制。

b.CRI 層面： 配置容器運行時的 Cgroups 參數(shù)（如 containerd 的 config.toml）。

25. 如何配置 containerd 使用私有鏡像倉庫？

修改 config.toml：

[plugins."io.containerd.grpc.v1.cri".registry]
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."my-registry.com"]
      endpoint = ["https://my-registry.com"]
  [plugins."io.containerd.grpc.v1.cri".registry.configs]
    [plugins."io.containerd.grpc.v1.cri".registry.configs."my-registry.com".tls]
      insecure_skip_verify = true  # 跳過 TLS 驗證（可選）

26. CRI 與 OCI（Open Container Initiative）的關(guān)系是什么？

? CRI： 定義 Kubernetes 與容器運行時的交互接口。

? OCI： 定義容器鏡像和運行時的標(biāo)準(zhǔn)（如鏡像格式、運行時規(guī)范 runc）。

? 關(guān)系： CRI 兼容的運行時（如 containerd）通過 OCI 標(biāo)準(zhǔn)管理容器生命周期。

27. 如何優(yōu)化 CRI 的性能以支持高密度容器部署？

? 啟用容器運行時緩存（如 containerd 的快照機(jī)制）。

? 調(diào)整并發(fā)拉取鏡像的線程數(shù)（max_concurrent_downloads）。

? 使用高性能存儲驅(qū)動（如 overlay2）。