[[285220]]

有很多人問我，平時(shí)是怎么看技術(shù)書的，我今天拿一個(gè)案例來講一下，你會(huì)看到，我主要靠“猜”，自己想想解決方案，然后到書中去驗(yàn)證。干貨內(nèi)容較多，建議靜心慢慢看。

1

我知道Docker是怎么回事，但是不太清楚Kubernetes究竟在干什么，它要解決什么問題?有哪些功能?在網(wǎng)上搜索了一些文章，可是都無法讓我滿意，因?yàn)樗麄兌际欠浅：暧^地講一講，然后馬上就進(jìn)入使用細(xì)節(jié)，讓人還是云里霧里。

之前我就說過，想深入地了解一門技術(shù)，最好的辦法就是看書，于是就去購書中心轉(zhuǎn)了一圈，發(fā)現(xiàn)一本書籍《Kubernetes in Action》，翻了一會(huì)兒我就覺得這本書不錯(cuò)，就拿它來學(xué)習(xí)吧。

(這里插入一句，我的公眾號(hào)文章只能講述一個(gè)技術(shù)的本質(zhì)問題，給大家一個(gè)大局觀，具體的細(xì)節(jié)還得去讀相關(guān)的書，有些人抱怨說通過我的文章學(xué)不會(huì)一個(gè)技術(shù)，那真是冤枉我了。)

2

這本書一開始就提到了微服務(wù)，這是個(gè)非常好的切入點(diǎn)，我腦海中立刻想到了微服務(wù)的特點(diǎn)，可以獨(dú)立部署，輕松擴(kuò)容。

那擴(kuò)容的時(shí)候具體該怎么做呢?例如有個(gè)訂單服務(wù)，我想把部署10份，難道我跑到服務(wù)器端，手工啟動(dòng)10個(gè)實(shí)例?

這肯定不符合自動(dòng)化運(yùn)維的方式，也許可以寫個(gè)腳本，接受一個(gè)參數(shù)或者讀取配置文件，把實(shí)例自動(dòng)創(chuàng)建起來。

但是仔細(xì)一想，這樣是不行的，因?yàn)楝F(xiàn)實(shí)中會(huì)有很多服務(wù)器，腳本怎么去管理呢?腳本怎么獲取它們的IP以及它們的負(fù)載情況，然后把Docker實(shí)例分發(fā)創(chuàng)建到合適的服務(wù)器中呢?

于是第一個(gè)猜測(cè)來了：

最好是有個(gè)系統(tǒng)，它能管理所有的服務(wù)器，我只要告訴他，把訂單服務(wù)的docker鏡像部署10份，剩下的事情就不用我管了，都由這個(gè)系統(tǒng)來搞定。

這時(shí)候我隱隱約約地感覺到了Kubernetes的核心功能。

于是我跳過了微服務(wù)的介紹，Docker的介紹，這些都是老掉牙的東西了，迅速翻到了第16頁：

這幅圖畫得相當(dāng)棒，清楚地展示了K8s的核心功能，但是仔細(xì)看以后，就發(fā)現(xiàn)有兩個(gè)微服務(wù)被放到了一起，作為一個(gè)整體來部署，這是我之前沒有想到的!

部署的最小粒度并不是Docker鏡像，而是另外一個(gè)東西!從系統(tǒng)設(shè)計(jì)的角度來看，必須得有個(gè)詞來表達(dá)，這個(gè)東西是什么?

于是我又往后翻，哦，原來這個(gè)詞叫做pod。

作者告訴我在第3章有詳細(xì)介紹，我迫不及待地往后翻，試圖滿足好奇心：pod到底是什么東西。

原來這些pod就像局域網(wǎng)中的一個(gè)個(gè)獨(dú)立的邏輯主機(jī)啊，每個(gè)Docker實(shí)例都是一個(gè)進(jìn)程。

3

到目前為止，我就明白了k8s本質(zhì)上是一層抽象，這一層抽象屏蔽了服務(wù)器的細(xì)節(jié)，程序員不需要知道程序運(yùn)行在哪個(gè)服務(wù)器上，只需要告訴k8s自己的需求就好。

那用什么方式來告訴k8s呢?這很容易猜測(cè)到，可以:

1. 通過命令行參數(shù)傳遞給k8s, 但是參數(shù)太受限。

2. 用配置文件，在其中可以指明pod的名稱，docker的鏡像名稱...... 可以用XML格式， JSON格式，YAML格式.....

當(dāng)然，這些念頭都是一閃而過，我翻開這本書的第3章，主要講pod，果然是用YAML,JSON去創(chuàng)建pod, 由于已經(jīng)預(yù)料到了，沒什么新意，稍微看了看就跳過。

讓我沒有想到的是可以使用標(biāo)簽和命名空間對(duì)pod進(jìn)行分組，但是講解有點(diǎn)啰嗦，似乎也不是核心概念，稍微翻了一下就過去了。

稍等 !為什么不在創(chuàng)建pod的時(shí)候指定pod的數(shù)量啊?比如我想創(chuàng)建10個(gè)訂單服務(wù)的docker實(shí)例，在哪里指定?仔細(xì)看看那些YAML文件，確實(shí)沒有副本數(shù)量，這k8s搞什么鬼?這里沒有指定，肯定在別的地方，那就是說：

除了pod之外，還有一個(gè)概念，用來指定pod和副本之間的關(guān)系，這個(gè)概念是什么?

4

快速翻到第4章，哈哈，原來這個(gè)概念叫做ReplicationController(簡(jiǎn)稱RC)，由它來保證pod的數(shù)目符合要求，多了就刪除，少了就添加。

從設(shè)計(jì)角度來看，再次體現(xiàn)了關(guān)注點(diǎn)分離，pod負(fù)責(zé)“靜態(tài)描述”，像一個(gè)模板，就像class， RC負(fù)責(zé)運(yùn)行時(shí)管理，來產(chǎn)生pod的object。

創(chuàng)建RC也是使用YAML，比較讓我意外的是，在指定pod時(shí)，用了前面所講的標(biāo)簽，看來標(biāo)簽是組織pod的重要方法，有時(shí)間回去看看細(xì)節(jié)。

需要注意的是，在管理pod數(shù)目的時(shí)候，用的是聲明式：“我想要運(yùn)行10個(gè)訂單實(shí)例”， 而不是“我想增加3個(gè)訂單實(shí)例”或“我想刪除3個(gè)訂單實(shí)例”。 你不用告訴k8s做什么、如何做，只是指定期望的狀態(tài)就好。

5

如果你也善于思考的話，這時(shí)候就會(huì)冒出了一個(gè)新問題：

這些pod 不斷地被刪除，被增加，不斷地變化，那外界怎么去訪問他們呢?

比如客戶端正在訪問pod1,然后pod1所在的機(jī)器掛掉，ReplicationController在另外一臺(tái)機(jī)器上創(chuàng)建了pod2，IP都變了，那客戶端下一次去訪問pod2呢?

如果讓我設(shè)計(jì)，我肯定得提供另外一個(gè)抽象層，讓這個(gè)抽象層來屏蔽后端的變化，讓客戶端連接到這個(gè)抽象層上。

k8s 會(huì)怎么做呢?第4章給出了答案：服務(wù)。 我個(gè)人覺得這個(gè)詞起得不好，太抽象，太廣泛。

可以看出，k8s和其他系統(tǒng)一樣，也是不斷地通過分離關(guān)注點(diǎn)，不斷地抽象來解決一個(gè)個(gè)問題的。

到目前為止，我腦海中想的都是那些“無狀態(tài)”的pod，可以隨意增加和刪除， 但肯定存在“有狀態(tài)”的pod，有持久化的需求，可以把數(shù)據(jù)存儲(chǔ)到硬盤上，這該怎么辦?

帶著這個(gè)問題，繼續(xù)上路吧!

6

好了，啰嗦了這么多，稍微總結(jié)一下：我希望給大家分享的就是，看書的時(shí)候要主動(dòng)思考，不要被動(dòng)接受。

帶著問題去看，自己先想想解決方案，然后到書中去驗(yàn)證，效率會(huì)非常高，讀起來會(huì)非?？?。

如果自己的問題在書中很快就得到回答，那讀起來就會(huì)酣暢淋漓;如果遲遲得不到回答，或者書中一直不厭其煩地描述細(xì)枝末節(jié)，那我很快就喪失興趣，把書扔掉。

當(dāng)然，由于每個(gè)人的基礎(chǔ)不同，可能剛開始讀書的時(shí)候提不出問題，或者提不出有價(jià)值的問題，這時(shí)候可以去直接看具體內(nèi)容，但是不能放棄思考：這個(gè)技術(shù)點(diǎn)是要解決什么問題的?是怎么解決的?

希望每個(gè)人都建立一套自己的知識(shí)體系，從這個(gè)知識(shí)體系中能伸出很多的觸角，能像海綿一樣吸收外界的知識(shí)，不斷地為自己的知識(shí)體系添磚加瓦。