Mirantis社はKubernetesのdockershimサポートを引き継ぎます #kubernetes #k8s #cri #docker
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本稿は Mirantis to take over support of Kubernetes dockershim の翻訳です。
dockershimが終了するという噂が誇張されて広まっているようです。Kubernetesエコシステムに関するニュースを日々追いかけている方は、まもなくリリースされるKubernetes 1.20からdockershimが非推奨となり、将来のリリースで削除されるという警告を受けるようになるという発表に驚いているかもしれません。多くの人々がパニックを起こしかけているかもしれませんが、どうかご安心ください。すべて問題ありません。
しかもよいニュースもあります。Mirantis社とDocker社は提携して、Docker Engine API用のCRIに適合したインターフェイスとしてのshimコードを、Kubernetesから切り離して別個にメンテナンスすることに合意しました。Mirantis社のお客様にとって、これはDocker Engineの商用サポート版であるMirantis Container Runtime (MCR)がCRIに準拠するようになることを意味します。Davanum Srinivas氏が開発した素晴しい初期のプロトタイプである https://github.com/dims/cri-dockerd から始め、オープンソースプロジェクトとして https://github.com/Mirantis/cri-dockerd にて利用可能な状態にしていきます。つまり、組み込みのdockershimを外部のdockershimに切り替えるだけで、これまで通りDocker Engine上にKubernetesを構築できるということを意味します。Mirantis社とDocker社は、すべての適合テストに合格し、dockershim組み込み版と同じように動作し続けることを保証するために今後も協力していきます。このdockershimをMirantis社はMirantis Kubernetes Engine (旧称:Docker EnterpriseおよびUniversal Control Plane)で、Docker社はDocker Desktopで、引き続き搭載していきます。
ことの起こり
Kubernetesを使用している方は、Kubernetesがコンテナをオーケストレーションするものであることをご存知だと思います。多くの人にとって「コンテナ」は「Docker」を意味していますが、厳密にはそうではありません。Dockerはコンテナに革命を起こし、コンテナが広く一般的に使われるきっかけとなりました。そしてDocker Engineは、Kubernetesがサポートする最初の（そして当初は唯一の）コンテナランタイムとなりました。
しかしそれはKubernetesコミュニティの長期計画ではありませんでした。
長期的には、Kubernetesコミュニティは多くのさまざまな種類のコンテナ(rktを覚えていますか?)を実行できる機能を求めていました。そして、コンテナエンジンがKubernetesと通信するための標準的な方法であるContainer Runtime Interface (CRI)を作成しました。コンテナエンジンがCRIに準拠していれば、余計な手間をかけずにKubernetesで動作させることができます。
初めてCRIに準拠したコンテナエンジンはcontainerdで、これはまさにDocker社の努力の結晶です。ご存知のように、Dockerは単なるコンテナランタイムではありません。ユーザインターフェイスのような、人間が利用するためのその他の機能も有しています。そこで、Docker社はコンテナランタイムとして必要な部分のみをcontainerdとして切り出し、それは最初のCRI準拠のランタイムとなりました。その後、Docker社はcontainerdをCloud Native Computing Foundation (CNCF)に寄贈しました。cri-containerdコンポーネントはランタイムに依存せず、Windowsだけでなく複数のLinux OSをサポートしています。
しかし、もう1つ問題が残っていました。DockerそのものはまだCRIに準拠していなかったのです。
dockershimとは？
KubernetesはDocker Engineを組み込みでサポートしていたのと同じように、さまざまなストレージボリュームソリューション、ネットワークソリューション、さらにはクラウドプロバイダーを組み込みでサポートしていました。しかし、これらを継続的にメンテナンスするのはあまりにも大変になってきたので、KubernetesコミュニティはサードパーティのソリューションをすべてKubernetesのコアから取り除き、次のようなインターフェイスを作成することにしました:
- Container Runtime Interface (CRI)
- Container Network Interface (CNI)
- Container Storage Interface (CSI)
このアイディアにより、これらのインターフェイスに準拠していれば、どのベンダーでも自動的にKubernetesと通信できる製品を作ることができるようになりました。
これは準拠していないコンポーネントがKubernetesで使えないということではなく、Kubernetesは適切なコンポーネントであれば何でもできるということを意味します。すなわち、非準拠のコンポーネントは「shim」という、Kubernetesの関連コンポーネントとの仲介をするものが必要であるということです。例えば、dockershimはCRIコマンドを受け取り、それをDocker Engineが理解できるものに変換します。またその逆の変換も行います。しかし、このようなサードパーティ製のコンポーネントをKubernetesのコアから取り外そうという動きに伴い、dockershimは削除せざるを得なくなりました。
これは大変なことに聞こえるかもしれませんが、みなさんが思っているほど深刻ではありません。例えば、docker buildコマンドによってビルドしたイメージはCRIの標準仕様に準拠しているため、これまで通りKubernetes上で動作します。
Kubernetesの組み込みdockershimが非推奨になった今、どうなるのでしょうか？
多くの人々にとって、dockershimが非推奨になっても問題ではありません。なぜなら、実際にはDockerそのものを使っているわけではなく、CRIに準拠しているcontainerdを使っているからです。そのような人々にとっては何も変わらないでしょう。
しかし、多くのMirantis社のお客様を含め、Kubernetesとシームレスに連携するために、dockershimに依存したワークロードを実行している方もいらっしゃいます。
今でも多くの企業にとって必要なコンポーネントであることから、Mirantis社とDocker社は、スタンドアロンのオープンソースコンポーネントとしてdockershimのサポートと開発を継続することに合意しました。
では、これは実際に何を意味するのでしょうか？
containerdを直接利用しているなら、まったく心配する必要はありません。containerdはCRIに準拠しているからです。もしあなたがMirantis社のお客様なら、同じく心配する必要はございません。dockershimサポートを含んだMirantis Container Runtimeは、CRIに準拠します。
一方、オープンソース版のDocker Engineを利用しているなら、dockershimプロジェクトがオープンソースコンポーネントとして利用可能になり、KubernetesでDocker Engineを使い続けることができるでしょう。ただ、これには少しの設定変更が必要になるので、ドキュメントを作成する予定です。
今回の出来事は多くの人々に衝撃を与えたかもしれませんが、一人として寒空の下に放置された人はいません。
