宜信容器雲是一套基於kubernetes的容器管理平臺。業務線用戶在容器雲上部署應用程序時，常常會遇到容器無法啟動或者應用程序運行不正常的情況。為了方便用戶排查在應用上雲過程中的問題，我們在web端集成了一系列的排錯方式，如下圖：
一、終端信息
終端信息查看的是容器實例運行時的標準輸出日誌。
效果等同於：kubectl logs PODNAME [-c CONTAINER]
基本原理如下圖：
應用部署時，所屬節點的kubelet通過grpc調用容器運行時接口(container runtime interface)，來請求docker守護進程創建容器運行時。
此時，docker守護進程會創建一個協程來接收容器運行時的標準輸出日誌，這個協程最終將STDOUT(標準輸出)的日誌寫到容器運行時所在節點的對應目錄下：
<code>/var/lib/docker/containers/container_id/{container_id-json.log}/<code>如下圖:
在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 -c bash
web端顯示如圖：
實現如下：
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更改為
<code>/bin/bash –c chmod -R 777 KUBERNETES_FILELOGS;useradd spider > /dev/null 2>&1;su spider/<code>
其中環境變量KUBERNETES_FILELOGS為在容器創建時需要賦權的文件目錄。主要是防止用戶誤操作，刪除存儲掛載等。
四、debug容器
debug容器是通過工具容器來對業務容器排障。
在使用web terminal來調試應用程序的過程中，業務線用戶經常需要各式各樣的命令來調試程序。之前的解決方案要麼是給業務線定製他們所需的基礎鏡像，儘量涵蓋多的所需命令，要麼就是在業務線用戶構建鏡像時在Dockerfile中添加命令。
但是，因為業務線眾多，定製基礎鏡像工作量過大；而在構建業務鏡像時添加過多命令，又操作繁瑣，並可能會帶來安全隱患。這些解決方案實際上都不符合容器技術的實踐原則—儘可能構建最簡容器鏡像，而精簡後的鏡像又極度缺失所需的命令工具。
鑑於存在這樣的矛盾，我們集成並改造了kubectl-debug（https://github.com/aylei/kubectl-debug）這個插件。容器實質上是由cgroup和namespace限制的一組進程，只要能夠加入到這個進程的各項namespace，就可實現交互。因此，debug容器的基本思路是：啟動一個包含眾多排障工具命令的容器，來加入到業務容器的namespace中，便能夠在工具容器中實現對業務容器的排障。
效果類似於：
<code>docker run -it --network=container: --pid=container: --ipc=container : -v /log/container _ID:/debugviewlogs/<code>
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的操作也做了安全審計。
因此，我們只要構建一個包含眾多排障工具的鏡像，不僅實踐了業務鏡像儘可能最簡的原則，還提供了調試應用程序所需的各種命令工具。
