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来替代。
