Updated 2022/05/05
我發現儘管過了很長的時間， kubernetes 到前天都還有在解釋棄用Dockershim 的說明 XD，如果你還有疑慮歡迎參考下面的 blog 或是留言我可以跟你討論更多
https://kubernetes.io/zh/blog/2022/05/03/dockershim-historical-context/
— — —
雖然這已經是 K8S 、Docker 社群中討論已久的議題，還是希望能夠自己有個清楚的整理，用自己的理解記錄下來，也分享這些內容給被這個問題困擾的人們。
在進入正題以前，以下內容我們必須先行理解。
什麼是 Dockershim ?
Dockershim 是 Kubernetes 的一個組件，主要目的是爲了通過 CRI 操作 Docker。換言之，kubelet 需要通過 Dockershim 操作 docker daemon 。
為什麼需要 Dockershim 這個轉接 ?
這與 Docker & Kubernetes 發展的歷史有關係，原先 Kubernetes 屬於 Google 內部所使用的系統，釋出 open source 時，為了配合市場中較廣為人使用的容器平台 Docker，通過維護 Dockershim 來使 kubelet 能夠與 docker 來做溝通。
是什麼原因需要棄用 Dockershim 呢？
在 Kubernetes 中，kubelet 透過 CRI 介面 [3] 與 container runtime 溝通/調用。 然而，docker 的 CRI （a.k.a dockershim）是 kubelet 程式碼中的一部分，由 kubernetes 社群所維護，並且與 kubelet 的生命週期緊密耦合。
這對於開發/維護來說並不是非常的理想，因為 kubelet 依賴於特定的 container runtime 的情況下，這不僅會給 sig-node 中的開發人員帶來維護負擔，而且當 Docker 本身出現了安全漏洞時也會給集群管理員帶來維護負擔。
因此在這些前提下，社群在 2020/12/02 宣告了這項消息，讓開發者、集群管理者們能夠有時間去做進一步的決定、測試。
Note : 棄用 Dockershim 的 Pros/Cons 可以參考這邊 [4]，簡單理解的話，對於社群維護、開發 kubelet 相關的負擔可以降低，增加安全性、增加性能、降低耦合性。
究竟何時會真的棄用 ？
Kubernetes’ built-in
dockershimcomponent was deprecated in release v1.20.The dockershim removal occurs in Kubernetes 1.24[5].
AWS EKS 上面的計畫？
The default runtime for 1.21 will still be Docker, and you can opt-in to containerd runtime by adding a
--container-runtime containerdoption to your user data.[1]
在 EKS 版本 1.21釋出後， 工作節點還是維持以 docker 作為預設 container runtime，但開始提供選項能夠配置 containerd 作為 container runtime (EKS 1.16, 1.17, 1.18, 1.19, and 1.20 都可以選擇以 containerd 作為 container runtime)， 讓開發者能提前使用 containerd 做測試。
/etc/eks/bootstrap.sh $CLUSTER_NAME \
-- b64-cluster-ca $B64_CLUSTER_CA \
-- apiserver-endpoint $API_SERVER_URL \
-- container-runtime containerdNote : Fargate 和 Bottlerocket 已經只使用 containerd 作為 container runtime 好一長段時間了…如果你的容器化應用在這兩個平台上運行都沒有問題的話，我認為在開發者適應這端不會有太大問題。
K8S 社群預計在 1.24 完全棄用 Dockershim，在 EKS 上 1.24 [2] 開始，將正式停止支持 Dockershim，並且採用 containerd 作為預設 container runtime。
(建議在將 EKS 升級到版本 1.24 之前，請確保驗證您的工作負載是否能在 containerd 上正常運行)
作為開發者，我該如何應對？
根據 EKS 文件 [2] 說明，由於 Dockershim 已經在內部使用了 containerd，您可能不需要進行任何更改，但是在下列情況下可能需要更改：
- 如果應用程式有掛載 Docker socket 的話。舉例來說：使用 container 構建 container image 會受到影響。許多監控工具也會掛載 Docker socket，例如 Datadog。您可能必須等待工具更新、重新部署以進行監控。
- 您可能需要對依賴特定 Docker 設置的任何應用程式進行更改。例如，使用 HTTPS_PROXY 可能需要更改。
- 如果您使用 Amazon ECR credential helper 來拉取 image，則需要切換到 kubelet image credential provider。
檢查你的應用是否依賴於 Docker
對於開發人員來說，Docker 仍然可以做為打包應用程式成鏡像的工具( Docker 打包的鏡像符合 OCI 開放容器標準）。任一 OCI 兼容的鏡像，不管它是用什麼工具構建的，在 Kubernetes 的角度來看都是一樣的。 containerd 和 CRI-O 兩者都知道怎麼拉取並運行這些鏡像。
作為 K8S 集群管理者，我該如何應對？
- 在將 EKS/K8S 升級到版本 1.24 之前，請確保驗證您的工作負載是否能在 containerd 上運行。
- 檢查 K8S 官網中提到的部分：
