Pod 擴容速度過慢，不僅可能導致系統無法承受突發流量，也會造成 Node 已完成 Provisioning 但 Pod 遲遲無法啟動的閒置資源浪費，甚至拉長 Incident Recovery 時間。

在大流量壓力測試中，我們發現 Kubernetes Cluster 雖然具備足夠的運算資源，但許多 Pods 從建立到進入 Running 狀態竟然需要 26 分鐘。

本議程將分享 SHOPLINE 優化 Pod 水平擴容速度的完整過程，包含如何定位出 Root Cause、理解 Cilium IPAM 的運作機制，以及 Cilium 各元件的交互是如何影響 Pod 擴容速度。我們最終將 Pod 擴容時間縮短 80~88%，並將相關優化貢獻至 Cilium Upstream。

此外，在優化過程中曾因錯誤判斷調整 Cilium 設定以及錯誤的操作，導致 Production 發生服務中斷。本次分享也將深入解析 Incident 背後的 Cilium Endpoint Restore、Endpoint State 與 IP Allocation 等機制，以及我們從中獲得的經驗與教訓。

由於內容將深入探討 Cilium 背後運作機制、AWS ENI IPAM 與 Prefix Delegation 的實作細節，建議聽眾具備 Kubernetes、Cilium 與 AWS 基礎知識。

聽眾收穫：

1. 提升排查能力：學會定位 Pod 長時間無法進入 Running 狀態的關鍵瓶頸
2. Cilium 底層機制理解：了解 Cilium IP Allocation、AWS ENI IPAM 與 Prefix Delegation 的實作細節及其對擴容的影響，並深入理解 Cilium Endpoint Restore、Endpoint State 的運作機制
3. Pod 擴容加速優化經驗： SHOPLINE 將 Pod 擴容速度縮短 88% 的具體優化手法與決策過程
4. 事故預防與應對：學到 Cilium 在什麼樣的條件與施工方式會造成停機，及如何避免類似的 Incident