从容器到调度，面试官爱问的 CRI 题，你掌握了吗？

引言

最近一直在思考该分享些什么，其实手头有不少面试题可以探讨和学习。希望今天的文章能为大家带来新的收获和成长。

---

开始

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

CRI（Container Runtime Interface） 是 Kubernetes 定义的标准接口，旨在对容器运行时进行抽象，以便 Kubernetes 能够兼容多种不同的容器运行时（如 Docker、containerd、CRI-O 等）。CRI 作为 Kubernetes 关键组件，提供了一种标准化的方式，使 Kubernetes 能够与各种容器运行时进行交互。

• 容器运行时（Container Runtime）： 负责创建和管理容器的核心组件，直接与操作系统交互，执行容器的生命周期管理。
• CRI 的作用： 通过定义统一的接口，使 Kubernetes 能够与不同的容器运行时进行通信，从而实现灵活的运行时支持。

2. CRI 的常见实现有哪些？

目前，常见的 CRI 实现包括：

• Docker： 虽然 Kubernetes 逐步减少对 Docker 的直接支持，但它曾是最流行的容器运行时。Docker 通过 dockershim 适配 Kubernetes 的 CRI 接口。
• containerd： 由 Docker 项目孵化并独立发展的容器运行时，现已成为 Kubernetes 推荐的默认运行时之一。它提供了容器的基本生命周期管理功能，如创建、启动、停止等。
• CRI-O： 专为 Kubernetes 设计的轻量级容器运行时，严格遵循 CRI 规范，去除了 Docker 中许多非必要功能，专注于与 Kubernetes 的无缝集成。
• Frakti： 一个支持容器和虚拟机混合运行的容器运行时，利用 KVM 提供虚拟化能力。

3. CRI 与 Docker 之间的关系是什么？

在早期，Kubernetes 通过 dockershim 适配 Docker 以支持 CRI。然而，自 Kubernetes 1.20 版本起，官方逐步废弃对 dockershim 的支持，并在 Kubernetes 1.24 版本中彻底移除。这是因为 Docker 并非专为 Kubernetes 设计，其架构存在额外的开销，影响了资源管理的灵活性。官方推荐使用 containerd 或 CRI-O 作为 Kubernetes 的默认容器运行时。

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

CRI 的工作流程主要包括以下几个步骤：

1. Kubernetes 通过 CRI 请求容器运行时：kubelet 发送请求，要求执行容器相关操作（如创建、启动、停止等）。
2. CRI 调用容器运行时 API：CRI 将请求转发给底层的容器运行时（如 containerd 或 CRI-O），并执行相应的操作。
3. 容器运行时与操作系统交互：运行时管理容器的进程、资源分配，并与宿主机内核进行交互。
4. 返回执行结果给 Kubernetes：运行时完成任务后，将状态或执行结果反馈给 Kubernetes。

该流程确保 Kubernetes 能够兼容多种容器运行时，并提供一致的管理体验。

5. Kubernetes 通过 CRI 启动容器时，必须提供哪些信息？

Kubernetes 通过 CRI 启动容器时，必须提供以下关键信息：

• 容器镜像：指定要拉取的镜像。
• 资源需求：包括 CPU、内存等资源限制。
• 网络配置：IP 地址、端口映射等。
• 存储卷：持久化存储的挂载信息。
• 命令和参数：容器启动时执行的命令及参数。
• 运行时配置：环境变量、日志管理、PID 控制等。

6. CRI 的主要接口有哪些？

CRI 主要提供以下接口：

• 容器管理：

  • CreateContainer：创建容器
  • StartContainer：启动容器
  • StopContainer：停止容器
  • RemoveContainer：删除容器

• 状态查询：

  • ContainerStatus：获取容器状态
  • ListContainers：列出当前所有容器

• 日志管理：

  • ContainerLogs：获取容器日志

• 资源管理：

  • UpdateContainerResources：更新容器资源配置
  • ContainerStats：获取 CPU、内存、磁盘等资源使用情况

7. Kubernetes 支持哪些容器运行时？

Kubernetes 兼容多个容器运行时，包括：

• Docker（已弃用）
• containerd（推荐）
• CRI-O（推荐）
• Frakti（支持虚拟机容器）
• gVisor（提供额外安全隔离）
• Kata Containers（基于虚拟化技术）

8. 为什么 Kubernetes 不再推荐 Docker 作为容器运行时？

主要原因如下：

• 性能优化：Docker 额外包含镜像构建、网络管理等功能，而 Kubernetes 只需容器运行时的核心能力。
• 架构复杂性：Docker 依赖 dockershim 作为中间层，而 containerd 和 CRI-O 直接实现 CRI，架构更简洁高效。
• 官方支持：Kubernetes 团队专注于维护 CRI 兼容的容器运行时，如 containerd 和 CRI-O，减少维护开销。

9. CRI-O 和 containerd 的区别是什么？

两者都是符合 CRI 规范的容器运行时，主要区别如下：

运行时	特点
CRI-O	轻量级，专为 Kubernetes 设计，无额外功能
containerd	由 Docker 分离而来，支持更广泛的容器工作负载

推荐使用它们的原因：

• 轻量级，避免额外的功能开销
• 更高效，减少 Kubernetes 资源消耗
• 社区支持稳定，深度集成 Kubernetes

10. 如何配置 Kubernetes 使用 CRI-O？

1. 安装 CRI-O：

   sudo apt install cri-o  # Ubuntu
   sudo yum install cri-o  # CentOS
   

2. 启动并启用 CRI-O：

   systemctl start crio
   systemctl enable crio
   

3. 配置 kubelet 使用 CRI-O： 在 /etc/default/kubelet 文件中添加：

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

4. 如果使用 kubeadm 部署 Kubernetes： 编辑 kubeadm 配置：

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

5. 重启 kubelet：

   systemctl restart kubelet
   

6. 验证运行时是否生效：

   kubectl get nodes -o wide
   

13. CRI 在容器调度中的作用是什么？

在 Kubernetes 的容器调度过程中，CRI（Container Runtime Interface）发挥着以下关键作用：

• 容器生命周期管理： CRI 负责容器的创建、启动、停止和删除。当 Kubernetes 调度一个 Pod 到某个节点时，kubelet 通过 CRI 启动容器，并持续监控其运行状态。
• 容器状态监控： kubelet 通过 CRI 获取容器的状态和资源使用情况（如 CPU、内存等），并将这些信息反馈给 Kubernetes，以辅助调度决策。
• 资源分配与限制： CRI 负责协调容器资源（CPU、内存、存储等）的分配与限制，确保容器不会超出节点的资源配额。
• 容器健康检查： CRI 提供健康检查接口，kubelet 可定期检查容器状态，并在容器失败时触发重启或迁移。

14. Kubernetes 中 kubelet 与 CRI 的交互方式

kubelet 是 Kubernetes 中管理容器生命周期的核心组件，它通过 CRI 直接与容器运行时交互，以确保容器的正常运行。主要交互方式包括：

1. 容器创建和启动： kubelet 通过 CRI 发送 Pod 规范（如容器镜像、资源要求等），CRI 解析后启动相应的容器。
2. 容器状态监控： kubelet 定期调用 CRI，获取容器状态、资源使用情况及健康状态，并据此决定是否重启、停止或删除容器。
3. 容器日志管理： kubelet 通过 CRI 获取容器日志，并整合到 Kubernetes 日志系统，便于调试与监控。
4. 健康检查： kubelet 依赖 CRI 的健康检查机制，确保容器运行状态正常，并在异常时触发自动恢复。
5. 容器停止与删除： 当 Pod 终止或迁移时，kubelet 通过 CRI 请求停止并清理容器，释放资源。

15. 如何在 Kubernetes 中实现容器的资源限制和 QoS（Quality of Service）？

在 Kubernetes 中，资源限制通过 Pod 规范的 requests（请求）和 limits（限制）字段进行定义，并影响 QoS 级别：

1. 资源请求与限制

• requests（请求）： 设定容器启动时所需的最小资源量，Kubernetes 以此进行调度。
• limits（限制）： 设定容器可使用的最大资源量，超出限制时容器可能会被 OOM（Out of Memory）杀死。

2. QoS（质量服务）级别

Kubernetes 根据 requests 和 limits 的设置，为 Pod 分配 QoS 级别：

• Guaranteed（保证）： requests 与 limits 相等，容器的资源得到完全保证。
• Burstable（弹性）： requests 小于 limits，容器在资源富余时可使用额外资源，但在资源紧张时可能会受到限制。
• BestEffort（尽力而为）： 未设置 requests 和 limits，此类容器优先级最低，可能最先被驱逐。

通过 CRI，kubelet 依据这些配置来管理容器的资源使用，确保资源分配合理。

16. CRI-O 和 containerd 的性能优化策略

CRI-O 和 containerd 是符合 CRI 规范的主流容器运行时，它们的性能优化策略主要包括：

1. 镜像拉取优化

• 镜像缓存： 通过镜像缓存减少重复拉取，提高启动速度。
• 镜像代理： 使用本地镜像代理（如 Harbor、Nexus）缓存常用镜像，降低对远程仓库的依赖。

2. 容器调度优化

• 资源分配优化： 合理配置 CPU、内存、I/O 限制，避免资源争抢。
• CPU 亲和性设置： 通过 cpu-shares 和 cpuset 控制 CPU 资源分配，提高调度效率。

3. 存储与 I/O 优化

• 使用高效存储驱动： overlay2 提供更好的文件系统性能，减少 I/O 负担。
• 日志优化： 采用日志轮转机制（max-size、max-file），防止日志文件过大影响性能。

4. 运行时垃圾回收

• 定期清理无用镜像和容器： 释放存储空间，防止磁盘占用过高。
• 高效日志管理： 结合 Fluentd、ELK 进行日志集中存储，减少本地日志占用。

17. 如何解决 Kubernetes 中 CRI 运行时的兼容性问题？

为确保 Kubernetes 版本、CRI 运行时（如 containerd、CRI-O）和底层容器技术（如 runc）的兼容性，可以采取以下措施：

• 正确配置 kubelet： 在 /etc/kubernetes/kubelet.conf 或命令行参数中指定 --container-runtime-endpoint，确保 kubelet 能正确连接 CRI 运行时。
• 版本匹配： 确保 Kubernetes、CRI 运行时与 OCI 组件（如 runc）版本兼容。
• 使用插件扩展： containerd 和 CRI-O 支持插件机制，可通过插件增强兼容性。
• 定期测试与监控： 结合 CI/CD 流程，在版本更新前进行兼容性测试，确保 Kubernetes 与 CRI 运行时稳定协作。

18. 如何优化 CRI 与 Kubernetes 调度器的集成？

• 高效资源调度： CRI 运行时需向 kubelet 提供准确的资源信息，调度器据此进行合理分配。
• Pod 亲和性与反亲和性： 通过 nodeAffinity 和 podAffinity 提高调度灵活性。
• 动态调度与重调度： kubelet 依赖 CRI 获取容器实时资源数据，以便调度器优化 Pod 迁移和负载均衡。

19. 如何实现 CRI 运行时的高可用性（HA）？

• 多节点部署： 在多个节点上运行 containerd 或 CRI-O，并配置负载均衡以防止单点故障。
• 状态同步： 采用共享存储（如 NFS、Ceph），确保容器状态在多个节点间保持一致。
• 自动故障恢复： 结合 kubelet 的健康检查机制，自动重启异常容器，确保业务连续性。

20. 如何优化 CRI 容器运行时的 I/O 性能？

• 使用 overlay2 存储驱动，提升文件系统性能。
• 优化日志写入，减少磁盘 I/O 开销，使用 Fluentd 或 ELK 进行集中日志管理。
• 采用高性能存储卷，使用本地 SSD 或分布式存储（如 Ceph）提升存取速度。

结语

本文深入解析了 CRI 在 Kubernetes 容器调度、资源管理、兼容性优化等方面的作用及优化策略，希望对您的面试准备有所帮助。祝您顺利通过面试！