宜信容器云是一套基于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 describe pod來查看pod時，也一樣能看到與該pod相關的events，從這些信息中可以很清楚看到事件的狀態變化，從而獲知pod啟動失敗的多種原因。比如：1）沒有可用的node供調度，如調度的節點資源不夠；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 terminal主要是通過websocket技術實現的，前端交互界面使用的是開源項目container-terminal（https://github.com/kubernetes-ui/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容器
在使用web terminal來調試應用程序的過程中，業務線用戶經常需要各式各樣的命令來調試程序。之前的解決方案要么是給業務線定制他們所需的基礎鏡像，盡量涵蓋多的所需命令，要么就是在業務線用戶構建鏡像時在Dockerfile中添加命令。但是，因為業務線眾多，定制基礎鏡像工作量過大；而在構建業務鏡像時添加過多命令，又操作繁瑣，并可能會帶來安全隱患。這些解決方案實際上都不符合容器技術的實踐原則--盡可能構建最簡容器鏡像，而精簡后的鏡像又極度缺失所需的命令工具。鑒于存在這樣的矛盾，我們集成并改造了kubectl-debug（https://github.com/aylei/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>
將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排錯和對應用程序的排障。
【本文是51CTO專欄機構宜信技術學院的原創文章，微信公眾號“宜信技術學院( id: CE_TECH)”】
戳這里，看該作者更多好文
