kubeadm 初始化集群时，Init 命令的工作流程

Init 命令的工作流程

kubeadm init 命令通过执行下列步骤来启动一个 Kubernetes 控制平面节点。

1. 在做出变更前运行一系列的预检项来验证系统状态。一些检查项目仅仅触发警告，其它的则会被视为错误并且退出 kubeadm，除非问题得到解决或者用户指定了 --ignore-preflight-errors=<list-of-errors> 参数。

2. 生成一个自签名的 CA 证书 (或者使用现有的证书，如果提供的话) 来为集群中的每一个组件建立身份标识。如果用户已经通过 --cert-dir 配置的证书目录（默认为 /etc/kubernetes/pki）提供了他们自己的 CA 证书以及/或者密钥， 那么将会跳过这个步骤，正如文档使用自定义证书所述。如果指定了 --apiserver-cert-extra-sans 参数, APIServer 的证书将会有额外的 SAN 条目，如果必要的话，将会被转为小写。

3. 将 kubeconfig 文件写入 /etc/kubernetes/ 目录以便 kubelet、控制器管理器和调度器用来连接到 API 服务器，它们每一个都有自己的身份标识，同时生成一个名为 admin.conf 的独立的 kubeconfig 文件，用于管理操作。

4. 为 API 服务器、控制器管理器和调度器生成静态 Pod 的清单文件。假使没有提供一个外部的 etcd 服务的话，也会为 etcd 生成一份额外的静态 Pod 清单文件。

静态 Pod 的清单文件被写入到 /etc/kubernetes/manifests 目录; kubelet 会监视这个目录以便在系统启动的时候创建 Pod。

一旦控制平面的 Pod 都运行起来， kubeadm init 的工作流程就继续往下执行。

1. 对控制平面节点应用 labels 和 taints 标记以便不会在它上面运行其它的工作负载。

2. 生成令牌以便其它节点以后可以使用这个令牌向控制平面节点注册它们自己。(可选)，用户可以通过 --token 提供一个令牌，正如文档 kubeadm token 所述。

3. 为了使得节点能够遵照 Bootstrap Tokens 和 TLS Bootstrap 这两份文档中描述的机制加入到集群中，kubeadm 会执行所有的必要配置： - 创建一份 ConfigMap 提供添加集群节点所需的信息，并为该 ConfigMap 设置相关的 RBAC 访问规则。 - 使得 Bootstrap Tokens 可以访问 CSR 签名 API。 - 对新的 CSR 请求配置为自动签发。

查阅kubeadm join文档以获取更多信息。

1. 通过 API 服务器安装一个 DNS 服务器 (CoreDNS) 和 kube-proxy 附加组件。 在 1.11 版本以及更新版本的 Kubernetes 中 CoreDNS 是默认的 DNS 服务器。 要安装 kube-dns 而不是 CoreDNS，必须在 kubeadm ClusterConfiguration 中配置 DNS 插件。有关配置的更多信息，请参见下面的 Using kubeadm init with a configuration file 一节。 请注意，尽管已部署 DNS 服务器，但直到安装 CNI 时才调度它。