k8s 的主要元件
- API server - 面對使用者、用於回應各種請求
- etcd - 鍵-值儲存，主要用來分享設定，這個服務本身就有能力在分散式的架構中確保資料的一致性，故被用來儲存各種設定及參數
- scheduler - 在有新的 container 起來時用於將其分配到適合的 node
- controller - 監控 pod 的狀態，在有容器死掉或資源不足的時候決定要不要補新的容器進去工作
- container runtime - 用來跑容器的軟體，例如最常見的 docker
- kubelet - 分散在每個 node 上的一個服務，用來確保容器有照預期的運行
k8s 架構
Node 是指實際上 k8s 被安裝、用來跑 pod 的機器，而為了達到高可用，故我們會用多個 node 組成一個 cluster，而 master node 則是用來監管及分派工作的 node。
一般而言，master node 是指有安裝 API server 的那個 node，而相對的 worker node 則是指有安裝 kubelet 及 runtime 的那些。
Pod
pod 是 k8s 上執行的最小單位，當我們要跑一個容器的時候，並不會在 k8s 上直接跑起這個容器，而是會建立起一個 pod，並在 pod 內跑我們的容器。
當一個服務的負載增加時，會需要直接起一個新的 pod 來跑、並分享流量，而不是在一個 pod 內起新的容器來處理請求。
在常見狀況下 pod 跟容器幾乎是一對一的關係，但實際上一個 pod 裡面可以跑多個容器， 舉例來說某個服務需要依賴 Redis，那麼我們是可以在同個 pod 裏面順便塞一個 Redis 的容器進去的。把多個容器塞在一起的好處就是他們會被視同在同一個機器上面，共享網路及儲存，故可以直接對 localhost 連線，或是直接對某個路徑讀寫來交換資料，而缺點就是當任一個容器壞掉時，則 pod 就會被視為死亡。
實際上，pod 的架構即是用來方便我們把主服務跟相依服務一起部署的工具，這樣可以避免多個 replica 建立後需要去管理多對多網路交換及儲存空間的問題。
Replica set
用作橫向擴容之用，單純地管理並維持多個 pod 同時在線上。它不是單純的在建立的當下會去啟動多個 pod、它在任何管理中的 pod 死亡時亦會加入新的 pod 以維持總數到其目標。
另外有個很有趣的屬性，當我們部署一個帶著新版 pod 設定的 replica set 時，它並不會嘗試去動線上的 pod。僅有在舊的 pod 死亡時才會用新版的 pod 去取代那個空缺。在課程練習中有一題要求我們將所有的 pod 更新到新版，而其範例解說便是逐步把所有舊的 pod 殺掉，達到一個類似金絲雀部署的效果。
另外注意我們可以用 kubectl 去調整 replica set 的參數，包其目標數量；但指令本身並不會去更動 replica set 的 yaml，故在下一次部署時會造成其目標數量會歸到原本的數字。
Deployment
Deployment 算是 pod 的部署計畫，它涵蓋了 pod 的參數、replica 及版本更新的策略。大概是細節以後聊吧，目前看到的章節裡很簡單帶過。
