在操作 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。

什麼是 MetalLB？

MetalLB 是一個用於裸機 Kubernetes 叢集的負載平衡器實作。它提供了在本地環境中使用 LoadBalancer 類型 Service 的能力，填補了雲端和本地 Kubernetes 環境之間的功能差距。

MetalLB 的主要功能：

• IP 位址分配：為 LoadBalancer Service 自動分配外部 IP 位址
• 流量路由：將外部流量路由到正確的 Service 與後端 Pod
• 高可用性：支援多節點部署與故障轉移
• 協定支援：支援 Layer 2 (ARP/NDP) 和 BGP 模式

為什麼需要 MetalLB？

在雲端 Kubernetes 環境中，當我們建立 type: LoadBalancer 的 Service，雲端供應商通常會自動配置一組外部 IP 或負載平衡器，讓叢集外部可以連進服務。

但在 Minikube、裸機伺服器或本機實驗環境中，Kubernetes 本身不會幫你分配外部 LoadBalancer IP。這時候如果直接建立 LoadBalancer Service，很常看到 EXTERNAL-IP 一直停在 <pending>。

MetalLB 解決的就是這個問題。它會從指定的 IP 位址池分配外部 IP 給 LoadBalancer Service，讓本機或內網 Kubernetes 也能用接近雲端的方式對外暴露服務。

本篇會使用 Minikube 作為示範環境，先啟用 MetalLB，接著配置 192.168.49.100-192.168.49.150 作為 LoadBalancer IP 位址池，最後沿用前面文章建立好的 dockertest Spring Boot 應用程式，透過 MetalLB 取得外部 IP 並測試連線。

什麼是 LoadBalancer Service？

Kubernetes LoadBalancer Service 是一種 Service 類型，用於將叢集內的應用程式暴露給外部網路。它會提供一個可從叢集外部存取的入口 IP，並透過 Service selector 將流量導向後端 Pod。

在雲端 Kubernetes 環境中，type: LoadBalancer 通常會自動建立雲端供應商的負載平衡器；在本機或裸機環境中，Kubernetes 本身不會自動分配外部 IP，因此常見做法是搭配 MetalLB，讓本地叢集也能取得 LoadBalancer IP。

LoadBalancer Service 的主要功能：

• 外部存取：讓叢集外部可以透過固定 IP 與連接埠存取應用程式
• 服務入口：透過 Service 提供穩定入口，避免直接依賴會變動的 Pod IP
• 負載分配：將進入 Service 的流量分配到符合 selector 的後端 Pod
• 流量策略：支援來源 IP 保留、會話親和性與內外部流量策略等設定

為什麼使用 LoadBalancer Service？

相較於 ClusterIP 或 NodePort，LoadBalancer Service 更適合需要直接對外提供 IP 入口的服務：

1. 外部連線更直覺：使用者可以直接透過 LoadBalancer IP 與 Service port 存取服務
2. 部署設定更清楚：Service 負責穩定入口，Deployment 負責維護後端 Pod
3. 適合非 HTTP 場景：除了 HTTP 服務，也能暴露 TCP 或 UDP 類型的服務