K8S目前是業(yè)界容器編排領(lǐng)域的事實標準，是幾乎所有云原生架構(gòu)的首選。目前隨著云原生架構(gòu)越來越流行，測試開發(fā)人員需要掌握K8S技術(shù)棧已經(jīng)成為越來越迫切的需求。
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 個案例來帶大家體驗一下其中的奧妙。

01
在實際介紹 K8S 的容器編排實例前需要先了解一下 K8S 中最基本的資源類型－－POD?？梢哉f 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é)束后回收這些資源。

yaml
apiVersion: "v1"
kind: "Pod"
metadata:
name: "sdk-test-109-hpf67-tr47k-95sch"
spec:
containers:
- command:
- "cat"
image: "http://registry.gaofei.com/qa/python3"
name: "python3"
tty: true
volumeMounts:
- mountPath: "/home/jenkins/agent"
name: "workspace-volume"
readOnly: false
image: "http://registry.gaofei.com/tester_jenkins_slave:v1"
name: "jnlp"
volumeMounts:
- mountPath: "/home/jenkins/agent"
name: "workspace-volume"
readOnly: false
volumes:
- emptyDir:
medium: ""
name: "workspace-volume"

上面是 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 中的定義，還是照例刪減了其他干擾項。

groovy
pipeline{
parameters {
choice(name: 'PLATFORM_FILTER', choices: ['python352', 'python368', 'python376','all'], description: '選擇測試的 python 版本')
}
agent{
kubernetes{
yaml """
apiVersion: v1
kind: Pod
metadata:
labels:
qa: python3
spec:
containers:
- name: python352
image: python:3.5.2
command:
- cat
tty: true
- name: python368
image: python:3.6.8
command:
- cat
tty: true
- name: python376
image: python:3.7.6
command:
- cat
tty: true
- name: jnlp
image:?http://registry.gaofie.com/tester_jenkins_slave:v1
"""
}
}
stages{
stage('sdk 兼容性測試'){
matrix {
when { anyOf {
expression { params.PLATFORM_FILTER == 'all' }
} }
axes {
axis {
name 'PLATFORM'
values 'python352', 'python368','python376'

}
}
stages{
stage('兼容性測試開始 '){
steps{
container("${PLATFORM}"){
echo "Testing planform ${PLATFORM}"
sh """
pip3 install -i?http://pypi.xxx.com/4paradigm/dev/?--trusted-host?http://pypi.xxx.com?'sdk[builtin-operators]'
pip3 install -r requirements.txt
cd test
python3 -m pytest -n 5
"""
}
}
}
}
}

}
}
}

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

yaml
image: "http://registry.gaofei.com/tester_jenkins_slave:v1"
name: "jnlp"
volumeMounts:
- mountPath: "/home/jenkins/agent"
name: "workspace-volume"
readOnly: false
volumes:
- emptyDir:
medium: ""
name: "workspace-volume"

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

mpdir.jpg ‘tempdir’)

實際上多個容器間的合作不僅可以共享目錄，也可以共享網(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容器編排了有了初步的了解，在下篇文章中，我們將通過介紹 K8S 中專門運行批處理程序的資源類型：JOB 的機制再來體會一下容器編排在其他方面的威力。