Istio使用過程中出現(xiàn)的問題怎么解決

今天小編給大家分享一下Istio使用過程中出現(xiàn)的問題怎么解決的相關(guān)知識(shí)點(diǎn)，內(nèi)容詳細(xì)，邏輯清晰，相信大部分人都還太了解這方面的知識(shí)，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

失敗的 Eureka 心跳通知

在上一篇文章中，我們介紹了 Headless Service 和普通 Service 的區(qū)別。由于 Headless Service 的特殊性，在 Istio 下發(fā)給 Envoy Sidecar 的配置中，此類服務(wù)的配置參數(shù)和其他服務(wù)的參數(shù)有所不同。除了我們上次遇到的 mTLS 故障之外，這些差異可能還會(huì)導(dǎo)致應(yīng)用出現(xiàn)一些其他意想不到的情況。

這次遇到的問題現(xiàn)象是：在 Spring Cloud 應(yīng)用遷移到 Istio 中后，服務(wù)提供者向 Eureka Server 發(fā)送心跳失敗。

備注：Eureka Server 采用心跳機(jī)制來判定服務(wù)的健康狀態(tài)。服務(wù)提供者在啟動(dòng)后，周期性（默認(rèn)30秒）向Eureka Server發(fā)送心跳，以證明當(dāng)前服務(wù)是可用狀態(tài)。Eureka Server在一定的時(shí)間（默認(rèn)90秒）未收到客戶端的心跳，則認(rèn)為服務(wù)宕機(jī)，注銷該實(shí)例。

查看應(yīng)用程序日志，可以看到 Eureka 客戶端發(fā)送心跳失敗的相關(guān)日志信息。

2020-09-24 13:32:46.533 ERROR 1 --- [tbeatExecutor-0] com.netflix.discovery.DiscoveryClient    : DiscoveryClient_EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client - was unable to send heartbeat!

com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server
	at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:112) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.sendHeartBeat(EurekaHttpClientDecorator.java:89) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$3.execute(EurekaHttpClientDecorator.java:92) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.shared.transport.decorator.SessionedEurekaHttpClient.execute(SessionedEurekaHttpClient.java:77) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.sendHeartBeat(EurekaHttpClientDecorator.java:89) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.DiscoveryClient.renew(DiscoveryClient.java:864) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at com.netflix.discovery.DiscoveryClient$HeartbeatThread.run(DiscoveryClient.java:1423) ~[eureka-client-1.9.13.jar!/:1.9.13]
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[na:na]
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) ~[na:na]
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) ~[na:na]
	at java.base/java.lang.Thread.run(Thread.java:832) ~[na:na]

過期的 IP 地址

對(duì)于請(qǐng)求失敗類的故障，我們首先可以通過 Envoy 的訪問日志查看失敗原因。通過下面的命令查看客戶端 Envoy Sidecar 的日志：

k logs -f eureka-client-66f748f84f-vvvmz -c eureka-client -n eureka

從 Envoy 日志中可以查看到客戶端通過 HTTP PUT 向服務(wù)器發(fā)出的心跳請(qǐng)求。該請(qǐng)求的 Response 狀態(tài)碼為 "UF,URX"，表示其 Upstream Failure，即連接上游服務(wù)失敗。在日志中還可以看到，在連接失敗后，Envoy 向客戶端應(yīng)用返回了一個(gè) "503" HTTP 錯(cuò)誤碼。

[2020-09-24T13:31:37.980Z] "PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP&lastDirtyTimestamp=1600954114925 HTTP/1.1" 503 UF,URX "-" "-" 0 91 3037 - "-" "Java-EurekaClient/v1.9.13" "1cd54507-3f93-4ff3-a93e-35ead11da70f" "eureka-server:8761" "172.16.0.198:8761" outbound|8761||eureka-server.eureka.svc.cluster.local - 172.16.0.198:8761 172.16.0.169:53890 - default

從日志中可以看到訪問的 Upstream Cluster 是 outbound|8761||eureka-server.eureka.svc.cluster.local ，Envoy 將該請(qǐng)求轉(zhuǎn)發(fā)到了 IP地址 為 172.16.0.198 的 Upstream Host。

查看集群中部署的服務(wù)，可以看到 eureka-server 是一個(gè) Headless Service。

HUABINGZHAO-MB0:eureka-istio-test huabingzhao$ k get svc -n eureka -o wide
NAME            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE   SELECTOR
eureka-server   ClusterIP   None         <none>        8761/TCP   17m   app=eureka-server

在本系列的上一篇文章『Istio 運(yùn)維實(shí)戰(zhàn)系列（2）：讓人頭大的『無頭服務(wù)』-上』中，我們了解到 Headless Service 并沒有 Cluster IP，DNS 會(huì)直接將 Service 名稱解析到 Service 后端的多個(gè) Pod IP 上。Envoy 日志中顯示連接 Eureka Server地址 172.16.0.198 失敗，我們來看看這個(gè) IP 來自哪一個(gè) Eureka Server 的 Pod 。

HUABINGZHAO-MB0:eureka-istio-test huabingzhao$ k get pod -n eureka -o wide | grep eureka-server
NAME                             READY   STATUS    RESTARTS   AGE     IP             NODE        NOMINATED NODE   READINESS GATES
eureka-server-0                  1/1     Running   0          6h65m   172.16.0.59    10.0.0.15   <none>           <none>
eureka-server-1                  1/1     Running   0          6m1s    172.16.0.200   10.0.0.7    <none>           <none>
eureka-server-2                  1/1     Running   0          6h66m   172.16.1.3     10.0.0.14   <none>           <none>

從上面的命令輸出中可以看到 Eureka 集群中有三個(gè)服務(wù)器，但沒有哪一個(gè)服務(wù)器的 Pod IP 是 Envoy 日志中顯示的 172.16.0.198。進(jìn)一步分析發(fā)現(xiàn) eureka-server-1 Pod 的啟動(dòng)時(shí)間比客戶端的啟動(dòng)時(shí)間晚很多，初步懷疑 Envoy 采用了一個(gè)已經(jīng)被銷毀的 Eureka Server 的 IP 進(jìn)行訪問，導(dǎo)致訪問失敗。

通過查看 Envoy dump 文件中 outbound|8761||eureka-server.eureka.svc.cluster.local 的相關(guān)配置，進(jìn)一步加深了我對(duì)此的懷疑。從下面的 yaml 片段中可以看到該 Cluster 的類型為 “ORIGINAL_DST”。

{
     "version_info": "2020-09-23T03:57:03Z/27",
     "cluster": {
      "@type": "type.googleapis.com/envoy.api.v2.Cluster",
      "name": "outbound|8761||eureka-server.eureka.svc.cluster.local",
      "type": "ORIGINAL_DST",  # 該選項(xiàng)表明 Enovy 在轉(zhuǎn)發(fā)請(qǐng)求時(shí)會(huì)直接采用 downstream 原始請(qǐng)求中的地址。
      "connect_timeout": "1s",
      "lb_policy": "CLUSTER_PROVIDED",
   ...

}

根據(jù) Envoy 的文檔說明，“ORIGINAL_DST” 的解釋為：

In these cases requests routed to an original destination cluster are forwarded to upstream hosts as addressed by the redirection metadata, without any explicit host configuration or upstream host discovery.

即對(duì)于“ORIGINAL_DST” 類型的 Cluster，Envoy 在轉(zhuǎn)發(fā)請(qǐng)求時(shí)會(huì)直接采用 downstream 請(qǐng)求中的原始目的地 IP 地址，而不會(huì)采用服務(wù)發(fā)現(xiàn)機(jī)制。Istio 中 Envoy Sidecar 的該處理方式和 K8s 對(duì) Headless Service 的處理是類似的，即由客戶端根據(jù) DNS 直接選擇一個(gè)后端的 Pod IP，不會(huì)采用負(fù)載均衡算法對(duì)客戶端的請(qǐng)求進(jìn)行重定向分發(fā)。但讓人疑惑的是：為什么客戶端通過 DNS 查詢得到的 Pod 地址 172.16.0.198 訪問失敗了呢？這是由于客戶端查詢 DNS 時(shí)得到的地址在訪問期間已經(jīng)不存在了。下圖解釋了導(dǎo)致該問題的原因：

1. Client 查詢 DNS 得到 eureka-server 的三個(gè)IP地址。

2. Client 選擇 Server-1 的 IP 172.16.0.198 發(fā)起連接請(qǐng)求，請(qǐng)求被 iptables rules 攔截并重定向到了客戶端 Pod 中 Envoy 的 VirtualInbound 端口 15001。

3. 在收到 Client 的連接請(qǐng)求后，根據(jù) Cluster 的配置，Envoy 采用請(qǐng)求中的原始目的地址 172.16.0.198 連接 Server-1，此時(shí)該 IP 對(duì)應(yīng)的 Pod 是存在的，因此 Envoy 到 Server-1 的鏈接創(chuàng)建成功，Client 和 Envoy 之間的鏈接也會(huì)建立成功。Client 在創(chuàng)建鏈接時(shí)采用了 HTTP Keep Alive 選項(xiàng)，因此 Client 會(huì)一直保持該鏈接，并通過該鏈接以 30 秒間隔持續(xù)發(fā)送 HTTP PUT 服務(wù)心跳通知。

4. 由于某些原因，該 Server-1 Pod 被 K8s 重建為 Server-1?，IP 發(fā)生了變化。

5. 當(dāng) Server-1 的 IP 變化后，Envoy 并不會(huì)立即主動(dòng)斷開和 Client 端的鏈接。此時(shí)從 Client 的角度來看，到 172.16.0.198 的 TCP 鏈接依然是正常的，因此 Client 會(huì)繼續(xù)使用該鏈接發(fā)送 HTTP 請(qǐng)求。同時(shí)由于 Cluster 類型為 “ORIGINAL_DST” ，Envoy 會(huì)繼續(xù)嘗試連接 Client 請(qǐng)求中的原始目的地址 172.16.0.198，如圖中藍(lán)色箭頭所示。但是由于該 IP 上的 Pod 已經(jīng)被銷毀，Envoy 會(huì)連接失敗，并在失敗后向 Client 端返回一個(gè)這樣的錯(cuò)誤信息：“upstream connect error or disconnect/reset before headers. reset reason: connection failure HTTP/1.1 503” 。如果 Client 在收到該錯(cuò)誤后不立即斷開并重建鏈接，那么直到該鏈接超時(shí)之前，Client 都不會(huì)重新查詢 DNS 獲取到 Pod 重建后的正確地址。

為 Headless Service 啟用 EDS

從前面的分析中我們已經(jīng)知道出錯(cuò)的原因是由于客戶端 HTTP 長鏈接中的 IP 地址過期導(dǎo)致的。那么一個(gè)最直接的想法就是讓 Envoy 采用正確的 IP 地址去連接 Upstream Host。在不修改客戶端代碼，不重建客戶端鏈接的情況下，如何才能實(shí)現(xiàn)呢？

如果對(duì)比一個(gè)其他服務(wù)的 Cluster 配置，可以看到正常情況下，Istio 下發(fā)的配置中，Cluster 類型為 EDS （Endopoint Discovery Service），如下面的 yaml 片段所示：

 {
  "version_info": "2020-09-23T03:02:01Z/2",
  "cluster": {
   "@type": "type.googleapis.com/envoy.config.cluster.v3.Cluster",
   "name": "outbound|8080||http-server.default.svc.cluster.local",
   "type": "EDS",       # 普通服務(wù)采用 EDS 服務(wù)發(fā)現(xiàn)，根據(jù) LB 算法從 EDS 下發(fā)的 endpoint 中選擇一個(gè)進(jìn)行連接
   "eds_cluster_config": {
    "eds_config": {
     "ads": {},
     "resource_api_version": "V3"
    },
    "service_name": "outbound|8080||http-server.default.svc.cluster.local"
   },
  ...

 }

在采用 EDS 的情況下，Envoy 會(huì)通過 EDS 獲取到該 Cluster 中所有可用的 Endpoint，并根據(jù)負(fù)載均衡算法（缺省為 Round Robin）將 Downstream 發(fā)來的請(qǐng)求發(fā)送到不同的 Endpoint。因此只要把 Cluster 類型改為 EDS，Envoy 在轉(zhuǎn)發(fā)請(qǐng)求時(shí)就不會(huì)再采用請(qǐng)求中錯(cuò)誤的原始 IP 地址，而會(huì)采用 EDS 自動(dòng)發(fā)現(xiàn)到的 Endpoint 地址。采用 EDS 的情況下，本例的中的訪問流程如下圖所示：

通過查閱 Istio 源碼，可以發(fā)現(xiàn) Istio 對(duì)于 Headless Service 缺省采用了 "ORIGINAL_DST" 類型的 Cluster，但我們也可以通過設(shè)置一個(gè) Istiod 的環(huán)境變量 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 為 Headless Service 強(qiáng)制啟用 EDS 。

func convertResolution(proxy *model.Proxy, service *model.Service) cluster.Cluster_DiscoveryType {
	switch service.Resolution {
	case model.ClientSideLB:
		return cluster.Cluster_EDS
	case model.DNSLB:
		return cluster.Cluster_STRICT_DNS
	case model.Passthrough: // Headless Service 的取值為 model.Passthrough
		if proxy.Type == model.SidecarProxy {
            // 對(duì)于 Sidecar Proxy，如果 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 的值設(shè)為 True，則啟用 EDS，否則采用 ORIGINAL_DST
			if service.Attributes.ServiceRegistry == string(serviceregistry.Kubernetes) && features.EnableEDSForHeadless {
				return cluster.Cluster_EDS
			}

			return cluster.Cluster_ORIGINAL_DST
		}
		return cluster.Cluster_EDS
	default:
		return cluster.Cluster_EDS
	}
}

在將 Istiod 環(huán)境變量 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 設(shè)置為 true 后，再查看 Envoy 的日志，可以看到雖然請(qǐng)求原始 IP 地址還是 172.16.0.198，但 Envoy 已經(jīng)把請(qǐng)求分發(fā)到了實(shí)際可用的三個(gè) Server 的 IP 上。

[2020-09-24T13:35:28.790Z] "PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP&lastDirtyTimestamp=1600954114925 HTTP/1.1" 200 - "-" "-" 0 0 4 4 "-" "Java-EurekaClient/v1.9.13" "d98fd3ab-778d-42d4-a361-d27c2491eff0" "eureka-server:8761" "172.16.1.3:8761" outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:39934 172.16.0.198:8761 172.16.0.169:53890 - default
[2020-09-24T13:35:58.797Z] "PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP&lastDirtyTimestamp=1600954114925 HTTP/1.1" 200 - "-" "-" 0 0 1 1 "-" "Java-EurekaClient/v1.9.13" "7799a9a0-06a6-44bc-99f1-a928d8576b7c" "eureka-server:8761" "172.16.0.59:8761" outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:45582 172.16.0.198:8761 172.16.0.169:53890 - default
[2020-09-24T13:36:28.801Z] "PUT /eureka/apps/EUREKA-TEST-CLIENT/eureka-client-544b94f967-gcx2f:eureka-test-client?status=UP&lastDirtyTimestamp=1600954114925 HTTP/1.1" 200 - "-" "-" 0 0 2 1 "-" "Java-EurekaClient/v1.9.13" "aefb383f-a86d-4c96-845c-99d6927c722e" "eureka-server:8761" "172.16.0.200:8761" outbound|8761||eureka-server.eureka.svc.cluster.local 172.16.0.169:60794 172.16.0.198:8761 172.16.0.169:53890 - default

神秘消失的服務(wù)

在將 Eureka Server Cluster 的類型從 ORIGINAL_DST 改為 EDS 之后，之前心跳失敗的服務(wù)正常了。但過了一段時(shí)間后，發(fā)現(xiàn)原來 Eureka 中注冊的部分服務(wù)下線，導(dǎo)致服務(wù)之間無法正常訪問。查詢 Eureka Server 的日志，發(fā)現(xiàn)日志中有如下的錯(cuò)誤：

2020-09-24 14:07:35.511  WARN 6 --- [eureka-server-3] c.netflix.eureka.cluster.PeerEurekaNode  : EUREKA-SERVER-2/eureka-server-2.eureka-server.eureka.svc.cluster.local:eureka-server-2:8761:Heartbeat@eureka-server-0.eureka-server: missing entry.
2020-09-24 14:07:35.511  WARN 6 --- [eureka-server-3] c.netflix.eureka.cluster.PeerEurekaNode  : EUREKA-SERVER-2/eureka-server-2.eureka-server.eureka.svc.cluster.local:eureka-server-2:8761:Heartbeat@eureka-server-0.eureka-server: cannot find instance

從日志中我們可以看到多個(gè) Eureka Server 之間的數(shù)據(jù)同步發(fā)生了錯(cuò)誤。當(dāng)部署為集群模式時(shí)，Eureka 集群中的多個(gè)實(shí)例之間會(huì)進(jìn)行數(shù)據(jù)同步，本例中的 Eureka 集群中有三個(gè)實(shí)例，這些實(shí)例之間的數(shù)據(jù)同步如下圖所示：

當(dāng)改用 EDS 之后，當(dāng)集群中的每一個(gè) Eureka Server 向集群中的其他 Eureka Server 發(fā)起數(shù)據(jù)同步時(shí)，這些請(qǐng)求被請(qǐng)求方 Pod 中的 Envoy Sidecar 采用 Round Robin 進(jìn)行了隨機(jī)分發(fā)，導(dǎo)致同步消息發(fā)生了紊亂，集群中每個(gè)服務(wù)器中的服務(wù)注冊消息不一致，導(dǎo)致某些服務(wù)被誤判下線。該故障現(xiàn)象比較隨機(jī)，經(jīng)過多次測試，我們發(fā)現(xiàn)在 Eureka 中注冊的服務(wù)較多時(shí)更容易出現(xiàn)改故障，當(dāng)只有少量服務(wù)時(shí)不容易復(fù)現(xiàn)。

找到原因后，要解決該問題就很簡單了，我們可以通過將 Eureka Server 的 Sidecar Injection 設(shè)置為 false 來規(guī)避該問題，如下面的 yaml 片段所示：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: eureka-server
spec:
  selector:
    matchLabels:
      app: eureka-server
  serviceName: "eureka-server"
  replicas: 3
  template:
    metadata:
      labels:
        app: eureka-server
      annotations:
        sidecar.istio.io/inject: "false"  # 不為 eureka-server pod 注入 Envoy Siedecar
    spec:
      containers:
      - name: eureka-server
        image: zhaohuabing/eureka-test-service:latest
        ports:
        - containerPort: 8761
          name: http

反思

對(duì)于 Headless Service，Istio 缺省采用 “ORIGINAL_DST” 類型的 Cluster，要求 Envoy Sidecar 在轉(zhuǎn)發(fā)時(shí)采用請(qǐng)求原始目的 IP 地址的行為其實(shí)是合理的。如同我們在本系列的上一篇文章『Istio 運(yùn)維實(shí)戰(zhàn)系列（2）：讓人頭大的『無頭服務(wù)』-上』所介紹的，Headless Service 一般用于定義有狀態(tài)的服務(wù)。對(duì)于有狀態(tài)的服務(wù)，需要由客戶端根據(jù)應(yīng)用特定的算法來自行決定訪問哪一個(gè)后端 Pod，因此不應(yīng)該在這些 Pod 前加一個(gè)負(fù)載均衡器。

在本例中，由于 Eureka 集群中各個(gè)節(jié)點(diǎn)之間會(huì)對(duì)收到的客戶端服務(wù)心跳通知進(jìn)行同步，因此對(duì)于客戶端來說，將心跳通知發(fā)送到哪一個(gè) Eureka 節(jié)點(diǎn)并不重要，我們可以認(rèn)為 Eureka 集群對(duì)于外部客戶端而言是無狀態(tài)的。因此設(shè)置 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 環(huán)境變量，在客戶端的 Envoy Sidecar 中對(duì)客戶端發(fā)往 Eureka Server 的請(qǐng)求進(jìn)行負(fù)載均衡是沒有問題的。但是由于 Eureka 集群內(nèi)部的各個(gè)節(jié)點(diǎn)之間的是有狀態(tài)的，修改后影響了集群中各個(gè) Eureka 節(jié)點(diǎn)之間的數(shù)據(jù)同步，導(dǎo)致了后面部分服務(wù)錯(cuò)誤下線的問題。對(duì)于引發(fā)的該問題，我們通過去掉 Eureka Server 的 Sidecar 注入來進(jìn)行了規(guī)避。

對(duì)于該問題，更合理的處理方法是 Envoy Sidecar 在嘗試連接 Upstream Host 失敗一定次數(shù)后主動(dòng)斷開和客戶端側(cè)的鏈接，由客戶端重新查詢 DNS，獲取正確的 Pod IP 來創(chuàng)建新的鏈接。經(jīng)過測試驗(yàn)證，Istio 1.6 及之后的版本中，Envoy 在 Upstream 鏈接斷開后會(huì)主動(dòng)斷開和 Downstream 的長鏈接，建議盡快升級(jí)到 1.6 版本，以徹底解決本問題。也可以直接采用騰訊云上的云原生 Service Mesh 服務(wù) TCM（Tencent Cloud Mesh），為微服務(wù)應(yīng)用快速引入 Service Mesh 的流量管理和服務(wù)治理能力，而無需再關(guān)注 Service Mesh 基礎(chǔ)設(shè)施自身的安裝、維護(hù)、升級(jí)等事項(xiàng)。

以上就是“Istio使用過程中出現(xiàn)的問題怎么解決”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會(huì)為大家更新不同的知識(shí)，如果還想學(xué)習(xí)更多的知識(shí)，請(qǐng)關(guān)注億速云行業(yè)資訊頻道。