三台機器、十個容器，哪個服務在哪台你開始用 Excel 記。
半夜機器一掛，你得先翻表格才知道上面跑了什麼。
這 30 天，我打算用一座雲之島把 Kubernetes 概念講完整：
① 雲之島（Cluster）
整座叢集島，也就是所有運算資源和機器集合起來的大本營，Cluster 是一個 Kubernetes 的大集合系統。
② 巢樹（Node）
島上的實體支撐點，承載著所有運算資源。
③ 泡泡（Pod）
掛在樹上的最小排程單位，負責封裝與隔離環境。
④ 小鳥（Container）
泡泡裡真正運作的應用程式實體。
每天一張圖、一段能複製貼上的指令，5分鐘動手做，30天後會有一個真的跑得起來的服務，釐清 Kubernetes 的運作脈絡與底層邏輯。
今天先看 K8s 出現前的 Docker 情境：
這時只有人工處理小鳥 (Container)，只要樹 (Node) 倒下，失去依靠的小鳥就會掉落。
首先，預設你已經會用 Docker 了。
一台機器上 docker run 起三個容器，順手得很。
問題是當機器變成三台、容器變成十個，有三件事會開始變成大麻煩。
第一，機器掛了，上面的服務就沒了。
單純在某台機器上用 docker run 啟動的容器，預設只會在該主機上執行。
即使設定重啟策略，也只能嘗試在原主機重啟；主機失效後，不會自動到另一台機器建立替代實例。
必須人工登入另一台、翻出指令、重新跑一次，還要記得改掉對外的 IP，這段時間服務就是掛的。
第二，新服務要放哪台，是你在決定。
你得自己記住每台機器配置了多少資源、已經承諾給哪些服務，以及哪些工作負載不能放在一起。
這些資訊沒有寫在任何地方，只存在你腦袋和那張 Excel 裡。
同事接手的第一天，就是災難的第一天。
第三，擴容要人工。 流量上來了，你要多開兩個容器。
開完還得去改前面的 Nginx 設定、把新的 IP 加進去、reload。
流量退了，再手動關掉、再改一次設定。
半夜三點做這件事，錯一個字就是全站掛掉。
在有多個節點、並且已配置好控制器、網路與儲存等能力的叢集中，Kubernetes 會把上面這三類決策交給一套持續協調的系統；它不是單靠一條指令就能保證跨機器高可用。
換句話說，你不再說「去 B 機器上跑一個容器」，你改成說「我要三份 hello 服務一直活著」。
在 Kubernetes 裡，這通常會表達成 Deployment 的期望狀態：
維持三個 Pod replicas，每個 Pod 裡執行 hello Container。
剩下的事情由不同元件協作：挑機器、建立工作負載、掛掉就嘗試補回；之後再透過 Service，把流量導向目前可用的 Pod。
這個轉變有個名字叫宣告式。
你描述你要的結果，不描述達成結果的步驟。
這是整個 K8s 最重要的觀念之一，其他元件會把它落實在不同地方。
Day 4 我們會看到島上是誰在負責比對「你要的」跟「現在的」有什麼差別。
所以先講清楚 K8s Container Image 與 Dockerfile 的觀念仍然適用，但 Kubernetes 底層不一定使用 Docker Engine，也可以透過 containerd、CRI-O 等 Container Runtime 執行容器。
它是站在容器上面那一層，專門決定工作負載要放哪、掛了怎麼辦、有幾份的那個東西。
也順便說清楚它的成本：要多學一套詞彙、多維護一組設定檔，一台機器跑一個小服務用不上它。
K8s 划算的時機，是當手上的機器和容器多到「哪個在哪」已經記不住的那一刻，也就是開始紀錄在 Excel 的那一刻，我們就是今天該學它。
我們預期用 Kind 在筆電上蓋出第一座島，跑起這 30 天都會用到的 hello 頁服務。
最後佈局這 30 天的地圖，讓我們知道自己走到哪裡。
第一幕（Day 1-5）登島
蓋出一座叢集、認識島上的地形和你手上的工具。
第二幕（Day 6-12）泡泡（Pod）與小鳥（Container）
把服務跑起來、讓它掛了會自己回來、學會查它為什麼起不來。
第三幕（Day 13-18）流量找得到人
讓外面的人連得進來。
第四幕（Day 19-23）帶著東西活下去
設定、密碼、資料的存放。
第五幕（Day 24-28）讓島自己運轉
健康檢查、資源限制、自動擴縮。
第六幕（Day 29-30）收成
一張全圖，總結我們系列文的收穫。
也預計系列文實作，會是用同一個服務，一天一天疊加上去。
你宣告想要的結果，K8s 持續讓目前狀態向它靠近。
iThome鐵人賽
看影片追技術