La 仮想化は非常に一般的な方法になっています、特にクラウドサービスでは、データセンターのサーバーをさらに活用できるようになります。 しかし最近、コンテナベースの仮想化が課されています。これにより、(特定のプロセスを複製する必要がないため)はるかに効率的な管理が可能になります。 そして、Docker対Kubernetesの戦いが発生するのはこのピークです。
あなたがおそらくすでに知っているXNUMXつの非常に人気のあるプロジェクト。 両方とも その長所と短所、そして違いがあります それはあなたがあなたのニーズに応じてプロジェクトを選ぶのを助けることになると鍵となることができます...
コンテナベースの仮想化とは何ですか?
ご存知のように、いくつかあります 仮想化の種類完全仮想化、準仮想化など。 このセクションでは、混乱を招く可能性のある他の変数を導入しないように、仮想マシンとコンテナーをマウントするときに一般的に使用される完全仮想化に焦点を当てます。
- 仮想マシン-これはリーチ中心の仮想化アプローチです。 これは、KVM、Xenなどのハイパーバイザー、またはVMWare、VirtualBoxなどのプログラムに基づいています。 このソフトウェアを使用すると、完全な物理マシン(vCPU、vRAM、ディスクドライブ、仮想ネットワーク、周辺機器など)がエミュレートされます。 したがって、オペレーティングシステム(ゲスト)をこの仮想ハードウェアにインストールし、そこから、ホストオペレーティングシステムで実行するのと同じ方法でアプリケーションをインストールして実行できます。
- コンテナ:これは、この完全なシステムの一部を省略できる一種のケージまたはサンドボックスが結合された別のテクノロジーであり、より効率的で、移植性と追加のセキュリティのいくつかの利点があります(ただし、脆弱性がないわけではありません) 。 実際、ハイパーバイザーを使用する代わりに、これらの場合、ホストシステム自体を使用して分離されたアプリを実行するDockerやKubernetesなどのソフトウェアがあります。 欠点は、ホストOS自体からのみネイティブアプリをデプロイできることです。 つまり、VMでは、たとえばLinuxディストリビューションでWindowsを仮想化でき、そのWindowsではネイティブアプリを実行できますが、コンテナーでは、ホストシステムでサポートされているアプリでのみ実行できます。 Linuxの場合..。
の拡張機能またはサポートを覚えておいてください ハードウェア仮想化Intel VTやAMD-Vと同様に、CPUオーバーヘッドが2%しかないことを前提として、パフォーマンスを大幅に向上させることができました。 ただし、これは、完全仮想化に割り当てられるメモリやストレージ自体などの他のリソースには適用されません。これは、かなりのリソース需要を意味します。
これがすべて、コンテナが解決するようになるものです。 特定のプロセスを複製する必要はありません アプリケーションをデプロイできるようにするため。 たとえば、Apacheサーバーを使用してコンテナーを作成する場合、完全な仮想マシンを使用すると、ホストオペレーティングシステム、ハイパーバイザー、ゲストオペレーティングシステム、およびそのサービス用のソフトウェアが必要になります。 一方、コンテナでは、このサービスを実装するソフトウェアがあれば十分です。これは、コンテナが「ボックス」で分離して実行され、ホストオペレーティングシステム自体を使用するためです。 それとは別に、ゲストOSを排除することで、アプリの起動がはるかに高速になります。
Dockerとは何ですか?
デッカー は、Apacheライセンスの下で、Goプログラミング言語で記述され、コンテナー内のアプリケーションのデプロイメントを自動化するために使用されるオープンソースプロジェクトです。 つまり、このソフトウェアは複数のプラットフォームで動作するため、さまざまなオペレーティングシステムでコンテナを管理できます。
Dockerが登場したとき、 それには多くの利点がありました、そしてそれはすぐに広がりました。 オペレーティングシステムとシンプルさの分離されたビジョンにより、アプリを使用してコンテナーを構築し、デプロイし、スケーリングし、迅速に実行することができました。 最小限のリソース消費で必要なすべてのアプリを起動する方法。
要約すると、Dockerは以下を提供します 文字 キー:
- 環境からの隔離。
- コンテナ管理。
- バージョン管理。
- 場所/親和性。
- 機敏。
- 生産性
- 効率。
しかし 特定の問題がないわけではありませんそれらのコンテナが調整しなければならなかったときのように、互いに通信します。 これが、Kubernetesの作成につながった理由のXNUMXつです...
後でコメントします DockerSwarm、同じDocker開発者によって作成されたソフトウェアであり、一連のDockerホストをクラスターにグループ化して、クラスターを一元管理し、コンテナーを調整できることをコメントしたいと思います。
Kubernetesとは何ですか?
もともとはGoogleによって作成され、後にCloud Native ComputingFoundationに寄付されました。 Kubernetes また、Dockerに似たシステムであり、オープンソースであり、Apacheでライセンスされ、Goプログラミング言語を使用して記述されています。 コンテナ化されたアプリケーションのデプロイメントと管理を自動化するために使用されます。 さらに、Dockerなど、コンテナーを実行するためのさまざまな環境をサポートします。
最終的に、Kubernetesは オーケストレーションプラットフォーム さまざまなマシンのさまざまなコンテナ、それらの管理、およびそれらの間の貨物の分配を支援する責任があるコンテナ。 このプロジェクトをこれらのタイプのシナリオで不可欠な部分にしたのは特にその組織です...
- 自動スケジューリング。
- 自己回復機能。
- 自動化されたロールアウトと展開。
- 負荷分散と水平スケール。
- リソース使用率の密度が高くなります。
- ビジネス環境向けの機能。
- 一元化されたアプリケーション管理。
- 自己拡張可能なインフラストラクチャ。
- 宣言型構成。
- 信頼性。
DockerとKubernetes
定義からわかるように、どちらも多くの点で非常に似ていますが、 それらの違い、およびそれらの長所と短所があります すべてのように。 あなたはこれらの詳細を知っていると、あなたが持っている目的に応じて、どれを選ぶべきかを知るためのすべてを持っていると思うかもしれません。
しかし、問題 それよりも複雑なものです。 DockerとKuernetesについてではありません。これは、非常に異なるものを比較するようなものであり、どちらかを選択する必要があると誤解する可能性があるためです。 DockerとKubernetesの結果はばかげています。むしろ、コンテナー化されたアプリケーションをより適切な方法で提供およびスケーリングできるように、両方のテクノロジーを結び付ける必要があります。
最も適切なのは比較することです Kubernetesを使用したDockerSwarm。 Docker Swarmはコンテナクラスターを作成するためのDockerオーケストレーションテクノロジーであるため、これはより成功するでしょう。 それでも完全に成功するわけではありません...実際、Kubernetesはクラスターで実行するように設計されており、Dockerがシングルモードで実行しているのに対し、本番環境でノードのクラスターを大規模に効率的に調整できます。
DockerとKubernetesの違い
あなたが知りたいのであれば、それらを保存する 発散 Docker SwarmとKubernetesの間では、次のようになります。
- Kubernetesには、 個人化 DockerSwarmが不足しています。
- DockerSwarmは もっと簡単に その単純さのために構成します。 さらに、Dockerエコシステムへの統合も簡単です。
- 代わりに、 フォールトトレランス Kubernetesはより高く、高可用性サーバーなどの環境ではよりポジティブになる可能性があります。
- DockerSwarmは より速く コンテナの展開と拡張に関して。
- その一部のKubernetesは提供しています より大きな保証 クラスター状態に。
- El 負荷分散 Kubernetesでは、Dockerのように自動ではありませんが、バランスを改善できます。
- Kubernetesのオファー より良い柔軟性複雑なアプリケーションでも。
- DockerSwarmは最大2000をサポートします ノード、Kubernetesの5000と比較して。
- Kubernetesは 最適化 多くの小さなクラスター用ですが、Dockersは大きなクラスター用です。
- Kubernetesは 複雑な、よりシンプルなDocker。
- Kubernetesで許可できる ストレージスペースを共有する Dockerはより制限されており、同じポッド内のコンテナー間でのみ共有されます。
- DockerSwarmを使用すると サードパーティのソフトウェア ロギングとモニタリングのために、Kubernetesには独自の組み込みツールが含まれています。
- DockerSwarmは95.000に制限されています コンテナ、Kubernetesは最大300.000をサポートできます。
- Dockerには 素晴らしいコミュニティ Kubernetesには、Microsoft、Amazon、Google、IBMなどの企業の支援もあります。
- Dockerはによって使用されます 企業 Spotify、Pinterest、eBay、Twitterなどのように。 Kubernetesは9GAG、Intuit、Buffer、Evernoteなどを好みます。
利点
いくつかの相違を見てきましたが、今は 利点 各:
- Kubernetes:
- ポッドを使用してサービスを簡単に整理できます。
- Googleによって開発され、クラウド業界での豊富な経験があります。
- 巨大なコミュニティとコンテナオーケストレーションツール。
- ローカルSANやパブリッククラウドなど、さまざまなストレージオプション。
- デッカー:
- 効率的で簡単な初期設定。
- コンテナのバージョンを追跡して、バリエーションを調べます。
- 速い。
- 非常に優れたドキュメント。
- アプリ間の良好な分離。
デメリット
に対する 欠点:
- Kubernetes:
- より複雑な移行。
- 複雑なインストールおよび構成プロセス。
- 既存のDockerツールと互換性がありません。
- 手動クラスターの実装は複雑です。
- デッカー:
- ストレージオプションは提供していません。
- 悪いフォローアップ。
- 非アクティブなノードの自動再プログラミングはありません。
- アクションはCLIで実行する必要があります。
- 複数のインスタンスの手動管理。
- 他のツールのサポートが必要です。
- クラスターの手動展開が難しい。
- ヘルスチェックはサポートされていません。
- Dockerは営利企業であり、DockerEngineやDockerDesktopなどの重要なコンポーネントの一部はオープンソースではありません。
DockerとKubernetes:結論
あなたが想像できるように、 選ぶのはそれほど簡単ではありません どちらか一方の間。 DockerとKubernetesの戦いは、見た目よりも複雑です。 そして、すべてはあなたが持っている目的に依存します。 どちらかがより適しているでしょう、そしてそれはあなたの選択であるべきです。
他の多くの場合、 DockerでKubernetesを使用するのが最適です すべてのオプションの。 両方のプロジェクトは一緒にうまく機能します。 これにより、インフラストラクチャのセキュリティとアプリケーションの高可用性を向上させることができます。 アプリをよりスケーラブルにすることもできます。
どうもありがとう ! 多くの場合のように、最も適切なものを選択することの問題ではないにしても、良くも悪くもないことを理解することは私にとってより明確になりつつあります。
どちらのシナリオがより適切に機能し、どのシナリオでそれらを一緒に使用するかを理解するために、より明確な例が必要なのかもしれません。
また、このタイプのソフトウェアにはどのような代替手段がありますか?
そして、コンテナについて知り始めた私たちが、大企業で働くのを待たずに実際の事例を見るには、どのような用途がありますか?
ここで何かが間違って定義されていると思います。dockerはコンテナーマネージャーであり、Orchestratorと比較することはできません。
比較は、DockerSwarmとKubernetesの間で行われます。
どうやらこの壮大な投稿の作成中に(私の意見では本当に興味深い)、いくつかの用語が交差しました。