#kubernetes1.20 #docker-bye

隨著 kubernetes 1.20 相關消息愈來愈多，目前一個引起廣泛討論的就是 docker support 將被標示為棄用，並且於未來版本的中將正式移除。

到底這個未來的改變對於開發以及維運人員來說，到底會有什麼樣的衝擊，這邊就來跟大家分享一下我的看法

# 開發人員
Q1: 我需要重新學習新的工具嗎？ 能不能繼續使用 Docker?
A1: 大部分情況下，你不需要重新學習任何工具，可以繼續使用 Docker 作為本地開發，你產生的 Image 依然可以讓 Kubernetes 去運行。

Q2: Kubernetes 一旦不支援 Docker，那我的 Image 還可以放 Docker Hub 嗎?
A2: 這個沒有問題，因為目前的 Container Registry 都基於 OCI 標準來設計，因此格式相容的情況下， Kubernetes 是可以繼續使用 Docker Hub 上的 image.

Q3: 我的開發環境是 Mac，使用的是 Docker for Desktop 並且用 Docker 內建的 Kubernetes 來開發，請問我會被影響嗎
A3: 這個開發環境比較特別，可以讓 docker build 產生的 image 直接給 kubernetes 使用。一旦 Kubernetes 底下使用別套，也許這條路徑會出問題。 因此這個問題值得關注。

# 維運人員
Q1: 我的公有雲 Kubernetes 服務會被影響嗎？
A1: 三大公有雲目前都有提供除了 Docker 以外的解決方案，可以參閱相關文件來切換。
如果已經使用 containerd/cri-o 這些解決方案的話，基本上什麼都不用做。
但是如果本來使用的是 docker 的話，那就要注意一下你的服務提供者有沒有提供轉移方式。

Q2: 自架 Kubernetes 會被影響嗎
A2: 這取決於你的使用方案，譬如你使用 Rancher 的話，預設是使用 Docker，因此勢必未來一定會有一波轉移問題要處理。
另外如果 Kubernetes 節點是由自己處理的，那要注意需要自行安裝其他的 Container Runtime。單純只有安裝 docker.io 是不夠。

Q3: 維運上會有什麼改變?
A3: 未來若 k8s 不再支持 docker，勢必你將不能於節點上使用 docker 這個指令來觀察相關的運行資訊。這部分可能需要改用 ctr 或是 crictl 等不同的 CLI 工具來觀察。
全新的工具，全新的用法勢必需要學習

Q4: 這樣切換有什麼好處?
A4: 不論是切換到 Containerd 或是 CRI-O ，效能上會提升，與資源消耗會下降，整個容器處理流程也會變得更加精銳

# 結論

1. Kubernetes 不是 Docker 管理平台，是容器管理平台。定義 CRI 標準就是為了支援多種容器技術。
2. Docker 被移除是可以考慮的，未來我認為 CRI-O 都有可能變成預設解決方案，因為其本身的設計就是為了 K8s 而最佳化，同時也與 Kubernetes 版本對齊，
3. 1.20 只是警告，將要退役，並不代表完全移除。但是不久的將來就會正式移除。
4. 如果有時間，就提早進行準備，永遠都不要到最後一刻才決定處理。大量仰賴 Open Source 的情況下，每個專案的開發能量也都很重要，一個不再維護的專案用起來會很令人提心跳膽。