kubeadm初始化集群的工作流程

kubeadm init的工作流程

1. 检查环境

当你执行 kubeadm init 指令后，kubeadm 首先要做的，是一系列的检查工作，以确定这台机器可以用来部署 Kubernetes。
检查的内容大致有如下：
Linux 内核的版本必须是否是 3.10 以上？
Linux Cgroups 模块是否可用？
机器的 hostname 是否标准？在 Kubernetes 项目里，机器的名字以及一切存储在 Etcd
中的 API 对象，都必须使用标准的 DNS 命名（RFC 1123）。
用户安装的 kubeadm 和 kubelet 的版本是否匹配？
机器上是不是已经安装了 Kubernetes 的二进制文件？
Kubernetes 的工作端口 10250/10251/10252 端口是不是已经被占用？
ip、mount 等 Linux 指令是否存在？
Docker 是否已经安装

2. 生成证书

Kubernetes 对外提供服务时，除非专门开启“不安全模式”，否则都要通过 HTTPS 才能
访问 kube-apiserver。这就需要为 Kubernetes 集群配置好证书文件。
kubeadm 为 Kubernetes 项目生成的证书文件都放在 Master 节点的
/etc/kubernetes/pki 目录下。在这个目录下，最主要的证书文件是 ca.crt 和对应的私钥
ca.key。
此外，用户使用 kubectl 获取容器日志等 streaming 操作时，需要通过 kube-apiserver
向 kubelet 发起请求，这个连接也必须是安全的。kubeadm 为这一步生成的是
apiserver-kubelet-client.crt 文件，对应的私钥是 apiserver-kubelet-client.key。
除此之外，Kubernetes 集群中还有 Aggregate APIServer 等特性，也需要用到专门的证
书，这里我就不再一一列举了。需要指出的是，你可以选择不让 kubeadm 为你生成这些
证书，而是拷贝现有的证书到如下证书的目录里：
 复制代码
1 /etc/kubernetes/pki/ca.{crt,key}
这时，kubeadm 就会跳过证书生成的步骤，把它完全交给用户处理。

3. 生成配置文件

证书生成后，kubeadm 接下来会为其他组件生成访问 kube-apiserver 所需的配置文
件。这些文件的路径是：/etc/kubernetes/xxx.conf：

1 ls /etc/kubernetes/
2 admin.conf controller-manager.conf kubelet.conf scheduler.conf

这些文件里面记录的是，当前这个 Master 节点的服务器地址、监听端口、证书目录等信
息。这样，对应的客户端（比如 scheduler，kubelet 等），可以直接加载相应的文件，使
用里面的信息与 kube-apiserver 建立安全连接。
接下来，kubeadm 会为 Master 组件生成 Pod 配置文件。我已经在上一篇文章中和你介
绍过 Kubernetes 有三个 Master 组件 kube-apiserver、kube-controller-manager、
kube-scheduler，而它们都会被使用 Pod 的方式部署起来。
你可能会有些疑问：这时，Kubernetes 集群尚不存在，难道 kubeadm 会直接执行
docker run 来启动这些容器吗？
当然不是。
在 Kubernetes 中，有一种特殊的容器启动方法叫做“Static Pod”。它允许你把要部署的
Pod 的 YAML 文件放在一个指定的目录里。这样，当这台机器上的 kubelet 启动时，它会
自动检查这个目录，加载所有的 Pod YAML 文件，然后在这台机器上启动它们。
从这一点也可以看出，kubelet 在 Kubernetes 项目中的地位非常高，在设计上它就是一个
完全独立的组件，而其他 Master 组件，则更像是辅助性的系统容器。
在 kubeadm 中，Master 组件的 YAML 文件会被生成在 /etc/kubernetes/manifests 路
径下。比如，kube-apiserver.yaml：

1 apiVersion: v1
2 kind: Pod
3 metadata:
4 annotations:
5 scheduler.alpha.kubernetes.io/critical-pod: ""
6 creationTimestamp: null
7 labels:
8 component: kube-apiserver
9 tier: control-plane
10 name: kube-apiserver
11 namespace: kube-system
12 spec:
13 containers:
14 - command:
15 - kube-apiserver
16 - --authorization-mode=Node,RBAC
17 - --runtime-config=api/all=true
18 - --advertise-address=10.168.0.2
19 ...
20 - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
21 - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
22 image: k8s.gcr.io/kube-apiserver-amd64:v1.11.1
23 imagePullPolicy: IfNotPresent
24 livenessProbe:
25 ...
26 name: kube-apiserver
27 resources:
28 requests:
29 cpu: 250m
30 volumeMounts:
31 - mountPath: /usr/share/ca-certificates
32 name: usr-share-ca-certificates
33 readOnly: true
34 ...
35 hostNetwork: true
36 priorityClassName: system-cluster-critical
37 volumes:
38 - hostPath:
39 path: /etc/ca-certificates
40 type: DirectoryOrCreate
41 name: etc-ca-certificates
42 ...

关于一个 Pod 的 YAML 文件怎么写、里面的字段如何解读，我会在后续专门的文章中为你
详细分析。在这里，你只需要关注这样几个信息：

1. 这个 Pod 里只定义了一个容器，它使用的镜像是：k8s.gcr.io/kube-apiserveramd64:v1.11.1 。这个镜像是 Kubernetes 官方维护的一个组件镜像。
2. 这个容器的启动命令（commands）是 kube-apiserver --authorizationmode=Node,RBAC …，这样一句非常长的命令。其实，它就是容器里 kube-apiserver
   这个二进制文件再加上指定的配置参数而已。
3. 如果你要修改一个已有集群的 kube-apiserver 的配置，需要修改这个 YAML 文件。
4. 这些组件的参数也可以在部署时指定，我很快就会讲解到。
   在这一步完成后，kubeadm 还会再生成一个 Etcd 的 Pod YAML 文件，用来通过同样的
   Static Pod 的方式启动 Etcd。所以，最后 Master 组件的 Pod YAML 文件如下所示：
    复制代码
   1 $ ls /etc/kubernetes/manifests/
   2 etcd.yaml kube-apiserver.yaml kube-controller-manager.yaml kube-scheduler.yaml
   而一旦这些 YAML 文件出现在被 kubelet 监视的 /etc/kubernetes/manifests 目录下，
   kubelet 就会自动创建这些 YAML 文件中定义的 Pod，即 Master 组件的容器。
   Master 容器启动后，kubeadm 会通过检查 localhost:6443/healthz 这个 Master 组件的
   健康检查 URL，等待 Master 组件完全运行起来。

4. 生成token

kubeadm 就会为集群生成一个token。在后面，只要持有这个
token，任何一个安装了 kubelet 和 kubadm 的节点，都可以通过 kubeadm join 加入到
这个集群当中。
这个 token 的值和使用方法会，会在 kubeadm init 结束后被打印出来。

5. 信息录入configMap

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

6. 安装默认插件

kubeadm init 的最后一步，就是安装默认插件。Kubernetes 默认 kube-proxy 和 DNS,这两个插件是必须安装的。它们分别用来提供整个集群的服务发现和 DNS 功能。其实，这,两个插件也只是两个容器镜像而已，所以 kubeadm 只要用 Kubernetes 客户端创建两个
Pod 就可以了。

kubeadm join 的工作流程

这个流程其实非常简单，kubeadm init 生成 bootstrap token 之后，你就可以在任意一台
安装了 kubelet 和 kubeadm 的机器上执行 kubeadm join 了。
可是，为什么执行 kubeadm join 需要这样一个 token 呢？
因为，任何一台机器想要成为 Kubernetes 集群中的一个节点，就必须在集群的 kubeapiserver 上注册。可是，要想跟 apiserver 打交道，这台机器就必须要获取到相应的证书
文件（CA 文件）。可是，为了能够一键安装，我们就不能让用户去 Master 节点上手动拷
贝这些文件。
所以，kubeadm 至少需要发起一次“不安全模式”的访问到 kube-apiserver，从而拿到
保存在 ConfigMap 中的 cluster-info（它保存了 APIServer 的授权信息）。而 bootstrap
token，扮演的就是这个过程中的安全验证的角色。
只要有了 cluster-info 里的 kube-apiserver 的地址、端口、证书，kubelet 就可以以“安
全模式”连接到 apiserver 上，这样一个新的节点就部署完成了。
接下来，你只要在其他节点上重复这个指令就可以了。