前言

成都創(chuàng)新互聯(lián)公司是一家專注于成都網(wǎng)站建設(shè)、做網(wǎng)站與策劃設(shè)計,可克達拉網(wǎng)站建設(shè)哪家好?成都創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設(shè)十余年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:可克達拉等地區(qū)。可克達拉做網(wǎng)站價格咨詢:028-86922220

在進行二進制搭建K8S集群前，我們需要梳理通最磨人的一個點，就是各種各樣的證書機制。這一步是在安裝配置kubernetes的所有步驟中最容易出錯也是最難排查問題的一步，而這卻剛好是第一步，萬事開頭難，不要因為這點困難就望而卻步。

一共有多少證書？

官方文檔參考：https://kubernetes.io/docs/setup/certificates/

先從Etcd算起：

1、Etcd對外提供服務(wù)，要有一套etcd?server證書

2、Etcd各節(jié)點之間進行通信，要有一套etcd?peer證書

3、Kube-APIserver訪問Etcd，要有一套etcd?client證書

再算kubernetes：

4、Kube-APIserver對外提供服務(wù)，要有一套kube-apiserver?server證書

5、kube-scheduler、kube-controller-manager、kube-proxy、kubelet和其他可能用到的組件，需要訪問kube-APIserver，要有一套kube-APIserver?client證書

6、kube-controller-manager要生成服務(wù)的service?account，要有一對用來簽署service?account的證書(CA證書)

7、kubelet對外提供服務(wù)，要有一套kubelet?server證書

8、kube-APIserver需要訪問kubelet，要有一套kubelet?client證書

加起來共8套，但是這里的“套”的含義我們需要理解。

同一個套內(nèi)的證書必須是用同一個CA簽署的，簽署不同套里的證書的CA可以相同，也可以不同。例如，所有etcd server證書需要是同一個CA簽署的，所有的etcd peer證書也需要是同一個CA簽署的，而一個etcd server證書和一個etcd peer證書，完全可以是兩個CA機構(gòu)簽署的，彼此沒有任何關(guān)系。這算兩套證書。

為什么同一個“套”內(nèi)的證書必須是同一個CA簽署的

原因在驗證這些證書的一端。因為在要驗證這些證書的一端，通常只能指定一個Root CA。這樣一來，被驗證的證書自然都需要是被這同一個Root CA對應(yīng)的私鑰簽署，不然不能通過認證。

其實實際上，使用一套證書（都使用一套CA來簽署）一樣可以搭建出K8S，一樣可以上生產(chǎn)，但是理清這些證書的關(guān)系，在遇到因為證書錯誤，請求被拒絕的現(xiàn)象的時候，不至于無從下手，而且如果沒有搞清證書之間的關(guān)系，在維護或者解決問題的時候，貿(mào)然更換了證書，弄不好會把整個系統(tǒng)搞癱。

TLS?bootstrapping?簡化kubelet證書制作

Kubernetes1.4版本引入了一組簽署證書用的API。這組API的引入，使我們可以不用提前準備kubelet用到的證書。

每個kubelet用到的證書都是獨一無二的，因為它要綁定各自的IP地址，于是需要給每個kubelet單獨制作證書，如果業(yè)務(wù)量很大的情況下，node節(jié)點會很多，這樣一來kubelet的數(shù)量也隨之增加，而且還會經(jīng)常變動（增減Node）kubelet的證書制作就成為一件很麻煩的事情。使用TLS bootstrapping就可以省事兒很多。

工作原理：Kubelet第一次啟動的時候，先用同一個bootstrap token作為憑證。這個token已經(jīng)被提前設(shè)置為隸屬于用戶組system：bootstrappers，并且這個用戶組的權(quán)限也被限定為只能用來申請證書。 用這個bootstrap token通過認證后，kubelet申請到屬于自己的兩套證書（kubelet server、kube-apiserver client for kubelet），申請成功后，再用屬于自己的證書做認證，從而擁有了kubelet應(yīng)有的權(quán)限。這樣一來，就去掉了手動為每個kubelet準備證書的過程，并且kubelet的證書還可以自動輪替更新

官方文檔參考：https://kubernetes.io/docs/tasks/tls/certificate-rotation/

kubelet證書為何不同

這樣做是一個為了審計，另一個為了安全。 每個kubelet既是服務(wù)端（kube-apiserver需要訪問kubelet），也是客戶端（kubelet需要訪問kube-apiserver），所以要有服務(wù)端和客戶端兩組證書。

服務(wù)端證書需要與服務(wù)器地址綁定，每個kubelet的地址都不相同，即使綁定域名也是綁定不同的域名，故服務(wù)端地址不同

客戶端證書也不應(yīng)相同，每個kubelet的認證證書與所在機器的IP綁定后，可以防止一個kubelet的認證證書泄露以后，使從另外的機器上偽造的請求通過驗證。

安全方面，如果每個node上保留了用于簽署證書的bootstrap token，那么bootstrap token泄漏以后，是不是可以隨意簽署證書了？安全隱患非常大。所以，kubelet啟動成功以后，本地的bootstrap token需要被刪除。

正式制作證書

雖然可以用多套證書，但是維護多套CA實在過于繁雜，這里還是用一個CA簽署所有證書。

需要準備的證書：

• admin-key.pem

• admin.pem

• ca-key.pem

• ca.pem

• kube-proxy-key.pem

• kube-proxy.pem

• kubernetes-key.pem

• kubernetes.pem

使用證書的組件如下：

• etcd：使用 ca.pem、kubernetes-key.pem、kubernetes.pem

• kube-apiserver：使用 ca.pem、kubernetes-key.pem、kubernetes.pem

• kubelet：使用 ca.pem

• kube-proxy：使用 ca.pem、kube-proxy-key.pem、kube-proxy.pem

• kubectl：使用 ca.pem、admin-key.pem、admin.pem

• kube-controller-manager：使用 ca-key.pem、ca.pem

我們使用CFSSL來制作證書，它是cloudflare開發(fā)的一個開源的PKI工具，是一個完備的CA服務(wù)系統(tǒng)，可以簽署、撤銷證書等，覆蓋了一個證書的整個生命周期，后面只用到了它的命令行工具。

注：一般情況下，K8S中證書只需要創(chuàng)建一次，以后在向集群中添加新節(jié)點時只要將/etc/kubernetes/ssl目錄下的證書拷貝到新節(jié)點上即可。

下載安裝cfssl命令行工具

[root@dong?bin]#?mkdir?-p?/usr/local/bin/cfssl
[root@dong?bin]#?wget?https://pkg.cfssl.org/R1.2/cfssl_linux-amd64?
[root@dong?bin]#?wget?https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64?
[root@dong?bin]#?wget?https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64?
[root@dong?bin]#?chmod?+x?cfssl*
[root@dong?bin]#?mv?cfssl_linux-amd64?/usr/local/bin/cfssl
[root@dong?bin]#?mv?cfssljson_linux-amd64?/usr/local/bin/cfssljson
[root@dong?bin]#?mv?cfssl-certinfo_linux-amd64?/usr/local/bin/cfssl-certinfo
[root@dong?bin]#?export?PATH=/usr/local/bin:$PATH

創(chuàng)建CA證書

創(chuàng)建存放證書目錄

[root@dong?bin]#?mkdir?-p?/opt/kubernetes/ssl/
[root@dong?bin]#?cd?/opt/kubernetes/ssl/

創(chuàng)建證書配置文件

[root@dong?ssl]#?vim?ca-config.json
{
??"signing":?{
????"default":?{
??????"expiry":?"87600h"
????},
????"profiles":?{
??????"kubernetes":?{
????????"usages":?[
????????????"signing",
????????????"key?encipherment",
????????????"server?auth",
????????????"client?auth"
????????],
????????"expiry":?"87600h"
??????}
????}
??}
}

字段說明：

ca-config.json：可以定義多個 profiles，分別指定不同的過期時間、使用場景等參數(shù)；后續(xù)在簽名證書時使用某個 profile；

signing：表示該證書可以簽名其他證書；生成的ca.pem證書中 CA=TRUE；

server auth：表示client可以用該 CA 對server提供的證書進行驗證；

client auth：表示server可以用該CA對client提供的證書進行驗證；

expiry：過期時間

創(chuàng)建CA證書簽名請求文件

[root@dong?ssl]#?vim?ca-csr.json
{
??"CN":?"kubernetes",
??"key":?{
????"algo":?"rsa",
????"size":?2048
??},
??"names":?[
????{
??????"C":?"CN",
??????"ST":?"BeiJing",
??????"L":?"BeiJing",
??????"O":?"k8s",
??????"OU":?"System"
????}
??],
????"ca":?{
???????"expiry":?"87600h"
????}
}

字段說明：

“CN”：Common Name，kube-apiserver 從證書中提取該字段作為請求的用戶名 (User Name)；瀏覽器使用該字段驗證網(wǎng)站是否合法；

“O”：Organization，kube-apiserver 從證書中提取該字段作為請求用戶所屬的組 (Group)；

生成CA證書和私鑰

[root@dong?ssl]#?cfssl?gencert?-initca?ca-csr.json?|?cfssljson?-bare?ca
[root@dong?ssl]#?ls?|?grep?ca
ca-config.json
ca.csr
ca-csr.json
ca-key.pem
ca.pem

其中ca-key.pem是ca的私鑰，ca.csr是一個簽署請求，ca.pem是CA證書，是后面kubernetes組件會用到的RootCA。

創(chuàng)建kubernetes證書

創(chuàng)建kubernetes證書簽名請求文件?kubernetes-csr.json

[root@dong?ssl]#?vim?kubernetes-csr.json
{
????"CN":?"kubernetes",
????"hosts":?[
??????"127.0.0.1",
??????"192.168.214.88",
??????"192.168.214.89",
??????"192.168.214.90",
??????"192.168.214.200",
??????"192.168.214.201",
??????"192.168.214.202",
??????"10.254.0.1",
??????"192.168.214.210",
??????"192.168.214.1/24",
??????"kubernetes",
??????"kube-api.wangdong.com",
??????"kubernetes.default",
??????"kubernetes.default.svc",
??????"kubernetes.default.svc.cluster",
??????"kubernetes.default.svc.cluster.local"
????],
????"key":?{
????????"algo":?"rsa",
????????"size":?2048
????},
????"names":?[
????????{
????????????"C":?"CN",
????????????"ST":?"BeiJing",
????????????"L":?"BeiJing",
????????????"O":?"k8s",
????????????"OU":?"System"
????????}
????]
}

字段說明：

如果 hosts 字段不為空則需要指定授權(quán)使用該證書的 IP 或域名列表。

由于該證書后續(xù)被 etcd 集群和 kubernetes master使用，將etcd、master節(jié)點的IP都填上，同時還有service網(wǎng)絡(luò)的首IP。(一般是 kube-apiserver 指定的 service-cluster-ip-range 網(wǎng)段的第一個IP，如 10.254.0.1)

我這里的設(shè)置包括一個私有鏡像倉庫，三個etcd，三個master，以上物理節(jié)點的IP也可以更換為主機名。

生成kubernetes證書和私鑰

[root@dong?ssl]#?cfssl?gencert?-ca=ca.pem?-ca-key=ca-key.pem?-config=ca-config.json?-profile=kubernetes?kubernetes-csr.json?|?cfssljson?-bare?kubernetes
[root@dong?ssl]#?ls?|grep?kubernetes
kubernetes.csr
kubernetes-csr.json
kubernetes-key.pem
kubernetes.pem

創(chuàng)建admin證書

創(chuàng)建admin證書簽名請求文件admin-csr.json

[root@dong?ssl]#?admin-csr.json
{
??"CN":?"admin",
??"hosts":?[],
??"key":?{
????"algo":?"rsa",
????"size":?2048
??},
??"names":?[
????{
??????"C":?"CN",
??????"ST":?"BeiJing",
??????"L":?"BeiJing",
??????"O":?"system:masters",
??????"OU":?"System"
????}
??]
}

說明：

后續(xù) kube-apiserver 使用 RBAC 對客戶端(如 kubelet、kube-proxy、Pod)請求進行授權(quán)；

kube-apiserver 預(yù)定義了一些 RBAC 使用的 RoleBindings，如 cluster-admin 將 Group system:masters 與 Role cluster-admin 綁定，該 Role 授予了調(diào)用kube-apiserver 的所有 API的權(quán)限；

O指定該證書的 Group 為 system:masters，kubelet 使用該證書訪問 kube-apiserver 時 ，由于證書被 CA 簽名，所以認證通過，同時由于證書用戶組為經(jīng)過預(yù)授權(quán)的 system:masters，所以被授予訪問所有 API 的權(quán)限；

注：這個admin 證書，是將來生成管理員用的kube config 配置文件用的，現(xiàn)在我們一般建議使用RBAC 來對kubernetes 進行角色權(quán)限控制， kubernetes 將證書中的CN 字段 作為User， O 字段作為 Group

生成admin證書和私鑰

[root@dong?ssl]#?cfssl?gencert?-ca=ca.pem?-ca-key=ca-key.pem?-config=ca-config.json?-profile=kubernetes?admin-csr.json?|?cfssljson?-bare?admin
[root@dong?ssl]#?ls?|?grep?admin
admin.csr
admin-csr.json
admin-key.pem
admin.pem

創(chuàng)建kube-proxy證書

創(chuàng)建 kube-proxy 證書簽名請求文件 kube-proxy-csr.json

[root@dong?ssl]#?vim?kube-proxy-csr.json
{
??"CN":?"system:kube-proxy",
??"hosts":?[],
??"key":?{
????"algo":?"rsa",
????"size":?2048
??},
??"names":?[
????{
??????"C":?"CN",
??????"ST":?"BeiJing",
??????"L":?"BeiJing",
??????"O":?"k8s",
??????"OU":?"System"
????}
??]
}

說明：

CN 指定該證書的 User 為 system:kube-proxy；

kube-apiserver 預(yù)定義的 RoleBinding system:node-proxier 將User system:kube-proxy 與 Role system:node-proxier 綁定，該 Role 授予了調(diào)用 kube-apiserver Proxy 相關(guān) API 的權(quán)限；

生成kube-proxy證書和私鑰

[root@dong?ssl]#?cfssl?gencert?-ca=ca.pem?-ca-key=ca-key.pem?-config=ca-config.json?-profile=kubernetes??kube-proxy-csr.json?|?cfssljson?-bare?kube-proxy
[root@dong?ssl]#?ls?|grep?kube-proxy
kube-proxy.csr
kube-proxy-csr.json
kube-proxy-key.pem
kube-proxy.pem

經(jīng)過上述操作，我們會用到如下文件：

[root@dong?ssl]#?ls?|?grep?pem
admin-key.pem
admin.pem
ca-key.pem
ca.pem
kube-proxy-key.pem
kube-proxy.pem
kubernetes-key.pem
kubernetes.pem

查看證書信息

[root@master1?ssl]#?cfssl-certinfo?-cert?kubernetes.pem
{
??"subject":?{
????"common_name":?"kubernetes",
????"country":?"CN",
????"organization":?"k8s",
????"organizational_unit":?"System",
????"locality":?"BeiJing",
????"province":?"BeiJing",
????"names":?[
??????"CN",
??????"BeiJing",
??????"BeiJing",
??????"k8s",
??????"System",
??????"kubernetes"
????]
??},
??"issuer":?{
????"common_name":?"kubernetes",
????"country":?"CN",
????"organization":?"k8s",
????"organizational_unit":?"System",
????"locality":?"BeiJing",
????"province":?"BeiJing",
????"names":?[
??????"CN",
??????"BeiJing",
??????"BeiJing",
??????"k8s",
??????"System",
??????"kubernetes"
????]
??},
??"serial_number":?"321233745860282370502438768971300435157761820875",
??"sans":?[
????"192.168.214.1/24",
????"kubernetes",
????"kube-api.wangdong.com",
????"kubernetes.default",
????"kubernetes.default.svc",
????"kubernetes.default.svc.cluster",
????"kubernetes.default.svc.cluster.local",
????"127.0.0.1",
????"192.168.214.88",
????"192.168.214.89",
????"192.168.214.90",
????"192.168.214.200",
????"192.168.214.201",
????"192.168.214.202",
????"10.254.0.1",
????"192.168.214.210"
??],
??"not_before":?"2019-03-12T11:26:00Z",
??"not_after":?"2029-03-09T11:26:00Z",
??"sigalg":?"SHA256WithRSA",
??"authority_key_id":?"CB:34:54:33:1F:F4:37:E:E5:94:B7:F5:8A:3D:F4:A4:43:43:E2:7F",
??"subject_key_id":?"EC:31:D8:5F:4:E3:6F:C2:7F:DA:A8:F0:BD:A:B9:1F:56:7B:9A:DF",
??"pem":?"-----BEGIN?CERTIFICATE-----\nMIIExjCCA66gAwIBAgIUOESejeFvtUe1qwPcXOQdC9a6iMswDQYJKoZIhvcNAQEL\nBQAwZTELMAkGA1UEBhMCQ04xEDAOBgNVBAgTB0JlaUppbmcxEDAOBgNVBAcTB0Jl\naUppbmcxDDAKBgNVBAoTA2s4czEPMA0GA1UECxMGU3lzdGVtMRMwEQYDVQQDEwpr\ndWJlcm5ldGVzMB4XDTE5MDMxMjExMjYwMFoXDTI5MDMwOTExMjYwMFowZTELMAkG\nA1UEBhMCQ04xEDAOBgNVBAgTB0JlaUppbmcxEDAOBgNVBAcTB0JlaUppbmcxDDAK\nBgNVBAoTA2s4czEPMA0GA1UECxMGU3lzdGVtMRMwEQYDVQQDEwprdWJlcm5ldGVz\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAteZIJbL5G2ZHEKajyVe7\nv4E1F9K9RzLTxghStRo808QOpVclOkFRHCi2qplrFrQmW4d/5AhJmofdoBuwIe/T\n3UgrhlPj1rWC5DhaG8J7+wOIp62yURslnXE+A+EsXQLXxeKxrbrodNwTmGJHXdGl\nv2pi0lyAgewdnhJHcYTvQbrDvbxpqYOHqKzJ3sqm1TSjnWSI9C1Hk/iF9xmjA4CG\nLDHocnxzNv+T/qSofv0yyGgA/HovlNxP+jSIwaWJu3QHhOxV3k2Bj7i0jSJoq3n9\nDl4co22Ge4SLiI2zPZayt9whzSyUoc5eloYJ1w7INcmfz2gOYl7L3godLg/gI5Eh\nNQIDAQABo4IBbDCCAWgwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUF\nBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBTsMdhfBONvwn/a\nqPC9CrkfVnua3zAfBgNVHSMEGDAWgBTLNFQzH/Q3DuWUt/WKPfSkQ0PifzCB6AYD\nVR0RBIHgMIHdghAxOTIuMTY4LjIxNC4xLzI0ggprdWJlcm5ldGVzghVrdWJlLWFw\naS53YW5nZG9uZy5jb22CEmt1YmVybmV0ZXMuZGVmYXVsdIIWa3ViZXJuZXRlcy5k\nZWZhdWx0LnN2Y4Iea3ViZXJuZXRlcy5kZWZhdWx0LnN2Yy5jbHVzdGVygiRrdWJl\ncm5ldGVzLmRlZmF1bHQuc3ZjLmNsdXN0ZXIubG9jYWyHBH8AAAGHBMCo1liHBMCo\n1lmHBMCo1lqHBMCo1siHBMCo1smHBMCo1sqHBAr+AAGHBMCo1tIwDQYJKoZIhvcN\nAQELBQADggEBADtxejgpSQy913K9YyVLcS2k9bs41mZZbuokyrZiJeJ/CKZKzCo+\ngnF7P9/35IjkNlnYhlpUTTIJbnlQY8mDyKx1AaZOkzr+2djYRpg2vL3E7+CdRldQ\nUpNANSITolInKqboXev8SlLF9Mc/dWqgZzoifezuEkZ+c5KM6MY6MpMDVjVKNBxy\nJTd3bZNaPopop8IWxLAel5IQbzUhooswtzUxUslwKnYYC9tsKc5AgiXdehCnbGNf\nIr6wkK2OJBJStNPqarnpH6FZ6JxJ+qt59SdNhLixOT84HBR7ews/ZCYhQuPaJTy2\nwIb0XOtxILF3JMBNW/n21IyhF0vXsMdLg+o=\n-----END?CERTIFICATE-----\n"
}

在搭建k8s集群的時候，將這些文件分發(fā)到至此集群中其他節(jié)點機器中即可。至此，TLS證書創(chuàng)建完畢。