作者 | 聲東? 阿里云售后技術(shù)專家
創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供忻城網(wǎng)站建設(shè)、忻城做網(wǎng)站、忻城網(wǎng)站設(shè)計(jì)、忻城網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)與制作、忻城企業(yè)網(wǎng)站模板建站服務(wù)，10余年忻城做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
導(dǎo)讀：不知道大家有沒(méi)有意識(shí)到一個(gè)現(xiàn)實(shí)：大部分時(shí)候，我們已經(jīng)不像以前一樣，通過(guò)命令行，或者可視窗口來(lái)使用一個(gè)系統(tǒng)了。
現(xiàn)在我們上微博、或者網(wǎng)購(gòu)，操作的其實(shí)不是眼前這臺(tái)設(shè)備，而是一個(gè)又一個(gè)集群。通常，這樣的集群擁有成百上千個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)是一臺(tái)物理機(jī)或虛擬機(jī)。集群一般遠(yuǎn)離用戶，坐落在數(shù)據(jù)中心。為了讓這些節(jié)點(diǎn)互相協(xié)作，對(duì)外提供一致且高效的服務(wù)，集群需要操作系統(tǒng)。Kubernetes 就是這樣的操作系統(tǒng)。
比較 Kubernetes 和單機(jī)操作系統(tǒng)，Kubernetes 相當(dāng)于內(nèi)核，它負(fù)責(zé)集群軟硬件資源管理，并對(duì)外提供統(tǒng)一的入口，用戶可以通過(guò)這個(gè)入口來(lái)使用集群，和集群溝通。
而運(yùn)行在集群之上的程序，與普通程序有很大的不同。這樣的程序，是“關(guān)在籠子里”的程序。它們從被制作，到被部署，再到被使用，都不尋常。我們只有深挖根源，才能理解其本質(zhì)。
我們使用 go 語(yǔ)言寫了一個(gè)簡(jiǎn)單的 web 服務(wù)器程序 app.go，這個(gè)程序監(jiān)聽(tīng)在 2580 這個(gè)端口。通過(guò) http 協(xié)議訪問(wèn)這個(gè)服務(wù)的根路徑，服務(wù)會(huì)返回 "This is a small app for kubernetes..." 字符串。
重慶分公司
重慶分公司
package main
import (
"github.com/gorilla/mux"
"log"
"net/http"
)
func about(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("This is a small app for kubernetes...\n"))
}
func main() {
r := mux.NewRouter()
r.HandleFunc("/", about)
log.Fatal(http.ListenAndServe("0.0.0.0:2580", r))
}使用 go build 命令編譯這個(gè)程序，產(chǎn)生 app 可執(zhí)行文件。這是一個(gè)普通的可執(zhí)行文件，它在操作系統(tǒng)里運(yùn)行，會(huì)依賴系統(tǒng)里的庫(kù)文件。
# ldd app
linux-vdso.so.1 => (0x00007ffd1f7a3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f554fd4a000)
libc.so.6 => /lib64/libc.so.6 (0x00007f554f97d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f554ff66000)為了讓這個(gè)程序不依賴于操作系統(tǒng)自身的庫(kù)文件，我們需要制作容器鏡像，即隔離的運(yùn)行環(huán)境。Dockerfile 是制作容器鏡像的“菜譜”。我們的菜譜就只有兩個(gè)步驟，下載一個(gè) centos 的基礎(chǔ)鏡像，把 app 這個(gè)可執(zhí)行文件放到鏡像中 /usr/local/bin 目錄中去。
FROM centos
ADD app /usr/local/bin制作好的鏡像存再本地，我們需要把這個(gè)鏡像上傳到鏡像倉(cāng)庫(kù)里去。這里的鏡像倉(cāng)庫(kù)，相當(dāng)于應(yīng)用商店。我們使用阿里云的鏡像倉(cāng)庫(kù)，上傳之后鏡像地址是:
registry.cn-hangzhou.aliyuncs.com/kube-easy/app:latest鏡像地址可以拆分成四個(gè)部分：倉(cāng)庫(kù)地址/命名空間/鏡像名稱:鏡像版本。顯然，鏡像上邊的鏡像，在阿里云杭州鏡像倉(cāng)庫(kù)，使用的命名空間是 kube-easy，鏡像名:版本是 app:latest。至此，我們有了一個(gè)可以在 Kubernetes 集群上運(yùn)行的、“關(guān)在籠子里”的小程序。
Kubernetes 作為操作系統(tǒng)，和普通的操作系統(tǒng)一樣，有 API 的概念。有了 API，集群就有了入口；有了 API，我們使用集群，才能得其門而入。Kubernetes 的 API 被實(shí)現(xiàn)為運(yùn)行在集群節(jié)點(diǎn)上的組件 API Server。這個(gè)組件是典型的 web 服務(wù)器程序，通過(guò)對(duì)外暴露 http(s) 接口來(lái)提供服務(wù)。
.jpg)
這里我們創(chuàng)建一個(gè)阿里云 Kubernetes 集群。登錄集群管理頁(yè)面，我們可以看到 API Server 的公網(wǎng)入口。
API Server 內(nèi)網(wǎng)連接端點(diǎn)： https://xx.xxx.xxx.xxx:6443阿里云 Kubernetes 集群 API Server 組件，使用基于 CA 簽名的雙向數(shù)字證書認(rèn)證來(lái)保證客戶端與 api server 之間的安全通信。這句話很繞口，對(duì)于初學(xué)者不太好理解，我們來(lái)深入解釋一下。
從概念上來(lái)講，數(shù)字證書是用來(lái)驗(yàn)證網(wǎng)絡(luò)通信參與者的一個(gè)文件。這和學(xué)校頒發(fā)給學(xué)生的畢業(yè)證書類似。在學(xué)校和學(xué)生之間，學(xué)校是可信第三方 CA，而學(xué)生是通信參與者。如果社會(huì)普遍信任一個(gè)學(xué)校的聲譽(yù)的話，那么這個(gè)學(xué)校頒發(fā)的畢業(yè)證書，也會(huì)得到社會(huì)認(rèn)可。參與者證書和 CA 證書可以類比畢業(yè)證和學(xué)校的辦學(xué)許可證。
這里我們有兩類參與者，CA 和普通參與者；與此對(duì)應(yīng)，我們有兩種證書，CA 證書和參與者證書；另外我們還有兩種關(guān)系，證書簽發(fā)關(guān)系以及信任關(guān)系。這兩種關(guān)系至關(guān)重要。
我們先看簽發(fā)關(guān)系。如下圖，我們有兩張 CA 證書，三個(gè)參與者證書。
其中最上邊的 CA 證書，簽發(fā)了兩張證書，一張是中間的 CA 證書，另一張是右邊的參與者證書；中間的 CA 證書，簽發(fā)了下邊兩張參與者證書。這六張證書以簽發(fā)關(guān)系為聯(lián)系，形成了樹(shù)狀的證書簽發(fā)關(guān)系圖。
.jpg)
然而，證書以及簽發(fā)關(guān)系本身，并不能保證可信的通信可以在參與者之間進(jìn)行。以上圖為例，假設(shè)最右邊的參與者是一個(gè)網(wǎng)站，最左邊的參與者是一個(gè)瀏覽器，瀏覽器相信網(wǎng)站的數(shù)據(jù)，不是因?yàn)榫W(wǎng)站有證書，也不是因?yàn)榫W(wǎng)站的證書是 CA 簽發(fā)的，而是因?yàn)闉g覽器相信最上邊的 CA，也就是信任關(guān)系。
理解了 CA（證書），參與者（證書），簽發(fā)關(guān)系，以及信任關(guān)系之后，我們回過(guò)頭來(lái)看“基于 CA 簽名的雙向數(shù)字證書認(rèn)證”。客戶端和 API Server 作為通信的普通參與者，各有一張證書。而這兩張證書，都是由 CA 簽發(fā)，我們簡(jiǎn)單稱它們?yōu)榧?CA 和客戶端 CA。客戶端信任集群 CA，所以它信任擁有集群 CA 簽發(fā)證書的 API Server；反過(guò)來(lái) API Server 需要信任客戶端 CA，它才愿意與客戶端通信。
阿里云 Kubernetes 集群，集群 CA 證書，和客戶端 CA 證書，實(shí)現(xiàn)上其實(shí)是一張證書，所以我們有這樣的關(guān)系圖。
.jpg)
登錄集群管理控制臺(tái)，我們可以拿到 KubeConfig 文件。這個(gè)文件包括了客戶端證書，集群 CA 證書，以及其他。證書使用 base64 編碼，所以我們可以使用 base64 工具解碼證書，并使用 openssl 查看證書文本。
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 787224 (0xc0318)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
Validity
Not Before: Nov 29 06:03:00 2018 GMT
Not After : Nov 28 06:08:39 2021 GMT
Subject: O=system:users, OU=, CN=252771643302762862Certificate:
Data:
Version: 3 (0x2)
Serial Number: 787224 (0xc0318)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
Validity
Not Before: Nov 29 06:03:00 2018 GMT
Not After : Nov 28 06:08:39 2021 GMT
Subject: O=system:users, OU=, CN=252771643302762862Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2184578451551960857 (0x1e512e86fcba3f19)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72
Validity
Not Before: Nov 29 03:59:00 2018 GMT
Not After : Nov 29 04:14:23 2019 GMT
Subject: CN=kube-apiserverCertificate:
Data:
Version: 3 (0x2)
Serial Number: 786974 (0xc021e)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=CN, ST=ZheJiang, L=HangZhou, O=Alibaba, OU=ACS, CN=root
Validity
Not Before: Nov 29 03:59:00 2018 GMT
Not After : Nov 24 04:04:00 2038 GMT
Subject: O=c0256a3b8e4b948bb9c21e66b0e1d9a72, OU=default, CN=c0256a3b8e4b948bb9c21e66b0e1d9a72理解了原理之后，我們可以做一個(gè)簡(jiǎn)單的測(cè)試：以證書作為參數(shù)，使用 curl 訪問(wèn) api server，并得到預(yù)期結(jié)果。
# curl --cert ./client.crt --cacert ./ca.crt --key ./client.key https://xx.xx.xx.xxx:6443/api/
{
"kind": "APIVersions",
"versions": [
"v1"
],
"serverAddressByClientCIDRs": [
{
"clientCIDR": "0.0.0.0/0",
"serverAddress": "192.168.0.222:6443"
}
]
}如開(kāi)始所講，Kubernetes 是管理集群多個(gè)節(jié)點(diǎn)的操作系統(tǒng)。這些節(jié)點(diǎn)在集群中的角色，卻不必完全一樣。Kubernetes 集群有兩種節(jié)點(diǎn)：master 節(jié)點(diǎn)和 worker 節(jié)點(diǎn)。
這種角色的區(qū)分，實(shí)際上就是一種分工：master 負(fù)責(zé)整個(gè)集群的管理，其上運(yùn)行的以集群管理組件為主，這些組件包括實(shí)現(xiàn)集群入口的 api server；而 worker 節(jié)點(diǎn)主要負(fù)責(zé)承載普通任務(wù)。
在 Kubernetes 集群中，任務(wù)被定義為 pod 這個(gè)概念。pod 是集群可承載任務(wù)的原子單元，pod 被翻譯成容器組，其實(shí)是意譯，因?yàn)橐粋€(gè) pod 實(shí)際上封裝了多個(gè)容器化的應(yīng)用。原則上來(lái)講，被封裝在一個(gè) pod 里邊的容器，應(yīng)該是存在相當(dāng)程度的耦合關(guān)系。
調(diào)度算法需要解決的問(wèn)題，是替 pod 選擇一個(gè)舒適的“居所”，讓 pod 所定義的任務(wù)可以在這個(gè)節(jié)點(diǎn)上順利地完成。
為了實(shí)現(xiàn)“擇優(yōu)而居”的目標(biāo)，Kubernetes 集群調(diào)度算法采用了兩步走的策略：
下面我們使用文章開(kāi)始的時(shí)候制作的鏡像，創(chuàng)建一個(gè) pod，并通過(guò)日志來(lái)具體分析一下，這個(gè) pod 怎么樣被調(diào)度到某一個(gè)集群節(jié)點(diǎn)。
首先，我們創(chuàng)建 pod 的配置文件，配置文件格式是 json。這個(gè)配置文件有三個(gè)地方比較關(guān)鍵，分別是鏡像地址，命令以及容器的端口。
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "app"
},
"spec": {
"containers": [
{
"name": "app",
"image": "registry.cn-hangzhou.aliyuncs.com/kube-easy/app:latest",
"command": [
"app"
],
"ports": [
{
"containerPort": 2580
}
]
}
]
}
}集群調(diào)度算法被實(shí)現(xiàn)為運(yùn)行在 master 節(jié)點(diǎn)上的系統(tǒng)組件，這一點(diǎn)和 api server 類似。其對(duì)應(yīng)的進(jìn)程名是 kube-scheduler。kube-scheduler 支持多個(gè)級(jí)別的日志輸出，但社區(qū)并沒(méi)有提供詳細(xì)的日志級(jí)別說(shuō)明文檔。查看調(diào)度算法對(duì)節(jié)點(diǎn)進(jìn)行篩選、打分的過(guò)程，我們需要把日志級(jí)別提高到 10，即加入?yún)?shù) --v=10。
kube-scheduler --address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true --v=10使用 curl，以證書和 pod 配置文件等作為參數(shù)，通過(guò) POST 請(qǐng)求訪問(wèn) api server 的接口，我們可以在集群里創(chuàng)建對(duì)應(yīng)的 pod。
# curl -X POST -H 'Content-Type: application/json;charset=utf-8' --cert ./client.crt --cacert ./ca.crt --key ./client.key https://47.110.197.238:6443/api/v1/namespaces/default/pods -d@app.json預(yù)選是 Kubernetes 調(diào)度的第一步，這一步要做的事情，是根據(jù)預(yù)先定義的規(guī)則，把不符合條件的節(jié)點(diǎn)過(guò)濾掉。不同版本的 Kubernetes 所實(shí)現(xiàn)的預(yù)選規(guī)則有很大的不同，但基本的趨勢(shì)，是預(yù)選規(guī)則會(huì)越來(lái)越豐富。
比較常見(jiàn)的兩個(gè)預(yù)選規(guī)則是 PodFitsResourcesPred 和 PodFitsHostPortsPred。前一個(gè)規(guī)則用來(lái)判斷，一個(gè)節(jié)點(diǎn)上的剩余資源，是不是能夠滿足 pod 的需求；而后一個(gè)規(guī)則，檢查一個(gè)節(jié)點(diǎn)上某一個(gè)端口是不是已經(jīng)被其他 pod 所使用了。
下圖是調(diào)度算法在處理測(cè)試 pod 的時(shí)候，輸出的預(yù)選規(guī)則的日志。這段日志記錄了預(yù)選規(guī)則 CheckVolumeBindingPred?的執(zhí)行情況。某些類型的存儲(chǔ)卷（PV），只能掛載到一個(gè)節(jié)點(diǎn)上，這個(gè)規(guī)則可以過(guò)濾掉不滿足 pod 對(duì) PV 需求的節(jié)點(diǎn)。
從 app 的編排文件里可以看到，pod 對(duì)存儲(chǔ)卷并沒(méi)有什么需求，所以這個(gè)條件并沒(méi)有過(guò)濾掉節(jié)點(diǎn)。
調(diào)度算法的第二個(gè)階段是優(yōu)選階段。這個(gè)階段，kube-scheduler 會(huì)根據(jù)節(jié)點(diǎn)可用資源及其他一些規(guī)則，給剩余節(jié)點(diǎn)打分。
目前，CPU 和內(nèi)存是調(diào)度算法考量的兩種主要資源，但考量的方式并不是簡(jiǎn)單的，剩余 CPU、內(nèi)存資源越多，得分就越高。
日志記錄了兩種計(jì)算方式：LeastResourceAllocation 和 BalancedResourceAllocation。
這兩種方式，一種傾向于選出資源使用率較低的節(jié)點(diǎn)，第二種希望選出兩種資源使用比例接近的節(jié)點(diǎn)。這兩種方式有一些矛盾，最終依靠一定的權(quán)重來(lái)平衡這兩個(gè)因素。
除了資源之外，優(yōu)選算法會(huì)考慮其他一些因素，比如 pod 與節(jié)點(diǎn)的親和性，或者如果一個(gè)服務(wù)有多個(gè)相同 pod 組成的情況下，多個(gè) pod 在不同節(jié)點(diǎn)上的分散程度，這是保證高可用的一種策略。
最后，調(diào)度算法會(huì)給所有的得分項(xiàng)乘以它們的權(quán)重，然后求和得到每個(gè)節(jié)點(diǎn)最終的得分。因?yàn)闇y(cè)試集群使用的是默認(rèn)調(diào)度算法，而默認(rèn)調(diào)度算法把日志中出現(xiàn)的得分項(xiàng)所對(duì)應(yīng)的權(quán)重，都設(shè)置成了 1，所以如果按日志里有記錄得分項(xiàng)來(lái)計(jì)算，最終三個(gè)節(jié)點(diǎn)的得分應(yīng)該是 29，28 和 29。
之所以會(huì)出現(xiàn)日志輸出的得分和我們自己計(jì)算的得分不符的情況，是因?yàn)槿罩静](méi)有輸出所有的得分項(xiàng)，猜測(cè)漏掉的策略應(yīng)該是 NodePreferAvoidPodsPriority，這個(gè)策略的權(quán)重是 10000，每個(gè)節(jié)點(diǎn)得分 10，所以才得出最終日志輸出的結(jié)果。
在本文中，我們以一個(gè)簡(jiǎn)單的容器化 web 程序?yàn)槔?，著重分析了客戶端怎么樣通過(guò) Kubernetes 集群 API Server 認(rèn)證，以及容器應(yīng)用怎么樣被分派到合適節(jié)點(diǎn)這兩件事情。
在分析過(guò)程中，我們棄用了一些便利的工具，比如 kubectl，或者控制臺(tái)。我們用了一些更接近底層的小實(shí)驗(yàn)，比如拆解 KubeConfig 文件，再比如分析調(diào)度器日志來(lái)分析認(rèn)證和調(diào)度算法的運(yùn)作原理。希望這些對(duì)大家進(jìn)一步理解 Kubernetes 集群有所幫助。
“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)者的技術(shù)圈?！?/p>
