kubeadm init流程

1.引導前的檢查

kubeadm init執行后，首先需要對集群master節點安裝的各種約束條件進行逐一檢查。
如果不符合kubeadm的要求，kubeadm將報錯並停止init過程。
下面列舉一些error級別的檢查：
　　kubeadm版本要與安裝的kubernetes版本的比對檢查。
　　kubernetes安裝的系統需求檢查。
　　其它檢查：用戶、主機、端口、swap、工具等。

 

2.生成私鑰和數字證書

kubeadm會為整個集群生成多組私鑰和公鑰數字證書。
包括整個集群的root CA的私鑰和CA的公鑰數字證書，
API Server與其它組件之間的相互通信所用的多組私鑰和數字證書，
用於service acount token簽名的私鑰和公鑰文件等。
這樣使得kubeadm搭建出來的集群是一個安全的集群。
所有kubernetes自身組件的通信以及pod到API Service的通信都是基於安全數據通道的。
且有生成驗證和授權機制的。

關於數字證書、CA和CA證書：
數字證書：互聯網通訊中標志通訊各方身份信息的一串數字，提供了一種在互聯網上驗證通信實體身份的方式。

CA：Certificate Authority，證書授權中心。它是負責管理和簽發證書的第三方機構。
　　它是負責管理和簽發證書的第三方機構，作用是檢查證書持有者身份的合法性，並簽發證書，以訪證書被偽造或篡改。
　　數字證書就是CA發行。

CA證書：CA頒發的證書，也就是我們常說的數字證書，包含證書擁有者的身份信息，CA機構的簽名，公鑰和私鑰。
　　　身份信息用於證明證書持有者的身份；CA簽名用於保護身份的真實性。公鑰和私鑰用於通信過程中加解密，從而保證通信信息的安全性。

查看kubeadm的證書：

主要包括：

（1）自建CA、生成ca.key和ca.crt

如果不指定外部的證書授權機構，那么kubeadm會自建證書授權機構，
生成私鑰（ca.key）和自簽署的數字證書（ca.crt）,用於后續簽發kubernetes集群所需要的其它公鑰證書證書。
查看ca的數字證書：
ca.crt是一個標准的x509格式的數字證書文件。

ubuntu@VM-16-6-ubuntu:/etc/kubernetes/pki$ openssl x509 -in ca.crt -noout -text Certificate: Data: Version: 3 (0x2) #版本號 Serial Number: 0 (0x0) #序列號，ca的第一個證書 Signature Algorithm: sha256WithRSAEncryption #加密方式 Issuer: CN=kubernetes Validity Not Before: Jun 19 03:23:59 2019 GMT Not After : Jun 16 03:23:59 2029 GMT Subject: CN=kubernetes Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:b4:e0:c3:3b:74:92:dc:57:87:dc:0e:cb:cb:1c: 92:e3:17:7d:74:eb:d5:06:14:7b:88:22:d2:77:34: 59:be:85:d2:65:7a:88:46:bc:9d:ec:3a:7e:d7:85: 08:e2:ce:46:cd:38:06:e1:6b:af:a8:46:b5:1e:3b: 74:60:a6:7a:45:6a:dd:fa:01:77:9f:61:66:5d:5c: 8e:06:82:9e:da:15:a3:80:95:e0:a2:f5:f7:3a:d5: d1:1f:ce:f0:a7:47:df:75:a2:ad:62:95:a2:7b:f2: 15:8d:f2:b0:d0:82:f5:59:1f:75:c0:a8:fd:02:8e: 35:05:2b:96:ec:78:d7:c1:0c:9b:34:26:53:c8:df: 0a:c4:27:05:12:74:1d:26:4c:b0:15:74:74:b8:4d: 08:c4:d9:48:19:77:6f:49:e9:27:de:ed:f6:f5:d4: 8b:93:14:8e:cb:3d:0d:f8:20:bc:15:80:37:64:22: cc:c2:bc:62:27:d4:cc:41:3b:81:59:26:77:10:fc: 8b:c6:7c:1f:9a:20:77:92:3c:51:f9:b8:15:8a:85: d4:c5:02:aa:91:11:9c:ed:b7:fd:fd:2c:09:57:37: f6:00:91:38:98:52:48:f6:b1:ed:d7:91:78:d0:a5: d2:30:ff:d1:76:e3:ea:91:e2:d8:3f:26:82:ea:cd: 0f:53 Exponent: 65537 (0x10001) X509v3 extensions: #證書的用途 X509v3 Key Usage: critical Digital Signature（數據簽名）, Key Encipherment（密鑰加密）, Certificate Sign（證書簽發） X509v3 Basic Constraints: critical CA:TRUE #這是一個ca的公鑰證書 Signature Algorithm: sha256WithRSAEncryption a6:f7:53:49:4f:1c:c4:1b:e9:84:08:4c:5a:49:03:c8:32:b1: 24:15:b6:47:0b:78:db:9a:1d:c5:23:fb:7b:89:fa:96:2d:eb: df:e9:d8:ad:3a:90:02:e0:fd:12:f2:0c:b2:15:68:72:e4:08: 83:57:ed:c9:78:5c:ae:10:4c:c5:92:50:14:32:c4:66:12:34: 50:7f:e0:5d:b0:6e:5f:95:49:b7:e3:c8:83:b9:90:f0:94:29: 19:0a:7c:9a:e6:59:68:11:1a:92:e8:9d:29:30:3c:3b:aa:06: 7f:59:89:e0:37:8b:c2:2e:89:a0:68:d1:78:bc:6c:d1:d9:79: cd:0c:2e:7b:7c:c4:4c:59:2e:89:13:fc:c6:6c:f3:45:e7:6e: b1:15:41:ee:eb:4c:15:c1:59:e4:8e:84:d8:34:c6:dd:95:eb: 36:26:4a:99:94:e4:11:6f:69:89:53:cb:8f:c0:6b:8f:bf:3f: 91:3b:03:d0:db:67:96:a1:f1:16:40:af:e3:44:14:21:8c:f0: 02:e9:a0:78:fc:30:5a:dd:d8:c1:b4:87:2c:2f:a3:64:71:e3: 7d:88:a4:6f:c1:b6:f0:44:a3:8e:90:b2:10:e0:b8:02:00:af: 40:bb:3b:6c:b9:b4:cf:9d:92:f9:83:1d:ba:d2:c8:f5:e3:04: 0f:70:cf:9f

（2）apiserver的私鑰與公鑰證書

有了ca之后，就可以用來簽發集群所使用的各種證書。
kubeadm會生成API Server的私鑰文件，運用ca來簽發API Server的公鑰數據證書。
在pki目錄下，apiserver.key是APIServer的私鑰文件。apiserver.crt是用ca來簽署的APIServer的公鑰數據證書。
查看apiserver.crt證書內容：

ubuntu@VM-16-6-ubuntu:/etc/kubernetes/pki$ openssl x509 -in apiserver.crt -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 5825362278220765184 (0x50d7d820c14f1800) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=kubernetes Validity Not Before: Jun 19 03:23:59 2019 GMT Not After : Jun 18 03:23:59 2020 GMT Subject: CN=kube-apiserver #與ca中不一樣 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:de:f4:70:62:6b:75:a2:d7:55:e6:b7:3e:54:4e: 75:f7:1a:d8:68:dd:b5:b8:3d:80:7b:06:b1:00:5b: b3:71:32:d3:19:42:74:23:e6:32:9c:4a:a8:ef:28: a5:63:28:d4:e7:e7:e9:77:6a:b3:36:15:b4:0e:c8: 46:c6:94:c1:a6:79:c7:fd:38:62:b0:9c:8c:83:f9: 7e:2f:11:f3:38:6a:81:50:f0:f3:54:66:28:95:04: 77:23:01:9d:7b:16:c9:45:7a:3f:4a:14:4a:f1:7a: 07:f3:85:f1:ab:cc:bf:e2:15:4e:3e:da:11:f0:8f: 2b:e0:81:1f:19:d2:27:17:97:e4:24:b9:e4:4d:20: c7:91:ab:24:f1:25:ea:a5:de:0e:37:9d:d0:30:57: 95:82:7a:6d:ff:1e:7d:7e:3f:82:69:6b:c3:0d:e0: cc:53:be:91:2f:f8:ec:6a:13:21:9f:d9:db:8a:f2: a1:d1:b7:8e:5c:0e:16:41:d0:a9:e1:70:85:c2:86: 4a:dd:d9:0e:01:97:4e:ab:32:0c:ee:ec:7a:4f:64: aa:0d:33:1d:d1:44:54:2b:97:b3:b5:88:7e:b4:1a: d5:4e:31:a6:4c:3f:59:a0:60:4b:43:3c:4f:54:75: 64:83:cd:8a:37:a8:6b:61:51:cb:b5:07:7e:d3:45: 9e:55 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Key Usage: critical Digital Signature（數據簽名）, Key Encipherment（密鑰加密）#並沒有簽署證書的用途 X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Subject Alternative Name: #可用於多種域名和IP地址。 DNS:vm-16-6-ubuntu, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:10.96.0.1, IP Address:148.70.251.10 Signature Algorithm: sha256WithRSAEncryption ac:77:88:a4:c7:10:78:1a:25:f9:9d:d8:a7:0f:89:a7:62:d4: 3c:27:86:b8:95:13:14:20:70:b9:00:88:a6:04:7b:01:a1:ba: 3f:79:a6:12:7f:98:c1:2c:b5:5f:05:43:d6:38:55:3c:96:02: 82:94:8b:b6:d5:99:48:e1:69:ac:cf:e9:44:b3:a4:73:6f:e5: 83:91:f5:f9:1c:f6:43:f1:42:a8:a5:ca:bc:53:53:93:db:ed: 7f:cb:fd:8c:9b:35:07:0c:cc:ea:f2:5e:be:20:d8:f7:58:f8: 60:b0:ab:4a:82:a9:ec:5b:4d:da:7d:9a:5c:95:f4:37:e5:89: 3a:1d:0a:ef:bd:fe:95:cd:b0:f8:07:d4:ba:17:36:da:33:cf: fc:f0:5e:98:0b:f9:db:b2:8f:a3:8c:1e:99:86:49:82:9f:29: 5d:ef:13:83:94:6d:e4:3a:a6:81:b6:a3:9c:32:a9:8e:76:a6: e8:62:52:15:27:82:36:cc:c6:3d:89:12:9c:c8:9d:3a:cd:61: 91:a7:f6:22:44:71:db:f4:ea:6f:65:37:9c:5a:5e:91:18:cb: 35:3e:b6:00:46:8e:a9:64:76:b0:b7:90:c8:f1:06:4d:b4:e4: 6b:65:b5:7c:f7:cd:36:ba:d8:4d:84:f5:e9:20:08:53:8f:3e: b0:55:72:5a

（3）apiserver訪問kubelet使用的客戶端私鑰與證書

APIServer會向各個node的kubelet主動發起鏈接，並從kubelet獲取日志。
或touch到正在運行的pod中，或提供kubelet的端口轉發功能。
kubelet會通過client端的SSL證書，來校驗APIServer建立的鏈接。
apiserver-etcd-client.crt和apiserver-etcd-client.key用來證明APIServer的合法身份的。

（4）sa.key和sa.pub

sa是service acount的縮寫。
sa.key用於對service acount token的數據簽名。sa.pub是sa.key對應的公鑰文件。

（5）Etcd相關私鑰和數字證書

etcd是kubernetes整個集群的控制中心，而集群中唯一可以訪問的組件是APIServer，
其它組件都是通過API Server的API存儲數據的。
為建立etcd和API Server之間的安全數據通道，kubeadm init會生成APIServer訪問etcd的相關私鑰和證書。
apiserver-etcd-client.crt和apiserver-etcd-client.key是kubeadm init生成的APIServer用於訪問etcd的私鑰文件和公鑰數字證書。用於etcd對於APIServer的身份驗證所用。
在pki目錄下面，還有一個etcd目錄，專門用來保存與etcd相關的證書文件。

我們可以看到，etcd下面也有一個ca，那apiserver-etcd-client.crt這個數字證書是由誰來簽發的了？測試一下

root@VM-16-6-ubuntu:/etc/kubernetes/pki# openssl verify -CAfile ca.crt ./apiserver-etcd-client.crt ./apiserver-etcd-client.crt: O = system:masters, CN = kube-apiserver-etcd-client error 7 at 0 depth lookup:certificate signature failure #報錯了，證明並非是由pki目錄下的ca簽發 139720460449432:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:103: 139720460449432:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed:rsa_eay.c:705: 139720460449432:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib:a_verify.c:218: root@VM-16-6-ubuntu:/etc/kubernetes/pki# openssl verify -CAfile etcd/ca.crt ./apiserver-etcd-client.crt ./apiserver-etcd-client.crt: OK

 

3.生成控制平面組件kubeconfig文件，這些文件將用於組件之間通信鑒權使用

通過kubeadm init將master節點啟動成功后，告知了kubeconfig的配置方法。
配置之后，kubectl就可以直接使用這些信息，訪問kubernetes集群。

這些文件都是kubeconfig文件，由kubeadm init生成。
kubelet.conf被kubelet組件使用，用於訪問APIServer。
scheduler.conf被scheduler組件所使用，用於訪問APIServer。
controller-manager.conf被controller-manager組件所使用，用於訪問APIServer。
admin.conf包含了整個集群的最高權限配置數據。

一旦配置了KUBECONFIG變量，kubectl就會使用KUBECONFIG變量所配置的信息。
Kubeconfig包含cluster、user和context信息。

Kubeconfig包含cluster、user和context信息。
root@VM-16-6-ubuntu:/etc/kubernetes# kubectl config view apiVersion: v1 clusters: - cluster: certificate-authority-data: REDACTED #ca信息 server: https://148.70.251.10:6443 #服務地址  name: kubernetes contexts: #用來綁定user和cluster。 - context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes current-context: kubernetes-admin@kubernetes #定義用哪個user訪問哪個cluster。 kind: Config preferences: {} users: - name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED

允許kubectl快速切換context，這樣可以使用不同身份管理不同集群。

 

4.生成控制平面組件manifest文件

這些文件將會被master節點上的kubelet所讀取，並啟動master控制平面組件，以及維護這些控制平面組件的狀態。
雖然kubeadm init將集群引導起來，但是有些問題你需要知道。
比如控制平面的組件是怎么啟動起來的？如果重啟了master節點，這些組件是否還會自動重啟。
這些控制組件的參數如何調整，又如何生效了？

kubeadm init在啟動過程中，會生成各個組件的manifests文件。

對應master上所有組件。控制平面組件以Static Pod形式運行。

root@VM-16-6-ubuntu:/etc/kubernetes/manifests# cat kube-scheduler.yaml apiVersion: v1 kind: Pod metadata: annotations: scheduler.alpha.kubernetes.io/critical-pod: "" creationTimestamp: null labels: component: kube-scheduler tier: control-plane name: kube-scheduler namespace: kube-system spec: containers: - command: - kube-scheduler - --address=127.0.0.1 - --leader-elect=true - --kubeconfig=/etc/kubernetes/scheduler.conf image: k8s.gcr.io/kube-scheduler-amd64:v1.10.2 livenessProbe: failureThreshold: 8 httpGet: host: 127.0.0.1 path: /healthz port: 10251 scheme: HTTP initialDelaySeconds: 15 timeoutSeconds: 15 name: kube-scheduler resources: requests: cpu: 100m volumeMounts: - mountPath: /etc/kubernetes/scheduler.conf name: kubeconfig readOnly: true hostNetwork: true volumes: - hostPath: path: /etc/kubernetes/scheduler.conf type: FileOrCreate name: kubeconfig status: {}

這些manifests文件都是控制平面組件的yaml文件。
master節點上的pod將讀取這些文件，並啟動控制平面組件。
與普通pod不同的是，這些pod是以靜態pod的形式運行。

靜態pod是由節點上的kubelet進程來管理的，不通過APIServer來管理，也不關聯任何replication的控制器。
由kubelet進程自己來監控。當靜態pod崩潰時，kubelet會重啟這些pod。
靜態pod始終綁定在一個kubelet上，並且始終運行在同一個節點上。
kubelet會自動為每一個靜態pod在APIServer上創建一個鏡像的pod。
我們可以通過APIserver查詢這些pod，但是不能通過APIServer對這些鏡像進行控制。
如果要刪除靜態pod，可以直接將其對應的manifests下的yaml文件移除即可。
所有控制平面的靜態pod都運行在kubesystem的名稱空間下，並且使用主機網絡。
kubelet讀取manifests目錄並管理各控制平台組件pod啟停。
如果修改調整組件的yaml文件，kubelet也會監視到這些變化，並重啟對應的pod，使其配置生效。

 

5.下載鏡像，等待控制平面啟動

默認情況下Kubeadm依賴kubelet下載鏡像並啟動static pod.默認從k8s.gcr.io上下載組件鏡像。
kubeadm會一直探測並等待localhost:6443/healthz服務返回成功。
localhost:6443/healthz服務是APIServer的存活探針服務。
存活探針配置在manifests的配置文件中的。

vim kube-apiserver.yaml
    ...
    livenessProbe:
      failureThreshold: 8 #失敗門檻次數 httpGet: host: 148.70.251.10 path: /healthz port: 6443 scheme: HTTPS initialDelaySeconds: 15 timeoutSeconds: 15 #超時時間 ...

 

6.保存MasterConfig配置信息，也就是集群創建的初始信息。

 

7.設置Master標值

將當前節點設置為master節點，這樣工作負載就不會調度到master節點上。

 

8.進行基於TLS的安全引導相關配置

為后續的worker節點的加入，進行基於TLS的安全引導相關配置。

 

9.安裝DNS和kube-proxy插件

DNS插件安裝后會處於pending狀態，需要等到網絡插件安裝后才能恢復到running狀態。
以DaemonSet方式部署Kube-proxy。

部署Kube-dns插件，作為內部DNS服務，可以使用CoreDNS來替代。