Istio 運維實戰系列（3）：讓人頭大的『無頭服務』-下

時間  2020-09-30
標籤 istio 實戰 系列 讓人 頭大 無頭服務 简体版
原文   原文鏈接

本系列文章將介紹用戶從 Spring Cloud，Dubbo 等傳統微服務框架遷移到 Istio 服務網格時的一些經驗，以及在使用 Istio 過程當中可能遇到的一些常見問題的解決方法。html

失敗的 Eureka 心跳通知

在上一篇文章中，咱們介紹了 Headless Service 和普通 Service 的區別。因爲 Headless Service 的特殊性，在 Istio 下發給 Envoy Sidecar 的配置中，此類服務的配置參數和其餘服務的參數有所不一樣。除了咱們上次遇到的 mTLS 故障以外，這些差別可能還會致使應用出現一些其餘意想不到的狀況。java

此次遇到的問題現象是：在 Spring Cloud 應用遷移到 Istio 中後，服務提供者向 Eureka Server 發送心跳失敗。git

備註：Eureka Server 採用心跳機制來斷定服務的健康狀態。服務提供者在啓動後，週期性（默認30秒）向Eureka Server發送心跳，以證實當前服務是可用狀態。Eureka Server在必定的時間（默認90秒）未收到客戶端的心跳，則認爲服務宕機，註銷該實例。

查看應用程序日誌，能夠看到 Eureka 客戶端發送心跳失敗的相關日誌信息。github

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 地址

對於請求失敗類的故障，咱們首先能夠經過 Envoy 的訪問日誌查看失敗緣由。經過下面的命令查看客戶端 Envoy Sidecar 的日誌：算法

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

從 Envoy 日誌中能夠查看到客戶端經過 HTTP PUT 向服務器發出的心跳請求。該請求的 Response 狀態碼爲 "UF,URX"，表示其 Upstream Failure，即鏈接上游服務失敗。在日誌中還能夠看到，在鏈接失敗後，Envoy 向客戶端應用返回了一個 "503" HTTP 錯誤碼。spring

[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 將該請求轉發到了 IP地址 爲 172.16.0.198 的 Upstream Host。後端

查看集羣中部署的服務，能夠看到 eureka-server 是一個 Headless Service。api

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 運維實戰系列（2）：讓人頭大的『無頭服務』-上』中，咱們瞭解到 Headless Service 並無 Cluster IP，DNS 會直接將 Service 名稱解析到 Service 後端的多個 Pod IP 上。Envoy 日誌中顯示鏈接 Eureka Server地址 172.16.0.198 失敗，咱們來看看這個 IP 來自哪個 Eureka Server 的 Pod 。bash

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          6h55m   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          6h56m   172.16.1.3     10.0.0.14   <none>           <none>

從上面的命令輸出中能夠看到 Eureka 集羣中有三個服務器，但沒有哪個服務器的 Pod IP 是 Envoy 日誌中顯示的 172.16.0.198。進一步分析發現 eureka-server-1 Pod 的啓動時間比客戶端的啓動時間晚不少，初步懷疑 Envoy 採用了一個已經被銷燬的 Eureka Server 的 IP 進行訪問，致使訪問失敗。服務器

經過查看 Envoy dump 文件中 outbound|8761||eureka-server.eureka.svc.cluster.local 的相關配置，進一步加深了我對此的懷疑。從下面的 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",  # 該選項代表 Enovy 在轉發請求時會直接採用 downstream 原始請求中的地址。
      "connect_timeout": "1s",
      "lb_policy": "CLUSTER_PROVIDED",
   ...

}

根據 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.

即對於「ORIGINAL_DST」 類型的 Cluster，Envoy 在轉發請求時會直接採用 downstream 請求中的原始目的地 IP 地址，而不會採用服務發現機制。Istio 中 Envoy Sidecar 的該處理方式和 K8s 對 Headless Service 的處理是相似的，即由客戶端根據 DNS 直接選擇一個後端的 Pod IP，不會採用負載均衡算法對客戶端的請求進行重定向分發。但讓人疑惑的是：爲何客戶端經過 DNS 查詢獲得的 Pod 地址 172.16.0.198 訪問失敗了呢？這是因爲客戶端查詢 DNS 時獲得的地址在訪問期間已經不存在了。下圖解釋了致使該問題的緣由：

  1. Client 查詢 DNS 獲得 eureka-server 的三個IP地址。
  2. Client 選擇 Server-1 的 IP 172.16.0.198 發起鏈接請求，請求被 iptables rules 攔截並重定向到了客戶端 Pod 中 Envoy 的 VirtualInbound 端口 15001。
  3. 在收到 Client 的鏈接請求後，根據 Cluster 的配置，Envoy 採用請求中的原始目的地址 172.16.0.198 鏈接 Server-1，此時該 IP 對應的 Pod 是存在的，所以 Envoy 到 Server-1 的連接建立成功，Client 和 Envoy 之間的連接也會創建成功。Client 在建立連接時採用了 HTTP Keep Alive 選項，所以 Client 會一直保持該連接，並經過該連接以 30 秒間隔持續發送 HTTP PUT 服務心跳通知。
  4. 因爲某些緣由，該 Server-1 Pod 被 K8s 重建爲 Server-1ꞌ，IP 發生了變化。
  5. 當 Server-1 的 IP 變化後，Envoy 並不會當即主動斷開和 Client 端的連接。此時從 Client 的角度來看，到 172.16.0.198 的 TCP 連接依然是正常的，所以 Client 會繼續使用該連接發送 HTTP 請求。同時因爲 Cluster 類型爲 「ORIGINAL_DST」 ，Envoy 會繼續嘗試鏈接 Client 請求中的原始目的地址 172.16.0.198，如圖中藍色箭頭所示。可是因爲該 IP 上的 Pod 已經被銷燬，Envoy 會鏈接失敗，並在失敗後向 Client 端返回一個這樣的錯誤信息：「upstream connect error or disconnect/reset before headers. reset reason: connection failure HTTP/1.1 503」 。若是 Client 在收到該錯誤後不當即斷開並重建連接，那麼直到該連接超時以前，Client 都不會從新查詢 DNS 獲取到 Pod 重建後的正確地址。

爲 Headless Service 啓用 EDS

從前面的分析中咱們已經知道出錯的緣由是因爲客戶端 HTTP 長連接中的 IP 地址過時致使的。那麼一個最直接的想法就是讓 Envoy 採用正確的 IP 地址去鏈接 Upstream Host。在不修改客戶端代碼，不重建客戶端連接的狀況下，如何才能實現呢？

若是對比一個其餘服務的 Cluster 配置，能夠看到正常狀況下，Istio 下發的配置中，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",       # 普通服務採用 EDS 服務發現，根據 LB 算法從 EDS 下發的 endpoint 中選擇一個進行鏈接
   "eds_cluster_config": {
    "eds_config": {
     "ads": {},
     "resource_api_version": "V3"
    },
    "service_name": "outbound|8080||http-server.default.svc.cluster.local"
   },
  ...

 }

在採用 EDS 的狀況下，Envoy 會經過 EDS 獲取到該 Cluster 中全部可用的 Endpoint，並根據負載均衡算法（缺省爲 Round Robin）將 Downstream 發來的請求發送到不一樣的 Endpoint。所以只要把 Cluster 類型改成 EDS，Envoy 在轉發請求時就不會再採用請求中錯誤的原始 IP 地址，而會採用 EDS 自動發現到的 Endpoint 地址。採用 EDS 的狀況下，本例的中的訪問流程以下圖所示：

經過查閱 Istio 源碼，能夠發現 Istio 對於 Headless Service 缺省採用了 "ORIGINAL_DST" 類型的 Cluster，但咱們也能夠經過設置一個 Istiod 的環境變量 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 爲 Headless Service 強制啓用 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 {
            // 對於 Sidecar Proxy，若是 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 的值設爲 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 環境變量 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 設置爲 true 後，再查看 Envoy 的日誌，能夠看到雖然請求原始 IP 地址仍是 172.16.0.198，但 Envoy 已經把請求分發到了實際可用的三個 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

神祕消失的服務

在將 Eureka Server Cluster 的類型從 ORIGINAL_DST 改成 EDS 以後，以前心跳失敗的服務正常了。但過了一段時間後，發現原來 Eureka 中註冊的部分服務下線，致使服務之間沒法正常訪問。查詢 Eureka Server 的日誌，發現日誌中有以下的錯誤：

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

從日誌中咱們能夠看到多個 Eureka Server 之間的數據同步發生了錯誤。當部署爲集羣模式時，Eureka 集羣中的多個實例之間會進行數據同步，本例中的 Eureka 集羣中有三個實例，這些實例之間的數據同步以下圖所示：

當改用 EDS 以後，當集羣中的每個 Eureka Server 向集羣中的其餘 Eureka Server 發起數據同步時，這些請求被請求方 Pod 中的 Envoy Sidecar 採用 Round Robin 進行了隨機分發，致使同步消息發生了紊亂，集羣中每一個服務器中的服務註冊消息不一致，致使某些服務被誤判下線。該故障現象比較隨機，通過屢次測試，咱們發如今 Eureka 中註冊的服務較多時更容易出現改故障，當只有少許服務時不容易復現。

找到緣由後，要解決該問題就很簡單了，咱們能夠經過將 Eureka Server 的 Sidecar Injection 設置爲 false 來規避該問題，以下面的 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

反思

對於 Headless Service，Istio 缺省採用 「ORIGINAL_DST」 類型的 Cluster，要求 Envoy Sidecar 在轉發時採用請求原始目的 IP 地址的行爲實際上是合理的。如同咱們在本系列的上一篇文章『Istio 運維實戰系列（2）：讓人頭大的『無頭服務』-上』所介紹的，Headless Service 通常用於定義有狀態的服務。對於有狀態的服務，須要由客戶端根據應用特定的算法來自行決定訪問哪個後端 Pod，所以不該該在這些 Pod 前加一個負載均衡器。

在本例中，因爲 Eureka 集羣中各個節點之間會對收到的客戶端服務心跳通知進行同步，所以對於客戶端來講，將心跳通知發送到哪個 Eureka 節點並不重要，咱們能夠認爲 Eureka 集羣對於外部客戶端而言是無狀態的。所以設置 PILOT_ENABLE_EDS_FOR_HEADLESS_SERVICES 環境變量，在客戶端的 Envoy Sidecar 中對客戶端發往 Eureka Server 的請求進行負載均衡是沒有問題的。可是因爲 Eureka 集羣內部的各個節點之間的是有狀態的，修改後影響了集羣中各個 Eureka 節點之間的數據同步，致使了後面部分服務錯誤下線的問題。對於引起的該問題，咱們經過去掉 Eureka Server 的 Sidecar 注入來進行了規避。

對於該問題，更合理的處理方法是 Envoy Sidecar 在嘗試鏈接 Upstream Host 失敗必定次數後主動斷開和客戶端側的連接，由客戶端從新查詢 DNS，獲取正確的 Pod IP 來建立新的連接。通過測試驗證，Istio 1.6 及以後的版本中，Envoy 在 Upstream 連接斷開後會主動斷開和 Downstream 的長連接，建議儘快升級到 1.6 版本，以完全解決本問題。也能夠直接採用騰訊雲上的雲原生 Service Mesh 服務 TCM（Tencent Cloud Mesh），爲微服務應用快速引入 Service Mesh 的流量管理和服務治理能力，而無需再關注 Service Mesh 基礎設施自身的安裝、維護、升級等事項。

參考文檔

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程