這篇文章記錄一次完整的 Webchat Kubernetes 部署體驗：從本機 Minikube 建立基礎服務、部署 Spring Boot API 與 WebSocket/STOMP 服務，到最後開啟前端頁面，實際用兩個使用者測試公開聊天室的即時訊息。
Webchat 是一個即時公開聊天室範例專案，包含純 HTML/CSS/JavaScript 前端、REST API 服務、WebSocket/STOMP 服務，以及 MySQL、Redis、RabbitMQ 這三個後端基礎設施。使用者登入後會取得 JWT，前端透過 REST API 送出訊息，再由 RabbitMQ 將事件分送到 WebSocket 節點，最後推播給已連線的聊天室使用者。
本文會以 webchatk8s/ 內的 Kubernetes manifest 為主，將整套服務部署到 Minikube 上，並用瀏覽器確認聊天室功能是否正常。
平常使用 Kubernetes 時，最常接觸的工具通常是 kubectl。它很完整，也很適合寫成腳本，但如果只是想快速查看 Pod 狀態、切換 namespace、看 logs、describe 資源或進入 container，每次都輸入完整指令會稍微打斷操作節奏。
k9s 是一套以終端機為基礎的 Kubernetes TUI 工具，可以用互動式畫面查看與管理 Kubernetes 叢集。它會持續監看叢集中的資源變化，並提供快捷鍵來執行常見操作，例如查看 Pod、切換 namespace、檢視 logs、port-forward、刪除資源與進入 shell。這篇文章會示範如何在 Ubuntu 環境安裝 k9s，並搭配 Minikube 叢集簡單確認操作畫面。
官方網站：K9s
官方專案連結：derailed/k9s
在操作 Kubernetes 時，kubectl 會依照目前 kubeconfig 中設定的 context 決定要連線到哪個叢集，以及預設操作哪個 namespace。當環境只有一個 Minikube 或單一測試叢集時，直接使用 kubectl config use-context 還算容易管理；但只要 context 或 namespace 變多，每次切換都輸入完整指令就會變得有點繁瑣。
kubectx 和 kubens 是用來簡化這件事的工具。kubectx 可以快速查看與切換 Kubernetes context，kubens 則可以快速查看與切換目前 context 的 namespace。這篇文章會示範如何在 Ubuntu 環境安裝 kubectx，並搭配實際範例操作 kubectx 與 kubens。
官方專案連結：ahmetb/kubectx
在 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 的實作方式。
