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