kubeadm工作原理-kubeadm init原理分析-kubeadm join原理分析

kubeadm概述

kubeadm是社区维护的Kubernetes集群一键部署利器，使用两条命令即可完成k8s集群中master节点以及node节点的部署，其底层原理是利用了k8s TLS bootstrap特性。

kubeadm部署k8s集群示例

（1）k8s master节点部署：

$ kubeadm init

此外，我们也可以自己编写yaml文件来自定义kubeadm的启动过程和一些组件的启动参数等等

$ kubeadm init --config xxx.yaml

（2）k8s node节点部署（将一个node节点加入到已有集群当中）：

$ kubeadm join <kube-apiserver的ip + 端口> --token <token>

此外，我们也可以自己编写yaml文件来自定义kubeadm的启动过程和一些组件的启动参数，包括kube-apiserver的ip与端口、token等

$ kubeadm join --config xxx.yaml

关于自定义yaml文件以及更多的kubeadm用法请参考：https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

k8s TLS bootstrap概述

当k8s集群开启了TLS认证后，每个节点的kubelet组件都要使用由kube-apiserver的CA签发的有效证书才能与kube-apiserver通信；当节点非常多的时候，为每个节点都单独签署证书是一件非常繁琐而又耗时的事情。

此时k8s TLS bootstrap功能应运而生。

k8s TLS bootstrap功能就是让kubelet先使用一个预先商定好的低权限token连接到kube-apiserver，向kube-apiserver申请证书，然后kube-controller-manager给kubelet动态签署证书，后续kubelet都将通过动态签署的证书与kube-apiserver通信。

关于k8s TLS bootstrap的详细分析这里暂时不展开。

kubeadm原理解析

大致流程

在k8s master中，会先启动一个kubelet，控制面组件通过kubelet static pod特性启动，在k8s master控制面组件启动成功后，其他节点需要加入到k8s集群时，使用TLS bootstrap来简化加入的过程，先通过bootstrap-token与kube-apiserver通信，自动从kube-controller-manager处签发拿到与kube-apiserver通信的证书，然后自动生成与kube-apiserver通信的kubeconfig文件，后续将使用kubeconfig文件与kube-apiserver进行通信。

详细流程解析

1.kubeadm init

kubeadm init的结果是完成一个k8s master节点的部署，包括kube-apiserver、kube-controller-manager、kube-scheduler、etcd等控制面组件以及kubelet数据面组件，即该master节点既是控制面又是数据面，所以master节点上也是可以运行pod的；

以下为kubeadm init的处理流程代码（基于k8s v1.17.4版本），一共13步：

// cmd/kubeadm/app/cmd/init.go-NewCmdInit()
    ...
    // initialize the workflow runner with the list of phases
	initRunner.AppendPhase(phases.NewPreflightPhase()) // 1.环境检查
	initRunner.AppendPhase(phases.NewKubeletStartPhase()) // 2.配置并启动kubelet
	initRunner.AppendPhase(phases.NewCertsPhase()) //