为了在竞争中保持领先地位，各组织不断寻求以快速和敏捷的方式推动创新，同时最大化运营和经济效率。为此，他们已经将应用程序迁移到多云和混合云环境已有相当一段时间了。
最初，这些应用程序使用“lift-and-shift”的方法迁移到云，保留了它们原来的单体架构。然而，这种单体应用程序无法充分利用云提供的优势，如弹性和分布式计算，并且也难以维护和扩展。
因此，作为下一个进化步骤，组织已经开始重新构建其现有的单体应用程序或开发新的容器化应用程序。
然而，部署和管理容器化应用程序是一项复杂的任务，这就是Kubernetes的用武之地。Kubernetes（也称为K8s），这个最初由谷歌开发的容器编排工具，已迅速成为在公共和私有云中部署容器化应用程序的首选平台。
通过使用K8s，组织能够在公共和私有云中成功地初步部署和管理这些容器化应用程序。然而，他们在随后的步骤中遇到了困难，例如以简单和自动化的方式让最终用户可以从外部访问Kubernetes应用程序，同时仍然保留控制权，以确保安全可靠地访问这些应用程序。
其主要原因是，用于前端这些应用程序并使其可供最终用户访问的传统负载均衡器在设计时考虑了单体应用程序，因此无法跟上部署这些Kubernetes应用程序的敏捷方式。
这些负载均衡器是为部署过程而设计的，在该过程中，应用程序的网络资源由网络和安全团队手动配置，该过程可能需要几天甚至几周，然后在负载均衡器上手动配置。这个过程显然不适合与Kubernetes应用程序的部署过程同步，从而成为整个部署过程中的瓶颈。
进一步加剧这个问题的是，在多云和混合云环境中部署应用程序时，每个公共云提供商都有自己的自定义负载均衡器和管理系统。
例如，AWS有自己的弹性负载均衡解决方案，它不同于Microsoft的Azure负载均衡器。这使得自动化应用程序部署的任务更加复杂和耗时。它还使得在不同的云环境中应用一致的策略集的任务容易出错，因为每个负载均衡器都有自己的独立配置和操作。
那么，解决方案是什么？
为了跟上Kubernetes应用程序的部署，需要一种访问解决方案，使负载均衡器能够在部署和扩展这些应用程序时动态管理它们。
实现这一点的一种方法是部署入口控制器或连接器代理，将外部负载均衡器连接到Kubernetes应用程序。这种连接器可以监控这些应用程序的生命周期，并使用信息自动更新负载均衡器，以将流量路由到它们。这将极大地简化和自动化配置外部负载均衡器的过程，因为新服务部署在K8s集群中，从而消除与手动配置过程相关的延迟。
除了支持外部负载均衡器的动态和自动配置外，解决方案理想情况下还应具有以下属性：
- 云不可知：当部署在单个云中时，上述过程可以工作，但要真正使其在多云和混合云环境中工作，解决方案应该以不同的形式提供，如物理、虚拟和容器，以便可以在公共和私有云中部署。拥有跨不同云环境一致工作的解决方案还提供了相关的好处，即能够应用一组一致的策略来访问应用程序，而不管应用程序运行在哪个云中。这将导致更安全的部署，并避免在将配置从一个云部署移植到另一个部署时出现潜在错误。
- 支持自动化工具：解决方案应支持自动化工具，如Terraform、Ansible和Helm，以便整个应用程序部署和日常操作过程可以自动化。
- 灵活的许可模式：该解决方案应提供软件订阅模式，使组织能够通过跨多个站点分配和分配容量来优化成本，以适应不断变化的业务和应用需求。
- 集中式可视性和分析：最后，解决方案应提供集中式可视和分析。这将实现主动故障排除和快速根本原因分析，从而提高应用程序的正常运行时间，以确保最终用户的满意度。
将应用程序作为容器化应用程序迁移到多云和混合云环境有许多好处，包括更高的灵活性和操作效率。然而，遗留负载均衡器是为管理单体应用程序而构建的，可能会阻碍部署容器化应用程序，从而阻碍访问云部署的全部好处。
此外，使用特定于云的负载平衡器会增加管理混合云基础设施的复杂性。通过部署连接到外部负载平衡器的入口控制器或连接器代理，IT团队可以在K8s集群内部署新服务时更有效地简化和自动化配置外部负载均衡器的过程。
原文链接：https://thenewstack.io/kubernetes-applications-for-multicloud-hybrid-cloud-environs/
