Kubernetes がどんどん遠ざかっていく中、Docker の将来はどうなるのでしょうか?

最近、Kubernetes が Docker を放棄するというニュースが業界で広く注目を集めています。 Kubernetes コミュニティからの指示によると、バージョン 1.20 以降、Kubernetes はコンテナ ランタイムとしての Docker の使用をサポートしなくなります。これを踏まえると、将来的にDockerが使えなくなるのではないかと心配する人が増えています。実際、これは Kubernetes が Docker を完全に放棄することを意味するものではありません。 CNCF もパニックにならないよう注意を促しています。 Docker によって生成されたイメージは、ユーザーのクラスター内のすべてのランタイムで引き続き動作します。しかし、この事件は依然として人々に疑問を抱かせます。Docker の将来はどうなるのでしょうか?長い間、コンテナといえばKubernetes + Dockerが標準と思われていましたが、今では必ずしもそうではないようです。

Kubelet は Docker ランタイムをサポートしなくなりました

Docker の将来に対する人々の懸念は、Kubernetes バージョン 1.20 の ChangeLog に、kubelet の Docker サポート機能が非推奨となり、以降のバージョンで削除される予定であると記載されているという事実に起因しています。コミュニティは、これを行った理由について、Kubelet は以前、dockershim というモジュールを使用して Docker の CRI サポートを実装していたが、Kubernetes コミュニティがそのメンテナンスに問題を発見したため、CRI の完全な実装を含む利用可能なコンテナ ランタイムの使用を検討することを推奨していると説明しました。

まず最初に注意すべきことは、ここで言及されている Docker ランタイムは、私たちがよく話題にする Docker とは異なるということです。これが、Docker が Kubernetes によって放棄されたと人々が考える理由かもしれません。ランタイムは、アプリケーションの動作を保証する環境です。これは通常、実行中に任意のプログラムから接続または呼び出すことができる再利用可能なプログラム/ライブラリまたはインスタンスです。 Kubernetes クラスター内には、コンテナ ランタイムと呼ばれるコンポーネントもあり、コンテナ イメージの抽出と実行を担当します。 Docker は現在最も人気のあるコンテナ ランタイムです。さらに、Containerd や CRI-O もあります。

ランタイムとして位置付けられる Containerd や CRI-O とは異なり、Docker には、コンテナの作成など、ランタイムに必要のない機能も多数統合されています。さらに、Docker はもともと Kubernetes に組み込むように設計されていませんでした。

kubelet は Docker のランタイムの使用をサポートするために妥協したと言えるでしょう。 Containerd と CRI-O ランタイムが使用される場合、呼び出しプロセスは次のようになります。kubelet は CRI-Container プラグインに呼び出し要求を送信し、CRI-Container はコンテナ ランタイムと通信して、要求されたさまざまな操作を完了します。ただし、Docker ランタイムを使用する場合は、このプロセスを変更する必要があります。 Docker ランタイムは CRI と互換性がないため、バッファーとして新しいプラグイン Dockershimi を導入する必要があります。この時点で、プロセスは次のようになります。まず、kubelet が Dockershimi にリクエストを送信し、Dockershimi が Docker ランタイムを呼び出し、Docker ランタイムが Containerd を呼び出します。Containerd は、要求されたさまざまな操作を完了する役割を担います。このプロセスにおける Docker ランタイムは少し扱いに​​くいことがわかります。これを追加することで、プロセスに余分なリンクが追加されるだけでなく、Dockershimi も導入されます。 Dockershimi の介入により新たな問題が発生しており、追加でメンテナンスを行う必要があります。そうしないと、セキュリティ上の問題が発生する可能性があります。

今日、Kubernetes コミュニティがますます強力になるにつれて、Kubernetes が Docker に対して行った妥協は継続されなくなり、そのため kubelet は Docker ランタイムをサポートしなくなりました。現時点では、この事件の影響は大きくありません。 CNCF が言ったように、Docker は消滅しません。 Docker は今後も無数のコンテナを構築し続けるでしょう。開発者は引き続き Docker を採用し、開発ツールとして Docker を使い続けることができます。 Docker によって生成されたイメージは、Kubernetes クラスター内で引き続き正常に実行できます。

GKE や EKS などのマネージド Kubernetes サービスなどのクラウド コンテナ サービスを使用している場合は、将来の Kubernetes バージョンで Docker サポートが完全に削除される前に、サポートされているコンテナ ランタイムがワーカー ノードに導入されていることを確認する必要があります。独自のクラスターを管理する場合は、サービスの中断を避けるために、必ずランタイムを更新して調整してください。バージョン 1.20 では、Docker の非推奨警告が表示されます。 Kubernetes の将来のバージョン (2021 年後半にリリース予定のバージョン 1.23) では、Docker ランタイムは完全に削除され、サポートされなくなります。

しかし、長期的にはどうでしょうか?

Docker の将来はどうなるのでしょうか?

Docker がコンテナの普及に大きく貢献したことは間違いありません。コンテナは Docker が登場する何年も前から存在していましたが、Docker が登場するまでは普及していませんでした。 2013 年に Docker が登場し、コンテナの実行が初めて非常に簡単になりました。 Docker を使用すると、開発者はコンテナを簡単に起動、停止、取り消しすることができ、学習曲線が緩やかで使いやすいため、ソフトウェア開発プロセスの主流となっています。

Docker は、比較的マイナーな技術であるコンテナを独力でインターネットの有名人に変えたと言えるでしょう。 Docker の人気により、Docker エコシステムが強化されました。 Docker プロジェクトを中心に、ネットワーク、ストレージ、監視、CI/CD、さらには UI プロジェクトが多数立ち上げられており、Rancher などのオープンソース スタートアップも数多く登場しています。同時に、競争の種も蒔かれました。

Docker は当初開発に重点を置き、市場を独占していましたが、Docker が今後も成長を続け、特に商業的価値を獲得するには、アプリケーションの展開と運用に重点を置き、展開、監視、管理のためのツールを提供する必要があります。 Swarm もその 1 つです。 CoreOS、Red Hat、Google、Microsoft などのアプリケーション ランタイム プラットフォーム プロバイダーにとって、コンテナーのサポートは厳格な要件ですが、コンテナー ランタイムを標準化することで Docker の影響を最小限に抑えたいと考えています。明らかに、Docker はそうすることを望んでいませんでした。特に、当時 Docker が非常に人気があったためです。これが両者間の論争の焦点です。

OCI 仕様の開始は、競合する 2 つの当事者間の妥協の結果です。 2015年、Dockerが先頭に立ってCoreOS、Google、RedHatなどの企業と共同で、Dockerが独自のコンテナランタイムライブラリLibcontainerを寄贈し、RunCプロジェクトに改名すると発表しました。その後、RunC をベースに、コンテナとイメージの一連の標準と仕様を全員が共同で開発しました。これはOCI（Open Container Initiative）です。 OCI の目的は、コンテナ ランタイムとイメージの実装を Docker プロジェクトから完全に分離し、他のメーカーが Docker プロジェクトに依存せずに独自のプラットフォームを構築できるようにすることです。

OCI は実際には Docker にほとんど影響を与えていません。特に、同じ年に設立された CNCF (Cloud Native Computing Foundation) と比較するとその影響は顕著です。この財団は、GoogleやRedHatなどのオープンソースインフラプレイヤーが立ち上げたもので、Dockerを中心としたコンテナビジネスエコシステムに対抗すべく、オープンソースインフラベンダーが主導し、独立した財団として運営されるKubernetesプロジェクトをベースにしたプラットフォームレベルのコミュニティを設立する準備を進めています。

両者の競争とは異なり、今回の競争はDockerが得意とする開発分野から離れ、アプリケーションの導入と運用、つまりPaaSレベルに重点が置かれており、まさにRed HatやGoogleなどが得意としている分野です。 Kubernetes は、得意分野であるコンテナ オーケストレーションから始まり、Docker をコンポーネントの 1 つとして採用しました。最初から戦略的に優位な立場にあったと言える。 Google が Borg で蓄積した高度な技術と、Red Hat などのオープンソース ソフトウェアの運用経験の助けを借りて、Kubernetes はすぐに競争でリードし始めました。

もちろん、この競争は最初は穏やかなものでした。 Kubernetes が 2014 年に誕生したとき、当時最も人気のあるコンテナ ランタイムが Docker だったため、Kubernetes では Docker が使用されました。当時は、Docker + Kubernetes に加えて、Docker + Mesos や Docker + Swarm も選択できました。

Kubernetes と Docker は直接競合するわけではないと言えます。直接的な競合相手は Docker の Swarm です。 Swarm は、Kubernetes と同様に機能するクラスタリングおよびスケジューリング ツールです。しかし、Swarm と Kubernetes の競争は本質的にはコンテナに関する発言権をめぐる競争であり、したがって本質的には Docker と CNCF の競争です。

Docker は Kubernetes に対抗するために、2016 年に Swarm プロジェクトを放棄し、すべてのコンテナ オーケストレーションとクラスター管理機能を Docker プロジェクトに統合すると発表しました。 Docker は、現時点で Swarm プロジェクトの唯一の競争上の優位性は Docker プロジェクトとのシームレスな統合であることを認識しています。しかし、この動きはうまくいかなかったようで、Docker はすぐに CNCF との競争に負けました。 2017 年 10 月の DockerCon EU カンファレンスで、Docker は Kubernetes のサポートを正式に発表し、Kubernetes プロジェクトを主力製品である Docker Enterprise Edition に組み込むことを発表した。これは、コンテナ オーケストレーションの分野での競争が終了し、Kubernetes が認知されたことを意味します。

振り返ってみると、敗北した Docker は強力なコンテナ開発者エコシステムに依存することで依然として影響力を発揮することができ、それが kubelet による妥協と Dockershimi の導入につながりました。しかし、時が経つにつれて、Kubernetes コミュニティはますます強力になり、Kubernetes エコシステムはますます完成し、Docker の発言力は徐々に低下し、疎外されるのも当然です。 Kubelet が Docker の特別扱いを取り消すのは時間の問題です。そのため、今後もDockerは開発分野において独自の価値を発揮し続ける可能性が高いでしょう。

しかし、いずれにせよ、Docker は 2013 年に正式にリリースされて以来、コンテナ技術を単独で普及させ、ソフトウェア業界に破壊的な変化をもたらし、ソフトウェア業界と IT 業界全体の発展と革新を促進してきました。この観点から見ると、Docker は当然の英雄であり、たとえ失敗したとしても私たちの尊敬を勝ち取るはずです。