作者 | 聲東? 阿里云售后技術(shù)專家

**<關(guān)注阿里巴巴云原生公眾號，回復?排查?即可下載電子書> **

《深入淺出 Kubernetes》一書共匯集 12 篇技術(shù)文章，幫助你一次搞懂 6 個核心原理，吃透基礎理論，一次學會 6 個典型問題的華麗操作！

Istio is the future！基本上，我相信對云原生技術(shù)趨勢有些微判斷的同學，都會有這個覺悟。其背后的邏輯其實是比較簡單的：當容器集群，特別是 Kubernetes 成為事實上的標準之后，應用必然會不斷的復雜化，服務治理肯定會成為強需求。

**Istio 的現(xiàn)狀是，聊的人很多，用的人其實很少。**所以導致我們能看到的文章，講道理的很多，講實際踩坑經(jīng)驗的極少。阿里云售后團隊作為一線踩坑團隊，分享問題排查經(jīng)驗，我們責無旁貸。這篇文章，我就跟大家聊一個簡單 Istio 問題的排查過程，權(quán)當拋磚。

二分之一活的微服務

問題是這樣的，用戶在自己的測試集群里安裝了 Istio，并依照官方文檔部署 bookinfo 應用來上手 Istio。部署之后，用戶執(zhí)行 kubectl get pods 命令，發(fā)現(xiàn)所有的 Pod 都只有二分之一個容器是 READY 的。

# kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 1/2 Running 0 1m productpage-v1-5cb458d74f-28nlz 1/2 Running 0 1m ratings-v1-76f4c9765f-gjjsc 1/2 Running 0 1m reviews-v1-56f6855586-dplsf 1/2 Running 0 1m reviews-v2-65c9df47f8-zdgbw 1/2 Running 0 1m reviews-v3-6cf47594fd-cvrtf 1/2 Running 0 1m

如果從來都沒有注意過 READY 這一列的話，我們大概會有兩個疑惑：2 在這里是什么意思，以及 1/2 到底意味著什么。

簡單來講，這里的 READY 列，給出的是每個 Pod 內(nèi)部容器的 Readiness，即就緒狀態(tài)。每個集群節(jié)點上的 kubelet 會根據(jù)容器本身 Readiness 規(guī)則的定義，分別是 tcp、http 或 exec 的方式，來確認對應容器的 Readiness 情況。

更具體一點，kubelet 作為運行在每個節(jié)點上的進程，以 tcp/http 的方式（節(jié)點網(wǎng)絡命名空間到 Pod 網(wǎng)絡命名空間）訪問容器定義的接口，或者在容器的 namespace 里執(zhí)行 exec 定義的命令，來確定容器是否就緒。

這里的 2 說明這些 Pod 里都有兩個容器，1/2 則表示，每個 Pod 里只有一個容器是就緒的，即通過 Readiness 測試的。關(guān)于 2 這一點，我們下一節(jié)會深入講，這里我們先看一下，為什么所有的 Pod 里，都有一個容器沒有就緒。

使用 kubectl 工具拉取第一個 details pod 的編排模板，可以看到這個 Pod 里兩個容器，只有一個定義了 readiness probe。對于未定義 readiness probe 的容器， kubelet 認為，只要容器里的進程開始運行，容器就進入就緒狀態(tài)了。所以 1/2 個就緒 Pod，意味著，有定義 readiness probe 的容器，沒有通過 kubelet 的測試。

沒有通過 readiness probe 測試的是 istio-proxy 這個容器。它的 readiness probe 規(guī)則定義如下：

readinessProbe:failureThreshold: 30httpGet:path: /healthz/readyport: 15020scheme: HTTPinitialDelaySeconds: 1periodSeconds: 2successThreshold: 1timeoutSeconds: 1

我們登錄這個 Pod 所在的節(jié)點，用 curl 工具來模擬 kubelet 訪問下邊的 uri，測試 istio-proxy 的就緒狀態(tài)。

# curl http://172.16.3.43:15020/healthz/ready -v * About to connect() to 172.16.3.43 port 15020 (#0) * Trying 172.16.3.43... * Connected to 172.16.3.43 (172.16.3.43) port 15020 (#0) > GET /healthz/ready HTTP/1.1 > User-Agent: curl/7.29.0 > Host: 172.16.3.43:15020 > Accept: */*> < HTTP/1.1 503 Service Unavailable< Date: Fri, 30 Aug 2019 16:43:50 GMT < Content-Length: 0 < * Connection #0 to host 172.16.3.43 left intact

繞不過去的大圖

上一節(jié)我們描述了問題現(xiàn)象，但是留下一個問題，就是 Pod 里的容器個數(shù)為什么是 2。雖然每個 Pod 本質(zhì)上至少有兩個容器：一個是占位符容器 pause，另一個是真正的工作容器，但是我們在使用 kubectl 命令獲取 Pod 列表的時候，READY 列是不包括 pause 容器的。

這里的另外一個容器，其實就是服務網(wǎng)格的核心概念 sidercar。其實把這個容器叫做 sidecar，某種意義上是不能反映這個容器的本質(zhì)的。Sidecar 容器本質(zhì)上是反向代理，它本來是一個 Pod 訪問其他服務后端 Pod 的負載均衡。

然而，當我們?yōu)榧褐械拿恳粋€ Pod，都“隨身”攜帶一個反向代理的時候，Pod 和反向代理就變成了服務網(wǎng)格。正如下邊這張經(jīng)典大圖所示。這張圖實在有點難畫，所以只能借用，繞不過去。

所以 sidecar 模式，其實是“自帶通信員”模式。這里比較有趣的是，在我們把 sidecar 和 Pod 綁定在一塊的時候，sidecar 在出流量轉(zhuǎn)發(fā)時扮演著反向代理的角色，而在入流量接收的時候，可以做超過反向代理職責的一些事情。這點我們會在其他文章里討論。

Istio 在 Kubernetes 基礎上實現(xiàn)了服務網(wǎng)格，Isito 使用的 sidecar 容器就是第一節(jié)提到的，沒有就緒的容器。所以這個問題，其實就是服務網(wǎng)格內(nèi)部，所有的 sidecar 容器都沒有就緒。

代理與代理的生命周期管理

上一節(jié)我們看到，Istio 中的每個 Pod，都自帶了反向代理 sidecar。我們遇到的問題是，所有的 sidecar 都沒有就緒。我們也看到 readiness probe 定義的，判斷 sidecar 容器就緒的方式就是訪問下邊這個接口：

http://<pod ip>:15020/healthz/ready

接下來，我們深入看下 Pod，以及其 sidecar 的組成及原理。在服務網(wǎng)格里，一個 Pod 內(nèi)部除了本身處理業(yè)務的容器之外，還有 istio-proxy 這個 sidecar 容器。正常情況下，istio-proxy 會啟動兩個進程：pilot-agent 和 Envoy。

如下圖，Envoy 是實際上負責流量管理等功能的代理，從業(yè)務容器出、入的數(shù)據(jù)流，都必須要經(jīng)過 Envoy；而 pilot-agent 負責維護 Envoy 的靜態(tài)配置，以及管理 Envoy 的生命周期。這里的動態(tài)配置部分，我們在下一節(jié)會展開來講。

我們可以使用下邊的命令進入 Pod 的 istio-proxy 容器做進一步排查。這里的一個小技巧，是我們可以以用戶 1337，使用特權(quán)模式進入 istio-proxy 容器，如此就可以使用 iptables 等只能在特權(quán)模式下運行的命令。

docker exec -ti -u 1337 --privileged <istio-proxy container id> bash

這里的 1337 用戶，其實是 sidecar 鏡像里定義的一個同名用戶 istio-proxy，默認 sidecar 容器使用這個用戶。如果我們在以上命令中，不使用用戶選項 u，則特權(quán)模式實際上是賦予 root 用戶的，所以我們在進入容器之后，需切換到 root 用戶執(zhí)行特權(quán)命令。

進入容器之后，我們使用 netstat 命令查看監(jiān)聽，我們會發(fā)現(xiàn)，監(jiān)聽 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內(nèi)部訪問readiness probe接口，一樣會得到503的錯誤。

就緒檢查的實現(xiàn)

了解了 sidecar 的代理，以及管理代理生命周期的 pilot-agent 進程，我們可以稍微思考一下 pilot-agent 應該怎么去實現(xiàn) healthz/ready 這個接口。顯然，如果這個接口返回 OK 的話，那不僅意味著 pilot-agent 是就緒的，而必須確保代理是工作的。

實際上 pilot-agent 就緒檢查接口的實現(xiàn)正是如此。這個接口在收到請求之后，會去調(diào)用代理 Envoy 的 server_info 接口。調(diào)用所使用的 IP 是 Localhost。這個非常好理解，因為這是同一個 Pod 內(nèi)部進程通信。使用的端口是 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.

到這里，建議大家回退看下上一節(jié)的插圖，在上一節(jié)我們選擇性的忽略是 Pilot 到 Envoy 這條虛線，即動態(tài)配置。這里的報錯，實際上是 Envoy 從控制面 Pilot 獲取動態(tài)配置失敗。

控制面和數(shù)據(jù)面

目前為止，這個問題其實已經(jīng)很清楚了。在進一步分析問題之前，我聊一下我對控制面和數(shù)據(jù)面的理解。控制面數(shù)據(jù)面模式，可以說無處不在。我們這里舉兩個極端的例子。

第一個例子，是 DHCP 服務器。我們都知道，在局域網(wǎng)中的電腦，可以通過配置 DHCP 來獲取 IP 地址，這個例子中，DHCP 服務器統(tǒng)一管理，動態(tài)分配 IP 地址給網(wǎng)絡中的電腦，這里的 DHCP 服務器就是控制面，而每個動態(tài)獲取 IP 的電腦就是數(shù)據(jù)面。

第二個例子，是電影劇本，和電影的演出。劇本可以認為是控制面，而電影的演出，包括演員的每一句對白，電影場景布置等，都可以看做是數(shù)據(jù)面。

我之所以認為這是兩個極端，是因為在第一個例子中，控制面僅僅影響了電腦的一個屬性，而第二個例子，控制面幾乎是數(shù)據(jù)面的一個完整的抽象和拷貝，影響數(shù)據(jù)面的方方面面。Istio 服務網(wǎng)格的控制面是比較靠近第二個例子的情況，如下圖：

Istio 的控制面 Pilot 使用 gRPC 協(xié)議對外暴露接口 istio-pilot.istio-system:15010，而 Envoy 無法從 Pilot 處獲取動態(tài)配置的原因，是在所有的 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。

# kubectl get svc -n kube-system NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 172.19.9.54 <none> 53/UDP,53/TCP 5d

最后，通過修改 kube-dns 服務，指定 IP 地址，sidecar 恢復正常。

# kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 2/2 Running 0 6d nginx-647d5bf6c5-gfvkm 2/2 Running 0 2d nginx-647d5bf6c5-wvfpd 2/2 Running 0 2d productpage-v1-5cb458d74f-28nlz 2/2 Running 0 6d ratings-v1-76f4c9765f-gjjsc 2/2 Running 0 6d reviews-v1-56f6855586-dplsf 2/2 Running 0 6d reviews-v2-65c9df47f8-zdgbw 2/2 Running 0 6d reviews-v3-6cf47594fd-cvrtf 2/2 Running 0 6d

結(jié)論

這其實是一個比較簡單的問題，排查過程其實也就幾分鐘。但是寫這篇文章，有點感覺是在看長安十二時辰，短短幾分鐘的排查過程，寫完整背后的原理，前因后果，卻花了幾個小時。這是 Istio 文章的第一篇，希望在大家排查問題的時候，有所幫助。

第 3 期云原生網(wǎng)絡研討會邀您參加

5 月 28 日，阿里云技術(shù)專家將為大家?guī)怼度绾螢樵圃鷳脦矸€(wěn)定高效的部署能力？》，屆時將會介紹阿里經(jīng)濟體大規(guī)模應用上云過程中遇到的核心部署問題、采取的對應解決方案，以及這些方案沉淀為通用化能力輸出開源后，如何幫助阿里云上的用戶提升應用部署發(fā)布的效率與穩(wěn)定性。

聽眾可獲取以下收益：

? 了解阿里經(jīng)濟體大規(guī)模應用上云的實踐經(jīng)驗，如何解決原生 K8s workload 不滿足場景需求的問題；
? 作為外部用戶，如何體驗和使用上阿里經(jīng)濟體上云所沉淀下來的應用部署發(fā)布能力；
? 演示阿里巴巴針對大規(guī)模 K8s 集群如何做到 DaemonSet 高可用的灰度升級（即將開源！）

點擊鏈接即可預約直播：https://yq.aliyun.com/live/2898

“阿里巴巴云原生關(guān)注微服務、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的公眾號?！?/p>

總結(jié)

以上是生活随笔為你收集整理的Istio 从懵圈到熟练：二分之一活的微服务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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