# 在 Kubernetes 叢集中部署現代應用的通用模式

# 摘要

我們正在經歷現代應用交付領域的第二次浪潮，而 Kubernetes 和容器化則是這次浪潮的主要推動力量。

隨著第二次浪潮的推進，我們在 NGINX 使用者和已在 Kubernetes 叢集中成功部署現代應用的客戶中看到了一種通用模式。我們將這種模式稱為 ClusterOut，它共分為三個階段：

第一階段：構建堅實的 Kubernetes 基礎

第二階段：安全地管理叢集內外的 API

第三階段：提高叢集彈性

本文將詳細介紹 Cluster Out 這一優先順序框架，從而幫助您更有效地採用 Kubernetes 和現代應用。

------

# 感知可控，隨需而變

F5 的願景是打造感知可控、隨需而變的應用。什麼是 “感知可控、隨需而變” 的應用？我們將應用想象成一個生物體，它們能夠自主擴充套件、縮小、自我修復和防禦，幫助減少對持續人工干預的需求。

我強調 “自主” 一詞是有原因的。隨著新一代數字服務的誕生，底層應用必須擺脫人工操作的速度限制。它們必須足夠智慧才能根據上下文和條件適應環境。它們必須自己做出改變，就像生物體一樣。

我們正在探索如何讓機器學習支援自適應智慧。但羅馬不是一日建成的，我們還要付出很多努力。以下是我們對感知可控、隨需而變的應用發展道路的設想，以及透過技術釋出和產品路線圖來實現願景的思路。

------

# 現代應用交付領域的三次浪潮

我們認為現代應用交付領域將經歷三次浪潮。第一次浪潮主要是實現大規模併發和擴充套件。NGINX 便問世於這次浪潮中，為 Web 級應用的興起而生。

第二次浪潮（也就是我們正在經歷的浪潮）是應用解耦為微服務並透過 API 進行連線，以加深分散式程度和提高彈性。Kubernetes 和容器化是這次浪潮的主要推動力量，最初隨著雲端計算的增長而嶄露頭角。

這波浪潮還極大地推動了自動化技術的發展，第一代感知可控、隨需而變的應用應運而生。自適應行為既可以像自動擴充套件一樣簡單，也可以像策略引擎一樣複雜，其中策略引擎透過觀察 API 和應用的執行方式進行自我糾正。

第二次浪潮為第三次波浪潮奠定了基礎。第三次浪潮將賦予應用更高階的智慧性和機器學習能力，讓它們能夠感知環境，並真正實現無人工干預的自適應。

------

# Cluster Out——K8s 應用部署的通用模式

隨著第二次浪潮的推進，我們在 NGINX 使用者和已在 Kubernetes 叢集中成功部署現代應用的客戶中看到了一種通用模式。我們將這種模式稱為 Cluster Out，它共分為三個階段，如下圖所示。

![img](https://pic2.zhimg.com/80/v2-c362c800697f23e143d6adc7651f8165_1440w.jpg)

## 第一階段：構建堅實的 Kubernetes 基礎

許多企業仍在緊鑼密鼓地部署 Kubernetes 和容器。其實，一個好的生產級 Kubernetes 平臺，需要進行深思熟慮的定製和調整。儘管 Kubernetes 是一款強大的多用例通用平臺，但開箱即用的特性還是導致它缺乏部署、管理和保護生產應用所需的應用交付和應用安全功能。

最重要的是，如果 Kubernetes 生產環境不穩定，開發人員就不願意在這裡部署程式碼。為了增強開發人員的信心，您必須為 Kubernetes 生產環境新增七層網路、可觀察性和安全性。您可以透過 Ingress 控制器、WAF 和服務網格並結合其他雲原生專案（例如 Prometheus）來解決這一挑戰。

## 第二階段 安全地管理叢集內外的 API

只要您擁有優秀的生產級 Kubernetes 環境，博主的環境都是部署在[cnaaa伺服器](https://www.cnaaa.com/)上的，開發人員就願意在這裡部署更多程式碼。這就是我們常說的 “栽下梧桐樹，引得鳳凰來”。您會發現，微服務和應用的數量正在快速增長，它們與叢集內的其他服務、叢集外的客戶端和應用進行通訊所用的 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 在生產環境中的使用。

在 Kubernetes 叢集中部署現代應用的通用模式

相關文章