无缝融入 Kubernetes 生态 | 云原生网关支持 Ingress 资源
Kubernetes Ingress 介紹
通常情況下,Kubernetes 集群內的網絡環境與外部是隔離的,也就是說 Kubernetes 集群外部的客戶端無法直接訪問到集群內部的服務,這屬于不同網絡域如何連接的問題。解決跨網絡域訪問的常規做法是為目標集群引入一個入口點,所有外部請求目標集群的流量必須訪問這個入口點,然后由入口點將外部請求轉發至目標節點。
同樣,Kubernetes 社區也是通過增設入口點的方案來解決集群內部服務如何對外暴露的問題。Kubernetes 一貫的作風是通過定義標準來解決同一類問題,在解決集群對外流量管理的問題也不例外。Kubernetes 對集群入口點進行了進一步的統一抽象,提出了 3 種解決方案:NodePort、LoadBalancer 和 Ingress。下圖是這三種方案的對比:
通過以上對比,我們可以發現,NodePort 和 LoadBalancer 主要工作在四層流量上,只能用于暴露集群中一個服務。當集群中對外暴露的服務數量增多時,NodePort 方案最終會因端口耗盡而無法暴露更多的服務,而 LoadBalancer 方案則會引入同等數量的 SLB,在增加成本的同時也給運維帶來一定的負擔。定位在七層流量上的 Ingress 方案可以通過定義基于虛擬主機域和路徑的路由規則來完成對集群中服務的代理,Ingress 與后端服務是一對多的關系,有效的降低了機器成本。
此外,因為外部訪問集群中服務的所有入口流量都先經過共享的 Ingress Provider 節點,所以集群管理者可以在 Ingress Provider 中額外實施訪問控制策略來保證集群中服務的安全性和穩定性,并且可以通過采集監控指標、記錄訪問日志以及開啟鏈路追蹤來增強可觀測建設。因此,目前 Ingress 方案是主流的選擇。
Kubernetes Ingress Provider 介紹
上文提到,Ingress 是 Kubernetes 應對集群管理外部訪問流量的場景抽象出來一個資源對象,用來描述集群外部如何訪問集群內部服務的方式。通過 Ingress 資源來配置不同的轉發規則,從而達到根據不同的規則設置外部訪問集群內不同的 Service 所對應的后端 Pod。Ingress Provider 是真實存在的 Workload 節點,是真正意義上 Ingress 規則的實現者與執行者。Kubernetes 提出 Ingress 的規范,將 Ingress 具體實現方式交給各種 Provider 以及云提供商,有效保證了 Ingress 不會被具體的 Provider 或者云廠商綁定,符合 Kubernetes 一直秉承的開放、標準的思想。
在云原生技術浪潮下,Ingress Provider 產品種類如雨后春筍般涌現,其中用戶知名度最高當屬 Kubernetes Nginx Ingress。接下來會簡單介紹一下 Nginx Ingress Controller 和阿里云推出的下一代網關——MSE Ingress Controller(MSE 云原生網關)。
Nginx Ingress Controller
Nginx Ingress Controller 是由 Kubernetes 官方維護的,內部由 Controller 和數據面 Nginx 組成。Nginx Ingress Controller 由用戶部署在 Kubernetes 集群中,通過訪問集群的 API Server 來實時監聽用戶應用到集群中的 Ingress 資源,經 Controller 解析并轉化為 Nginx 配置文件(nginx.conf),然后通過 reload 數據面 Nginx 的方式使得配置生效。
當外部請求訪問集群入口點 Nginx Ingress Controller 時,匹配 Nginx Ingress 轉發規則的流量轉發到后端 Service 所對應的 Pod,由 Pod 處理外部請求,其流程圖如下:
MSE Ingress Controller(MSE 云原生網關)
隨著云原生技術持續演進,云原生應用微服務化不斷深入,Nginx Ingress 在面對復雜路由規則配置、支持多種應用層協議(Dubbo 和 QUIC 等)、服務訪問的安全性以及流量的可觀測性等問題上略顯疲憊。
為了解決用戶對大規模流量治理的強烈訴求,MSE 云原生網關應運而生,這是阿里云推出的兼容標準 Ingress 規范的下一代網關,具備低成本、安全、高集成和高可用的產品優勢。將傳統的流量網關和微服務網關合并,在降低 50%資源成本的同時為用戶提供了精細化的流量治理能力,支持 ACK 容器服務、Nacos、Eureka、固定地址、FaaS 等多種服務發現方式,支持多種認證登錄方式快速構建安全防線,提供全方面、多視角的監控體系,如指標監控、日志分析以及鏈路追蹤,并且支持解析單、多 Kubernetes 集群模式下的標準 Ingress 資源,滿足云原生應用場景下以聲明式進行統一流量治理的訴求。
MSE Ingress Controller 通過 List-Watch 機制獲取關聯的 ACK 集群中 Ingress 資源的變化,然后以熱更新的方式動態更新 MSE 云原生網關的路由規則。當 MSE 云原生網關收到請求時,匹配 Ingress 轉發規則轉發請求到后端 Service 所對應的 Pod。
相比 Nginx Ingress Controller,首先 MSE Ingress Controller 是以熱更新的方式秒級生效監聽到的 Ingress 資源,這種無需重啟數據面即可生效配置的方式大大提高了集群入口網關的穩定性,有效保障了業務流量無損。更重要的是,MSE Ingress Controller 可以進行多集群管理,即同時作為多個集群的入口網關,意味著可以同時監聽多個集群中的 Ingress 資源,解決用戶跨 Kubernetes 集群流量調度和流量治理問題。
下圖是 MSE Ingress Controller 在多 ACK 集群模式下 Ingress 的應用場景。
通過 MSE 云原生網關解析 Ingress
我們將基于 MSE 云原生網關和阿里云 ACK 產品進行實踐,由云原生網關解析并執行 ACK 集群中定義的 Ingress 資源,完成對外暴露 ACK 集群中指定服務。
前提條件
? 已擁有一個 MSE 云原生網關
? 已擁有一個 ACK 運維集群
步驟一:關聯 ACK 集群并配置監聽 Ingress
步驟二:部署服務
創建并拷貝以下內容到 httpbin.yaml 文件中,用于部署名稱為 httpbin Deployment,以及名稱為 httpbin 的 Service,然后應用到 ACK 集群中。
apiVersion: v1 kind: Service metadata:name: httpbinlabels:app: httpbinservice: httpbin spec:ports:- name: httpport: 8000targetPort: 80selector:app: httpbin --- apiVersion: apps/v1 kind: Deployment metadata:name: httpbin spec:replicas: 1selector:matchLabels:app: httpbintemplate:metadata:labels:app: httpbinspec:containers:- image: mse-gw-demo-registry.cn-hangzhou.cr.aliyuncs.com/gw/httpbinimagePullPolicy: IfNotPresentname: httpbinports:- containerPort: 80步驟三:配置 Ingress
創建并拷貝以下內容到 ingress.yaml 中,然后應用到 ACK 集群中。
ACK 1.19 版本之前
apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata:name: ingress-demo spec:rules:- host: test.comhttp:paths:- path: /ipbackend:serviceName: httpbinservicePort: 800 ACK 1.19 及之后版本 apiVersion: networking.k8s.io/v1 kind: Ingress metadata:name: ingress-demo spec:rules:- host: test.comhttp:paths:- path: /ipbackend:service:name: httpbinport:number: 8000pathType: Exact步驟四:訪問服務
在 MSE 云原生網關控制臺的基本信息查看網關 IP 地址。
通過以下命令行測試訪問服務。
curl -H "host: test.com" 47.97.127.61/ip預期結果:
{"origin": "x.x.x.x" }步驟五:查看域名、路由相關配置
我們可以在 MSE 云原生網關控制臺查看已監聽的域名和路由相關的配置,例如,上述 ingress.yaml 在云原生網關控制臺的解析結果。
域名管理如下:
路由管理如下:
總結
以上是生活随笔為你收集整理的无缝融入 Kubernetes 生态 | 云原生网关支持 Ingress 资源的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 从旁观者到贡献者:经历 OpenYurt
- 下一篇: 基于 EventBridge 构建 Sa