為什麼不是每個人在使用 Kubernetes 時都只使用最便宜的伺服器？
最近，我學習了很多關於 Kubernetes 的知識，了解到 Kubernetes 可以在需要時水平自動擴展您的容器並添加伺服器到您的節點池（當然，雲提供商應該支持此功能才能工作）。例如，當伺服器上的容器超過該伺服器上資源的 70% 時，會添加一個新伺服器，並且您將自動根據每台伺服器執行的小時數計費。GCP 和 AWS 等大型雲提供商支持這一點。
所以，我在想，為什麼不直接選擇最便宜的可用伺服器並讓 Kubernetes 與這些伺服器一起擴展呢？據我了解，沒有必要使用 $ 100 servers in the node pool when you can use $ 5台伺服器。當然， $ 100 can handle more load, but if you’re using $ 5 個伺服器，Kubernetes 會自動為你添加新的伺服器。
為什麼甚至可以選擇使用更昂貴的伺服器和託管 Kubernetes？為什麼不是每個人都只選擇最便宜的伺服器？
等式有很多。
你真的能走多低？一個關鍵因素是你的豆莢有多小。如果您的一個 pod 中的應用程序需要 4G 的 RAM，那麼將 1 個 8G 伺服器拆分為 4x2G 伺服器意味著該應用程序現在沒有節點可以執行。
加上成本。每個節點都有一些執行 Kubernetes 的成本。還有在每個節點上執行的 DaemonSet，增加了更多成本。如果將節點數量增加一倍，則 DaemonSet 的副本也會增加一倍，這會增加執行集群的成本。即使沒有這些，也會有作業系統、Linux 發行版、kubelet 和其他 Kubernetes 組件的成本。節點越小，節點上的工作負載百分比就越大，只是執行節點而不是執行應用程序的成本。
考慮管理成本。是的，基礎設施即程式碼、自動擴展組等都有幫助。但是你擁有的節點越多，當出現問題時，你就越需要管理、監控和調試。
網路因素。節點越多，節點之間的網路流量就越多，這比 Linux 橋上節點內的虛擬網路要慢。雲提供商還傾向於顯著限制較小節點上的網路，從而導致超時和延遲，從而可能使應用程序無法使用。
以我的經驗，公司很快就可以使用大約 10 個節點來實現 HA。您希望剩餘節點中有足夠的容量來處理從宕機節點故障轉移的容器。對於 10 個節點，這意味著要留出 10% 以上的額外容量來處理集群中的一個故障節點。如果您只有 3 個節點，則每個節點需要少於 2/3 用於處理單個節點宕機。在這些公司達到 20 個節點之前，他們開始擴展到更大的節點。這使得集群中的節點更新可以通過一個小團隊和最小的自動化進行管理。在某個點上，較大節點的成本超過了執行更多節點的更多管理成本的成本，並且它們返回到橫向擴展以獲得更多容量。