[[285220]]

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

1

我知道Docker是怎么回事，但是不太清楚Kubernetes究竟在干什么，它要解決什么問題?有哪些功能?在網上搜索了一些文章，可是都無法讓我滿意，因為他們都是非常宏觀地講一講，然后馬上就進入使用細節，讓人還是云里霧里。

之前我就說過，想深入地了解一門技術，最好的辦法就是看書，于是就去購書中心轉了一圈，發現一本書籍《Kubernetes in Action》，翻了一會兒我就覺得這本書不錯，就拿它來學習吧。

(這里插入一句，我的公眾號文章只能講述一個技術的本質問題，給大家一個大局觀，具體的細節還得去讀相關的書，有些人抱怨說通過我的文章學不會一個技術，那真是冤枉我了。)

2

這本書一開始就提到了微服務，這是個非常好的切入點，我腦海中立刻想到了微服務的特點，可以獨立部署，輕松擴容。

那擴容的時候具體該怎么做呢?例如有個訂單服務，我想把部署10份，難道我跑到服務器端，手工啟動10個實例?

這肯定不符合自動化運維的方式，也許可以寫個腳本，接受一個參數或者讀取配置文件，把實例自動創建起來。

但是仔細一想，這樣是不行的，因為現實中會有很多服務器，腳本怎么去管理呢?腳本怎么獲取它們的IP以及它們的負載情況，然后把Docker實例分發創建到合適的服務器中呢?

于是第一個猜測來了：

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

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

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

這幅圖畫得相當棒，清楚地展示了K8s的核心功能，但是仔細看以后，就發現有兩個微服務被放到了一起，作為一個整體來部署，這是我之前沒有想到的!

部署的最小粒度并不是Docker鏡像，而是另外一個東西!從系統設計的角度來看，必須得有個詞來表達，這個東西是什么?

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

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

原來這些pod就像局域網中的一個個獨立的邏輯主機啊，每個Docker實例都是一個進程。

3

到目前為止，我就明白了k8s本質上是一層抽象，這一層抽象屏蔽了服務器的細節，程序員不需要知道程序運行在哪個服務器上，只需要告訴k8s自己的需求就好。

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

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

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

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

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

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

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

4

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

從設計角度來看，再次體現了關注點分離，pod負責“靜態描述”，像一個模板，就像class， RC負責運行時管理，來產生pod的object。

創建RC也是使用YAML，比較讓我意外的是，在指定pod時，用了前面所講的標簽，看來標簽是組織pod的重要方法，有時間回去看看細節。

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

5

如果你也善于思考的話，這時候就會冒出了一個新問題：

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

比如客戶端正在訪問pod1,然后pod1所在的機器掛掉，ReplicationController在另外一臺機器上創建了pod2，IP都變了，那客戶端下一次去訪問pod2呢?

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

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

可以看出，k8s和其他系統一樣，也是不斷地通過分離關注點，不斷地抽象來解決一個個問題的。

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

帶著這個問題，繼續上路吧!

6

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

帶著問題去看，自己先想想解決方案，然后到書中去驗證，效率會非常高，讀起來會非常快。

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

當然，由于每個人的基礎不同，可能剛開始讀書的時候提不出問題，或者提不出有價值的問題，這時候可以去直接看具體內容，但是不能放棄思考：這個技術點是要解決什么問題的?是怎么解決的?

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