關鍵字: GKE, cluster autoscaler, HPA, Alias IP VPC (VPC Native)
影響: 部署卡住，節點與 Pod 都沒有辦法自動擴展
自作團隊使用 GKE 作為其 Kubernetes 平台，某天收到回報發現有些 Pod 部署上卡住沒有起來，過往只有幾分鐘的部署時間當下花了將近一個小時還沒有辦法順利起來。基於過往的部署經驗，通常都會是 ConfigMap, Secret 或是錯誤的 nodeSelector 才會導致這些情況，但是這次的情況不太一樣，
因為有一半左右的 Pod 可以正確起來，有一半的則是都停留於 pending 狀態，這些狀況不太像是上述原因造成的。
作者透過 describe 去檢查後發現當下叢集內 256 個節點中沒有半個節點可以使用，而這些節點又是依賴 GKE Cluster Autoscaler 來管理，因此作者轉往這邊去尋找相關蛛絲馬跡，最後發現到 IP 用完的錯誤訊息。
作者表示無法想像為什麼 65536 個 IP 會被使用，簡單估算一下團隊內使用的數量大概就是千位等級而已，距離六萬還是一段遙遠的距離。
根據 GKE 的文件，每個節點預設都可以部署 110 的Pod，因此假設 63356 個 IP 可以用， 65536/110 ~= 595 ，這意味 Cluster autoscaler 至少要可以分配 595 個節點，而不是當前的 256 個節點而已。最後查到另外一份 GCP 文件表示， kubernetes (GKE) 會針對可用 Pod 的數量去分配兩倍空間的 subnet，這部分主要作為一個緩衝區，來面對Pod反覆的移除與加入。
透過這樣的計算， GCP 要分配至少兩倍的 subnet，所以本來 110 個 Pod，就要分配至少 220 個IP，而 220 對應到 subnet 上最近接的量就是/24, 也就是256個
因此 65536/256 =256 就得到為什麼最後只能有 256 個節點。
文末也列出了一些可能性解法，有興趣的可以參考
https://deploy.live/blog/when-gke-ran-out-of-ip-addresses/
subnet計算 在 我的網路筆記外傳-子網路切割快速計算法 的推薦與評價
在IPv4 的協定下，IP 位址是由4 個8 位元組成的數字來表達，如200.1.1.130，一個IP位址分為網路位址( Network Address ) +主機位址( Host Address ) ... ... <看更多>