案例 | 信安运维基于 TKE 平台的容器技术实践
引言
截止到2021年5月，TEG 信安运维团队历时一年，完成了 TKE 容器从0到1的平台能力建设，集群总规模超过60万核，在资源成本、服务质量和运营效率上都取得了明显的收益。本文将介绍信安 TKE 容器的建设思路和历程，分享各阶段遇到的问题和方案，希望能给其他上云团队提供一些参考。
背景
信安致力于提供专业的内容安全解决方案，承接了公司内外大量的业务安全需求，随着业务量的迅速增长，信安内部的资源规模也日益增长，在机器成本、服务质量和交付效率方面也暴露了很多优化空间；自从公司倡导开源协同、自研上云以来，TKE[1](Tencent Kubernetes Engine)成了内部首推的上云方式，以 docker 和 kubernetes 为核心的容器技术也早已成为业界架构升级的主流选择。
因此，在2020上半年，信安联合 TKE、智研和运管团队协同建设，开启了信安容器平台的建设之路。
建设思路和总体规划
信安对于容器平台的建设思路和历程，可以总结概括为“一个方向、三个阶段”：
【一个方向】向云原生理念看齐，围绕云原生开源生态体系进行方案选型，紧跟业界先进的基础架构升级方向；
【三个阶段】云原生有三驾马车：容器云 + Devops 运营体系 + 微服务，分别对应了容器化征途必经的三个阶段，
阶段1：基础平台建设，将容器技术引入到服务架构并适配，完成从0到1的能力建设、业务改造和架构升级； 阶段2：运营能力迭代，主要任务是围绕容器平台提升研效能力、完善数据运营能力，并建立稳定性保障体系； 阶段3：云原生成熟度提升，基于公司发布的云原生成熟度模型，以成熟度评分为抓手，推动现有架构持续优化。
基础平台建设
平台能力建设
在 TKEStack 团队的协助下，信安顺利地在深圳、广州、上海、南京4个地区完成了CPU独立集群的搭建，结合 TKEStack 的控制台页面，快速具备了容器发布和管理的基础能力。通用能力之外，在个性化需求的适配上，主要有：
实例固定 IP：通过 FloatingIP 插件实现，创建容器时在网络模式中选择浮动IP，IP回收策略选择“缩容或删除 APP 时回收”，即可实现 CMDB 同步：通过 CMDB 控制器插件实现，实例启动后，插件会自动将 pod IP 注册到 annotation 中指定的业务模块 L5/北极星服务注册：通过LBCF插件实现，实例 running 状态后，可以将实例IP和指定端口注册到L5/北极星，实例被删除时，可以从L5/北极星下线
GPU 集群也在深圳和上海完成搭建并投入使用，并设计了基于 Virtual Kubelet、将 GPU 集群的CPU资源注册到CPU 集群中进行调度的方案，能更好地复用 GPU 机器上空闲的CPU资源。
业务容器化改造
具备平台能力后，下一步就是对现有的 IDC/CVM 上部署的服务进行容器化改造。这里的难点主要有：
服务多样性，包含无状态、有状态和 GPU 的服务，单个服务的包很大（最大可达几十个G），服务有自己的依赖环境等 需要考虑多个研发运营流程节点：包括开发改造、测试流程规范、Dockerfile 镜像制作、CICD 流程、运维变更规范等
我们主要采取了如下几个措施：
首先，梳理不同场景下服务的改造流程，在内部制定了统一的开发、测试和运维使用规范 在基础镜像的选择上，我们基于信安标准化的机器环境制作了基础镜像，减少服务因为环境问题导致异常的概率 抽象出 Dockerfile 模板，降低了服务改造成本（开发同学几乎0参与） 统一容器内的启动入口（Entrypoint 和 CMD），在管理脚本中启动服务 部分服务在启动之前、需要将容器IP写到配置文件中，我们通过在管理脚本中实现 对于 size 过大的软件包和镜像，考虑将文件机型拆分管理，例如数据模型文件、通过服务启动时再去文件下发系统拉取
资源利用优化
一方面，将每个服务划分到单独的 namespace 空间，结合 ns 的 ResoureQuota 来配置和限制服务所能使用的资源；
另一方面，为了提升集群整体的资源利用率，对每个服务在实际部署时进行合理的 cpu 资源超卖，即 cpu 的 limits 值会大于 requests 值；一般会结合服务的当前利用率、目标利用率以及服务的重要性来考虑，具体的超卖比例计算公式为：
目标利用率 / (当前利用率 * 服务权重)
通过这种方式，对于长期利用率低下的服务，在不调整实例的情况下，就可以极大地提升宿主机整机的 CPU 利用率。
调度管理
通过开启 K8s 本身的 HPA 和 CA 能力，可以实现整体架构从应用层、到集群层的两级弹性调度。
由于我们是跨地区多集群部署，所以需要对多个服务、在多个集群去配置管理HPA，并且定期根据实际的资源使用情况，来判断当前服务的 HPA 策略是否合理；为此，我们设计开发了 HPA 管理系统，实现了：
将 HPA 策略分类管理，对于业务请求波动情况、伸缩指标、阈值和优先级相近的服务，可以用一个调度类来批量创建HPA策略 在跨集群中，通过一个统一的入口来下发和配置 HPA，无需在每个集群单独配置和管理，提升管理效率 通过定时拉取服务的监控指标，可以输出服务当前的资源实际使用情况，判断 HPA 策略合理性并修改
运营能力迭代
Devops 研效能力方案
【CICD】：基于现有的智研 CI 流水线，增加【智研-镜像构建】和【智研-制品入库】插件，将编译生成的软件包转化成镜像后推送到统一软件源，实现 CI 和 TKE 的对接
【监控】：将 agent 注入到基础镜像中，随管理脚本启动
【日志】：业务日志直接上报到智研，k8s 集群层面的 event 事件，通过事件持久化组件存储到 Elasticsearch、供后续查询
【配置管理】：将七彩石 agent 注入到基础镜像中，随管理脚本启动，服务统一用七彩石下发配置
数据运营系统建设
为了更贴合业务运营场景，我们设计并开发了 kbrain 系统，在后台对接 k8s 集群、拉取基础数据并进行二次处理后存入 cdb 中，通过 grafana 配置展示业务维度的视图数据和报表，并引入了健康度评分、成本收益、超卖比例、资源碎片实例等有价值的数据作为运营参考。
对于已经配置了 HPA 弹性伸缩策略的服务，也可以在 HPA 调度看板查看效果，如下图所示：
这里有4条曲线：当前利用率、目标利用率、当前副本数、目标副本数
趋势图证明：当前利用率提高时，目标副本数随之提高，扩容完成后、利用率恢复到正常水平
稳定性保障体系
对于 TKE 这样的大规模基础平台，完善的稳定性保障体系和平台支撑是必不可少的。主要从以下几个方面考虑：
SLA 规范：作为业务方，和 TKE 平台支撑方明确对齐 SLA 规范，包括不可用的定义、故障的响应机制和处理流程、平台运维变更规范、节假日规范以及问题上升渠道等，这是稳定性的基础 稳定性指标：整理所有能够反馈平台和业务稳定性的指标，并通过后台拉取后在 grafana 平台汇聚展示 容量管理：实时监测集群的剩余资源水位，避免因容量不足导致的故障 预案机制：梳理所有可能产生的故障，并提前设计好快速恢复的应急预案 监控告警：检查集群和服务是否都接入和上报了有效的监控指标，出现问题时必须能第一时间收到告警 混沌工程：协同引入混沌工程 oteam，围绕 TKE 建立故障演练能力，检验 SLA、稳定性指标、容量系统和预案机制的可靠性
云原生成熟度提升
经过前两个阶段的基础平台建设和运营能力迭代，我们基本完成了容器能力从0到1、从无到有的建设；下一步，是从“有”到“优”，把现有的容器架构和业务改造模式、往更加云原生的方向靠拢。
富容器瘦身
在前期，由于人力投入有限，我们采用了富容器的方式改造业务，也就是把容器当成虚拟机用，在容器的基础镜像里面注入了过多的基础 agent。
基于云原生理念和容器的正确打开姿势，我们把容器进行瘦身，将原有的容器拆分成：1个业务容器+多个基础 agent 容器，将大文件从镜像里面完全剥离、利用云盘/云存储/文件分发系统实现。
拆分后，1个 pod 里面会有多个容器，容器之间如果需要共享文件（例如 业务进程读写智研监控 agent 的 socket 文件），可以采用 emptydir 卷挂载方式实现。
小核心改造+Overlay网络优化
对于 TKE 容器集群来说，如果大多数服务都是大核心配置（例如 36c、76c甚至更大），会产生较多的资源碎片，一部分节点的剩余可分配资源（2c、4c、8c等）无法真正分配出去，造成资源浪费。所以，从宏观角度看，需要把大部分服务的容器资源配置尽可能切小。
信安的服务在容器化改造之前，习惯了多进程的架构并为之做了优化，单机经常运行48/76个进程（甚至更多）；容器化改造运行后，由于超卖、基于获取到的 cpu limits 值运行的进程数会远高于 cpu requests 值，导致部分进程异常（无法真正绑核运行）。
因此，需要修改服务运行配置、切换到小核心配置且 requests=limits 值的容器中运行。
然而，在容器切小核心的同时，服务的实例数也会增长。例如，从76核配置切换到38核，实例数会翻一倍；从76核到8核，实例数几乎扩大到10倍。如果这时服务依然采用 FloatingIP 的网络架构，对于集群底层的IP资源又是一个巨大的开销。
一般来说，切换到 Overlay 网络即可，但Overlay网络的延迟会高出20%，而且因为是集群内唯一的虚拟IP、所以无法注册到L5/北极星、也不支持 monitor 监控。经过和TKE团队的调研论证，最终设计采用了基于Overlay改进的 HostPort 网络方案：实例 Pod 依然拿到的是集群内虚拟IP，但是可以把 Pod 内部的服务端口映射到宿主机的随机端口，再把宿主机IP+随机端口 注册到L5/北极星，从而既实现了服务注册、又能够最大限度降低时延。
我们针对试点服务（低俗识别）首先完成了小核心改造+Overlay 网络的部署和测试，验证得到：
overlay+HostPort 网络下的吞吐量与时延、和 FloatingIP 接近
成果小结
截止到2021年5月：信安已基本完成了 基础平台建设+运营能力迭代 这两个阶段的建设任务，正在努力提升云原生成熟度。
TKE集群累计规模超60w+核，累计节省成本约20w+核，在成本、质量和效率方面收益明显。
结语
技术圈有一句名言：“人们对于新技术往往都会短期高估它的影响，但是大大低估它长期的影响”。
新的技术，从创造到落地必然需要经历一个过程，它需要在短期付出比较多的投入，架构的升级也会给团队其他项目和人员带来阵痛；但只要论证清楚方向、并坚定地朝着它努力，我们必将迎来质变、收获我们所希冀的馈赠。
路漫漫其修远兮，希望大家都能在云原生建设的道路上行得更远、走得更好！
参考资料
TKE: 【https://cloud.tencent.com/product/tke】
互动赢好礼
精读本文，回答作者提问
阅读本文，回答作者提问，将于6月30日11点选出答案最佳2名及留言点赞最高的前3名，送腾讯云小云仔一只。
Q：在搭建 k8s 容器平台能力的时候，你遇到过哪些需要定制开发的功能需求？
往期精选推荐