為了在競爭中保持領先地位，各組織不斷尋求以快速和敏捷的方式推動創新，同時最大化運營和經濟效率。為此，他們已經將應用程序遷移到多云和混合云環境已有相當一段時間了。

　　最初，這些應用程序使用“lift-and-shift”的方法遷移到云，保留了它們原來的單體架構。然而，這種單體應用程序無法充分利用云提供的優勢，如彈性和分布式計算，并且也難以維護和擴展。

　　因此，作為下一個進化步驟，組織已經開始重新構建其現有的單體應用程序或開發新的容器化應用程序。

　　然而，部署和管理容器化應用程序是一項復雜的任務，這就是Kubernetes的用武之地。Kubernetes(也稱為K8s)，這個最初由谷歌開發的容器編排工具，已迅速成為在公共和私有云中部署容器化應用程序的首選平臺。

　　通過使用K8s，組織能夠在公共和私有云中成功地初步部署和管理這些容器化應用程序。然而，他們在隨后的步驟中遇到了困難，例如以簡單和自動化的方式讓最終用戶可以從外部訪問Kubernetes應用程序，同時仍然保留控制權，以確保安全可靠地訪問這些應用程序。

　　其主要原因是，用于前端這些應用程序并使其可供最終用戶訪問的傳統負載均衡器在設計時考慮了單體應用程序，因此無法跟上部署這些Kubernetes應用程序的敏捷方式。

　　這些負載均衡器是為部署過程而設計的，在該過程中，應用程序的網絡資源由網絡和安全團隊手動配置，該過程可能需要幾天甚至幾周，然后在負載均衡器上手動配置。這個過程顯然不適合與Kubernetes應用程序的部署過程同步，從而成為整個部署過程中的瓶頸。

　　進一步加劇這個問題的是，在多云和混合云環境中部署應用程序時，每個公共云提供商都有自己的自定義負載均衡器和管理系統。

　　例如，AWS有自己的彈性負載均衡解決方案，它不同于Microsoft的Azure負載均衡器。這使得自動化應用程序部署的任務更加復雜和耗時。它還使得在不同的云環境中應用一致的策略集的任務容易出錯，因為每個負載均衡器都有自己的獨立配置和操作。

　　那么，解決方案是什么?

　　為了跟上Kubernetes應用程序的部署，需要一種訪問解決方案，使負載均衡器能夠在部署和擴展這些應用程序時動態管理它們。

　　實現這一點的一種方法是部署入口控制器或連接器代理，將外部負載均衡器連接到Kubernetes應用程序。這種連接器可以監控這些應用程序的生命周期，并使用信息自動更新負載均衡器，以將流量路由到它們。這將極大地簡化和自動化配置外部負載均衡器的過程，因為新服務部署在K8s集群中，從而消除與手動配置過程相關的延遲。

　　除了支持外部負載均衡器的動態和自動配置外，解決方案理想情況下還應具有以下屬性：

　　——云不可知：當部署在單個云中時，上述過程可以工作，但要真正使其在多云和混合云環境中工作，解決方案應該以不同的形式提供，如物理、虛擬和容器，以便可以在公共和私有云中部署。擁有跨不同云環境一致工作的解決方案還提供了相關的好處，即能夠應用一組一致的策略來訪問應用程序，而不管應用程序運行在哪個云中。這將導致更安全的部署，并避免在將配置從一個云部署移植到另一個部署時出現潛在錯誤。

　　——支持自動化工具：解決方案應支持自動化工具，如Terraform、Ansible和Helm，以便整個應用程序部署和日常操作過程可以自動化。

　　——靈活的許可模式：該解決方案應提供軟件訂閱模式，使組織能夠通過跨多個站點分配和分配容量來優化成本，以適應不斷變化的業務和應用需求。

　　——集中式可視性和分析：最后，解決方案應提供集中式可視和分析。這將實現主動故障排除和快速根本原因分析，從而提高應用程序的正常運行時間，以確保最終用戶的滿意度。

　　將應用程序作為容器化應用程序遷移到多云和混合云環境有許多好處，包括更高的靈活性和操作效率。然而，遺留負載均衡器是為管理單體應用程序而構建的，可能會阻礙部署容器化應用程序，從而阻礙訪問云部署的全部好處。

　　此外，使用特定于云的負載平衡器會增加管理混合云基礎設施的復雜性。通過部署連接到外部負載平衡器的入口控制器或連接器代理，IT團隊可以在K8s集群內部署新服務時更有效地簡化和自動化配置外部負載均衡器的過程。