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

騰訊雲原生發表於2020-09-29

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

什麼是『無頭服務』？

『無頭服務』即 Kubernetes 中的 Headless Service。Service 是 Kubernetes 對後端一組提供相同服務的 Pod 的邏輯抽象和訪問入口。Kubernetes 會根據排程演算法為 Pod 分配一個執行節點，並隨機分配一個 IP 地址；在很多情況下，我們還會對 Pod 進行水平伸縮，啟動多個 Pod 來提供相同的服務。在有多個 Pod 並且 Pod IP 地址不固定的情況下，客戶端很難通過 Pod 的 IP 地址來直接進行訪問。為了解決這個問題，Kubernetes 採用 Service 資源來表示提供相同服務的一組 Pod。

在預設情況下，Kubernetes 會為 Service 分配一個 Cluster IP，不管後端的 Pod IP 如何變化，Service 的 Cluster IP 始終是固定的。因此客戶端可以通過這個 Cluster IP 來訪問這一組 Pod 提供的服務，而無需再關注後端的各個真實的 Pod IP。我們可以將 Service 看做放在一組 Pod 前的一個負載均衡器，而 Cluster IP 就是該負載均衡器的地址，這個負載均衡器會關注後端這組 Pod 的變化，並把發向 Cluster IP 的請求轉發到後端的 Pod 上。(備註：這只是對 Service 的一個簡化描述，如果對 Service 的內部實現感興趣，可以參考這篇文章如何為服務網格選擇入口閘道器？）

對於無狀態的應用來說，客戶端並不在意其連線的是哪一個 Pod，採用 Service 是沒有問題的。但在某些特殊情況下，並不能這樣做。例如，如果後端的這一組 Pod 是有狀態的，需要由客戶端根據某種應用相關的演算法來選擇哪一個 Pod 提供服務；或者客戶端需要連線所有的後端 Pod，這時我們就不能在這一組 Pod 前放一個負載均衡器了。這種情況下，我們需要採用 Headless Service，即無頭服務（該命名把多個 Pod 前面的負載均衡器比作服務的頭，很形象是不是？）。在定義 Headless Service，我們需要把 Service 的 Cluster IP 顯示設定為 None，這樣 Kubernetes DNS 在解析該 Service 時會直接返回其後端的多個 Pod IP，而不是 Service 的 Cluster IP。

假設從客戶端訪問一個 Redis 叢集，分別採用帶 Cluster IP 的普通 Service 和 Headless Service 進行訪問的過程如下圖所示：

Istio 中『無頭服務』的 mTLS 故障

由於 Headless Service 的特殊性，Istio 中對 Headless Service 的處理和普通 Service 有所不同，在應用遷移到 Isito 的過程中也常常遇到由於 Headless Service 導致的一些問題。下面我們就以一個由於 Headless Service 的 mTLS 故障導致的典型案例進行說明。

故障現象：運維同學反饋從帶 Envoy Sidecar 的 Pod 中訪問 Redis 伺服器，但在沒有安裝 Sidecar 的 Pod 中可以正常訪問該 Redis 伺服器。

遇到無法進行出向訪問的問題，我們可以首先通過 Envoy 的管理介面來檢視 Envoy 的訪問日誌。在客戶端 Pod 中執行下面的命令檢視 Envoy 日誌：

kubectl logs -f redis-client-6d4c6c975f-bm5w6 -c istio-proxy

日誌中對 Redis 的訪問記錄如下，其中 UR，URX 是 Response Flag，表示 upstream connection failure，即連線上游失敗。

[2020-09-12T13:38:23.077Z] "- - -" 0 UF,URX "-" "-" 0 0 1001 - "-" "-" "-" "-" "10.1.1.24:6379" outbound|6379||redis.default.svc.cluster.local - 10.1.1.24:6379 10.1.1.25:45940 - -

我們可以通過 Envoy 管理介面匯出其 xDS 配置，以進一步分析其失敗原因。

kubectl exec redis-client-6d4c6c975f-bm5w6 -c istio-proxy curl http://127.0.0.1:15000/config_dump

由於是出向訪問錯誤，因此我們主要關注客戶端中該出向訪問的 Cluster 的配置。在匯出的 xDS 配置中，可以看到 Redis Cluster 的配置，如下面的 yaml 片段所示（為了方便讀者檢視，去掉了該 yaml 中一些無關的內容）：

{
     "version_info": "2020-09-13T00:33:43Z/5",
     "cluster": {
      "@type": "type.googleapis.com/envoy.api.v2.Cluster",
      "name": "outbound|6379||redis.default.svc.cluster.local",
      "type": "ORIGINAL_DST",
      "connect_timeout": "1s",
      "lb_policy": "CLUSTER_PROVIDED",
      "circuit_breakers": {
        ...
      },

      # mTLS 相關設定
      "transport_socket": {
       "name": "envoy.transport_sockets.tls",
       "typed_config": {
        "@type": "type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext",
        "common_tls_context": {
         "alpn_protocols": [
          "istio-peer-exchange",
          "istio"
         ],

         # 訪問 Redis 使用的客戶端證書
         "tls_certificate_sds_secret_configs": [
          {
           "name": "default",
           "sds_config": {
            "api_config_source": {
             "api_type": "GRPC",
             "grpc_services": [
              {
                "envoy_grpc": {
                "cluster_name": "sds-grpc"
               }
              }
             ]
            }
           }
          }
         ],

         "combined_validation_context": {
          "default_validation_context": {
           # 用於驗證 Redis 伺服器身份的 spiffe indentity
           "verify_subject_alt_name": [
            "spiffe://cluster.local/ns/default/sa/default"
           ]
          },
          # 用於驗證 Redis 伺服器的根證書
          "validation_context_sds_secret_config": {
           "name": "ROOTCA",
           "sds_config": {
            "api_config_source": {
             "api_type": "GRPC",
             "grpc_services": [
              {
               "envoy_grpc": {
                "cluster_name": "sds-grpc"
               }
              }
             ]
            }
           }
          }
         }
        },
        "sni": "outbound_.6379_._.redis.default.svc.cluster.local"
       }
      },
      "filters": [
       {
         ...
       }
      ]
     },
     "last_updated": "2020-09-13T00:33:43.862Z"
    }

在 transport_socket 部分的配置中，我們可以看到 Envoy 中配置了訪問 Redis Cluster 的 tls 證書資訊，包括 Envoy Sidecar 用於訪問 Redis 使用的客戶端證書，用於驗證 Redis 伺服器證書的根證書，以及採用 spiffe 格式表示的，需驗證的伺服器端身份資訊。這裡的證書相關內容是使用 xDS 協議中的 SDS（Secret discovery service）獲取的，由於篇幅原因在本文中不對此展開進行介紹。如果需要了解 Istio 的證書和 SDS 相關機制，可以參考這篇文章一文帶你徹底釐清 Isito 中的證書工作機制。從上述配置可以得知，當收到 Redis 客戶端發起的請求後，客戶端 Pod 中的 Envoy Sidecar 會使用 mTLS 向 Redis 伺服器發起請求。

Redis 客戶端中 Envoy Sidecar 的 mTLS 配置本身看來並沒有什麼問題。但我們之前已經得知該 Redis 服務並未安裝 Envoy Sidecar，因此實際上 Redis 伺服器端只能接收 plain TCP 請求。這就導致了客戶端 Envoy Sidecar 在向 Redis 伺服器建立連結時失敗了。

Redis 客戶端以為是這樣的：

但實際上是這樣的：

在伺服器端沒有安裝 Envoy Sidecar，不支援 mTLS 的情況下，按理客戶端的 Envoy 不應該採用 mTLS 向伺服器端發起連線。這是怎麼回事呢？我們對比一下客戶端 Envoy 中的其他 Cluster 中的相關配置。

一個訪問正常的 Cluster 的 mTLS 相關配置如下：

   {
     "version_info": "2020-09-13T00:32:39Z/4",
     "cluster": {
      "@type": "type.googleapis.com/envoy.api.v2.Cluster",
      "name": "outbound|8080||awesome-app.default.svc.cluster.local",
      "type": "EDS",
      "eds_cluster_config": {
       "eds_config": {
        "ads": {}
       },
       "service_name": "outbound|8080||awesome-app.default.svc.cluster.local"
      },
      "connect_timeout": "1s",
      "circuit_breakers": {
       ...
      },
      ...

      # mTLS 相關的配置
      "transport_socket_matches": [
       {
        "name": "tlsMode-istio",
        "match": {
         "tlsMode": "istio"  #對帶有 "tlsMode": "istio" lable 的 endpoint，啟用 mTLS
        },
        "transport_socket": {
         "name": "envoy.transport_sockets.tls",
         "typed_config": {
          "@type": "type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext",
          "common_tls_context": {
           "alpn_protocols": [
            "istio-peer-exchange",
            "istio",
            "h2"
           ],
           "tls_certificate_sds_secret_configs": [
            {
             "name": "default",
             "sds_config": {
              "api_config_source": {
               "api_type": "GRPC",
               "grpc_services": [
                {
                 "envoy_grpc": {
                  "cluster_name": "sds-grpc"
                 }
                }
               ]
              }
             }
            }
           ],
           "combined_validation_context": {
            "default_validation_context": {},
            "validation_context_sds_secret_config": {
             "name": "ROOTCA",
             "sds_config": {
              "api_config_source": {
               "api_type": "GRPC",
               "grpc_services": [
                {
                 "envoy_grpc": {
                  "cluster_name": "sds-grpc"
                 }
                }
               ]
              }
             }
            }
           }
          },
          "sni": "outbound_.6379_._.redis1.dubbo.svc.cluster.local"
         }
        }
       },
       {
        "name": "tlsMode-disabled",
        "match": {},   # 對所有其他的 enpoint，不啟用 mTLS，使用 plain TCP 進行連線
        "transport_socket": {
         "name": "envoy.transport_sockets.raw_buffer"
        }
       }
      ]
     },
     "last_updated": "2020-09-13T00:32:39.535Z"
    }

從配置中可以看到，一個正常的 Cluster 中有兩部分 mTLS 相關的配置：tlsMode-istio 和 tlsMode-disabled。tlsMode-istio 部分和 Redis Cluster 的配置類似，但包含一個匹配條件（match部分），該條件表示只對帶有 "tlsMode" : "istio" lable 的 endpoint 啟用 mTLS；對於不帶有該標籤的 endpoint 則會採用 tlsMode-disabled 部分的配置，使用 raw_buffer，即 plain TCP 進行連線。

檢視 Istio 的相關原始碼，可以得知，當 Istio webhook 向 Pod 中注入 Envoy Sidecar 時，會同時為 Pod 新增一系列 label，其中就包括 "tlsMode" : "istio" 這個 label，如下面的程式碼片段所示：

  patchLabels := map[string]string{
		label.TLSMode:                                model.IstioMutualTLSModeLabel,
		model.IstioCanonicalServiceLabelName:         canonicalSvc,
		label.IstioRev:                               revision,
		model.IstioCanonicalServiceRevisionLabelName: canonicalRev,
	}

由於 Pod 在被注入 Envoy Sidecar 的同時被加上了該標籤，客戶端 Enovy Sidecar 在向該 Pod 發起連線時，根據 endpoint 中的標籤匹配到 tlsMode-istio 中的配置，就會採用 mTLS；而如果一個 Pod 沒有被注入 Envoy Sidecar，自然不會有該 Label，因此不能滿足前面配置所示的匹配條件，客戶端的 Envoy Sidecar 會根據 tlsMode-disabled 中的配置，採用 plain TCP 連線該 endpoint。這樣同時相容了伺服器端支援和不支援 mTLS 兩種情況。

下圖展示了 Istio 中是如何通過 endpoint 的標籤來相容 mTLS 和 plain TCP 兩種情況的。

通過和正常 Cluster 的對比，我們可以看到 Redis Cluster 的配置是有問題的，按理 Redis Cluster 的配置也應該通過 endpoint 的 tlsMode 標籤進行判斷，以決定客戶端的 Envoy Sidecar 是通過 mTLS 還是 plain TCP 發起和 Redis 伺服器的連線。但實際情況是 Redis Cluster 中只有 mTLS 的配置，導致了前面我們看到的連線失敗故障。

Redis 是一個 Headless Service，通過在社群查詢相關資料，發現 Istio 1.6 版本前對 Headless Service 的處理有問題，導致了該故障。參見這個 Issue Istio 1.5 prevents all connection attempts to Redis (headless) service #21964。

解決方案

找到了故障原因後，要解決這個問題就很簡單了。我們可以通過一個 Destination Rule 禁用 Redis Service 的 mTLS。如下面的 yaml 片段所示：

kind: DestinationRule
metadata:
  name: redis-disable-mtls
spec:
  host: redis.default.svc.cluster.local
  trafficPolicy:
    tls:
      mode: DISABLE

再檢視客戶端 Envoy 中的 Redis Cluster 配置，可以看到 mTLS 已經被禁用，Cluster 中不再有 mTLS 相關的證書配置。

    {
     "version_info": "2020-09-13T09:02:28Z/7",
     "cluster": {
      "@type": "type.googleapis.com/envoy.api.v2.Cluster",
      "name": "outbound|6379||redis.dubbo.svc.cluster.local",
      "type": "ORIGINAL_DST",
      "connect_timeout": "1s",
      "lb_policy": "CLUSTER_PROVIDED",
      "circuit_breakers": {
        ...
      },
      "metadata": {
       "filter_metadata": {
        "istio": {
         "config": "/apis/networking.istio.io/v1alpha3/namespaces/dubbo/destination-rule/redis-disable-mtls"
        }
       }
      },
      "filters": [
       {
        "name": "envoy.filters.network.upstream.metadata_exchange",
        "typed_config": {
         "@type": "type.googleapis.com/udpa.type.v1.TypedStruct",
         "type_url": "type.googleapis.com/envoy.tcp.metadataexchange.config.MetadataExchange",
         "value": {
          "protocol": "istio-peer-exchange"
         }
        }
       }
      ]
     },
     "last_updated": "2020-09-13T09:02:28.514Z"
    }

此時再嘗試從客戶端訪問 Redis 伺服器，一切正常！

小結

Headless Service 是 Kubernetes 中一種沒有 Cluster IP 的特殊 Service，Istio 中對 Headless Service 的處理流程和普通 Service 有所不同。由於 Headless Service 的特殊性，我們在將應用遷移到 Istio 的過程中常常會遇到與此相關的問題。

這次我們遇到的問題是由於 Istio 1.6 之前的版本，對 Headless Service 處理的一個 Bug 導致無法連線到 Headless Service。該問題是一個高頻故障，我們已經遇到過多次。可以通過建立 Destination Rule 禁用 Headless Service 的 mTLS 來規避該問題。該故障在1.6版本中已經修復，建議儘快升級到 1.6 版本，以徹底解決本問題。也可以直接採用騰訊雲上的雲原生 Service Mesh 服務 TCM（Tencent Cloud Mesh），為微服務應用快速引入 Service Mesh 的流量管理和服務治理能力，而無需再關注 Service Mesh 基礎設施自身的安裝、維護、升級等事項。

Headless Service 的坑較多，除了這一個故障以外，我們還在遷移過程中遇到了其他一些關於 Headless Service 的問題，在後續文章中再繼續和大家分享。

附錄

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！

Istio 運維實戰系列（3）：讓人頭大的『無頭服務』-下
2020-09-29
運維
Istio的運維-診斷工具(istio 系列五)
2020-06-09
運維
「IT運維迷宮」那些讓人頭疼的常見問題與破局之道
2024-04-30
運維
服務網格大戰，再見 Istio! - Fossas
2021-06-11
Istio 運維實戰系列（1）：應用容器對 Envoy Sidecar 的啟動依賴問題
2020-09-29
運維IDE
淺談那些年讓運維掉了大把頭髮的併發統計
2018-08-06
運維
讓人頭疼的BCProxy許可權
2020-04-04
IT運維服務管理的實施步驟
2020-06-04
運維
多伺服器運維管理運維管理不再頭疼
2020-03-03
伺服器運維
Istio實踐（2）-流量控制及服務間呼叫
2022-04-12
servicemesher/istio-handbook：服務網格Istio中文思維導圖
2020-03-16
k8s-服務網格實戰-入門Istio
2023-11-01
K8S
拯救運維人！智慧運維如何實現1＋1>2
2021-01-21
運維
從頭構建和訓練 GPT-2 ｜實戰
2024-07-14
GPT
為什麼國產資料庫的日誌看了讓人上頭呢？
2024-01-25
資料庫
MySQL運維實戰系列：MySQL5.7GroupBy問題
2018-11-29
MySql運維
go-zero 微服務實戰系列（二、服務拆分）
2022-06-10
Go微服務
運維轉型之路 —手工運維到無人值守的自動化運維，從根本實現降本增效
2022-12-02
運維
拳頭首席設計師勵志人生：沒上大學曾為餐館服務生
2019-06-03
戰鬥民族進軍無人駕駛，合作雙方都是本土巨頭
2018-03-06
Glance基礎服務運維
2022-04-30
運維
Istio的流量管理(實操二)(istio 系列四)
2020-05-25
Istio的流量管理(實操一)(istio 系列三)
2020-05-14
螞蟻金服 Service Mesh 大規模落地系列 - 運維篇
2020-01-02
運維
NodeJS 實戰系列：個人開發者應該如何選購雲服務
2023-04-02
NodeJS
在阿里雲容器服務上基於Istio實現東西向流量管理
2018-09-14
阿里
使用Istio服務網格實現流量映象
2018-12-31
Istio最佳實踐：在K8s上透過Istio服務網格進行灰度釋出
2018-09-05
K8S
透過自動化運維實現無人值守的故障自愈
2024-04-12
運維
什麼是IT運維管理服務
2022-12-09
運維
還在寫那些讓人頭皮發麻的程式碼嗎？
2019-02-13
工作中遇到很讓人頭疼的上司怎麼辦？
2018-03-22
2D頭像生成3D虛擬人開影片會，谷歌新作讓人難繃
2024-05-31
3D谷歌
無人值守的運維到底靠譜不靠譜?
2018-12-27
運維
這年頭，連無人機都有了“身份證”！
2018-03-13
無人機
JavaCV的攝像頭實戰之四：抓圖
2022-01-27
Java
JavaCV的攝像頭實戰之一：基礎
2022-01-21
Java
JavaCV的攝像頭實戰之五：推流
2022-02-09
Java

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

什麼是『無頭服務』？

Istio 中『無頭服務』的 mTLS 故障

解決方案

小結

附錄

相關文章