Kubernetes 開源于 2014 年，是谷歌 10 多年大規(guī)模容器管理系統(tǒng) Borg 的開源版本。Kubernetes 這個 單詞在首字母 K 和尾字母 s 之間有 8 個字母，因此稱為 K8S。這種稱謂方式和 i18n （internationalization）是一致的，如果做過本地化國際化的人應(yīng)該對 i18n 這樣的叫法很熟悉。 對于一 個剛剛接觸容器的初學者來說，搞清楚容器編排是什么，搞清楚 K8S 是什么是一件非常不容易的事 情。 編排二字賦予了它非常多的意義。

大多數(shù)人理解 K8S 是容器集群的管理技術(shù)，這個描述是不完整的，如果 K8S 僅僅是一個管理多臺節(jié)點 上容器的管理軟件的話，那么業(yè)界直接稱呼為容器集群就好了。而不是像現(xiàn)在這樣稱其為容器編排領(lǐng)域 的事實標準，谷歌和 Linux 也不會為了它一起創(chuàng)辦了 CNCF 云原生基金會。 所以 K8S 除了是一個容 器集群管理軟件外它還提供了針對容器的網(wǎng)絡(luò)，調(diào)度，權(quán)限，資源，安全，硬件等管理和設(shè)計的能力。 接下來通過 2 個案例來帶大家體驗一下其中的奧妙。

POD 介紹

在實際介紹 K8S 的容器編排實例前需要先了解一下 K8S 中最基本的資源類型－－POD。 可以說 POD 是 K8S 中最重要的資源，其他一切的資源都是圍繞著 POD 并為其提供服務(wù)的。

用一句話說明 POD 的定義： POD 是由多個容器組成的邏輯概念，這些容器共同配合對外提供服務(wù)， 同時 POD 也是 K8S 中最小的調(diào)度單位，POD 中的容器必須調(diào)度在同一臺機器上不可分割。

這么說比較抽象，用一個實例來展示一下 POD 到底是什么。 通過下載并配置 jenkins 中 K8S 的插件 來打通兩者之間的通信，使得 jenkins 在運行 pipeline 時可以動態(tài)的在 K8S 中創(chuàng)建 POD 并在其中一個 容器中通過 jnlp 動態(tài)的創(chuàng)建并向 jenkins 注冊 slave 節(jié)點（容器）， 后續(xù)這個 pipeline 中所有的任務(wù) 都將在這個 POD 中的容器中執(zhí)行。

通過這樣的機制實現(xiàn)了更強大的 jenkins pipeline 的高可用和負載均衡架構(gòu)。 從此實現(xiàn)了在 K8S 中可以 動態(tài)創(chuàng)建 jenkins 的 slave 節(jié)點運行任務(wù)的能力， 并在任務(wù)結(jié)束后回收這些資源。

上面是 jenkins 動態(tài)創(chuàng)建 POD 的配置文件，這其中為了更方便說明我刪除了很多其他干擾項，只留下 了最需要關(guān)注的部分?？梢钥吹?containers 字段中定義兩個容器。其中名字為 jnlp 的容器是由 jenkins 提供用來與 jenkins 建立通信并注冊 slave 節(jié)點用的。 對 jenkins slave 節(jié)點配置比較熟悉的人對此應(yīng)該 并不陌生，除了 jnlp 外 jenkins 還支持 ssh 等協(xié)議形式的 slave 通信機制。

另外一個名字為 python3 的容器使用的就是官方提供的 python3 鏡像，它的任務(wù)是用來執(zhí)行測試任務(wù)。 也就是說在這個 POD 中分工是明確的，jnlp 容器負責注冊 jenkins slave 節(jié)點并與之保持通信。而 python3 容器擁有 python 的執(zhí)行環(huán)境所以可以在獲取代碼后運行諸如 pytest 這樣的測試任務(wù)。實際上 如果需要可以定義更多的容器，比如要測試一款 python sdk 的兼容性的時候， 可以再定義一個 python2.6 的容器，這樣在 pipeline 中可以通過切換不同的容器達到切換運行環(huán)境的目的以便測試 sdk 在 python3 和 python2 上的兼容性。

下面貼一下 jenkins pipeline 中的定義，還是照例刪減了其他干擾項。

通過上面的 Pipeline 的配置可以看到通過 container 指令，可以在 pipeline 中任意的切換容器（運行環(huán) 境）來完成 Python 的兼容性測試。這里可能有人可能會問運行環(huán)境可以通過切換容器來完成，但是各 個容器之間是怎么共享文件和代碼的呢？ 畢竟要執(zhí)行測試必須先獲取代碼， 那這些容器是怎么獲取代 碼執(zhí)行測試的，又是通過什么方式合并每個容器中的測試報告的呢？ 這個問題可以抽象成一個 POD 中 的容器是怎么共享文件的。 在學習 Docker 的時候知道在啟動容器的時候可以通過-v 這個參數(shù)來將容 器中的某個目錄或文件掛載到宿主機上， 而在 POD 中的玩法也類似。 回到上面 Jenkins 啟動的 POD 的定義中來：

上面是 POD 中關(guān)于數(shù)據(jù)卷的一段定義， 可以看到 jenkins 創(chuàng)建的 POD 定義中自動添加了一個臨時的 共享目錄，而 POD 中所有的容器都會掛載這個目錄。 通過這樣的形式達到了所有容器共享文件的目 的。 而這個目錄就是 Jenkins 的 Workspace。相信熟悉 Jenkins 的人對此目錄不會感到陌生。

實際上多個容器間的合作不僅可以共享目錄，也可以共享網(wǎng)絡(luò)或者進程名稱空間。 還記得學習 Docker 的時候使用的 container 網(wǎng)絡(luò)模式么， 實際上 POD 中的容器都是默認通過 container 模式將網(wǎng)絡(luò)連接 在一起的，很多軟件應(yīng)用比如 mock server，流量復(fù)制，service mesh 都是通過在 POD 中額外定義一個 proxy 容器劫持業(yè)務(wù)容器的網(wǎng)絡(luò)。

而如果你想使用 jvm-sandbox 這種字節(jié)碼注入工具的話還可以通過打開 POD 中 shareProcessNamespace 這個參數(shù)來共享進程名稱空間，使得 jvm-sandbox 容器中可以看到業(yè)務(wù)容器的 進程并以 jvm-attach 的方式進行字節(jié)碼注入。 而這種通過啟動多個容器互相協(xié)作配合的玩法有一個專 業(yè)名詞叫"side car"。

所以回過頭來看看什么是 POD，什么是容器編排？ 從這里的角度看 POD 是容器之間的一種協(xié)作模 式，多個容器組成一個 POD，而一個 POD 提供了多種機制，包括但不限于共享和限制目錄，網(wǎng)絡(luò)，進 程，資源等機制來讓容器之間的協(xié)作更加順暢， 而這也是容器編排的表現(xiàn)之一， 不僅僅是運行， 而 是多個容器配合在一起更好的運行。

接下來再看一個 K8S 中專門運行批處理程序的資源類型：JOB。 通過介紹 JOB 的機制再來體會一下容 器編排在其他方面的威力。

批處理任務(wù)編排

實際上多個容器間的合作不僅可以共享目錄，也可以共享網(wǎng)絡(luò)或者進程名稱空間。 還記得學習 Docker 的時候使用的 container 網(wǎng)絡(luò)模式么， 實際上 POD 中的容器都是默認通過 container 模式將網(wǎng)絡(luò)連接 在一起的，很多軟件應(yīng)用比如 mock server，流量復(fù)制，service mesh 都是通過在 POD 中額外定義一個 proxy 容器劫持業(yè)務(wù)容器的網(wǎng)絡(luò)。 而如果你想使用 jvm-sandbox 這種字節(jié)碼注入工具的話還可以通過打開 POD 中 shareProcessNamespace 這個參數(shù)來共享進程名稱空間，使得 jvm-sandbox 容器中可以看到業(yè)務(wù)容器的 進程并以 jvm-attach 的方式進行字節(jié)碼注入。 而這種通過啟動多個容器互相協(xié)作配合的玩法有一個專 業(yè)名詞叫"side car"。 所以回過頭來看看什么是 POD，什么是容器編排？ 從這里的角度看 POD 是容器之間的一種協(xié)作模 式，多個容器組成一個 POD，而一個 POD 提供了多種機制，包括但不限于共享和限制目錄，網(wǎng)絡(luò)，進 程，資源等機制來讓容器之間的協(xié)作更加順暢， 而這也是容器編排的表現(xiàn)之一， 不僅僅是運行， 而 是多個容器配合在一起更好的運行。 接下來再看一個 K8S 中專門運行批處理程序的資源類型：JOB。 通過介紹 JOB 的機制再來體會一下容 器編排在其他方面的威力。

上面定義的是向 K8S 提交一個 job 類型的也即是批處理程序請求的配置文件， 將這個配置文件保存為 yaml 文件后就可以通過 kubectl 命令行將任務(wù)提交到 K8S 集群中運行了， job 會幫助創(chuàng)建相應(yīng)的 POD 來完成任務(wù)。 雖然我已經(jīng)對這段配置做了一定程度的刪減，但仍然有不少的字段類型容易讓新手眼花繚 亂。 不過本次案例只需關(guān)注幾個重點的地方，第一個是在文件中的 template 字段， 它代表了 POD 的 模板， job 通過此模板來動態(tài)的創(chuàng)建 POD，它定義了本次執(zhí)行測試的運行環(huán)境， 也就是測試是在 POD 中的容器中執(zhí)行的。 K8S 會根據(jù)用戶填寫的內(nèi)容來啟動 POD。 第二個需要注意的地方是配置中 最下面的 3 個字段：

backoffLimit：可容忍的失敗次數(shù)。 穩(wěn)定性測試是要長期執(zhí)行的，而任何長期執(zhí)行的任務(wù)都無法保 證在運行過程中 100% 的不出問題，有些時候網(wǎng)絡(luò)卡頓或者公司內(nèi)的一些基礎(chǔ)設(shè)施的臨時中斷都可 能造成測試的失敗。所以 K8S 會在任務(wù)失敗時嘗試進行重試（當整個節(jié)點出現(xiàn)異常時，K8S 可以 將容器調(diào)度到其他節(jié)點上重試執(zhí)行，擁有更好的容錯能力），而這個字段可以理解為重試的次數(shù)

parallelism：并行的數(shù)量。 如果你的批處理任務(wù)需要并發(fā)能力，那么 K8S 會按照這個字段的數(shù)字 同時啟動多個容器來并發(fā)的執(zhí)行。 由于大部分的測試并發(fā)能力來源于測試框架而不是外部軟件， 所以本次測試在這里填寫為 1 就可以。

completions：任務(wù)成功執(zhí)行 N 次后結(jié)束任務(wù)。 即便是像穩(wěn)定性測試這種需要長期運行的測試類 型，它也有結(jié)束測試的時候。 所以把這個參數(shù)設(shè)定為 1000 代表當測試重復(fù)運行了 1000 次后就 結(jié)束本次的批處理任務(wù)。

注意：每次測試運行結(jié)束后，K8S 會銷毀當前的容器，并啟動一個一模一樣的新容器來執(zhí)行新的任務(wù)。 也就是在的案例里如果不出意外的話，前后會啟動 1000 個容器來完成本次的穩(wěn)定性測試。通過這樣一 個案例的講解可以體會一下相比于原生的 Docker 容器，K8S 帶來了多少額外的能力。在 K8S 中容器只 不過是程序的運行時環(huán)境而已，除了程序能運行起來，K8S 更關(guān)注的是程序怎樣更好的運行。通過上面 針對配置文件最后 3 個字段的講解可以看出來 K8S 在嘗試幫助用戶解決更復(fù)雜的程序運行問題。在本 案例中如果不使用 K8S，用戶需要編寫自己的模塊來控制測試用例的重復(fù)執(zhí)行，并發(fā)，容錯和重試機 制，也就是說用戶需要自己編寫代碼來對測試用例進行＂編排＂。在傳統(tǒng)的容器場景中，很多人都會把 容器當做一個小型的虛擬機來使用--只要程序能在容器里跑起來就可以了。這種模式并不具備＂編排＂ 的思維能力，真實的企業(yè)場景下要求的不僅僅是把程序跑起來就可以了，還關(guān)心容器調(diào)度到什么節(jié)點， 什么時候觸發(fā)和結(jié)束任務(wù)，當任務(wù)出現(xiàn)異常時要如何處理，容器和容器之前如何配合以便完成更大的任 務(wù)等等。這便是 K8S 提供的＂容器編排＂了。希望讀者可以用心體會"容器編排"這 4 個字的含義。

接下來再看一下，如果希望任務(wù)能夠定時觸發(fā)該怎么辦呢？K8S 中同樣提供了 CronJob 類型的任務(wù)，可 以看到在 schedule 字段中可以填寫 cron 表達式來定時啟動容器完成的批處理任務(wù)。

實際上，目前看到的編排能力仍然是 K8S 的冰山一角，K8S 目前已經(jīng)成為了分布式計算平臺，支持很 多大數(shù)據(jù)和機器學習的計算框架比如 Spark 和 Flink。 下面是將 Spark 任務(wù)調(diào)度到 K8S 中執(zhí)行的 Demo。

熟悉大數(shù)據(jù)領(lǐng)域的人都知道 Hadoop 是分布式計算領(lǐng)域中最流行的調(diào)度平臺。 提交的 Spark 任務(wù)都會 被調(diào)度到 Hadoop 集群中進行調(diào)度，運行。 但是 K8S 也同樣具備這樣的能力，通過下載支持 K8S 的 Spark 安裝包就可以使用 spark-submit 命令將任務(wù)提交到 K8S 上以容器的形態(tài)執(zhí)行，在參數(shù)中可以指定 使用多少個 executor，每個 executor 申請多少資源等等。 這便是 K8S 的魅力，如果你深入了解 K8S 會發(fā)現(xiàn)更多有趣又好用的功能。

總結(jié)

實際上除了上面講的能力外，K8S 還包含了非常多的容器編排能力，尤其對于在線服務(wù)的編排能力上尤 為強大， 但這部分內(nèi)容留待后續(xù)講解。 最后附上一個最簡單的 K8S 流程圖幫助大家理解。畢竟 K8S 還是一個集群管理軟件，上述說明的所有案例在提交給 K8S 后， K8S 都會按照自己的調(diào)度策略將 POD 調(diào)度到一個合適的節(jié)點上執(zhí)行。