此文章適合沒有任何 Kubernetes/容器/Docker 經(jīng)驗的同學(xué) — 在不久的將來，你不懂如何操作 Kubernetes 接口，就等于現(xiàn)在的你不懂最普通的 Linux 命令。此文章閱讀耗時大概 15 分鐘。

螞蟻金服資源調(diào)度組致力于將 Kubernetes 落地到世界上最有價值的金融科技獨角獸公司，歡迎聯(lián)系作者微信 answer1991chen 咨詢招聘事宜。

文章 Markdown 源碼位于

https://github.com/answer1991/articles/blob/master/Kubernetes-is-the-next-generation-os.md ，遵從 Apache License 2.0 開源協(xié)議。

導(dǎo)言

此文章著重介紹如何在入門階段使用 Kubernetes，以及要面向 Kubernetes 編程帶來的優(yōu)勢，不會介紹復(fù)雜的 Kubernetes 架構(gòu)、實現(xiàn)。

因此此文章適合沒有任何 Kubernetes/容器/Docker 經(jīng)驗的同學(xué)，對 Kubernetes 有了解的同學(xué)也可以從此文章里面獲取一些靈感，可以更加酷炫的玩轉(zhuǎn) Kubernetes。

希望在閱讀完此文章之后，你可以從 “我需要一個 Linux VM 做開發(fā)、測試和部署”，變成 “我需要一個 Kubernetes 做開發(fā)、測試和部署”。

Kubernetes 是下一代操作系統(tǒng)

Kubernetes 是這幾年非常熱門的一個詞匯，大概所有的軟件工程師都已經(jīng)聽說過這個詞。

那么 Kubernetes 到底是什么呢？可能 Google 會告訴你很多，但是我想告訴你的是：

Kubernetes 是下一代操作系統(tǒng)；一個 Kubernetes 集群是一個資源無限大(可擴(kuò)容)的虛擬機(jī)。

而且，Kubernetes 的接口是是聲明式的，是天然面向分布式系統(tǒng)而設(shè)計的（下面會詳細(xì)介紹）。

說到這里，大家估計立刻就有疑問了。我想大概是這些：

Q: 那么，Linux、Windows 要被淘汰了？

A: 不會被淘汰，只是 Linux、Windows 是一個底層的單機(jī)操作系統(tǒng)。而我們這些普通的應(yīng)用軟件工程師將來都不會跟 Linux 打交道了，都會使用 Kubernetes 這個更上層、同時功能也更強(qiáng)大的操作系統(tǒng)。

Q: 那么，我不學(xué) Kubernetes 可以嗎？

A: 不行！在未來不久的某一天，也許云廠商只賣 Kubernetes “虛擬機(jī)”了：阿里云不單獨賣 ecs 了，亞馬遜AWS，微軟云，Google 云等各種云廠商都不賣 Linux 虛擬機(jī)了。

如果你想買單機(jī)版的 Linux 虛擬機(jī)，他們都會一臉驚訝的問你，你買那么底層的、功能那么薄弱的計算機(jī)干什么？就像你現(xiàn)在從云廠商那里買不到一個還沒有安裝 Linux 的虛擬機(jī)一樣。

以后，云廠商交付的 “虛擬機(jī)” 必定是 “集群級別的虛擬機(jī)” ，而 “集群級別的虛擬機(jī)” 的操作系統(tǒng)就是 Kubernetes。

在不久的將來，你不懂如何操作 Kubernetes 接口，就等于現(xiàn)在的你不懂最普通的 Linux 命令。

Q: 那這樣的話，我買不到 Linux 虛擬機(jī)，我連學(xué)習(xí) Linux 的機(jī)會都沒有了？

A: 當(dāng)然不是，有了 Kubernetes，你可以在 1秒內(nèi)自己搞一個任何 Linux 發(fā)行版本的 “單機(jī)虛擬機(jī)” 出來。

Q: Kubernetes 真的是一個操作系統(tǒng)？Show me….

A:

 

“一頓操作猛如虎” 聽起來很酷，但是你在做一些沒必要的事情，同時你做了這些事情并不討好你的老板，可能在因為你的失誤操作引起更大的故障和問題。

 

面向 Kubernetes 做最簡單的操作，達(dá)到最佳的效果，才是更酷的事情。

A: 行了行了，別說那么多了，我還是需要一個 Linux VM。

Q: 好的，我給您一個 Kubernetes，然后給你一個 基礎(chǔ) OS Pod “菜單”文件，然后您自己就可以創(chuàng)建任何一個 Linux 發(fā)行版、任何一個 Linux 版本的的 Linux VM了。在文章的最后會有介紹。

小試牛刀

既然是“小試”，那么我們來嘗試一個最簡單的應(yīng)用，一個 HTTP 服務(wù)：nignx。同時，我應(yīng)該部署一個高可用、多副本(例子中為3副本)天然容災(zāi)的 nginx。

部署完成的結(jié)構(gòu)圖大概如下所示：

沒有 Kubernetes 之前的部署

在沒有 Kubernetes 之前，我們大概要做這么些操作才能交付這個 nginx 服務(wù)：

1. 到三個 Linux VM 上面，分別把三個 nginx 進(jìn)程起好。這里可能還需要關(guān)心 nginx 進(jìn)程怎么起、啟動命令是啥、配置怎么配。
2. 到負(fù)載均衡管理頁面，申請一個負(fù)載均衡，把 3個 nignx 進(jìn)程的 IP 填入。拿回負(fù)載均衡的 IP。
3. 到 DNS 管理頁面申請一個 DNS 記錄，寫入把拿到的負(fù)載均衡的 IP 寫入 A 記錄。
4. 把這個 DNS 記錄作為這個 nginx 服務(wù)的交付成果，交付給用戶。

有了 Kubernetes 的部署

有了 Kubernetes 之后， 我們只需要寫一個 nginx 如何部署的 “菜單”，然后提交這個“菜單”給 Kubernetes，我們就完成了部署。

“菜單” 是一個 yaml 文件(例子中文件名 nginx.yaml)，大概這個樣子:

apiVersion: apps/v1 
 
kind: Deployment 
 
metadata: 
 
name: nginx 
 
spec: 
 
replicas: 3 
 
selector: 
 
matchLabels: 
 
app-name: my-nginx 
 
template: 
 
metadata: 
 
labels: 
 
app-name: my-nginx 
 
spec: 
 
containers: 
 
- name: nginx 
 
image: nginx 
 
--- 
 
apiVersion: v1 
 
kind: Service 
 
metadata: 
 
name: nginx 
 
spec: 
 
selector: 
 
app-name: my-nginx 
 
type: ClusterIP 
 
ports: 
 
- name: http 
 
port: 80 
 
protocol: TCP 
 
targetPort: 80 

提交“菜單”到 Kubernetes 集群：

$ kubectl apply -f ./nginx.yaml 

訪問剛部署的 HTTP 服務(wù):

發(fā)生了什么？這里大概簡單的介紹一下我們的“菜單”：

1. 我們向 Kubernetes 提交了一個叫 nginx 的 Deployment。Deployment 是 Kubernetes 里的一種副本保持 “資源聲明”，我們在我們的 Deployment 聲明了 需要3個副本(replica: 3)，副本的內(nèi)容(template: … )是用 nginx 鏡像啟動的Pod(Pod 即 Linux 里的進(jìn)程，如上章節(jié)介紹的)。如果沒有玩過 docker 的同學(xué)，可以把 nginx 鏡像 認(rèn)為是 nginx 二進(jìn)制包，只不過它是 docker 鏡像方式存在的，不在這里詳細(xì)展開。我們的 nginx Pod 打上了 my-app=nginx 這樣的 Label, Label 可以理解成 分類“標(biāo)簽”，別人(Service)來定位我們 Pod 需要用這樣的 “標(biāo)簽” 來匹配。
2. 我們還向 Kubernetes 提交了一個 Service。提交一個 Service 就是向 Kubernetes 申請一個 負(fù)載均衡。Service 依靠 Label (selector: …) 去找到它的后端真實進(jìn)程(Pod)。
3. Service 會根據(jù)規(guī)則自動生成域名。規(guī)則不在這里詳細(xì)展開介紹。
4. 我們就能用 Service 自動生成的域名作為交付成果，交付給用戶了！

容災(zāi)

Deployment 能自動副本保持，即我們的 nginx Pod 少了一個，Kubernetes 能自動幫我們補齊。

變更、發(fā)布、升級

如需要調(diào)整副本數(shù)目，我們只需要修改 Deployment.Spec.Replica 字段，再次 kubectl apply-f./nginx.yaml 即可，副本調(diào)整完成。

如果我們需要升級鏡像（nginx 二進(jìn)制版本），同樣的修改 PodSpec.Containers[*].Image 即可，然后 kubectl apply-f./nginx.yaml

Deployment 支持滾動升級，在升級時可以一個個升級你的 Pod（滾動升級）。

當(dāng)然，我們線上可能有更加復(fù)雜的升級策略，螞蟻金服提供的增強(qiáng)版 Kubernetes 提供比 Deployment 更加實用的升級策略，比如“灰度升級”， “分批升級” 等更加符合生產(chǎn)環(huán)境發(fā)布策略的升級方案。

關(guān)于“菜單” 和 聲明式系統(tǒng)

Kubernetes 是聲明式的系統(tǒng)。關(guān)于詳細(xì)的介紹 “什么是聲明式系統(tǒng)”，您可以去 Google 或者內(nèi)網(wǎng)上面也有許多聲明式系統(tǒng)的介紹。

我這邊有個簡單的比喻：假如你需要一桌菜（至于為什么是“菜”，是因為這個文章是我在做飯的時候構(gòu)思的）。

但是，這個放菜的 “桌子” 不太穩(wěn)定(或者說有老鼠來偷吃菜品)，一直發(fā)生一些事故，就像我們的線上部署應(yīng)用的環(huán)境一樣，服務(wù)器可能故障。當(dāng)你需要在這個桌子上面擺上一桌 “菜” 的時候，“菜”可能會壞掉。

別擔(dān)心，在聲明式系統(tǒng)里，“廚師長”是個盡職的好同志，當(dāng)你提交了一份“菜單”之后，我們的“廚師長”會一直保證你桌子上的菜一直會和你寫的“菜單”里的菜一模一樣。

如果某道“菜”壞了，“廚師長”就幫你再做一份。

在 Kubernetes 里面，有各種各樣這樣盡職的廚師長（有負(fù)責(zé) Deployment 的廚師長，有負(fù)責(zé) Service 的廚師長等等）。只要天沒塌下來，你提交的“菜單”里的菜都會一直美美的在桌子上“迎客”。

那么，我們回過頭來看我說的 “不久的某一天，云廠商只賣 Kubernetes 虛擬機(jī)了，而不單純的賣 Linux VM”。

你真的要買幾個 Linux VM 自己去啟動進(jìn)程（命令式），然后自己去搭建一套聲明式的系統(tǒng)去守護(hù)你的落在各個機(jī)器上的分布式應(yīng)用進(jìn)程？而不使用更高級、更好用的 Kubernetes 操作系統(tǒng)？

談軟件交付

軟件交付即把我們開發(fā)的一套應(yīng)用程序部署到其它環(huán)境。

軟件交付幾個重要關(guān)注的點：

1. 如何快速的部署一套我們的 “全家桶” 應(yīng)用到客戶環(huán)境。為什么說“全家桶”，是因為我們不可能只交付一個 nginx 服務(wù)，我們肯定會交付一套非常復(fù)雜的應(yīng)用或者中間件系統(tǒng)，比如交付一套 “支付寶系統(tǒng)” 到某個商業(yè)銀行。
2. 如何在客戶現(xiàn)場做自動化容災(zāi)，降低駐場和支持成本，或者根本不駐場。
3. 如何簡單、可靠地升級后續(xù)的版本。
4. 上述的幾點，不管是 “部署”，“容災(zāi)”，“升級” 都需要關(guān)注客戶現(xiàn)場的運行環(huán)境，我們有沒有辦法屏蔽這種運行環(huán)境差異。比如：我們帶過去的可運行軟件，在客戶的 OS 上是不是能運行；客戶現(xiàn)場的負(fù)載均衡方案都不一樣，如果到了客戶現(xiàn)場查看了他們的負(fù)載均衡方案之后再寫一個負(fù)責(zé)均衡部署方案肯定大大降低了交付效率。
5. 客戶現(xiàn)場的環(huán)境不一樣，必定帶來配置文件不一樣。讓一個現(xiàn)場交付人員弄懂所有應(yīng)用的配置參數(shù)，是不是一件讓他很頭疼的事情？

軟件交付方案的歷史：

1. 交付 源代碼：這應(yīng)該是最早的時代，客戶現(xiàn)場的環(huán)境（操作系統(tǒng)、機(jī)型）都不同，需要帶著代碼到客戶現(xiàn)場編譯，然后運行軟件。
2. 交付 可運行文件：像 Java 提出的 “Build once, run everywhere” 概念，在這個時代，我們可以面向一個運行時虛擬機(jī)交付軟件。或者我們都面向 Linux 交付，我們的使用 Go 編譯的二進(jìn)制，能順利的部署到大多數(shù)的 Linux OS 上。但是這種方案也強(qiáng)依賴客戶現(xiàn)場需要裝上指定版本的 Java 虛擬機(jī)，或者 Linux 特定的版本(應(yīng)用依賴 Linux 內(nèi)核特性)。
3. 交付 鏡像：交付鏡像，最大可能的屏蔽了底層 OS, Java 虛擬機(jī)的差異。在鏡像里面，我們把自己需要的 OS 基礎(chǔ) 和 Java 虛擬機(jī)也裝上了。不再依賴客戶現(xiàn)場的 OS 和 Java 虛擬機(jī)版本了。

鏡像最大可能的程度上把我們需要的運行時環(huán)境和我們的應(yīng)用可執(zhí)行文件打在一起，在各種環(huán)境下面都能完美地運行。那么，只有鏡像就能快樂的交付軟件了嗎？在我眼里，鏡像做的事情完全不夠。原因無非也是這么些：

1. 怎么配置啟動參數(shù)，要交付人員辛苦的讀懂啟動參數(shù)配置說明說嗎？
2. 怎么做分布式應(yīng)用的組網(wǎng)、服務(wù)發(fā)現(xiàn)
3. 怎么做容災(zāi)
4. 怎么做部署的元數(shù)據(jù)錄入：今天我在客戶現(xiàn)場把 A 應(yīng)用部署到了 節(jié)點1 上面，我要把這個信息記在哪兒？

你可能會告訴我，你說的這些我們的 PaaS 系統(tǒng)都能搞定。是的，你說的沒錯！但是當(dāng) PaaS 能用統(tǒng)一標(biāo)準(zhǔn)管理應(yīng)用、屏蔽應(yīng)用的細(xì)節(jié)，解決應(yīng)用的組網(wǎng)和服務(wù)發(fā)現(xiàn)，監(jiān)聽每個應(yīng)用的實例變化（自動化感知故障發(fā)生）然后自動恢復(fù)（副本保持），那么它就已經(jīng)差不多是 Kubernetes 了。

把上述的所有功能邏輯都整合在 PaaS，勢必導(dǎo)致 PaaS 的臃腫，我們是不是可以面向 Kubernetes 這個 OS 去做一個輕量級的 PaaS？因為很多功能在 Kubernetes 已經(jīng)有了，而且肯定比我們自己研發(fā)的 PaaS 要好用許多。

我們的 PaaS 是不是可以向 Kubernetes 提交 Deployment，而不是自己親自去做進(jìn)程拉起、副本健康檢查、副本保持等功能。

面向 Kubernetes 交付軟件

正如我上文所說，可能有一天所有客戶現(xiàn)場的 OS 都是 Kubernetes，那我們是不是可以像上文啟動 nginx 服務(wù)一樣，用這種 YAML “聲明” 的方式去交付我們的軟件？

當(dāng)然可以！但是，當(dāng)我們?nèi)ソ桓兑粋€ “全家桶” 服務(wù)的時候，我們會發(fā)現(xiàn)我們的 YAML 寫了幾千行，甚至上萬行了。

這個上萬行的 YAML 誰來維護(hù)？就算是分開給各個子應(yīng)用的 owner 維護(hù)，是不是也可能會發(fā)生牽一發(fā)而動全身。有沒有更加簡單的方式？

當(dāng)然有。我們再回來談 “菜單” 和做菜。我是一個吃貨，但是我很懶。當(dāng)我點菜的時候，非常希望點一個 “套餐”，而不希望一個個的去點每個菜，更不希望弄懂菜是怎么做出來的。

我想要點一個 “滿漢全席”(復(fù)雜的應(yīng)用)，可我不想清楚的弄懂套餐里面單獨有什么菜、每個菜的配方是什么。一個“滿漢全席”(復(fù)雜的應(yīng)用)里面，可能有“山珍”(數(shù)據(jù)庫)和“海味”(Web服務(wù))。

我只想告訴我們的“大廚”， 我要 “滿漢全席” ，然后我們的 “大廚” 就心領(lǐng)神會的知道 “滿漢全席” 里面有什么，然后把 “滿漢全席” 給做出來。

那么這個 “大廚” 要親自做這里的每道菜嗎？也不必，因為我們的 “大廚” 也可能是個 “懶人”，當(dāng)需要一桌 “滿漢全席” 的時候，他只會告訴負(fù)責(zé) “山珍” 的 “大廚” ，要一桌 “山珍”（數(shù)據(jù)庫），然后告訴負(fù)責(zé) “海味” 的 “大廚”，要一桌 “海味”（Web服務(wù)）。

當(dāng)我們的大廚發(fā)現(xiàn) “山珍“ 和 “海味” 都準(zhǔn)備好的時候，他會告我 “滿漢全席” 準(zhǔn)備好了。

是不是發(fā)現(xiàn)和交付軟件很像？為什么我們不交付一個 “大廚” 出去？到客戶現(xiàn)場負(fù)責(zé)交付的人員，只要告訴 “大廚” 我們需要一個 “滿漢全席” 這種套餐級別的聲明就行了。

并不是說套餐沒有參數(shù)，只是套餐的參數(shù)能做到對用戶屏蔽不必要的細(xì)節(jié)：比如我們的 “滿漢全席” 就只要一個參數(shù)，只要讓用戶填他的 “滿漢全席” 需要支持 “多少Q(mào)PS”。

面向 Kubernetes 編程：使用 Operator 交付軟件

上面提到的使用“交付大廚”的方式去交付軟件看起來很美好。那么，如何實現(xiàn)呢？也就是我們要怎么培養(yǎng)出屬于我們自己的“廚師”。

其實我們在 “小試牛刀” 的章節(jié)已經(jīng)介紹了一位 “廚師” 了：負(fù)責(zé) “Deployment” 的廚師。只是，他的工作比較通用化、沒有什么業(yè)務(wù)含義。

它只是負(fù)責(zé)守護(hù)用戶在 “菜單” 里面描述的 “進(jìn)程”(Pod) 數(shù)量，至于怎么起 “進(jìn)程” 都是用戶傳入的。

那么，我們是不是可以根據(jù)這個 “廚師” 的模仿出有業(yè)務(wù)含義的 “廚師”？比如，業(yè)界有一位比較出名的一個 “廚師”，是負(fù)責(zé) etcd 集群的。

如果我需要一個副本數(shù)是3的 etcd 集群，只要向 Kubernetes 提交如下的一個 “菜單”：

apiVersion: "etcd.database.coreos.com/v1beta2" 
 
kind: "EtcdCluster" 
 
metadata: 
 
name: "example-etcd-cluster" 
 
spec: 
 
size: 3 

“etcd廚師長” 就會根據(jù)這個 “菜單” 做出一個副本數(shù)是3（Spec.Size=3）的 etcd 集群給你。用戶不需要知道 3 副本的 etcd 集群里每個副本參數(shù)是什么樣的。

“etcd廚師長” 真實的名字叫 etcd-operator。顧名思義，operator 就是“廚師長”，“xxx-operator”就是 “xxx應(yīng)用-廚師長”。

在不久的將來，我覺得我們也會有 “xx-db-operator”，“xx-web-operator”，我們也用這種簡潔明了的聲明方式，快速得到一個 db 實例， 或者一個 “xx-web” 應(yīng)用。

回到怎么培養(yǎng)廚師長的話題，首先我們來介紹一下名詞:

1. CRD (CustomResourceDefinitions)：定義“滿漢全席”這樣的全家桶。Deployment 是 Kubernetes 官方的資源定義，Kubernetes 同時向開發(fā)者提供了 “自定義資源定義”。開發(fā)者可以向 Kubernetes 集群提交有 “滿漢全席” 的定義，那么當(dāng)用戶提交一桌 “滿漢全席” 時，Kubernetes 就明白用戶的請求了，也就是說 Kubernetes 知道用戶所說的 “滿漢全席” 是什么了。

2. CR (Custom Resources)：一個 CRD 實例，即一桌 “滿漢全席”，也就是類似上文一樣的 YAML 聲明。

3. Custom Controller：我們的“廚師長”。當(dāng) Controller 發(fā)現(xiàn)用戶提交了 一桌 “滿漢全席”，那么他就開始做菜了。當(dāng)然它并不是完全親自做每道菜，正如我上文所說。我們的 “廚師長” 可以依賴另一位 “廚師長”，比如 “db 廚師長” 可以依賴 “Deployment 廚師長”，當(dāng)用戶需要一個 db 實例的時候，“db 廚師長” 只需要負(fù)責(zé)再向 Kubernetes 提交一個 Deployment 聲明即可。

注意：“廚師長” 之間的交互也是靠 “CR” 或者 Kubernetes 官方定義的資源（如 Deployment、Pod）。“廚師長” 一般也是通過 Deployment 的方式部署在 Kubernetes 集群內(nèi)（保證了 “廚師長” 自身的穩(wěn)定性），除非像 “Deployment 廚師長” 這種 Kubernetes 核心 “廚師長”的穩(wěn)定性 由 Kubernetes 服務(wù)提供商保證。

4. Operator: Kubernetes 里的 Operator，即 CRD + Custom Controller。

一個簡單的圖將它們串起來：

上圖展示了我們的 My-App-Operator 的 “廚師長” 的關(guān)系圖。當(dāng)我們需要一個 “my-app” 應(yīng)用實例時，我們只要告訴我們的 “廚師長” 是需要多少副本數(shù)的實例。

我們的 “廚師長” 自動將需求轉(zhuǎn)化成 Deployment，其它的功能就完全依靠了 “Deployment 廚師長”。

如何面向 Kubernetes 寫一個 Operator

首先我們來看一下 “廚師長” (Operator) 需要關(guān)注一些什么事情，以及它做了什么事情：

1. 多久要開始做菜（Observe）：即 “廚師長” (Operator/Controller) 需要知道多久他要開始工作了。當(dāng)用戶提交了 “菜單”(CR)，“廚師長” 要開始做菜?；蛘撸驗?“桌子” 上少了一個預(yù)期中的 “菜”(Pod 因為故障少了一個)，“廚師長” 也要開始做菜了。
2. 做什么菜（Analyze）：“廚師長” 首先要看看桌子上的菜，再對比一下用戶的 “菜單”，得出還缺少什么菜，那么就做什么菜。
3. 開始做菜（Action）：得出做什么菜之后，那么后面的事情就簡單了。通知其他 “廚師長” 做菜（提交一個其他的CR），或者自己親手做個菜（提交一個 Pod）。

這 3 件事情，其實就是 Controller 模式的核心三件事：

那么用 Kubernetes 寫一個 Operator 需要多久？

可能從 “0” 到可以把 Operator 運行起來只需要 10分鐘吧。因為 Kubernetes 的 Kube-Apiserver 提供天然的 watch 接口，我們可以去關(guān)注我們在意的資源(我們的 CR，我們的 Pod 等)，這樣我們的 “廚師” 就能很自然的得到通知該干活了。

然后 “廚師” 就開始做出分析，到最后再向 Kube-Apiserver 提交我們想要的資源（Deployment，或者其它的 CR）。

我們都面向 Kube-Apiserver 做編程， 所有的“廚師”都 向 Kube-Apiserver 提交、修改、Watch資源作為統(tǒng)一的交互協(xié)議，一切都會變得簡單許多。

最后，再加上 Operator 的腳手架幫我們生成基礎(chǔ)代碼（初始化 Kubernetes 客戶端，建立 Watch 等），我們開發(fā)者只需要關(guān)心的怎么 Analyze 和 Action 即可。Operator 的腳手架社區(qū)常見的有 kube-builder 和 coreos 提供的 operator-framework 等。

我們用偽代碼來寫一下上文畫的 My-App-Operator 核心邏輯 （其它都腳手架做好了，甚至如何 build，Operator 本身它自己如何部署的“菜單” YAML 都是腳手架生成好了）：

// Reconcile 即我們 Operator 核心代碼邏輯 
 
// Reconcile 何時觸發(fā)，也是 Operator 生成好了 
 
func Reconcile(crName string) error { 
 
// 獲取 CR (用戶提交的“菜單”) 
 
cr := client.getCR(crName) 
 
// 計算出這個 CR 期望的 Deployment (用戶提交的“菜單”應(yīng)該在桌子上有什么菜) 
 
desireDeployment := getDesireDeployment(client, cr) 
 
// 目前集群里面實際的 Deployment (實際上桌子上有什么菜) 
 
deployment := client.GetDeployment(crName) 
 
// 如果期望和實際的不太一樣，把實際的更新一下就行了。if diff(desireDeployment, deployment) { 
 
return client.UpdateDeployment(desireDeployment); 
 
} 
 
// 如果期望和實際都一樣，什么事情都不做了。return nil 
 
} 

面向 Kubernetes 變成 和 Operator 的優(yōu)勢總結(jié)

1. 統(tǒng)一的信息獲取源和統(tǒng)一的接口：Kube-Apiserver 就像是一個大的信息流轉(zhuǎn)中心。所有的組件（“廚師長”）都通過這個中心上傳他負(fù)責(zé)的資源（CR，Deployment，Pod都是 Kubernetes 的資源）的信息，同時，他也通過這個接口，去感知其它資源狀態(tài)的變化，如果這些變化是他感興趣的，那么他就開始工作（“廚師長” 開始工作）。
2. 構(gòu)建在 Kubernetes 核心組件以及 社區(qū)通用的 Operator 之上：站在巨人的肩膀上能讓我們的工作更加的減負(fù)同時達(dá)到更加理想的效果。

上文中，我們的 Operator 可能在依賴 Deployment 之后，他負(fù)責(zé)的 “菜”（Pod）就自帶副本保持功能。同時，假如我們的應(yīng)用（DB，Web）要依賴社區(qū)的 MySQL 數(shù)據(jù)庫，那么我們的應(yīng)用 Operator（Web + DB） 可以通過社區(qū)的 MySQL-Operator 提供的 CR 快速建出 MySQL 實例，然后再使用 Deployment 建出 Web。

優(yōu)秀的社區(qū) Operator

優(yōu)秀的社區(qū) Operator (awesome-operators): 

https://github.com/operator-framework/awesome-operators

FaaS

用 Operator 交付軟件，目前看起來是最酷的一種交付軟件方式。

但是在當(dāng)今云原生技術(shù)快速發(fā)展的時代，可能在不久的將來，Operator 模式可能也會被淘汰。因為 Operator 也需要開發(fā)者關(guān)注一些部署的細(xì)節(jié)，讓開發(fā)者真正只關(guān)注在自己的業(yè)務(wù)邏輯，“業(yè)務(wù)代碼” 變成 “服務(wù)” 完全對開發(fā)者透明，可能需要比 Kubernetes 更上層的框架 - FaaS框架。

FaaS 全稱是 Function as a service 。用戶只要寫自己的業(yè)務(wù)函數(shù)，向 Kubernetes 提交業(yè)務(wù)函數(shù)，F(xiàn)aaS 框架將業(yè)務(wù)函數(shù)變成 Deployment，變成 Pod，變成 Service。但是 FaaS 目前還在發(fā)展階段，并不像 Kubernetes 已經(jīng)變成事實標(biāo)準(zhǔn)，這里不再詳細(xì)討論。

落地

說了那么多，其實我的初衷是希望每個開發(fā)者都從 Linux VM 轉(zhuǎn)向 Kubernetes “VM”。但是轉(zhuǎn)變發(fā)生在每個人身上，應(yīng)該是有各種困難。我能想到的一些最基本的困難大概列在下面，同時歡迎跟我交流你的一些困惑。

代碼變成鏡像

大家都知道，Kubernetes 只允許以 Pod 的方式運行“進(jìn)程”。在 FaaS 沒成熟之前，如何把我們的代碼變成一個鏡像是一個比較頭疼的事情。可能應(yīng)用的開發(fā)同學(xué)并不想自己去理解 docker，怎么去打鏡像。

別擔(dān)心！Spring 框架或者其擴(kuò)展的腳手架應(yīng)該已經(jīng)可以在工程里自動添加 Dockerfile 文件，使用腳手架之后，用戶只要執(zhí)行 make image 這樣的命令，就能構(gòu)建出鏡像了。

別說了，我還是想要一個 Linux VM

向 Kubernetes 提交下面這樣的一個 YAML 文件，你就能得到一個 ubuntu VM：

apiVersion: v1 
 
kind: Pod 
 
metadata: 
 
name: my-vm-1 
 
spec: 
 
containers: 
 
- name: vm 
 
image: ubuntu 

同時，告訴你一個更酷炫的玩法：自己定制一個屬于你自己的 Linux 發(fā)行版！在原有的 OS 鏡像基礎(chǔ)上，加上你的 Shell 工具腳本、寫一串向愛人表白的話、搞個開機(jī) Logo，都很簡單！

做一個屬于你自己的 Linux 鏡像，那么在世界的任何地方，你都能起動一個經(jīng)過你定制的 Linux VM。