【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署，深入解析其工作流程
前言
大家好，我是秋意零。
在前面 4 个章节中，我们充分了解了容器技术和 Kubernes 原生时代引擎的架构和设计思想，今天分享的主要内容是，探索 Kubernetes 部署，深入解析其工作流程
简介
- 个人主页： 秋意零
- 个人介绍：在校期间参与众多云计算相关比赛，如： “省赛”、“国赛”，并斩获多项奖项荣誉证书
- 目前状况：24 届毕业生，拿到一家私有云（IAAS）公司 offer，暑假开始实习
- 账号：各个平台， 秋意零 账号创作者、 云社区 创建者
- 欢迎大家：欢迎大家一起学习云计算，走向年薪 30 万
系列文章目录
【云原生|探索 Kubernetes-1】容器的本质是进程
【云原生|探索 Kubernetes-2】容器 Linux Cgroups 限制
【云原生|探索 Kubernetes 系列 3】深入理解容器进程的文件系统
【云原生|探索 Kubernetes 系列 4】现代云原生时代的引擎
正文开始：
- 快速上船，马上开始掌舵了（Kubernetes），距离开船还有 3s，2s，1s…
文章目录
- 前言
- 系列文章目录
- 一、解决部署 Kubernetes 复杂性问题
- 二、kubeadm 为什么没有容器化部署 kubelet ？
- 三、kubeadm init 工作流程
-
- Preflight Checks
- 生成证书文件
- 生成访问 kube-apiserver 所需的配置文件
- kubeadm 为运行在 Master 上的组件生成 Pod 配置文件
- configmap（cluster-info）
- 安装默认插件
- 四、kubeadm join 的工作流程
- 五、配置 kubeadm 部署参数
- 总结
- 留个问题
一、解决部署 Kubernetes 复杂性问题
万事开头难，Kubernetes 项目的部署一直以来都是初学者的 “拦路虎”。起初用户部署需要二进制安装，除了将各个组件编译成二进制文件外，复制二进制文件编写对应的配置文件，配置启动服务脚本以及对 kube-apiserver 配置授权文件等繁琐的步骤。
在 kubeadm 部署工具诞生之前，一般使用 Ansible、SlatStack等自动化运维工具部署 Kubernetes 项目。但是使用自动化工具还是比较繁琐，在使用 Ansible、SlatStack 或其他自动化工具之前，首先需要学习它们，而它们的学习成本都不低于 Kubernetes 项目，有可能还会更高。
这种情况下就急需一种简单部署 Kubernetes 项目的工具。2016年6月社区许多用户表达了 Kubernetes 部署的复杂性，直到2017年1月：kubeadm 项目在 Kubernetes 1.5 版本中首次发布为实验性功能。
kubeadm 的主要目标是提供一个简化的部署流程，而这个流程可以简化为下列两条命令，即可部署完 Kubernetes 项目：
- 1.初始化集群：用户在 master 控制节点，使用
kubeadm init命令初始化一个空白的 Kubernetes 集群，kubeadm 会自动生成所组件需要的证书和密钥，并容器部署配置 etcd、kube-apiserver、kube-controller-manager 和 kube-scheduler 的初始化工作； - 2.加入集群：用户在 node 计算节点，使用
kubeadm join命令将 node 计算节点加入到 Kubernetes 集群中。这个命令使用主节点生成的连接令牌，使得其他节点能够自动连接到集群并完成加入过程。
这样一看 Kubernetes 的部署过程，是不是非常方面啊？
需要注意的是：在执行
kubeadm init初始化集群之前，需要关闭交换分区、开启 ipv4（ipv6） 桥接流量转发、安装 Docker（或其他容器项目）、配置 Cgroup 类型与容器运行时的类型（如：systemd）一致等基础环境配置。如果您不清楚的话，可以查看下面这篇哦！！
配置基础环境和部署 Kubernetes 集群，可以查看这篇：部署kubernetes-v1.25.3（k8s）- 基于containerd容器运行时
二、kubeadm 为什么没有容器化部署 kubelet ？
使用 kubeadm 部署 Kubernetes 集群时，你会发现容器化部署并没有 kubelet 的身影。
coredns 组件： 用于 Kubernetes 集群中的 DNS服务器和服务发现组件。
kube-proxy 组件：主要负责实现 Kubernetes 服务的网络代理和负载均衡功能。
为什么 kubelet 没有使用容器化部署呢？
深入探究 Kubernetes 这个系列专栏中，在 第 4 篇文章介绍过，kubelet 组件需要和 CRI、Device Plugin、CNI、CSI 接口交互，而这些接口下层操作务必需要操作宿主机系统，如果 kubelet 使用容器化部署，那么直接操作宿主机就会变得非常麻烦。
- 对于网络配置来说还好，kubelet 容器可以通过不开启 Network Namespace（即 Docker 的 host network 模式）的方式，直接共享宿主机的网络栈；
- 可是，要让 kubelet 隔着容器的 Mount Namespace 和文件系统，操作宿主机的文件系统，就有点儿困难了。比如：在容器中执行
mount -t nfs命令，由于被隔离在了单独的 Mount Namespace，kubelet 做的挂载操作，不能被 “传播” 到宿主机上。
因上所述，Kubeadm 并没有把 kubelet 也部署在容器中，而是直接运行在宿主机上。所以我们在使用 kubeadm 的第一步，是在宿主机上执行 yum install -y kubeadm kubelet kubectl 命令安装。
三、kubeadm init 工作流程
Preflight Checks
在执行 kubeadm init 命令后，为保证 Kubernetes 集群正常部署完成，kubeadm 首先是进行一些列的环境检查，这个检查步骤，我们称为：“Preflight Checks”。
- Linux 内核的版本是否是 3.10 以上
- Linux Cgroups 模块是否可用？
- 机器的 hostname 是否标准？在 Kubernetes 项目里，机器的名字以及一切存储在 Etcd 中的 API 对象，都必须使用标准的 DNS 命名（RFC 1123）。
- 用户安装的 kubeadm 和 kubelet 的版本是否匹配？
- Kubernetes 的工作端口 10250/10251/10252 端口是不是已经被占用？
- 检查节点的 CPU 资源是否满足要求。
- 检查节点上的 SELinux 配置是否与 Kubernetes 兼容。
- 检查节点的防火墙规则是否允许 Kubernetes 组件之间的通信。
- 检查节点的系统时间是否与其他节点同步。
- 更多 Checks 信息参考. . . . . .
生成证书文件
Preflight Checks 之后，生成 Kubernetes 对外提供服务所需的各种证书和对应的目录。
Kubernetes 对外提供服务时，除非开启 “不安全模式”，否则都是通过 HTTPS 才能访问 kube-apiserver，由于是 HTTPS 协议，就需要为 Kubernetes 集群配置好证书文件。
kubeadm 生成的证书文件都放在 Master 控制节点的 /etc/kubernetes/pki/ 目录下，在这个目录下，最主要的证书文件是 ca.crt 和对应的私钥 ca.key。
用户使用 kubectl 操作容器时，需要通过 kube-apiserver 向 kubelet 发起请求，这个连接也必须时安全的。kubeadm 为这一步生成的是 apiserver-kubelet-client.crt 文件，对应的私钥是 apiserver-kubelet-client.key。
生成访问 kube-apiserver 所需的配置文件
证书生成后，kubeadm 接下来会为其他组件生成访问 kube-apiserver 所需的配置文件。这些文件的路径是：/etc/kubernetes/xxx.conf：
- 这些文件中记录了，当前这个 Master 节点的服务器地址、监听端口、证书目录等信息。这样，对应的客户端（这里如：scheduler，kubelet 组件），可以直接加载相应的文件，使用里面的信息与 kube-apiserver 建立安全连接了。
kubeadm 为运行在 Master 上的组件生成 Pod 配置文件
Kubernetes 有三个 Master 组件 kube-apiserver、kube-controller-manager、kube-scheduler，并使用 Pod 的方式部署起来。Etcd 和这三个组件 Pod 的 YAML 文件存放路径为：/etc/kubernetes/manifests/，这种以文件保存，并使用文件启动 Pod 的方式被称为：“Static pod”。
上面这些 YAML 文件及保存的位置，被 kubelet 监视，kubelet 就会自动创建这些 YAML 文件中定义的 Pod。
Master 容器启动后，kubeadm 会通过检查 https://localhost:6443/healthz 这个 Master 组件的健康检查 URL，等待 Master 组件完全运行起来。检查完之后，kubeadm 就会为集群生成一个 bootstrap token（引导令牌）。在后面，只要持有这个 token，任何一个安装了 kubelet 和 kubadm 的节点，都可以通过 kubeadm join 加入到这个集群当中。
可以通过
kubeadm token create --print-join-command命令生成 Node 节点加入集群的命令 token。
configmap（cluster-info）
在 token 生成之后，kubeadm 会将 ca.crt 等 Master 节点的重要信息，通过 ConfigMap 的方式保存在 Etcd 当中，供后续部署 Node 节点使用。这个 ConfigMap 的名字是 cluster-info。
安装默认插件
kubeadm init 的最后一步，就是安装默认插件。Kubernetes 默认 kube-proxy 和 coredns 这两个插件是必须安装的。kube-porxy 采用 Deamonset 方式部署，coredns 采用 Deployment 方式部署。
- kube-proxy：提供整个集群外的服务发现，如 service 的 nodeport 暴露策略是提供 Kubernetes 集群以外的其他服务的发现访问，但是需要提供七层代理的话这时候就需要采用 ingress 的插件来实现；
- coredns ：提供 DNS（域名解析） 功能，给 K8S 整个集群内部的 pod 直接的访问。
总结：kube-proxy 对集群外、coredns 对集群内
大佬求解：
这两个插件 YAML 文件按道理来说，对应 YAML 是会存在宿主机上的，查阅了资料说：
/etc/kubernetes/manifests/目录下的文件，可能存在的 coredns.yaml 和 kube-proxy.yaml 文件。但是我自己集群上并没有对应的文件，我使用的 Kubernetes 集群版本为 v1.23.1 和 v1.25.3。
四、kubeadm join 的工作流程
kubeadm init 生成 bootstrap token（引导令牌）之后，就可以在安装了 kubelet 和 kubeadm 的机器上执行 kubeadm join 加入集群的命令了。
为什么我们需要生成这样一个令牌呢？
想要成为 Kubernetes 集群中的一个节点，就必须在集群的 kube-apiserver 上注册。但是，跟 kube-apiserver 打交道，这台机器就必须要获取到相应的证书文件（CA 文件）。为了实现一键安装，就不能让用户去 Master 节点上手动拷贝这些文件。
这种情况下，kubeadm 至少需要发起一次 “不安全模式” 的访问到 kube-apiserver，从而拿到保存在 ConfigMap 中的 cluster-info（它保存了 APIServer 的授权信息）。有了 bootstrap token，就可以发起这种 “不安全模式” 的访问到 kube-apiserver，并且通过安全验证。
只要有了 cluster-info 里的 kube-apiserver 的地址、端口、证书，kubelet 就可以以 “安全模式” 连接到 apiserver 上，这样一个新的节点就部署完成了。
五、配置 kubeadm 部署参数
我们怎么实现，定制我的集群组件参数呢？
推荐：使用 kubeadm config print init-defaults > kubeadm.yaml 命令生成定制集群文件：
apiVersion: kubeadm.k8s.io/v1beta3
bootstrapTokens:
- groups:
- system:bootstrappers:kubeadm:default-node-token
token: abcdef.0123456789abcdef
ttl: 24h0m0s
usages:
- signing
- authentication
kind: InitConfiguration
localAPIEndpoint:
advertiseAddress: 1.2.3.4
bindPort: 6443
nodeRegistration:
criSocket: /var/run/dockershim.sock
imagePullPolicy: IfNotPresent
name: node
taints: null
---
apiServer:
timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta3
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns: {}
etcd:
local:
dataDir: /var/lib/etcd
imageRepository: k8s.gcr.io
kind: ClusterConfiguration
kubernetesVersion: 1.23.0
networking:
dnsDomain: cluster.local
serviceSubnet: 10.96.0.0/12
scheduler: {}
这样我们在使用 kubeadm init 初始化时，就使用下列这条命令即可：
kubeadm init --config kubeadm.yaml
总结
这里，我们分享了 kubeadm 部署 kubernetes 的使用方式。
我们从为何出现 kubeadm，解决了什么问题开始了我们这篇文章的开头。然后我们了解到 kubeadm 部署 Master 组件方式时采用容器化部署，而为什么 kubelet 组件没有采用容器化部署的原因。
最后，我们聊了聊 kubeadm 的 init 工作过程和 join 工作过程。init 工作过程大致上就是：检查环境、生成证书，配置访问 apiserver 的配置文件、以 Pod 部署方式部署 Master 组件。
通过这些，我们应该对 kubeadm 部署 Kuberentes 的方式有一个充分的认识。
留个问题
kubeadm 部署 Kubernetes 集群的方式，可以应用到生产环境当中吗？
欢迎给位大佬在评论区讨论交流！（我会在评论区中或者下一篇文章中给出答案）
