【51CTO.com快译】
作者丨Emile Vauge
译者丨崔皓
策划丨孙淑娟
随着互联网的发展，人们生活的方方面面不断转移到线上，而且人们的线上需求向互联网扩展的趋势越发明显。这种趋势始于多年前(可以说是在互联网繁荣时期)，趋势的形成也见证了技术的更迭。
AWS 于 2002 年作为第一个公有云产品被推出时，就为企业打开了一扇大门，透过这扇门，企业可以将 IT 运维工作交给 AWS 完成，并根据 IT 服务情况对硬件资源进行灵活调整。虚拟机的应用将应用软件从硬件层面抽象出来，这种方式对应用部署模式提出了新的要求。
为什么应该使用微服务架构
微服务被认为是独立且松耦合服务的集合，它们可以独立于部署环境进行维护和配置。这种特性使它们可以被打包到容器中进行大规模部署(2014 年由 Docker 商品化)，由此容器技术正在成为新一代分布式基础设施的组成部分。
Rancher、Docker Swarm 和 Mesos 等不同技术竞相在容器编排中占据领先地位。但最终 Kubernetes(由 Google 于 2014 年开源)在容器化微服务领域独占鳌头。
虽然对于企业而言 Kubernetes 的优势明显，但其固有的复杂性和陡峭的学习曲线却让人望而却步。这也是为什么小公司由于缺乏运维知识和运维资源，无法应用大型技术栈并使其发挥作用的原因。而大企业面临的困难是难以将云原生工具和处理流程集成到旧有的基础设施中。
应对 Kubernetes 的复杂性
多年来，业界出现了多种解决方案，旨在帮助企业应用 Kubernetes 并优化容器编排。Rancher、OpenShift 和公有云托管服务(例如 Azure Kubernetes Service、Elastic Kubernetes Service 和 Google Kubernetes Engine)就是很好的例子。这些解决方案极大地降低了 Kubernetes 集群部署和管理的难度，加速了企业采取云原生应用的进程，同时使所部署的应用更具伸缩性和扩展性。
出于以上原因 Kubernetes 在业内获得了广泛的应用。2021 年为了了解 Kubernetes 的使用情况，Traefik Labs 调查了 1,000 多名 IT 专业人士。调查中，超过 70% 的受访者表示将 Kubernetes 用于商业项目。然而，企业虽然克服了容器部署的困难，但在扩展部署方面又面临新的阻碍。
随着 Kubernetes 持续被应用，新的挑战接踵而至。企业需要支持更多更大的 Kubernetes 集群，从而满足越来越多的容器化应用的需求。然而，更多的集群意味着更多的组件需要被管理和更新。在单个 Kubernetes 部署中相对容易解决的问题，放到更大的多集群环境中就会被成倍放大。Kubernetes 的复杂性随着集群的不断扩展也被急剧加深。因此，多集群编排不可避免地成为工程师要解决的下一个前沿问题。
Kubernetes 多集群需求
开发人员需要趁手的工具来管理多集群，从上下文报警到新的部署策略的方方面面都是如此。让我们将管理工具进行如下分析：
- Federation 工具提供了一种机制，用于管理多个 Kubernetes 集群以及集群对应的配置信息。托管的集群会提供一组 API 用来协调分布式环境的多个 Kubernetes 集群的配置，就是 Federation 会针对管理的多个 Kubernetes 集群提供一组 API 来管理这些集群和它们对应的配置。基于多集群的联合云技术可以支持两个或多个不同位置的计算云互连，使运维团队更容易处理复杂的多集群问题。
- 想让多个集群像单独个体一样工作是非常复杂的事情，不过连通性可以让梦想成真。使用正确的工具可以有效处理集群互连、控制集群路由、使跨区域的分布式池负载均衡(使用全局服务器负载平衡或 GSLB - Global Server Load Balancing)，以及管理跨越多个集群的应用更新。
- 安全问题在复杂的分布式环境中显得更加复杂，幸运的是可以使用云原生安全工具和对应的处理流程来解决。我们不禁要问，如何处理零信任环境中的安全问题?如何管理每个连接端到端的加密?如何控制对应用程序的访问?如何在分布式基础架构中管理 TLS 证书?只有把关于安全解决方案集成到集群中，分布式应用才变得更加安全。
- 可观察性使您可以快速查看分布式基础架构的大图，从而可以快速发现和诊断问题。Grafana 和 Prometheus 就是为此目的所打造的工具，并且在业内得到广泛使用。随着部署的集群数量的增加，系统中的问题也层出不穷，因此可观察性和上下文报警就变得尤为重要。拥有适合的工具能让开发人员准确地查看问题，从而保证应用程序顺利运行，同时还节省了猜测问题的宝贵时间。
Kubernetes 多集群的未来
确保集群、服务和网络流量在云原生世界中协同工作是一项巨大挑战。Kubernetes 赢得了“容器编排”的战争，并持续被世界各地的组织广泛采用。但随着日趋成熟的技术不断涌现，新的问题和新的挑战也接踵而至，使得多集群应用部署变得更加复杂。
没有人想再管理 Kubernetes 了，使用 Kubernetes 的门槛需要降低。
工作在 Kubernetes 上的开发、工程和运维团队(包括所有技术级别)，为了更好地构建和操作应用程序，需要更简单的方法来实现集群和网络的可见性、可扩展性和安全性。开发人员在寻找微服务管理工具的过程中，必须优先考虑工具的即时可观察性、开箱即用的上下文报警功能、地理感知内容交付(译者：在多个集群部署的情况下，由于集群中部署的服务有可能会互相调用。所以，需要按照地理位置在同一个地方的集群中的服务互相调用。也就是服务会去调用同一个集群中的服务，尽量不去做跨集群的服务，尽管这种跨集群的调用是可能的，但是效率不高。这里说的地理感知就是指服务调用会通过地理上的位置感知要调用的其他服务，而被调用的服务将需要交付的内容提供给调用者。DNS 也是实现了这种地理感知内容交付的。)以及内置服务网格等功能。
多集群编排的挑战正变得越来越普遍，但通过使用正确的工具适应云原生世界，但如果开发和运营团队将能够使用合适的工具应用于云原生世界，就可以解决多集群 Kubernetes 的 复杂问题，并收获 Kubernetes 带来的巨大成果。
译者介绍
崔皓，51CTO 社区编辑，资深架构师，拥有 18 年的软件开发和架构经验，10 年分布式架构经验。曾任惠普技术专家。乐于分享，撰写了很多热门技术文章，阅读量超过 60 万。《分布式架构原理与实践》作者。
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
