【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎

文章目录

  • 系列文章目录
  • 关于作者
  • 一、前言|回顾
  • 二、静态和动态视图
  • 三、爆火的容器编排工具 Kubernetes 的诞生
  • 四、Kubernetes 要解决的问题是什么?
  • 五、理解 Kubernetes 全局架构图
    • Master(控制节点)
    • Node(计算节点)
      • Node 节点小结
  • 六、Kubernetes 设计思想
  • 七、Kubernetes 全景图
  • 总结
  • ✊ 最后
  • 参考

在这里插入图片描述

系列文章目录


【云原生|探索 Kubernetes-1】容器的本质是进程
【云原生|探索 Kubernetes-2】容器 Linux Cgroups 限制
【云原生|探索 Kubernetes 系列 3】深入理解容器进程的文件系统



关于作者


大家好,我是秋意零。

CSDN作者主页

  • 博客主页

简介

  • 普通本科生在读
  • 在校期间参与众多计算机相关比赛,如: “省赛”、“国赛”,斩获多项奖项荣誉证书
  • 各个平台,秋意零 账号创作者
  • 云社区 创建者
点赞、收藏+关注下次不迷路!

欢迎加入云社区


一、前言|回顾

今天介绍的主题是:Kubernetes 的本质。文章有点长,希望大家能完整阅读完,并品味。

前面三篇文章中,我们介绍了容器的具体实现是怎么回事。通过前三篇文章,你应该能理解:一个 “容器”,首先是启用 Linux Namespace(名称空间)、配置 Linux Cgroups(限制)、使用 rootfs (根文件系统) 三种技术来实现容器进程的隔离。

二、静态和动态视图

1.容器基础核心技术是由三个技术实现的:Linux Namespace、 Linux Cgroups、rootfs 。一个正在运行的 Linux 容器 ,我们可以 “一分为二” 看待为静态和动态视图:

  • 静态视图: 一组联合挂载目录 /var/lib/docker/overlay2//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 系列 4】理解现代云原生时代的引擎_第1张图片

四、Kubernetes 要解决的问题是什么?

容器编排?容器调度?容器集群管理?

但是实际上,随着社会和 Kubernetes 项目的不断发展,Kubernetes 需要解决的问题是不同的,所以没有一个标准答案,不过 Kubernetes 的诞生是为了解决容器编排的问题。

目前为止 Kubernetes 已经逐渐演进为云原生下的 ”操作系统”:

  • 操作系统一般有存储、网络、进程调度、设备管理、安全性管理、系统调用 API 等功能。所以类似操作系统一样 Kubernetes 也提供了的存储、网络、资源调度、设备管理、安全性管理、声明式 API。
  • 所以 Kubernetes 具有运维能力,比如自动化部署和扩展、高可用性和容错、水平扩展、服务发现和负载均衡、网络管理、存储管理、自动化滚动更新等。

所以 Kubernetes 解决的问题和所在的高度对比 Compose 、Swarm 是不一样的。

下图是 ChatGPT 回答的 “操作系统” 和 “Kubernetes(操作系统)” 功能对比图:

  • 【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第2张图片
  • 【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第3张图片

五、理解 Kubernetes 全局架构图

Kubernetes 项目依托 Borg 项目的理论优势,在短短几个月内迅速站稳了脚跟,进而确定了Kubernetes 全局架构图:

【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第4张图片
Kubernetes 架构是由 Master (控制节点)和 Node(计算节点) 两种节点组成:

Master(控制节点)

Master 控制节点,主要负责管理和控制整个集群的运行。

  • Master(控制节点):由三个独立的组件组成:kube-apiserver(提供 API 接口)、kube-apiserver(负责资源调度)、kube-controller-manager(负责容器编排控制)。整个集群的持久化数据,由 kube-apiserver 处理后交给 Etcd 键值对数据库保存。【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第5张图片

Kubernetes 没有把 Docker 作为整个框架的核心,而是把它作为做底层容器运行时实现。

Kubernetes 着重要解决的问题,则来自于 Borg 的研究人员在论文中提到的一个非常重要的观点:

  • 运行在大规模集群中的各种任务之间,实际上存在着各种各样的关系。这些关系的处理,才是作业编排和管理系统最困难的地方。

如:一个 Web 应用与后端数据库之间的访问关系,一个负载均衡器和它的后端服务之间的代理关系。

Node(计算节点)

Node(计算节点)承载容器的运行,负责运行容器的工作负载,并提供计算资源、容器运行时、容器网络、存储卷挂载等功能。

  • Node(计算节点):Node 节点中最核心的部分,是 kubelet 组件。

    • kubelet 主要负责和容器运行时打交道,这个交互依赖的是一个 CRI(Container Runtime Interface)容器运行时接口,这个接口是 Kubernetes 与容器运行时交互的标准接口,定义了容器运行的时候的各项核心操作,比如:容器的创建和销毁、容器的启动和停止。【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第6张图片
      【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第7张图片
      通过上图 ChatGPT 介绍,CRI 和容器运行时的关系是:CRI 是 Kubernetes 针对容器运行时的标准接口规范,定义了Kubernetes主节点和容器运行时之间的通信协议。而容器运行时则是实现这个规范的软件,用来启动、停止和管理容器的进程。容器运行时需要遵守 CRI 规范来与 Kubernetes 集群进行交互。


    这里需要说明的是:只要支持和 CRI 接口对接,就可以替换容器运行时和 Kubernetes 无缝集成,比如:Kubernetes 1.24.x 及以后的版本 ,Docker 项目已经不是 Kubernetes 的默认容器运行时了,而是 containerd,常见的容器运行时,可以看下图我在官网上截取的,更多信息参考官网)
    【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第8张图片

    • 容器运行时,通过 OCI 容器运行时规范和底层的 Linux 操作系统进行交互,把 CRI 请求翻译成对 Linux 系统的调用,对 Linux Namespace 和 Cgroups 操作等。
      【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第9张图片
    • 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 系列 4】理解现代云原生时代的引擎_第10张图片

六、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 项目核心功能的“全景图”:【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎_第11张图片
从这副图中,我们可以看到 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 则是我们这个系统中的应用程序。

✊ 最后


我是秋意零,欢迎大家一键三连、加入云社区

我们下期再见(⊙o⊙)!!!


参考

参考《深入剖析Kubernetes》作者 张磊

你可能感兴趣的:(#,深入探索,Kubernetes,kubernetes,云原生,Kubernetes全局架构,云计算,Kubernetes设计思想)