Kubernetes 為什麼不是我的最優先選項
最近在社群網站寫到「容器數量越來越多，該從 Docker Swarm 轉換到 Nomad 上」的訊息，然後就被問到這幾年來只要是這類問題，畢竟會被問的「為什麼不用 Kubernetes？」的問題。
冰山之下
像是 Kubernetes 這類解決方案，之所以會被大多數人所知道，必定是有大公司選擇使用，所以我們不需要懷疑這個方案是否有嚴重的缺陷。然而，我們要思考的是，這些公司以外有多少公司在使用？
這類有名的架構、方案、技術我們去使用當然沒問題，但是也有所謂的「必要性」的問題，身為工程師肯定會覺得這個技術超酷，想要去使用。我自己也會，所以也嘗試過 Kubernetes 覺得非常的好用。
假設只是想自己架設一個測試站，或者一些簡單的工具來實驗，通常會怎麼選？是不是直接使用 Docker Compose 來解決這類型的問題，大多數的工具也都會提供範本。
這也是我在最初階段採用 Docker Swarm 的原因，因為我的問題始終是要解決 Home Lab 的運作（當然，我的 Home Lab 跑的東西有點多，套用到初創公司可能都適合）
成本昂貴
大多數人使用 Kubernetes 的經驗不外乎公司、雲端跟 Minikube 這三種情境，很少有「自建機房」這種類型的狀況，以 Home Lab 或初創公司的等級來說，比較接近「自建機房」的狀況。
用使用雲端跟 Minikube 的經驗來看這件事情是非常失真的，因為不會需要考慮儲存跟網路的問題。
以儲存為例子，假設要發揮 Kubernetes 的叢集（Cluster）的優點，搭個三節點的服務不為過，對個人或者初創公司都算是負擔得起的程度（甚至用 Raspberry Pi 和 K3s 來搭建）那麼，假設我運行資料庫的節點故障，要轉移到其他節點時，資料要怎麼從死掉的節點轉移？
在 Minikube 的情境下根本不會碰到，然而在自己搭建的 Kubernetes 環境就會需要去處理，那麼就必須再多出儲存節點，即使是一台簡單的 NAS 也是一筆額外的花費，更何況 NAS 不一定能支援 CSI（Container Storage Interface）的協定。
使用 Docker Swarm 也會碰到，然而 Swarm 本身不做調度，會預設節點死亡本身就是有服務故障的狀況，處理方式就不同。
網路就更棘手，用 Minikube 的時候根本不需要考慮 Ingress（進入的流量）因為都在本機或者區網上，使用隨機的埠號（Port）也不會有問題。
在雲端上有現成的 Load Balancer（負載平衡）以及 Kubernetes 天生的支援，把容器掛到正確的 Load Balancer 上什麼都不用做，到了地端（自建機房）的狀況，我們要如何讓我們的網路環境能夠實現這件事情？去買一台 F5 設備（收購 Nginx 的公司）也許會支援，付出的代價還是額外花費。
不論如何，我們大多得採取「購入設備」的方式來解決這些基礎建設的問題，如果現在是一間銀行，為了符合法規不能上雲端要去搭建私有雲（如：自建機房）去購入這些設備一方面合理，另一方面這些花費對這類法人來說不算困難。然而，個人跟中小企業，就變成一筆不必要的額外花費。
漸進改善
也許是因為工作內容的關係，作為工程師很容易用「非黑即白」的方式看待各種問題，然而市面上不是只有「用 Kubernetes」和「不使用 Kubernetes」兩種狀況。
這也是為什麼我的方法是從單機虛擬化開始，來讓備份跟環境隔離乾淨。當需要跑的服務增加，以及有自動化的需求（自動搭建測試環境）出現，開始轉往容器化以及 Docker Swarm 叢集來維護。
這讓我可以在每個階段都「付出最小成本」去維護這些環境，並且只需要在轉移的過程中付出一定程度的格式轉換代價（如：撰寫 Docker Compose 設定）就可以轉移到新的架構上。
這一次開始評估轉換到 Nomad 上也不是完全沒有根據的決定，首先我已經驗證了適用於 NFS 的 CSI 可以運作良好，以及我本身就有使用 NAS 的 NFS 作為 Docker Swarm 的卷宗（Volume）來支援節點的遷移（Migrate）
同時，我判斷需要轉換到 Nomad 上的原因是我的 Docker Swarm 上也有一些共用的服務，這些服務有些需要兩到三個不同的副本（Replicate），這樣很難用 Docker Swarm 部署跟管理，但是 Nomad 作為 Hashicorp 公司的產品之一，自然會被自家的 IaC（Infrastructure as Code）工具 Terraform 支援，也就表示我可以利用 Terraform 模組化跟套用樣板去維護這些共用服務。
至於單一服務（開發用的測試環境）也已經被驗證過很好的在自己習慣使用的 GitLab CI 中運作正常，可以視為對 Docker Swarm 的升級，因為 Nomad 多了更多便於管理的功能（調度、從網頁存取容器命令列）這些都是在容器達到特定數量後，材需要煩惱的管理維護問題。
最後，假設要轉移到 Kubernetes 上，因為有了 CSI 的基礎，就只需要處理最困難的網路問題（Load Balancer 的搭建）而 Kubernetes 又提供比 Nomad 還更多的功能，以漸進式的擴充來說路線非常合理，更何況 Nomad 目前還支援跟 Kubernetes 混合並存的模式，在未來的升級上會更加平滑容易。