Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
0
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

Kubernetes v1.20のDockershim非推奨 よくある質問FAQ

Kubernetes v1.20 において、Dockershim非推奨がかなり話題になっているので、
2020年12月02日(水)の 公式ブログを読み、和訳しました。
間違いなどありましたら、コメントでご指摘ください。

なぜdockershimが非推奨になるのか?

結論から言えば、dockershimを維持することは、Kubernetesにとって、あまり嬉しいことじゃないのです。
これはなぜかというと、DockerとKubernetesでコンテナランタイムがサポートしているAPIの規格がことなるからです。
Kubernetesがコンテナランタイムと連携する際にCRI標準というAPI規格を用いていますが、Docker自体は現在CRIを実装していないため、問題が起きています。

そもそも、Dockershimは常に一時的な解決策を意図していました。それゆえにshimという名前がついています。
さらに、cgroups v2やNamespaceなど、dockershimとは大部分互換性がなかった機能が、新しいCRIランタイムに実装されています。dockershimのサポートの継続のためにこれらのAPIを利用できないということになってしまっています。

これらの問題から、コミュニティでは、dockershimのサポートを継続しないという結論に至ったのです。

Kubernetes 1.20でもDockerは使えますか?

使えます。1.20で変わったことは、ランタイムとしてDockerを使用している場合、kubeletの起動時に警告ログが1つ表示されることだけです。

dockershimはいつ削除されますか?

早くても、2021年後半の1.23になる予定らしいです。

既存のDockerイメージは今まで通り使えますか?

はい、docker buildから生成されたイメージはすべてのCRI実装で動作します。既存のイメージはすべてまったく同じように動作します。

プライベートなイメージは今まで通り使えますか?

はい。すべてのCRIランタイムは、Kubernetesで使用されているのと同じプルシークレット設定を、PodSpecまたはServiceAccountを介してサポートしています。

現在、本番環境で他のランタイムを使っている例はありますか?

kindプロジェクトでは以前からcontainerdを使用しており、ユースケースの安定性が向上しています。kind と containerd は、Kubernetes コードベースへの変更を検証するために毎日活用されています。
また、OpenShift 4.xでは2019年6月からCRI-Oランタイムを本番で使用しています。

その他の例についても、containerdとcri-oの採用者を下記のページから見ることができます。

https://github.com/containerd/containerd/blob/master/ADOPTERS.md
https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md

人々は常に OCI を参照していますが、それは何ですか?

OCIはコンテナツールとテクノロジー間のインターフェースの多くを標準化したものです。
OCIイメージ仕様(コンテナイメージをパッケージングするための標準仕様)とOCIランタイム仕様(コンテナを実行するための標準仕様)を維持します。

どのCRIの実装を使えばいいのでしょうか?

Dockerを使用している場合には、コンテナに移行するのは比較的簡単です。
しかし、あなたの環境に適したものがある場合に備えて、CNCFのすべてのオプションを検討することをお勧めします。
これは、複雑な質問です。

CRI の実装を変更する際に注意すべき点は?

基本的なコンテナ化コードはDockerとほとんどのCRIで同じですが、周辺にはいくつかの違いがあります。移行時に考慮すべき一般的なことは以下の通りです。

  • 設定のロギング
  • ランタイムリソースの制限
  • ノードプロビジョニングスクリプト
  • docker CLI またはKubectl プラグイン
  • Dockerへの直接アクセスが必要なKubernetesツール(例:kube-imagepuller
  • レジストリミラー、安全でないレジストリのようなレジストリの設定
  • dockerを利用するKubernetesの外で実行される他のサポートスクリプトやデーモン (監視やセキュリティエージェントなど)
  • GPUや特殊なハードウェアと、それらがランタイムやKubernetesとどのように統合されているか
  • dockerd の設定をカスタマイズしている場合、可能な限り新しいコンテナランタイムに適応させる。(Kubernetes のリソース要求/制限やファイルベースのログ収集 DaemonSets を使用している場合は問題なく機能する。)

ただし、システムメンテナンスのために実行するものと、イメージを構築するときにコンテナ内に入れ子になっているものは動作しません。
前者については、crictlツールを使うことができます。
後者については、Dockerを必要としないimg, buildah, kanikoなどの新しいコンテナビルドオプション利用してください。

参考

https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
https://kubernetes.io/blog/2020/12/02/dockershim-faq/
https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
0
Help us understand the problem. What are the problem?