コンテナが登場する前は、新しいマシンでアプリを実行するのは悪夢のような作業でした。アプリは特定のソフトウェアや設定ファイルに依存していることが多く、新しいマシンでそれらのソフトウェアや設定ファイルが欠落していたり、異なっていたりすると、アプリは動作しませんでした。
Dockerはこれを一変させました。開発者は必要なものすべてをアプリにパッケージ化できるため、どの環境でも同じように動作させることができます。
次に登場したのはKubernetesです。Kubernetesは、チームが多数のコンテナを一度に実行し、大規模に管理するのに役立ちます。
このガイドでは、Kubernetes と Docker を簡単に説明し、それぞれの機能、連携方法 (または連携しない方法)、実際に必要なものを判断する方法について説明します。
TL;DR: 知っておくべき Docker と Kubernetes の違い
-
Dockerは、ローカルまたは単一ノード環境でのコンテナの構築、パッケージ化、実行に最適です。
-
Kubernetesは、本番環境のクラスタ間でコンテナをオーケストレーション、スケーリング、管理するように設計されています。
-
KubernetesなしでDockerを使用する（Swarmを使用）、またはDockerなしでKubernetesを使用する（containerd経由）ことができます。
-
ほとんどのチームは、スピードとスケーラビリティを組み合わせるために、開発にはDockerを使用し、デプロイメントにはKubernetesを使用しています。
Dockerとは何ですか？
デッカー 開発者がアプリをどこにデプロイしても一貫した方法で実行できるようにするプラットフォームです。
これはコンテナを使用することで実現されます。コンテナとは、アプリに必要なすべてのもの（コード、設定、サポートソフトウェア）を保持する軽量パッケージです。これにより、アプリはノートパソコンでも、テスト環境でも、本番環境でも同じように動作します。
コンテナ自体は新しいものではありません。UNIXなどのシステムでは何十年も前から存在していました。しかし、Dockerによってコンテナは使いやすくなりました。
Dockerを使えば、簡単なコマンドでコンテナを作成できます。システムに適切なバージョンのPythonがインストールされているかどうかや、ライブラリが不足しているかどうかを心配する必要はありません。アプリに必要なものはすべてコンテナ内に既に揃っています。
Dockerはコンテナの管理も容易にしました。Docker Engine、Docker CLI、Docker Composeなどのツールを使えば、わずか数行のコードでコンテナを構築、実行、整理できます。
また、コンテナの標準フォーマットも導入され、レジストリと呼ばれるオンライン ライブラリを通じて共有が容易になりました。
現在、Dockerはコンテナを内部的に実行するためにcontainerdというツールを使用しています。これはKubernetesや他のプラットフォームで使用されているコアランタイムと同じです。
大きなメリットは？
ソフトウェアを手動でインストールしたり、不足しているファイルをトラブルシューティングしたり、別の環境を構築したりする必要はありません。また、仮想マシンとは異なり、コンテナは軽量なので、起動が速く、使用するリソースも少なくて済みます。
Dockerはどのように機能しますか？
Dockerは、アプリとその依存関係をイメージと呼ばれる再利用可能なパッケージに変換します。このDockerイメージは設計図のようなもので、アプリの実行に必要なすべてのもの（コード、ライブラリ、設定、起動手順）が含まれています。
イメージを作成するには Dockerfileを書くDockerに次のように伝えます。
- どのようなベースイメージから始めるか
- 含めるファイル
- 実行するコマンド
- 適用する環境設定
これらのイメージはレイヤー構造で構築されます。Dockerfile内の各命令は新しいレイヤーを作成します。これらのレイヤーはキャッシュされるため、将来のビルドが高速化されます。
イメージを実行すると、Docker はコンテナを作成します。コンテナが実行されると、Docker はこれらのレイヤーを単一のビューに統合し、アプリはまるで 1 つの完全なファイルシステムであるかのように、必要なものすべてにアクセスできるようになります。
違いは次のとおりです。
- イメージはアプリのパッケージ化されたバージョンであり、準備はできていますが、実行されていません。
- コンテナとは、イメージ実行時に得られるものです。これは、アプリが実際に実行される、ライブで隔離された環境です。
Docker がイメージをビルドすると、そのイメージは変更されません。更新が必要な場合は、新しいバージョンのイメージを作成します。
新しいバージョンでは、Dockerはバックエンドでコンテナを管理するためにcontainerdというツールを使用します。このツールはKubernetesでも使用されているため、Kubernetesはコンテナを実行するために完全なDockerプラットフォームを必要としなくなりました。
つまり、簡単に言えば、
- Dockerfile を記述します。
- Docker はそこからイメージを構築します。
- イメージを実行して、軽量で信頼性の高いコンテナを作成します。
Dockerアーキテクチャ
Dockerはクライアントサーバーアーキテクチャを採用しています。この構成には、コンテナの構築、実行、管理を連携して行ういくつかの主要コンポーネントが含まれています。
Dockerデーモン
Dockerデーモンは、マシン上で実行されるバックグラウンドプロセスです。イメージの構築、コンテナの実行、そしてそれらの管理といった、Dockerの重労働を担います。
デーモンはDockerクライアントからのコマンドをリッスンします。また、コンテナの追跡、ストレージの管理、競合（2つのコンテナが同じ名前やポートを使用しようとするなど）の発生防止も行います。
Dockerクライアント
Dockerクライアントは、Dockerとやり取りするためのツールです。docker buildやdocker runなどのコマンドを入力するたびに、クライアントと通信していることになります。
クライアントはDockerデーモンに指示を送信し、デーモンはそれを実行します。クライアントは自分のマシンからでも、別のコンピューターからでも実行できます。
Dockerコマンドラインインターフェース
Dockerコマンドラインインターフェース（CLI）はクライアントの一部です。これはテキストベースのツールで、コマンドを入力してイメージのビルド、コンテナの起動、ステータスの確認を行うことができます。
一般的なコマンドは次のとおりです。
- docker build (イメージをビルドする)
- docker run (コンテナを起動する)
- docker ps (実行中のコンテナを一覧表示する)
ドッカーの作成
Docker Compose は複数のコンテナを使用してアプリを実行します。
アプリがウェブサーバー、データベース、キャッシュ層を使用しているとします。各コンテナを個別に起動する代わりに、Compose を使えば、たった 1 つのコマンドですべてを一度に起動できます。
そのためには、アプリの設定をシンプルなYAMLファイルに記述する必要があります。Dockerはそのファイルを読み込み、記述通りにすべてのコンテナをセットアップします。
Docker エンジン REST API
Docker Engine REST API を使用すると、他のシステムと Docker を連携させることができます。JSON と HTTP を使用して Web 経由で指示を送信するための標準的な方法を提供します。
これは、Docker タスクを自動化したり、Docker を他のツールに接続したりする場合に非常に役立ちます。
Dockerマシン
Docker Machine は、特にクラウド プロバイダー上や異なるオペレーティング システム間で仮想マシン上に Docker をセットアップするために使用されました。
これにより、ユーザーは手動で作業することなく、Docker対応のVMを作成できるようになりました。しかし、現在ではほとんどの開発者はDocker DesktopやKubernetesなどの他のツールを使用しています。
Dockerの利点：なぜ使う価値があるのか
Dockerが、煩雑で一貫性のないデプロイメントプロセスを高速化していることはご理解いただけたかと思います。そこで、開発者にとっての主なメリットを簡単にまとめてみましょう。
| 利点 | その意味 |
|---|
| 携帯性 | 開発、テスト、本番環境で同じ方法でコンテナを実行します。 |
| 速度 | コンテナは VM よりも起動が速く、使用するリソースも少なくなります。 |
| 分離 | 1 つのコンテナがクラッシュしても、他のコンテナには影響しません。 |
| 簡単なツーリング | 簡単なコマンドを使用してコンテナを構築、実行、共有します。 |
| ビルトインセキュリティ | デフォルトの安全対策はシステム リスクの軽減に役立ちます。 |
Kubernetesとは何ですか？
Kubernetes 複数のマシン間でコンテナを実行および管理するのに役立つオープンソース システムです。
各コンテナを実行する場所を決定し、コンテナを正常な状態に保ち、問題が発生した場合にコンテナを再起動するなど、難しい部分を自動的に処理します。
このプロセスはコンテナ オーケストレーションと呼ばれます。
コンテナを手動で起動したり、どのサーバーに空き容量があるかを追跡したりする代わりに、Kubernetes が代わりに実行します。また、トラフィックの増加に合わせてコンテナを追加実行し、不要になったらシャットダウンすることで、アプリをスケールすることもできます。
Kubernetes はもともと Google によって作成されました。
現在、クラウド サーバー、独自のデータ センター、またはその両方を使用しているかどうかに関係なく、コンテナベースのアプリケーションを本番環境で実行するために最も広く使用されているツールです。
Kubernetesはどのように機能しますか？
Kubernetesにアプリをデプロイすると、Kubernetesは利用可能なリソースに基づいて、アプリを実行するのに最適なマシンを選択します。その後、コンテナを監視して、正常な状態を維持します。
コンテナがクラッシュした場合、Kubernetes は自動的に再起動します。トラフィックが増加した場合は、負荷に対応するためにコンテナを追加で起動できます。トラフィックが減少した場合は、スケールダウンできます。
Kubernetesは常にあなたが 欲しいです （あなたの「望ましい状態」）を実行している 実際に 実行中。差異があれば修正します。
現在、Kubernetesはコンテナの管理にDockerプラットフォーム全体を必要としません。代わりに、Dockerでも使用されているcontainerdなどのコンテナランタイムを使用します。つまり、Dockerで構築されたコンテナは引き続き実行できますが、Kubernetesが直接管理します。
Kubernetesはコンテナインフラストラクチャの自動操縦装置と考えてください。Kubernetesは、システムの稼働を維持し、負荷分散を行い、問題をリアルタイムで修正するため、チームはサーバーの監視ではなく構築に集中できます。
Kubernetesアーキテクチャ
Kubernetesには2つの主要な部分があります。 コントロールプレーン と ワーカーノード.
コントロールプレーンはシステムを管理し、何をどこで実行するかを決定します。ワーカーノードは、コンテナが実際に実行されるマシンです。これらのコンポーネントを組み合わせることで、コンテナ化されたアプリを実行するためのスケーラブルで自己修復的なシステムが構築されます。
コントロールプレーン（中枢脳）
コントロールプレーンはクラスター全体を管理します。コンテナの配置場所を決定し、その状態を監視し、期待どおりに動作していない場合は変更を加えます。
いくつかの部分が含まれます:
- APIサーバー Kubernetesとやりとりする方法です。新しいコンテナを作成するなどのコマンドを送信すると、そのコマンドはAPIサーバーを経由します。
- etcd Kubernetesが記憶する必要があるすべての情報（設定、状態、クラスタデータ）を保存するキーバリューデータベースです。システムのメモリとして機能します。
- スケジューラ 新しいコンテナをどのマシン（またはノード）で実行するかを決定します。利用可能なリソースと定義したルールを参照します。
- コントローラーマネージャー 変更を監視し、アクションを実行します。コンテナの実行が停止した場合は、再起動します。何かのコピーを3つ要求した場合、3つが確実に実行されるようにします。
- クラウドコントローラーマネージャー (optional) Kubernetesをクラウドプロバイダーに接続します。ロードバランサーやストレージといったクラウド固有の機能を処理します。
ワーカーノード（コンテナが実行される場所）
ワーカーノードはコンテナ内で実際のアプリを実行します。
各ノードには次のものが含まれます。
- クベレット コントロールプレーンとやり取りするローカルエージェントです。マシン上のコンテナが期待通りに動作しているかどうかを確認します。
- 久部プロキシ ネットワークトラフィックを処理します。リクエストが同じマシン上にあるか、クラスター内の別のマシン上にあるかに関係なく、適切なコンテナに確実に届くようにします。
- コンテナランタイム コンテナを実行するツールです。Kubernetesは次のような様々なランタイムをサポートしています。 コンテナ, それを作成する, デッカー (ただし、Docker 自体は不要になりました)。
Kubernetes の利点: コンテナ管理に Kubernetes を選ぶ理由
チームが本番環境で Kubernetes に依存する理由を簡単に説明します。
| 利点 | その意味 |
|---|
| 自動スケーリング | リアルタイムの需要に基づいてコンテナを追加または削除します。 |
| 自己回復 | 何かが失敗した場合にコンテナを再起動または再スケジュールします。 |
| 一貫した展開 | YAML 構成を使用して、信頼性が高く繰り返し可能なリリースを保証します。 |
| 資源効率 | CPU とメモリの使用を最適化するためにコンテナをスケジュールします。 |
| ビルトインセキュリティ | デフォルトで分離、シークレット、およびアクセス制御をサポートします。 |
| マルチクラウドの柔軟性 | 変更を加えることなく、クラウド、ハイブリッド、オンプレミスなど、どこでも Kubernetes を実行できます。 |
Docker vs Kubernetes: 比較
DockerとKubernetesはよく一緒に扱われますが、コンテナライフサイクルにおける目的は異なります。両者を比較してみましょう。
| 機能 | デッカー | Kubernetes |
|---|
| 何それがありません | コンテナを構築して実行する | コンテナを大規模にオーケストレーションおよび管理する |
| 主な使用例 | 現地開発とパッケージング | コンテナ化されたアプリを本番環境にデプロイおよびスケーリングする |
| 対象領域 | 単一ノードまたは小規模環境 | マルチノード、マルチ環境クラスター |
| セットアップの複雑さ | インストールと実行が簡単 | より複雑。クラスタのセットアップと構成が必要 |
| スケーリング | 手動またはDocker Swarm経由 | 自動スケーリング、負荷分散、自己修復機能を内蔵 |
| ネットワーキング | 基本的なブリッジネットワーク | 高度なサービス検出と内部負荷分散 |
| エコシステムの成熟度 | 強力な開発ツール、イメージエコシステム | 強力なエンタープライズ導入、豊富なクラウドネイティブ エコシステム |
| コンテナランタイム | 内部でcontainerdを使用する | containerd、CRI-O、またはその他のCRI互換ランタイムを使用する |
| ベスト | コンテナの構築、テスト、共有 | 環境全体で本番環境レベルのワークロードを管理する |
Docker、Kubernetes、あるいはその両方を選ぶ: 何が効果的で、なぜそうなのか
すべてのプロジェクトにKubernetesが必要なわけではありません。また、Dockerだけでは必ずしもスケールするとは限りません。では、KubernetesとDockerのどちらを選ぶべきでしょうか？あるいは、両方を使うべきタイミングを見極めるにはどうすればよいでしょうか？まず、次の点を理解しましょう。
ローカルでビルドおよびテストする場合は Docker を使用します。
Dockerは、単一のマシン上でコンテナを構築、テスト、実行するのに最適です。ローカル環境での作業、自動テストの実行、アプリのパッケージ化など、Dockerは軽量、高速、そして使いやすいツールです。
運用ワークロードを拡張または管理する必要がある場合は、Kubernetes を使用します。
Kubernetesは本番環境に適しています。アプリを複数のサーバーで実行し、24時間7日オンライン状態を維持し、障害発生時に迅速に復旧する必要がある場合に役立ちます。オーケストレーション、スケーリング、監視、自己修復といった難しい部分をKubernetesが処理します。
開発環境から本番環境に移行するときは、両方を使用します。
多くのチームはDockerとKubernetesを併用しています。あなたもそうすることができます。その方法をご紹介します。
- Dockerを使用してコンテナを構築する
- コンテナレジストリにプッシュする
- Kubernetes を使用してステージングまたは本番環境でデプロイおよび管理する
このワークフローにより、ローカル開発からライブ環境までの一貫性が確保されます。
どちらか一方だけを使用することはできますか?
はい、チームの規模、インフラストラクチャ、目標によっては、それが理にかなっている場合もあります。
Kubernetes なしの Docker (Swarm)
Kubernetesがやり過ぎだと感じたら、 DockerSwarm コンテナをオーケストレーションするためのよりシンプルな代替手段です。Docker CLIに組み込まれており、小規模なチームやステージング環境に適しています。
一部のチームが依然として Swarm を使用する理由:
- クイックセットアップ: 数分で基本的なクラスターを形成できます。
- 使い慣れたツール: 同じ Docker CLI とイメージ形式を使用します。
- 十分なスケーリング: サービス検出、負荷分散、ローリング アップデートをサポートします。
しかし、SwarmにはKubernetesが提供する柔軟性、エコシステム、そしてマルチクラウドサポートが欠けています。そのため、現在では本番環境ではあまり普及していません。
KubernetesはDockerを使うのか？DockerなしのKubernetes（containerd）
Kubernetes v1.20以降、KubernetesはデフォルトのランタイムとしてDockerを使用しなくなりました。代わりに、containerdやCRI-Oなどのコンテナランタイムを使用します。これらはより軽量で効率的です。
これは次のことを意味します:
- Dockerでコンテナを構築できる
- Kubernetesは ドッカーエンジン 実行するには
- Dockerでビルドしたイメージはこれまでと同じように動作します
KubernetesとDockerは、KubernetesなしでもDockerプラットフォーム全体で並行して動作するようになりました。.
コンテナスタックを制御する
DockerとKubernetesは競合関係にありません。コンテナライフサイクルにおける、それぞれ異なるものの補完的な問題を解決します。
Docker はコンテナを素早く構築するのに役立ちます。Kubernetes はコンテナを大規模かつ確実に実行するのに役立ちます。
それぞれのコンテナ（または両方）をいつ使用するかを把握することで、インフラストラクチャに必要な制御と一貫性を確保できます。しかし、可視性がなければ、構築とスケーリングだけでは不十分です。コンテナが稼働したら、問題を早期に発見し、迅速に解決する必要があります。
ここで LogicMonitor が役立ちます。LogicMonitor はコンテナ化された環境全体の可観測性を統合し、チームが信頼性の高いサービスの提供に集中できるようにします。
© LogicMonitor 2025 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
