Kubernetes が Docker を放棄した後は何をすべきでしょうか?

最近、Kubernetes は最新の Changelog で、Kubernetes 1.20 以降では Docker がコンテナ ランタイムとして非推奨になることを発表しました。このニュースはクラウド ネイティブ分野で大きな騒ぎを引き起こし、Rancher 技術コミュニティの多くの友人たちもこれについて熱い議論を交わしました。

Kubernetes が Docker を放棄することを選択したのはなぜですか?まず、Dockershim について簡単に理解する必要があります。これは、Kubernetes と Docker の通信を支援するブリッジ サービスです。 Kubelet は以前、dockershim を使用して Docker の CRI サポートを実装していました (Docker 自体はまだ CRI を実装していません)。しかし、今日では、Dockershim の維持は運用者/開発者にとって大きな負担となっています。したがって、Kubernetes コミュニティでは、CRI の完全な実装 (v1alpha1 または v1 と互換性がある) を含む利用可能なコンテナ ランタイムの使用を検討することを推奨しています。これにより、コンテナ ランタイムとしての Docker のサポートが削除されます。

しかし、あまり心配する必要はありません。最近、Rancher コミュニティから、誰もが気になる質問をいくつか集めました。答えを一つずつ挙げます。

1. Kubernetes Kubelet はコンテナ ランタイムとして Docker を廃止しました。代替案はありますか?

Kubernetes クラスターでは、コンテナ ランタイムがコンテナ イメージのプルと実行を担当します。 Docker は、最も一般的に使用されているコンテナ ランタイムです。 Docker が廃止された後も、containerd と CRI-O という 2 つの一般的なオプションが残っています。

Containerd は、非常にシンプルで堅牢、かつ移植性に優れた業界標準のコンテナ ランタイムです。 Containerd はホスト内のコンテナのライフサイクル全体を管理できます。これは昨年 2 月に CNCF を卒業した 100% オープンソース ソフトウェアです。

昨年の初めに、Rancher は軽量の Kubernetes ディストリビューション K3s をリリースしました。これはすでに、デフォルトのコンテナ ランタイムとして containerd を使用していました。

コンテナ: https://github.com/containerd/containerd/

CRI-O は、OCI 準拠のランタイムと Kubelet の統合を提供することを目的として Red Hat がリリースしたコンテナ ランタイムです。この記事の後半では、コンテナランタイムを選択する際の参考として、containerd と CRI-O のパフォーマンスをさらに比較します。

CRI-O: https://github.com/cri-o/cri-o

2. Kubernetes 1.20 でも Docker を使用できますか?

はい、Docker をランタイムとして使用する場合、1.20 では Kubelet の起動時に警告ログのみが出力されます。 Kubernetes は、2021 年末にリリースされるバージョン 1.23 で dockershim を削除します。

3. 既存の Docker イメージは引き続き機能しますか?

まだ入手可能です。 Docker によって生成されるイメージは、実際には Docker 固有のイメージではなく、OCI (Open Container Initiative) イメージです。イメージの構築にどのツールを使用したとしても、OCI 準拠のイメージは Kubernetes にとって同じように見えます。 containerd と CRI-O はどちらもこれらのイメージを抽出して実行できます。したがって、コンテナ イメージの構築には引き続き Docker を使用できますし、containerd および CRI-O とともに引き続き使用することもできます。

4. どの CRI 実装を使用すればよいですか?

これは多くの要因に依存する、より複雑な質問です。すでに Docker に精通している場合は、containerd への移行は比較的簡単な選択であり、パフォーマンスが向上し、コストも低くなります。もちろん、CNCF スペース内の他のプロジェクトを調べて、自分の環境に適したものを選択することもできます。

出典: https://kubernetes.io/blog/202…i-use

eBay は、コンテナの作成、起動、停止、削除など、containerd と CRI-O で一連のパフォーマンス テストを実行し、かかった時間を比較しました。ご覧のとおり、containerd はコンテナの起動を除くすべての面で優れたパフォーマンスを発揮します。合計時間で見ると、containerd は cri-o よりも時間がかかりません。

eBay によって共有されるデータは次のとおりです。

Rancher、Alibaba Cloud、AWS、Google、IBM、Microsoft が初期メンバーであり、containerd コミュニティの構築に協力しています。 2017 年 3 月、Docker は containerd を CNCF (Cloud Native Computing Foundation) に寄贈しました。 Containerd は急速な開発と幅広いサポートを享受しています。 Docker エンジンは、コンテナ ライフサイクル管理の基盤として containerd を使用しています。 2018 年 5 月、Kubernetes はコンテナ ランタイム マネージャーとして containerd を正式にサポートしました。 2019 年 2 月、CNCF は、containerd が卒業し、より安定した本番環境対応プロジェクトになったことを発表しました。

5. Containerd の Rancher サポート

Rancher は、軽量 Kubernetes ディストリビューション K3s および RKE2 (2020 年 10 月にリリース) で、デフォルトのコンテナ ランタイムとして containerd を長い間使用してきました。 Rancher 2.x が Kubernetes 1.20+ をサポートした後、これらの貴重な経験が Rancher 2.x の新しいバージョンに適用されると信じています。

実際、Docker を放棄して Kubernetes に移行するという決定は長い間検討されてきたものであり、この点にあまり注意を払っていなかったエンジニアにとっては、少し意外なことかもしれません。しかし、あまり心配する必要はありません。Kubernetes のエンド ユーザーの場合、これはバックエンド コンテナー ランタイムの変更に過ぎず、使用上の違いはほとんど感じられません。開発者/オペレーターの場合は、引き続き Docker を使用してイメージを構築し、同じ方法でイメージをレジストリにプッシュし、これらのイメージを Kubernetes にデプロイすることができます。クラスターを実行・運用するユーザーであれば、必要なコンテナランタイムにDockerを切り替えるだけで済みます。