做者
汤英康，腾讯高级工程师、Kubernetes 开源协同 PMC，负责TEG信息安所有的容器化上云相关工做。docker
引言
截止到2021年5月，TEG 信安运维团队历时一年，完成了 TKE 容器从0到1的平台能力建设，集群总规模超过60万核，在资源成本、服务质量和运营效率上都取得了明显的收益。 本文将介绍信安 TKE 容器的建设思路和历程，分享各阶段遇到的问题和方案，但愿能给其余上云团队提供一些参考。安全
背景
信安致力于提供专业的内容安全解决方案，承接了公司内外大量的业务安全需求，随着业务量的迅速增加，信安内部的资源规模也日益增加，在机器成本、服务质量和交付效率方面也暴露了不少优化空间；自从公司倡导开源协同、自研上云以来，TKE(Tencent Kubernetes Engine)成了内部首推的上云方式，以 docker 和 kubernetes 为核心的容器技术也早已成为业界架构升级的主流选择。网络
所以，在2020上半年，信安联合 TKE、智研和运管团队协同建设，开启了信安容器平台的建设之路。架构
建设思路和整体规划
信安对于容器平台的建设思路和历程，能够总结归纳为“一个方向、三个阶段”：运维
【一个方向】向云原生理念看齐，围绕云原生开源生态体系进行方案选型，紧跟业界先进的基础架构升级方向；socket
【三个阶段】云原生有三驾马车：容器云 + 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 上部署的服务进行容器化改造。这里的难点主要有：url
- 服务多样性，包含无状态、有状态和 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到一、从无到有的建设；下一步，是从“有”到“优”，把现有的容器架构和业务改造模式、往更加云原生的方向靠拢。
富容器瘦身
在前期，因为人力投入有限，咱们采用了富容器的方式改造业务，也就是把容器当成虚拟机用，在容器的基础镜像里面注入了过多的基础 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月：
1）信安TKE集群累计规模达62w+核，GPU卡容器化超2000卡
2）业务累计接入40+个信安服务，约占33%的转维服务
3）累计节省成本约20w核，质量和效率也有明显的提高。
结语
技术圈有一句名言：“人们对于新技术每每都会短时间高估它的影响，可是大大低估它长期的影响”。
新的技术，从创造到落地必然须要经历一个过程，它须要在短时间付出比较多的投入，架构的升级也会给团队其余项目和人员带来阵痛；但只要论证清楚方向、并坚决地朝着它努力，咱们必将迎来质变、收获咱们所希冀的馈赠。
路漫漫其修远兮，但愿你们都能在云原生建设的道路上行得更远、走得更好！
容器服务（Tencent Kubernetes Engine，TKE）是腾讯云提供的基于 Kubernetes，一站式云原生 PaaS 服务平台。为用户提供集成了容器集群调度、Helm 应用编排、Docker 镜像管理、Istio服务治理、自动化DevOps以及全套监控运维体系的企业级服务。 【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！