kubeadm初始化及证书详解

kubeadm init执行流程

kubeadm采用的是容器化部署方式，把kubelet直接运行在宿主机上，然后使用容器部署其他的Kubernetes组件。

root@k8s-master:# kubeadm init ....
[init] Using Kubernetes version: v1.28.0
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.217.143]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.217.143 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.217.143 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 7.004685 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node k8s-master as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node k8s-master as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: 1a4q9h.73udmlg5f5ptt9tb
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
​
Your Kubernetes control-plane has initialized successfully!
​
To start using your cluster, you need to run the following as a regular user:
​
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config
​
Alternatively, if you are the root user, you can run:
​
  export KUBECONFIG=/etc/kubernetes/admin.conf
​
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/
​
Then you can join any number of worker nodes by running the following on each as root:
​
kubeadm join 192.168.217.143:6443 --token 1a4q9h.73udmlg5f5ptt9tb \
        --discovery-token-ca-cert-hash sha256:40fa0c186de148666a53ae4e193a1a6ca25cedd97034cef357514b3e6725e70e

第1步，做一系列检查工作，确定此台机器可以部署k8s，这一步检查称为[preflight]

第2步，在通过[preflight]检查之后，kubeadm是生成k8s对外提供服务所需的各种证书和对应的目录/etc/kubernetes/pki；这一步对应[certs]

kubernetes对外提供服务时，除非专门开启不安全模式，否则都要通过https才能访问kube-apiserver，这就需要为kubernetes集群配置好证书文件

kubeadm为Kubernetes项目生成的证书文件都放在master节点的/etc/kubernetes/pki目录下。在这个目录下，最主要的证书文件是ca.crt和对应的私钥ca.key

如果用户想直接向apiserver发起请求，需要使用apiserver-kubelet-client.crt，apiserver-kubelet-client.key和/etc/kubernetes/pki/ca.crt

其他证书解析见后面kubeadm证书详解

第3步，证书生成后，kubeadm会为其他组件生成访问kube-apiserver所需要的配置文件，这些文件的路径是/etc/kubernetes/xxx.conf；这一步对应[kubeconfig]

root@k8s-master:/etc/kubernetes# ls
admin.conf  controller-manager.conf  kubelet.conf  manifests  pki  scheduler.conf
root@k8s-master:/etc/kubernetes# cd manifests/
root@k8s-master:/etc/kubernetes/manifests# ls
etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml

这样，对应的客户端（比如scheduler，kubelet等）可以直接加载相应的文件，使用里面的信息与kube-apiserver建立安全连接。

第4步，kubeadm为master组件生成pod配置文件；这一步对应了[etcd]和[control-plane]

kube-apiserver、kube-controller-manager、kube-scheduler这三个master节点的组件都已pod形式部署。

在Kubernetes中，有一种特殊的容器启动方法叫做Static Pod。它允许把要部署的Pod的yaml文件放在一个指定的目录里/etc/kubernetes/manifests/。这样，当这台机器上的kubelet启动时，它会自动检查这个目录，加载所有的Pod YAML文件，然后在这台机器上启动它们。

一旦这些YAML文件出现在被kubelet监视的/etc/kubernetes/manifests目录下，kubelet就会自动创建这些YAML文件中定义的Pod，即Master组件的容器。

注意：根据命令kubeadm init的回显信息可以看到，此时kubelet服务还没有启动起来

第5步，将kubelet的一些配置文件写入到对应路径，然后启动kubelet；这一步对应[kubelet-start]

然后从配置文件加载数据，等待kubelet启动，这一步对应[wait-control-plane]

第6步，kubeadm会等待master组件完全运行起来；这一步对应[apiclient]

第7步，上传和存储配置文件信息，这一步对应了[upload-config],[kubelet],[upload-certs]

第8步，给主节点加标签和污点；这一步对应[mark-control-plane]

第9步，kubeadm就会为集群生成一个bootstrap token，在后面，只要持有这个token，任何一个安装了kubelet和kubadm的节点，都可以通过kubeadm join加入到这个集群当中，这一步对应[bootstrap-token]

在token生成之后，kubeadm会将ca.crt等Master节点的重要信息，通过ConfigMap的方式保存在Etcd当中，供后续部署Node节点使用。这个ConfigMap的名字是cluster-info

第10步，kubeadm init的最后一步，就是安装默认插件。Kubernetes默认kube-proxy和DNS这两个插件是必须安装的。它们分别用来提供整个集群的服务发现和DNS功能。其实，这两个插件也只是两个容器镜像而已

init完成后会生成token，在其他节点通过kubeadm join就可以加入到集群中

kubeadm join工作流程

kubeadm init生成bootstrap token之后，就可以在任意一台安装了kubelet和kubeadm的机器上执行kubeadm join

任何一台节点想要称为kubernetes集群中的一个节点，都必须在kube-apiserver上注册，这就必须要使用相应的证书文件

为了方便安装节点，不让用户去master节点手动拷贝这些证书文件，kubadm需要对kube-apiserver发起一次不安全的访问，从而拿到ConfigMap中的cluster-info(它保存了kube-apiserver的授权信息)，这个过程中就是bootstrap token来完成的

一旦拿到cluster-info里的kube-apiserver的相关信息，kubelet就可以安全的连接到kube-apiserver了

kubeadm为k8s生成的证书

kubernetes证书概述

使用kubeadm创建完Kubernetes集群后, 默认会在/etc/kubernetes/pki目录下存放集群中需要用到的证书文件, 整体结构如下图所示

root@k8s-master:/etc/kubernetes/pki# tree
.
├── apiserver.crt
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
├── apiserver.key
├── apiserver-kubelet-client.crt
├── apiserver-kubelet-client.key
├── ca.crt
├── ca.key
├── etcd
│   ├── ca.crt
│   ├── ca.key
│   ├── healthcheck-client.crt
│   ├── healthcheck-client.key
│   ├── peer.crt
│   ├── peer.key
│   ├── server.crt
│   └── server.key
├── front-proxy-ca.crt
├── front-proxy-ca.key
├── front-proxy-client.crt
├── front-proxy-client.key
├── sa.key
└── sa.pub
​
1 directory, 22 files

Kubernetes把证书放在了两个文件夹中

• /etc/kubernetes/pki
• /etc/kubernetes/pki/etcd

Kubernetes集群根证书6个

Kubernetes集群根证书CA(Kubernetes集群组件的证书签发机构)

• /etc/kubernetes/pki/ca.crt
• /etc/kubernetes/pki/ca.key

以上这组证书为签发其他Kubernetes组件证书使用的根证书, 可以认为是Kubernetes集群中证书签发机构之一

由此根证书签发的证书有

• kube-apiserver组件持有的服务端证书

  • /etc/kubernetes/pki/apiserver.crt
  • /etc/kubernetes/pki/apiserver.key

• kubelet 组件持有的客户端证书, 用作 kube-apiserver 主动向 kubelet 发起请求时的客户端认证

  • /etc/kubernetes/pki/apiserver-kubelet-client.crt
  • /etc/kubernetes/pki/apiserver-kubelet-client.key

Kubernetes集群组件之间的交互是双向的, kubelet 既需要主动访问 kube-apiserver, kube-apiserver 也需要主动向 kubelet 发起请求, 所以双方都需要有自己的根证书以及使用该根证书签发的服务端证书和客户端证书

在 kube-apiserver 中, 一般明确指定用于 https 访问的服务端证书和带有CN 用户名信息的客户端证书

在 kubelet 的启动配置中, 一般只指定了 ca 根证书, 而没有明确指定用于 https 访问的服务端证书

这是因为, 在生成服务端证书时, 一般会指定服务端地址或主机名, kube-apiserver 相对变化不是很频繁, 所以在创建集群之初就可以预先分配好用作 kube-apiserver 的 IP 或主机名/域名, 但是由于部署在 node 节点上的 kubelet 会因为集群规模的变化而频繁变化, 而无法预知 node 的所有 IP 信息, 所以 kubelet 上一般不会明确指定服务端证书, 而是只指定 ca 根证书, 让 kubelet 根据本地主机信息自动生成服务端证书并保存到配置的cert-dir文件夹中

汇聚层证书4个

kube-apiserver 的另一种访问方式就是使用 kubectl proxy 来代理访问, 而该证书就是用来支持SSL代理访问的. 在该种访问模式下, 我们是以http的方式发起请求到代理服务的, 此时, 代理服务会将该请求发送给 kube-apiserver, 在此之前, 代理会将发送给 kube-apiserver 的请求头里加入证书信息,

API Aggregation允许在不修改Kubernetes核心代码的同时扩展Kubernetes API. 开启 API Aggregation 需要在 kube-apiserver 中添加如下配置:

--requestheader-client-ca-file=<path to aggregator CA cert>
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=<path to aggregator proxy cert>
--proxy-client-key-file=<path to aggregator proxy key>

• kube-apiserver代理根证书(客户端证书)

  • 用在requestheader-client-ca-file配置选项中, kube-apiserver 使用该证书来验证客户端证书是否为自己所签发。由此根证书签发的证书只有一组，代理层(如汇聚层aggregator)使用此套代理证书来向 kube-apiserver 请求认证
  • /etc/kubernetes/pki/front-proxy-ca.crt
  • /etc/kubernetes/pki/front-proxy-ca.key

• 代理端使用的客户端证书, 用作代用户与 kube-apiserver 认证

  • /etc/kubernetes/pki/front-proxy-client.crt
  • /etc/kubernetes/pki/front-proxy-client.key

etcd集群根证书10个

etcd集群所用到的证书都保存在/etc/kubernetes/pki/etcd这路径下

• etcd 集群根证书CA(etcd 所用到的所有证书的签发机构)

  • /etc/kubernetes/pki/etcd/ca.crt
  • /etc/kubernetes/pki/etcd/ca.key

由此根证书签发机构签发的证书有

• etcd server 持有的服务端证书

  • /etc/kubernetes/pki/etcd/server.crt
  • /etc/kubernetes/pki/etcd/server.key

• peer 集群中节点互相通信使用的客户端证书。【Peer：对同一个etcd集群中另外一个Member的称呼】

  • /etc/kubernetes/pki/etcd/peer.crt
  • /etc/kubernetes/pki/etcd/peer.key

• pod 中定义 Liveness 探针使用的客户端证书。【kubeadm 部署的 Kubernetes 集群是以 pod 的方式运行 etcd 服务的, 在该 pod 的定义中, 配置了 Liveness 探活探针】

  • /etc/kubernetes/pki/etcd/healthcheck-client.crt
  • /etc/kubernetes/pki/etcd/healthcheck-client.key

• 配置在 kube-apiserver 中用来与 etcd server 做双向认证的客户端证书

  • /etc/kubernetes/pki/apiserver-etcd-client.crt
  • /etc/kubernetes/pki/apiserver-etcd-client.key

Serveice Account秘钥2个

这组的密钥对儿仅提供给 kube-controller-manager 使用. kube-controller-manager 通过 sa.key 对 token 进行签名, master 节点通过公钥 sa.pub 进行签名的验证

• /etc/kubernetes/pki/sa.key
• /etc/kubernetes/pki/sa.pub