コンテナテクノロジー：docker、rkt、orchestration、kubernetes、GKE、AWS Container Service

Question

コンテナ技術をよく理解しようとしていますが、少し混乱しています。特定のテクノロジーがスタックのさまざまな部分に重なっており、DevOpsチームが適切と考えるように、さまざまなテクノロジーのさまざまな部分を使用できるようです（たとえば、Dockerコンテナーを使用できますが、Dockerエンジンを使用する必要はなく、クラウドプロバイダーのエンジンを使用できます）代わりに）。私の混乱は、「コンテナスタック」の各レイヤーが何を提供し、各ソリューションの主要なプロバイダーが誰であるかを理解することにあります。

これが私の素人の理解です。私の理解の穴に関する修正とフィードバックをいただければ幸いです

コンテナ：アプリケーション、ランタイム環境、システムライブラリなどを含む自己完結型のパッケージ。アプリケーションを備えたミニOSのように
- Dockerは事実上の標準のようです。注目に値し、広く使用されている他のものはありますか？
コンテナクラスター：リソースを共有するコンテナーのグループ
コンテナエンジン：コンテナをクラスタにグループ化し、リソースを管理します
オーケストレーター：これはコンテナーエンジンと何か違いがありますか？どうやって？
- Docker Engine、rkt、Kubernetes、Google Container Engine、AWS Container Serviceなどは＃2〜4のどこにありますか？

Anirudh Ramanathan · Answer

これは少し長く、過度に単純化されている可能性がありますが、アイデアを広めるには十分なはずです。

物理マシン

少し前までは、単純なアプリケーションをデプロイする最良の方法は、新しいWebサーバーを購入し、それにお気に入りのオペレーティングシステムをインストールして、そこでアプリケーションを実行することでした。

このモデルの短所は次のとおりです。

プロセスは互いに干渉する可能性があり（CPUとファイルシステムのリソースを共有するため）、一方が他方のパフォーマンスに影響を与える可能性があります。
このシステムのスケールアップ/スケールダウンも難しく、新しい物理マシンのセットアップに多くの労力と時間を要します。
物理マシンのハードウェア仕様、OS /カーネルバージョン、およびソフトウェアパッケージバージョンに違いがある場合があり、ハードウェアに依存しない方法でこれらのアプリケーションインスタンスを管理することは困難です。

物理マシンの仕様に直接影響を受けるアプリケーションでは、特定の調整や再コンパイルなどが必要になる場合があります。つまり、クラスター管理者は、それらを個々のマシンレベルのインスタンスと見なす必要があります。したがって、このアプローチは拡張性がありません。これらのプロパティにより、最新の本番アプリケーションの展開には望ましくありません。

仮想マシン

仮想マシンは、上記の問題のいくつかを解決します。

同じマシンで実行している場合でも、分離を提供します。
これらは、基盤となるハードウェアに関係なく、標準の実行環境（ゲストOS）を提供します。
それらは、スケーリング（分単位）時に非常に迅速に別のマシン（複製）で起動できます。
通常、物理ハードウェアから仮想マシンに移行するためにアプリケーションを再設計する必要はありません。

しかし、彼らは彼ら自身のいくつかの問題をもたらします：

これらは、オペレーティングシステムのインスタンス全体を実行する際に大量のリソースを消費します。
それらは、私たちが望むほど速く開始/停止しない場合があります（秒のオーダー）。
ハードウェア支援による仮想化を使用しても、アプリケーションインスタンスでは、ホスト上で直接実行されているアプリケーションよりもパフォーマンスが大幅に低下する可能性があります。（これは特定の種類のアプリケーションでのみ問題になる可能性があります）
VMイメージのパッケージ化と配布は、それほど単純ではありません（これは、仮想化のための既存のツールの場合ほど、このアプローチの欠点ではありません）。

コンテナ

次に、どこかで cgroups（コントロールグループ）がLinuxカーネルに追加されました。この機能により、プロセスをグループに分離し、プロセスが表示できる他のプロセスとファイルシステムを決定し、グループレベルでリソースアカウンティングを実行できます。

さまざまなコンテナランタイムとエンジンが登場し、可視性やリソースなどが制限されている名前空間など、OS内の環境である「コンテナ」を作成するプロセスが非常に簡単になりました。これらの一般的な例には、docker、rkt、runC、LXCなどがあります。

たとえば、Dockerには、コンテナに即座に起動できる再利用可能なエンティティである「イメージ」の作成などの対話を提供するデーモンが含まれています。また、直感的な方法で個々のコンテナを管理することもできます。

コンテナの利点：

カーネル/ OSの独自のインスタンスがなく、単一のホストOS上で実行されるため、軽量でオーバーヘッドがほとんどありません。
これらは、さまざまなコンテナー間である程度の分離を提供し、コンテナーによって消費されるさまざまなリソースに制限を課す機能を提供します（cgroupメカニズムを使用）。
それらを取り巻くツールは急速に進化し、主にdockerにより、再利用可能なユニット（イメージ）、イメージリビジョンを格納するためのリポジトリ（コンテナーレジストリ）などを簡単に構築できるようになりました。
コンテナを個別に維持および配布するために、単一のコンテナで単一のアプリケーションプロセスを実行することをお勧めします。コンテナの軽量性により、これが望ましいものになり、デカップリングにより開発が迅速化されます。

いくつかの短所もあります：

提供される分離のレベルは、VMの場合よりも低くなります。
ステートレスで使用するのが最も簡単です 12-factor アプリケーションを新たに構築し、レガシーアプリケーションやクラスター化された分散データベースなどをデプロイしようとすると少し苦労します。
それらは効果的かつ大規模に使用されるためにオーケストレーションとより高いレベルのプリミティブを必要とします。

コンテナオーケストレーション

本番環境でアプリケーションを実行する場合、複雑さが増すにつれて、さまざまなコンポーネントが含まれる傾向があり、その一部は必要に応じてスケールアップ/スケールダウンするか、スケールアップが必要になる場合があります。コンテナ自体がすべての問題を解決するわけではありません。次のような実際の大規模アプリケーションに関連する問題を解決するシステムが必要です。

コンテナ間のネットワーキング
負荷分散
これらのコンテナに接続されたストレージの管理
コンテナーの更新、スケーリング、マルチノードクラスター内のノード間での分散など。

コンテナーのクラスターを管理する場合は、コンテナーオーケストレーションエンジンを使用します。これらの例としては、Kubernetes、Mesos、Docker Swarmなどがあります。これらは、上記の機能に加えて多くの機能を提供し、目標はdev-opsに伴う労力を削減することです。

GKE（Google Container Engine）は、Google CloudPlatformでKubernetesをホストしています。これにより、ユーザーはnノードのkubernetesクラスターが必要であることを指定するだけで、クラスター自体をマネージドインスタンスとして公開できます。 Kubernetesはオープンソースです必要に応じて、Google Compute Engine、別のクラウドプロバイダー、または独自のデータセンター内の独自のマシンにセットアップすることもできます。

ECSは、Amazonによって構築および運用され、AWSスイートの一部として利用できる独自のコンテナ管理/オーケストレーションシステムです。

iamnat · Answer

あなたの質問に具体的に答えるには：

Dockerエンジン：DockerコンテナーとDockerイメージのライフサイクルを管理するためのツール。 Dockerコンテナを作成、再起動、削除します。 Dockerイメージを作成、名前変更、削除します。
rkt：Dockerエンジンに似ていますが、実装が異なります
Kubernetes：コンテナを使用する分散アプリケーションのライフサイクルを管理するためのツールのコレクション。コンテナー、コンテナーのグループ、コンテナーの構成、コンテナーのオーケストレーション、実際のインスタンスでのスケジューリング、開発者がコンテナーを処理するための他のサービス/ツールを作成および保守するのに役立つツールが含まれています。
Google Container Engine：VMを取得する代わりに、VMに「docker-engine」をインストールし、kubernetesをインストールして、インフラストラクチャへの適切な権限などですべてを機能させるなど、すべてが一緒になって選択できるかどうかを想像してください。マシンのタイプと、これらすべてが正常に機能しているクラスターのサイズ。プロジェクト固有のDockerリポジトリ（Googleコンテナレジストリ）からイメージをプルしたり、永続ボリュームを要求したり、ロードバランサーをプロビジョニングしたりするなど、サービスアカウントや権限などを気にすることなく機能します。
ECS：GKE（4）に類似していますが、Kubernetesはありません。

あなたの理解のポイントに対処するために：あなたは物事について大まかに正しいです（私が思うコンテナエンジンを除いて）。理解することが重要なのはコンテナとは何かということだけを理解することが重要です。残りはマーケティング/製品名だけです。今日のコンテナーの理解は、Dockerコンテナーとは何か、DockerとDockerを取り巻くツールによって強制される多くの意見によって、非常に歪められていることを理解することも重要です。コンテナは長い間存在してきました。

したがって、（Docker）コンテナーとは何かを理解すると、コンテナーエンジンはコンテナーを管理するための単なるツールであり、コンテナークラスターはコンテナーの単なるグループであり、オーケストレーターはいくつかのパラメーターに基づいてコンテナーが実行される場所を管理するためのツールです。私見ですが、コンテナの周りにしっかりとしたメンタルモデルを理解して構築すれば、残りのツールが何であるかについてあまり心配する必要はありません。残りは自動的に収まります。

これらすべてを理解するための最良の方法は？ Dockerを使用してかなり複雑なアプリケーションをビルドおよびデプロイし（データを永続化/アプリでデータベースを使用）、すべてが理にかなっています。