摘要：
我們正在經歷現代應用交付領域的第二次浪潮，而Kubernetes 和容器化則是這次浪潮的主要推動力量。
隨著第二次浪潮的推進，我們在NGINX 使用者和已在Kubernetes 集群中成功部署現代應用的客戶中看到了一種通用模式。 我們將這種模式稱為 ClusterOut，它共分為三個階段：
第一階段：構建堅實的Kubernetes 基礎
第二階段：安全地管理集群內外的 API
第三階段：調高集群彈性
感知可控，隨需而變
F5的願景是打造感知可控、隨需而變的應用。 什麼是「感知可控、隨需而變」 的應用？ 我們將應用想像成一個生物體，它們能夠自主擴展、縮小、自我修復和防禦，説明減少對持續人工干預的需求。
我強調”自主”一詞是有原因的。 隨著新一代數位服務的誕生，底層應用必須擺脫人工操作的速度限制。 它們必須足夠智慧才能根據上下文和條件適應環境。 它們必須自己做出改變，就像生物體一樣。
我們正在探索如何讓機器學習支援自適應智慧。 但羅馬不是一日建成的，我們還要付出很多努力。 以下是我們對感知可控、隨需而變的應用發展道路的設想，以及通過技術發佈和產品路線圖來實現願景的思路。
現代應用交付領域的三次浪潮
我們認為現代應用交付領域將經歷三次浪潮。 第一次浪潮主要是實現大規模併發和擴展。 NGINX 便問世於這次浪潮中，為 Web 級應用的興起而生。
第二次浪潮（也就是我們正在經歷的浪潮）是應用解耦為微服務並通過API 進行連接，以加深分散式程度和提高彈性。 Kubernetes 和容器化是這次浪潮的主要推動力量，最初隨著雲計算的增長而嶄露頭角。
這波浪潮還極大地推動了自動化技術的發展，第一代感知可控、隨需而變的應用應運而生。 自適應行為既可以像自動擴展一樣簡單，也可以像策略引擎一樣複雜，其中策略引擎通過觀察 API 和應用的執行方式進行自我糾正。
第二次浪潮為第三次波浪潮奠定了基礎。 第三次浪潮將賦予應用更高級的智慧性和機器學習能力，讓它們能夠感知環境，並真正實現無人工干預的自適應。
Cluster Out——K8s應用部署的通用模式
隨著第二次浪潮的推進，我們在 NGINX 使用者和已在 Kubernetes 集群中成功部署現代應用的客戶中看到了一種通用模式。 我們將這種模式稱為 Cluster Out，它共分為三個階段，如下圖所示。
第一階段構建堅實的 Kubernetes 基礎
許多企業仍在緊鑼密鼓地部署 Kubernetes 和容器。 其實，一個好的生產級 Kubernetes 平臺，需要進行深思熟慮的定製和調整。 儘管 Kubernetes 是一款強大的多用例通用平臺，但開箱即用的特性還是導致它缺乏部署、管理和保護生產應用所需的應用交付和應用安全功能。
最重要的是，如果 Kubernetes 生產環境不穩定，開發人員就不願意在這裡部署代碼。 為了增強開發人員的信心，您必須為 Kubernetes 生產環境添加七層網路、可觀察性和安全性。 您可以通過 Ingress 控制器、WAF 和服務Service mesh並結合其他雲原生專案（例如 Prometheus）來解決這一挑戰。
第二階段安全地管理集群內外的 API
只要您擁有優秀的生產級 Kubernetes 環境，開發人員就願意在這裡部署更多代碼。 這就是我們常說的”栽下梧桐樹，引得鳳凰來”。 您會發現，微服務和應用的數量正在快速增長，它們與集群內的其他服務、集群外的用戶端和應用進行通信所用的 API 數量也是如此。 內部（服務到服務）API 調用次數通常是外部（應用到客戶端）調用的 10 倍或更多倍。
隨著應用環境的擴張，一系列讓 Kubernetes 平台無法應對的新挑戰不斷湧現，包括要求更複雜的 API 身份驗證、授權、路由/整形和生命週期管理等。 複雜的環境可能有成百上千個 API，因此擁有可説明您對 API 進行保護、管理、版本控制和棄用的工具至關重要。 在 Cluster Out 的這個階段，您需要 API 閘道、API 管理和 API 安全工具等技術，它們能夠隨著開發人員做出的調整持續擴展服務，並進一步增強應用功能。
第三階段提高集群彈性
實施 Cluster Out 模式的第三個階段是考慮如何將 Kubernetes 環境與其他環境連接起來，無論這些環境是其他集群還是虛擬機或裸機上的應用部署。 畢竟，我們現在設計的是分散式、鬆散耦合和富有彈性的雲原生應用。
現代應用必須至少能夠跨多個 Kubernetes 集群進行通信，從而實現更高級別的彈性並實施更智慧的策略（例如成本控制策略）。 而從廣泛意義上來說，現代應用很少是孤島。 它們更有可能被融合到一個由外部服務、存儲桶和合作夥伴 API（可能位於其他環境）組成的網路中。 即使在內部，複雜的應用也可能需要與不同集群、可用區或數據中心的其他內部應用進行通信。
在這個階段，開箱即用的 Kubernetes 仍然未能解決其所面臨的挑戰。 您需要將 Kubernetes 邊界（即Ingress Controller）自動連接到外部技術，例如四層負載均衡器、應用交付控制器和 DNS 服務，從而路由流量和處理故障轉移。
實際上，Cluster Out 模式只是我們從 Kubernetes 早期採用者身上看到的一個成功秘訣。 作為一個優先順序框架，Cluster Out 是在企業環境中大規模運行容器的邏輯和方法，能夠説明您更有效地採用 Kubernetes 和現代應用。 這種方法的強大之處在於，它為平台團隊提供了一種系統方法，支援 Kubernetes 在生產環境中的使用。
作者：RobertWhiteley
職位：F5 NGINX 總經理