Kubernetes如何改变美团的云基础设施？

下图就是目前我们整个的云原生应用管理架构，已支持Hulk容器平台、Serverless以及TiDB等平台的落地。

2.3 基础设施迁移后的收益

完成全公司业务98%的容器化，显著提升了资源管理的效率和业务稳定性。

Kubernetes稳定性99.99%以上。 Kubernetes成为美团内部集群管理平台的标准。

三、运营大规模Kubernetes集群的挑战和应对策略

在整个基础设施迁移过程中，除了解决历史遗留问题和系统建设，随着Kubernetes集群规模和数量快速增长，我们遇到的新的挑战是：如何稳定、高效地运营大规模Kubernetes集群。我们在这几年的Kubernetes运营中，也逐渐摸索出了一套验证可行的运营经验。

3.1 核心组件优化与升级

我们最初使用的Kubernetes是1.6版本，性能和稳定性是比较差的，当我们达到1K节点的时候就逐渐出现问题，达到5K节点时基本集群不可用。例如，调度性能非常差，集群吞吐量也比较低，偶尔还发生“雪崩”的情况，扩缩容链路耗时也在变长。

针对核心组件的分析和优化，这里从kube-apiserver、kube-scheduler、etcd以及容器等四个方面来概括下。

针对kube-apiserver，为了减少重启过程长时间地发生429请求重试，我们实现了多级的流量控制，将不可用窗口从15min降低为1min，并通过减少和避免外部系统的List操作降低集群负载，通过内部的VIP来做节点的负载均衡，保障控制节点的稳定性。 在kube-scheduler层，我们增强了调度的感知策略，调度效果相比之前更稳定;对调度性能的优化提出的预选中断和局部最优策略也已合并到社区，并成为通用的策略。 针对etcd的运营，通过拆分出独立的Event集群降低主库的压力，并且基于高配的SSD物理机器部署可以达到日常5倍的高流量访问。 在容器层面，容器复用提升了容器的故障容忍能力，并通过精细化的CPU分配提升应用稳定性;通过容器的磁盘预挂载提升Node的故障恢复速度。

另外，社区版本的迭代是非常快的，高版本在稳定性和特性支持上更好，不可避免我们需要进行版本的升级，但如何确保升级成功是一个很大的挑战，尤其是我们在没有足够的Buffer资源进行资源腾挪情况下。

集群升级，业界通用的方案是直接基于原有集群升级，方案存在以下几点问题：

升级版本有限制，不能跨大版本升级：只能一点点从低版本升级到高版本，耗时费力，而且成功率低。 控制平面升级风险不可控：尤其是有API变更的时候，会覆盖之前的数据，甚至是不可回滚的。 用户有感知，容器需要新建，成本和影响较高：这个是比较痛的点，无可避免会发生容器新建。

为此，我们深入研究了Kubernetes对容器层面的控制方式，设计实现了一种能够平滑将容器数据从低版本集群迁移到高版本集群的方案，将集群升级细化为Node粒度的逐个宿主机上容器的原地热升级，随时可以暂停和回滚。新方案主要是通过外部工具将Node和Pod数据从低版本集群迁移到高版本集群，并解决Pod对象和容器的兼容性问题。核心思路是两点：通过低版本兼容高版本的API，通过刷新容器的Hash保障Pod下的容器不会被新;通过工具实现Pod和Node资源数据从低版本集群迁移到高版本集群。

该方案亮点主要包括以下4个方面：

大规模生产环境的集群升级不再是难题。 解决了现有技术方案风险不可控的问题，风险降到了宿主机级别，升级更为安全。 通用性强，可做到任意版本的升级，且方案生命周期长。 优雅地解决了升级过程中容器新建问题，真正做到了原地热升级。

3.2 平台化与运营效率

大规模的集群运营是非常有挑战的事情，满足业务的快速发展和用户需求也是对团队极大的考验，我们需要从不同纬度的考虑集群的运营和研发能力。

在Kubernetes与etcd集群的整个运营和运维能力建设上，我们关注的目标是安全运营、高效运维、标准化管理以及节约成本。所以针对Kubernetes与etcd集群，我们已经完成了平台化的管理运营，覆盖了特性扩展、性能与稳定性、日常运维、故障恢复、数据运营以及安全管控等6个方面。

对于一个非公有云业务的Kubernetes团队，人力还是非常有限的，除了集群的日常运营还有研发任务，所以我们对于运营效率的提升非常关注。我们将日常运维逐步的沉淀转换，构建了一套美团内部的Kubernetes集群管理平台。

将集群的管理标准化、可视化，避免了黑白屏的运维操作。

通过告警自愈和自动巡检将问题处理收敛掉，所以虽然我们有大几十个集群，但我们的运维效率还是比较高的，值班同学很少需要关注。

全部的运维操作流程化，不仅提升了运维效率，人为操作导致的故障的概率也减小了。

通过运营数据的分析进一步做了资源的精细化调度和故障预测，进一步提前发现风险，提升了运营的质量。

3.3 风险控制和可靠性保障

规模大、覆盖业务广，任何的集群故障都会直接影响到服务的稳定性甚至用户的体验，在经历了多次运维故障和安全压力下，我们形成了一套可复制的风险控制和可靠性保障策略。

在整个风险管控链路中，我们分为指标、告警、工具、机制&措施和人员5个层面：

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!