宜信容器雲排錯工具集

宜信容器雲是一套基於kubernetes的容器管理平臺。業務線使用者在容器雲上部署應用程式時，常常會遇到容器無法啟動或者應用程式執行不正常的情況。為了方便使用者排查在應用上雲過程中的問題，我們在web端整合了一系列的排錯方式，如下圖：

一、終端資訊

終端資訊檢視的是容器例項執行時的標準輸出日誌。

效果等同於： kubectl logs PODNAME [-c CONTAINER]

基本原理如下圖：

應用部署時，所屬節點的kubelet透過grpc呼叫容器執行時介面(container runtime interface)，來請求docker守護程式建立容器執行時。

此時，docker守護程式會建立一個協程來接收容器執行時的標準輸出日誌，這個協程最終將STDOUT(標準輸出)的日誌寫到容器執行時所在節點的對應目錄下： /var/lib/docker/containers/container_id/{container_id-json.log}

如下圖:

在web端檢視對應例項的終端資訊時，kubelet將接收的Api-server請求轉化成docker client來請求docker守護程式。Docker守護程式到相應的目錄下讀取對應容器的日誌檔案資料，再由kubelet返回日誌資料到Api-server，最終顯示到web端，供使用者檢視。

容器日誌的生命週期與容器的生命週期一致，容器銷燬後，其相關的日誌檔案也會銷燬。

二、events

events是kubelet用來記錄容器啟動及執行過程中的事件。

效果等同於： kubectl get events

同樣，當使用kubectl describe pod來檢視pod時，也一樣能看到與該pod相關的events，從這些資訊中可以很清楚看到事件的狀態變化，從而獲知pod啟動失敗的多種原因。比如：

1）沒有可用的node供排程，如排程的節點資源不夠；

2）健康狀態檢查失敗；

3）拉取映象失敗，如下圖：

events的基本實現如下圖：

events中包含事件相關的型別、原因、來源、訊息等，會在kubelet和controller manager等元件中生成，廣播出去後，經過一系列的函式過濾、聚合等，再傳送給Api-server存到etcd中。當web端檢視events事件時，請求Api-server讀取etcd中相應的事件，並返回顯示，供使用者檢視異常引數、錯誤狀態等。

三、web terminal

web terminal可提供一個互動式的介面shell,可執行各種命令。

效果等同於： kubectl exec -it <podName> -c <containerName> bash

web端顯示如圖：

實現如下：

web terminal主要是透過websocket技術實現的，前端互動介面使用的是開源專案container-terminal（）,其提供了一個容器的TTY(虛擬終端)。

當檢視web terminal時，前端web發起了一個websocket請求，到Api-server。再由所屬節點的kubelet響應該Api-server的請求，並與容器執行時建立連線。

之所以kubelet能夠與容器執行時建立連線，是因為kubelet 定義了一個 CRI 規範中的 RuntimeServiceClient 介面，而容器執行時中的RuntimeServiceServer（即Streaming Server，提供了streaming API）實現了該介面。

kubelet 和容器執行時建立連線後,kubelet返回請求，Api-server將請求升級為SPDY(SPDY允許在單個的TCP請求中複用獨立的STDIN/STDOUT/STDERR),並將WS的流對映到SPDY相應的標準流上,便與目標容器執行時Streaming Server建立了流，Api-server便實現了web與容器執行時的資料互動。

此時，在web端輸入命令，下發執行完後，可看到返回的結果，如此便實現了互動。

web terminal提供了進入容器的便利，使用者可以執行任何操作，為了安全，我們做了必要的安全措施：

1）記錄了使用者的操作命令。

待使用者輸入命令後，記錄操作，作為安全審計。

2）生產環境使用普通使用者進入容器。

即在exec進入容器時的命令 /bin/bash -i更改為 /bin/bash –c chmod -R 777 $KUBERNETES_FILELOGS;useradd spider > /dev/null 2>&1;su spider,其中環境變數$KUBERNETES_FILELOGS為在容器建立時需要賦權的檔案目錄。主要是防止使用者誤操作，刪除儲存掛載等。

四、debug容器

debug容器是透過工具容器來對業務容器排障。

在使用web terminal來除錯應用程式的過程中，業務線使用者經常需要各式各樣的命令來除錯程式。之前的解決方案要麼是給業務線定製他們所需的基礎映象，儘量涵蓋多的所需命令，要麼就是在業務線使用者構建映象時在Dockerfile中新增命令。

但是，因為業務線眾多，定製基礎映象工作量過大；而在構建業務映象時新增過多命令，又操作繁瑣，並可能會帶來安全隱患。這些解決方案實際上都不符合容器技術的實踐原則--儘可能構建最簡容器映象，而精簡後的映象又極度缺失所需的命令工具。

鑑於存在這樣的矛盾，我們整合並改造了kubectl-debug（）這個外掛。容器實質上是由cgroup和namespace限制的一組程式，只要能夠加入到這個程式的各項namespace，就可實現互動。因此，debug容器的基本思路是：啟動一個包含眾多排障工具命令的容器，來加入到業務容器的namespace中，便能夠在工具容器中實現對業務容器的排障。

效果類似於：

docker run -it --network=container:<container_ID> --pid=container:<container_ID> --ipc=container :<container_ID> -v /log/container _ID:/debugviewlogs <image>

web端顯示如下圖：

debug容器原理如下圖：

將Debug-agent以DaemonSet的形式部署到kubernetes叢集的所有節點中，並掛載了宿主機的/var/docker/docker.sock，實現與docker daemon的通訊。如上圖的步驟：

1）web端提供pod的cluster、namespace、podname資訊，向後端服務Backend server發起websocket請求;

2）後端服務Backend server接收到請求後，向Api-server驗證該pod是否存在，並返回pod所在的宿主機Node和pod的容器資訊，根據狀態判斷是否可以debug；

注意：如果pod的狀態reason是CrashLoopBackOff，那麼Backend server將會請求Api-server讓kubelet複製一個pod, 複製的Pod被改寫了啟動命令（sleep）、去掉了label及健康檢查。後續debug操作是對複製後pod進行的。

3）Backend server傳遞debug的pod資訊，發起debug請求（升級的SPDY請求，對映了WS的標準流）。

4）Debug-agent收到請求後，開始拉取debug工具映象，進而建立一個debug容器，並將debug容器的各個namespace設定為目標業務容器app的namespace。再將宿主Node的目錄/log/  掛載到debug容器的目錄/debugviewlogs中，便可實現將debug容器中生成的檔案在web端下載。如下兩圖：

建立完debug容器後，Debug-agent將Backend server的SPDY請求中繼到debug容器。debug容器將SPDY的標準流attach到業務容器中。如此，web端便可與debug容器實現互動。在debug操作結束後，Debug-agent便會將debug容器清理回收。同樣的，debug的操作也做了安全審計。

因此，我們只要構建一個包含眾多排障工具的映象，不僅實踐了業務映象儘可能最簡的原則，還提供了除錯應用程式所需的各種命令工具。

總結

終端資訊、events、web terminal及debug容器都提供了一個視覺化的web，讓使用者能夠方便快速地實現對pods排錯和對應用程式的排障。

12月5日(本週四)20點，由宜信技術學院發起的第7期宜信技術沙龍邀請到了宜信高階架構師陳曉宇老師，以《宜信容器雲的A點與B點》為主題，介紹其設計思想、技術架構和核心功能，以及容器雲在宜信落地的實踐經驗。

本次分享以線上直播的方式進行，識別下圖二維碼，新增小助手微信，回覆“容器雲”即可獲得直播地址。

作者：段德華

來源：宜信技術學院