Istio is the future!基本上,我相信對雲原生技術趨勢有些微判斷的同學,都會有這個覺悟。其背後的邏輯其實是比較簡單的:當容器集群,特別是 Kubernetes 成為事實上的標準之後,應用必然會不斷的複雜化,服務治理肯定會成為強需求。
Istio 的現狀是,聊的人很多,用的人其實很少。所以導致我們能看到的文章,講道理的很多,講實際踩坑經驗的極少。阿里雲售後團隊作為一線踩坑團隊,分享問題排查經驗,我們責無旁貸。這篇文章,我就跟大家聊一個簡單 Istio 問題的排查過程,權當拋磚。
二分之一活的微服務
問題是這樣的,用戶在自己的測試集群裡安裝了 Istio,並依照官方文檔部署 bookinfo 應用來上手 Istio。部署之後,用戶執行 kubectl get pods 命令,發現所有的 Pod 都只有二分之一個容器是 READY 的。
如果從來都沒有注意過 READY 這一列的話,我們大概會有兩個疑惑:2 在這裡是什麼意思,以及 1/2 到底意味著什麼。
簡單來講,這裡的 READY 列,給出的是每個 Pod 內部容器的 Readiness,即就緒狀態。每個集群節點上的 kubelet 會根據容器本身 Readiness 規則的定義,分別是 tcp、http 或 exec 的方式,來確認對應容器的 Readiness 情況。
更具體一點,kubelet 作為運行在每個節點上的進程,以 tcp/http 的方式(節點網絡命名空間到 Pod 網絡命名空間)訪問容器定義的接口,或者在容器的 namespace 裡執行 exec 定義的命令,來確定容器是否就緒。
這裡的 2 說明這些 Pod 裡都有兩個容器,1/2 則表示,每個 Pod 裡只有一個容器是就緒的,即通過 Readiness 測試的。關於 2 這一點,我們下一節會深入講,這裡我們先看一下,為什麼所有的 Pod 裡,都有一個容器沒有就緒。
使用 kubectl 工具拉取第一個 details pod 的編排模板,可以看到這個 Pod 裡兩個容器,只有一個定義了 readiness probe。對於未定義 readiness probe 的容器, kubelet 認為,只要容器裡的進程開始運行,容器就進入就緒狀態了。所以 1/2 個就緒 Pod,意味著,有定義 readiness probe 的容器,沒有通過 kubelet 的測試。
沒有通過 readiness probe 測試的是 istio-proxy 這個容器。它的 readiness probe 規則定義如下:
readinessProbe:
failureThreshold: 30
httpGet:
path: /healthz/ready
port: 15020
scheme: HTTP
initialDelaySeconds: 1
periodSeconds: 2
successThreshold: 1
timeoutSeconds: 1
我們登錄這個 Pod 所在的節點,用 curl 工具來模擬 kubelet 訪問下邊的 uri,測試 istio-proxy 的就緒狀態。
繞不過去的大圖
上一節我們描述了問題現象,但是留下一個問題,就是 Pod 裡的容器個數為什麼是 2。雖然每個 Pod 本質上至少有兩個容器:一個是佔位符容器 pause,另一個是真正的工作容器,但是我們在使用 kubectl 命令獲取 Pod 列表的時候,READY 列是不包括 pause 容器的。
這裡的另外一個容器,其實就是服務網格的核心概念 sidercar。其實把這個容器叫做 sidecar,某種意義上是不能反映這個容器的本質的。Sidecar 容器本質上是反向代理,它本來是一個 Pod 訪問其他服務後端 Pod 的負載均衡。
然而,當我們為集群中的每一個 Pod,都“隨身”攜帶一個反向代理的時候,Pod 和反向代理就變成了服務網格。正如下邊這張經典大圖所示。這張圖實在有點難畫,所以只能借用,繞不過去。
所以 sidecar 模式,其實是“自帶通信員”模式。這裡比較有趣的是,在我們把 sidecar 和 Pod 綁定在一塊的時候,sidecar 在出流量轉發時扮演著反向代理的角色,而在入流量接收的時候,可以做超過反向代理職責的一些事情。這點我們會在其他文章裡討論。
Istio 在 Kubernetes 基礎上實現了服務網格,Isito 使用的 sidecar 容器就是第一節提到的,沒有就緒的容器。所以這個問題,其實就是服務網格內部,所有的 sidecar 容器都沒有就緒。
代理與代理的生命週期管理
上一節我們看到,Istio 中的每個 Pod,都自帶了反向代理 sidecar。我們遇到的問題是,所有的 sidecar 都沒有就緒。我們也看到 readiness probe 定義的,判斷 sidecar 容器就緒的方式就是訪問下邊這個接口:
接下來,我們深入看下 Pod,以及其 sidecar 的組成及原理。在服務網格里,一個 Pod 內部除了本身處理業務的容器之外,還有 istio-proxy 這個 sidecar 容器。正常情況下,istio-proxy 會啟動兩個進程:pilot-agent 和 Envoy。
如下圖,Envoy 是實際上負責流量管理等功能的代理,從業務容器出、入的數據流,都必須要經過 Envoy;而 pilot-agent 負責維護 Envoy 的靜態配置,以及管理 Envoy 的生命週期。這裡的動態配置部分,我們在下一節會展開來講。
我們可以使用下邊的命令進入 Pod 的 istio-proxy 容器做進一步排查。這裡的一個小技巧,是我們可以以用戶 1337,使用特權模式進入 istio-proxy 容器,如此就可以使用 iptables 等只能在特權模式下運行的命令。
docker exec -ti -u 1337 --privileged bash
這裡的 1337 用戶,其實是 sidecar 鏡像裡定義的一個同名用戶 istio-proxy,默認 sidecar 容器使用這個用戶。如果我們在以上命令中,不使用用戶選項 u,則特權模式實際上是賦予 root 用戶的,所以我們在進入容器之後,需切換到 root 用戶執行特權命令。
進入容器之後,我們使用 netstat 命令查看監聽,我們會發現,監聽 readiness probe 端口 15020 的,其實是 pilot-agent 進程。
istio-proxy@details-v1-68868454f5-94hzd:/$ netstat -lnpt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:15090 0.0.0.0:* LISTEN 19/envoy
tcp 0 0 127.0.0.1:15000 0.0.0.0:* LISTEN 19/envoy
tcp 0 0 0.0.0.0:9080 0.0.0.0:* LISTEN -
tcp6 0 0 :::15020 :::* LISTEN 1/pilot-agent
我們在istio-proxy內部訪問readiness probe接口,一樣會得到503的錯誤。
就緒檢查的實現
瞭解了 sidecar 的代理,以及管理代理生命週期的 pilot-agent 進程,我們可以稍微思考一下 pilot-agent 應該怎麼去實現 healthz/ready 這個接口。顯然,如果這個接口返回 OK 的話,那不僅意味著 pilot-agent 是就緒的,而必須確保代理是工作的。
實際上 pilot-agent 就緒檢查接口的實現正是如此。這個接口在收到請求之後,會去調用代理 Envoy 的 server_info 接口。調用所使用的 IP 是 Localhost。這個非常好理解,因為這是同一個 Pod 內部進程通信。使用的端口是 Envoy 的 proxyAdminPort,即 15000。
有了以上的知識準備之後,我們來看下 istio-proxy 這個容器的日誌。實際上,在容器日誌裡,一直在重複輸出一個報錯,這句報錯分為兩部分,其中 Envoy proxy is NOT ready 這部分是 pilot agent 在響應 healthz/ready 接口的時候輸出的信息,即 Envoy 代理沒有就緒;而剩下的 config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected 這部分,是 pilot-agent 通過 proxyAdminPort 訪問 server_info 的時候帶回的信息,看起來是 Envoy 沒有辦法從 Pilot 獲取配置。
Envoy proxy is NOT ready: config not received from Pilot (is Pilot running?): cds updates: 0 successful, 0 rejected; lds updates: 0 successful, 0 rejected.
到這裡,建議大家回退看下上一節的插圖,在上一節我們選擇性的忽略是 Pilot 到 Envoy 這條虛線,即動態配置。這裡的報錯,實際上是 Envoy 從控制面 Pilot 獲取動態配置失敗。
控制面和數據面
目前為止,這個問題其實已經很清楚了。在進一步分析問題之前,我聊一下我對控制面和數據面的理解。控制面數據面模式,可以說無處不在。我們這裡舉兩個極端的例子。
第一個例子,是 DHCP 服務器。我們都知道,在局域網中的電腦,可以通過配置 DHCP 來獲取 IP 地址,這個例子中,DHCP 服務器統一管理,動態分配 IP 地址給網絡中的電腦,這裡的 DHCP 服務器就是控制面,而每個動態獲取 IP 的電腦就是數據面。
第二個例子,是電影劇本,和電影的演出。劇本可以認為是控制面,而電影的演出,包括演員的每一句對白,電影場景佈置等,都可以看做是數據面。
我之所以認為這是兩個極端,是因為在第一個例子中,控制面僅僅影響了電腦的一個屬性,而第二個例子,控制面幾乎是數據面的一個完整的抽象和拷貝,影響數據面的方方面面。Istio 服務網格的控制面是比較靠近第二個例子的情況,如下圖:
Istio 的控制面 Pilot 使用 gRPC 協議對外暴露接口 istio-pilot.istio-system:15010,而 Envoy 無法從 Pilot 處獲取動態配置的原因,是在所有的 Pod 中,集群 DNS 都無法使用。
簡單的原因
這個問題的原因其實比較簡單,在 sidecar 容器 istio-proxy 裡,Envoy 不能訪問 Pilot 的原因是集群 DNS 無法解析 istio-pilot.istio-system 這個服務名字。在容器裡看到 resolv.conf 配置的 DNS 服務器是 172.19.0.10,這個是集群默認的 kube-dns 服務地址。
istio-proxy@details-v1-68868454f5-94hzd:/$ cat /etc/resolv.conf
nameserver 172.19.0.10
search default.svc.cluster.local svc.cluster.local cluster.local localdomain
但是客戶刪除重建了 kube-dns 服務,且沒有指定服務 IP,這導致,實際上集群 DNS 的地址改變了,這也是為什麼所有的 sidecar 都無法訪問 Pilot。
svc -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 172.19.9.54 53/UDP,53/TCP 5d
最後,通過修改 kube-dns 服務,指定 IP 地址,sidecar 恢復正常。
結論
這其實是一個比較簡單的問題,排查過程其實也就幾分鐘。但是寫這篇文章,有點感覺是在看長安十二時辰,短短幾分鐘的排查過程,寫完整背後的原理,前因後果,卻花了幾個小時。這是 Istio 文章的第一篇,希望在大家排查問題的時候,有所幫助。
本文轉自<阿里巴巴雲原生技術圈>——阿里巴巴雲原生小助手