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

我们依托私有云和公有云资源，部署多个Kubenretes集群，这些集群有些是承载通用业务，有些是为特定应用专有的集群，在集群维度对云端资源进行调配，包括机房的划分、机型的区分等。在集群之下，我们又根据不同的业务需要，建设不同业务类型的专区，以便做到资源池的隔离来应对业务的需要。更细的维度，我们针对应用层面的资源需求、容灾需求以及稳定性等做集群层的资源调度，最后基于底层不同硬件以及软件，实现CPU、MEM和磁盘等更细粒度的资源隔离和调度。

2.2.3 应用稳定性的提升和治理

不管是VM，还是最初的容器平台，在应用稳定性方面一直都存在问题。为此，我们需要在保障应用的SLA上做出更多的努力。

2.2.3.1 容器复用

在生产环境中，宿主机的发生重启是一种非常常见的场景，可能是主动重启也可能是被动，但用户角度来看，宿主机重启意味着用户的一些系统数据就可能丢失，代价还是比较高的。我们需要避免容器的迁移或重建，直接重启恢复。但我们都知道，在Kubernetes中，对于Pod中的容器的重启策略有以下几种：Always、OnFailure和Never，宿主机重启后容器会重新被创建。

为了解决这个问题，我们为容器的重启策略类型增加了Reuse策略。流程如下：

kubelet在SyncPod时，重启策略如果是Reuse则会获取对应Pod已退出状态的App容器，如果存在则拉起最新的App容器(可能有多个)，如果不存在则直接新建。 更新App容器映射的pauseID为新的pause容器ID，这样就建立了Pod下新的pause容器和原先App容器的映射。 重新拉起App容器即可完成Pod状态同步，最终即使宿主机重启或内核升级，容器数据也不会丢失。

2.2.3.2 Numa感知与绑定

用户的另一个痛点与容器性能和稳定性相关。我们不断收到业务反馈，同样配置的容器性能存在不小的差异，主要表现为部分容器请求延迟很高，经过我们测试和深入分析发现：这些容器存在跨Numa Node访问CPU，在我们将容器的CPU使用限制在同一个Numa Node后问题消失。所以，对于一些延迟敏感型的业务，我们要保证应用性能表现的一致性和稳定性，需要做到在调度侧感知Numa Node的使用情况。

为了解决这个问题，我们在Node层采集了Numa Node的分配情况，在调度器层增加了对Numa Node的感知和调度，并保证资源使用的均衡性。对于一些强制需要绑定Node的敏感型应用，如果找不到合适的Node则扩容失败;对于一些不需要绑定Numa Node的应用，则可以选择尽量满足的策略。

2.2.3.3 其他稳定性优化

在调度层面，我们为调度器增加了负载感知和基于服务画像应用特征的打散和优选策略。

在故障容器发现和处理上，基于特征库落地的告警自愈组件，能够秒级发现-分析-处理告警。

对于一些有特殊资源需求，例如高IO、高内存等应用采用专区隔离，避免对其他应用造成影响。

2.2.4 平台型业务容器化

相信做过ToB业务的同学应该都了解，任何产品都存在大客户方案，那么对于美团这样的公司，内部也会存在这种情况。平台型业务的容器化有个特点是：实例数多，以千或万计，所以资源成本就比较高;业务地位比较高，一般都是非常核心的业务，对性能和稳定性要求很高。所以，如果想要通过“一招鲜”的方式解决此类业务的问题，就有些不切实际。

这里，我们以MySQL平台为例，数据库业务对于稳定性、性能和可靠性要求非常高，业务自己又主要以物理机为主，所以成本压力非常大。针对数据库的容器化，我们主要是从宿主机端的资源分配定制和优化为切入口。

针对CPU资源分配，采用独占CPU集合的方式，避免Pod之间发生争抢。

通过允许自定义SWAP大小来应对短暂的高流量，并关闭Numa Node和PageCache来提升稳定性。

在磁盘分配中采用Pod独占磁盘进行IOPS的隔离，以及通过预分配和格式化磁盘来提升扩容的速度，提升资源交付效率。

调度支持独有的打散策略和缩容确认，规避缩容风险。

最终，我们将数据库的交付效率提升了60倍，并且在大多数情况下性能比之前的物理机器还要好。

2.2.5 业务资源优先级保障

对于一个企业而言，基于成本考虑，资源一直会处于不足的状态，那么如何保障资源的供给和分配就显得非常重要。

业务预算配额确定资源供给，通过专区来做专有资源专用。

建设弹性资源池和打通公有云来应对突发资源需求。

按照业务和应用类型的优先级保障资源使用，确保核心业务先拿到资源。

多个Kubenretes集群和多机房来做容灾，应对集群或机房的故障。

2.2.6 云原生架构的落地

在迁移到Kubernetes之后，我们进一步实现了云原生架构的落地。

为了解决云原生应用管理的障碍，我们设计实现了美团特色的云原生应用管理引擎——KubeNative，将应用的配置和信息管理对平台透明化，业务平台只需要创建原生的Pod资源即可，不需要关注应用的信息同步和管理细节，并支持各PaaS平台自己来扩展控制层面的能力，运行自己的Operator。

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

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