?

??

本文節(jié)選自ServiceMesher 社區(qū)出品的開源電子書《Istio Handbook——Istio 服務(wù)網(wǎng)格進階實戰(zhàn)》，作者鐘華，來自騰訊云。

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

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

多控制面模式

多控制面模式，各網(wǎng)格之間服務(wù)實例無法自動共享，互相訪問不透明。應(yīng)用場景有限，實現(xiàn)相對簡單。

單控制面模式

單控制面模式，根據(jù)各集群是否屬于同一個網(wǎng)絡(luò)，還可以細分為「單網(wǎng)絡(luò)單控制面」和「多網(wǎng)絡(luò)單控制面」:

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

多控制面

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

配置各集群 CA 證書

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

我們以 istio 源碼中提供的示例 CA 證書為例，在各集群中創(chuàng)建一個名為?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/?目錄下，需要注意這套證書已廣泛播，僅供線下測試使用，一定不要在生產(chǎn)環(huán)境使用！以避免不必要的安全風(fēng)險。

安裝控制面

使用?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?服務(wù)，用于解析遠端服務(wù)的 DNS 地址。該服務(wù)使用的鏡像是 coredns 官方鏡像。

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

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

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

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

配置 ServiceEntry

為了實現(xiàn)在本集群中訪問遠端集群的服務(wù)，我們需要在本集群中注冊遠端服務(wù)的 ServiceEntry，設(shè)置 ServiceEntry 需要注意以下幾點：

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

以集群 1 訪問 集群 2 中的 httpbin.bar 服務(wù)為例，我們需要在 集群 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) 用于設(shè)置目的服務(wù)的 VIP，同時該服務(wù)的?endpoints?中，CLUSTER2_GW_ADDR?需要填寫集群 2 的 ingress gateway 地址。這會告訴 istio: 應(yīng)該將集群 1 訪問?240.0.0.2?的流量，路由到集群 2 的 ingress gateway。

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

SNI 感知網(wǎng)關(guān)分析

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

目的網(wǎng)關(guān)端口 15443 預(yù)設(shè)了 SNI 感知的 listener，具體地，從集群 1 中 client 發(fā)出的流量攔截到 sidecar 后，sidecar 會將其轉(zhuǎn)換為 mTLS 流量，并帶上 SNI 信息（httpbin）轉(zhuǎn)發(fā)出去。流量到達集群 2 的 ingress gateway 15443 端口后，該 ingress gateway 會提取 SNI 信息，分析出實際的目的服務(wù)為 httpbin 服務(wù)，最終轉(zhuǎn)發(fā)給集群 2 中 httpbin 服務(wù)的 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$?結(jié)尾的?cluster?替換為?svc.cluster.local，進而轉(zhuǎn)發(fā)到網(wǎng)格內(nèi)部，以此實現(xiàn)了 TLS 層的路由。

單控制面

與多控制面網(wǎng)格不同，單控制面網(wǎng)格中的所有集群，共享一個 istio 控制面，單控制面作為流控規(guī)則的唯一下發(fā)入口，會 watch 所有 Kubernetes 集群的服務(wù)發(fā)現(xiàn)數(shù)據(jù)，所有集群數(shù)據(jù)面的 Envoy 都會連接單控制面，獲得 xDS 信息。

「單網(wǎng)絡(luò)單控制面」和 「多網(wǎng)絡(luò)單控制面」的安裝流程類似，簡述如下。

配置各集群 CA 證書

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

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

主集群安裝控制面

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

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

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

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

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

遠端集群安裝

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

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

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

配置多網(wǎng)絡(luò)模式的 Gateway

如果是選擇「多網(wǎng)絡(luò)單控制面」，各集群都需要安裝一個入流量網(wǎng)關(guān)。這包括 2 個步驟，首先需要在每個集群中安裝網(wǎng)關(guān)對應(yīng)的 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"

關(guān)于 mTLS 和 AUTO_PASSTHROUGH

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

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

注冊遠端集群服務(wù)發(fā)現(xiàn)

對最簡單的單集群服務(wù)網(wǎng)格，pilot 會連接所在 kubernetes 集群的 api server，自動將該集群的服務(wù)發(fā)現(xiàn)數(shù)據(jù)（如 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}

至此「單控制面」服務(wù)網(wǎng)格搭建完畢。如果配置正確，主集群中的控制面將會 watch 遠端集群的服務(wù)數(shù)據(jù)，pilot 會整合所有集群的服務(wù)發(fā)現(xiàn)數(shù)據(jù)和流控規(guī)則，以 xDS 形式下發(fā)到各集群數(shù)據(jù)面。

部署模式選擇

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

「單控制面」模式，將多個集群聯(lián)結(jié)為一個統(tǒng)一的服務(wù)網(wǎng)格，集群間同名服務(wù)自動共享服務(wù)實例。這種模式適合于業(yè)務(wù)聯(lián)系緊密的多集群，甚至是業(yè)務(wù)對等的多集群。這些集群間服務(wù)互訪較多，所有集群共享流控治理規(guī)則。可以實現(xiàn)「地域感知路由」、「異地容災(zāi)」等高級的網(wǎng)格應(yīng)用場景。

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

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

引用鏈接

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

開源電子書 Istio Handbook

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

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

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

總結(jié)

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

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