麒麟云容器运行时优化之容器停止优化

在应用容器化部署的大趋势下，特别是在大规模容器部署和管理的场景下，服务的部署和自愈都会频繁创建销毁容器。容器停止操作的性能对于提升容器管理系统的效率至关重要。CRI-O 是在 Kubernetes CRI 标准提出后，RedHat 开发的一个轻量高效、仅为 Kubernetes 所用的容器运行时，CRI-O 已成为 Kubernetes 广泛采用的容器运行时组件。RedHat 在其容器云产品 Openshift 的最新版中已默认采用 CRI-O 做为容器运行时。麒麟云团队对 CRI-O 停止容器的过程进行了深入的分析，提出了一些优化的方法。测试结果表明，优化后停止容器的速度实现了约 33%的提升。本文将详细介绍这些优化策略的具体细节、实施方法，并展示优化后的性能对比结果。优化基于 CRI-O1.24.5 版本。

1 容器停止分析

将容器完全删除需要执行两步操作，停止和移除。停止指的是停止容器进程，而移除阶段负责清理容器残余信息和回收资源。经过 bucketbench 测试，发现移除只需 20ms 左右，而停止需要 600ms 左右。所以删除容器优化重点在停止操作。CRI-O 停止容器较为简单，需要运行 PreStop 的 hook 函数，调用 OCI 的 StopContainer 接口。在确保容器停止后，卸载容器镜像目录。最后更新容器状态并持久化。即对于 CRI-O，容器停止可以分为主要的四部分。

1. 运行 prestop 的 hook 函数

2. 同步调用 OCI 的 StopContainer 接口并检查容器直到容器停止

3. 卸载容器镜像目录

4. 更新容器状态并持久化

测试发现第一步耗时很低，而 prestop 的钩子函数根据业务容器注解信息按需调用。业务差异较大，测试时暂不考虑。第二步耗时占比较大，存在优化空间。第三，四步，受硬件性能影响较大，磁盘性能越好，耗时占比越小。于是主要针对第二步进行优化。

容器停止还会对 pause 状态的容器先进行 unpause 操作再进行 stop。属于 pause 接口优化内容，不属于容器停止优化范畴。下文将其省略。

图 1 CRI-O容器停止序列图

2 缩短轮询周期

CRI-O 调用 OCI 的 StopContainer 接口之后会创建协程以 100ms 为周期，查询容器进程是否停止。100ms 的周期是 CRI-O 为了通用性的考虑，但在 KylinV10 系统的物理环境下，影响了整个 Stop 的表现。考虑到协程运行的开销很低，并且在首次查询时一定会不满足 if 条件而进行 100ms 的等待。因此我们缩短了轮询周期，以提高 Stop 速度。

3 移除非必要函数调用

CRI-O 在调用完 OCI 的 StopContainer 接口后，会始终调用 UpdateContainerStatus 来刷新容器状态。后续持久化容器状态也会调用该函数进行容器状态刷新，前后两次调用之间没有需要依赖容器状态进行的处理，属于重复调用，可以移除这些不必要的 UpdateContainerStatus 调用。进一步研究发现，UpdateContainerStatus 代码逻辑存在问题，会重复调用不必要 OCI 的 State 接口。如下方代码所示，UpdateContainerStatus 存在两次 stateCmd 调用，如果第一次返回的容器状态为 ContainerStateStopped，会继续进行第二次调用。有两种情况，使得 stateCmd 返回容器状态为 ContainerStateStopped，一种是调用 OCI 的 state 接口，正常返回容器当前状态为 ContainerStateStopped，另一种是调用 OCI 的 state 接口出错，强制设置容器状态为 ContainerStateStopped。

第一种情况，OCI 的 State 返回容器状态如果是 ContainerStateStopped 状态，再运行第二次，仍然会是 ContainerStateStopped 状态，因为容器不会从 ContainerStateStopped 恢复成 running 或者其他状态。容器只有四种状态，Created，Paused，Running，Stopped。Stopped 已经是最后的状态。

第二种情况，如果是 OCI 出错，canReturn 已经跳过后续第二次调用。不会执行后续第二次 stateCmd 代码。所以第二次的 stateCmd 调用可以去除。

4 性能对比

在搭载了 KylinV10 系统的 FT-2000+物理环境中，使用 bucketbench 测试不同线程数 Stop 总计 100 个 Pod 的结果如下（耗时为 Sandbox 与 Container 二者之和）。在单线程下与优化前相比提高了约 33%的停止速度。当并发数提高时，优化效果将减弱，这主要是因为并发数提高后不可避免的出现部分锁等待，资源抢占的情况。

图 2 CRI-O容器停止速度对比图

银河麒麟云原生操作系统是麒麟软件面向云原生场景，为支撑云原生应用而全新打造的一款操作系统产品。云原生应用对操作系统有更多的功能需求和特殊的性能需求，如容器编排，集群调度，服务发现，负载均衡，弹性伸缩，资源隔离，快速容器创建，低延迟容器网络等。同时，在云原生应用编排领域，kubernetes 已成为业界的事实标准。银河麒麟云原生操作系统采用"内核+操作系统+kubernetes"的联合设计思想，在传统操作系统接口外，为云原生应用提供 kubernetes 扩展 API，支持操作系统集群粒度统一纳管，支持一致性发布和原子回滚。在容器调度，容器网络，容器运行时等关键组件进行深入优化，致力打造国产平台容器性能标杆。银河麒麟云原生操作系统已运用于银行和证券领域。