Kubernetes 日誌管理（Logging）

上一篇介紹了 Kubernetes 服務故障的排查流程，透過 kubectl get、kubectl describe 等指令確認 Pod、Service 等資源的狀態。

但有時候 Pod 顯示 Running，並不代表應用程式一定正常運作。例如 API 可能因為資料庫連線失敗而無法回應請求，這時只查看 Pod 狀態可能無法直接找出問題。

因此，除了查看 Kubernetes 資源狀態，也需要觀察容器內應用程式所產生的日誌（Log）。

Kubernetes 的日誌

日誌是應用程式或系統在執行過程中產生的紀錄，可以用來了解程式的執行情況。

常見的日誌內容包括：

• INFO：記錄一般執行資訊。
• WARNING：記錄可能需要注意的情況。
• ERROR：記錄執行時發生的錯誤。

這些是常見的日誌等級，但實際格式與分類仍取決於應用程式。

在 Kubernetes 中，容器通常會將日誌輸出至標準輸出（stdout）與標準錯誤（stderr）。

容器執行環境會接收這些輸出，讓 Kubernetes 可以透過 kubectl logs 查看。

不過 Kubernetes 並不會自動提供完整的長期日誌保存與搜尋系統。如果需要集中管理多個 Node 的日誌，通常還需要額外的日誌收集工具。

建立測試環境

這次使用 BusyBox 建立一個會定期產生日誌的 Deployment。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: logging-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: logging-demo
  template:
    metadata:
      labels:
        app: logging-demo
    spec:
      containers:
        - name: busybox
          image: busybox:1.36
          command:
            - /bin/sh
            - -c
            - |
              while true; do
                echo "$(date) INFO: Application is running"
                sleep 5
              done

這個 Deployment 會建立兩個 Pod，每個 Pod 都會每隔五秒輸出一次日誌。

建立資源：

kubectl apply -f logging-demo.yaml

查看 Pod：

kubectl get pods -l app=logging-demo

確認兩個 Pod 都正常執行後，就可以開始觀察日誌。

查看 Pod 日誌

使用以下指令：

kubectl logs <pod-name>

可以查看指定 Pod 中容器的日誌。

會看到類似以下內容：

這些訊息來自前面 YAML 中的 echo 指令。

由於範例會持續產生日誌，因此也可以使用 -f 參數持續觀察：

kubectl logs -f <pod-name>

這樣就不需要每次都重新執行指令。

按下 Ctrl + C 即可停止查看。

常用的日誌參數

除了基本的 kubectl logs，還可以搭配其他參數使用。

查看最近幾筆日誌

kubectl logs <pod-name> --tail=10

只顯示最後十行日誌。

查看指定時間內的日誌

kubectl logs <pod-name> --since=5m

查看最近五分鐘的日誌。

顯示時間戳記

kubectl logs <pod-name> --timestamps=true

讓 Kubernetes 在每一行日誌前面附加時間戳記，方便確認訊息產生的時間。

查看 Deployment 的日誌

除了指定 Pod，也可以直接指定 Deployment：

kubectl logs deployment/logging-demo --all-pods=true --all-containers=true --prefix=true

這樣可以查看 Deployment 所管理的所有 Pod 日誌，並標示來源 Pod 與容器。

如果 Deployment 有多個副本，這種方式會比逐一輸入 Pod 名稱方便。

容器重新啟動後的日誌

如果容器因為錯誤而重新啟動，可能需要查看重新啟動前的日誌。

可以使用：

kubectl logs <pod-name> --previous

--previous 可以查看同一個 Pod 中，指定容器前一次執行時的日誌。

這對於排查 CrashLoopBackOff 等問題特別有幫助。

不過，這項功能只能查看仍然保留的前一次容器日誌。如果 Pod 已經被刪除，或舊日誌已經被清理，就不一定能透過這個指令取得。

Kubernetes 日誌的限制

前面的實作都是透過 kubectl logs 直接查看容器日誌，但這種方式仍然有一些限制。

例如：

• Pod 被刪除後，原本的日誌不一定還能取得。
• 日誌通常儲存在 Node 上，可能受到輪替與儲存空間限制。
• 當叢集有大量 Pod 時，逐一查看日誌會很麻煩。
• kubectl logs 本身不提供完整的跨 Pod 長期搜尋與分析功能。

因此，在正式環境中，通常會使用集中式日誌管理架構。

例如透過 Fluent Bit 收集容器日誌，再將日誌傳送至 Loki 等儲存系統，最後使用 Grafana 查詢與分析。

整體流程可以簡單理解為：

Pod
 |
 | stdout / stderr
 v
Container Runtime
 |
 v
Node 上的容器日誌
 |
 v
Fluent Bit
 |
 v
Loki
 |
 v
Grafana

這裡先了解日誌收集的基本架構即可，後續有機會再介紹相關的可觀測性工具。

總結

這篇介紹了 Kubernetes 的日誌管理方式，並透過 BusyBox 建立持續產生日誌的 Deployment，練習使用 kubectl logs 查看容器輸出。

雖然前面故障排查的文章已經使用過 kubectl logs，但這篇進一步介紹了持續追蹤、時間篩選、多 Pod 日誌，以及容器重新啟動前的日誌查看方式。

當應用程式發生問題時，可以先透過 kubectl get 和 kubectl describe 確認 Kubernetes 資源的狀態，再使用 kubectl logs 觀察應用程式內部發生的情況。

對於需要長期保存與集中搜尋日誌的環境，則可以進一步使用 Fluent Bit、Loki 和 Grafana 等工具。