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 上,这样一个新的节点就部署完成了。
接下来,你只要在其他节点上重复这个指令就可以了。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

kjkdd

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值