Update content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md

Co-authored-by: nasa9084 <[email protected]>

Author: aquiladayc

content/ja/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md

@@ -18,7 +18,7 @@ Kubernetesはv1.20より新しいバージョンで、コンテナランタイ
 もし、GKE、EKS、AKSといったマネージドKubernetesサービス(それらはデフォルトで[containerdを使用しています](https://github.com/Azure/AKS/releases/tag/2020-11-16))を使っているのなら、Workerノードがサポート対象のRuntimeを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。
 もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダと確認し、アップグレードのための適切なテストと計画を立ててください。
 
-もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のKubernetesリリース(現在の計画では2021年下旬のv1.22)でDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他のサポート対象のRuntimeに切り替える必要があります。切り替える際、そのRuntimeが現在使用しているDocker Daemonの設定をサポートすることを確認してください。（Loggingなど）
+もし、ご自身で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の一部として設計されているわけではありません。これが問題の原因となっています。