【云原生|探索 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/，这个是我们容器的 rootfs 根文件系统，也称为 “容器镜像”（Container Image），是容器的静态视图；/merged - 动态视图： 使用
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 存储插件深入展开，这会是后续重要的内容。
- kubelet 主要负责和容器运行时打交道，这个交互依赖的是一个 CRI（Container Runtime Interface）容器运行时接口，这个接口是 Kubernetes 与容器运行时交互的标准接口，定义了容器运行的时候的各项核心操作，比如：容器的创建和销毁、容器的启动和停止。
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 则是我们这个系统中的应用程序。
✊ 最后
我是秋意零，欢迎大家一键三连、加入云社区
我们下期再见(⊙o⊙)！！！
参考
参考《深入剖析Kubernetes》作者 张磊