系列文章目录
大家好,我是秋意零。
点赞、收藏+关注下次不迷路!
一、前言|回顾
今天介绍的主题是:Kubernetes 的本质。文章有点长,希望大家能完整阅读完,并品味。
前面三篇文章中,我们介绍了容器的具体实现是怎么回事。通过前三篇文章,你应该能理解:一个 “容器”,首先是启用 Linux Namespace(名称空间)、配置 Linux Cgroups(限制)、使用 rootfs (根文件系统) 三种技术来实现容器进程的隔离。
二、静态和动态视图
1.容器基础核心技术是由三个技术实现的:Linux Namespace、 Linux Cgroups、rootfs 。一个正在运行的 Linux 容器 ,我们可以 “一分为二” 看待为静态和动态视图:
-
静态视图: 一组联合挂载目录 /var/lib/docker/overlay2/<directory-of-running-container>/merged
,这个是我们容器的 rootfs 根文件系统,也称为 “容器镜像”(Container Image),是容器的静态视图; -
动态视图: 使用 Namespace + Cgroups
技术构建的隔离环境,我们称为 “容器运行时”(Container Runtime),是容器的动态视图。
2.如果你是一名开发人员,我们只需要关心 “容器镜像”,而如果你是一名运维人员,你需要关心 “容器运行时”。软件开发流程:开发-测试-发布-运维,“容器镜像”(这里是开发部分)承载着容器信息的传递,而不是 “容器运行时”(这里是运维部分)。
-
因为开发者只需要编写代码,代码跑起来程序正常运行就行,是属于 “容器镜像”部分; -
而运维者需要维护这个程序的生命周期,管理程序状态的,是属于 “容器运行时” 的部分
3.这里的价值在于:通过容器镜像将开发者关联起来,科技圈中 “得开发者得天下”。
-
开发者,负责将自己的程序代码打包为容器镜像; -
运维者或用户,将容器镜像运行为容器。
❝
这样,容器从一个开发者当中的工具,一跃变成了云计算领域的绝对主角;
而这里容器还不够有意义,更有意义的是 “容器编排”,因为单一的容器,到庞大的容器集群,从容器到容器云的飞跃,非常需要对容器进行编排管理; 而能够定义容器组织和管理规范的 “容器编排” 技术,则会是容器技术领域的 “头把交椅”。
三、爆火的容器编排工具 Kubernetes 的诞生
具有代表性的容器编排工具(这里主要介绍 Kubernetes):
-
Docker 公司的 Compose + Swarm
组合; -
Google 和 RedHat 公司主导的 Kubernetes
项目。
Kubernetes 是由 Google 开源的容器编排系统,最初是基于 Google 内部的 Borg 系统(始于 2003 年)开发的。2014 年,Google 将 Kubernetes 作为开源项目发布,并将其交给了 Cloud Native Computing Foundation(CNCF)来管理和维护,使其成为一个全球性的开源项目。Kubernetes 的诞生是为了解决容器编排的问题,使得开发人员能够更轻松地管理和部署大规模容器化应用程序。
❝
Google 公司的 Borg 系统和 Borg 论文密切相关。Borg 论文是由 Google 的工程师们在 2015 年 4 月发表的一篇论文,详细描述了 Borg 系统的设计、实现和应用场景。这篇论文对于后来 Kubernetes 的设计和发展产生了深远的影响。 因此,Borg 系统和 Borg 论文可以说是互相关联、相辅相成的。
Borg 系统要承担的责任,是承载 Google 公司整个基础设施的核心依赖。在 Google 整个基础设施技术栈的最底层。正是由于这个地位,Borg 可以说是 Google 最不可能开源的一个项目。而幸运的是,得益于 Docker 项目和容器技术的风靡,它却终于得以以另一种方式与开源社区见面,这个方式就是 Kubernetes 项目。
Kubernetes 项目在 Borg 体系的指导下,体现出了一种独有的 “先进性” 与 “完备性”。
四、Kubernetes 要解决的问题是什么?
容器编排?容器调度?容器集群管理?
但是实际上,随着社会和 Kubernetes 项目的不断发展,Kubernetes 需要解决的问题是不同的,所以没有一个标准答案,不过 Kubernetes 的诞生是为了解决容器编排的问题。
目前为止 Kubernetes 已经逐渐演进为云原生下的 ”操作系统”:
-
操作系统一般有存储、网络、进程调度、设备管理、安全性管理、系统调用 API 等功能。所以类似操作系统一样 Kubernetes 也提供了的存储、网络、资源调度、设备管理、安全性管理、声明式 API。 -
所以 Kubernetes 具有运维能力,比如自动化部署和扩展、高可用性和容错、水平扩展、服务发现和负载均衡、网络管理、存储管理、自动化滚动更新等。
❝
所以 Kubernetes 解决的问题和所在的高度对比 Compose 、Swarm 是不一样的。
下图是 ChatGPT 回答的 “操作系统” 和 “Kubernetes(操作系统)” 功能对比图:
-
在这里插入图片描述 -
在这里插入图片描述
五、理解 Kubernetes 全局架构图
Kubernetes 项目依托 Borg 项目的理论优势,在短短几个月内迅速站稳了脚跟,进而确定了Kubernetes 全局架构图:
Kubernetes 架构是由 Master (控制节点)和 Node(计算节点) 两种节点组成:
Master(控制节点)
Master 控制节点,主要负责管理和控制整个集群的运行。
-
Master(控制节点):由三个独立的组件组成:kube-apiserver(提供 API 接口)、kube-apiserver(负责资源调度)、kube-controller-manager(负责容器编排控制)。整个集群的持久化数据,由 kube-apiserver 处理后交给 Etcd 键值对数据库保存。
Kubernetes 没有把 Docker 作为整个框架的核心,而是把它作为做底层容器运行时实现。
Kubernetes 着重要解决的问题,则来自于 Borg 的研究人员在论文中提到的一个非常重要的观点:
-
❝
运行在大规模集群中的各种任务之间,实际上存在着各种各样的关系。这些关系的处理,才是作业编排和管理系统最困难的地方。
如:一个 Web 应用与后端数据库之间的访问关系,一个负载均衡器和它的后端服务之间的代理关系。
Node(计算节点)
Node(计算节点)承载容器的运行,负责运行容器的工作负载,并提供计算资源、容器运行时、容器网络、存储卷挂载等功能。
-
Node(计算节点):Node 节点中最核心的部分,是 kubelet 组件。
-
kubelet 主要负责和容器运行时打交道,这个交互依赖的是一个 CRI(Container Runtime Interface)容器运行时接口,这个接口是 Kubernetes 与容器运行时交互的标准接口,定义了容器运行的时候的各项核心操作,比如:容器的创建和销毁、容器的启动和停止。
通过上图 ChatGPT 介绍,CRI 和容器运行时的关系是:CRI 是 Kubernetes 针对容器运行时的标准接口规范,定义了Kubernetes主节点和容器运行时之间的通信协议。而容器运行时则是实现这个规范的软件,用来启动、停止和管理容器的进程。容器运行时需要遵守 CRI 规范来与 Kubernetes 集群进行交互。(这里需要说明的是:只要支持和 CRI 接口对接,就可以替换容器运行时和 Kubernetes 无缝集成,比如:Kubernetes 1.24.x 及以后的版本 ,Docker 项目已经不是 Kubernetes 的默认容器运行时了,而是 containerd,常见的容器运行时,可以看下图我在官网上截取的,更多信息参考官网)
-
容器运行时,通过 OCI 容器运行时规范和底层的 Linux 操作系统进行交互,把 CRI 请求翻译成对 Linux 系统的调用,对 Linux Namespace 和 Cgroups 操作等。
-
kubelet 还通过 gRPC 协议与 Device Plugin 设备插件进行交互。这个插件是 Kubernetes 用来添加和管理 GPU、FPGA、网络适配器等宿主机物理设备的主要组件,也是 Kubernetes 项目进行机器学习训练、高性能作业支持等工作必须关注的功能,因为这些功能需要高算力的支持。提供给 Pod 使用(声明相应的 Device Request 来获取这些资源,并绑定到自己的容器中)。 -
kubelet 的另一个重要功能,是调用 CNI 容器网络接口(Container Networking Interface)和 CSI 容器存储接口(Container Storage Interface),分别为 Kubernetes 项目提供容器网络配置和持久化存储。
这里目前不对 CNI 网络插件和 CSI 存储插件深入展开,这会是后续重要的内容。
-
Node 节点小结
Node 计算节点 kubelet 工作流程图:
-
kubelet 直接与 CRI(容器运行时接口)、Device Plugin (设备插件)、CNI(容器网络接口)、CSI(容器存储接口)交互: -
CRI(容器运行时接口): CRI 向下走,与 Container Runtime(容器运行时)交互,容器运行时负责操作容器生命周期,再下走需要与 Linux 系统直接交互,来操作 Linux Namespace、Linux Cgroups 等。 -
Device Plugin(设备插件):Device Plugin 添加管理宿主机物理设备,如 GPU、FPGA(集成电路设备),下层是直接与 Linux 宿主操作系统交互,最终会将资源分配给容器。 -
CNI(容器网络接口):CNI 与 Networking 交互,Networking 负责处理容器网络相关的功能和配置,Networking 与 Linux 系统交互。首先为容器创建一个网络接口(包括IP地址、子网掩码、网关等网络参数),其次配置网络路由(Linux 宿主机上设置,确保容器可以与其他网络节点进行通信),最后连接网络设备(与Linux宿主机上的网络设备进行交互,如:虚拟网络设备、配置VLAN)。 -
CSI(容器存储接口): 容器存储管理的标准接口,与存储提供商之间定义了一致的交互方式,这里与 Volume Plugin 卷插件交互,负责管理容器存储卷(提供具体功能),与 Linxu 宿主机交互,提供存储卷的挂载、卸载和管理等功能
-
六、Kubernetes 设计思想
在传统虚拟机中,发现并不相关的应用被一股脑儿地部署在同一台虚拟机中(粗粒度),有了容器之后就是单独一个应用一个环境(粗粒度)。容器也是 “微服务” 思想得以落地的先决条件。
如果只做 “封装微服务、调度单容器” 这一层次,Docker Swarm + Compose 项目就能很好实现,并具备了处理一些简单依赖关系,如:一个 “Web 容器” 和它的后端数据库 “DB 容器” 之间的访问。
在 Compose 中,你可以使用 “link” 将这两个具有依赖关系的容器联系起来,这种 “link” 实际上是配置了两个容器之间的 /etc/hosts
文件。
-
但是这种方案还是过去简单了,没有办法支持未来可能出现的更多种类的关系。架构一般是:追求项目的普适性,就一定要从顶层开始做好设计。
Kubernetes 项目最主要的设计思想是,从更宏观的角度,以统一的方式来定义任务之间的各种关系,并且为将来支持更多种类的关系留有余地。
Kubernetes 对容器间的 "访问“ 进行了分类,比如:Pod,它是 Kubernetes 中最基本的单元,Pod 中可以包含一个或多个容器,这些容器可以通过 locahost
进行频繁的交互和访问,也可以通过本地磁盘目录交换文件,因为一个 Pod 中它们的 Network Namespace 和数据卷是共享的,从而提高效率来交换信息。
❝
需要注意的是:需要非常频繁的交互和访问,我们一般把这类容器放入到一个 Pod 中。
对于另外一种更为常见的需求,比如: Web 应用与数据库之间的访问关系,它们之间一般不会部署到一个 Pod 中或者说一台机器上,这样即使 Web 端 down 机了,数据库也不会受到影响,对于容器来说把当前运行的容器删除了,或者后端数据库做了高可用(前端也可以)IP地址会变化或后端 IP 地址很多,这种时候 Web 怎么和数据库连接呢?
-
Kubernetes 为这种情况提供了一个叫 ”Service“ 的服务。目前你可以把 Service 看作一个做负载均衡和服务发现的一个服务。Service 为我们提供了一个虚拟 VIP,我们访问这个与后端数据库关联的 VIP 地址,它就会为我们代理到后端的数据库上,并且支持负责均衡和服务发现(外部可以访问)。
七、Kubernetes 全景图
从 Servcie 服务可以看到,我们都是围绕着 Pod 去扩展和去提供服务的,我们可以看下图 Kubernetes 项目核心功能的“全景图”:
从这副图中,我们可以看到 Pod 的地位是在最中心,所有的服务都是为 Pod 提供服务或者管理 Pod。
从容器这个最基础的概念出发,首先遇到了容器间 “紧密协作” 关系的难题,于是就有了 Pod;有了 Pod 之后,我们希望能一次启动或收缩多个应用的实例,这样就需要 Deployment 这个 Pod 的控制器;有了这样的控制器之后(一组相同的 Pod),就需要一个 VIP 来负载均衡和暴露服务访问它,这个时候就有了 Service。
这个时候还有一些问题,比如:Web 访问数据库时肯定时需要密码的,这个时候我们怎么安全的定义密码而不会以明文的方式暴露在外呢?
-
Kubernetes 提供了一个加 Secret 服务,它把键值对的数据保存在 Etcd 中,我们使用这个密码信息时,就要用到 Secret 里的数据以 Volume 的方式挂载到容器里。
Kubernetes 项目并没有像其他项目那样,为每一个管理功能创建一个指令,然后在项目中实现其中的逻辑。
-
相比之下,在 Kubernetes 项目中,我们所推崇的使用方法是: -
首先,通过一个“编排对象”,比如 Pod、Job、CronJob、Deployment 等,来描述你试图管理的应用; -
然后,再为它定义一些“服务对象”,比如 Service、Secret、Horizontal Pod Autoscaler(自动水平扩展器)等。这些对象,会负责具体的平台级功能。
-
这种使用方法,就是所谓的 “声明式 API”。这种 API 对应的 “编排对象” 和 “服务对象”,都是 Kubernetes 项目中的 API 对象(API Object)。
总结
首先我们简单的回顾了一下前面章节的知识,理解静态视图和动态视图,了解开发和运维在容器中所承担的角色。
接着我们介绍了 Kubernetes 它和 borg 系统和论文之间的关系,这里也说明了 Kubernetes 诞生的基础,阐述了 Kubernetes 是为解决什么问题而诞生的。然后我们重点介绍了 Kubernetes 的全局架构图,从 Master 控制节点和 Node 计算节点展开。
最后我们说明了设计思想所站在的高度和其他项目有什么不同,同时阐述了 Kubernetes 之间的对象服务关系,分清楚 “编排对象” 和 “服务对象”,理解 Kubernetes 是管理 Pod 以及为 Pod 提供服务的。通过 Pod 我们应该能明白 Kubernetes 是可以想象成操作系统的,为 Pod 提供网络、存储、安全、等服务,而 Pod 则是我们这个系统中的应用程序。
参考
参考《深入剖析Kubernetes》作者 张磊
非特殊说明,本博所有文章均为博主原创。
如若转载,请注明出处:https://www.qiuyl.com/cloudnative/kubernetes-xilie/202
共有 0 条评论