Kubernetes と Docker: 両方使用しないのはなぜですか?

コンテナは、アプリケーション コードとその依存関係をパッケージ化し、あらゆる IT インフラストラクチャで実行できるようにするソフトウェアの実行可能単位です。コンテナは単独で動作します。LinuxはホストOS（通常はLinux）から切り離されているため、IT環境全体で移植できます。

コンテナの概念を理解する 1 つの方法は、コンテナを仮想マシン (VM)と比較することです。どちらも仮想化テクノロジーに基づいていますが、コンテナが OS を仮想化するのに対し、VM はハイパーバイザー(VM とコンピューターのハードウェアの間にある軽量ソフトウェア レイヤー) を活用して物理ハードウェアを仮想化します。

従来の仮想化では、各 VM にはゲスト オペレーティング システム (OS) の完全なコピー、OS とアプリケーション (および関連するライブラリと依存関係) を実行するために必要なハードウェアの仮想コピーが含まれています。一方、コンテナには、アプリケーションとそのライブラリ、依存関係のみが含まれます。ゲスト・ホストがないため、コンテナのサイズが大幅に縮小され、軽量化、高速化、ポータブル化されます。さらに、コンテナはホストの DNS 設定を自動的に使用します。

エンジニアはコンテナを使用して、多数の分散システムやクロスプラットフォーム環境で一貫して実行されるアプリケーションを迅速に開発できます。コンテナの移植性により、機能チーム間のツールやソフトウェアの違いから生じる競合の多くが解消されます。

このためDevOpsワークフローに特に適しており、開発者とオペレーションが環境間で連携しやすくなります。小型で軽量なコンテナは、アプリケーションが疎結合された小さなサービスで構成されるマイクロサービスアーキテクチャにも最適です。また、コンテナ化は、多くの場合、オンプレミスのアプリケーションをモダナイズし、クラウド・サービスと統合するための最初のステップです。

Docker はオープンソースのコンテナ化プラットフォームです。基本的には、開発者がコンテナをより簡単かつ安全に、そして迅速に構築、デプロイ、管理できるようにするツールキットです。このツールキットは、containerdとも呼ばれます。

Dockerはオープンソース・プロジェクトとして始まりましたが、現在では商用Docker製品を製造するDocker, Inc.も指します。現在、開発者が Windows、Linux、MacOS を使用しているかどうかにかかわらず、コンテナを作成するための最も人気のあるツールです。

実際、コンテナ・テクノロジーは2013年にDockerがリリースされる何十年も前から利用できました。初期には、Linuxコンテナ（LXC）が最も普及していました。DockerはLXC上に構築されましたが、Dockerのカスタマイズされたテクノロジーにより、すぐにLXCを追い越し、最も人気のあるコンテナ化プラットフォームになりました。

Docker の主な属性の中には、移植性があります。Docker コンテナは、あらゆるデスクトップ、データセンター、クラウド環境で実行できます。各コンテナでは1つのプロセスのみを実行できるため、アプリケーションの一部が更新中または修復中である間も、アプリケーションを継続的に実行できます。

Dockerで一般的に使用されるツールや用語には、次のようなものがあります。

• Docker Engine： 開発者がコンテナを構築および実行できるようにするランタイム環境。
• Dockerファイル： OSネットワーク仕様やファイルの場所など、Dockerコンテナ・イメージの構築に必要なすべてを定義したシンプルなテキスト・ファイル。これは基本的に、Docker Engineがイメージを組み立てるために実行するコマンドのリストです。
• Docker Compose: 複数コンテナのDockerアプリケーションを定義して実行するためのツールです。アプリケーションに含まれるサービスを指定するYAMLファイルを作成し、Docker CLIを介して1回のコマンドでコンテナをデプロイして実行できます。

ここで、Kubernetesがコンテナ・ランタイムとしてのDockerのサポートを停止した理由を再確認してみましょう。このセクションの上部で述べたように、Dockerはcontainerdであり、コンテナ・ランタイムではありません。これは、Dockerが基盤となるコンテナ・ランタイム上に配置され、ユーザー・インターフェースを通じてユーザーに機能とツールを提供することを意味します。KubernetesはDockerをランタイムとしてサポートするために、Docker Shimと呼ばれる別のランタイムをサポートして実装する必要がありました。このランタイムは基本的に2つのテクノロジーの間に位置し、通信を支援しました。

これは、利用可能なコンテナ・ランタイムがあまりなかった時代に行われました。しかし、CRI-Oなど多くのコンテナ・ランタイムが存在する現在、Kubernetesはユーザーに多くのコンテナ・ランタイム・オプションを提供することができ、その多くはKubernetesとコンテナの中間層を介さずに確実に通信するためのランタイムです。

ただし、KubernetesはランタイムとしてのDockerに対する特別なサポートを提供しなくなりましたが、Dockerは引き続き、Dockerfileの使用やDockerイメージのビルドを可能にするDocker独自のイメージ・フォーマットであるOpen Container Initiative（OCI）で構築されたコンテナを実行および管理することができます。言い換えれば、Kubernetesエコシステムにおいて、Dockersにはまだ多くのメリットがあるということです。

Dockerコンテナ化プラットフォームは、以下のような、前述のコンテナのメリットをすべて提供します。

• 軽量の移植性： コンテナ化されたアプリケーションは、任意の環境から別の環境（Dockerが動作している場所ならどこでも）に移動でき、OSに関係なく動作します。
• アジャイル・アプリケーション開発： コンテナ化により、CI/CDプロセスの採用やDevOpsなどのアジャイル手法の活用が容易になります。たとえば、コンテナ化されたアプリをある環境でテストし、急速に変化するビジネス需要に応じて別の環境にデプロイできます。
• 拡張性： Dockerコンテナは迅速に作成でき、複数のコンテナを効率的かつ同時に管理できます。

その他のDocker API機能には、コンテナ・イメージの自動的な追跡とロールバック、既存コンテナを新しいコンテナを構築するためのベース・イメージとして使用する機能、アプリケーションのソースコードに基づいてコンテナを構築する機能が含まれます。Dockerは、Docker Hubを介してインターネット全体で何千ものコンテナを共有する、活気のある開発者コミュニティに支えられています。

しかし、Dockerは小規模なアプリケーションには適していますが、大規模なエンタープライズ・アプリケーションには、膨大な数のコンテナ（場合によっては数百、数千）が含まれる場合があり、コンテナの管理を担当するITチームにとっては圧倒されるものになります。そこで役立つのが、コンテナ・オーケストレーション です。Dockerには独自のオーケストレーション・ツールであるDocker Swarmがありますが、現在のところ最も人気があり堅牢なオプションはKubernetesです。

Dockerには、コンテナの作成と実行に使用されるいくつかのコマンドがあります。

• docker build ：このコマンドは、ソースコード（つまり、Dockerfileと必要なファイルから）から新しいDockerイメージを構築します。
• docker create ：このコマンドは、イメージを開始せずにイメージから新しいDockerイメージを作成します。これには、イメージ上に書き込み可能なコンテナ・レイヤーを作成し、それを準備することが含まれます。
• docker run ：このコマンドは、docker create コマンドとまったく同じように動作しますが、作成後に「実行」という追加のステップがある点で異なります。
• docker exec ：このコマンドは、すでに実行されているコンテナ内で新しいコマンドを実行するために使用されます。

Kubernetes は、コンテナ化されたアプリケーションの展開、管理、スケーリングをスケジュール設定し、自動化するためのオープンソースのコンテナ・オーケストレーション・プラットフォームです。コンテナは、「クラスター」と呼ばれる複数のコンテナ・アーキテクチャーで動作します。Kubernetesクラスターには、クラスター内の残りのコンテナ（またはワーカー・ノード）のワークロードをスケジュールするコントロール・プレーンとして指定されたコンテナが含まれています。

マスター・ノードは、アプリケーション（またはDockerコンテナ）をホストする場所を決定し、それらをまとめる方法を決定し、オーケストレーションを管理します。Kubernetesは、アプリケーションを構成するコンテナをクラスターにグループ化することで、サービスの検出を容易にし、ライフサイクル全体にわたって大量のコンテナを管理できるようにします。

Googleは2014年にKubernetesをオープンソース・プロジェクトとして導入しました。現在は、Cloud Native Computing Foundation（CNCF）と呼ばれるオープンソースソフトウェア基盤によって管理されています。本番環境でのコンテナ・オーケストレーション向けに設計されたKubernetesは、堅牢な機能、何千人もの貢献者を擁する活発なオープンソース・コミュニティ、主要なパブリッククラウド・プロバイダー（IBM Cloud、Google、Azure、AWSなど）間でのサポートと移植性により人気が高まっています。

• 自動デプロイメント： Kubernetesは、複数の計算ノード（VMまたはベアメタルサーバー）にわたるコンテナのデプロイメントをスケジュールし、自動化します。
• サービス検出と負荷分散:コンテナをインターネット上に公開し、トラフィックの急増が発生したときに負荷分散を採用して安定性を維持します。
• オートスケーリング機能: CPU使用率、メモリーしきい値、メトリクスのどれに基づいていても、新しいコンテナを自動的に起動して高負荷を処理します。
• 自己修復機能：Kubernetesは、コンテナが失敗したりノードがなくなったりしたときに、コンテナの再起動、置き換え、スケジュール変更を行い、ユーザー定義のヘルスチェックに応答しないコンテナを強制終了します。
• 自動ロールアウトとロールバック: アプリケーションの変更をロールアウトし、アプリケーションの正常性を監視して問題がないか監視し、何か問題が発生した場合は変更をロールバックします。
• ストレージオーケストレーション： 必要に応じて選択した永続的なローカルまたはクラウドのストレージシステムを自動的にマウントし、レイテンシーを短縮し、ユーザーエクスペリエンスを向上させます。
• 動的ボリューム・プロビジョニング：クラスター管理者は、ストレージ・プロバイダーに手動で呼び出しを行ったり、オブジェクトを作成したりすることなく、ストレージ・ボリュームを作成できます。

KubernetesとDockerは別のテクノロジーですが、高度に補完的な関係にあり、強力な組み合わせを実現しています。Dockerはコンテナ化を提供し、開発者がコマンドラインを介してアプリケーションを小さな分離されたコンテナに簡単にパッケージ化できるようにします。開発者は、互換性の問題を気にすることなく、IT環境全体でこれらのアプリケーションを実行できます。アプリケーションがテスト中に単一ノード上で実行される場合、そのアプリケーションはどこでも実行されます。

需要が急増すると、KubernetesはDockerコンテナのオーケストレーションを提供し、IT環境全体でスケジュールして自動的にデプロイして高可用性を確保します。Kubernetesには、コンテナの実行だけでなく、ロード・バランシング、自己修復、自動ロールアウトとロールバックなどのメリットがあります。さらに、グラフィカル・ユーザー・インターフェイスにより、使いやすさが向上しています。

将来的にインフラストラクチャーの拡張を予想している企業にとって、最初からKubernetesを使用することは理にかなっていると言えます。また、すでにDockerを使用している企業にとっては、Kubernetesは既存のコンテナとワークロードを活用しながら、拡張に伴う複雑な問題を解決します。

最近のバージョンのDockerには、Kubernetesとの統合が組み込まれています。この機能により、開発チームは、Dockerを活用して構築したすべてのコンテナ化されたアプリケーションをより効果的に自動化し、管理できるようになります。

最終的には、ビジネス目標を達成するためにどのようなツールの組み合わせが必要かという問題です。Kubernetes チュートリアルで開始方法を確認し、IBM Cloud Kubernetes Service を調べて詳細を学んでください。

IBM CloudLabsの無料ブラウザベースの Kubernetes チュートリアルを通じてバッジを獲得します。