KubernetesとDockerの比較：適切なコンテナソリューションを選ぶ方法

Kubernetesは、クラス最高のコンテナオーケストレーションソリューションであり、Dockerは、最も広範に使用されているコンテナ化プラットフォームです。代替ソリューションとして比較されることが多いものの、これらは直接的な競合企業ではありません。Dockerはコンテナ技術のプラットフォームであり、KubernetesはDockerなどのプラットフォームのためのコンテナオーケストレーターです。実のところ、KubernetesはDockerなどのコンテナランタイムに依存して機能することが多く、両者は互いを補完する技術となっています。

それでは、DockerとKubernetesの違いとはどのようなものなのでしょうか？この記事では、KubernetesとDockerの関係を分析し、一般的な誤解を解き、これらの比較が持つ意味を説明します。

KubernetesとDockerの比較：コンテナ化を理解するということ 

Dockerについて語るには、まずコンテナについて知る必要があります。 

コンテナは、アプリケーション開発における重大な問題を解決するものです。開発者は、コードを記述する際、独自のローカル開発環境で作業を行います。しかし、このコードを本番環境にて稼働させるにあたり、さまざまな問題が発生します。マシン上では完璧に動作したコードが、オペレーティングシステムや依存関係、ライブラリの違いにより本番環境では稼働しない、という事態が発生するかもしれないのです。  

複数のコンテナが移植性に関する重大な問題の解決に成功し、現在ではコードとそれを実行する基礎インフラストラクチャの分離が可能となっています。開発者は、（正しい実行のために必要なすべてのbinとライブラリを含む）アプリケーションを小さなコンテナイメージにパッケージ化することができるようになったのです。本番環境では、コンテナ化プラットフォームを備えたすべてのコンピュータでこのコンテナを実行することが可能です。

仮想マシンの代わりにコンテナを使用すべき理由

コンテナおよびコンテナプラットフォームの管理には、従来の仮想化よりも多くの利点があります。 

コンテナのフットプリントはごくわずかなものとなっています。必要となるのは、アプリケーションと、実行に必要なすべてのbinおよびライブラリの定義のみです。1つ1つがゲストオペレーティングシステムの完全なコピーを持つ仮想マシン（VM）とは異なり、コンテナはゲストオペレーティングシステムを必要とせず、カーネルレベルにて分離を行います。 

コンテナイメージレイヤーのキャッシュおよび再利用により、類似するコンテナはディスクにおける依存関係の重複を防ぐことができるため、イメージの肥大化を軽減したり、スペースを節約したりすることが可能となります。例として、3つのアプリケーションがすべてNodeとExpressで実行される場合において、フレームワークの個別インスタンスを3つ持つ必要はなくなります。これは、コンテナがインスタンス間でこれらのbinとライブラリを共有することができるためです。  

アプリケーションを自己完結型の環境にカプセル化することで、より迅速なデプロイメントや、デプロイメント環境間における整合性の向上、そして無限のスケーラビリティが実現するのです。

Dockerとは

Dockerは、現在最も人気のあるコンテナ技術であり、サイト信頼性エンジニア（SRE）や、DevOpsおよびDevSecOpsチーム、開発者、テスター、そしてシステム管理者により広範に使用されています。 

現在におけるDockerの市場独占には、適切なタイミングで市場に登場したこと、そして初期段階からオープンソースであったことが影響していると考えられます。Flexera発表の2023 State of the Cloudレポートからは、企業の39%がAWS環境でDockerを使用しており、その数が増加を続けていることがわかります。 

Dockerの主な機能

Dockerについて語るとき、多くの人はコンテナの構築と実行を可能にするランタイム、Docker Engineに焦点を当てます。しかし、Dockerコンテナは、実行の前に構築する必要があり、これはDockerfileから始める必要があります。 

• Dockerfile：Dockerfileは、ベースOSやインストール済みパッケージ、ファイルパス、公開ポートなど、コンテナイメージの構築に必要なすべてのものの定義を行います。
• Dockerイメージ：実行を行うコンテナを作成するために使用される、移植可能な静的ブループリントを指します。Dockerfileが揃ったら、Dockerイメージの構築を開始し、最終的にDocker Engine上で実行することができます。
• Docker Hub：イメージを共有し、再利用するためのパブリックレジストリを指します。

Kubernetesとは

Kubernetesは、極めれば極めるほど深みにはまってしまう性質を持っているものの、機能自体はきわめてシンプルです。Kubernetesは、Googleによって開発され、現在はCloud Native Computing Foundation（CNCF）が管理する強力なコンテナオーケストレーションプラットフォームです。このプラットフォームは、マシンのクラスター間におけるコンテナ化アプリケーションのデプロイメント、拡張、および管理の自動化を行います。

例として、Kubernetesはユーザーが決定したシステム表示（コンテナイメージAのコピーを3つとコンテナイメージBのコピーを2つ、など）を実現します。望ましい状態と実際の状態を比較した結果、これらの間に差異が生じる場合には、修正措置が講じられます。

Kubernetesは市場のリーダーであり、コンテナのオーケストレーションと分散アプリケーションのデプロイメントを行うための標準化された手段です。パブリッククラウドサービスとオンプレミスの両方で実行可能なこのプラットフォームは、高度なモジュール化が施されており、オープンソースであるほか、活発なコミュニティを擁してもいます。また、あらゆる規模の企業による投資を受けており、多くのクラウドコンピューティングプロバイダがサービスの一環としてKubernetesの提供を行っています。Sumo Logicは、Kubernetes搭載のアプリケーションを含む、すべてのオーケストレーション技術をサポートしています。

Kubernetesアーキテクチャの主要コンポーネント

Kubernetesは、互いを認識したり、気にかけたりしない多数のコンポーネントにより構成されています。これらのコンポーネントは、APIサーバーを介して相互通信を行います。各コンポーネントは独自の機能で動作し、後に監視を行うために収集できるメトリクスを公開します。コンポーネントは、大きく3つに分けることができます。

• コントロールプレーン：コントロールプレーン（マスターノード）は、APIサーバー、スケジューラ、コントローラマネージャなどのコンポーネントを介してクラスターアクティビティのオーケストレーションを行います。
• ノード：ワークロードを実行し、Kubernetesクラスターの総合的なコンピューティング能力を構成するマシン（物理または仮想）を指します。ノードは、コンテナが実行のためにデプロイされる場所であり、アプリケーションはこの物理的なインフラストラクチャ上で実行されます。
• ポッド：Kubernetesクラスター内でデプロイ可能な最小の単位で、多くの場合、単一のコンテナが含まれます。クラスターを定義する際、ポッドに制限が設定されることで、実行に必要なリソース（CPU、メモリ）が定義されます。スケジューラは、この定義を使用し、ポッドを配置するノードを決定します。ポッド内に複数のコンテナがある場合、必要なリソースを見積もることが困難になり、スケジューラはポッドを適切に配置できなくなります。

DockerとKubernetesの比較：両者の必要性の有無

KubernetesがなくてもDockerを使用することはできますが、Kubernetesの機能はDockerやcontainerd、CRI-Oなどのコンテナランタイムに依存します。多くの本番環境設定では、KubernetesとDockerの組み合わせが一般的です。

開発においては、Kubernetesを使用せずにDockerを使用することが一般的ですが、本番環境においては、Dockerを使用せずにKubernetesを使用する方法（別のコンテナランタイムを使用）が普及してきています。

Docker ComposeとKubernetesの比較

Docker ComposeとKubernetesは、両者ともコンテナオーケストレーションフレームワークです。これらの主な違いは、Kubernetesが複数の仮想、または実際のコンピュータ上でコンテナを実行できるのに対し、Docker Composeは単一のホストマシン上でしかコンテナを実行できないという点にあります。

KubernetesとDocker Swarmの比較

多くの人がKubernetesとDockerを比較するとき、それは実際にはKubernetesとDocker Swarmの比較となることが少なくありません。DockerのネイティブコンテナオーケストレーションツールであるDocker Swarmは、Dockerエコシステムに緊密に統合されており、独自のAPIを使用しているという利点があります。 

他の多くのスケジューラと同様、Docker Swarmには、サーバーのクラスター間で分散された大量のコンテナを管理する能力があります。そのフィルタリングおよびスケジューリングのシステムにより、クラスター内で最適なノードを選択してコンテナをデプロイすることが可能となります。

オーケストレーションシステムが重要となる理由

Dockerコンテナの普及は、次のような新たな疑問を生み出しました。

• 複数のコンテナを調整し、スケジュールするにはどうすればいいのか？ 
• ダウンタイムなしでアプリケーションをシームレスにアップグレードするにはどうすればいいのか？ 
• アプリケーションの健全性を監視したり、問題が発生したときにそれを認識してシームレスに再起動したりするにはどうすればいいのか？

KubernetesやMesos、Docker Swarmなどのコンテナオーケストレーションプラットフォームは、これらの課題を解決するために登場したのです。これらのツールは、マシンのクラスターを1台の大きなマシンのように動作させるものであり、この機能は大規模な環境では不可欠となっています。

実のところ、現実世界の本番環境において、大量のコンテナを管理するのは決して容易なことではありません。大量のコンテナには、次のことを実現するオーケストレーションシステムが必要となります。

• 同時に大量のコンテナとユーザーを処理する。アプリケーションでは、数千ものコンテナおよびユーザーが同時にインタラクションを行う可能性があるため、これらの管理においてはその目的専用に設計された包括的かつ全体的なシステムが必要となります。
• コンテナとユーザー間のサービス検出および通信を管理する。ユーザーはどのようにしてコンテナを見つけ、通信を維持することができるでしょうか？各マイクロサービスに対し、サービス検出を目的とした独自の組み込み関数を提供する方法は、繰り返しが多く、きわめて非効率的です。このような試みは、許容を超えた大規模な速度低下（またはグリッドロック）につながる可能性が高いといえるでしょう。
• 負荷を効率的に分散する。オーケストレーションが行われていないアドホック環境においては、コンテナレベルの負荷がその時点でのユーザー要件に大きく依存する可能性が高くなるため、サーバーレベルの負荷はきわめて不均衡なものとなってしまいます。ログジャムは、コンテナやシステムリソースの非効率的な割り当てや、可用性の制限に起因するものです。負荷分散により、このような混沌とした状態を秩序、そして効率的なリソース割り当てと置き換えることができるのです。
• 認証とセキュリティ。Kubernetesなどのオーケストレーションシステムにより、アプリケーションレベルではなくインフラストラクチャレベルで認証とセキュリティを処理し、すべてのプラットフォーム間で一貫したポリシーを適用することが容易になります。
• マルチプラットフォームデプロイメント。オーケストレーションでは、マルチプラットフォームおよびマルチクラウド環境におけるコンテナ操作やマイクロサービスの可用性、そして同期の調整などのきわめて複雑なタスクが管理されます。

コンテナベースのアプリケーションのための動的かつ包括的なインフラストラクチャとして機能するオーケストレーションシステムは、アプリケーションが外部世界とのインタラクションを管理しながら、保護された、そして高度に組織化された環境で動作することを可能とします。

Kubernetesは、そのモジュール式アーキテクチャと活発なコミュニティが功を奏し、現在ではコンテナオーケストレーションにおける主要な選択肢となっています。 

DockerとKubernetesの関係

KubernetesとDockerはどちらも、コンテナ化されたアプリケーションをインテリジェントに管理し、強力な機能を提供するための包括的なデファクトソリューションです。このことは多少の混乱につながっています。現在では、「Kubernetes」という単語がKubernetesをベースにしたコンテナ環境全体の略語として使用されることも少なくありません。しかし、実際にはこれらは異なるルーツを持ち、異なる問題のソリューションとなるため、直接比較することはできないのです。

Dockerとは、Dockerコンテナを構築、配布、および実行するためのプラットフォームおよびツールを指します。これには、Docker DesktopやDocker CLI、Docker Daemonなどのツールが含まれます。 

一方、Kubernetesは、Docker Swarmを上回るスケーラビリティによって大規模なノードのクラスターを調整する、Dockerコンテナ用のコンテナオーケストレーションシステムです。これは、Kubernetesエコシステムのスケジューリング単位（1つ以上のコンテナを含めることが可能）となるポッドの概念に基づき動作します。ポッドは高可用性実現のため、ノード間で分散されます。Kubernetesクラスター上でDockerビルドを実行することは難しくないものの、Kubernetes自体は完全なソリューションではなく、カスタムプラグインの併用を前提としています。

KubernetesとDockerは根本的に異なる技術ですが、連携させることで効果を発揮します。両者は、分散アーキテクチャにおけるコンテナの管理およびデプロイメントを容易にする、という共通点を持ち合わせています。

Kubernetesを使用せずにDockerを使用することができるかについて

Kubernetesを使用せずにDockerを使用することは珍しくありません。Kubernetesには多くの利点があるものの、このシステムは非常に複雑なことでも知られており、起動によるオーバーヘッドが不要、または望ましくないという状況が少なからず存在します。

開発環境では、Kubernetesなどのコンテナオーケストレーターを使用せずにDockerを使用するのが一般的です。また、本番環境においてコンテナオーケストレーターを使用するメリットは、それに起因する複雑さを上回るものではありません。AWS、GCP、およびAzureなどの多くのパブリッククラウドサービスでもいくつかのオーケストレーション機能は提供されているため、複雑さとのトレードオフは不要といえるでしょう。

Dockerを使用せずにKubernetesを使用することができるかについて

Kubernetesはコンテナオーケストレーターであるため、オーケストレーションを行うためにはコンテナランタイムが必要となります。Kubernetesは、Dockerとの併用が最も一般的ではあるものの、他のコンテナランタイムと併用することも可能です。Kubernetesでデプロイできる他のコンテナランタイムとしては、RunCやcri-o、containerdなどが挙げられます。CNCFは、エコシステムランドスケープのページにてサポートされているコンテナランタイムのリストを管理しており、Kubernetesの文書には、ContainerDとCRI-Oを使用して設定を行うための具体的な手順が記載されています。

まとめ：DockerとKubernetesの優れた相性

さて、最善の選択肢はどちらになるのでしょうか？これはひっかけ問題ではありません。答えはそう、「両方」なのです。

他のコンテナソースやランタイムと併用することも可能ではあるものの、KubernetesはDockerとの連携を想定して設計されており、関連文書の大部分はDockerとの併用を念頭に置いた内容となっています。 

これらの組み合わせは次のものを提供します。

• 信頼性が高く、繰り返しが可能なコンテナデプロイメント
• コンテナランタイムインターフェースの集中管理
• 自動化されたフェイルオーバーを備えた回復力のあるインフラストラクチャ
• 大規模なクラウドネイティブアプリケーションのサポート

「KubernetesかDockerか」ではなく「KubernetesとDocker」こそが求められる姿勢であり、今日においてこれはより明白なものとなっています。最新のコンテナ技術を扱うすべての企業チームにとって、DockerとKubernetesの併用は、分散アプリを構築および実行する上で最も堅牢かつスケーラブルな基盤が得られることを意味します。 

Sumo Logicの使用により、いかにKubernetesとDockerのパフォーマンスデータを実用的なインサイトに変えることができるかをご覧ください。30日間の無料トライアルを開始しましょう。