Kubernetes 節點選擇
以往在使用雲 K8s 都是選用自動維護節點 (GCP GKE autopilot / Byteplus VKE VCI) 或者在公司地端單一台性能強大的機器上使用，只管著去部署 pod其餘都會交由平台維護，不用去想更多細節。
但這次使用 Aliyun ACK pro 雖然也會自動維護節點，但主要的差異在於這些pod request / limit 該如何調整在相關特定node上面的細節是這次的新課題。
總結了一些重點。
Node 機型選擇
- 不要選太小的機型
每台節點預設都會跑 CSI 等基礎建設 Pod，會固定吃掉一部分資源。若選用過小的機型（例如 2c/4G），扣掉系統預留與基礎元件後，真正可分配給業務的餘額本來就少；此時只要業務 Pod 的 request 稍大，單台節點很快就被占滿，造成頻繁擴容、資源碎片化。
- C 系列 vs R 系列：本質是 CPU/RAM 比例
雲商機型的 vCPU 與記憶體通常是固定比例綁定的：
| 系列 | 定位 | vCPU:RAM | 範例 |
|---|---|---|---|
| C系列 | 運算型 | 1:2 | 4c8G |
| R系列 | 內存型 | 1:4 | 4c16G |
選型關鍵，是讓機型的 CPU:RAM 比例盡量貼近 workload 實際的 CPU:RAM 使用比例，這樣兩種資源才能一起吃滿、不偏廢。
實際踩坑：Go 微服務選錯機型
本專案是 Go 微服務架構，Pod 數量多，但單顆 Pod 偏 CPU 密集、吃記憶體不高。
- 原本：用 R 系列 4c16G 部署約 80 個 Pod，自動擴容到 12 台 VM。
- 問題：細看才發現，擴容幾乎都是因為 CPU 額度先被占滿而被迫加機器，但每台 VM 的 RAM 都還剩一大半——記憶體形同浪費。等於是「為了補 CPU 而被迫多買了一堆用不到的 RAM」。
- 調整：全數改用 **C 系列（1:2）**後，機型比例貼近 workload 實際用量，CPU 跟 RAM 能更平均地被吃滿，VM 總數因此大幅下降。
結論
機型選型不是「越大越好」或「越省越好」，而是要讓機型的 CPU:RAM 比例對齊 workload 的實際資源消耗比例：CPU 密集型選 C 系列、記憶體密集型選 R 系列，避免某一種資源先被榨乾、另一種卻閒置浪費。