一、背景

vivo人工智能计算平台小组从2018年底开始建设 AI 计算平台至今，已经在k8s集群、以及离线的深度学习模型训练等方面，积累了众多宝贵的开发、运维经验，并逐步打造出稳定的基础容器平台 - AI容器平台（VContainer）。为了支撑公司AI在线业务的发展，满足公司对算力资源的高效调度管控需求，需要将在线业务，主要包括C端、推理等业务，由原来的虚拟机或物理机迁移至AI容器平台。于是小组从2020年初开始，基于在线业务的需求对AI容器平台进行进一步建设，并将平台与公司的CMDB、CICD等基础模块进行打通，使在线业务能够顺利从虚拟机、物理机迁移至AI 容器平台。

目前AI容器平台已迁移了4成左右的AI在线业务，大大小小100+在线应用，流量峰值超过22w qps，数百台服务器支撑着在线业务容器的运行。

本文是 vivo AI 计算平台技术演进系列文章之一，着重分享了计算平台的底座 - AI容器平台（VContainer）的在线业务容器化落地过程中所遇到的问题及解决的思路，vivo AI 计算平台相关的技术实践可参考此前发布的《vivo AI 计算平台的K8s填坑指南》。

二、容器化部署的优点

与虚拟机或物理机的部署相比，将业务部署到AI容器平台有很多优点：

• 容器平台可以统一对算力资源进行管控、调度，解决了机器资源分散、闲置、难以维护等问题

• 容器平台可以做到一键扩缩容，解决了业务扩缩容时资源申请、操作效率低问题

• 容器平台支持弹性伸缩，可以根据监控指标或定时做动态伸缩，很适合应用于具有高低峰特性的业务，保障业务稳定的同时，提升资源的利用率

总的来说，容器化部署可以提升资源利用率和运维效率，达到节约机器、运维成本的目的。

三、功能模块概览

在线业务容器化落地所涉及到的功能模块分两部分：公司云平台和 AI容器平台。云平台是用户入口，AI容器平台则是容器化部署的基础环境：

云平台模块介绍

如上图，AI容器平台打通了公司云平台，以其作为业务容器化部署的入口，保证用户操作体验与虚拟机、物理机的一致，主要打通以下模块：

• CICD：业务容器化部署、管理入口

• CMDB：业务容器元数据信息维护入口

• 监控中心：业务容器监控指标查看入口，例如可以查看容器的运行时指标，如CPU、负载、网络IO等指标，也可以针对指标配置各种告警规则

• 日志中心：业务容器日志查看入口

上图只列举了AI容器平台所打通的主要模块，除这些模块之外，业务还可以继续沿用云平台上的配置中心、调用链、服务治理等众多模块的功能。

AI容器平台模块介绍

AI容器平台是容器化部署的基础环境，我们建设、集成了一系列的组件用于支撑业务容器的部署、管理、监控、运维等工作：

• 业务部署：负责对接公司云平台的CICD，提供业务的部署及管理等服务

• 容器信息上报：负责对接公司云平台的CMDB，进行容器元数据信息的上报

• 监控指标上报：负责对接公司云平台的监控中心，该服务会从prometheus拉取容器监控指标进行上报

• 业务日志上报：负责对接公司云平台的日志中心，容器平台通过deamonset的形式在每个节点上部署公司的日志采集插件，采集插件会从约定的主机目录下采集业务日志，然后对接日志中心的kaffka进行上报

• 弹性伸缩：提供hpa水平扩缩容功能，可基于cpu、内存、qps进行动态扩缩容，或者配置定时（Cron表达式）的扩缩容

• 流量网关：业务流量入口，基于nginx ingress controller

• DNS服务：k8s集群域名解析服务，基于coredns

四、业务容器化的痛点解决

为了保证在线业务能够平滑、稳定地迁移到容器平台，平台侧需要解决一系列业务容器化的需求与痛点，下面列举了几个比较典型的问题进行说明：

1、网络扁平化

网络扁平化，是指支持平台外的应用通过pod ip访问pod实例。未经扁平化的k8s网络，pod的ip是不能被集群外访问的，例如类似java dubbo的应用，集群外的dobbo comsumer 是无法通过 pod ip 访问dubbo provider的。为了满足平台外的应用通过pod ip访问pod实例的场景，平台需要将k8s calico网络与机房网络打通（扁平化）。

AI容器平台和网络团队合作，Calico采用Route Reflector模式，在RR节点和机房交换机分别新增BIRD配置，使RR节点将集群内的calico路由信息通过BGP协议同步给交换机。这样集群外的服务访问pod IP时，交换机可以找到对应的路由规则，从而实现了容器网络的扁平化。

2、灰度发布

由于k8s原生的deployment只支持滚动更新、重建两种更新模式，难以支持灰度、发布暂停等功能，所以平台引入了另一款发布功能比较完善的部署组件 - Argo Rollout 来进行支持，Argo Rollout 除了兼容原生deployment的所有特性，还支持灰度发布、蓝绿发布等更加强大的发布特性。

3、无损发布

无损发布，主要是解决发布过程中，旧版本容器实例销毁、新版本容器实例创建过程中的请求流量损失问题，目前主要有两类无损发布场景：

• http无损发布：http流量通过ingress或service代理到pod实例的场景，这种场景可以通过配置容器的就绪检查、优雅退出时间（terminationGracePeriodSeconds）来实现，就续检查可以保证新的实例变为就绪后才能接受流量，合适的优雅退出时间可以确保旧实例上剩余请求处理完，k8s才对实例进行销毁，同时业务也可以在容器的preStop勾子做些收尾操作。

• dubbo无损发布：由于java dubbo有自身的一套服务注册和消费机制，容器的就绪检查无法控制dubbo 客户端对dubbo 服务端的调用，所以需要额外的机制去实现无损。
目前的方案是结合dubbo注册中心开发的禁用/启用接口和 k8s的初始化容器 initContainer 来实现，核心过程如下：

（1）对于旧版本pod实例：在业务容器的preStop环节调用dubbo注册中心禁用接口，禁止流量请求到当前实例（根据pod ip禁用），同时需要合理配置优雅退出时间（terminationGracePeriodSeconds），以确保旧实例上剩余请求处理完，k8s才对实例进行销毁
。

（2）对于新版本pod实例：在初始化容器 initContainer环节调用dubbo注册中心禁用接口，禁止流量请求到当前实例（根据pod ip禁用），当业务容器的dubbo服务启动后，会自动注册到注册中心，但此时注册中心是禁用此pod ip的，流量还不会进来。最后在postStart环节，判断服务已经启动完毕后（比如调用服务的check接口），再调用dubbo注册中心的启用接口，让当前的pod开始接受流量

总结一下，其实两类发布场景的无损解决思路是一样的：
对于老版本的容器实例，先把流量断掉，等上面的剩余请求处理完毕后进行回收；
对于新版本的容器实例，确保服务能够正常处理请求后再把流量接进来。

通过对http无损发布和dubbo无损发布的支持，使业务的流量能够平滑地从旧版本切换到新版本，保障了业务的稳定。

4、调度部署策略配置

在线业务的核心诉求是稳定，平台侧应该尽量减少单节点、单实例故障对业务的影响，让业务能够无感知地容忍部分异常和失败，同时需要减少不同业务之间的相互影响，所以对调度部署策略来说，也是一个需要着重考虑的点，目前主要从以下方面进行控制：

• 减少单点故障对业务的影响：将应用进行多副本部署的同时，让各实例优先打散在不同的节点上，技术上可以通过k8s pod的反亲和策略来实现；

• 减少同个节点不同业务的IO影响：由于目前IO无法做到像CPU、内存的隔离程度，IO负载高(网络或磁盘IO)的业务尽量不要部署在同个节点上，可以给业务进行分类，比如计算密集型、 IO密集型等类型，通过反亲和优先将不同类型的应用调度到一起，同类型的应用分散；

• 支持需要独占节点的业务：有些业务的资源诉求大，负载高，无法与别的业务共存，这种情况可以通过节点的label和taint机制，给业务划分单独的一批节点进行隔离部署，保障业务稳定。

5、机房dns打通

有些部署在容器平台的业务，需要有一个在平台内外都能访问的通用域名，方便调试或与其他业务对接，而k8s 的service 的域名（格式形如 serviceName.namespace.svc.cluster.local），并不能在k8s集群外进行访问，使用起来不方便，所以平台在coredns层面配置了域名重写（rewrite）规则，并与公司机房的dns进行打通，机房dns服务器会将约定后缀（.vcontainer.idcCode）的域名解析请求forward到平台的coredns进行处理，使得采用约定后缀（格式形如 serviceName.namespace.svc.vcontainer.idcCode ，将原生的后缀 .cluster.local 替换为 .vcontainer.idcCode）格式的域名在k8s集群内和集群外都可以访问。

6、资源弹性伸缩

业务对资源的使用有动态伸缩的需求，比如负载高峰时段希望能自动扩容，保障业务稳定，负载低峰时段希望能自动缩容，提高资源利用率，避免资源浪费。

资源的伸缩主要分为两类，水平伸缩（hpa）和垂直伸缩（vpa），水平伸缩主要是通过调整部署的副本数来实现，垂直伸缩则是基于容器的申请资源的request 和 limit来控制，由于考虑到线上业务的稳定性，业务申请资源时尽量需要保证request 和 limit一致，避免同一节点的容器在资源不足时互相挤占资源，造成机器故障（比如内存不足时导致节点System OOM），所以在弹性伸缩方面，平台重点建设了hpa功能。目前平台已经支持基于CPU、内存、定时（Cron表达式）、QPS等指标对业务实例数的资源进行水平伸缩的功能，并逐步在业务中进行推广。

五、业务容器化的规范

为了保证业务能够平滑顺利地从虚拟机或物理机迁移到容器平台，需要对业务做一些规范约束，防止出现不稳定因素，方便管理维护。

1、统一基础镜像

要求业务使用公司统一的基础镜像，保证业务运行环境的稳定（如 CentOS、JDK、tomcat版本统一等）。

2、Java业务的JDK版本要求

对于java 业务，统一使用jdk1.8.0.192版本（jdk1.8.0.191 及以上版本），经验证此版本对docker 容器的支持比较友好，能够正确从系统cgroup识别到容器申请的CPU、内存等信息。某些旧版本的jdk欠缺对容器的支持，运行时容易造成问题。
举例子说明，在jdk7上跑应用时，业务方根据Runtime.getRuntime().availableProcessors() 来设置线程池的线程数时，availableProcessors获取到的是主机的CPU核数，而不是容器实际申请的cpu核数，会导致业务并发量过大，容器负载过高而出问题。另外JVM也会启动过多的GC线程，导致JVM进程出问题。

3、业务日志规范化

业务日志需要写入到约定的目录，日志内容也需要遵守日志中心规定的json格式，保证日志能被正常采集和处理。

4、实例无状态化

部署的实例要求是无状态的，如果有对本地存储依赖，则需要改造为访问分布式存储，才能保证资源调度的安全和灵活，也方便后续弹性伸缩的落地。

5、通过域名访问容器服务

要求通过域名方式访问容器服务，而不能写死IP来访问，因为pod的ip不是固定的。

六、业务落地过程所踩过的坑

在线业务的容器化推进得益于平台和运维同学们的持续投入、专业和严谨，进展比预想顺利，目前依然在稳步推进中。当然，由于容器化部署所涉及的组件、链路环境还是相对复杂，自然也会踩到一些坑，下面例举了部分比较典型的问题：

1、容器的资源request和limit不一致导致节点System OOM
容器的资源request和limit不一致可能会导致一些不稳定因素，比如导致节点System OOM，因为当不同业务的pod调度到同一个节点上，如果request和limit不一致，容器在资源不足时会互相挤占资源，造成机器故障（比如所有容器实际使用的内存总和超过机器内存时，会造成System OOM），所以应该尽量保证线上业务容器的资源request和limit一致。

2、跨机房延迟

在落地过程中，某些在线业务所依赖的组件（如数据库，缓存等）与容器部署在不同机房，会导致业务请求响应比在原来虚拟机上部署时慢，所以应该尽量将容器业务部署在跟其所依赖的中间件环境的同一个机房内。

3、机器CPU性能问题

线上机器型号尽量保持一致，当同个应用的不同实例部署在CPU性能差别很大的节点上时，容易导致同个应用的不同实例负载不均衡，影响业务的稳定性。

4、kmem accounting导致的memory cgroup泄漏

kmem accounting导致的memory cgroup泄漏（创建容器时申请，但之后无法释放回收）的问题也是AI容器平台的节点经常遇到的问题，网上也有很多分析解决方案，问题的起因跟kubelet、runc、linux都有关联，在此不作详述，问题的影响是，会导致容器创建失败，只能通过重启机器解决。AI容器平台的解决方案是关闭kubelet、runc等组件的kmem accounting特性，目前从节点灰度的情况来看是有效的。

5、僵尸进程问题

由于docker容器中的1号进程（如entrypoint 进程）并不具备管理多进程（子进程）的能力，容器实际上比较适合单进程模式运行，但某些场景下我们又需要将其当成虚拟机来使用，在容器里启多个进程做各种操作，那么就容易造成子进程资源无法回收而形成僵尸进程风险，僵尸进程持续占用着系统资源而无法进行释放，也会造成机器卡死，影响业务调度和运行的稳定性。好在k8s为此给pod提供了一个shareProcessNamespace特性，可以在pod内开启共享PID名称空间，将 pod 中的 1 号进程变成了 /pause，并在/pause 进程中实现了对容器内其他进程的管理，从而避免出现僵尸进程。

七、总结展望

由于容器化部署的众多优点，越来越多的公司选择将业务迁移到容器平台之上，vivo AI 容器平台也开始了在线业务容器化落地的实践，相对于离线业务，在线业务对平台的稳定性和资源调度管理有更严格的要求，本文总结了在线业务容器化落地过程中所遇到的问题及解决的思路，后续也将持续进行功能迭代优化，以支持更复杂的业务场景（比如支持有状态的应用的发布，IP固定的原地发布等），并对离在线混部的技术和策略进行探索，以适应大规模算力资源的调度管控需求。

作者介绍：

刘东阳，曾就职于金蝶, 蚂蚁金服等公司，目前是 vivo AI 研究院计算平台组的资深工程师，关注 K8s、容器等云原生技术。

创作场景

vivo AI 计算平台在线业务落地实践