【云原生|探索 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 系列 5】简化 Kubernetes 的部署,深入解析其工作流程_第1张图片

文章目录

  • 前言
  • 系列文章目录
  • 一、解决部署 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 服务的网络代理和负载均衡功能。

【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署,深入解析其工作流程_第2张图片

为什么 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”。

  1. Linux 内核的版本是否是 3.10 以上
  2. Linux Cgroups 模块是否可用?
  3. 机器的 hostname 是否标准?在 Kubernetes 项目里,机器的名字以及一切存储在 Etcd 中的 API 对象,都必须使用标准的 DNS 命名(RFC 1123)。
  4. 用户安装的 kubeadm 和 kubelet 的版本是否匹配?
  5. Kubernetes 的工作端口 10250/10251/10252 端口是不是已经被占用?
  6. 检查节点的 CPU 资源是否满足要求。
  7. 检查节点上的 SELinux 配置是否与 Kubernetes 兼容。
  8. 检查节点的防火墙规则是否允许 Kubernetes 组件之间的通信。
  9. 检查节点的系统时间是否与其他节点同步。
  10. 更多 Checks 信息参考. . . . . .

生成证书文件

Preflight Checks 之后,生成 Kubernetes 对外提供服务所需的各种证书和对应的目录。
Kubernetes 对外提供服务时,除非开启 “不安全模式”,否则都是通过 HTTPS 才能访问 kube-apiserver,由于是 HTTPS 协议,就需要为 Kubernetes 集群配置好证书文件。

kubeadm 生成的证书文件都放在 Master 控制节点的 /etc/kubernetes/pki/ 目录下,在这个目录下,最主要的证书文件是 ca.crt 和对应的私钥 ca.key。

【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署,深入解析其工作流程_第3张图片
用户使用 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 的部署,深入解析其工作流程_第4张图片

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 的部署,深入解析其工作流程_第5张图片
上面这些 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。

在这里插入图片描述
【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署,深入解析其工作流程_第6张图片

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 集群的方式,可以应用到生产环境当中吗?

欢迎给位大佬在评论区讨论交流!(我会在评论区中或者下一篇文章中给出答案)

【云原生|探索 Kubernetes 系列 5】简化 Kubernetes 的部署,深入解析其工作流程_第7张图片

你可能感兴趣的:(#,深入探索,Kubernetes,kubernetes,云原生,kubeadm,容器,云计算运维)