在 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 類型的服務

什麼是 Ingress？

Kubernetes Ingress 是一個 API 物件，用於管理對叢集內服務的外部存取，通常是 HTTP/HTTPS 流量。Ingress 提供了負載平衡、SSL 終止和基於名稱的虛擬主機功能。

Ingress 的主要功能：

• 路由管理：根據 URL 路徑或主機名稱將流量路由到不同的服務
• 負載平衡：在多個後端服務之間分配流量
• SSL/TLS 終止：處理 HTTPS 加密和解密
• 域名綁定：支援基於域名的虛擬主機

為什麼使用 Ingress？

相較於直接使用 NodePort 或 LoadBalancer 類型的 Service，Ingress 提供了更靈活的流量管理方式：

1. 成本效益：一個 Ingress Controller 可以處理多個服務的外部存取
2. 統一管理：集中管理所有外部流量的路由規則
3. 高級功能：支援路徑重寫、認證、限流等進階功能

什麼是 Kubernetes Service？

Kubernetes Service 是一個穩定的網路抽象層，用來將流量導向一組符合條件的 Pod。由於 Pod 會隨著部署、擴展、重啟或節點異動而重新建立，Pod IP 並不適合作為固定存取入口；Service 則提供固定的服務名稱、虛擬 IP 與連線方式，讓應用程式可以穩定地彼此溝通。

Service 通常會透過 selector 找到帶有指定 label 的 Pod，並把流量轉送到 Pod 的 targetPort。對使用者或其他服務來說，只需要存取 Service，就不需要關心後方 Pod 的實際位置。

Service 的主要功能：

• 穩定入口：即使 Pod 被重新建立，Service 名稱與 IP 仍能維持穩定
• 服務發現：透過 Kubernetes DNS 使用 Service 名稱存取服務
• 負載分散：將請求分配到多個符合 selector 的 Pod
• 對外暴露：依照不同 Service Type，提供叢集內或叢集外的存取方式

為什麼需要 Service？

在 Kubernetes 中，Deployment 負責管理 Pod 的生命週期，但 Deployment 本身不提供固定的網路入口。當應用程式需要被其他 Pod、節點外部使用者，或雲端負載平衡器存取時，就需要透過 Service 建立對應的流量入口。

什麼是 Volume？

Kubernetes Volume 是一個 API 物件，用於為 Pod 中的容器提供持久化或共享的儲存空間。Volume 解決了容器檔案系統的臨時性問題，讓資料能夠在容器重啟後保留，或在多個容器之間進行共享。

Volume 的主要功能：

• 資料持久化：確保重要資料在容器重啟或 Pod 重新調度後不會遺失
• 容器間共享：讓同一 Pod 內的多個容器能夠共享資料
• 外部儲存整合：連接到各種外部儲存系統，如雲端儲存、網路檔案系統等
• 臨時儲存管理：提供高效能的臨時工作空間

為什麼使用 Volume？

相較於依賴容器內建的檔案系統，Volume 提供了更可靠的資料管理方式：

1. 資料安全性：避免因容器故障導致的資料遺失
2. 靈活性：支援多種儲存後端，適應不同的應用需求
3. 效能最佳化：可選擇適合的儲存介質來提升應用效能
4. 統一管理：集中管理所有持久化資料的儲存策略