ACK容器的應用交付網絡設計
概述
簡介
本文致力于為Kubernetes（簡稱k8s）集群提供一份詳盡的網絡入口設計指南，特別關注Service與Ingress這兩大核心組件的設計策略。在網絡配置中，確保Kubernetes集群內服務間及外部對服務訪問的高效性和安全性至關重要。正確理解和實施Service與Ingress的設計原則，不僅能顯著提高應用的可訪問性，還能大幅增強系統的整體性能和穩定性。
基本概念
Kubernetes：Kubernetes 是一個開源容器編排引擎，用于自動化容器化應用程序的部署、擴展和管理。該開源項目由云原生計算基金會（ CNCF ）托管。
ACK：阿里云容器服務 Kubernetes 版 ACK（Container Service for Kubernetes）是全球首批通過Kubernetes一致性認證的容器服務平臺，提供高性能的容器應用管理服務，支持企業級Kubernetes容器化應用的生命周期管理，讓您輕松高效地在云端運行Kubernetes容器化應用。
Service：Kubernetes 中 Service 是將運行在一個或一組 Pod 上的網絡應用程序公開為網絡服務的方法。Service 通過標簽選擇器識別一組目標 Pod，并根據 Service 的類型（如 ClusterIP、NodePort、LoadBalancer 或 ExternalName）來管理這些 Pod 之間的流量分配，有效解決了直接訪問 Pod 存在的問題，保證了應用的高可用性和運行效率。Service 的默認協議是 TCP ，你還可以使用其他受支持的任何協議。Service主要負責處理東西向流量。
Ingress：使用一種能感知協議配置的機制來解析 URI、主機名稱、路徑等 Web 概念， 讓你的 HTTP（或 HTTPS）網絡服務可被訪問。 Ingress 概念允許你通過 Kubernetes API 定義的規則將流量映射到不同后端。Ingress 可以提供負載均衡、SSL 終結以及基于名稱的虛擬托管功能。Ingress 控制器 負責完成 Ingress 的工作，具體實現上通常會使用某個負載均衡器， 不過也可以配置邊緣路由器或其他前端來幫助處理流量。Ingress主要負責處理南北向流量。
容器網絡插件：容器網絡插件（CNI Plugins）負責容器網絡的具體實現。容器網絡插件決定了Pod IP地址分配的機制、是否使用Overlay網絡、集群內流量的轉發鏈路、對Pod的訪問控制機制等容器網絡特性。目前已經有很多知名的開源容器網絡插件，如Calico、Flannel、Cilium等。容器服務 Kubernetes 版支持兩種容器網絡插件：Terway與Flannel。這兩種插件擁有不同的特性，請參照下方的介紹以及Terway與Flannel的對比，在創建集群前完成容器網絡插件的選型。
Terway：Terway網絡插件是阿里云自研的容器網絡插件。在容器服務 Kubernetes 版中作為節點的ECS實例使用ENI（彈性網卡）進行網絡通信，Terway將節點的ENI分配給Pod，為Pod提供了網絡互聯能力。因此，在使用Terway時，Pod直接接入VPC網絡。由于不需要使用VXLAN等隧道技術封裝報文，Terway模式網絡具有較高的通信性能。Terway適用于大規模集群、對網絡性能和訪問控制能力有較高需求的場景。
Flannel：Flannel是一個經典的開源容器網絡插件，它使用VXLAN等虛擬化網絡技術為Pod構建了一個Overlay網絡。Flannel的配置簡單、易于使用，但是網絡性能會受到NAT損失的影響，訪問控制能力相較于Terway也更弱，并且集群的節點數量上限較低。Flannel適用于節點數量不超過1000的小規模集群，以及對網絡性能和訪問控制能力需求較低，希望快速搭建、使用集群的場景。
NLB：網絡型負載均衡NLB（Network Load Balancer ）是阿里云面向萬物互聯時代推出的新一代四層負載均衡，支持超高性能和自動彈性能力，單實例可以達到1億并發連接，幫您輕松應對高并發業務。
ALB：應用型負載均衡ALB（Application Load Balancer）是阿里云推出的專門面向HTTP、HTTPS和QUIC等應用層負載場景的負載均衡服務，具備超強彈性及大規模應用層流量處理能力。ALB具備處理復雜業務路由的能力，與云原生相關服務深度集成，是阿里云官方提供的云原生Ingress網關。
EIP：彈性公網 IP EIP（Elastic IP Address）是可以獨立購買和持有的公網IP地址資源。目前，EIP支持綁定到專有網絡類型的云服務器 ECS（Elastic Compute Service）實例、輔助彈性網卡、負載均衡 SLB（Server Load Balancer）實例、NAT 網關（NAT Gateway）和高可用虛擬IP上。
設計原則
在設計 Kubernetes 的 Ingress 和 Service 時，應遵循以下原則以確保系統的高可用性、擴展性、性能、可觀察性和安全性：首先，實現多區域或多可用區的高可用部署，并通過健康檢查與自動恢復機制保證服務的持續在線；其次，利用動態伸縮能力和靈活的路由規則支持服務的高效擴展和流量管理；再者，采用智能流量管理和峰值處理策略優化性能，同時通過全面的監控體系和即時告警機制提高系統的可觀察性；最后，通過原生支持的 Kubernetes YAML 文件和自動化部署工具提升自服務能力，并運用網絡通信限制加強安全性。這些原則共同構成了構建穩定、高效、安全的 Kubernetes 應用交付網絡的基礎。
高可靠性
跨區域/多可用區部署：
Service: 實現跨多個可用區（AZs）的部署，確保單個AZ故障不會影響服務的整體可用性。
Ingress: 配置 Ingress 控制器以支持多區域或多可用區部署，確保即使某個區域或可用區發生故障，也能維持服務的連續性和高可用性。
健康檢查與故障轉移：
Service: 使用 Kubernetes 的內置健康檢查機制來監控 Pod 的狀態，自動移除不健康的實例。
Ingress: 利用 Ingress 控制器的健康檢查特性，定期檢查后端服務的健康狀況，并在檢測到故障時自動將流量重定向到其他健康節點。
擴展性
細粒度水平擴展策略：
Service: 支持基于可用區的細粒度水平擴展策略。
Ingress: 設計支持復雜路由規則的 Ingress，包括路徑匹配、主機名匹配等，以便根據不同的業務需求靈活分配流量。
性能與彈性
動態流量管理與自動伸縮：
Service & Ingress: 集成智能流量管理策略，如會話保持、加權輪詢等，優化用戶體驗并提升系統整體性能。同時，為 Ingress 控制器和服務配置自動伸縮策略，確保在不同時間段內能夠高效處理變化的流量壓力。
保障高峰時段性能：
Service & Ingress: 集成自動伸縮功能，依據實時流量數據動態調整負載能力，保證在高峰時段的服務性能不受影響，同時在低峰期節省成本。
可觀測
性能指標收集與展示：
Service & Ingress: 進行性能指標的收集與展示，提供全面的服務運行狀態視圖。
異常檢測與告警：
Service & Ingress: 自動化異常檢測和告警系統，快速響應潛在問題，減少故障恢復時間。
自服務能力
原生兼容與自動化部署：
Service & Ingress: 原生兼容 Kubernetes YAML 文件定義和管理服務及 Ingress。支持通過 Terraform、ROS 等基礎設施即代碼（IaC）工具進行自動化部署，提高運維效率。
安全性
網絡通信限制與加密：
Service & Ingress: 支持網絡安全組，限制不必要的網絡通信，增強服務安全。默認啟用 TLS 終止，保護數據傳輸的安全性，防止中間人攻擊。
設計關鍵點
使用阿里云的NLB來作為 Load Balancer類型的Service，使用阿里云ALB來作為Ingress。
高可靠性
跨區域/多可用區部署：
Service: NLB采用多層次容災架構設計，通過集群容災、會話保持、可用區多活等機制保障實例的可用性。
Ingress: ALB單實例至少兩可用區部署，各可用區之間可以實現故障隔離，即如果一個可用區出現故障，不會影響其他可用區的正常運行。
健康檢查與故障轉移：
Service: 網絡型負載均衡NLB通過健康檢查來判斷后端服務器業務的可用性。開啟健康檢查功能后，當某臺后端服務器健康檢查出現異常時，負載均衡會自動將新的請求分發到其他健康檢查正常的后端服務器上。當該后端服務器恢復正常運行時，負載均衡會自動將其重新納入服務并進行流量轉發。健康檢查機制是保證業務高可用的關鍵要素之一。它提高了用戶業務的整體可用性，避免了局部后端服務器異常對整體服務造成的影響。
Ingress: 為確保ALB后端服務器的業務可用性，您可以通過為ALB服務器組配置健康檢查來檢查服務器組的運行狀況，以避免后端服務器異常對業務的影響，并提升業務可靠性。在開啟健康檢查時，默認情況下，ALB會自動將客戶端請求路由至健康檢查狀態正常的服務器，并將持續對該服務器組的所有后端服務器的運行狀況進行監控。服務器必須通過連續n次的健康檢查才會被視為正常（n為配置的健康檢查健康閾值，多次健康檢查是為了避免網絡抖動的影響）。
擴展性
細粒度水平擴展策略：
Service&Ingress: NLB、ALB支持通過手動橫向擴展可用區，用戶可以將流量分發到不同地理位置的多個可用區，從而提高系統的可靠性和性能。
性能與彈性
動態流量管理與自動伸縮：
Service & Ingress: NLB、ALB提供域名與VIP，多級分發承載海量請求。支持通過流量分發擴展應用系統的服務能力，消除單點故障提升應用系統的可用性。允許自定義可用區組合和在可用區間彈性伸縮，避免單可用區資源瓶頸。
可觀測
性能指標收集與展示：
Service & Ingress: 您可以利用云監控功能查看ALB、NLB資源的運行狀態和各個指標的使用情況，方便快速定位問題。您可以通過控制臺、API、SDK方式來查看ALB、NLB的監控信息。同時，ALB、NLB支持對接Prometheus監控。
異常檢測與告警：
Service & Ingress: 開通云監控服務后，您可以通過云監控控制臺、API和SDK為應用型負載均衡ALB、NLB實例配置監控報警規則。
自服務能力
原生兼容與自動化部署：
Service：支持通過 Terraform、ROS 等基礎設施即代碼（IaC）工具進行自動化部署NLB，通過Annotation配置網絡型負載均衡NLB作為service。
apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-zone-maps: "${zone-A}:${vsw-A},${zone-B}:${vsw-B}" # 例如cn-hangzhou-k:vsw-i123456,cn-hangzhou-j:vsw-j654321。 name: nginx namespace: default spec: externalTrafficPolicy: Local ports: - name: tcp port: 80 protocol: TCP targetPort: 80 - name: https port: 443 protocol: TCP targetPort: 443 selector: app: nginx loadBalancerClass: "alibabacloud.com/nlb" type: LoadBalancerIngress: 支持通過 Terraform、ROS 等基礎設施即代碼（IaC）工具進行自動化部署ALB。支持K8s集群中kubectl，負責監聽API Server中AlbConfig/Ingress/Service等資源的變化，動態地轉換為ALB所需的配置，原生兼容Nginx Ingress。
安全性
網絡通信限制與加密：
Service & Ingress: ALB、NLB默認支持加入安全組，可以進行基于協議/端口/IP的訪問控制。
Ingress：ALB支持HTTP、HTTPS、WebSocket、TLS等多種協議。
設計最佳實踐
Service設計
場景介紹
用阿里云上容器ACK的POD做Web Server，即：Application安裝在ACK的POD中、Service服務以IP+Port形式暴露。
Service類型選擇
LoadBalancer型Service，基于NodePort增加了一個外部負載均衡器，使外部流量能夠平滑地分發到集群中的多個Pod上。Service會自動提供一個外部IP，客戶端可通過此IP訪問服務。該服務既支持在OSI模型的第四層（傳輸層）處理TCP/UDP類型的流量，也可以擴展至第七層（應用層），進行HTTP/HTTPS流量管理。
創建或關聯NLB
可以選擇已有NLB實例，也可以自動創建新的NLB作為LoadBalancer
可以通過ACK控制臺或kubectl（YAML腳本）創建或關聯NLB，并配置服務關聯（相當于NLB掛載服務器組）和端口映射（相當于NLB配置監聽）
通過Service YAML文件中的Annotation（注解）可以實現豐富的負載均衡NLB。
NLB配額限制
請關注NLB配額限制。
Ingress設計
ALB云原生Ingress
場景介紹
采用ALB Ingress為集群中的Service提供統一的入口。與Nginx Ingress相比，ALB Ingress的特點是全托管服務，您無需進行維護操作。它能自動檢測Kubernetes集群中Ingress資源的變化，并根據預設規則將流量分配至后端服務。此外，ALB Ingress設計有較強的彈性伸縮機制，能夠自動適應流量的動態變化，確保系統穩定運行。
工作原理
ALB Ingress涉及到以下基本概念：
ALB Ingress Controller：負責管理Ingress資源的組件。它通過API Server動態地獲取Ingress資源和AlbConfig資源的變化，然后更新ALB實例。與Nginx Ingress Controller不同，ALB Ingress Controller 是 ALB 實例的控制面，負責管理 ALB 實例，但不直接處理用戶流量。用戶流量的轉發由 ALB 實例來實現。ALB Ingress Controller會通過集群API Server動態地獲取Ingress資源的變化，并依照Ingress所描述的轉發規則動態地更新ALB實例。
AlbConfig（CRD）：AlbConfig是由ALB Ingress Controller創建的一種CRD (Custom Resource Definition) 。AlbConfig中的參數決定了ALB實例的配置。一個AlbConfig對應一個ALB實例。ALB實例是用戶請求流量的入口，負責將用戶請求轉發到后端Service中。它由ALB完全托管。相比起Nginx Ingress Controller，ALB Ingress免于運維，并且擁有更強大的彈性。
IngressClass：IngressClass定義了某一個Ingress與某一個AlbConfig的關聯。
Ingress：Ingress是Kubernetes中用于定義外部流量路由規則和訪問規則的資源對象，ALB Ingress Controller通過監測Ingress資源的變化并更新ALB實例以實現流量轉發。
Service：在Kubernetes中，Pod被認為是臨時資源，是不穩定而多變的。Service為具有相同功能的Pod提供了一個穩定、統一的入口。其他應用程序或服務可以通過訪問Service的虛擬IP和端口來與后端Pod進行通信，而無需關注Pod可能發生的變化。關于Service的詳細介紹，請參見Service快速入門。
配額限制
請關注ALB Ingress配額限制。
NLB+Nginx Ingress
場景介紹
采用開源的 Nginx 作為 Ingress 控制器，并將其部署在 Kubernetes 的 Pod 中。前端則使用網絡負載均衡器（NLB）來實現對這些 Pod 的流量分發。通過這種架構，NLB 和 Nginx 共同構成了一個高效且可靠的七層流量入口系統。
配額限制
請關注NLB配額限制。
ALB Ingress對比Nginx Ingress
維度 | Nginx Ingress | ALB Ingress |
定位 |
|
|
性能 |
|
|
配置 |
|
|
功能 |
|
|
安全 |
|
|
運維 |
|
|
應用場景介紹
ALB Ingress應用場景
金絲雀/藍綠發布/AB測試在進行新版本的部署時，采用金絲雀發布、藍綠部署或AB測試等策略，能夠有效地降低風險并確保用戶體驗。這些方法通過基于HTTP頭信息、Cookie值或是權重分配等多種條件來精確地將流量引導至新舊版本的服務中。例如，可以設定特定比例的用戶請求被轉發到新版本的應用程序上，以便在真實環境中觀察其性能表現，同時確保大部分用戶不受影響。
物聯網隨著物聯網技術的發展，連接到互聯網的設備數量呈現出爆炸性增長，從智能家居設備到工業自動化系統，單個應用可能需要管理數以百萬計的HTTP、HTTPS及HTTP/2連接。這不僅要求后端架構具備強大的并發處理能力，還必須能夠高效地管理和維護如此龐大的客戶端群體，確保每個設備都能獲得及時且準確的數據傳輸服務。
游戲與金融行業對于游戲和金融服務而言，每一毫秒的延遲都可能意味著巨大的損失。因此，這兩個領域特別重視API請求的快速響應和高度穩定性。通過利用先進的硬件加速技術和提供超高的服務水平協議（SLA），可以顯著減少數據處理時間，并極大提高系統的可靠性和安全性。這種優化對于保障玩家體驗或金融交易的安全高效至關重要。
遠程辦公支持面對日益增長的遠程工作需求，支持WebSocket及其安全版本WSS變得尤為重要。這類協議允許服務器與客戶端之間建立持久連接，從而實現實時雙向通信。為了適應不斷變化的工作環境，系統設計中加入了動態配置功能，使得調整設置時無需重新加載整個應用程序，確保了長連接的無縫切換和數據傳輸的連續性，為用戶提供更加流暢的使用體驗。