導入 Kubernetes Container Manager
之前玩過 Docker Swarm (文章) 也研究過很肥的 Cloud Foundry，最近還是回到一直最想了解的 Google Kubernetes (簡稱K8S)。比較這三種 Container Manager，以複雜度和功能來看 Cloud Foundry > Kubernetes > Docker Swarm，這時候根據需求做架構取捨就變得很重要，相對強大的 Cloud Foundry 學習曲線也是很高的。如果還是 Docker 的輕度使用者，若是需要面臨 Docker Cluster 架構升級，本人還是建議選擇 K8S 入手。但如果你的服務很單純，只是需要多台節點共同分擔運算，那選擇最輕量的 Docker Swarm 也是不錯的。
如果服務複雜且常常需要共用資源、分配資源，那可以選擇 K8S，否則在 Docker Swarm 很多 HA/LB 更新機制都要自己實現蠻累的，穩定性與管理工具也不及 K8S 來的方便。基本上想要上手以 Container 建構的 Microservice (微服務) 的世界，每一個服務 (或 Process) 都必須進化為無狀態 (Stateless)、容錯、分散的特性是必要的，比起學習 K8S 等等 Container Manager 功能，我覺得微服務的轉換這才是最困難且花最多時間的工作。
Kubernetes 架構剖析
上圖是 Kubernates Cloud Controller Manager (CCM) 標準的架構圖，主要說明透過 Google Cloud 運作 K8s 的架構，對於自己透過實體機或 VM 架設整個 K8s Cluster 概念也是一樣的。我們先大致說明一下各個功能與設計。
Kubernetes Controller Manager
Kubernetes Controller Manager (KCM) 位於 Kubernetes Master 中，負責所有的控制功能，其中包含了以下四個元件：
Node Controller 節點控制器：K8s Cluster 由許多 Node 所組成，Node Controller 負責管理這些 Node，包含新增刪除、Hostname 與 IP Address 管理、Node Type 與 Size 等等資源管理，當 Node 發生錯誤造成離線時，Node Controller 也會自動進行處理，將 Node 移除 Cluster。
Route Controller 路由控制器：這個 Route Controller 只有在 Google Compute Engine 才有作用，用來讓不同的雲節點可以互相通信。
Service Controller 服務控制器：在 K8s 中所有的網路是與外界隔離的，必須透過 Service 來註冊服務，這個功能有點像是 ELB，主要是提供一個統一的入口，將網路封包派送到正確的 Container 中，也會扮演 Load Balance 的角色。
PersistentVolumeLabels Controller：由於所有 Container 在 K8s Cluster 都是 Stateless，但有時我們在實現服務的同時可能會需要儲存持久性的資料，像是資料庫等等服務，為了讓 Container 在任何一個 Node 重新執行的時候可以讀取之前的資料，所以必須提供 Volume 進行掛載。目前已經有很多不同的 Persistent Volume Implements，可以參考 Storage Document。
Kubelet
Kubelet 安裝於每一個 Node 上，負責與 API Server 溝通，也包含初始化並且將自己納入到整個 Cloud Cluster 的管理，Kubelet 就像是 Node 上面的 Docker 代理人，負責管理自己所分派的 Container。
Kubernetes API server
所有的 K8s 操作都是透過 API Server，官方也有豐富的 API Document，API 透過標準的 HTTP WebService 實現，包含了 Rest 與 WebSocket 等等 API 設計。無論是負責在節點管理 Container 的 kubelet 或開發者用來操作 K8s 的 kubectl，甚至 K8s Dashboard 都是透過這個 API Server 進行串接。
etcd
etcd 是一個分散式資料庫系統，由於我們的 Master Node 可以由多個節點組成，好讓某個節點發生故障的時候可以有其他 Master Node 接手管理 Container，因次透過 etcd 會隨時同步每一個 Master Node 的資料。
kube-scheduler
K8s 所有 Container 的管理都是非同步的，當 API Server 收到資源管理需求時，會交由 kube-scheduler 進行調度，分配最適合的 Node 來執行 Container。kube-scheduler 的工作可複雜了，包含在 Node 拓撲中選擇適合的 Node，你不會想把同性質的 Container 全部執行在同一個 Node 吧，到時候 Node 掛了 Service 就全死了，這些計算工作就是 kube-scheduler 負責的。此外 kube-scheduler 還需要將 pod 進行重啟，其中有內建一個評分演算法，避免 pod 搞掛整台 Node，挺複雜的。
kube-proxy
kube-proxy 提供給 kubectl 或 kubelet 進行 API Server 連線，kube-proxy 會讀取認證設定檔，方便同時管理不同的 K8s Cluster。
K8S 的架構今天先介紹到這裡，有空再繼續介紹 K8S Object 等等知識，掰囉～