Kubernetes と Docker: 違いを解説

Docker と Kubernetes のコンテナ ソリューションについて学び、Kubernetes と Docker の違いを理解して、ニーズに最適なソリューションを選択してください。

Kubernetes と Docker: 違いを解説

コンテナ化は数十年前から存在していますが、近年ではアプリケーション開発や近代化のために採用されるケースが増えています。この記事では、2 つのコンテナ ソリューションとその使用方法について説明します。

コンテナ エンジン ソリューションである Docker、そのコンテナ オーケストレーション ソリューションである Docker Compose、およびクラスター コンテナ オーケストレーション ソリューションである Docker Swarm。

Kubernetes は、要件に最適なソリューションを選択できるようにするために Docker Swarm と比較するもう 1 つのクラスター化されたコンテナー ソリューションです。

コンテナ化とは何ですか?

コンテナ化は、アプリケーション レベルでの仮想化の一種です。これは、アプリケーションとそのすべての依存関係、ランタイム、ライブラリ、および構成ファイルを、コンテナーと呼ばれる自己完結型の実行可能パッケージにパッケージ化するように設計されています。オペレーティング システム (OS) はコンテナーに含まれていないため、ハードウェア レベルで仮想化され、オペレーティング システムが含まれる仮想マシン (VM) とは異なります。

仮想化の概念は複数の仮想マシン間で物理リソースを共有することですが、コンテナは単一のオペレーティング システムのカーネルを複数のコンテナ間で共有します。仮想マシンとは異なり、コンテナにはオペレーティング システムが含まれていないため軽量です。このため、コンテナの起動には数秒かかります。さらに、コンテナは、変更を加えることなく、さまざまなオペレーティング システム (Windows、Linux、macOS) やさまざまな環境 (クラウド、VM、物理サーバー) に簡単にデプロイできます。

2013 年、Docker Inc. は、さまざまなプラットフォームで広く使用できるようにコンテナを標準化する目的で Docker を導入しました。 1 年後、Google はコンテナ ホストのクラスターを管理するためのソリューションとして Kubernetes をリリースしました。これら 2 つのソリューションの定義により、Kubernetes と Docker の違いが明らかになります。

Dockerとは何ですか?

Docker は、さまざまなプラットフォームで同じ動作で実行できる標準コンテナーにアプリケーションをパッケージ化して実行するためのオープン ソース プラットフォームです。 Docker を使用すると、コンテナ化されたアプリケーションはホストから分離されるため、任意のオペレーティング システムを実行している任意のプラットフォームにアプリケーションを配信できる柔軟性が得られます。さらに、Docker エンジンはコンテナを管理し、同じホスト上で同時に実行できるようにします。

クライアント サーバー アーキテクチャのため、Docker はクライアント側コンポーネントとサーバー側コンポーネント (Docker クライアントと Docker デーモン) で構成されます。クライアントとデーモン (Dockerd) は同じシステム上で実行することも、クライアントをリモート デーモンに接続することもできます。デーモンは、他の Docker オブジェクト (コンテナ、ネットワーク、ボリューム、イメージなど) を管理するだけでなく、クライアントから送信された API リクエストも処理します。

Docker Desktop は、Docker Compose、Docker CLI (コマンドライン インターフェイス) などの他のコンポーネントを含む、Docker クライアントとデーモンのインストーラーです。Windows、Linux、macOS など、さまざまなプラットフォームにインストールできます。

開発者は、同じホスト上の複数のコンテナで実行されるアプリケーションを設計できるため、複数のコンテナを同時に管理する必要が生じます。この目的のために、Docker Inc. は Docker Compose を立ち上げました。 Docker と Docker Compose をまとめると、Docker は 1 つのコンテナを管理できますが、Compose はホスト上で複数のコンテナを管理できます。

Docker の作成

同じホスト上で複数のコンテナ化されたアプリケーションを管理するのは、複雑で時間のかかる作業です。 Docker Compose は、Compose ファイル形式を使用して、ホスト上で定義された複数のコンテナー化されたアプリケーションを管理する、単一ホスト用のオーケストレーション ツールです。

Docker Compose では、すべてのコンテナを定義する単一の YAML 構成ファイルを作成することで、複数のコンテナを同時に実行できます。 Compose を使用すると、アプリケーションを 1 つのコンテナーでビルドするのではなく、複数のコンテナーに分割できます。アプリケーションをマイクロサービスと呼ばれるサブサービスに分割し、各マイクロサービスをコンテナ内で実行できます。その後、Compose を通じて 1 つのコマンドを実行して、すべてのコンテナを起動できます。

Docker スウォーム

開発者は、異なるホスト上の複数のコンテナで実行されるアプリケーションを設計できますが、そのためには、異なるホスト間のコンテナ クラスター用のオーケストレーション ソリューションが必要です。この目的のために、Docker Inc. は Docker Swarm を立ち上げました。

Docker Swarm または Swarm モードの Docker は、Docker をインストールした後に有効にできる Docker エンジンのクラスターです。 Swarm では、同じホスト上の複数のコンテナの管理のみ可能な Compose とは異なり、異なるホスト上の複数のコンテナの管理が可能です。

Kubernetes とは何ですか?

Kubernetes (K8s) は、1 つ以上のホスト上のコンテナを管理するためのオーケストレーション ツールです。 K8s は、オンプレミス、クラウド、ハイブリッド環境のいずれであってもクラスターをホストし、Docker やその他のコンテナー プラットフォームと統合できます。 Google はもともと、コンテナの展開と管理を自動化するために Kubernetes を開発し、導入しました。 K8s は、コンテナのフォールト トレランス、ホスト間の負荷分散、コンテナの自動作成と削除など、回復力をサポートするいくつかの機能を提供します。

Kubernetes は、マスター ノードまたはワーカー ノードのいずれかである 1 つ以上のホストで構成されるクラスターを管理します。マスター ノードには Kubernetes のコントロール プレーン コンポーネントが含まれ、ワーカー ノードにはコントロール プレーン以外のコンポーネント (Kubelet および Kube-proxy) が含まれます。テストを実行するには、少なくとも 1 つのマスター ノードと 3 つのワーカー ノードを含む、少なくとも 4 つのホストのクラスターを用意することをお勧めします。

コントロール パネル コンポーネント (マスター ノード)

マスター ノードは複数のノードにまたがることができますが、実行できるのは 1 台のコンピューター上のみです。マスターノードにアプリケーション コンテナを作成しないことをお勧めします。マスターはクラスターの管理を担当します。クラスター イベントに応答し、クラスターの決定を行い、コンテナーのスケジューリング操作を使用し、新しい Pod (同じホスト上のコンテナーのグループ、Kubernetes の最小単位) を開始し、制御ループを実行するなどを行います。

Apiserver は、API を他の Kubernetes コンポーネントに公開するコントロール プレーン フロントエンドです。他のコンポーネントのアクセスと認証を処理します。

Etcd は、すべてのクラスターのキー/値データを保存するデータベースです。高可用性を確保するために、各マスターノードには etcd のコピーが必要です。

Kube スケジューラは、新しく作成された Pod にノードを割り当てる役割を担います。

Kube コントローラー マネージャーは、複雑さを軽減するために単一のプロセスで実行されるコントローラー プロセスのセットです。コントローラー プロセスは、apiserver を介してクラスターの共有状態を監視する制御ループです。クラスターの状態が変化すると、クラスターを目的の状態に戻すアクションが実行されます。コントロール マネージャーは、ノード、ジョブ、サービス アカウント、トークンなどのステータスを監視します。

クラウド コントローラー マネージャーは、クラスターがクラウド プロバイダーの API と通信できるようにするオプションのコンポーネントです。クラウドと対話するコンポーネントとオンプレミス クラスターと対話するコンポーネントを分離します。

ノードコンポーネント（ワーカーノード）

ワーカーノードは非マスターノードです。ノード コンポーネントには、kubelet と kube-proxy の 2 つがあります。 Docker などのコンテナ ランタイム ソフトウェアに加えて、各ワーカー ノードで実行する必要があります。

Kubelet は、各コンテナが Pod 内で実行されるようにするためにワーカー ノード上で実行されるエージェントです。 Kubernetes によって作成されたコンテナを管理し、正常な状態で実行されていることを確認します。

Kube-proxy は、各ワーカーノードで実行され、Kubernetes ネットワーク サービスの一部となるネットワーク プロキシです。これにより、ポッドはクラスターまたは外部ネットワークと通信できるようになります。

その他のコンポーネント

サービスは、特定の時間に連携して動作するポッドの論理グループです。 Pod とは異なり、Service には固定 IP アドレスがあります。これにより、Pod を削除する際の問題が修正され、代わりに他の Pod またはオブジェクトがサービスと通信できるようになります。サービスにポリシーを割り当てて、ラベルに基づいてポッドをフィルタリングすることで、サービスのポッドのセットが選択されます。

ラベルは、ポッド、サービス、またはその他のオブジェクトに割り当てることができる属性のキーと値のペアです。タグを使用すると、共通のプロパティに基づいてオブジェクトをクエリし、選択項目にタスクを割り当てることができます。各オブジェクトには 1 つ以上のタグを設定できます。キーはオブジェクト内で 1 回だけ定義できます。

Kubernetes と Docker Swarm: どちらが優れているでしょうか?

Kubernetes と Docker は、異なる範囲のソリューションであり、互いに補完し合って強力な組み合わせを形成します。したがって、Docker と Kubernetes を比較するのは正しいとは言えません。 Docker を使用すると、開発者はアプリケーションを分離されたコンテナにパッケージ化できます。開発者は、オペレーティング システムとの互換性の問題を心配することなく、これらのコンテナーを他のマシンに展開できます。

開発者は Docker Compose を使用してホスト上のコンテナを管理できます。しかし、Docker Compose と Kubernetes の比較も、ソリューションが異なる範囲に適用されるため、正確な比較ではありません。 Compose は単一のホストにスコープが設定されていますが、Kubernetes はホストのグループにスコープが設定されています。

コンテナとホストの数が増えると、開発者は Docker Swarm または Kubernetes を使用して Docker コンテナをオーケストレーションし、クラスター内で管理できます。 Kubernetes と Docker Swarm はどちらも、クラスター設定におけるコンテナ オーケストレーション ソリューションです。

Kubernetes は、高可用性、負荷分散、スケジューリング、監視を提供し、常時稼働で信頼性が高く堅牢なソリューションを提供するため、大規模な環境では Swarm よりも広く使用されています。

以下の点では、K8s をより堅牢なソリューションとして検討する価値がある違いを強調します。

インストール

Swarm はすでに Docker Engine に含まれています。 Swarm は、いくつかの Docker CLI (コマンド ライン インターフェイス) 標準コマンドを使用して簡単に有効化できます。

ただし、Kubernetes の導入は、インストールして使用するために新しい非標準のコマンドを学習する必要があるため、より複雑です。さらに、Kubernetes で使用される特定のデプロイメント ツールの使用方法を学習する必要があります。クラスター ノードは、マスター、コントローラー、スケジューラーなどの定義など、Kubernetes で手動で構成する必要があります。

注: Kubernetes のインストールの複雑さは、Kubernetes as a Service (KaaS) を使用することで克服できます。 KaaS はすべての主要なクラウド プラットフォームで利用できます。これらには、Google Cloud Platform (GCP) の一部である Google Kubernetes Engine (GKE) や Amazon Elastic Kubernetes Service (EKS) が含まれます。

スケーラビリティ

どちらのソリューションもスケーラビリティをサポートしています。ただし、Swarm ではスケーラビリティを実現しやすい一方で、Kubernetes はより柔軟性に優れています。

Swarm はシンプルな Docker API を使用して、コンテナとサービスをオンデマンドでより簡単かつ迅速に拡張できるようにします。

一方、Kubernetes は自動スケーリングをサポートしており、スケーラビリティがより柔軟になります。ただし、統合 API を使用するため、拡張性はより複雑になります。

負荷分散

Swarm には負荷分散機能が組み込まれており、内部ネットワークを使用して自動的に実行されます。クラスターへのすべてのリクエストはホスト間で負荷分散されます。 Swarm は DNS を使用して、サービス名に対する要求を負荷分散します。 Swarm でこの機能を手動で設定する必要はありません。

Kubernetes は、負荷分散をサポートするように手動で構成する必要があります。 Pod で負荷分散ポリシーを定義する必要があります。したがって、ポッドはサービスとして定義する必要があります。 Kubernetes は負荷分散に Ingress を使用します。Ingress は、外部ネットワークから Kubernetes サービスへのアクセスを許可するオブジェクトです。

高可用性

どちらのソリューションも、高可用性機能をネイティブにサポートしています。

スウォーム マネージャーはクラスターの状態を監視し、実際の状態の変化を修正して目的の状態を満たすアクションを実行します。ワーカーノードがクラッシュするたびに、Swarm マネージャーは実行中の別のノード上にコンテナを再作成します。

Kubernetes は障害が発生したノードを自動的に検出し、シームレスに新しいノードにフェールオーバーします。

モニター

Swarm には監視およびログ記録ツールが組み込まれていません。このためには、Reimann や Elasticsearch、Kibana (ELK) などのサードパーティ ツールが必要です。

Kubernetes には、クラスターのステータスをネイティブに監視できる ELK 監視ツールが組み込まれています。さらに、ノード、コンテナ、ポッドなどの他のオブジェクトを監視するための監視ツールもいくつかサポートされています。

結論は

Docker は、オペレーティング システムに依存しないコンテナー内でアプリケーションを構築およびデプロイするためのコンテナー化プラットフォームです。 Windows、Linux、または macOS 上の Docker Desktop を使用してインストールでき、Compose や Swarm などの他のソリューションも含まれています。同じホスト上に複数のコンテナを作成すると、それらの管理が複雑になります。この場合、Docker Compose を使用すると、同じホスト上のアプリケーションの複数のコンテナを簡単に管理できます。

大規模な環境では、高可用性やその他の高度な機能を確保するために、複数のノードのクラスタリングが必須になります。これには、Docker Swarm や Kubernetes などのコンテナ オーケストレーション ソリューションが必要です。 2 つのプラットフォームの機能を比較すると、どちらもスケーラビリティ、高可用性、負荷分散をサポートしていることがわかります。ただし、Swarm はインストールと使用が簡単ですが、Kubernetes は自動スケーリングと組み込みの監視ツールをサポートしています。これが、ほとんどの大規模組織が、主に数百のコンテナに分散されているアプリケーションに Kubernetes と Docker を使用する理由です。