?

??

本文節選自ServiceMesher 社區出品的開源電子書《Istio Handbook——Istio 服務網格進階實戰》，作者鐘華，來自騰訊云。

Istio 在 1.1 后提供了兩類多集群的連通的部署模式：

1.?多控制面2.?單控制面，也稱為 “共享控制面” 模式

多控制面模式

多控制面模式，各網格之間服務實例無法自動共享，互相訪問不透明。應用場景有限，實現相對簡單。

單控制面模式

單控制面模式，根據各集群是否屬于同一個網絡，還可以細分為「單網絡單控制面」和「多網絡單控制面」:

??單網絡單控制面模式，支持多 Kubernetes 集群融合為一個服務網格，但是該種模式對網絡有嚴格的要求：需要所有集群處于同一個扁平網絡，Pod IP 互通且不重疊，使用 VPN 連通多集群網絡是常見的一個選項。不過這些網絡需求在實際環境可能難以滿足，也限制了該模式的應用場景。??多網絡單控制面模式，同樣實現了多 Kubernetes 集群融合為一個服務網格，且在網絡上沒有上述限制，每個多 Kubernetes 集群是一個獨立的網絡，甚至可以分布于不同地域。但其實現也最復雜，且該模式要求開啟服務間 mTLS 通信，通信效率上也有一定影響。

多控制面

多控制面部署模式中，每個 Kubernetes 集群中都包含一套獨立的 istio 控制面，istio 并不會主動打通各集群間的服務訪問，用戶需要主動注冊集群間互訪的服務條目，這些包括設置 DNS 和 gateway，注冊 ServiceEntry 等。下面我們以集群 1 訪問集群 2 中的 httpbin.bar 服務為例，解析多控制面服務網格連通的核心流程。

配置各集群 CA 證書

多控制面模式下的集群間互訪，要求使用雙向 TLS 通信。因為每個集群中都有獨立的 CA，如果這些 CA 使用自簽名證書將無法互相驗證，因此各集群需要共享 root CA，利用 root CA 再為每個子集群簽發 intermediate CA 證書。

我們以 istio 源碼中提供的示例 CA 證書為例，在各集群中創建一個名為?cacerts?的 secret，istiod 中的 CA 會自動讀取并使用這些證書。

kubectl create namespace istio-system kubectl create secret generic cacerts -n istio-system \--from-file=samples/certs/ca-cert.pem \--from-file=samples/certs/ca-key.pem \--from-file=samples/certs/root-cert.pem \--from-file=samples/certs/cert-chain.pem

Istio 源碼中提供了一套示例的 CA 證書，位于?samples/certs/?目錄下，需要注意這套證書已廣泛播，僅供線下測試使用，一定不要在生產環境使用！以避免不必要的安全風險。

安裝控制面

使用?IstioOperator?在各集群中分別安裝控制面：

$ istioctl install \-f manifests/examples/multicluster/values-istio-multicluster-gateways.yaml

Operator manifest 配置概要如下：

apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec:addonComponents:istiocoredns:enabled: truecomponents:egressGateways:- name: istio-egressgatewayenabled: truevalues:global:podDNSSearchNamespaces:- global- default.svc.cluster.globalmultiCluster:enabled: truecontrolPlaneSecurityEnabled: truegateways:istio-egressgateway:env:# Needed to route traffic via egress gateway if desired.ISTIO_META_REQUESTED_NETWORK_VIEW: "external"

上面的配置會安裝一個?istiocoredns?服務，用于解析遠端服務的 DNS 地址。該服務使用的鏡像是 coredns 官方鏡像。

podDNSSearchNamespaces?配置會影響后續 Pod 注入的內容，具體地會調整 Pod 的 dnsConfig，該配置將修改 Pod?/etc/resolv.conf?文件中 DNS searches 配置，為 Pod 增加了 2 個 DNS 搜索域。

dnsConfig:searches:- global- default.svc.cluster.global

在多控制面網格拓撲中，每個集群身份都是對等的，對某個集群來說，任何其他集群都是遠端集群。Kubernetes service 默認使用?svc.cluster.local?作為域名后綴，Kubernetes 集群內自帶的 DNS 服務（KubeDNS 或者 CoreDNS），負責解析 service 域名。

在該模式下，為了區別請求的目的端是本集群服務還是遠端集群服務，istio 使用?svc.cluster.global?指向遠端集群服務。默認情況下，isito 本身不會影響 Kubernetes 集群內的 DSN 條目。不過我們上一步中安裝了一個?istiocoredns，該組件會負責解析?svc.cluster.global?的域名查詢。

配置 ServiceEntry

為了實現在本集群中訪問遠端集群的服務，我們需要在本集群中注冊遠端服務的 ServiceEntry，設置 ServiceEntry 需要注意以下幾點：

?Host 格式?<service name>.<namespace>.global，對該域名的查詢請求，將由上一步配置的 istiocoredns 進行解析。??需要在 ServiceEntry 提供 VIP，可以理解為遠端目標服務在本集群中的 service IP，每個遠端服務需要配置不同的 VIP，同時這些 VIP 不能和本集群中的其他 service IP 重疊。

以集群 1 訪問 集群 2 中的 httpbin.bar 服務為例，我們需要在 集群 1 中配置以下 ServiceEntry：

apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata:name: httpbin-bar spec:hosts:- httpbin.bar.globallocation: MESH_INTERNALports:- name: http1number: 8000protocol: httpresolution: DNSaddresses:- 240.0.0.2endpoints:- address: {{ CLUSTER2_GW_ADDR }}ports:http1: 15443 # Do not change this port value

其中?addresses?(240.0.0.2) 用于設置目的服務的 VIP，同時該服務的?endpoints?中，CLUSTER2_GW_ADDR?需要填寫集群 2 的 ingress gateway 地址。這會告訴 istio: 應該將集群 1 訪問?240.0.0.2?的流量，路由到集群 2 的 ingress gateway。

以上配置的 VIP 并不會作為集群間 IP 層的實際目的地址，當集群 1 中的某個 client 發起對該 IP 訪問后，流量會被攔截到對應的 sidecar 中，sidecar 會根據 xDS 信息，將目的 IP 轉換為 集群 2 的 ingress gateway 地址。為了避免沖突，這里推薦使用 E 類網絡地址 240.0.0.0/4，該網絡地址段作為保留范圍并未廣泛使用。

SNI 感知網關分析

SNI（Server Name Indication）指定了 TLS 握手時要連接的主機名。SNI 協議是為了支持同一個 IP（和端口）支持多個域名。

目的網關端口 15443 預設了 SNI 感知的 listener，具體地，從集群 1 中 client 發出的流量攔截到 sidecar 后，sidecar 會將其轉換為 mTLS 流量，并帶上 SNI 信息（httpbin）轉發出去。流量到達集群 2 的 ingress gateway 15443 端口后，該 ingress gateway 會提取 SNI 信息，分析出實際的目的服務為 httpbin 服務，最終轉發給集群 2 中 httpbin 服務的 pod。

{"name": "0.0.0.0_15443","active_state": {"listener": {"name": "0.0.0.0_15443","address": {"socket_address": {"address": "0.0.0.0","port_value": 15443}},"filter_chains": [{"filter_chain_match": {"server_names": ["*.global"]},"filters": [{"name": "envoy.filters.network.sni_cluster"},{"name": "envoy.filters.network.tcp_cluster_rewrite","config": {"cluster_pattern": "\\.global$","cluster_replacement": ".svc.cluster.local"}},......{"name": "envoy.tcp_proxy","typed_config": {"stat_prefix": "BlackHoleCluster","cluster": "BlackHoleCluster"}}]}],"listener_filters": [{"name": "envoy.listener.tls_inspector",......}],"traffic_direction": "OUTBOUND"}} }

其中，envoy.listener.tls_inspector?將檢測 TLS 流量，并可以提取 SNI 作為 server name，進行路由決策。tcp_cluster_rewrite?將后綴以?global$?結尾的?cluster?替換為?svc.cluster.local，進而轉發到網格內部，以此實現了 TLS 層的路由。

單控制面

與多控制面網格不同，單控制面網格中的所有集群，共享一個 istio 控制面，單控制面作為流控規則的唯一下發入口，會 watch 所有 Kubernetes 集群的服務發現數據，所有集群數據面的 Envoy 都會連接單控制面，獲得 xDS 信息。

「單網絡單控制面」和 「多網絡單控制面」的安裝流程類似，簡述如下。

配置各集群 CA 證書

對于「多網絡」模式，跨集群通信必須經過 istio gateway，gateway 同樣利用 SNI 進行路由感知，這種模式必須開啟 mTLS，因此需要提前配置各集群的 CA 證書，步驟和「多控制面」流程一致，不再贅述。

「單網絡」模式中的跨集群通信是 pod 與 pod 直連，沒有經過 istio gateway，因此并不需要強制使用 mTLS，可以不用配置 mTLS 證書，但是如果業務上需要開啟 mTLS 通信，多個集群各自的自簽名證書無法互相驗證，因此也需要配置自簽名的 CA 證書。

主集群安裝控制面

我們將控制面所在的 Kubernetes 稱為主集群，其他集群稱為遠端集群。

我們使用 IstioOperator 進行安裝，安裝之前，每個集群都要確定以下 2 個重要的拓撲配置：

??集群標識：每個集群都需要有一個唯一的集群名；??網絡標識：標識集群所屬的網絡，「單網絡模式」中，所有集群的網絡標識都相同，「多網絡模式」中，某些或者所有集群的網絡標識不同。

以上兩個配置，會作為 pod 元數據寫入到各集群的 sidecar injector 的配置中（configmap?istio-sidecar-injector），然后再以環境變量的形式注入到 pod 的模板中，分別名為?ISTIO_META_CLUSTER_ID?和?ISTIO_META_NETWORK。

istio 會結合這些信息，來判斷 2 個 pod 是否屬于同一個集群，以及是否屬于同一個網絡，進而配置不同的路由策略。比如在「多網絡單控制面」模式下，處于同一網絡的 pod 訪問，將使用 pod ip 互通，而當訪問另一個網絡中的 pod 時，流量目的端將配置為對方網絡的 gateway 地址。

遠端集群安裝

apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec:values:global:multiCluster:clusterName: ${REMOTE_CLUSTER_NAME}network: ${REMOTE_CLUSTER_NETWORK}remotePilotAddress: ${ISTIOD_REMOTE_EP}## 多網絡模式需要以下配置，單網絡模式不需要# components:# ingressGateways:# - name: istio-ingressgateway# enabled: false

遠端集群中仍然安裝了一個完整的 istiod，似乎和主集群一樣。不過如果我們仔細分析遠端集群的配置，我們可以發現，遠端集群其實只需要獨立的 sidecar injector 和負責本集群證書的 citadel ，在 istio 1.5 之前，遠端集群中的確只有這 2 個組件。不過 istio 1.5 將所有控制面組件合并為一個單體，因此目前遠端集群中也安裝了一個完整的 istiod。

理論上，主集群中的 istiod 也應該可以提供遠端集群的 pod 注入服務和證書服務，不過這些在 istio 1.5 中還未完成，預計在后續版本中會逐步提供，屆時遠端集群中不再需要安裝 istiod，會更加的簡單。

配置多網絡模式的 Gateway

如果是選擇「多網絡單控制面」，各集群都需要安裝一個入流量網關。這包括 2 個步驟，首先需要在每個集群中安裝網關對應的 deployment 和 service。然后要在控制面所在集群中安裝 istio gateway CRD:

apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata:name: cluster-aware-gatewaynamespace: istio-system spec:selector:istio: ingressgatewayservers:- port:number: 443name: tlsprotocol: TLStls:mode: AUTO_PASSTHROUGHhosts:- "*.local"

關于 mTLS 和 AUTO_PASSTHROUGH

通常來說，istio ingress gateway 需要配套指定服務的 VirtualService，用以指定 ingress 流量的后端服務。但在「多網絡模式」中，該 ingress gateway 需要作為本數據面所有服務的流量入口。也就是所有服務共享單個 ingress gateway (單個 IP)，這里其實是利用了 TLS 中的?SNI(Server Name Indication)^[1]。

傳統的 ingress gateway 承載的是南北流量 (server-client)，這里的 ingress gateway 屬于網格內部流量，承載的是東西流量 (server-server)。設置?AUTO_PASSTHROUGH，可以允許服務無需配置 VirtualService，而直接使用 TLS 中的 SNI 值來表示 upstream，服務相關的 service/subset/port 都可以編碼到 SNI 內容中。

注冊遠端集群服務發現

對最簡單的單集群服務網格，pilot 會連接所在 kubernetes 集群的 api server，自動將該集群的服務發現數據（如 service，endpoint 等）接入控制面。對于多集群模式，pilot 需要用戶主動提供，如何去連接遠端集群的 api server。istio 約定方式是：用戶將遠端集群的訪問憑證 (kube config 文件) 存于主集群的 secret 中，同時打上固定 label istio/multiCluster: "true"。

一份遠端集群訪問憑證 secret 模板類似這樣：

apiVersion: v1 kind: Secret metadata:name: istio-remote-secret-{{ REMOTE_CLUSTER_NAME }}namespace: istio-systemlabels:istio/multiCluster: "true" type: Opaque stringData:{{ REMOTE_CLUSTER_NAME }}: |-apiVersion: v1clusters:- cluster:server: {{ REMOTE_CLUSTER_API_SERVER_ADDRESS }}name: {{ REMOTE_CLUSTER_NAME }}contexts:- context:cluster: {{ REMOTE_CLUSTER_NAME }}user: {{ REMOTE_CLUSTER_USER }}name: {{ REMOTE_CLUSTER_NAME }}current-context: {{ .REMOTE_CLUSTER_CTX }}kind: Configusers:- name: {{ REMOTE_CLUSTER_USER }}user:token: {{ REMOTE_CLUSTER_TOKEN }}

secret name 并不重要，pilot 會 watch 所有包含 label?istio/multiCluster: "true"?的 secret。istio 提供了生成以上 secret 的簡化命令，注意生成的遠端集群 secret，最終是 apply 到主集群中：

$ istioctl x create-remote-secret --name ${REMOTE_CLUSTER_NAME} --context=${REMOTE_CLUSTER_CTX} | \kubectl apply -f - --context=${MAIN_CLUSTER_CTX}

至此「單控制面」服務網格搭建完畢。如果配置正確，主集群中的控制面將會 watch 遠端集群的服務數據，pilot 會整合所有集群的服務發現數據和流控規則，以 xDS 形式下發到各集群數據面。

部署模式選擇

「多控制面」模式，嚴格的講每個 kubernetes 集群仍然是獨立的服務網格，適合于業務界限明顯的多集群，集群間服務互訪不多，大部分場景下，各集群服務和流控偏向于獨立治理，對于有互訪需求的小部分服務，需要用戶顯式地進行服務連通注冊。

「單控制面」模式，將多個集群聯結為一個統一的服務網格，集群間同名服務自動共享服務實例。這種模式適合于業務聯系緊密的多集群，甚至是業務對等的多集群。這些集群間服務互訪較多，所有集群共享流控治理規則?？梢詫崿F「地域感知路由」、「異地容災」等高級的網格應用場景。

至于選擇「單網絡單控制面」還是「多網絡單控制面」，更多的是依賴集群間的網絡連通現狀。「單網絡」模式要求集群與集群處于同一個網絡平面，pod IP 不重疊且可以直連；如果網絡拓撲不滿足，那么可以選擇「多網絡」模式，該模式下每個集群都有一個入口網關，供其他集群訪問流量進入，不過需要考慮的是業務能否接受 mTLS 帶來的開銷。

以上是 istio 最常見的多集群模式，istio 還可以實現其他更復雜的拓撲，比如多個遠端集群，有部分屬于相同網絡，另一部分屬于不同網絡；另外控制面組件還可能以冗余的方式，分布到多個集群，這樣可以有多個主集群，用以提高控制面的可用性。不過這些模式對服務網格的理解和運維能力要求更高，用戶應該謹慎選型。

引用鏈接

[1]?SNI(Server Name Indication):?https://en.wikipedia.org/wiki/Server_Name_Indication

開源電子書 Istio Handbook

ServiceMesher 社區作為中國最早研究和推廣 Service Mesh 技術的開源技術社區，于今年 2 月重啟了開源電子書 Istio Handbook 的創作，本書側重本書更加注重基礎知識的提煉及實戰經驗分享，當前已有 21 人參與了編寫，創作仍在進行中，歡迎更多人參與進來，參與方式及在線瀏覽地址為?https://www.servicemesher.com/istio-handbook

以下為已參與編寫的作者名單，ServiceMesher 社區期待您的加入！

點擊?閱讀原文?查看更多

總結

以上是生活随笔為你收集整理的Istio 中的多集群部署与管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。