簡體   English   中英

有關在Google容器集群內使用的節點的困惑

[英]Confusion about nodes used inside a Google Container Cluster

創建Google Container Engine集群后,Container Engine將創建一個Compute Engine管理的實例組來管理創建的實例。 這些實例來自Google Compute引擎,這意味着它們是虛擬機。

但是我們在doc頁面中讀到:“ VM是重量級且不可移植的。新方法是基於操作系統級虛擬化而不是硬件虛擬化來部署容器”不是矛盾嗎? 如果我錯了糾正我。 我們之所以使用容器,是因為與VM相比,它們的運行速度非常快(無論是在啟動時還是在執行任務方面),而且它們還節省了大量空間。 因此,如果我們有一個最多可支持4個容器的節點(vm),我們的客戶可以迅速吃掉4個容器,但是超出此數目,gcloud autoscaler將需要吃一個新節點(vm)來支持即將到來的容器,這將導致一些任務延遲。

在物理機器上啟動容器是不可能的嗎?

您對運行關鍵時間執行任務有何建議?

絕對有可能在物理計算機上啟動容器。 實際上,根據Borg的論文 (其設計對Container Engine / Kubernetes產生了重大影響),這是Google自己的基礎架構中的規范:

每個任務都映射到在計算機上的容器中運行的一組Linux進程[62]。 Borg的大部分工作負載都無法在虛擬機(VM)中運行,因為我們不想支付虛擬化的費用。 此外,該系統是在我們對處理器進行了大量投資而沒有硬件虛擬化支持的時候設計的。

由於容器引擎托管在GCP內,因此使用VM來促進動態配置。 但是,與計划在其上的容器的生存期相比,這些VM的生存期很長。 可以在這些VM的上/下計划容器的容器,然后作業完成。 但是,在升級集群或調整集群大小時,VM將被拆除。

Kubernetes可以安裝在虛擬機和物理機上(有多個關於裸機的入門指南 )。 Google的Cloud Platform僅提供虛擬機作為服務,這就是為什么Google Container Engine構建在虛擬機之上的原因。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM