vertical是什么意思中文,verticalsync

　　 　　

　　

　　云原生为从业者指出了充分利用云的能力和价值的最佳途径，如今已经成为企业数字化转型的必由之路。随着云计算的普及，企业应用容器化的趋势已经不可阻挡，它面临着以下重要问题：如何解决激增的流量负载与资源容量规划之间的矛盾？如何平衡成本和系统可用性？ 　　

　　

　　集装箱扩容是解决上述问题的关键。扩展的重点是如何在负载突然增加的情况下，通过调整集装箱集群的规模来提高集装箱集群的承载能力，从而提升用户体验，保证系统服务的高可用性。目前最常用的策略是增加容器副本的数量来提高系统的整体处理能力，即容器横向扩展，但它只适用于无状态服务，而不适用于一些有状态服务(如数据库服务、消息队列等中间件应用)。另一种常见的策略是通过提高单个集装箱的处理能力来提高系统的整体处理能力，即集装箱的纵向扩展。容器的垂直扩展虽然可以快速调整容器资源限制，但是会影响业务的连续性，这对于应用来说是不可接受的，尤其是7*24小时关键支持的应用。 　　

　　

　　目前行业内还没有成熟的集装箱在线垂直扩容方案。有鉴于此，工商银行在没有任何行业经验借鉴的情况下，积极探索，率先在同行业实现了集装箱的纵向扩展，既平衡了资源成本和系统可用性，又有效缓解了激增的流量负荷与资源容量规划之间的矛盾。 　　

　　

　　一、行业现状 　　

　　

　　据调查，大型互联网公司(如亚马逊、谷歌、IBM等。)在容器的垂直扩展方面进行了很多实践(如表1所示)。实现容器的垂直扩展主要有两种方式：垂直Pod Autoscaler(VPA)和修改Kubernetes源代码。其中，VPA可以根据容器资源的利用率自动设置CPU和内存的软硬限制，为每个容器提供合适的资源，但容器需要重建。修改Kubernetes源代码可以保证容器的在线扩展，但是对Kubernetes源代码的侵入性很大，对后续的Kubernetes版本升级影响很大，对现有版本的影响需要进一步评估。 　　

　　

　　 　　

　　

　　表1行业主流垂直扩张方案 　　

　　

　　二。中国工商银行在集装箱纵向拓展领域的探索与应用 　　

　　

　　中国工商银行自主研发建设基于Docker和Kubernetes架构的PaaS云平台，现已承载200多个应用和20多万个常用应用容器。与此同时，工商银行在中间件容器领域积极探索，已实现覆盖MySQL、Redis、ElasticSearch、ZooKeeper等有状态应用的容器化部署，其中MySQL容器上云率达到90%以上。 　　

　　

　　随着容器类型和规模的不断扩大，资源利用和服务的高可用性在上云后变得尤为重要，而容器的在线垂直扩展是保证应用服务高可用性的重要手段和措施。 　　

　　

　　2.1积极研究和探索创新思路，并开始进行实际案例验证。 　　

　　

　　经过对行业现状的调研，明确行业现有方案无法满足需求，工行提出了线上容器拓展的探索思路，并进行了案例验证： 　　

　　

　　创建一个QoS等级为保证的Pod(规格：2C4G)。根据docker stats containerId，此时容器的内存限制和容器的Cgroup限制(如图1所示)都相等，都是399997952 KB (3.725 GB)。 　　

　　

　　 　　

　　

　　图1容器内存限制的屏幕截图 　　

　　

　　使用docker update命令将内存限制修改为8G，Docker Update-Memory 799995904-Memory-Swap-1，检查此时主机上的container Cgroup的值已经修改为8G(如图2所示)。此时，容器限制已经被修改，并且容器在该过程中没有被重新启动。 　　

　　

　　 　　

　　

　　图2屏幕截图 　　

　　

　　2.2透析容器资源限制原则，明确容器参数调整措施。 　　

　　

　　随着 　　

2.1 节末尾遗留的问题，工商银行对于 Pod 的创建流程（如图 3 所示）及 K8s 源码展开了深入地研究：

　　

　　 　　

图 3 Pod 创建流程图

　　

用户向 API Server 发起一个 Pod 创建请求，API Server 接收请求后，将 PodSpec 写入 ETCD。Scheduler 通过查看 ETCD 中存储的信息，找到宿主机信息为空的 Pod，并进行调度计算，找到最合适的宿主机，然后将信息更新至 ETCD 中的 PodSpec。Kubelet 通过定期监测 ETCD，找到分配给自己的 Pod，即 ETCD 中与自身 IP 相同的 PodSpec 记录，紧接着就调用 Docker 和创建 Pod，并在 Docker 的配置文件中添加一个 PodSpec 的 Hash 值的标注。

　　

通过 Pod 的创建流程可以发现，Pod 的最终创建是由 Kubelet 来处理，于是就根据容器 id 关键字查找 Kubelet 日志，可以看到如下信息：“Container spec hash changed (1073425520 vs 2818111920)..Container will be killed and recreated”。

　　

　　

日志表明容器的 hash 值已经发生变化，容器将会重启，倒推至 K8s 源码位于 pkg/kubelet/kuberuntime/kuberuntime_manager.go 中的 computePodActions 方法（如图 4 所示），该方法是用来计算 PodSpec 的哈希值是否发生变化，内部则是调用 containerChanged 方法（如图 5 所示）决定了容器是否需要重启。

　　

　　 　　

图 4 computePodActions 方法源码截图

　　 　　

图 5 containerChanged 方法源码截图

　　

可以清楚地看到只要 v1.Container 的任何一个字段发生改变都会导致期望的容器 hash 值变化。如果 hash 值变化则返回 true，告知 Kubelet SyncPod 方法（如图 6 所示）触发 Pod 内容器重建或者 Pod 重建。SyncPod 通过以下步骤完成保证运行中的 Pod 与期望的配置时刻保持一致:

　　

　　

根据从 API Server 获得的 PodSpec 以及当前 Pod 状态比较并计算所需要执行的操作（重启、删除等）；在必要情况下删除当前 Pod 的沙箱容器；根据需要（如重启）删除掉 Pod 中的业务容器；根据需要创建 Pod 的沙箱容器；启动下一个根容器；启动 Pod 中的业务容器；

　　 　　

图 6 syncPod 方法源码截图

　　

2.3 深入剖析内核限制机制，找准内核参数改造方向

　　

通过 2.2 节已然明确了容器重启的原因，就可以针对性地制定改造措施：

　　

　　

修改 PodSpec 资源限制后，再将其更新至 ETCD；重新计算 PodSpec 的 Hash 值，将最新的 Hash 值更新至 Docker 容器配置文件。

　　

通过上述步骤后，容器确实能够不停机扩容，Pod 也未发生重启。但是通过混沌测试工具 ChaosBlade 测试内存占用时，发现容器内存最大上限依然是 4G，说明容器的 Cgroup 虽然修改了，但是最大使用量依然是扩容前的值，于是又引发了一个新的问题：为何容器 Cgroup 已经完成了修改，但是使用量却依然被限制？

　　

　　

为了解决上述疑问，工商银行对 Cgroup 机制进行深入地研究。Linux CGroup（Control Group）是 Linux 内核的一项重要功能，用于隔离、限制一组特定进程的资源使用（如 CPU、内存、磁盘、网络等）。Kubernetes 作为容器编排和管理的工具，其底层原理就是通过 CGroup 技术实现容器的资源限制和隔离。

　　

　　 　　

图 7 宿主机 CGroup 隔离结构图

　　

　　

Kubelet 启动时，会按需创建一个四层的 CGroup 树（如图 7 所示），具体列举如下：

　　

　　

第一层（Container CGroup）：容器级别的资源限制，由容器运行时（例如 Docker）来负责创建和维护，通过 docker update 命令即可进行实时调整。

　　

　　

第二层（Pod CGroup）：将 Pod 使用到的资源都纳入管辖范围内，与 Pod 一一对应，其限制取决于 Pod 中容器的资源限制之和。通过调整宿主机相应目录的参数即可实现 Pod 层级资源限制调整。

　　

　　

第三层（QoS CGroup）：是对于不同级别 Pod 的总限制，对于 Guaranteed 级别的 Pod，本身已经指定了资源软、硬限制，无需再增加 CGroup 来约束。对于 Burstable Pod 中容器必须没有设置内存和 cpu 限制或请求级别的 Pod，由于部分容器没有指定资源限制，在极端条件下会无限地占用资源，因此需要分别设置 Burstable CGroup 和 BestEffort CGroup。通过调整宿主机相应目录的参数即可实现 CGroup 层级资源限制调整。

　　

　　

第四层（Kubepods CGroup）：Kubelet 将所有的 Pod 都创建在一个 Kubepods 的 CGroup 下，用来限制宿主机上所有运行 Pod 最大可以使用的资源。Kubepods CGroup 已是所有 Pod 资源使用上限，无需进行调整。

　　

　　

经过对 Linux CGroup 机制的深入剖析，不同等级的 Pod 就明确了准确的内核参数改造方向：

　　

　　

对于 Guaranteed 级别 Pod，按照 Container Cgroup、Pod Cgroup 二层参数的调整即可实现 Guaranteed 级别 Pod 内核限制的修改。对于 Burstable、BestEffort 级别 Pod，按照 Container Cgroup、Pod Cgroup、QoS CGroup 三层参数的调整即可实现 Burstable、BestEffort 级别 Pod 内核限制的修改。

　　

至此，工商银行已顺利实现容器在线纵向扩容的创新探索及案例验证。

　　

2.4 依托云运维能力，实现容器在线纵向扩容落地

　　

工商银行基于容器自服务云平台，集成容器在线纵向扩容功能，形成可视化、易操作的自服务体系，已成功实现生产环境落地，并在 MySQL 容器实现全面推广，效果立竿见影。通过结合 Prometheus 等监控手段，MySQL 容器在性能容量达到一定阈值时，能够实现秒级扩容，降低停机扩容的运维成本和时间，并通过在线方式保障了业务的连续性和高可用性。

　　

三、未来展望随着工商银行 IT 架构转型的持续推进，越来越多的有状态服务将实现云化部署，这对大规模中间件容器的高可用性、服务器资源利用率提出了更高的要求。后续工商银行将持续推进容器在线纵向扩容系统建设，规划包括内存自动扩缩容、CPU 自动扩缩容等场景，在逐步平衡资源成本与系统可用性的同时，不断缓和激增的流量负载与资源容量规划之间的矛盾。同时，通过对接监控体系实现集监控、自调整、快速恢复于一体的更加完善的自动纵向扩容体系，进一步提升机器资源利用率，全面推进中间件容器的高可用能力建设。