1

Google Container Engineクラスタが作成されると、Container Engineは、作成されたインスタンスを管理するCompute Engine管理インスタンスグループを作成します。これらのインスタンスはGoogle Computeエンジンからのものです。つまり、それらは仮想マシンです。Google Container Cluster内で使用されるノードについての混乱

しかし、私たちはdocページで次のように読んでいます。「VMは重量がありポータブルではありません。新しい方法は、ハードウェア仮想化ではなくオペレーティングシステムレベルの仮想化に基づいてコンテナを展開することです。私が間違っていれば私を修正してください。 コンテナは、VMに比べて非常に高速(ブート時またはタスク実行時)で、コンテナを使用するため、多くのスペースを節約できます。したがって、4つのコンテナを最大限サポートできるノード(VM)が1つあれば、クライアントは4つのコンテナを迅速にランチすることができますが、この数を超えると、gcloudオートスケーラは次のコンテナをサポートするために新しいノードディレイ。

物理マシンでコンテナを起動することは不可能ですか?

重要な実行タスクの実行にはどのようなことをお勧めしますか?

答えて

3

物理マシンでコンテナを起動することは間違いありません。実際には、Borg paper(重くコンテナエンジン/ Kubernetesに影響を与えているの設計)によると、これはGoogleの独自のインフラストラクチャ内の規範である:

各タスクは、上のコンテナで実行中のLinuxプロセスのセットにマップ マシン[62]。仮想化のコスト を支払う必要はないため、Borgのワークロードの大部分は、仮想マシン(VM)内で を実行しません。また、システムは、 仮想化をサポートしていないプロセッサに相当な投資をハードウェアに実装した時点で設計されていました( )。

コンテナエンジンはGCP内でホストされるため、VMは動的プロビジョニングを容易にするために使用されます。しかし、これらのVMは、スケジュールされたコンテナの寿命に比べて長寿命です。コンテナのポッドは、これらのVMのオン/オフでスケジュールされ、ジョブは完了するまで実行されます。ただし、クラスタをアップグレードまたはサイズ変更すると、VMが破棄されます。

1

Kubernetesは、仮想マシンと物理マシンの両方にインストールできます(multiple getting started guides for bare metalがあります)。 GoogleのCloud Platformは、仮想マシンをサービスとして提供するだけで、Google Container Engineは仮想マシンの上に構築されています。

関連する問題