作者 | 聲東  阿里雲售後技術專家

**導讀**：不知道大家有沒有意識到一個現實：大部分時候，我們已經不像以前一樣，透過命令列，或者可視視窗來使用一個系統了。

# 前言
現在我們上微博、或者網購，操作的其實不是眼前這臺裝置，而是一個又一個叢集。通常，這樣的叢集擁有成百上千個節點，每個節點是一臺物理機或虛擬機器。叢集一般遠離使用者，坐落在資料中心。為了讓這些節點互相協作，對外提供一致且高效的服務，叢集需要作業系統。Kubernetes 就是這樣的作業系統。

![1.jpeg](https://ucc.alicdn.com/pic/developer-ecology/58564153edaa45b4bfb49dd3994821e1.jpeg)

比較 Kubernetes 和單機作業系統，Kubernetes 相當於核心，它負責叢集軟硬體資源管理，並對外提供統一的入口，使用者可以透過這個入口來使用叢集，和叢集溝通。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/f22ab4c9789c4edfba7aa8053be64f25.png)

而執行在叢集之上的程式，與普通程式有很大的不同。這樣的程式，是“關在籠子裡”的程式。它們從被製作，到被部署，再到被使用，都不尋常。我們只有深挖根源，才能理解其本質。

# “關在籠子裡”的程式

## 程式碼
我們使用 go 語言寫了一個簡單的 web 伺服器程式 app.go，這個程式監聽在 2580 這個埠。透過 http 協議訪問這個服務的根路徑，服務會返回 "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 命令編譯這個程式，產生 app 可執行檔案。這是一個普通的可執行檔案，它在作業系統裡執行，會依賴系統裡的庫檔案。

```
# 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)
```

## “籠子”
為了讓這個程式不依賴於作業系統自身的庫檔案，我們需要製作容器映象，即隔離的執行環境。Dockerfile 是製作容器映象的“菜譜”。我們的菜譜就只有兩個步驟，下載一個 centos 的基礎映象，把 app 這個可執行檔案放到映象中 /usr/local/bin 目錄中去。

```
FROM centos
ADD app /usr/local/bin
```

## 地址
製作好的映象存再本地，我們需要把這個映象上傳到映象倉庫裡去。這裡的映象倉庫，相當於應用商店。我們使用阿里雲的映象倉庫，上傳之後映象地址是:

```
registry.cn-hangzhou.aliyuncs.com/kube-easy/app:latest
```

映象地址可以拆分成四個部分：倉庫地址/名稱空間/映象名稱:映象版本。顯然，映象上邊的映象，在阿里雲杭州映象倉庫，使用的名稱空間是 kube-easy，映象名:版本是 app:latest。至此，我們有了一個可以在 Kubernetes 叢集上執行的、“關在籠子裡”的小程式。

# 得其門而入

## 入口
Kubernetes 作為作業系統，和普通的作業系統一樣，有 API 的概念。有了 API，叢集就有了入口；有了 API，我們使用叢集，才能得其門而入。Kubernetes 的 API 被實現為執行在叢集節點上的元件 API Server。這個元件是典型的 web 伺服器程式，透過對外暴露 http(s) 介面來提供服務。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/7f634e3f51bb4f5082ed42efb751de9a.png)

這裡我們建立一個阿里雲 Kubernetes 叢集。登入叢集管理頁面，我們可以看到 API Server 的公網入口。

```
API Server 內網連線端點： https://xx.xxx.xxx.xxx:6443
```

## 雙向數字證書驗證
阿里雲 Kubernetes 叢集 API Server 元件，使用基於 CA 簽名的雙向數字證書認證來保證客戶端與 api server 之間的安全通訊。這句話很繞口，對於初學者不太好理解，我們來深入解釋一下。

從概念上來講，數字證書是用來驗證網路通訊參與者的一個檔案。這和學校頒發給學生的畢業的證書類似。在學校和學生之間，學校是可信第三方 CA，而學生是通訊參與者。如果社會普遍信任一個學校的聲譽的話，那麼這個學校頒發的畢業的證書，也會得到社會認可。參與者證書和 CA 證書可以類比畢業證和學校的辦學許可證。

這裡我們有兩類參與者，CA 和普通參與者；與此對應，我們有兩種證書，CA 證書和參與者證書；另外我們還有兩種關係，證書籤發關係以及信任關係。這兩種關係至關重要。

我們先看簽發關係。如下圖，我們有兩張 CA 證書，三個參與者證書。

其中最上邊的 CA 證書，簽發了兩張證書，一張是中間的 CA 證書，另一張是右邊的參與者證書；中間的 CA 證書，簽發了下邊兩張參與者證書。這六張證書以簽發關係為聯絡，形成了樹狀的證書籤發關係圖。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/9680a208b7044216a648f35d5a31295c.png)

然而，證書以及簽發關係本身，並不能保證可信的通訊可以在參與者之間進行。以上圖為例，假設最右邊的參與者是一個網站，最左邊的參與者是一個瀏覽器，瀏覽器相信網站的資料，不是因為網站有證書，也不是因為網站的證書是 CA 簽發的，而是因為瀏覽器相信最上邊的 CA，也就是信任關係。

理解了 CA（證書），參與者（證書），簽發關係，以及信任關係之後，我們回過頭來看“基於 CA 簽名的雙向數字證書認證”。客戶端和 API Server 作為通訊的普通參與者，各有一張證書。而這兩張證書，都是由 CA 簽發，我們簡單稱它們為叢集 CA 和客戶端 CA。客戶端信任叢集 CA，所以它信任擁有叢集 CA 簽發證書的 API Server；反過來 API Server 需要信任客戶端 CA，它才願意與客戶端通訊。

阿里雲 Kubernetes 叢集，叢集 CA 證書，和客戶端 CA 證書，實現上其實是一張證書，所以我們有這樣的關係圖。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/d0b845e2eced4b3180f511b7a1a916c9.png)

## KubeConfig 檔案
登入叢集管理控制檯，我們可以拿到 KubeConfig 檔案。這個檔案包括了客戶端證書，叢集 CA 證書，以及其他。證書使用 base64 編碼，所以我們可以使用 base64 工具解碼證書，並使用 openssl 檢視證書文字。

- 首先，客戶端證書的簽發者 CN 是叢集 id c0256a3b8e4b948bb9c21e66b0e1d9a72，而證書本身的 CN 是子賬號 252771643302762862；

```
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=252771643302762862
```

- 其次，只有在 API Server 信任客戶端 CA 證書的情況下，上邊的客戶端證書才能透過 API Server 的驗證。kube-apiserver 程式透過 client-ca-file 這個引數指定其信任的客戶端 CA 證書，其指定的證書是 /etc/kubernetes/pki/apiserver-ca.crt。這個檔案實際上包含了兩張客戶端 CA 證書，其中一張和叢集管控有關係，這裡不做解釋，另外一張如下，它的 CN 與客戶端證書的簽發者 CN 一致；

```
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=252771643302762862
```

- 再次，API Server 使用的證書，由 kube-apiserver 的引數 tls-cert-file 決定，這個引數指向證書 /etc/kubernetes/pki/apiserver.crt。這個證書的 CN 是 kube-apiserver，簽發者是 c0256a3b8e4b948bb9c21e66b0e1d9a72，即叢集 CA 證書；

```
Certificate:
    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-apiserver
```

- 最後，客戶端需要驗證上邊這張 API Server 的證書，因而 KubeConfig 檔案裡包含了其簽發者，即叢集 CA 證書。對比叢集 CA 證書和客戶端 CA 證書，發現兩張證書完全一樣，這符合我們的預期。

```
Certificate:
    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
```

## 訪問
理解了原理之後，我們可以做一個簡單的測試：以證書作為引數，使用 curl 訪問 api server，並得到預期結果。

```
# 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"
    }
  ]
}
```

# 擇優而居

## 兩種節點，一種任務
如開始所講，Kubernetes 是管理叢集多個節點的作業系統。這些節點在叢集中的角色，卻不必完全一樣。Kubernetes 叢集有兩種節點：master 節點和 worker 節點。

這種角色的區分，實際上就是一種分工：master 負責整個叢集的管理，其上執行的以叢集管理元件為主，這些元件包括實現叢集入口的 api server；而 worker 節點主要負責承載普通任務。

在 Kubernetes 叢集中，任務被定義為 pod 這個概念。pod 是叢集可承載任務的原子單元，pod 被翻譯成容器組，其實是意譯，因為一個 pod 實際上封裝了多個容器化的應用。原則上來講，被封裝在一個 pod 裡邊的容器，應該是存在相當程度的耦合關係。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/40190cc759d34a0d80f9e11619c8c9f4.png)

## 擇優而居
排程演算法需要解決的問題，是替 pod 選擇一個舒適的“居所”，讓 pod 所定義的任務可以在這個節點上順利地完成。

為了實現“擇優而居”的目標，Kubernetes 叢集排程演算法採用了兩步走的策略：

- 第一步，從所有節點中排除不滿足條件的節點，即預選；
- 第二步，給剩餘的節點打分，最後得分高者勝出，即優選。

下面我們使用文章開始的時候製作的映象，建立一個 pod，並透過日誌來具體分析一下，這個 pod 怎麼樣被排程到某一個叢集節點。

## Pod 配置
首先，我們建立 pod 的配置檔案，配置檔案格式是 json。這個配置檔案有三個地方比較關鍵，分別是映象地址，命令以及容器的埠。

```
{
    "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
                    }
                ]
            }
        ]
    }
}
```

## 日誌級別
叢集排程演算法被實現為執行在 master 節點上的系統元件，這一點和 api server 類似。其對應的程式名是 kube-scheduler。kube-scheduler 支援多個級別的日誌輸出，但社群並沒有提供詳細的日誌級別說明文件。檢視排程演算法對節點進行篩選、打分的過程，我們需要把日誌級別提高到 10，即加入引數 --v=10。

```
kube-scheduler --address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true --v=10
```

## 建立 Pod
使用 curl，以證書和 pod 配置檔案等作為引數，透過 POST 請求訪問 api server 的介面，我們可以在叢集裡建立對應的 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
```

## 預選
預選是 Kubernetes 排程的第一步，這一步要做的事情，是根據預先定義的規則，把不符合條件的節點過濾掉。不同版本的 Kubernetes 所實現的預選規則有很大的不同，但基本的趨勢，是預選規則會越來越豐富。

比較常見的兩個預選規則是 PodFitsResourcesPred 和 PodFitsHostPortsPred。前一個規則用來判斷，一個節點上的剩餘資源，是不是能夠滿足 pod 的需求；而後一個規則，檢查一個節點上某一個埠是不是已經被其他 pod 所使用了。

下圖是排程演算法在處理測試 pod 的時候，輸出的預選規則的日誌。這段日誌記錄了預選規則 CheckVolumeBindingPred 的執行情況。某些型別的儲存卷（PV），只能掛載到一個節點上，這個規則可以過濾掉不滿足 pod 對 PV 需求的節點。

從 app 的編排檔案裡可以看到，pod 對儲存卷並沒有什麼需求，所以這個條件並沒有過濾掉節點。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/831043df6d7f47338e25f53a378e8d56.png)

## 優選
排程演算法的第二個階段是優選階段。這個階段，kube-scheduler 會根據節點可用資源及其他一些規則，給剩餘節點打分。

目前，CPU 和記憶體是排程演算法考量的兩種主要資源，但考量的方式並不是簡單的，剩餘 CPU、記憶體資源越多，得分就越高。

日誌記錄了兩種計算方式：LeastResourceAllocation 和 BalancedResourceAllocation。

- 前一種方式計算 pod 排程到節點之後，節點剩餘 CPU 和記憶體佔總 CPU 和記憶體的比例，比例越高得分就越高；
- 第二種方式計算節點上 CPU 和記憶體使用比例之差的絕對值，絕對值越大，得分越少。

這兩種方式，一種傾向於選出資源使用率較低的節點，第二種希望選出兩種資源使用比例接近的節點。這兩種方式有一些矛盾，最終依靠一定的權重來平衡這兩個因素。

![8.png](https://ucc.alicdn.com/pic/developer-ecology/e589e0a72cd24f9aa9ccac122e0df4f6.png)

除了資源之外，優選演算法會考慮其他一些因素，比如 pod 與節點的親和性，或者如果一個服務有多個相同 pod 組成的情況下，多個 pod 在不同節點上的分散程度，這是保證高可用的一種策略。

![9.png](https://ucc.alicdn.com/pic/developer-ecology/63f95385ff004b158ba90d679329b151.png)

## 得分
最後，排程演算法會給所有的得分項乘以它們的權重，然後求和得到每個節點最終的得分。因為測試叢集使用的是預設排程演算法，而預設排程演算法把日誌中出現的得分項所對應的權重，都設定成了 1，所以如果按日誌裡有記錄得分項來計算，最終三個節點的得分應該是 29，28 和 29。

![10.png](https://ucc.alicdn.com/pic/developer-ecology/222f2bba5ff94921a229aabfdd743196.png)

之所以會出現日誌輸出的得分和我們自己計算的得分不符的情況，是因為日誌並沒有輸出所有的得分項，猜測漏掉的策略應該是 NodePreferAvoidPodsPriority，這個策略的權重是 10000，每個節點得分 10，所以才得出最終日誌輸出的結果。

# 結束語
在本文中，我們以一個簡單的容器化 web 程式為例，著重分析了客戶端怎麼樣透過 Kubernetes 叢集 API Server 認證，以及容器應用怎麼樣被分派到合適節點這兩件事情。

在分析過程中，我們棄用了一些便利的工具，比如 kubectl，或者控制檯。我們用了一些更接近底層的小實驗，比如拆解 KubeConfig 檔案，再比如分析排程器日誌來分析認證和排程演算法的運作原理。希望這些對大家進一步理解 Kubernetes 叢集有所幫助。

# 架構師成長系列直播

![11.png](https://ucc.alicdn.com/pic/developer-ecology/9baecc83edd44ad39683d2ff4760c280.png)

> “[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

從認證到排程，K8s 叢集上執行的小程式到底經歷了什麼？

相關文章