鬆獅容器小白25連拍

Container Orchestration編程初探

從下圖中從下而上來看你可以理解成在一個大的平台

1. 可以想像是雲端或是虛擬化平台
2. 平台上分別有三台各自獨立的宿主機
3. 上面有各自的作業系統
4. 跑了運作容器的執行環境(Container Runtime)
5. 容器化應用程式服務

Container Runtime
也簡稱CRI，可以指這整個容器程序運作的抽象底層，又或是理解為內部環境中程式語言在整個執行過程的生命週期的實踐。其中Container Runtime初始的用途就是要能夠運行容器。

透過上述各自宿主機上執行自己的容器化應用程式，但隨著AP服務需求日益增大，無論是在大規模的佈署管理正式生產環境或是爆量的存取需求而反映出需要更多大量計算資源而導致無法快速因應市場環境需求。

這時就有了叢集與編程腳本的概念，透過Container Orchestration把三台機器抽象成一整個共享池的容器資源，而原來各自宿主機就如同是一個個的容器節點，而APP的佈署實踐再也不需要知道需要配置到哪的指定機器上，直接由Orchestration來決定該如何佈建以及該放置到哪個節點資源的調度即可。

就如同前篇中 Docker Swarm 原生的叢集編排腳本技術來實踐。

Container Orchestration也把裡面的服務分別拆解出以下重要核心：

• Resource Management：管理底層的資源包含像是擴充與縮容運算資源節點，而節點資源內容就像是常見的CPU，Memory等...
• Scheduling：當被上層指派一個任務像是一個容器服務時，而容器到底應該要放在哪個節點機器上來運作。
• Service Management：主要是提供把容器應用服務透過連接埠映射讓外部用戶能順利存取訪問之用。

上述說了這些露露長就是希望讓自己能夠瞭解這樣的產品技術背後的驅力是想要解決甚麼樣的問題，另外這樣的核心服務並不僅僅專屬於在某一家的產品技術上，而一個通識服務基礎，無論哪種容器編程都一定是內涵這樣的觀念在裡面，已經就是標準化技術編程，以下是列出市場熟知的三大自動編程解決方案：

1. Docker Swarm
2. Mesos
3. Kubernetes(K8s)

經過這幾年的容器發展，Kubernetes已然成為容器編程的領導地位，而圍繞此容器技術的生態圈都以此作為一個公認的統一標準，故無論是在技術資源或是應用實例的豐富性上都已成為一個當紅炸子雞的一艘世界級航空母艦。

各家雲端服務提供者都無不爭相支援納入自己的雲平台環境中，讓B2B / B2B2C / B2C都能夠留住用戶在我的雲平台上透過K8s能完成各種嶄新應用並同時把成本花在刀口上不被長期持有的傳統算算資源與授權所扼殺了有能力的創意開發夢想者。

專注重要K8s實踐

K8s簡單三大元件服務：

• 大於>=1 Master Nodes
• 大於>=1 Worker Nodes
• 分散式鍵值儲存區空間etcd

Master Node
在k8s整個架構之中Master扮演著稱職的管理叢集要角，管理用戶可以透過CLI，GUI或開發人員熟悉的API個字熟悉的方式來與Master做彼此間的通訊互動來達到其讀寫、控制或變更叢集資源配置如：Pod數量，計算資源大小等等。
作為一個稱職的k8s管理用戶，我們最終就是把自己所需Input到Master，讓Master知道你的意圖後，接下來的處理就交給k8s。
以下區分幾個服務核心：

• etcd
• api-server
• Scheduler
• Controller

etcd 為 key-value 鍵-值儲存，用來儲存、檢索和管理關聯陣列資料之用，本身用來儲存叢集內的狀態與組態設定，另外透過etcd回報訊息給Master來了解目前叢集運行狀況，另外當Master因某些原因故障時則可以透過etcd來作為還原到K8s的正常狀態之用。

api-server 因為節點之間並無法直接溝通，故需要透過API把一系列節點與節點之間的溝通橋樑，舉凡像是新增，修改，讀取或刪除等動作都是先傳送到api-server，透過API來做彼此間驗證並處理上述一系列要求的工作任務。當執行完成時會把叢集最新狀態儲存到etcd中。

Scheduler 排程器會參考目前節點的狀態，一旦需要配置調整Pod時就會找到最佳的節點落腳處來做配置。

Controller 控制器透過api-server知道最新的叢集狀態並嘗試把目前狀態更新反饋成用戶管理人員想要得到的狀態，包含負責監視叢集狀態的程序如：Node Controller、Replication Controller等..

Worker Node
為K8s要能執行運作的最小伺服器主機單位，一個Worker Node簡稱節點(Node) ，就是對應一台主機，這其中可以是實體機器如：商用伺服器，PC，NB或虛擬機VM如：AWS EC2，GCP上GCE等...
以下區分幾個服務核心：

• Worker Node
• container runtime
• kubelet
• kube-proxy

Worker Node 上述已經明顯說明，而除此之外。Pod本身會被分配到節點來運作，而Pod最小單位中是含有一個到多個容器來實踐你的所需服務的。

Container Runtime 在一開始也講述到CRI主要任務就是一系列初始運行容器的整個生命週期的過程，而k8s也是用docker來建立執行容器之用。

kubelet 運行在節點中，負責管理該Node上的所有Pods狀態並與Master作溝通協調，每當kubelet接收到來自Master發出Pod所定義的內容時，會在呼叫container runtime建立Pod所需容器並確保容器狀態保持正常。

kube-proxy是當需要讓外部做連線存取Service，kube-proxy本身會持續性監視回報api-server資訊。當Service建立後kube-proxy會把外部需求指定映射到所需對應的Pod服務。

Fluentd 是屬於一套日誌系統收集的工具服務，但因為並不只於這套可以自行安裝其他日誌收集的套件，故屬於選項之一，就不在此篇特別贅述。