為什麼需要 Kubernetes？ - ianchen0119/Introduce-to-5GC GitHub Wiki

最近半年，我因為修課與相關專案接觸了許多 container 相關的技術，其中就包含了 docker、docker-compose 以及 K8s。 在談什麼是 K8s（Kubernetes）之前，我想先分享一下我對於 container 技術的理解：

Docker

以 docker 為例，其實 docker 並不是 container 的唯一代表，它與其他容器化技術的解決方案基本上都是遵照 Open Container Initiative (OCI) 的實作。

Why containerize?

至於為何需要 container，可以把它簡單的理解成：開發者可能會因為專案需求去安裝各式各樣的開發工具，隨著工具的累積，我們很難保證這些工具不會發生衝突，甚至是不同專案對於不同工具的版本有不一樣的要求時，我們不可能為了專案來回的卸載、安裝各個版本的開發工具。 這時候，一個隔離系統環境、隔離檔案系統、隔離系統的網路環境這樣複雜且龐大的需求誕生了，也正是這樣的需求促成了 Container 技術。

Deploy multiple containers

有了容器化的技術，開發者可以隨意的將開發環境+應用程式打包成一個個 Container，就在這時候：Bang! Microservice 流行了起來，筆者我自己是在 2019 年參加 JSDC workshop 時接觸到這個名詞，但如果你跟那時的我一樣是個沒有在使用容器化技術開發的工程師，可能會很難搞清楚微服務到底想幹嘛。 簡單來說，因應微服務的需求，我們將一個 Service 拆成好幾個子服務，以網頁服務我們就可以拆分成 登入系統、主頁面服務、後台管理、資料庫...多個子項目。那麼，問題來了：

  1. 每個子項目的部署環境有沒有可能不同？是的，基本上一定不同。
  2. 那這個問題好不好解決？不難解決，我們把多個子項目打包成多個 Container 就行了！
  3. 如果我要快速的啟動多個 Container 該怎麼做？為了解決這樣的問題，單單使用 Docker 可能已經無法滿足我們的需要，這時候，像是 Docker-compose 這樣的解決方案就冒出來了，它可以幫助我們描述 Service，並且一次啟動多個 Service 做到快速部署的目的。
  4. 如果把 High Availability、failover 考慮進來，請問有解嗎？ummm，使用 Docker-compose 這類的解決方案我們當然也有辦法透過自己造輪子的方式做到故障偵測、甚至是狀態備份，但如果我們希望系統的某個子服務故障時自動恢復它，我們可能就會需要 K8s。

看到這裡，我們不難猜出 K8s 到底可以滿足什麼樣的需求：

  1. 動態的編排服務節點
  2. 節點備援
  3. 服務的付載平衡

除了上述的特點，K8s 還能結合 CI/CD tool 打造一個全自動化的 CI/CD pipeline，每一個子專案的 commit 被 push 至遠端節點後，這個 pipeline 可以幫我們做自動化的 1. 測試 2. 整合 3. 交付 加速系統部署的效率。

建置 K8s

目前市面上有多種建置 K8s 的方法，開發者可以根據不同的使用需求或是預算考量選擇一個最佳的方案。

公有雲

目前 GCP、AWS、Azure 都有提供 K8s cluster service，如果服務不到非常龐大，使用公有雲算是個不錯的選擇（不用花錢花時間維護設備，簡易的服務也不會燒太多錢）。

本地部署

如果是選擇在本地環境架設 Kubernetes，那麼就有非常多種選擇了：

  • Kubeadm 由 Kubernetes 團隊維護的方案，設定多節點環境時會比較複雜，也需要自己處理 CNI。
  • K3D K3S（輕量化的 K8s）的 docker 版本，不需要自己處理 CNI，建置多節點也只需要透過指令就能做到。
  • Minikube 透過 VM 架設 K8s，同樣不需要處理 CNI，並且 minikube 整合了許多功能包，算是入門 kubernetes 的好選擇。
  • KIND (Kubernetes In Docker) KIND 顧名思義是將 Kubernetes 以 container 的形式運作起來，比起 Minikube 它有更高的靈活性（建立多節點叢集），並且不需要自己處理 CNI。

筆者的話： 在這邊想要抱怨一下 kubernetes 的命名想法...筆者當初入門的時候一度搞不清楚 kubeadm、kubectl、kubelet 之間的關係，有時候建置方案的選擇太多對新手來說可能也是一種困擾啊...

總結

本篇文章介紹了常見的容器解決方案，並且用實際案例讓大家理解 K8s 的優勢。不過，筆者認為並不是所有的服務都必須要使用 K8s 來建置，docker-compose 幾乎可以應付日常的開發需求，在某些時候，我認為 docker-compose 更為方便一些：

1. 設計了一個系統雛形，進入概念性驗證階段時

個人認爲在個人專案的初期幾乎不需要 K8s，因為一個概念性的專案或是服務並不會有動態調整資源的需求。在這個情況下，docker 或是 docker-compose 會是你的好夥伴。

2. 整合性測試、端對端測試

當一個服務上線時可能會在 CI/CD pipeline 上做一些端對端的測試，如果一個服務被拆分成多個元件，我們可以使用 docker-compose 實作整個網路拓墣。

3. 生命週期短暫的專案

如果是沒有上線需球或是只需要存在幾天的軟體，那導入 K8s 毫無疑問是拿石頭砸自己的腳！在這個場境下，使用 docker 會是更好的方案。