在開始介紹架構前，先來暸解一下 Cluster(叢集)。
中文稱作「叢集」，簡單來說就是一群電腦。在雲的世界中，我們將多個獨立的機器以網路相連起來並組合、形成一組提供應用服務的群體。
使用 Azure 服務時常會在 Compute 中選擇運算的資源，其中一選項就是運算叢集。
[圖片參考]: https://kubernetes.io/docs/concepts/overview/components/
上圖是今天要介紹的整體架構，在 Kubernetes 叢集中主要有兩個角色：
負責控制整個叢集的活動，例如：監控叢集中的 node 的狀況，當服務出現異常而無法運行時，master 進行處理以繼續維持應用服務正常運行。
節點是指執行程式的電腦機器，可以是實體或虛擬運算資源，主要提供服務所需的底層運算、網路或儲存資源。
我們可以把 Kubernetes 叢集想像成一個團隊，隊長為 master，隊員為 worker node。隊長負責指揮、控制帶領團隊，而隊員為實際執行任務的人、每個隊員都有著共同完成的目標。
在叢集中，至少會有一個 master node 跟一個 worker node。在現實情境，則可能會有多個 master 搭配多個 worker node。
接著來看到架構圖中的「Pods」(內部是藍色正方體的容器)。
是叢集中最小可部署單位，一個 worker node 裡面可能會存在一個或多個 pods。在叢集中是透過 Pods 來啟動容器、並由容器執行應用服務。相關的應用程式、library 和相依套件會被打包成 image 檔，由 pods 依 image 建立容器來跑應用服務。
大多情況一個 pod 裡只會執行一個容器，但在特殊情況如：相依的容器需要與另一個容器協作時，就會在一個 pod 中起多個容器。
接下來逐一介紹在 Master 與 Worker Node 中的各項重要程序(process)：
是叢集的匝道兼守門人，負責將叢集外的請求傳入內部、及將內部的訊息回傳至叢集外。api server 也會對請求進行驗證，只有受到授權的請求才可以進入。
在後續也會提到在叢集中，我們透過 kubectl 跟 API server 進行指令的互動來操作叢集。例如：今天如果要下指令刪除某個 pod，這個請求必須先通過 api server 驗證，在傳送去指定的 process 來操作 pod
當要建立一個 pod 時，scheduler 負責決定要把 pod 放在哪個 node 上。
Scheduler 會進行資源運算及查看每個 node 的資源使用情況，例如某個 node 上仍有多餘的資源可以使用，則 scheduler 會把 pod 指派在目標 node 上。這邊比較特別注意的是，scheduler 只決定 pod 放在哪個 node 上，實際的作業交給 kubelet 來執行。
負責偵測叢集的狀態變動，例如：某個 pod 掛掉，controller manager 偵測到異常時會再通知 scheduler 重新建立一個 pod 以維護叢集中 pod 的數量。
另外 controller manager 會根據 spec(之後會提到)查看當前 pods 執行數量是否正確。
在 controller manager 中包含多種不同控制器，如節點控制器，在節點故障時負責通知及回報；任務控制器，建立 pod 來執行一次性任務，負責監控直至任務完成，還有其他控制器這邊就不多做介紹。
是 key-value 形式的分散式儲存庫，主要記錄所有叢集各個時點的狀態資料。例如：建立或刪除 pod 時的叢集資料。而以上介紹的元件事實上都是仰賴 etcd 的資料來進行作業。
允許將叢集連接到雲端供應商的 API，透過雲端服務提供商的 API 來進行節點和資源的管理。若是本地端或學習用的環境就不會用到此元件，該元件僅執行在特定的雲端平台控制器。
每個 node 上會有 3 個重要的 process。
每個 pod 中會需要 container runtime 來執行容器。在前一篇有介紹 Kubernetes 支援的有 containerd、CRI-O 與 Docker。
負責接收來自 API Server 的命令請求，並與 Pod 溝通，確保容器按照預期運行。
負責 node、pod 和容器間的網路通訊，此外會將 service 的請求轉導至 pod 上，並自動計算出最有效率的方式來分派請求、而不浪費網路資源。
在機器的資源使用上，Master 主要負責控制與下決策，相較 worker node 使用較少的資源(ex: CPU、RAM 和儲存空間)；而 worker node 負責執行任務，故使用到的資源需求相對來的多。
iThome鐵人賽
看影片追技術