从 OpenStack 到 Mesos 再到 Kubernetes, 携程容器云自动化运维平台实践 -InfoQ

随着虚拟化技术和云计算技术的普及，IT 互联网基础设施发生了很大的变化，底层的计算、存储、网络等资源也越来越复杂，需要有平台能管理好这些资源，尽量将工作流程自动化，将运维人员从繁重的手动工作中解救出来。而现在工具的更新迭代也越来越快，如何构建这样的平台提高软件构件和交付的效率也是很多团队面临的问题。

InfoQ 记者采访了携程系统研发部云平台高级研发经理周昕毅，来了解携程容器云自动化运维平台的建设情况。

背景

携程容器云自动化运维平台是携程容器云基础设施的管理工具。携程容器云承载着携程机票、酒店、交通等业务线数千个应用，近 10 万个容器实例，整体容量年增长率超过 40%。

运维平台从 2016 年开始建设，主要分为三个建设时期。

平台初期(2016.01 ~ 2017.01)主要解决OpenStack架构下的运维问题。这个阶段平台提供的能力包括：
宿主机的自动上线，
平台监控及日志收集，
故障排查工具、提升工程师排障效率。

这个阶段的特点是关注标准化推进，包括宿主机标准化、监控标准制定、日志标准和规范落地。

Mesos阶段(2017.02 ~ 2018.02) 在标准化的基础上，平台开始提供SDN网络、云存储、容器迁移等自动化工具，管理覆盖面更广。

这个阶段整个容器云的容量增长很快，依靠平台的能力，团队得以继续维持容器云持续高效运行。

Kubernetes阶段(2018.03 ~至今) ，Mesos的开源社区活跃度在2017年底开始逐步降低，虽然Mesos简单稳定使用起来又熟悉，但是我们发现越来越多的需求需要定制开发，平台维护成本也变高，并且生产版本老旧，编排能力和范式弱，升级成本不亚于迁移。

容器云基础设施在 2018 年开始全面转向 Kubernetes。在 Kubernetes 运维管理的基础上，运维平台逐步开始提供容量规划与预警、故障关联及合并、容器实例自动迁移、应用自动扩缩容等能力。Kubernetes 拥有庞大的生态，迁移到 Kubernetes 也让未来的技术路线更加清晰。不过 Kubernetes 本身有一定的复杂度，团队需要时间熟悉，短期内也有稳定性的风险。

自动化运维平台架构设计

运维平台搭建初期主要关注三个方面：配置管理、监控管理、日志管理。

配置管理相关工具先后尝试过SaltStack、Ansible和Rundeck。在大规模集群管理的实践中，SaltStack性能最好、可靠性最高，目前运维平台使用SaltStack进行配置管理，Ansible/Rundeck相比而言更适合中小规模的平台管理。
监控管理工具尝试过Zabbix和Promethus，当前使用携程自研的Hickwall监控系统，针对容器监控做了额外的定制开发。

配图 1:携程自研 HICKWALL 监控平台

日志管理尝试了ElasticBeats、Kafka、ELK等主流开源工具，目前基于ELK给用户提供了一站式日志检索和关联查询的能力。

为了将配置、监控、日志三个模块进行整合，提升工程师日常运维工作效率，平台引入了 Stackstorm，在平台建设中贯彻事件驱动运维的理念。Stackstorm 是一个功能强大的开源自动化平台，可将所有应用程序，服务和工作流程连接起来。它跟传统化运工具有些区别。我们开发的聊天机器人也可以和 StackStorm 工具做集成，提高排障的效率。

初期运维平台架构（包括 Openstack 时期和 Mesos 时期）如下图：

运维平台通过 SaltStack 进行配置管理，实现配置标准化的落地；其他公司的最佳实践、Docker/内核/K8S 等版本升级、线上环境出现的各类异常和故障会促使我们不断修订运维标准，通过 StackStorm 流程灰度发布到平台各套环境中。

经过近三年演进，运维平台当前架构（即 Kubernetes 时期）如下图：

围绕云平台三大核心资源：计算、网络、存储进行统一平台化管理，实践数据驱动运维。在应用运维层面，平台会关注 CPU 和内存资源使用率，为应用提供容量建议，并针对符合条件的应用进行自动扩缩容。

网络管理方面，除了网段和 IP 地址的分配管理，平台也收集丢包、延迟、带宽使用等监控数据，提升网络服务质量。

平台建设的挑战

运维平台初期建设以开发运维工具为主，解决工作中遇到的实际问题：部分机器配置不统一导致线上出问题，宿主机安装配置耗时长且需要人工介入，重要告警淹没在海量的其他告警信息中得不到及时处理。

随着时间推进，平台变得很庞大，工具链很多，工程师需要熟悉多个技术栈。因此需要用产品化的思维来进行运维平台演进，即把运维平台当成产品来设计，不再堆叠各种工具 case by case 解决问题，而是梳理清楚云平台的核心运维管理流程，对未来可能出现的需求进行提前规划。

经过对需求的整理我们发现，容器云运维平台的核心还是在于对核心资源（计算、网络、存储）进行高效管理。提升资源的交付速度，提升工程师对平台的控制力，提升平台基础设施的稳定性，促进知识分享和沉淀，是运维平台存在的意义。

在平台从 Mesos 迁移到 Kubernetes 的过程中，需要做到用户无感知，IP、源信息不变，进行跨系统操作，这个过程中的一些要点有：

同AZ的Mesos迁移到Kubernetes按物理机维度迁移；
拆解迁移过程为多个checkpoint，支持回滚；
使用Stackstorm自动化pipeline。

标准化是自动化运维的基石，其重要性毋庸置疑。我们主要通过工具+流程+巡检三套武器来保证平台的标准化推进。

SaltStack 管控了所有服务器的核心配置文件，用户无法自行修改。SaltStack 配置修改有严密的流程，宿主机上下线也有严格的流程管控。在此基础上，我们建设了自动化巡检工具，定期扫描所有服务器和核心服务的状态和配置信息，一旦有异常立即会发出警告。

自动化运维平台实践

携程容器云自动化运维平台的一些基础运维工作包括：服务器上下线，生产环境异常排查，服务监控，硬件故障维修，应用性能预警，资源管理，容量管理等。

自动化运维平台实现了服务器上下线的自动化，提供工具提升生产环境异常的排查效率，通过运维数据的积累、进行资源使用情况和容量预估。以下是几个实践案例。

智能告警

样例中的第一种类型的告警比较好理解，监控告诉我们 kube-state-metrics 服务连不上了，随后又恢复了，这个时候工程师不需要立即响应，可以事后查一下该服务 up and down 相关日志。第二种类型的告警是在告警发出时，平台进行了关联计算，把可能引发该告警的服务 Error Log 发送在告警信息中，工程师收到告警后点击 Error Log 链接可以查看详情、快速判断故障 Root Cause。

宿主机维护、自动上下线、通知相关用户

随着平台规模大了，也会出现硬件故障需要进行宿主机维修的情况，为了给用户更好的体验，运维平台实现了自动化的通知机制，从流程上保证业务运行的持续性和稳定性，有特殊需求的用户也可以方便的提前介入处理。

容量管理

容量管理往往是老板比较关心的，因为涉及到花钱。每个季度到底投多少钱买宿主机？动态调度的能力有没有？应用有波峰和波谷的，尽量把波峰的应用挫开，我们需要对它进行资源使用情况的预判，这样才能实现弹性计算。

为了实现容量管理我们主要借助了监控系统、 Hadoop 平台以及自己运维的监控工具，最终通过 PAAS 平台实现容器弹性的调度。最终目标是把资源合理利用出去，同时又保证一定的稳定性。

这是我们容量的整体情况，会发现它的内存基本上用的非常满，这个集群它的 CPU 资源也是用的比较满，我们会从一些维度去做整体的分析和个别的分析。

自动化运维平台的规划

携程自动化运维项目中尝试使用了大数据实时计算相关技术(Spark/Spark Streaming)，并通过数据仓库建设，相关模型和算法调整，提升资源使用率和容量预估的准确性。

自动化运维平台整体设计思路不变，即进一步提升对核心资源高效管理的能力，加速运维工程师知识积累和沉淀。同时需要拥抱新技术，比如 AIOps，通过更强大的工具让运维平台有更多的能力。AIOps 概念的产生及周边生态的活跃，对自动化运维平台起到很好的促进作用，运维平台数据和流程的积累可以为后续 AIOps 平台的建设提供支撑，让 AIOps 平台在云平台运维管理中落地。

平台的下一步的规划是云原生运维平台建设，以及混合云运维管理平台建设。

写在最后

在线应用的底层基础设施变更具有一定风险，需要投入较多人力进行迁移方案设计，“给高速飞行中的飞机换零件”，挑战在于：运行中的系统给迁移方案带来了诸多先天限制，原则上只允许成功，不允许失败。现在云计算的发展日新月异，不断有新的技术和架构出现，各领风骚三五年，要求架构师们具备一定的技术前瞻性和敏锐的嗅觉，同时在设计架构时需要考虑底层变更的成本。在技术和工具的选型上，首先需要明确自己所在组织的实际需求，找到最适合自己的；另外如果使用开源方案，那么必然要选择社区活跃度高的。

在 2019 年的背景下，如果没有历史包袱的企业进行运维自动化平台建设，可以尝试基于 Kuberenetes 进行基础平台建设。

从携程的实践经验看，如果从平台设计之初就考虑兼容多种底层架构，那么迁移就会很顺滑。“唯一不变的是变化”。相反，如果设计时就想着一套架构用十年，开弓没有回头箭，底层架构的迁移就无法顺利进行。

作者简介

周昕毅，携程系统研发部云平台高级研发经理。现负责携程容器云平台运维，Cloud Storage 及 Cloud Network 基础设施研发及运维。