利用Tmux和kubectl解決Kubernetes故障

作者：Abhishek Tamrakar 2020-02-25 21:32:59

一個使用 tmux 的 kubectl 插件可以使 Kubernetes 疑難問題變得更簡單。

[[316174]]

一個使用 tmux 的 kubectl 插件可以使 Kubernetes 疑難問題變得更簡單。

Kubernetes 是一個活躍的開源容器管理平臺，它提供了可擴展性、高可用性、健壯性和富有彈性的應用程序管理。它的眾多特性之一是支持通過其主要的二進制客戶端 kubectl 運行定制腳本或可執行程序，kubectl 很強大的，允許用戶在 Kubernetes 集群上用它直接做很多事情。

使用別名進行 Kubernetes 的故障排查

使用 Kubernetes 進行容器編排的人都知道由于設計上原因帶來了其功能的復雜性。舉例說，迫切需要以更快的速度并且幾乎不需要手動干預的方式來簡化 Kubernetes 中的故障排除（除過特殊情況）。

在故障排查功能方面，有很多場景需要考慮。在一種場景下，你知道你需要運行什么，但是這個命令的語法（即使作為一個單獨的命令運行）過于復雜，或需要一、兩次交互才能起作用。

例如，如果你需要經常進入一個系統命名空間中運行的容器，你可能發現自己在重復地鍵入：

kubectl --namespace=kube-system exec -i -t <your-pod-name>

為了簡化故障排查，你可以用這些指令的命令行別名。比如，你可以增加下面命令到你的隱藏配置文件（.bashrc 或 .zshrc）：

alias ksysex='kubectl --namespace=kube-system exec -i -t'

這是來自于 Kubernetes 常見別名存儲庫的一個例子，它展示了一種簡化 kubectl 中的功能的方法。像這種場景下的簡單情形，使用別名很有用。

切換到 kubectl 插件

更復雜的故障排查場景是需要一個一個的執行很多命令，調查環境，最后得出結論。僅僅用別名方法是不能解決這種情況的；你需要知道你所部署的 Kubernetes 之間邏輯和相關性，你真正需要的是自動化，以在更短的時間內輸出你想要的。

考慮到你的集群有 10 ~ 20 或 50 ~ 100 個命名空間來提供不同的微服務。一般在進行故障排查時，什么對你有幫助？

你需要能夠快速分辨出拋出錯誤的是哪個命名空間的哪個 Pod 的東西。
你需要一些可監視一個命名空間的所有 Pod 日志的東西。
你可能也需要監視特定命名空間的出現錯誤的某個 Pod 的日志。

涵蓋這些要點的解決方案對于定位生產環境的問題有很大的幫助，以及在開發和測試環節中也很有用。

你可以用 kubectl 插件創建比簡單的別名更強大的功能。插件類似于其它用任何語言編寫的獨立腳本，但被設計為可以擴充 Kubernetes 管理員的主要命令。

創建一個插件，你必須用 kubectl-<your-plugin-name> 的正確的語法來拷貝這個腳本到 $PATH 中的導出目錄之一，并需要為其賦予可執行權限（chmod +x）。

創建插件之后將其移動到路徑中，你可以立即運行它。例如，我的路徑下有一個 kubectl-krawl 和 kubectl-kmux：

$ kubectl plugin list
The following compatible plugins are available:
 
/usr/local/bin/kubectl-krawl
/usr/local/bin/kubectl-kmux
 
$ kubectl kmux

現在讓我們見識下帶有 tmux 的 Kubernetes 的有多強大。

駕馭強大的 tmux

Tmux 是一個非常強大的工具，許多管理員和運維團隊都依賴它來解決與易操作性相關的問題：通過將窗口分成多個窗格以便在多臺計算機上運行并行的調試來監視日志。它的主要的優點是可在命令行或自動化腳本中使用。

我創建一個 kubectl 插件，使用 tmux 使故障排查更加簡單。我將通過注釋來解析插件背后的邏輯（插件的完整代碼留待給你實現）：

# NAMESPACE 是要監控的名字空間
# POD 是 Pod 名稱
# Containers 是容器名稱
 
# 初始化一個計數器 n 以計算循環計數的數量，
# 之后 tmux 使用它來拆分窗格。
n=0;
 
# 在 Pod 和容器列表上開始循環
while IFS=' ' read -r POD CONTAINERS
do
    # tmux 為每個 Pod 創建一個新窗口
    tmux neww $COMMAND -n $POD 2>/dev/null
    # 對運行中的 Pod 中 的所有容器啟動循環
    for CONTAINER in ${CONTAINERS//,/ }
    do
        if [ x$POD = x -o x$CONTAINER = x ]; then
            # 如果任何值為 null，則退出。
                     warn "Looks like there is a problem getting pods data."
            break
        fi
           
        # 設置要執行的命令
        COMMAND=”kubectl logs -f $POD -c $CONTAINER -n $NAMESPACE”
        # 檢查 tmux 會話
        if tmux has-session -t <會話名> 2>/dev/null;
        then
            <設置會話退出>
        else
            <創建會話>
        fi
        # 在當前窗口為每個容器切分窗格
        tmux selectp -t $n \; \
        splitw $COMMAND \; \
        select-layout tiled \;
        # 終止容器循環
    done
    
    # 用 Pod 名稱重命名窗口以識別
    tmux renamew $POD 2>/dev/null
    
    # 增加計數器
    ((n+=1))
 
# 終止 Pod 循環
done<<(<從 kubernetes  集群獲取 Pod 和容器的列表>)
 
# 最后選擇窗口并附加會話
tmux selectw -t <會話名>:1 \; \
attach-session -t <會話名>\;

運行插件腳本后，將產生類似于下圖的輸出。每個 Pod 有一個自己的窗口，每個容器（如果有多個）被分割到其窗口中 Pod 窗格中，并在日志到達時輸出。Tmux 之美如下可見；通過正確的配置，你甚至會看到哪個窗口正處于激活運行狀態（可看到標簽是白色的）。

總結

別名是在 Kubernetes 環境下常見的也有用的簡易故障排查方法。當環境變得復雜，用高級腳本生成的kubectl 插件是一個更強大的方法。至于用哪個編程語言來編寫 kubectl 插件是沒有限制。唯一的要求是該名字在路徑中是可執行的，并且不能與已知的 kubectl 命令重復。

責任編輯：龐桂玉來源： Linux中國