來自Shopify的Andy Kwiatkowski在柏林舉行的Velocity會議上討論了他們爲何要在Kubernetes中創建自定義的自動擴展器。 現有的自動擴展方案無法滿足Shopify的需求。這主要是因爲它們會接收到大量突如其來的流量請求。同時，他們還需要在收縮或配置複雜的擴展條件時，能夠有一個經濟有效的解決方案。
Kwiatkowski說到，Shopify的Web站點在促銷或“限時搶購”的時候會突然接收到大量的請求。限時搶購通常只會維持很短的時間，比如十五或二十分鐘。所以，它們需要快速擴展，但是反應式擴展並不適合這些情況，這主要是因爲擴展過程有很多的活動，比如生成新節點、下載Docker鏡像以及啓動守護程序集之類的應用。因此，平均來看，擴展可能會需要兩分鐘到二十分鐘。當自動擴展和添加處理能力就緒的時候，限時搶購可能已經結束了。
Shopify使用Go語言創建了一個自定義的自動擴展器以滿足其突然暴增的流量的需求，目前它還沒有開源。同時，他們還需要更好的控制功能，以實現安全的部署或配置更爲複雜的擴展條件（比如使用過去的數據）。自動擴展器每30秒運行一次，爲即將到來的限時搶購添加所需的副本。
擴展或伸縮還會影響每月的雲賬單。因此，自動擴展器需要基於豐富的信息作出決策。爲了定義集羣需要多少副本，Shopify使用了Kubernetes中來自HPA的風險與成分分析公式。Shopify定義了他們希望的服務器繁忙程度。然後，基於服務器的繁忙程度和目前存在的副本數量，該公式能夠給出集羣應該具有的副本數量。其目的是始終保持集羣的目標使用率。
收縮集羣會消耗時間，因此會增加成本。所以，爲了有一個高效的成本擴展方案，Shopify必須通過分析過去的流量數據來提升其自動擴展器。在運行一些實驗之後，Shopify注意到在使用平均CPU利用率來設置擴展規則時（當然其他解決方案都是這樣做的），他們無法準確地預測峯值。如果使用CPU使用率中位數的話，會有更好的結果，只不過會有暫時的額外容量。但是，當有更長（30分鐘）的峯值時，自動擴展器不會增加更多的副本。爲了解決該問題，他們使用CPU利用率的指數加權平均值（exponentially weighted average，EWA），在這種方式下，新的值會比舊的值更重要。因此，自動擴展器可以快速添加更多副本。
Shopify的自動擴展器會同時計算中位數和EWA的CPU利用率。如果沒有明顯差異的話，自動擴展器會使用中位數CPU利用率。否則的話，它會使用EWA的CPU利用率。通過這種方式，Shopify能夠在真正需要的時候才添加副本。
最後，Kwiatkowski說，有時他們收集的數據會有錯誤，如空值、零值、陳舊的數據或稀疏的數據。因此，爲了避免在擴展或伸縮時出現問題，如果有任何數據錯誤，它們總是按最大容量伸縮以確保安全。此外，它們配置了一個最小的副本值，以防止在收縮時出現問題。
原文鏈接：
How Shopify Implements Custom Autoscaling Rules in Kubernetes