【探索 Kubernetes|集群搭建篇系列 5】简化 Kubernetes 的部署，深入解析其工作流程-Toy模板网

这篇具有很好参考价值的文章主要介绍了【探索 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 复杂性问题

万事开头难，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 服务的网络代理和负载均衡功能。

【探索 Kubernetes|集群搭建篇系列 5】简化 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。

【探索 Kubernetes|集群搭建篇系列 5】简化 Kubernetes 的部署，深入解析其工作流程
用户使用 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 建立安全连接了。

【探索 Kubernetes|集群搭建篇系列 5】简化 Kubernetes 的部署，深入解析其工作流程

kubeadm 为运行在 Master 上的组件生成 Pod 配置文件

Kubernetes 有三个 Master 组件 kube-apiserver、kube-controller-manager、kube-scheduler，并使用 Pod 的方式部署起来。Etcd 和这三个组件 Pod 的 YAML 文件存放路径为：/etc/kubernetes/manifests/，这种以文件保存，并使用文件启动 Pod 的方式被称为：“Static pod”。
【探索 Kubernetes|集群搭建篇系列 5】简化 Kubernetes 的部署，深入解析其工作流程
上面这些 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: {}