在 Kubernetes 中排查問題時，最常用的工具通常是 kubectl logs、kubectl describe、kubectl exec 與 kubectl port-forward。這些指令已經能處理大部分日常除錯情境，但如果容器映像檔本身很精簡，裡面沒有 curl、ps、netstat、tcpdump 等工具，或是需要進一步查看 Node 層級的狀態，就會遇到一些限制。

kubectl debug 是 Kubernetes 提供的除錯指令，可以在不重新打包應用程式映像檔的情況下，建立臨時的除錯環境。它常見的用途包含：複製既有 Pod 來建立 debug Pod、在 Pod 中加入 ephemeral container，以及在指定 Node 上建立 debug pod。這篇文章會用 Tomcat 服務作為範例，示範如何使用 kubectl debug 進行常見的場景排查。

本文整理了 Kubernetes 日常管理中最常用的指令，幫助您快速掌握 kubectl 的基本操作。

Kubernetes 的 RBAC（Role-Based Access Control）可以用來控管「誰」可以在「哪個範圍」對「哪些資源」執行「哪些操作」。這篇文章會示範如何建立一個名為 dockertest-user 的使用者，並透過 Role 與 RoleBinding 限制它只能在 dockertest namespace 中讀取 Pod。

這次的目標很單純：dockertest-user 可以在 dockertest namespace 內執行 get、list、watch Pod，但不能刪除 Pod，也不能跨到其他 namespace 查詢資源。

在操作 Kubernetes 時，kubectl 會透過 kubeconfig 取得叢集連線資訊、使用者憑證與目前要操作的 context。當只有一個本機測試叢集時，直接使用預設的 ~/.kube/config 通常就足夠；但如果同一個叢集需要切換不同 namespace，或是同一台機器要管理多個環境，就很容易在指令中反覆加上 -n <namespace>，甚至因為操作錯 namespace 而造成誤用。

這篇文章會示範如何替本機 Minikube 額外建立一個 context，讓 kubectl 預設操作 dockertest namespace。範例會保留既有 Minikube 的 cluster 與 user 設定，只新增一份輕量的 kubeconfig，用來管理不同操作情境。

在 Kubernetes 裡部署服務時，除了要思考 Pod 數量是否足夠，也要思考每個 Pod 本身配置的 CPU 與記憶體是否合理。若 resources.requests 設得太低，服務可能容易被資源限制影響；若設定得太高，又會讓叢集排程時預留過多資源，造成浪費。

這篇文章會整理 Kubernetes VPA（Vertical Pod Autoscaler）的基本概念，並透過一份測試用 Deployment 與 VPA 配置，觀察 VPA 如何根據 Pod 的使用情況提供資源建議。文末也附上 Demo 影片，方便對照完整操作流程。

在 Kubernetes 部署服務時，Pod 的數量通常不會一直維持固定不變。當流量或 CPU 使用率提高時，我們希望服務可以自動增加 Pod 來分攤負載；當負載下降後，也希望 Pod 數量可以自動縮回來，避免浪費叢集資源。

這篇文章會先整理 Kubernetes HPA（Horizontal Pod Autoscaler）的常用設定參數，再透過一份 Spring Boot 測試服務配置，展示如何依照 CPU 使用率自動調整 Deployment 的副本數。

在 Kubernetes 裡部署服務時，資源配置通常不是一次設定好就永遠不需要調整。流量、任務量、背景批次作業與使用者行為都可能隨時間變化。如果 Pod 數量太少，服務可能在高峰時處理不過來；如果資源預留太多，又會讓叢集長時間保留用不到的 CPU 與記憶體。

Autoscaling 的目的，就是讓 Kubernetes 可以根據實際負載與資源使用情況，自動調整工作負載或叢集資源。它不只是「流量變大就加 Pod」這麼單一，而是依照不同層級的需求，調整 Pod 數量、單一 Pod 的資源請求，甚至是 Node 數量。

這篇文章會先整理 Kubernetes Autoscaling 的整體概念，說明常見的擴縮容方向，以及 HPA 與 VPA 分別解決什麼問題。後續文章會再分別深入介紹 HPA 與 VPA 的實作方式。

Kubernetes Limit / Request 使用指南

在 Kubernetes 部署應用程式時，resources.requests 與 resources.limits 是很重要的設定。它們會影響 Pod 是否能被排程、容器最多能使用多少 CPU 與記憶體，以及命名空間內的資源是否會被合理控管。

這篇文章會透過三份測試配置檔，依序觀察以下幾件事：

• 只在 Deployment 內設定 requests 與 limits
• 使用 LimitRange 統一限制命名空間內的單一容器資源範圍
• 使用 ResourceQuota 控制整個命名空間的資源總配額

在 Kubernetes 裡，如果想查看 Node 或 Pod 的 CPU、Memory 使用量，常見的做法是透過 kubectl top 指令，或是在 Kubernetes Dashboard 裡查看資源監控圖表。不過這些功能背後都需要 metrics-server 提供即時資源指標。

這篇文章會示範如何在 Minikube 環境中啟用 metrics-server，並確認它是否正常運作。

metrics-server 是什麼

metrics-server 是 Kubernetes 官方常用的叢集資源指標收集元件。它會從各個 Node 的 Kubelet 取得 CPU 與 Memory 使用量，並透過 Kubernetes Metrics API 提供給其他工具使用。

啟用 metrics-server 之後，常見的用途包含：

• 使用 kubectl top nodes 查看 Node 資源使用量
• 使用 kubectl top pods 查看 Pod 資源使用量
• 在 Kubernetes Dashboard 顯示 CPU 與 Memory 監控圖表

什麼是 Minikube Mount？

Minikube Mount 是 Minikube 提供的本機目錄掛載功能，可以將開發機上的資料夾掛載到 Minikube 節點內，讓 Kubernetes Pod 透過 hostPath 讀取或寫入這些檔案。對於本機開發、測試資料同步、日誌觀察或快速驗證 Volume 行為來說，這是一個很方便的工具。

需要注意的是，minikube mount 不是 Kubernetes 原生的持久化儲存方案，而是 Minikube 在本機開發環境提供的輔助功能。它適合用於單機測試與開發流程，不建議直接套用到正式環境。

Minikube Mount 的主要功能：

• 本機資料同步：將開發機上的目錄提供給 Minikube 節點使用
• 快速測試 Volume：搭配 hostPath 驗證 Pod 掛載目錄後的讀寫行為
• 開發檔案共享：讓容器直接讀取本機設定檔、測試資料或靜態檔案
• 日誌觀察：將容器產生的檔案寫回本機目錄，方便直接檢查

為什麼使用 Minikube Mount？

在 Minikube 環境中，Kubernetes 節點其實是在 VM、容器或其他 driver 內執行，因此 Pod 看到的節點檔案系統不等同於開發機的檔案系統。如果只在 Pod 裡設定 hostPath，它讀到的是 Minikube 節點內的路徑，而不是 Windows、macOS 或 Linux 主機上的資料夾。

minikube mount 的作用，就是在開發機與 Minikube 節點之間建立一個掛載通道。當本機資料夾被掛載到節點後，Pod 再透過 hostPath 掛載該節點路徑，就能讀寫開發機上的檔案。