微服務架構通常會與容器和 Kubernetes 技術結合，能夠縮短業務上市時間、提升數位體驗，進而推動業務增長和技術創新。 無論是搭配使用傳統架構還是獨立使用，這些現代應用技術都可以顯著改善可擴展性、靈活性和部署速度，甚至節省成本。
在 2020 年之前，我們發現大多數客戶已開始採用微服務作為其數位化轉型戰略的一部分，但疫情極大地推動了應用的現代化步伐。 我們在 2020 年 對 NGINX 用戶進行的一項調查發現，60% 的受訪者在生產環境中使用微服務，較 2019 年 （40%） 有所上升，容器的受歡迎程度是其他現代應用技術的 2 倍多。
Kubernetes 是公認的容器化應用管理標準。 as evidenced by the 雲原生計算基金會 （CNCF） 在 2020 年進行的一項調查發現，91% 的受訪者正在使用 Kubernetes ，其中83%在生產環境中使用。 許多企業在採用Kubernetes 時已經做好了進行重大架構變更的準備，但大規模運行現代應用技術對企業帶來的影響卻是他們沒有想到的。 如果您正在運行 Kubernetes，您可能已經遇到了以下三個攸關業務的障礙：
- 文化
即使應用團隊採用了敏捷開發和 DevOps 這樣的現代方法，他們通常也擺脫不了康威定律，即“企業對於系統架構的設計，往往反映了該企業自身的溝通形態” 。 換句話說，分散式應用由獨立運轉但資源分享的分散式團隊開發。 雖然這種溝通形態能夠有效提高團隊的工作效率，但同時也容易形成孤島，進而出現溝通低效（這將導致其他負面結果）、安全漏洞、工具蔓延、自動化實踐不一致以及團隊衝突等問題。 - 複雜性
企業要想實施企業級微服務技術，就必須將一套關鍵元件組合在一起，以實現可視化、安全性和流量管理。 通常，團隊會使用基礎架構平臺、雲原生服務和開源工具來滿足這一需求。 雖然每個策略都各有所用，但也都各有不足，可能會造成出現複雜性。 同一企業結構內的不同團隊常常會選擇不同的策略來滿足相同的要求，從而導致「運營債務」。。 此外，各個團隊一旦在某個時間點選擇了某個流程和工具，那麼無論使用容器部署和運行現代微服務應用的需求如何變化，他們都會繼續使用下去
The CNCF Cloud Native Interactive Landscape（雲原生基金會的交互全景圖） 清楚地說明了支援微服務應用的必要基礎架構的複雜性。 企業需要精通各種不同的技術，這會造成基礎架構鎖定、IT 無處不在、工具蔓延以及基礎架構維護人員學習難度加大等。
- 安全性
雲原生應用和傳統應用的安全性需求存在明顯不同，因為 Kubernetes 中不存在「圍欄」（ring‑fenced）策略。 龐大的生態系統和容器化應用的分散式特性意味著攻擊面更為廣泛，而對外部 SaaS 應用的依賴則意味著員工和外部人員注入惡意代碼或洩露信息的機會大幅增加。 此外，文化和複雜性部分（尤其是工具蔓延）中提到的後果將直接影響到現代應用的安全性和彈性。 在生態系統中使用不同的工具解決相同的問題不僅效率低下，而且給 SecOps 團隊帶來了巨大的挑戰，他們必須學習如何正確地配置每個元件。
解決方案：生產級 Kubernetes
與大多數企業結構問題一樣，解決 Kubernetes 挑戰的方法是將技術和流程相結合。 接下來我們將主要討論技術元件，有關流程及其他主題請關注後續文章。
Kubernetes 是一種開源技術，實現生產級 Kubernetes 的方式有很多。 雖然一些企業更喜歡配置適合自己的Kubernetes，但許多企業發現，Amazon Elastic Kubernetes Service（EKS）、Google Kubernetes Engine （GKE）、Microsoft Azure Kubernetes Service（AKS）、Red Hat OpenShift 容器平臺 及 Rancher 等服務可提供出色的靈活性、規範性及強大的支援。
Kubernetes 平臺支援服務輕鬆啟動和運行，但是它們關注的是服務廣度而非深度。 您可以一站式獲齊所需的所有服務，但無法獲得大規模生產所需的所有功能。 具體來說，它們不關注進階網路功能和安全性，而這正是許多客戶對 Kubernetes 不滿意的地方。
要實現生產級 Kubernetes，您需要按照以下順序添加三個元件：
1.可擴展的 ingress/egress 層，用於控制進出集群的流量
這是通過 Ingress 控制器實現的。 Ingress 控制器是一個專用負載均衡器，能夠將 Kubernetes 網路的複雜性抽象出來，並在 Kubernetes 集群內部的服務和外部之間建立了一座橋樑。 如果該元件包含有助於提高彈性（例如進階健康檢查和 Prometheus 指標）、快速擴展（動態重新配置）和自助服務（基於角色的存取控制 （RBAC））的特性，它就變成了生產級元件。
2.內置安全防護，防範整個集群中的威脅
雖然集群外部可能只要有“粗粒度”的安全防護就夠了，但集群內部必須要有“細粒度”安全防護。 根據集群的複雜程度，您可能需要在以下三個位置部署靈活的 Web 應用防火牆（WAF）：在 Ingress 控制器上、為每個service 進行代理、為每個 pod 進行代理。 通過這種靈活性，您可以對敏感應用實施更嚴格的控制（例如在計費方面），並對低風險應用放寬控制。
3.可擴展的東西向流量層，用於優化集群內的流量
一旦 Kubernetes 應用的複雜性和規模超出基本工具的處理能力範圍，就需要使用這第三個元件。 在該階段，您需要一個服務網格，這是一種編排工具，可為集群內的應用服務提供更細粒度的流量管理和安全性。 服務網格通常負責管理容器化應用之間的應用路由，提供和實施自動的服務到服務的雙向 TLS （mTLS） 策略，並讓應用的可用性和安全性變得可視化。
在選擇這些元件時，請優先考慮可移植性和可視化。 不受平臺限制的元件可以降低複雜性並提高安全性，團隊需要學習和保護的工具更少，並且能夠更輕鬆地根據業務需求轉移工作負載。 可視化和監控的重要性已毋庸贅言。 通過整合 Grafana 和 Prometheus 等主流工具，您可以獲得一個統一基礎架構的「單一管理平臺」視圖，確保您的團隊能夠先客戶一步檢測到問題。 此外，還有一些互補技術可能對生產級 Kubernetes 來說不一定是必需的，但卻是現代應用開發的重要組成部分。 例如，當企業和機構準備對傳統應用進行現代化改造時，第一步就是使用 API 閘道構建微服務。
NGINX 如何助您一臂之力
我們的 Kubernetes 解決方案不受平臺限制，並包含實現生產級 Kubernetes 所需的三個元件：用作ingress/egress層的 NGINX Ingress Controller、用作 WAF 的 NGINX App Protect、用作東西向流量層的 NGINX Service Mesh。
這些解決方案可以解決以下四大方面的問題，讓 Kubernetes 成為您最好的搭檔
- 自動化 —— 更快速、更安全地將應用推向市場
使用 NGINX Ingress Controller 的流量路由和應用配置功能，再加上 NGINX Service Mesh 的 NGINX Plus sidecar 自動部署功能，部署、擴展、保護和更新應用。 - 安全性 —— 保護客戶和業務免受現有和新興威脅
在集群的任意位置部署 NGINX App Protect，以減少潛在的故障點，同時使用 NGINX Service Mesh 和NGINX Ingress Controller 管理和實施服務之間的端到端加密。 - 性能 —— 提供客戶和使用者期望的數位體驗
NGINX解決方案可輕鬆處理峰值流量和安全威脅，並且不會對性能造成影響，完勝其他 WAF、Ingress 控制器和負載均衡器。 - 洞察 —— 推動業務發展，提供出色客戶服務
NGINX Ingress Controller 和 NGINX Service Mesh 可為您提供有針對性的應用性能和可用性洞察，並通過深度追蹤説明您理解微服務應用處理請求的過程。