Google 於 2015 年釋出 Kubernetes (簡稱 K8S) 後，引起了話題。原先僅是屬於內部專案 – Borg，IT 大廠如Redhat、CoreOS、IBM，甚至 Amazon、Microsoft 這些公有雲端供應商都搶著整合進自己的服務中。到底是什麼原因讓 Kubernetes 爆紅？

容器興盛的開始

相信您一定聽過 Docker，這個在 2013 年推出，以碼頭貨櫃命名的容器，強調 build, ship and run 的觀念(可前往 Katacoda教學網站試試看)。Docker 的輕量虛擬化的技術及易於移植的特性，非常利於現代雲端服務的開發及部署。相對來說，傳統的虛擬機需要追求高規格，且在基礎設施和維運(Ops)上需要花費非常多的工夫和心力。以下是傳統虛擬機器與 Docker 容器所做的比較[1]：

*詳細可參考 Docker 官方網站

當開發維運時，最希望的就是在部署後持續監控，當任一台伺服器流量過頭的時候，希望可以自動擴展；當流量很低迷時，可以自動縮減伺服器。除此之外，最重要的是，當一台伺服器掛點後，希望可以自動修復，而且隨時必須保持服務實例的個數。以上很多功能 Docker 都可以幫您做到，並利用容器來提供服務。這樣的服務型態被稱作 CaaS(Container as a Service)，看起來一切都很美好。但是 Docker 容器不是萬能，在容器/服務個數越來越複雜的情況下，如何管理叢集和服務的生命週期，將會是各家容器編排管理 (orchestration) 的能力。其中 Google 的 Kubernetes 就是一個十分精良的容器編排管理工具。

現在聯繫 iKala Cloud，瞭解更多 Google Cloud 加值服務！

微服務架構的成形

應用推展的過程中，程式碼將越來越龐大，傳統單體架構 (Monolithic Architecture) 的服務會造成巨大的不便(如下圖[2])，例如：
1. 龐大且複雜的程式碼 -除錯、新增功能與測試都包在一起，變得十分複雜
2. 容易以低效率的開發方式進行 – 利用新語言和新框架將更為困難，因為搬移或更動將耗費巨大成本
3. 不利於敏捷開發 – 現今的服務幾乎是每天更新，單體架構會讓這件事變得很耗時間4. 可靠性低 – 單體架構是將所有的模組均建構在一個程序 (process) 內，當其中一環有bug時，容易牽一髮動全身

而微服務 (microservices) 架構正好解決了這樣的問題(請見下圖)，將每一個具有商業邏輯的服務獨立出來，例如不再將所有資料都寫入同一個資料庫，而是每個單獨的服務都有一個最適合自己本身結構的資料庫。好處是讓每個服務都可以用最適合自己的語言、資料庫來開發。從下圖可以看到，乘客管理、Web UI、金流等都是一個獨立出來的微服務，而每個服務都開放了 REST API 實行客戶端或者服務之間的溝通。在實作上，每一個商業功能/服務都可能是一台 VM 或者一個容器。

Kubernetes 特別適合微服務這樣的架構。將數個容器組合起來成一個服務(Service，註：Service 是 K8S 的專有名詞，下面會介紹)，Kubernetes 也提供了良好的服務發現(Service discovery)機制，讓每個服務彼此可以通信。最重要的是 K8S 強大的編程可以自動擴展服務，甚至還可以對大規模的容器作滾動更新 (Rolling update) 以及回滾機制 (Rolling back/Undo)，更可以整合 CI/CD 等 DevOps 的工具，絕對讓您用最小的力氣管理最龐大的系統。

Kubernetes 的架構

了解容器和微服務的基本概念後，您就會了解 K8S 正是實現微服務架構的一個完美工具。Kubernetes 還是一個開源專案，您可以自己設計並作出貢獻。更令人興奮的是，由於開源的特性，更多的雲端供應商也將 K8S 納為己用，Google 就更不用說了，您可以在 Google Container Engine (GKE) 裡面使用 Kuberenetes。

話不遲疑，現在來瞧瞧 K8S 的架構：

K8S 屬分布式系統，主要元件有：
1. Master – 大總管，可做為主節點
2. Node – 主要工作的節點，上面運行了許多容器。可想作一台虛擬機。K8S 可操控高達 1,000 個 nodes 以上
3. masters 和 nodes組成叢集 (Clusters)

更細部來看：

Master 包含了三個基本組件

Etcd, API Server, Controller Manager Server

Node 包含了四個基本組件

Kubelet, Proxy, Pod, Container

這邊不打算細項討論，有興趣的朋友可參閱這本 O’Reilly 免費電子書[3] 或官方互動教學網站 試試看。現在我們著重在 K8S 最重要的三個部分，即是：

• Pod

• Service

• Deployments (Replication Controller)

Pod

容器是位於 pod 內部，一個 pod 包覆著一個以上的容器，這造成 K8S 與一般容器不同的操作概念。在 Docker 裡，Docker container 是最小單位，但在 K8S 可想作 pod 為最小單位。從以下 pod 的特性來看，就可以了解為什麼它是 K8S 裡面三巨頭之一了。

1. Pod 擁有不確定的生命週期，這意味著您不曉得任一 pod 是否會永久保留
2. Pod 內有一個讓所有 container 共用的 Volume，這會與 Docker 不同
3. Pod 採取 shared IP，內部所有的容器皆使用同一個 Pod IP，這也與 Docker 不同
4. Pod 內的眾多容器都會和 Pod 同生共死，就像桃園三結義一樣！

Service

K8S的 Service 有它的獨特方法，我們看看它的特性
1. 每個 Service 包含著一個以上的 pod
2. 每個 Service 有個獨立且固定的 IP 地址 – Cluster IP
3. 客戶端訪問 Service 時，會經由上述提過的 proxy 來達到負載平衡、與各 pod 連結的結果
4. 利用標籤選擇器 (Label Selector)，聰明地選擇那些已貼上標籤的 pod

Deployments

舊版的 K8S 使用了副本控制器 (Replication Controller) 的名詞，在新版已經改成  Deployments 囉。Deployments 顧名思義掌控了部署 Kubernetes 服務的一切。它主要掌管了 Replica Set 的個數，而 Replica Set 的組成就是一個以上的 Pod[4]。

1. Deployments 的設定檔(底下以 YAML 格式為例)，可以指定 replica，並保證在該 replica 的數量運作
2. Deployments 會檢查 pod 的狀態
3. Deployments 下可執行滾動更新或者回滾

至於 Kubernetes 怎麼建構服務的呢？又如何在 GKE 內使用呢？

第二回 GKE 系列教學 (二) 請 參考這裡 ！

另外還有 K8S專欄：Kubernetes Service 介紹，讓您了解更進階的 Service 操作 🙂

參考資料:

[1] http://www.ithome.com.tw/news/91847

[2] https://www.nginx.com/blog/introduction-to-microservices/

[3] O’Reilly free e-book http://www.oreilly.com/webops-perf/free/kubernetes.csp

[4] https://kubernetes.io/docs/user-guide/deployments/