Kubernetes 5| 简化 Kubernetes 部署
前言
大家好,我是秋意零。
在前面 4 个章节中,我们充分了解了容器技术和 Kubernes 原生时代引擎的架构和设计思想,今天分享的主要内容是,探索 Kubernetes 部署,深入解析其工作流程
👿 简介
- 🏠 个人主页: 秋意零
- 🧑 个人介绍:在校期间参与众多云计算相关比赛,如:🌟 “省赛”、“国赛”,并斩获多项奖项荣誉证书
- 🎉 目前状况:24 届毕业生,拿到一家私有云(IAAS)公司 offer,暑假开始实习
- 🔥 账号:各个平台, 秋意零 账号创作者、 云社区 创建者
- 💕欢迎大家:欢迎大家一起学习云计算,走向年薪 30 万
系列文章目录
【云原生|探索 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 服务的网络代理和负载均衡功能。
为什么 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 集群的方式,可以应用到生产环境当中吗?
欢迎给位大佬在评论区讨论交流!(我会在评论区中或者下一篇文章中给出答案)