云原生最佳实践 | 梅赛德斯-奔驰如何提高其K8s平台的稳定性和可扩展性？

导读：当前，云原生已成为企业实现应用现代化、抢占数字化转型先机的最佳路径。因此我们开设「云原生案例集锦」栏目，深入剖析企业如何利用云原生技术来赋能业务增长。

本篇文章介绍了全球最成功的汽车公司之一梅赛德斯-奔驰如何将其Kubernetes集群管理扩展到公共云中，实现自动化集群创建和更快的滚动升级。

业务挑战

梅赛德斯-奔驰是全球最成功的汽车公司之一。作为梅赛德斯-奔驰的全资子公司，梅赛德斯-奔驰技术创新有限公司与梅赛德斯-奔驰合作，开发数字产品和软件解决方案。Kubernetes是我们技术栈中至关重要的组成部分，并且我们从v0.9版本开始就一直依赖它。然而，在我们采用Kubernetes时，并没有现成的Kubernetes集群管理解决方案可用，因此我们不得不自己创建解决方案。

我们组织的Kubernetes集群，在基于本地IaaS的托管OpenStack上快速增长。我们曾使用自编写的Terraform流水线来创建基础架构和Kubernetes集群，但这变得过于复杂，几乎无法管理。因此，我们需要一种更简化的解决方案。此外，我们希望为AWS等公共云环境做好准备，因为我们计划提供多云设置。

解决方案

在调研了各种选择后，我们决定迁移到Cluster API，这是一个Kubernetes项目，为配置和管理Kubernetes集群提供了声明式API。Cluster API使我们能够使用Kubernetes本身来管理我们的集群。它为我们的30名开发人员和平台工程师团队提供了更一致的体验，因为它减少了完成工作所需的框架和工具的数量。此外，Cluster API旨在跨不同的云提供商和基础架构上运行，这意味着无论集群在哪里运行，我们都可以使用相同的工具和工作流来管理它们。

采用Cluster API对我们的Kubernetes平台产生了深远的影响。其中最显著的好处之一是使用了协调循环(reconciliation loops)，它取代了我们以前使用Terraform和传统流水线的旧有集群生命周期。这使我们能够始终了解我们基础架构的状态，并消除了可能出现的个性化手动更改或问题。通过协调循环，我们发现将新的变更部署到我们的Kubernetes集群所需的时间大大减少，从而加快了我们向用户交付的速度。

此外，我们成功地测试了滚动升级，只需触发一次即可，从而减少了流水线的重新启动需求。对我们来说，这是一个重大的胜利，因为我们可以确保服务的高可用性，避免停机时间并最小化对用户的干扰。

“得益于Cluster API，Kubernetes的滚动升级现在更加顺畅。这对于依赖PodDisruptionBudgets（PDB）确保应用程序可用性的用户尤为有利。在故障转移期间，如果某个Pod无法准备就绪，我们的传统流程需要在问题解决后重新运行升级作业。然而，借助Cluster API及其持续的协调循环，一旦Pod准备就绪，升级过程可以立即恢复，从而将停机时间降至最低并减少升级失败的风险。”—Tobias Giese, 软件工程师, Mercedes-Benz Tech Innovation GmbH

对于我们来说，使用可插拔的Cluster API云提供商是另一个重大突破。我们能够更轻松、更快速地引入新的公共云，使我们能够快速高效地扩展我们的Kubernetes基础架构。

Cluster API的另一个重要优点是其开源性质。通过利用开源项目，我们能够专注于核心业务，同时依赖于更广泛社区的贡献和支持。项目的协作性质还使我们能够向行业中的其他人学习，获得新的见解，并构建更好的解决方案。我们能够为开源和CNCF社区做出贡献，从而回馈并帮助行业中的其他人。

最后，Cluster API使我们能够显著扩展我们的Kubernetes基础架构。我们最初使用Terraform管理200个集群，但管理变得难以应付。如今，我们拥有近1000个集群，都通过Cluster API和多个管理集群高效管理。现在，我们可以轻松管理基础架构，知道我们拥有一个可扩展和可靠的系统。

总而言之，Cluster API为我们带来了许多好处。我们能够消除不一致性，缩短部署时间，执行滚动升级，更快地引入新的云，标准化我们的基础架构，并利用开源的力量。

我们的理念：一切皆自助服务

在梅赛德斯-奔驰及其子公司，如梅赛德斯-奔驰科技创新公司，我们将缩短上市时间作为首要任务，并相信赋予团队自助解决方案的力量。为了实现这一目标，我们采用了FOSS（自由开源软件）优先策略。通过采用自助服务和FOSS优先的方法，我们成功地减少了例行基础设施任务所需的时间，并将重点放在为用户提供价值上。最终，这将使我们平台的用户能够专注于他们的核心业务，而不会花费时间应对基础设施相关的挑战。

一切皆自助服务意味着我们努力通过API和用户界面使所有资源可用，为用户提供灵活性，让他们按照自己的需求管理自己的资源。例如，我们通过OpenStack云控制器管理器（OCCM）处理本地负载均衡器，使用户能够通过类型为LoadBalancer的Kubernetes服务轻松提供和管理负载均衡器。

类似地，我们对防火墙的处理方式是在集群内维持一个拒绝所有策略，同时允许用户根据需要通过NetworkPolicies开放端口。此外，我们还通过为类型为LoadBalancer的Kubernetes服务使用loadBalancerSourceRanges，增加了限制入口流量仅来自特定IP CIDR的能力。

为进一步增强自助服务，我们开发了一个API，为用户提供管理自己集群的接口。这个API由一个用户友好的用户界面支持，方便用户轻松管理集群。

请注意：所有的数值都是示例值，不反映实际的集群信息。

最后，为了确保我们的集群安全并符合最佳实践，我们使用像我们定制的CaaS Inspector这样的工具，它基于Popeye来检查我们的集群，并确定需要改进的方面。根据我们的经验和行业最佳实践，CaaS Inspector会为集群计算一个得分，提供对集群配置的整体状况的洞察。

接下来，我们对于使用Cluster API的下一步非常兴奋，特别是在利用Cluster API Runtime SDK来进一步增强我们的集群管理系统的能力。

此外，我们正在探索使用FluxCD进行GitOps，以便将指标导出器或自定义控制器等附加组件部署到工作负载集群中。虽然目前我们仍依赖Ansible来实现这一目的，但GitOps将允许我们对这些附加组件进行协调，以实现更高效的版本控制和管理。

此外，我们计划构建一个定制的集群控制器，负责处理集群的所有必要元信息以及在Cluster API可以提供集群之前必须创建的基础设施。这将为我们提供更大的灵活性和对集群管理系统的控制，并帮助我们进一步优化工作流程，提高我们的Kubernetes集群的稳定性和可扩展性。

企业收益

采用Cluster API对我们的Kubernetes平台带来了革命性的变化。我们能够消除特例情况，减少部署时间，进行滚动升级，更快地接入新的云平台，标准化我们的基础架构，并充分利用开源的力量。