前言

我們提供的服務(wù)有：網(wǎng)站設(shè)計(jì)、成都網(wǎng)站設(shè)計(jì)、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、大姚ssl等。為1000+企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢(xún)和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的大姚網(wǎ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)離用戶(hù)，坐落在數(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)一的入口，用戶(hù)可以通過(guò)這個(gè)入口來(lái)使用集群，和集群溝通。

而運(yùn)行在集群之上的程序，與普通程序有很大的不同。這樣的程序，是“關(guān)在籠子里”的程序。它們從被制作，到被部署，再到被使用，都不尋常。我們只有深挖根源，才能理解其本質(zhì)。

“關(guān)在籠子里”的程序

代碼

我們使用 go 語(yǔ)言寫(xiě)了一個(gè)簡(jiǎn)單的 web 服務(wù)器程序 app.go，這個(gè)程序監(jiān)聽(tīng)在 2580 這個(gè)端口。通過(guò) http 協(xié)議訪(fǎng)問(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ì)依賴(lài)系統(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è)程序不依賴(lài)于操作系統(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ù)地址/命名空間/鏡像名稱(chēng):鏡像版本。顯然，鏡像上邊的鏡像，在阿里云杭州鏡像倉(cāng)庫(kù)，使用的命名空間是 kube-easy，鏡像名:版本是 app:latest。至此，我們有了一個(gè)可以在 Kubernetes 集群上運(yùn)行的、“關(guān)在籠子里”的小程序。

入口

Kubernetes 作為操作系統(tǒng)，和普通的操作系統(tǒng)一樣，有 API 的概念。有了 API，集群就有了入口；有了 API，我們使用集群，才能得其門(mén)而入。Kubernetes 的 API 被實(shí)現(xiàn)為運(yùn)行在集群節(jié)點(diǎn)上的組件 API Server。這個(gè)組件是典型的 web 服務(wù)器程序，通過(guò)對(duì)外暴露 http(s) 接口來(lái)提供服務(wù)。

這里我們創(chuàng)建一個(gè)阿里云 Kubernetes 集群。登錄集群管理頁(yè)面，我們可以看到 API Server 的公網(wǎng)入口。

API Server 內(nèi)網(wǎng)連接端點(diǎn)： https://xx.xxx.xxx.xxx:6443

雙向數(shù)字證書(shū)驗(yàn)證

阿里云 Kubernetes 集群 API Server 組件，使用基于 CA 簽名的雙向數(shù)字證書(shū)認(rèn)證來(lái)保證客戶(hù)端與 api server 之間的安全通信。這句話(huà)很繞口，對(duì)于初學(xué)者不太好理解，我們來(lái)深入解釋一下。

從概念上來(lái)講，數(shù)字證書(shū)是用來(lái)驗(yàn)證網(wǎng)絡(luò)通信參與者的一個(gè)文件。這和學(xué)校頒發(fā)給學(xué)生的畢業(yè)證書(shū)類(lèi)似。在學(xué)校和學(xué)生之間，學(xué)校是可信第三方 CA，而學(xué)生是通信參與者。如果社會(huì)普遍信任一個(gè)學(xué)校的聲譽(yù)的話(huà)，那么這個(gè)學(xué)校頒發(fā)的畢業(yè)證書(shū)，也會(huì)得到社會(huì)認(rèn)可。參與者證書(shū)和 CA 證書(shū)可以類(lèi)比畢業(yè)證和學(xué)校的辦學(xué)許可證。

這里我們有兩類(lèi)參與者，CA 和普通參與者；與此對(duì)應(yīng)，我們有兩種證書(shū)，CA 證書(shū)和參與者證書(shū)；另外我們還有兩種關(guān)系，證書(shū)簽發(fā)關(guān)系以及信任關(guān)系。這兩種關(guān)系至關(guān)重要。

我們先看簽發(fā)關(guān)系。如下圖，我們有兩張 CA 證書(shū)，三個(gè)參與者證書(shū)。

其中最上邊的 CA 證書(shū)，簽發(fā)了兩張證書(shū)，一張是中間的 CA 證書(shū)，另一張是右邊的參與者證書(shū)；中間的 CA 證書(shū)，簽發(fā)了下邊兩張參與者證書(shū)。這六張證書(shū)以簽發(fā)關(guān)系為聯(lián)系，形成了樹(shù)狀的證書(shū)簽發(fā)關(guān)系圖。

然而，證書(shū)以及簽發(fā)關(guān)系本身，并不能保證可信的通信可以在參與者之間進(jìn)行。以上圖為例，假設(shè)最右邊的參與者是一個(gè)網(wǎng)站，最左邊的參與者是一個(gè)瀏覽器，瀏覽器相信網(wǎng)站的數(shù)據(jù)，不是因?yàn)榫W(wǎng)站有證書(shū)，也不是因?yàn)榫W(wǎng)站的證書(shū)是 CA 簽發(fā)的，而是因?yàn)闉g覽器相信最上邊的 CA，也就是信任關(guān)系。

理解了 CA（證書(shū)），參與者（證書(shū)），簽發(fā)關(guān)系，以及信任關(guān)系之后，我們回過(guò)頭來(lái)看“基于 CA 簽名的雙向數(shù)字證書(shū)認(rèn)證”?？蛻?hù)端和 API Server 作為通信的普通參與者，各有一張證書(shū)。而這兩張證書(shū)，都是由 CA 簽發(fā)，我們簡(jiǎn)單稱(chēng)它們?yōu)榧?CA 和客戶(hù)端 CA?？蛻?hù)端信任集群 CA，所以它信任擁有集群 CA 簽發(fā)證書(shū)的 API Server；反過(guò)來(lái) API Server 需要信任客戶(hù)端 CA，它才愿意與客戶(hù)端通信。

阿里云 Kubernetes 集群，集群 CA 證書(shū)，和客戶(hù)端 CA 證書(shū)，實(shí)現(xiàn)上其實(shí)是一張證書(shū)，所以我們有這樣的關(guān)系圖。

KubeConfig 文件

登錄集群管理控制臺(tái)，我們可以拿到 KubeConfig 文件。這個(gè)文件包括了客戶(hù)端證書(shū)，集群 CA 證書(shū)，以及其他。證書(shū)使用 base64 編碼，所以我們可以使用 base64 工具解碼證書(shū)，并使用 openssl 查看證書(shū)文本。

• 首先，客戶(hù)端證書(shū)的簽發(fā)者 CN 是集群 id c0256a3b8e4b948bb9c21e66b0e1d9a72，而證書(shū)本身的 CN 是子賬號(hào) 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 信任客戶(hù)端 CA 證書(shū)的情況下，上邊的客戶(hù)端證書(shū)才能通過(guò) API Server 的驗(yàn)證。kube-apiserver 進(jìn)程通過(guò) client-ca-file 這個(gè)參數(shù)指定其信任的客戶(hù)端 CA 證書(shū)，其指定的證書(shū)是 /etc/kubernetes/pki/apiserver-ca.crt。這個(gè)文件實(shí)際上包含了兩張客戶(hù)端 CA 證書(shū)，其中一張和集群管控有關(guān)系，這里不做解釋?zhuān)硗庖粡埲缦?，它?CN 與客戶(hù)端證書(shū)的簽發(fā)者 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 使用的證書(shū)，由 kube-apiserver 的參數(shù) tls-cert-file 決定，這個(gè)參數(shù)指向證書(shū) /etc/kubernetes/pki/apiserver.crt。這個(gè)證書(shū)的 CN 是 kube-apiserver，簽發(fā)者是 c0256a3b8e4b948bb9c21e66b0e1d9a72，即集群 CA 證書(shū)；

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

• 最后，客戶(hù)端需要驗(yàn)證上邊這張 API Server 的證書(shū)，因而 KubeConfig 文件里包含了其簽發(fā)者，即集群 CA 證書(shū)。對(duì)比集群 CA 證書(shū)和客戶(hù)端 CA 證書(shū)，發(fā)現(xiàn)兩張證書(shū)完全一樣，這符合我們的預(yù)期。

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

訪(fǎng)問(wèn)

理解了原理之后，我們可以做一個(gè)簡(jiǎn)單的測(cè)試：以證書(shū)作為參數(shù)，使用 curl 訪(fǎng)問(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"
    }
  ]
}

網(wǎng)站名稱(chēng)：客戶(hù)端怎樣通過(guò)Kubernetes集群APIServer認(rèn)證？
轉(zhuǎn)載注明：http://www.rwnh.cn/article38/ippesp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、云服務(wù)器、App開(kāi)發(fā)、關(guān)鍵詞優(yōu)化、做網(wǎng)站、微信公眾號(hào)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)