From 8ae8a16ffcafe882c0d81a232d7257ad5876658c Mon Sep 17 00:00:00 2001 From: aquiladayc <56868556+aquiladayc@users.noreply.github.com> Date: Mon, 6 Dec 2021 09:03:22 +0900 Subject: [PATCH] Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md Co-authored-by: nasa9084 --- .../blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md index 6d73c2cab5..5a6e102cb7 100644 --- a/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md +++ b/content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md @@ -20,7 +20,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。(Loggingなど) -## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 ## +## では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。 ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスターの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります(他にはcontainerdやCRI-Oが挙げられます)が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。 お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。