Docker なしで Kubernetes を使用できますか?

ゲッティイメージズ/iStockphoto

コンテナの出現により、現代の企業全体でソフトウェア開発とワークロード操作に刺激的な可能性が生まれました。 しかし、コンテナの人気の劇的な増加により、Docker などのエンジンでは処理できないコンテナ管理の問題が生じています。

Kubernetes などのプラットフォームは、自動化とオーケストレーションを通じてこれらの複雑なコンテナ管理の課題に対処します。 Kubernetes は、Docker Engine を含む多数のコンテナー ランタイムに対応する無料の効果的なプラットフォームです。

Docker と Kubernetes はどちらもコンテナ時代の初期に登場したため、この 2 つは長年にわたって密接に絡み合っており、同じ意味で参照されることもあります。 ただし、Docker と Kubernetes は補完的なものではありますが、IT 環境では異なる目的を果たす異なるタイプのツールです。

コンテナは、特殊なタイプの VM です。 他の VM と同様に、コンテナーはソフトウェアをパッケージ化して管理し、サーバー、ストレージ、ネットワークなどの基盤となるコンピューティング環境からソフトウェアを抽象化します。 この抽象化により、コンテナーと VM がコンピューティング環境間を簡単に移動できるようになります。

OS を含む VM とは異なり、コンテナーには、ランタイム、システム ツール、システム ライブラリ、対応する設定など、コンテナーのワークロードを実行するために必要なコードと依存関係のみが含まれます。 その結果、コンピューティング環境に関係なく、たとえ要件があったとしてもわずかな要件で実行できる、機敏でリソース効率の高いパッケージが得られます。

コンテナー内にパッケージ化されていない 2 つのコンポーネントは、OS とコンテナー エンジンです。 OS はコンテナ内で実行されるコードをサポートし、コンテナ エンジンはコンテナ自体のロードと実行の仕組みを処理します。

コンテナーが作成され、コンテナー イメージとして保存されます。 コンテナーを呼び出すと、イメージ ファイルがコンテナー エンジンにロードされ、イメージが実行中のコンテナーに事実上変更されます。 このパッケージ化と抽象化により、コンテナはほぼすべてのインフラストラクチャ上で同じように実行されます。

コンテナ エンジンは、コンテナの読み込み、実行、管理に必要なソフトウェア プラットフォームまたはレイヤーです。 コンテナ エンジンは、VM 内のハイパーバイザと同じレイヤーを占有するため、ハイパーバイザまたはコンテナ用の OS と呼ばれることがよくあります。

Docker は、いくつかの人気のあるコンテナ エンジンの 1 つです。 Docker または別のコンテナー エンジンがコンピューター上で利用可能になると、システムはコンテナー エンジン層の上にコンテナーを読み込んで実行できます。

Docker は次の主要な機能を提供します。

Docker を含むコンテナ エンジンの中心はコンテナ ランタイムです。 コンテナー ランタイムは、コンテナーの読み込みと実行という重労働を実行するだけでなく、コンテナーの名前空間と cgroup または論理 OS 構造の実装も行います。

containerd、CRI-O、runC、Mirantis Container Runtime など、多数のコンテナ ランタイムが利用可能です。 一部のランタイムには、コンテナーの解凍、管理、イメージ共有などの高レベルの機能が組み込まれています。 開発者がランタイムと直接対話するソフトウェアを作成できるようにする API も提供するものもあります。

コンテナは使いやすく、コンピューティングの占有面積が比較的小さいため、非常に人気があります。 エンタープライズ サーバーは、ビジネス用のアプリケーションやサービスを構成する数十、場合によっては数千のコンテナをホストできます。

しかし、多くのコンテナーの数が多く、ライフサイクルが短いため、大規模で動的なコンテナー フリートを手動で展開して管理する必要がある IT 管理者にとって、深刻な課題が生じています。 コンテナーのデプロイメントを調整し、リアルタイムで管理を実行するには、高度に自動化されたツールが必要です。

これは、K8s と略されることもある Kubernetes プラットフォームの役割です。 もともと Google によって開発された Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を処理するオープンソースの自動化およびオーケストレーション ツールです。 Kubernetes を使用すると、IT 管理者はコンテナベースのアーキテクチャに必要なほとんどのタスクを整理、スケジュール、自動化できます。

確かに、利用可能なコンテナ自動化およびオーケストレーション プラットフォームは Kubernetes だけではありません。 たとえば、Docker には Docker Swarm と呼ばれる独自のツールがあります。 クラウド プロバイダーは、Azure Kubernetes Service や Amazon Elastic Kubernetes Service などのマネージド Kubernetes サービスも提供しています。 他のサードパーティの代替手段には、SUSE Rancher や HashiCorp Nomad などがあります。

Kubernetes の広範な機能、低価格、広範なコンテナー ランタイムのサポートと拡張性により、主要な自動化およびオーケストレーション プラットフォームとしての地位を確立しました。 Kubernetes の主な機能には次のものがあります。

Kubernetes のすべての機能の中で、コンテナのサポートと拡張性が最も強力です。 これらの特性により、Kubernetes は、containerd、CRI-O、およびその他の Kubernetes Container Runtime Interface (CRI) 実装を含む、さまざまなコンテナ ランタイムと相互運用できます。

さらに、Kubernetes は、Kubernetes 用のオープンソース ツールのエコシステム全体を生み出す API を提供します。 これらには、Istio サービス メッシュと Knative サーバーレス コンピューティング プラットフォームが含まれます。

Docker と Kubernetes は関連していますが、この 2 つは IT 環境内で個別に展開および管理される別個のインフラストラクチャ ツールです。 具体的には、Docker はコンテナ エンジンです。つまり、仮想化されたコンテナがロードされて実行されるソフトウェア層またはプラットフォームです。 対照的に、Kubernetes は自動化およびオーケストレーションのプラットフォームであり、コンテナー間の関係を整理および管理するソフトウェア ツールです。

Kubernetes 開発の初期段階では、Docker が圧倒的に有力なコンテナ エンジンであり、そのコンテナ ランタイムのサポートは、dockershim と呼ばれる Kubernetes コンポーネントの形式で Kubernetes にハードコードされていました。 シムとは、追加の機能を提供するためにデータ フローを遮断および変更するソフトウェアの変更を指します。

dockershim コンポーネントにより、Kubernetes は、Docker が CRI 互換のランタイムを使用しているかのように Docker と対話できるようになりました。 Kubernetes が進化するにつれて、追加のコンテナ ランタイムが受け入れられ、あらゆるコンテナ ランタイムが標準化された方法で Kubernetes と相互運用できるように CRI が発明されました。 最終的に、dockershim によってもたらされる依存関係は、さらなる Kubernetes 開発を妨げるレガシーな問題になりました。

2022 年初頭の Kubernetes 1.24 のリリースに伴い、現在 Kubernetes の管理者および開発者である Cloud Native Computing Foundation は、dockershim コンポーネントを非推奨にすることを決定しました。 Kubernetes の開発者は、dockershim を排除することで、標準化されたランタイムを優先して従来のサポートを削除し、プロジェクトのコードを合理化および簡素化することを意図していました。

Kubernetes プロジェクトでは dockershim が非推奨になりましたが、Docker コンテナは引き続き Kubernetes で動作し、docker build コマンドで生成されたイメージはすべての CRI 実装で引き続き動作します。 ただし、dockershim を削除すると、Docker ユーザーにいくつかの潜在的な問題が生じます。

dockershim に依存している Docker ツールと UI は動作しなくなる可能性があります。 同様に、コンテナー ランタイムでスケジュールされたコンテナーは Docker から認識されなくなり、docker ps または docker Inspection コマンドを使用した情報の収集は機能しなくなります。

コンテナーがリストに表示されなくなったため、管理者はログを取得したり、コンテナーを停止したり、docker exec を使用してコンテナー内で何かを実行したりすることができません。 また、管理者は引き続き docker build を使用してイメージをプルまたはビルドできますが、それらのイメージはコンテナー ランタイムと Kubernetes には表示されません。

これらの問題を考慮すると、Docker ユーザーには 2 つの主な選択肢があります。

1 つ目は、これまでと同様に Docker を使い続けることです。 既存のコンテナは動作します。Mirantis と Docker はどちらも、Kubernetes によって dockershim が非推奨になった後も dockershim を維持することにコミットしているため、ユーザーは当面は適切な dockershim コンポーネントにアクセスできるようになります。

2 つ目は、containerd や CRI-O などの CRI 準拠のコンテナー ランタイムを使用する別のコンテナー エンジンに移行することです。 幅広いコンテナ プロジェクトとツールは両方のランタイムを使用しており、クラウド プロバイダーがサポートするコンテナ エンジンと Kubernetes バージョンはすべて CRI に準拠しています。 コンテナ インフラストラクチャとプロバイダーがサポートする Kubernetes バージョンをクラウドで実行している企業は、dockershim の非推奨の影響を直接受けるべきではありません。

現在、他のコンテナ エンジンや自動化およびオーケストレーション ツールがコンテナ化された環境でシェアを獲得しつつあります。 シンプルな低レベルのランタイムからフル機能のクラウドネイティブ プラットフォームまで、さまざまな製品が提供されています。

同様に、IT リーダーは、増大する自動化およびオーケストレーション プラットフォームのリストから選択して、膨大なコンテナ フリートを編成および管理できます。 Kubernetes の代替案は、多くの場合 Kubernetes のオープン ソース コードに基づいており、クラウドベースのオプションとサードパーティのオプションが含まれます。

コンテナ エンジンまたは自動化およびオーケストレーション プラットフォームの選択は、コスト、複雑さ、パフォーマンス、安定性、機能セット、セキュリティ、相互運用性などの要素によって決まります。 他の重要なインフラストラクチャの選択と同様に、ツールの組み合わせをテストして評価し、それらが技術要件とビジネス要件を満たしていることを確認します。

交換が必要ですか? これらの 5 つの Docker 代替案を試してください