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

这篇具有很好参考价值的文章主要介绍了【云原生|探索 Kubernetes 系列 4】理解现代云原生时代的引擎。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

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

系列文章目录

【云原生|探索 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/<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 系列 4】理解现代云原生时代的引擎

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

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

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

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

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

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

下图是 ChatGPT 回答的 “操作系统” 和 “Kubernetes（操作系统）” 功能对比图：

五、理解 Kubernetes 全局架构图

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

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