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

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

文章 Markdown 源碼位于

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

導(dǎo)言

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

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

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

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

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

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

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

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

說(shuō)到這里，大家估計(jì)立刻就有疑問(wèn)了。我想大概是這些：

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

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

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

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

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

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

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

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

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

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

A:

 

“一頓操作猛如虎” 聽(tīng)起來(lái)很酷，但是你在做一些沒(méi)必要的事情，同時(shí)你做了這些事情并不討好你的老板，可能在因?yàn)槟愕氖д`操作引起更大的故障和問(wèn)題。

 

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

A: 行了行了，別說(shuō)那么多了，我還是需要一個(gè) Linux VM。

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

小試牛刀

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

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

沒(méi)有 Kubernetes 之前的部署

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

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

有了 Kubernetes 的部署

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

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

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 

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

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

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

容災(zāi)

Deployment 能自動(dòng)副本保持，即我們的 nginx Pod 少了一個(gè)，Kubernetes 能自動(dòng)幫我們補(bǔ)齊。

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

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

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

Deployment 支持滾動(dòng)升級(jí)，在升級(jí)時(shí)可以一個(gè)個(gè)升級(jí)你的 Pod（滾動(dòng)升級(jí)）。

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

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

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

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

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

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

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

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

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

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

談軟件交付

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

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

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

軟件交付方案的歷史：

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

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

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

你可能會(huì)告訴我，你說(shuō)的這些我們的 PaaS 系統(tǒng)都能搞定。是的，你說(shuō)的沒(méi)錯(cuò)！但是當(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)聽(tīng)每個(gè)應(yīng)用的實(shí)例變化（自動(dòng)化感知故障發(fā)生）然后自動(dòng)恢復(fù)（副本保持），那么它就已經(jīng)差不多是 Kubernetes 了。

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

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

面向 Kubernetes 交付軟件

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

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

這個(gè)上萬(wàn)行的 YAML 誰(shuí)來(lái)維護(hù)？就算是分開(kāi)給各個(gè)子應(yīng)用的 owner 維護(hù)，是不是也可能會(huì)發(fā)生牽一發(fā)而動(dòng)全身。有沒(méi)有更加簡(jiǎn)單的方式？

當(dāng)然有。我們?cè)倩貋?lái)談 “菜單” 和做菜。我是一個(gè)吃貨，但是我很懶。當(dāng)我點(diǎn)菜的時(shí)候，非常希望點(diǎn)一個(gè) “套餐”，而不希望一個(gè)個(gè)的去點(diǎn)每個(gè)菜，更不希望弄懂菜是怎么做出來(lái)的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在不久的將來(lái)，我覺(jué)得我們也會(huì)有 “xx-db-operator”，“xx-web-operator”，我們也用這種簡(jiǎn)潔明了的聲明方式，快速得到一個(gè) db 實(shí)例， 或者一個(gè) “xx-web” 應(yīng)用。

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

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

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

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

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

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

一個(gè)簡(jiǎn)單的圖將它們串起來(lái)：

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

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

如何面向 Kubernetes 寫一個(gè) Operator

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

1. 多久要開(kāi)始做菜（Observe）：即 “廚師長(zhǎng)” (Operator/Controller) 需要知道多久他要開(kāi)始工作了。當(dāng)用戶提交了 “菜單”(CR)，“廚師長(zhǎng)” 要開(kāi)始做菜?；蛘?，因?yàn)?“桌子” 上少了一個(gè)預(yù)期中的 “菜”(Pod 因?yàn)楣收仙倭艘粋€(gè))，“廚師長(zhǎng)” 也要開(kāi)始做菜了。
2. 做什么菜（Analyze）：“廚師長(zhǎng)” 首先要看看桌子上的菜，再對(duì)比一下用戶的 “菜單”，得出還缺少什么菜，那么就做什么菜。
3. 開(kāi)始做菜（Action）：得出做什么菜之后，那么后面的事情就簡(jiǎn)單了。通知其他 “廚師長(zhǎng)” 做菜（提交一個(gè)其他的CR），或者自己親手做個(gè)菜（提交一個(gè) Pod）。

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

那么用 Kubernetes 寫一個(gè) Operator 需要多久？

可能從 “0” 到可以把 Operator 運(yùn)行起來(lái)只需要 10分鐘吧。因?yàn)?Kubernetes 的 Kube-Apiserver 提供天然的 watch 接口，我們可以去關(guān)注我們?cè)谝獾馁Y源(我們的 CR，我們的 Pod 等)，這樣我們的 “廚師” 就能很自然的得到通知該干活了。

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

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

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

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

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

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

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

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

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

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

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

FaaS

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

但是在當(dāng)今云原生技術(shù)快速發(fā)展的時(shí)代，可能在不久的將來(lái)，Operator 模式可能也會(huì)被淘汰。因?yàn)?Operator 也需要開(kāi)發(fā)者關(guān)注一些部署的細(xì)節(jié)，讓開(kāi)發(fā)者真正只關(guān)注在自己的業(yè)務(wù)邏輯，“業(yè)務(wù)代碼” 變成 “服務(wù)” 完全對(duì)開(kāi)發(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)變成事實(shí)標(biāo)準(zhǔn)，這里不再詳細(xì)討論。

落地

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

代碼變成鏡像

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

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

別說(shuō)了，我還是想要一個(gè) Linux VM

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

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

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

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