Kubernetes — 核心资源对象 — 计算实例

Bertha 。 2023-10-01 21:53 31阅读 0赞

## 目录 ##

#### 文章目录 ####

*  目录
 *  Object
 *  容器与镜像
 *   *  什么是容器？
     *  什么是镜像？
     *  如何运行容器？
     *  容器运行时的生命周期
 *  Pod
 *   *  Pod 的本质是什么？
     *  Pod 的实现机制
     *   *  共享网络
         *  共享存储
     *  Pod 的生命周期
 *  Label
 *  ConfigMap
 *  容器设计模式
 *   *  InitContainer
     *  Sidecar

## Object ##

Object 是 Kubernetes 系统中的持久化实体（存储在 etcd cluster 中），Kubernetes 使用这些 objects 来表示集群中的状态。

这些 Object 描述了哪些应用应该运行在集群中，它们请求的资源下限和上限以及重启、升级和容错的策略。每一个创建的对象其实都是我们对集群状态的改变，这些对象描述的其实就是集群的期望状态，Kubernetes 会根据我们指定的期望状态不断检查对当前的集群状态进行迁移。

type Deployment struct {
        
        metav1.TypeMeta `json:",inline"`
        metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"`
    
        Spec DeploymentSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"`
        Status DeploymentStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"`
    }

每一个 Object 都包含两个嵌套对象来描述规格（Spec）和状态（Status），对象的规格其实就是我们期望的目标状态，而状态描述了对象的当前状态，这部分一般由 Kubernetes 系统本身提供和管理，是我们观察集群本身的一个接口。

## 容器与镜像 ##

### 什么是容器？ ###

在介绍容器的具体概念之前，先简单回顾一下操作系统是如何管理进程的。

首先，当我们登录到操作系统之后，可以通过 ps 等操作看到各式各样的进程，这些进程包括系统自带的服务和用户的应用进程。那么，这些进程都有什么样的特点？

1.  第一，这些进程可以相互看到、相互通信；
2.  第二，它们使用的是同一个文件系统，可以对同一个文件进行读写操作；
3.  第三，这些进程会使用相同的系统资源。

这样的三个特点会带来什么问题呢？

1.  因为这些进程能够相互看到并且进行通信，高级权限的进程可以攻击其他进程；
2.  因为它们使用的是同一个文件系统，因此会带来两个问题：这些进程可以对于已有的数据进行增删改查，具有高级权限的进程可能会将其他进程的数据删除掉，破坏掉其他进程的正常运行；此外，进程与进程之间的依赖可能会存在冲突，如此一来就会给运维带来很大的压力；
3.  因为这些进程使用的是同一个宿主机的资源，应用之间可能会存在资源抢占的问题，当一个应用需要消耗大量 CPU 和内存资源的时候，就可能会破坏其他应用的运行，导致其他应用无法正常地提供服务。

针对上述的三个问题，如何为进程提供一个独立的运行环境呢？

1.  针对不同进程使用同一个文件系统所造成的问题而言，Linux 和 Unix 操作系统可以通过 chroot 系统调用将子目录变成根目录，达到视图级别的隔离；进程在 chroot 的帮助下可以具有独立的文件系统，对于这样的文件系统进行增删改查不会影响到其他进程；
2.  因为进程之间相互可见并且可以相互通信，使用 Namespace 技术来实现进程在资源的视图上进行隔离。在 chroot 和 Namespace 的帮助下，进程就能够运行在一个独立的环境下了；
3.  但在独立的环境下，进程所使用的还是同一个操作系统的资源，一些进程可能会侵蚀掉整个系统的资源。为了减少进程彼此之间的影响，可以通过 Cgroup 来限制其资源使用率，设置其能够使用的 CPU 以及内存量。

综上可以得到答案：**容器就是一个视图隔离、资源可限制、独立文件系统的进程集合**。

*  所谓 “视图隔离” 就是能够看到部分进程以及具有独立的主机名等；
 *  控制资源使用率则是可以对于内存大小以及 CPU 使用个数等进行限制；
 *  容器具有一个独立的文件系统，因为使用的是系统的资源，所以在独立的文件系统内不需要具备内核相关的代码或者工具，我们只需要提供容器所需的二进制文件、配置文件以及依赖即可。只要容器运行时所需的文件集合都能够具备，那么这个容器就能够运行起来。

### 什么是镜像？ ###

综上所述，我们将这些：**容器运行时所需要的所有的文件集合称之为容器镜像**。

通常情况下，我们会采用 Dockerfile 来构建镜像，这是因为 Dockerfile 提供了非常便利的语法糖，能够帮助我们很好地描述构建的每个步骤。当然，每个构建步骤都会对已有的文件系统进行操作，这样就会带来文件系统内容的变化，我们将这些变化称之为 changeset。当我们把构建步骤所产生的变化依次作用到一个空文件夹上，就能够得到一个完整的镜像。

changeset 的分层以及复用特点能够带来几点优势：

1.  第一，能够提高分发效率，简单试想一下，对于大的镜像而言，如果将其拆分成各个小块就能够提高镜像的分发效率，这是因为镜像拆分之后就可以并行下载这些数据；
2.  第二，因为这些数据是相互共享的，也就意味着当本地存储上包含了一些数据的时候，只需要下载本地没有的数据即可，举个简单的例子就是 golang 镜像是基于 alpine 镜像进行构建的，当本地已经具有了 alpine 镜像之后，在下载 golang 镜像的时候只需要下载本地 alpine 镜像中没有的部分即可；
3.  第三，因为镜像数据是共享的，因此可以节约大量的磁盘空间，简单设想一下，当本地存储具有了 alpine 镜像和 golang 镜像，在没有复用的能力之前，alpine 镜像具有 5M 大小，golang 镜像有 300M 大小，因此就会占用 305M 空间；而当具有了复用能力之后，只需要 300M 空间即可。

### 如何运行容器？ ###

运行一个容器一般情况下分为三步：

1.  第一步：从镜像仓库中将相应的镜像下载下来；
2.  第二步：当镜像下载完成之后就可以通过 docker images 来查看本地镜像，这里会给出一个完整的列表，我们可以在列表中选中想要的镜像；
3.  第三步：当选中镜像之后，就可以通过 docker run 来运行这个镜像得到想要的容器，当然可以通过多次运行得到多个容器。一个镜像就相当于是一个模板，一个容器就像是一个具体的运行实例，因此镜像就具有了一次构建、到处运行的特点。

### 容器运行时的生命周期 ###

容器是一组具有隔离特性的进程集合，在使用 docker run 的时候会选择一个镜像来提供独立的文件系统并指定相应的运行程序。这里指定的运行程序称之为 initial 进程，这个 initial 进程启动的时候，容器也会随之启动，当 initial 进程退出的时候，容器也会随之退出。

因此，可以认为容器的生命周期和 initial 进程的生命周期是一致的。当然，因为容器内不只有这样的一个 initial 进程，initial 进程本身也可以产生其他的子进程或者通过 docker exec 产生出来的运维操作，也属于 initial 进程管理的范围内。当 initial 进程退出的时候，所有的子进程也会随之退出，这样也是为了防止资源的泄漏。

但是这样的做法也会存在一些问题，首先应用里面的程序往往是有状态的，其可能会产生一些重要的数据，当一个容器退出被删除之后，数据也就会丢失了，这对于应用方而言是不能接受的，所以需要将容器所产生出来的重要数据持久化下来。容器能够直接将数据持久化到指定的目录上，这个目录就称之为数据卷。

数据卷有一些特点，其中非常明显的就是数据卷的生命周期是独立于容器的生命周期的，也就是说容器的创建、运行、停止、删除等操作都和数据卷没有任何关系，因为它是一个特殊的目录，是用于帮助容器进行持久化的。简单而言，我们会将数据卷挂载到容器内，这样一来容器就能够将数据写入到相应的目录里面了，而且容器的退出并不会导致数据的丢失。

通常情况下，数据卷管理主要有两种方式：

1.  第一种是通过 bind 的方式，直接将宿主机的目录直接挂载到容器内；这种方式比较简单，但是会带来运维成本，因为其依赖于宿主机的目录，需要对于所有的宿主机进行统一管理。
2.  第二种是将目录管理交给运行引擎。

## Pod ##

Kubernetes 以 Pod 为最小单位进行调度、扩展、资源分配、管理生命周期。Pod 的运行模式通常设置为单个主容器，也可选择添加对日志支持等辅助功能的挎斗模式（sidecar）容器。Pod 通常由 Deployment 管理。

为什么要引入 Pod 这一逻辑对象？

*  **可管理性**：有些容器天生就是需要紧密联系，一起工作的。例如：微服务中的 Side Car（边车）模式，Pod 中的一个 ContainerA 提供业务，另一个 ContainerB 专门负责对 ContainerA 进行收集、监控日志和流量信息；又例如：ContainerA 作为 File Puller 定期从外部拉取最新的文件，将其存放到共享 Volume 中，ContainerB 作为 Web Server 直接从 Volume 读取文件，两个 Containers 紧密合作；Pod 将 Containers 封装到一个部署单元中。
 *  **通信和资源共享**：Pod 中的所有 Containers 使用同一个 network namespace，即 Containers 具有相同的 IP 地址和 Port 空间，它们互相之间可以直接用 localhost 进行通信。同样的，这些容器也会共享存储，当 Kubernetes 挂载 Volume 到 Pod，本质上是将 Volume 挂载到 Pod 中的每一个 Container。

由此，Pod 是 Containers 的集合，共享存储和网络。Pod 具有独立的 IP 地址、主机名（Hostname），Pod 中的 Containers 共享这个 IP 地址、端口空间，并且可以通过 localhost 彼此查找。Pod 利用 Namespace 进行资源隔离，相当于一个独立的沙箱环境。不同的 Pod 之间的通信属于远程访问。

Pod 是虚拟的资源对象（进程），如果没有实体（物理机，物理网卡）与之对应，就无法直接对外提供服务访问。所以，Pod 如果想要对外提供服务，必须绑定物理主机的端口，让这个端口和 Pod 的端口进行映射，这样就可以通过物理主机的 IP + Port 进行数据包的转发。

![在这里插入图片描述][1ab6687c17f64cb68ccc080676d70006.png]

![在这里插入图片描述][bf50f1d970474aa980ccd898f5e36984.png]

### Pod 的本质是什么？ ###

*  容器的本质是一个进程，是一个视图被隔离，资源被受限的进程。
 *  容器镜像的本质是一个包含了容器运行时全部所需文件的集合。
 *  Kubernetes 的本质是是云时代的操作系统，它管理着这些进程（容器）。

实际上，一个生产应用往往需要多个进程之间（进程组）的协同才能完成工作，所以同一个进程组中的进程应该统一被原子性的进行调度、运行和销毁。

可见，Pod 的本质对应的就是一个进程组，是一个最终生产应用的逻辑集合。

### Pod 的实现机制 ###

像 Pod 这样一个东西，本身是一个逻辑概念。那在机器上，它究竟是怎么实现的呢？

核心就在于如何让一个 Pod 里的多个容器之间最高效的共享某些资源和数据。因为，容器之间原本是被 Linux Namespace 和 cgroups 隔开的，所以现在实际要解决的是怎么去打破这个隔离，然后共享某些事情和某些信息。这就是 Pod 的设计要解决的核心问题所在。

#### 共享网络 ####

比如说现在有一个 Pod，其中包含了一个容器 A 和一个容器 B，它们两个就要共享 Network Namespace。在 Kubernetes 里的解法是这样的：它会在每个 Pod 里，额外起一个 Infra container 小容器来共享整个 Pod 的 Network Namespace。

Infra container 是一个非常小的镜像，大概 100~200KB 左右，是一个汇编语言写的、永远处于 “暂停” 状态的容器。由于有了这样一个 Infra container 之后，其他所有容器都会通过 Join Namespace 的方式加入到 Infra container 的 Network Namespace 中。

所以说一个 Pod 里面的所有容器，它们看到的网络视图是完全一样的。即：它们看到的网络设备、IP地址、Mac地址等等，跟网络相关的信息，其实全是一份，这一份都来自于 Pod 第一次创建的这个 Infra container。这就是 Pod 解决网络共享的一个解法。

在 Pod 里面，一定有一个 IP 地址，是这个 Pod 的 Network Namespace 对应的地址，也是这个 Infra container 的 IP 地址。所以大家看到的都是一份，而其他所有网络资源，都是一个 Pod 一份，并且被 Pod 中的所有容器共享。这就是 Pod 的网络实现方式。

由于需要有一个相当于说中间的容器存在，所以整个 Pod 里面，必然是 Infra container 第一个启动。并且整个 Pod 的生命周期是等同于 Infra container 的生命周期的，与容器 A 和 B 是无关的。这也是为什么在 Kubernetes 里面，它是允许去单独更新 Pod 里的某一个镜像的，即：做这个操作，整个 Pod 不会重建，也不会重启，这是非常重要的一个设计。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr_size_16_color_FFFFFF_t_70]

#### 共享存储 ####

Pod 共享存储就相对比较简单。

比如说现在有两个容器，一个是 Nginx，另外一个是非常普通的容器，在 Nginx 里放一些文件，让我能通过 Nginx 访问到。所以它需要去 share 这个目录。我 share 文件或者是 share 目录在 Pod 里面是非常简单的，实际上就是把 volume 变成了 Pod level。然后所有容器，就是所有同属于一个 Pod 的容器，他们共享所有的 volume。

例如有一个 volume 叫做 shared-data，它是属于 Pod level 的，所以在每一个容器里可以直接声明：要挂载 shared-data 这个 volume，只要你声明了你挂载这个 volume，你在容器里去看这个目录，实际上大家看到的就是同一份。这个就是 Kubernetes 通过 Pod 来给容器共享存储的一个做法。

所以，如果一个应用容器 App 写了日志，只要这个日志是写在一个 volume 中，只要声明挂载了同样的 volume，这个 volume 就可以立刻被另外一个 LogCollector 容器给看到。以上就是 Pod 实现存储的方式。

### Pod 的生命周期 ###

在 kubernetes 的官方文档中，对 Pod 的生命周期做出了解释。

和容器类似的，Pod 也是一个具有临时性（而不是长期存在）的实体。Pod 本身不具备自愈能力，在创建时，Pod 会被赋予一个 UUID，然后被调度到某个 Node，在终止（根据重启策略）或删除该 Pod 之前就一直运行在该 Node 上。注意，如果一个 Node 宕机了，那么调度到该 Node 的 Pods 也会在计划给定的超时期限后被删除。

Kubernetes 通过 Controller 来管理这些 “临时性” 的 Pod，当一个 Pod（由 UUID 定义）被删除后，Controller 会启动一个新的、几乎完全相同的 Pod 来进行替代。如果需要的话，新 Pod 的名字保持不变，但是其 UID 也会不同，表示并非是同一个 Pod。

对于 “普通” 的 Volume 而言，其生命周期与 Pod 一样，即：Volume 会伴随 Pod 的整个生命周期，Pod 删除或重建后，那么 Pod 运行期间产生的数据就会随之被删除。

## Label ##

Label 是一个非常核心的 kubernetes API 的概念，本质是一组 Key/Value Pair。这些 Label 可以被 Selector，也就是被选择器所查询到。与 SQL 中的 select 语句是非常相似的。

通过 Label，kubernetes 的 API 层就可以对这些资源进行一个筛选，每个 Kubernetes Object 都可以贴上多个 Label。例如：Service 和 Deployment 都通过 Label Selector（标签选择器）来绑定与之匹配的 Pods。

## ConfigMap ##

设计良好的应用程序应该遵循 12 因素的应用程序声明，对于应用程序的配置，应该将配置存储在 “环境” 中。尽管现在常见的安全实践指出，在环境中存储配置可能会导致机密的意外泄漏，因为一些应用程序在失败时抛出了它们的环境，但是配置应该与构建的应用程序分开存储，因为每个环境都有配置更改。（开发、临时、生产）。

ConfigMap 允许将配置文件作为环境变量或文件系统挂载到 Pod 中，从而解决了这个问题。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr_size_16_color_FFFFFF_t_70_pic_center]

## 容器设计模式 ##

### InitContainer ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr_size_16_color_FFFFFF_t_70 1]

有了 InitContainer 之后就可以这样去描述：Pod 是一个自包含的，可以把这一个 Pod 在全世界任何一个 Kubernetes 上面都顺利启用起来。不用担心有没有分布式存储、Volume 是不是持久化的。

通过组合两个不同角色的容器，并且按照这样一些像 Init Container 这样一种编排方式，统一的去打包这样一个应用，把它用 Pod 来去做的非常典型的一个例子。像这样的一个概念，在 Kubernetes 里面就是一个非常经典的容器设计模式，叫做：“Sidecar”。

### Sidecar ###

什么是 Sidecar？就是说其实在 Pod 里面，可以定义一些专门的容器，来执行主业务容器所需要的一些辅助工作，比如我们前面举的例子，其实就干了一个事儿，这个 Init Container，它就是一个 Sidecar，它只负责把镜像里的 WAR 包拷贝到共享目录里面，以便被 Tomcat 能够用起来。

其它有哪些操作呢？比如说：

*  原本需要在容器里面执行 SSH 需要干的一些事情，可以写脚本、一些前置的条件，其实都可以通过像 Init Container 或者另外像 Sidecar 的方式去解决；
 *  还有一个典型例子就是日志收集，日志收集本身是一个进程，是一个小容器，那么就可以把它打包进 Pod 里面去做这个收集工作；
 *  还有一个非常重要的东西就是 Debug 应用，实际上现在 Debug 整个应用都可以在应用 Pod 里面再次定义一个额外的小的 Container，它可以去 exec 应用 pod 的 namespace；
 *  查看其他容器的工作状态，这也是它可以做的事情。不再需要去 SSH 登陆到容器里去看，只要把监控组件装到额外的小容器里面就可以了，然后把它作为一个 Sidecar 启动起来，跟主业务容器进行协作，所以同样业务监控也都可以通过 Sidecar 方式来去做。

这种做法一个非常明显的优势就是在于其实将辅助功能从我的业务容器解耦了，所以我就能够独立发布 Sidecar 容器，并且更重要的是这个能力是可以重用的，即同样的一个监控 Sidecar 或者日志 Sidecar，可以被全公司的人共用的。这就是设计模式的一个威力。

[1ab6687c17f64cb68ccc080676d70006.png]: https://img-blog.csdnimg.cn/1ab6687c17f64cb68ccc080676d70006.png
[bf50f1d970474aa980ccd898f5e36984.png]: https://img-blog.csdnimg.cn/bf50f1d970474aa980ccd898f5e36984.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20201206191146458.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20201121220931813.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20201206191719481.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ptaWxr,size_16,color_FFFFFF,t_70