Kubernetes と Docker の分離があなたにとって何を意味するか

この瞬間が来るまで長い時間がかかりました。 Kubernetes はバージョン 1.20 以降、コンテナ ランタイムとしての Docker を非推奨にし、Kubernetes 用に作成された Container Runtime Interface (CRI) を使用するランタイムに切り替えました。ただし、これは Docker の終焉を意味するものではなく、お気に入りのコンテナ化ツールを放棄する必要があることを意味するものでもありません。

[[355903]]

実際のところ、Kubernetes のエンドユーザーにとって、それほど大きな変化はありません。引き続き Docker を使用してコンテナを構築することができ、docker build を実行して生成されたイメージは Kubernetes クラスター内で引き続き実行されます。

それで、なぜそんなに大騒ぎするのでしょうか?何が変わったのでしょうか。そしてなぜ Docker が突然厄介者のように見えるのでしょうか。 Dockerfile を書き続けるだけでいいのでしょうか?

慌てないで

ここで混乱が生じる理由は、2つの異なる事柄について話しているからです。 Kubernetes クラスター ノード内では、コンテナ ランタイム デーモンが、イメージのプルと保存、コンテナの実行と監視、ネットワーク接続など、コンテナのライフサイクル全体を管理します。

Docker は間違いなく最も人気のある選択肢です。ただし、Docker は Kubernetes に組み込むように設計されていません。これがすべての問題の根源です。 Docker は単なるコンテナ ランタイムではありません。これは、多くの UX 拡張機能を備えた完全なテクノロジー スタックであり、簡単に操作できます。実際、Docker 自体には高レベルのコンテナ ランタイムが含まれています。続き。そして、containerd は今後、コンテナ ランタイム オプションになります。

さらに、これらの UX 拡張機能は Kubernetes には必要ありません。どちらかといえば、これらは Kubernetes が本当に必要なものを得るために回避しなければならない障害です。つまり、Kubernetes クラスターは、コンテナ化された Dockershim と呼ばれる別のツールを使用する必要があります。これにより、複雑さのレベルが増し、チームが維持するツールがさらに増えます。エラーや問題が発生する可能性のある別の原因。

つまり、ここで実際に起こっていることは、Kubernetes がバージョン 1.23 で Dockershim を削除し、Docker のサポートがなくなるということです。

気にするべきでしょうか?

では、開発者として、何を変えようとしているのでしょうか?それほどでもないです。開発中に Docker を使用する場合は、引き続き使用しても違いはわかりません。 Docker を使用してイメージをビルドする場合、結果は Docker に固有のものではありません。これは OCI (Open Container Initiative) イメージです。 Kubernetes とその互換性のあるコンテナ ランタイム (Containerize や CRI-O など) は、これらのイメージをプルして使用する方法を知っています。そのため、私たちはまずコンテナの外観に関する基準を開発しました。

一方、GKE や EKS などのマネージド Kubernetes サービスを使用している場合は、サポートされているコンテナ ランタイムを実行する前に、ノードに Docker サポートが再適用されていることを確認するか、カスタム構成 (使用している場合) を更新する必要があります。 Kubernetes をローカルで実行している場合は、不要な問題や予期せぬ事態を避けるためにも変更を加える必要があります。

結論は

バージョン 1.20 では、Docker から非推奨の警告が表示されます。この変化は起こりつつあり、他の変化と同様に、最初はいくつかの問題が発生する可能性があります。しかし、それは壊滅的なものではなく、長期的には物事を容易にするでしょう。

この記事によって物事が明確になり、不安がいくらか軽減されることを願っています。結局のところ、開発者にとってはこれらの変更は意味をなさないかもしれません。