40天14大版本升级，腾讯会议背后大规模容器技术实践
春节前后因受新冠肺炎疫情影响，在线办公应用迅速火爆，腾讯会议作为一款企业级在线办公产品，迅速受到用户认可。用户数在爆炸式增长的同时，业务也在高速的迭代升级，40天完成14大版本升级，上演了一场小步快跑，快速迭代的经典案例。本文将从容器的角度着手，为大家呈现腾讯会议如何基于腾讯云容器服务TKE，在后端容量达到100万核的历程下，版本快速迭代背后的云原生技术。
腾讯会议作为面向企业级的关键产品，对产品的可用性和稳定性要求是非常高的，任何服务不稳定都可能会导致用户无法接入会议、会议中断或音视频质量差，从而导致用户投诉，影响到产品口碑，降低用户信任度。
同时，用户数爆炸式增长，需要后端能力可以实时跟上用户的增长节奏，对扩容时效性有非常高的要求。此外，服务运营过程中，产品必然会有功能调优、bug修复等迭代升级，为了使对升级户使用透明，要求平台能高效、可控地支持业务程序发布更新。
解决思路
为解决上述业务场景需求，基于腾讯云容器服务(TKE)实现了对腾讯会议的支撑。借助TKE的动态路由、固定网络、弹性伸缩、以及可控升级等能力，完美地承载了腾讯会议、在线教育、空中课堂等疫情期间高增长业务的部署运营，管理平台架构如下：
管理平台基于TKE集群部署服务，并基于此做了一些功能拓展，图示绿色标示已实现的能力，红色标示进行中，灰色为规划中待实施；TKE集群以腾讯云CVM、CBS、CLB、VPC等基础能力为根基，部署云原生的k8s集群；通过基于TKE拓展的operator，从路由(CLB/L5 Controller)、网络(Ipamd)、资源管理(NodeResourceOversell、DynamicQuota)、弹性伸缩(VPA、HPAPlus)等多个维度做了功能优化，很好地支撑了腾讯会议等腾讯自研业务的部署运营。
业务部署模型如下：
这里业务分三套环境部署，分别对应测试、预发布、正式三套namespace。业务在namespace下以多套微服务模式部署。每套服务包含一套独立完整的执行资源，如：workload、service/ingress、configmap、secret、pv/pvc等
腾讯云容器服务TKE英文全称是Tencent kubernetes Engine，简称TKE，旨在为用户提供稳定、安全、高效、灵活扩展、简单易用的 Kubernetes 容器管理平台。TKE基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务，完全兼容原生 kubernetes API ，扩展了腾讯云的云硬盘、负载均衡等 kubernetes 插件，为容器化的应用提供高效部署、资源调度、服务发现和动态伸缩等一系列完整功能，解决用户开发、测试及运维过程的环境一致性问题，提高了大规模容器集群管理的便捷性，帮助用户降低成本，提高效率。
具体方案解析
下面将从具体从质量保证、效率以及可控升级三大方面介绍腾讯云容器服务TKE是如何支撑腾讯会议的业务演进的。
1、质量保证
业务服务稳定性直接决定了产品口碑，为了保证腾讯会议等业务的服务质量，腾讯云在以下动态路由、异常检测、并行扩容、业务迁移几个维度做了保障措施：
1.1动态路由
动态路由是基于腾讯自研的路由系统L5，通过在TKE集群内拓展service能力实现的L5-controller组件。L5-controller控制层面实现逻辑和通用controller类似，基本流程包括监听变更事件，触发回调，入队列；拉起worker，更新路由。不过为了保障路由的一致性，扩展了主辅两套功能流程，如上图分别用橙、绿色箭头标示流程，主流程保障实效行，辅流程保障一致性。其中，主流程通过监听事件，实时触发，且多worker并发执行，保障路由更新时效性，秒级生效。辅助流程串行扫描集群中的service，拉取该service对应的路由配置数据与L5路由系统中的数据做对账，查漏补缺，任何非通过中控台的路由设置，都会被做强一致性检测到并覆盖，分钟级生效。L5-controller数据层面可以保证变更设置秒级生效，强一致性分钟级实施
1.2 异常检测
通过云原生k8s自带的以下能力，支持用户自定义pod健康检查，保证服务在异常时段内，流量隔离
- livenessProbe：存活检查探针
- readinessProbe：就绪检查探针
- postStart：pod正常拉起前指定执行动作
- preStop：pod销毁前指定执行动作
- terminationGracePeriodSeconds：pod终止等待时间
通过以上几个功能特性的使用，配合动态路由能力，可以实现业务服务的高稳定性保障。
1.3 并行扩容
在腾讯会议这种互联网海量用户场景中，对扩容敏感性的把握是非常需要的，流量短时间爆发式增长，要求后端扩容节奏必须能跟上，所以腾讯云对云原生的HPA的两大能力做扩展，其一是并发量，以高并发的方式运行扩容检测流程，高并发主动检测业务高负载，然后根据实况实时触发扩容；其二是计算周期，支持用户自定义设置检测计算周期，最低甚至可达到秒级，当检测流程在计算周期内发现高负载，可实时触发扩容。
1.4 业务迁移
业务迁移主要通过以下三种模式实现：
helm部署：云原生的方式，一份配置，多集群分发，优点是高效可管理，缺点是容易和现网运行配置存在缺漏差异，导致不一定完全可用，强依赖于部署规范
namespace打包复制：将业务的ns及该ns下所有资源全量打包，复制部署到另外的集群中，尽可能地保证业务的执行环境及配置还原，中控台已实现一键操作，快速高效
namespace打包复用：和上面流程类似，存在功能优化即支持用户自定义调整配置，降低用户操作成本
2. 效率
新冠疫情期间，腾讯会议受广大用户良好口碑认可，用户爆发式增长，服务的部署效率是核心能力体现，为了助推平台能力可以快速适应用户增长的节奏，腾讯云从流程自动化、CI/CD、鉴权管理、弹性扩缩几方面做了努力：
2.1 自动化
自动化主要是为了提高流程效率，具体实施流程如：新建集群、集群容量扩充、环境初始化、组件分发，依赖腾讯云API，自动实施创建集群、集群添加node；环境初始化，内核参数调整、系统环境设置、工具安装、文件系统格式化、组件分发等流程，都是依赖于脚本封装，工具化执行；中控台对各流程、工具的一体化整合，都是通过平台通道实施的，如：批量执行脚本、批量安装，新建集群后注册中控台等
2.2 CI/CD
部署在TKE集群的腾讯内部业务，基本都已打通CI/CD流程，并且支持跨多个网络环境串联部署，腾讯会议通过现有CI/CD模式，借助于云原生的服务编排模式部署，实现了从开发、部署、测试、上线、及版本迭代的高效落地
2.3 鉴权管理
CMDB作为产品、业务模块、IP的关联关系管理模型，应用非常广泛，在很多公司的业务场景中都有重用。CMDB Controller的实现和通用Controller逻辑基本类似，具体包括监听apiserver的pod变更事件、根据事件回调触发对应worker、worker查询集群信息，查询pod关联的产品信息、最终将关联关系落地到CMDB服务系统。
CMDB的实时同步，为很多定制化的拓展功能落地提供了很好的辅助作用，如下面的鉴权申请流程：
如流程图示，通过init-container模式，通过业务CMDB快速同步落地，与腾讯内部的织云、L5等系统联动，可以高效打通鉴权通道，使得一直让业务头疼鉴权申请全自动化，高效的支持业务服务部署。
2.4 弹性扩缩
为了满足腾讯会议等关键业务的场景需求，除了云原生的VPA能力外，腾讯云基于云原生HPA做了拓展，通过单独抽离出HPA功能模块以Operator方式实现，用以支持业务自定义特性设置，具体拓展能力包括多路指标，支持通过Metrics server、Promethus、业务监控等多路指标采集，更好地兼容业务场景
；并行实施，多work并行检测业务指标，实时触发弹性伸缩，保证时效性；自定义，支持用户自定义扩缩容阈值、计算周期、弹性系数。其中多路指标的功能框架如下图：
3.可控升级
腾讯会议对于用户来说，都是用于解决用户直面沟通难的关键场景，为了提供更好用户体验，产品运营过程中，或多或少会有功能优化、bug修复等迭代。在云原生的模式下，如何保障更新升级的可靠、可控显得尤为重要。腾讯云基于云原生能力在以下固定网络、升级轻量化、分批升级、容量保障四个方面做了拓展优化，实现了以下几个场景需求的能力：
3.1 固定网络
固定网络是指pod销毁重建后ip依然不变，场景如：pod异常、workload版本更新等，固定网络是腾讯自研业务非常认可的一大特性，很多业务后台服务都有基于ip的鉴权管理、白名单机制等功能依赖，相信不少公司都会有类似的场景需求。固定网络的设计基于三大功能模块：IPAMD Controller、TKE-ENI-AGENT、CNI：
- IPAMD Controller以operator形式运行，负责ip的分配管理、网络资源的状态更新、以及node、pod的关联关系的记录更新等
- TKE-ENI-AGENT以daemonset方式运行在每个node上，负责路由对账、生成 cni 配置、设置节点策略路由和 Pod 的网络堆栈
- CNI也是运行在node上，负责实施节点策略路由和 Pod 的网络堆栈
固定网络的具体实现流程如上图：
- 用户发起statefulset的创建
- IPAMD Controller通过list-watch机制，监听到创建请求
- IPAMD Controller通过IP allocator去对新statefulset下所有pod分配IP
- IPAMD Controller为每个pod生成对应的网络配置StaticIPConfig，然后在该statefulset以后的生命周期中，对pod与已分配ip的关联关系和状态更新进行管理
- IP allocator是IPAMD Controller的核心功能，它会根据pod信息和statefulset的状态去判断当前pod是新建申请、销毁重建预留、删除回收等流程，并生成对应配置，当statefulset新建时，allocator会配新的IP给到pod，当pod异常销毁重建时，allocator会临时回收保留原IP，等重建好后，重复复用，当statefulset删除时，会把所有分配的IP回收
- 当pod在node上创建时，会通过TKE-ENI-AGENT获取IPAMD已经生成好的网络配置StaticIPConfig，然后通过GRPC的方式请求IP allocator实施生效pod网络配置
- IP allocator接收到TKE-ENI-AGENT请求后，会去获取已经分配好的pod网络配置StaticIPConfig，然后根据配置去调用腾讯云接口创建ENI弹性网卡，最后生成CNI配置CNIInfo
- CNI根据IP allocator生成的配置CNIInfo，实施节点策略路由和 Pod 的网络堆栈，生效pod网络
3.2 StatefulsetPlus Operator
云原生的Deployment、StatefulSet等workload类型，没法很好地满足腾讯会议等业务的使用需求如：升级轻量化、分批升级、容量保障等，所以腾讯云基于StatefulSet开发一套Operator支持新的workload类型即StatefulsetPlus，它继承了Kubernete内置的StatefulSet所有核心特性，主功能逻辑和StatefulSet类似，但做了细分能力拓展如支持容器（Pod）实例的固定IP、支持应用的多批次灰度更新，更好的兼容传统应用的发布、Node失联时，Pod的自动漂移、支持容器原地升级。StatefulsetPlus Operator的应用架构及功能模块如下：
StatefulsetPlus通过CRD模式部署，和Statefulset的yaml参数有部分差异，使用方式和Statefulset基本一致
3.3 分批升级
诸如腾讯会议等很多重点业务，在更新升级时要求绝对地可控推进，分批升级便是基于该场景拓展实现的，也可以更好的兼容传统应用的发布，分批升级在实际使用中的演化过程如下所示：
分批升级要做到足够可控，需要在发起升级时预先指定批次，后续每个过程都会有人工触发，若出现升级失败，可以修复后继续，也可以直接走Rollback流程，相对于其他workload，StatefulsetPlus的分批升级功能带给用户的使用优势是用户可配置每个批次的实例集，比如用户可根据应用服务地区，只暂时升级对应地区的实例。每个批次指定实例进行并发更新，升级效率高。
同时，升级更安全和省心，支持每个批次完成后等待用户确认，再触发升级下一批实例，通过应用探针自动监测到升级成功后，自动触发升级下一批实例。另外，支持手动伸缩容，基于基础指标(Cpu, Mem, Network I/O)的弹性伸缩，也支持基于应用自定义监控指标的弹性伸缩。
总结
当前，全面上云的趋势已然清晰，腾讯会议也借助于云计算的盛风顺势起飞，迅速基于云原生技术完成版本的快速迭代和功能的完善升级。在各行各业云原生改造盛况之下，容器技术在其中作用至关重要。腾讯内部在很早之前就已经研究与容器相关的技术与服务，其中很多成功的业务，例如游戏、微信、广告等都选择运行在容器技术上，可以说容器技术正在支撑着数十亿计的用户。
随着云原生技术生态蓬勃发展，作为一枚技术追随者，也希望腾讯云容器服务TKE技术能支撑着更多业务傲然前行。
