Amazon EKS中使用的基礎架構

Question

我正在研究一個基於Amazon kubernetes服務EKS構建的應用程序的演示。 但是，由於我無法直接訪問AWS，因此我正在努力了解其底層使用了什么基礎架構。

我的理解。

1. 您定義集群，而不管是否使用它都需要一定的成本，因此我懷疑總有一個主節點處於運行狀態。
2. 在作業運行期間，您需要支付VM成本，因此很顯然，它可以在VM上運行

現在我的問題是：

當您上下旋轉時會發生什么？

首先，是將VM精確地旋轉到所需的速度，還是總有一部分可以讓您快速擴展？

其次，如果VM降速運行，是否意味着實例已終止或剛剛停止。

---

我注意到擴展在幾秒鍾內發生，所以這使我懷疑虛擬機實際上是在每次啟動時制作的。

Answer 1

您的理解大致正確。 有一個由Amazon通過EKS（實際上是kubernetes集群的主節點）管理的“控制平面”。 作為AWS賬戶持有人，這對於您而言是不可見的，您無法親自訪問這些基礎計算機。 亞馬遜對此收取統一費用，您無法將其縮減/縮小以降低成本。

您為創建的每個Amazon EKS集群每小時支付$ 0.20。

關於作業運行的第二點不是很清楚。 您不必在Kubernetes中運行作業-您可以在pod中運行容器（您也可以運行'jobs'，這些作業也是基於進程完成時間有限的Pod）。

默認情況下，您需要為EKS集群創建“工人組”。 如何創建這些取決於您。

通常，您為每個工作組創建一個自動伸縮組，然后可以定義自己如何自動伸縮集群中的工作節點。正如您所猜測的，它們是經典的EC2 VM，可以通過SSH或SSM訪問它們例。 （由您管理）。

因此，要擴展運行容器工作負載的工作組，您可以手動上下擴展它們，依靠自動擴展組指標來擴展/擴展它們，也可以使用定制解決方案（例如cluster-autoscaler）來更智能地擴展它們。並根據集群中的容器在做什么。

因此，通常當自動擴展組/工作組擴展時，它將終止EC2實例。 當出現新實例時，您的工作組的啟動配置應具有其需要了解的所有信息，以允許新實例自動加入EKS群集並開始調度Pod。

因此，是的，當工作組擴展時，虛擬機的確已創建/啟動/配置。 如果它們是基於Linux的EKS輔助節點，則這些節點通常會很快啟動。 Windows的通常要慢一些。

為了回答您的其他問題-僅當您仔細配置了擴展機制並滿足自己的要求時，VM才可以滿足您的需求。 群集自動縮放器對此很有幫助 。

希望可以幫助您解決問題。