在操作 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 的實作方式。
在 Kubernetes 裡，如果想查看 Node 或 Pod 的 CPU、Memory 使用量，常見的做法是透過 kubectl top 指令，或是在 Kubernetes Dashboard 裡查看資源監控圖表。不過這些功能背後都需要 metrics-server 提供即時資源指標。
這篇文章會示範如何在 Minikube 環境中啟用 metrics-server，並確認它是否正常運作。
metrics-server 是 Kubernetes 官方常用的叢集資源指標收集元件。它會從各個 Node 的 Kubelet 取得 CPU 與 Memory 使用量，並透過 Kubernetes Metrics API 提供給其他工具使用。
啟用 metrics-server 之後，常見的用途包含：
kubectl top nodes 查看 Node 資源使用量kubectl top pods 查看 Pod 資源使用量