資源管理深入

DAY6 已介紹過 requests 和 limits 的基本設定。這篇會從實際觀察出發，練習查看 Pod 與 Node 的資源使用量，並根據 Pod 狀態和事件判斷可能的資源問題。

觀察資源使用量

在 Minikube 中，可以啟用 Metrics Server：

minikube addons enable metrics-server

啟用後稍等一段時間，讓 Metrics Server 啟動並收集資料，再查看 Pod 和 Node 的資源使用量：

kubectl top pods
kubectl top nodes

如果想查看個別容器的使用量，可以加上 --containers：

kubectl top pod <Pod名稱> --containers

kubectl top 顯示的是近期觀察到的 CPU 與記憶體使用量，不是資源上限。剛建立 Pod 後，指標可能需要等一會兒才會出現。

建立觀察用 Deployment

以下建立兩個持續運作的容器，並設定不同的資源需求與上限。這個範例用來觀察資源設定與目前使用量，不會刻意讓容器超出限制。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: resource-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: resource-demo
  template:
    metadata:
      labels:
        app: resource-demo
    spec:
      containers:
        - name: app
          image: busybox:1.36
          command: ["sh", "-c", "while true; do date; sleep 10; done"]
          resources:
            requests:
              cpu: "100m"
              memory: "32Mi"
            limits:
              cpu: "300m"
              memory: "64Mi"

套用後，等待 Pod 啟動後，查看 Pod 狀態與使用量：

kubectl get pods
kubectl top pods

Deployment 有兩個副本，因此會建立兩個 Pod。每個 Pod 的資源設定都套用在其容器上；排程器會依據 Pod 中容器的資源需求，判斷 Node 是否有足夠的可分配資源。

資源不足時，Pod 為什麼會 Pending？

排程器會參考 Pod 的 requests，判斷 Node 是否還能容納新的 Pod。即使 Node 當下看起來沒有忙碌，只要可分配資源不足以滿足 Pod 的 requests，Pod 仍可能無法排程，並停留在 Pending。
可以查看 Pod 的詳細資訊和事件：

kubectl describe pod <Pod名稱>

在輸出最下方的 Events 區段中，若看到 Insufficient cpu 或 Insufficient memory，代表目前沒有符合資源需求的 Node。
這時要檢查 Pod 設定的 requests、Node 的可分配資源，以及目前已排程的 Pod。單看 kubectl top nodes 顯示的即時使用量，不能直接判斷 Node 是否還能排入新的 Pod，因為排程器會根據已分配的 requests 評估資源。

如何判斷要調整哪項資源？

可以把資源設定、即時使用量和 Pod 狀態一起觀察：

CPU 超過 limit 時，容器通常會受到節流，執行速度可能變慢；記憶體超過 limit 時，容器則可能遭到終止。這些狀況應搭配 Pod 狀態與事件確認，不能只根據單次 kubectl top 的結果下結論。

查看 Pod 狀態與事件

查看 Pod 的狀態與重啟次數：

kubectl get pods

如果容器曾經重新啟動，可以查看前一次容器執行時輸出的日誌：

kubectl logs <Pod名稱> --previous

也可以查看詳細資訊與事件：

kubectl describe pod <Pod名稱>

此為其中一個Pod的輸出結果。
從 Events 可以看到，Scheduled 表示 Pod 已排程到 minikube-m03；接著 kubelet 取得映像、建立並啟動容器。本次 Pod 順利啟動，事件中沒有出現資源不足的訊息。

若容器因記憶體不足而遭到終止，Pod 狀態或 describe 輸出中可能會看到 OOMKilled。如果 Pod 尚未成功排程，則可從 Events 查看排程器回報的原因。

小結

資源管理不只有設定 requests 和 limits，也需要觀察實際用量、Pod 狀態與事件。遇到問題時，可以先用 kubectl top 查看近期用量，再用 kubectl describe pod 確認是否有排程失敗或容器終止的訊息，據此判斷要調整 requests、limits，或進一步檢查應用程式。
註:kubectl top 需要叢集中有可用的 Metrics Server。顯示的用量是近期指標，可能會延遲，也不等於容器的資源上限。