本文整理了 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 掛載該節點路徑，就能讀寫開發機上的檔案。

在 Kubernetes 中，ClusterIP Service 預設只能在叢集內部被存取。這樣的設計很適合讓後端服務、資料庫或內部 API 保持在叢集網路內，但在開發與除錯時，我們常常需要從本機瀏覽器或本機工具暫時連進去確認服務是否正常。

這時候可以使用 kubectl proxy 或 kubectl port-forward 建立一條臨時通道，把本機請求導向叢集內的服務。這兩個指令都不需要改 Service Type，也不需要額外建立 NodePort、LoadBalancer 或 Ingress，很適合用在本機測試、問題排查與臨時驗證。

這篇文章會使用一個 Tomcat 服務作為範例，示範如何透過這兩種方式存取 Kubernetes 內部的 ClusterIP Service。