作者 | 王夕寧? 阿里巴巴高級技術專家

參與阿里巴巴云原生公眾號文末留言互動，有機會獲得贈書福利！

本文摘自于由阿里云高級技術專家王夕寧撰寫的《Istio?服務網(wǎng)格技術解析與實踐》一書，文章介紹將集群外部的客戶端連接到集群內(nèi)運行的服務，以及如何從集群內(nèi)的服務訪問集群外部的任何服務，即通常所說的南北向流量管理。其中介紹了 Istio 在南北向流量方面的路由控制能力，引出 Istio 網(wǎng)關的概念及其工作原理。

本文文末匯集并整理了近期 Istio 的相關問題并特邀王夕寧老師進行解答，希望能夠?qū)Υ蠹矣兴鶐椭鷡

Istio 網(wǎng)關

網(wǎng)絡社區(qū)中有一個術語 Ingress，是指入口請求到集群內(nèi)服務的流量管理。Ingress 指的是源自本地網(wǎng)絡之外的流量，指向本地集群網(wǎng)絡中的端點。此流量首先路由到公開的入口點，以便通過執(zhí)行一些本地網(wǎng)絡的規(guī)則和策略來確認哪些流量被允許進入。如果流量未通過這些入口點，則無法與集群內(nèi)的任何服務連接。如果入口點允許流量進入，則將其代理到本地網(wǎng)絡中的合適節(jié)點。Istio 對入口流量的管理是由 Istio 網(wǎng)關進行的。

Istio 網(wǎng)關的工作原理

傳統(tǒng)上，Kubernetes 使用 Ingress 控制器來處理從外部進入集群的流量。使用 Istio 時，情況不再如此。Istio 網(wǎng)關用新的 Gateway 資源和 VirtualServices 資源來控制入口流量，它們協(xié)同工作以將流量路由到網(wǎng)格中。在網(wǎng)格內(nèi)部不需要 Gateways，因為服務可以通過集群本地服務名稱相互訪問。

那么 Istio 網(wǎng)關是怎樣工作的？請求如何到達它想要的應用程序？基本步驟如下：

1.客戶端在特定端口上發(fā)出請求；
2.負載均衡器在這個端口上進行偵聽，并將請求轉(zhuǎn)發(fā)到集群中（在相同或新的端口）；
3.在集群內(nèi)部，請求被路由到 Istio IngressGateway 服務所偵聽的負載均衡器轉(zhuǎn)發(fā)過來的端口上；
4.Istio IngressGateway 服務將請求（在相同或新的端口）轉(zhuǎn)發(fā)到對應的 pod 上；
5.在 IngressGateway pod 上會配置 Gateway 資源和 VirtualService 資源定義。Gateway 會配置端口、協(xié)議以及相關安全證書。VirtualService 的路由配置信息用于找到正確的服務；
6.Istio IngressGateway pod 會根據(jù)路由配置信息將請求路由到對應的應用服務上；
7.應用服務將請求路由到對應的應用 pod 上。

（tio 網(wǎng)關的工作原理）

Istio 網(wǎng)關的負載均衡作用

典型的服務網(wǎng)格具有一個或多個負載均衡器，也稱為網(wǎng)關（Gateway），它們從外部網(wǎng)絡終止 TLS 并允許流量進入網(wǎng)格。然后，流量通過邊車網(wǎng)關（Sidecar gateway）流經(jīng)內(nèi)部服務。應用程序使用外部服務的場景也很常見，可以直接調(diào)用外部服務，或者在某些部署中強制通過專用出口網(wǎng)關（Egress Gateway）離開網(wǎng)格的所有流量。

Istio 具有入口網(wǎng)關的概念，它扮演網(wǎng)絡入口點的角色，負責保護和控制來自集群外部的流量對集群的訪問。

（網(wǎng)關在網(wǎng)格中的使用情況）

此外，Istio 的網(wǎng)關還扮演負載均衡和虛擬主機路由的角色。如圖所示，可以看到默認情況下 Istio 使用 Envoy 代理作為入口代理。Envoy 是一個功能強大的服務到服務代理，但它也有負載均衡和路由的功能，可代理的流量包括從服務網(wǎng)格外部到其內(nèi)部運行的服務，或者從集群內(nèi)部服務到外部服務。在前面章節(jié)中介紹的 Envoy 的所有功能也可以在入口網(wǎng)關中使用。

（Istio 的入口網(wǎng)關服務）

對于入口流量管理，你可能會問：為什么不直接使用 Kubernetes Ingress API？

• 第一個原因，Kubernetes Ingress 是一個面向 HTTP 工作負載的非常簡單的規(guī)范。有 Kubernetes Ingress 的實現(xiàn)（如 Nginx、Heptio Contour 等），但每個都適用于 HTTP 流量。實際上，Ingress 規(guī)范只將端口 80 和端口 443 視為入口點。這嚴重限制了集群運維人員可以允許進入服務網(wǎng)格的流量類型。例如，如果你有 Kafka 工作負載，則可能希望向這些消息代理公開直接 TCP 連接；
• 第二個原因，Kubernetes Ingress API 無法表達 Istio 的路由需求。Ingress 沒有通用的方法來指定復雜的流量路由規(guī)則，如流量拆分或流量鏡像等。這個領域缺乏規(guī)范會導致每個供應商重新設想如何更好地為每種類型的 Ingress 實現(xiàn)（如 HAProxy、Nginx 等）做好配置管理。Ingress 試圖在不同的 HTTP 代理之間取一個公共的交集，因此只能支持最基本的 HTTP 路由；
• 最后一個原因，由于事前沒有明確規(guī)定，大多數(shù)供應商的選擇是通過部署上的定制注釋來做配置。供應商之間的注釋各不相同，并且不可移植，如果 Istio 繼續(xù)延續(xù)這種趨勢，那么就會有更多的注釋來解釋 Envoy 作為邊緣網(wǎng)關的所有功能。

Istio 網(wǎng)關通過將 L4-L6 配置與 L7 配置分離克服了 Ingress 的這些缺點。Istio 網(wǎng)關只用于配置 L4-L6 功能（例如，對外公開的端口、TLS 配置），所有主流的 L7 代理均以統(tǒng)一的方式實現(xiàn)了這些功能。然后，通過在 Gateway 上綁定 VirtualService 的方式，可以使用標準的 Istio 規(guī)則來控制進入 Gateway 的 HTTP 和 TCP 流量。負載均衡器可以手動配置或通過服務自動配置其類型，例如 type: LoadBalancer。在這種情況下，由于并非所有云都支持自動配置，假設手動配置負載均衡器以將流量轉(zhuǎn)發(fā)到 IngressGateway Service 正在偵聽的端口。例如如下的負載均衡器正在監(jiān)聽以下端口：

• HTTP：端口 80，將流量轉(zhuǎn)發(fā)到端口 30080；
• HTTPS：端口 443，將流量轉(zhuǎn)發(fā)到端口 30443；
• MySQL：端口 3306，將流量轉(zhuǎn)發(fā)到端口 30306 確保負載均衡器配置轉(zhuǎn)發(fā)到所有工作節(jié)點。這將確保即使某些節(jié)點關閉也會轉(zhuǎn)發(fā)流量。

入口網(wǎng)關服務

IngressGateway 服務（入口網(wǎng)關服務）必須監(jiān)聽上節(jié)介紹的所有端口，以便能夠?qū)⒘髁哭D(zhuǎn)發(fā)到 IngressGateway pod 上。Kubernetes 服務不是“真正的”服務，該請求將由 Kubernetes 提供的 kube-proxy 轉(zhuǎn)發(fā)到具有運行對應 pod 的節(jié)點上。在節(jié)點上，IP table 配置將請求轉(zhuǎn)發(fā)到適當?shù)?pod：

ports:- name: http2nodePort: 30000port: 80protocol: TCP- name: httpsnodePort: 30443port: 443protocol: TCP- name: mysqlnodePort: 30306port: 3306protocol: TCP

入口網(wǎng)關部署

IngressGateway 部署是一個基于 Envoy 代理的封裝，它的配置方式與服務網(wǎng)格中使用的 Sidecar 配置相同（實際上是同樣的容器鏡像）。當我們創(chuàng)建或更改一個 Gateway 或 VirtualService 時，Istio Pilot 控制器會檢測到這些變更，并將這些變更信息轉(zhuǎn)換為 Envoy 配置，然后將 Envoy 配置信息發(fā)送給相關 Envoy 代理，包括內(nèi)部的 Envoy 和 IngressGateway 中的 Envoy。

注意：這里不要混淆 IngressGateway 與 Gateway，Gateway 資源是用于配置 IngressGateway 的一種 Kubernetes 的自定義資源。

由于不必在 Kubernetes pod 或部署中聲明容器端口，因此我們不必在 IngressGateway Deployment 中聲明端口。但是，如果查看部署內(nèi)部，可以看到聲明的許多端口。另外，在 IngressGateway 部署中需要關注 SSL 證書，為了能夠訪問 Gateway 資源內(nèi)的證書，請確保已正確加載這些證書。

網(wǎng)關資源

網(wǎng)關資源用來配置 Envoy 的端口，前面的示例中已經(jīng)使用該服務公開了三個端口，因此需要在 Envoy 中處理這些端口。此外，可以通過聲明一個或多個 Gateways 來支持多端口能力。下面的示例中使用單個 Gateway，但可以分為兩個或三個分別定義：

apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata:name: default-gatewaynamespace: istio-system spec:selector:istio: ingressgatewayservers:- hosts:- '*'port:name: httpnumber: 80protocol: HTTP- hosts:- '*'port:name: httpsnumber: 443protocol: HTTPStls:mode: SIMPLEprivateKey: /etc/istio/ingressgateway-certs/tls.keyserverCertificate: /etc/istio/ingressgateway-certs/tls.crt- hosts: # For TCP routing this fields seems to be ignored, but it is matched- '*' # with the VirtualService, I use * since it will match anything.port:name: mysqlnumber: 3306protocol: TCP

網(wǎng)關虛擬服務

VirtualService 資源與 Gateway 資源相互配合支持 Envoy 的配置。下面是一個支持 HTTP 服務的網(wǎng)關虛擬服務的基本配置：

apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata:name: counter spec:gateways:- default-gateway.istio-system.svc.cluster.localhosts:- counter.lab.example.comhttp:- match:- uri:prefix: /route:- destination:host: counterport:number: 80

現(xiàn)在，當我們添加一個 Gateway 和一個 VirtualService 時，路由已在 Envoy 配置中創(chuàng)建。要查看此內(nèi)容，你可以使用如下命令：

kubectl port-forward istio-ingressgateway-xxxx-yyyy-n istio-system 15000

調(diào)試入口網(wǎng)關

調(diào)試網(wǎng)絡問題有時很困難，所以這里總結一些有用的命令用于調(diào)試。端口轉(zhuǎn)發(fā)到第一個 istio-ingressgateway pod：

kubectl -n istio-system port-forward $(kubectl -n istio-system get pods -listio=ingressgateway -o=jsonpath="{.items[0].metadata.name}") 15000

然后，可以從端口轉(zhuǎn)發(fā)的入口網(wǎng)關 pod 中獲得 http 路由：

Curl --silent http://localhost:15000/config_dump |jq .configs[3].dynamic_route_configs[].route_config.virtual_hosts[]

（端口轉(zhuǎn)發(fā)的入口網(wǎng)關 pod）

查看上述端口轉(zhuǎn)發(fā)的入口網(wǎng)關 pod 的日志信息：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -listio=ingressgateway -o=jsonpath="{.items[0].metadata.name}") --tail=300

查看 Pilot pod 的日志信息：

kubectl -n istio-system logs $(kubectl -n istio-system get pods -listio=pilot -o=jsonpath="{.items[0].metadata.name}") discovery --tail=300

當啟動端口轉(zhuǎn)發(fā)到入口網(wǎng)關 istio-ingressgateway 之后，可以執(zhí)行更多操作以獲取更多信息，例如：

• 需要查看 Envoy 偵聽器，請點擊網(wǎng)址：http://localhost:15000/listeners；
• 需要打開更詳細的日志記錄，請點擊網(wǎng)址：http://localhost:15000/logging；
• 可以在根目錄?http://localhost:15000/?中找到更多信息。

《Istio服務網(wǎng)格技術解析與實戰(zhàn)》讀者可免費體驗 ASM 產(chǎn)品進行學習！點擊了解阿里云服務網(wǎng)格產(chǎn)品 ASM：
www.aliyun.com/product/servicemesh

作者簡介

王夕寧 阿里云高級技術專家，阿里云服務網(wǎng)格產(chǎn)品 ASM 及 Istio on Kubernetes 技術負責人，專注于 Kubernetes、云原生、服務網(wǎng)格等領域。曾在 IBM 中國開發(fā)中心工作，擔任過專利技術評審委員會主席，擁有 40 多項相關領域的國際技術專利。《Istio 服務網(wǎng)格解析與實戰(zhàn)》一書由其撰寫，詳細介紹了 Istio 的基本原理與開發(fā)實戰(zhàn)，包含大量精選案例和參考代碼可以下載，可快速入門 Istio 開發(fā)。Gartner 認為，2020 年服務網(wǎng)格將成為所有領先的容器管理系統(tǒng)的標配技術。本書適合所有對微服務和云原生感興趣的讀者，推薦大家對本書進行深入的閱讀。

關于?Istio 的一些?Q&A

Q1：Istio 在實際生產(chǎn)環(huán)境實踐中都會遇到哪些瓶頸，常見的優(yōu)化手段又都有哪些？
A1：阿里云之所以推出服務網(wǎng)格 ASM 這個產(chǎn)品，就是把過去一兩年支持客戶使用 Istio 的過程中遇到的太多問題，總結成了經(jīng)驗并落地到產(chǎn)品中。所以多關注下這個產(chǎn)品的能力就會看到具體解決了哪些問題。在此就不一一贅述了。

Q2：Istio 會導致性能消耗增加嗎？
A2：這個問題需要一個上下文，這就像問 Java 虛擬機會導致性能消耗嗎。任何解耦總會帶來一定的通信消耗。建議使用 Istio 前先判斷下自己的應用是否適合解耦、服務化以及容器化，然后再看是否適合采用 Istio 的哪些功能。

Q3：Service Mesh 是很好的工具，但是痛點也很明顯，引入 Istio 會讓運維更加復雜，阿里云服務網(wǎng)格產(chǎn)品 ASM 這方面有做什么改進？
A3：阿里云服務網(wǎng)格 ASM 提供了一個全托管式的服務網(wǎng)格平臺，兼容于社區(qū) Istio 開源服務網(wǎng)格，用于簡化服務的治理，并提供了簡單易用的控制臺，托管模式下讓用戶解脫控制面的復雜管理，極大地減輕開發(fā)與運維的工作負擔。具體可以參考這個入門教程了解一下：https://help.aliyun.com/document_detail/149552.html

Q4：最近在研究 Istio，有真正落地使用的例子嗎？
A4：過去一兩年我們已經(jīng)支持了大量客戶使用 Istio，譬如有客戶使用 Istio 流量管理來做應用的灰度發(fā)布，有客戶使用它的統(tǒng)一的聲明式的方式來管理入口網(wǎng)關，包括入口網(wǎng)關的 tls 透傳功能、tls 終止以及動態(tài)加載證書的能力等等。

Q5：目前阿里服務網(wǎng)格產(chǎn)品 ASM 針對 Istio 采用什么樣的監(jiān)控？
A5：阿里云服務網(wǎng)格 ASM 的可觀測性能力從三個維度提供了不同的能力，包括：

• 日志：每一個 Sidecar 代理和入口網(wǎng)關的訪問日志及分析報表，可以參考：https://help.aliyun.com/document_detail/162798.html；
• 跟蹤：集成了阿里云鏈路追蹤服務 Tracing Analysis，為分布式應用的開發(fā)者提供了完整的調(diào)用鏈路還原、調(diào)用請求量統(tǒng)計、鏈路拓撲、應用依賴分析等能力，可以參考：https://help.aliyun.com/document_detail/149551.html；
• 監(jiān)控：集成了 ARMS Prometheus 及 Grafana Dashboard 的能力，這部分的文檔正在輸出，請持續(xù)關注產(chǎn)品的文檔：https://help.aliyun.com/product/147365.html。

Q6：阿里的 ASM 的 Proxy 會采用 MOSN 嗎？期待 MOSN 成為 Istio 可選數(shù)據(jù)平面之一。
A6：阿里云服務網(wǎng)格 ASM 從一開始的設計就是兼容于社區(qū) Istio 開源服務網(wǎng)格，只要符合與 Istio 控制面規(guī)約要求的數(shù)據(jù)面代理，從理論上都是可以支持的。當然一個新代理的適配是需要一定量的開發(fā)工作，這兒我們也想了解下客戶對于這方面的訴求。

Q7：Istio 也有類似 Linkerd 的 mutls 功能嗎？
A7：Istio 默認已經(jīng)提供了雙向 tls 認證的功能，而且支持漸進式，包括 permissive 和 strict 兩種方式。

-?贈書福利?-

《Istio 服務網(wǎng)格技術解析與實踐》- 機械工業(yè)出版社贊助

5 月 15 日 11：00 前在阿里巴巴云原生公眾號留言區(qū)分享你在學習 Istio 技術的踩坑經(jīng)驗、或者對新技術的更新、迭代有何獨特的個人見解，精選留言點贊前 3 名各送出此書一本！

課程推薦

為了更多開發(fā)者能夠享受到 Serverless 帶來的紅利，這一次，我們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發(fā)者入門的 Serverless 公開課，讓你即學即用，輕松擁抱云計算的新范式——Serverless。

點擊即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/serverless

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號。”

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結

以上是生活随笔為你收集整理的Istio 网关之南北向流量管理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。