Kubernetes 的發展其實跟 Docker 脫不了關係 (｡･ω･｡)ﾉ

開始前先聽個故事

Docker 開創了容器技術的廣泛應用。
它讓「一次構建，隨處運行」的理念成為現實，徹底改變了開發者和維運團隊的工作方式。

2013-2014年， Docker 憑藉開源和簡潔易用的特質成為開發者的寵兒，看見商機的資訊業巨頭們也紛紛投入容器化技術的發展：CoreOS 推出了Rocket、Google推出了 lmctfy，但誰都沒有成功撼動 Docker 的地位。當時，CoreOS 的創辦人 Alex Polvi 還評論：Docker已經逐漸失去對於 Container 標準化的堅持。

同業們的挑戰陸續敗下陣來。
引領技術革命的 Docker 依然站穩市場領先地位，並幾乎是獨斷主導了容器技術的生態發展。
接下來的事態走向，也就不算太意外。

一如所有爆紅的慣例，Docker 踏上了商業化的道路。

Docker 開始動手收購與自家產品相關軟體和工具、把公司名稱從 dotCloud 正式改名為 Docker 並註冊了商標，一連串的商業化行為引起同業的注意，也讓開源社區產生警惕。

\\\ 這東西要開始收費啦！///

尤其是依附著 Docker 開發出來的產品，無不擔心起即將要被收取的授權費用。

於是2015年，在Linux基金會的主導 (和同行的施壓) 下，Docker與其他容器技術小夥伴們共同成立了 OCI 聯盟（Open Container Initiative）＊註1：一個以建立和推廣容器標準，並促進技術生態系統發展的組織。

然後讓 Docker 貢獻出了容器標準。

雖說有了 OCI 成立，但風頭正盛且擁有使用者絕對優勢的 Docker 並不積極參與標準化的制定，使得組織的發展有些緩慢。也因為置身事外的態度，Docker 自此漸漸地失去制定規則的主導權，埋下後來 Kubernetes 與其分手的導火線。

說了一大堆，其實只是覺得這段發展很好聽 （吃瓜）

為什麼處於黃金年代的 Docker 會同意加入 Linux 基金會？

Docker 的 container runtime 採用的其中兩個核心技術：Namespace ＆ Cgroup 並不是自行實作的，而是依賴於 Linux 環境，Docker 的運行一開始就離不開 Linux。換句話說，要是其他同業有心投入，其實也能利用這兩項核心技術開發自己的解決方案。同時，Docker 面臨著來自其他公司和開源專案的競爭，主動推動技術標準化有助於鞏固自身的產業地位及話語權，也能加深與其他技術公司的合作關係。另一方面，也順勢回應了開源社區希望能看到更多開放性和協作的需求。

這跟 kubernetes 有什麼關係？

Docker 帶來的革新造就了容器化技術發展的環境，也才有後續 kubernetes 等工具的出現，甚至第一版的 Kubernetes 就是使用 Docker 做為 container runtime的喔！

• container runtime
  用來管理和執行容器的軟體層，負責啟動、停止、管理和監控容器中的應用程序。

Kubernetes (k8s)

與 OCI 同時於 2015 年成立的，還有 CNCF（Cloud Native Computing Foundation）＊註2。

CNCF 是致力於推動雲原生技術的標準化和最佳實踐的組織，它的成立就現在來看，相當於是將 Kubernetes 推上了容器技術主位的重要助力。

Kubernetes 是 CNCF 的第一個專案。
原先，Kubernetes 是 Google 自行發展的專案，但在 Docker 逐漸商業化時空背景下，加入 CNCF 的 Kubernetes 憑藉強大的社群支持迅速崛起，社群的集體智慧與協作不但使其站上了容器發展的主舞台，更擺脫了Docker影響，成為容器管理領域的引領者。
與 Docker 不同，Kubernetes 完全專注於容器的管理。他不在乎使用者用什麼工具產生image，只要符合公開標準就支援執行，並將發展重心聚焦在自動化部署、容器擴展、修復等容器生命週期的管理功能上，不但大幅度降低容器的管理難度，更是為微服務提供了漂亮解決方案。

既然有公開標準，使用者是不是使用Docker就不是那麼重要了。

雖說一開始，Kubernetes是採用Docker作為運作核心，但在使用者增加到一定程度之後，Kubernetes調整了發展策略。
當Docker已經開始走向商業化，對已經發展出規模的Kubernetes來說，無論是基於開源的核心即將收取授權費還是應該遵循公開標準的考量，調整container runtime都只是早晚的事。
2020年，已完成 CRI 導入的Kubernetes公開宣布將移除Docker。

故事就說到這，雖說 Docker 在容器管理系統上被 Kubernetes 壓了一頭，但在但在容器技術本身的發展上，Docker 依然處於容器技術中的核心，有著舉足輕重的地位。

Docker不符合公開標準嗎？

欸，還真的就不符合。
還記得CoreOS創辦人的評論嗎？原先處於領導地位的Docker對運行標準並沒有執行的非常嚴謹，對後續的標準制定也並不上心。除了規範中的實作，還另外做了許多標準外的強化功能，並透過Dockershim這套工具實現。是的，Dockershim並不符合公開標準。於是決心走向標準化的Kubernetes，在1.22版宣布將要徹底移除專屬Docker的相關支援。

Docker沒有發展自己的管理工具嗎？

有的！Docker 推出了 Docker Swarm：一個能將 Docker Container 部署成叢集(Cluster)的工具。為了簡便使用， Docker Swarm 完全是圍繞 Docker 開發出的產品，雖說學習門檻低，可以很容易從基本 Docker 指令建構出叢集，但從容器出發的設計和綁定 Docker 也為產品設下不少侷限。
Kubernetes 則是提供標準化規則，不只設置彈性高，還降低了整併其他工具的門檻，逐漸成為市場上最熱門的容器管理工具。

Kubernetes 就這樣直接拔掉 Docker 沒問題嗎？

還是有啦，所以不是一次性而是漸進式的更新。
Kubernetes 在 1.5版導入 CRI 架構，並將 Docker 的操作獨立出來，透過 Dockershim 運行，這樣既不會立即對 Docker 使用者造成影響，又能實踐標準化規範。
2020年，k8s 宣布 1.20 版後將不再支援 Docker，且 Dockershim 也被標示為棄用，最終於 2022 年（1.24版）正式移除。

• CRI (Container Runtime Interface）
  container runtime 的抽象化和標準化，讓 Kubernetes 不再依賴特定的 container runtime。不但符合 CRI 規範就能直接整合，大幅提高了相容性，同時也為工具開發者提供了明確的標準。

小結

Docker 和 Kubernetes 的發展密切相關，前者造就了容器化技術的浪潮，後者則乘上時勢建立了現下最廣泛使用的容器管理解決方案。

最後做個簡易比較：

Docker 就像是堆積木：

• 每個積木代表一個獨立的應用程式或服務
• 積木可以單獨使用，也可以組合成更大的結構
• 積木是標準化的，可以輕易地移動、重用或分享
  

Kubernetes 則像是設計師：

• 決定如何使用這些積木和整體結構
• 規劃積木的擺放位置和組合方式(部署容器)
• 根據需求增加或減少積木(自動擴展)
• 如果某個結構倒塌，會迅速重建(自我修復)
• 確保所有結構都正常運作(監控和管理)
  

資訊補充

Container Runtime Interface (CRI)
2020年，Kubernetes 宣布 v1.20 後不再支援 Docker
2022年，Kubernetes v1.24 正式移除 Dockershim。

註1：OCI 聯盟

OCI 聯盟（Open Container Initiative）

• 成立 (2015):
  • 2015 年 6 月，在 DockerCon 會議上，Docker 宣布與其他行業領導者共同成立
  • 初始成員包括：Docker、CoreOS、Google、Microsoft、Amazon、IBM 等公司
  • 以「為容器化技術制定公開標準」為目標
• 初期發展 (2015-2016):
  • 以 Docker 捐贈的 image spec 和 runtime spec 作為起點，OCI 開始制定主要規範
  • Docker 捐贈 libcontainer：用來建立和管理容器的專案項目
    （往後成為 OCI 發展 runtime spec 的基礎）
• 第一個正式規範發布 (2017):
  • 2017 年 7 月，OCI 發布了 v1.0 runtime Spec 和 image Spec

隨著容器化持續發展，OCI 開始關注更廣泛的容器生態系統問題。
2019 年，OCI 開始制定分發規範（distribution-spec），旨在標準化容器映像的分配方式。
現今，主要的容器技術都採用了 OCI 標準，Kubernetes 等容器管理平台也都支援 OCI 兼容的 container runtime 運行。

• Runtime Specification：
  定義了 container 的生命週期管理，包含建立、啟動、停止、刪除。最常見的是OCI官方實作的解決方案：runc。
• Image Specification：
  定義了 image 的結構和格式。

註2：CNCF

CNCF（Cloud Native Computing Foundation）

雲端原生運算基金會

1. 成立 (2015):
   • 於 2015 年 7 月由 Linux 基金會創立。
   • 初始成員包括 Google、CoreOS、Mesosphere、Red Hat、Twitter、Huawei、Intel 等公司
   • 同年，Kubernetes 成為 CNCF 的第一個託管項目，奠定了 CNCF 在容器管理領域的重要地位。
2. 快速成長 (2016-2017):
   • 多個重要項目加入，如 Prometheus、OpenTracing、Fluentd、linkerd 等
   • CNCF 開始舉辦 KubeCon + CloudNativeCon 會議，成為雲原生技術的主要交流平台
3. 致力標準化 (2017):
   • 發布 Cloud Native Definition 1.0，定義了雲原生的核心概念
4. 生態系統擴展 (2018-2019):
   • 項目數量迅速增加，涵蓋監控、服務網格、構建、安全等多個領域
   • 重要項目如 Envoy、Helm、Harbor 等加入

CNCF 至今仍致力於推動雲原生技術並持續關注新興領域，在推動開源協作、技術標準化和最佳實踐有著關鍵地位，極大地影響了雲端計算和軟體開發領域，相關專案和解決方案也在企業中被大幅採用。