【Kubernetes】——pod资源深度解析

以你之姓@ 2023-02-25 10:26 227阅读 0赞

### 一、前言 ###

接触k8s也有小一年了。跟着需求走很容易囫囵吞枣式的学习k8s, 知其然而不知其所以然。周末正好有时间，再回过头来看看k8s的实现方式。刚看了前几张官方文档，就产生了一个疑问：**k8s为何要引入pod作为其控制的最小单元，直接用容器不好吗？**带着这个疑问，好好翻阅了一下资料，特此记录一下。

### 二、pod是什么？ ###

Pod是 Kubernetes 项目中最小的 API 对象，而Pod也是由容器组组成的。Pod 里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume。这个解释太官方了。你可以把pod想象成一个“豆荚” ，然后里面包着一组有关联关系的“豆子”（容器）。一个豆荚里的豆子，它们共同吸收着同一个养分，Pod也是如此，里面的容器共有着同一组资源。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70][]

上面这个图很形象的表达了pod和容器的关系。转换成咱们计算机的知识，其实，你把Pod想成虚拟机，然后容器想成虚拟机里面的应用你就明白很多了。我们还是拿K8S跟OpenStack对比就明白了：

<table> 
 <thead> 
  <tr> 
   <th> <p>K8S</p> </th> 
   <th> <p>OpenStack</p> </th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td> <p>Pod</p> </td> 
   <td> <p>VM</p> </td> 
  </tr> 
  <tr> 
   <td> <p>Docker</p> </td> 
   <td> <p>application 应用、进程</p> </td> 
  </tr> 
 </tbody> 
</table>

OpenStack管理的VM可以说是OpenStack里的最小单元，虚拟机我们知道有隔离性，里面部署的应用只跑在虚拟机里面，他们共享这个VM的CPU、Mem、网络、存储资源。那么，同理Pod也是如此，Pod里面的容器共享着Pod里面的CPU、Mem、网络和存储资源。

三、pod的内部实现机制

因为Linux提供了Namespace和Cgroup两种机制才让容器的出现提供了可能。Namespace用于进程之间的隔离，Cgroup用于控制进程资源的使用；Namespace由hostname、PID、filesystem、network、IPC组成。在K8S里，Pod的生成也是基于Namespace和Cgroup的，所以Pod内的架构合成，我们可以用下面这张图画出来：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 1][]

那这些要素是通过什么机制组合在一起呢？这里是通过一个叫Pause（gcr.io/google\_containers/pause-amd64）的容器完成的。K8S在初始化一个Pod的时候会先启动一个叫Pause的容器，然后再启动用户自定义的业务容器。这个Pause容器我们认为它是一个“根容器”，它主要有两方面作用：

*  扮演PID 1的角色，处理僵尸进程
 *  在Pod里为其他容器共享Linux namespace的基础

首先我们了解下Linux系统下PID为 1 的进程它的作用和意义。在Linux里，PID 为 1的进程，叫超级进程，也叫根进程，它是系统的第一个进程，是其他进程的父进程，所有的进程都会被挂在这个进程下。如果一个子进程的父进程退了，那么这个子进程会被挂到 PID 1 下面。

其次，我们知道容器本身就是一个进程。在一个Namespace下，Pause作为PID为1的进程存在于一个Pod里，其他的业务容器都挂载这个Pause进程下面。这样，一个Namespace下的进程就会以Pause作为根，呈树状的结构存在一个Pod下。

最后，Pause还有个功能是负责处理僵尸进程。僵尸进程：一个进程使用fork函数创建子进程，如果子进程退出，而父进程并没有来得及调用wait或waitpid获取其子进程的状态信息，那么这个子进程的描述符仍然保存在系统中，其进程号会一直存在被占用（而系统的进程号是有限的），这种进程称之为僵尸进程（Z开头）。

Pause这个容器代码是用C写的（代码见下），其中Pause的代码里，有个无限循环的for(;;)函数，函数里面执行的是pause( )函数，pause() 函数本身是在睡眠状态的， 直到被信号(signal)所中断。因此，正是因为这个机制，Pause容器会一直等待SIGCHLD信号，一旦有了SIGCHLD信号（进程终止或者停止时会发出这种信号），Pause就会启动sigreap方法，sigreap方法里就会调用waitpid**获取其子进程的状态信息**，这样自然就不会在Pod里产生僵尸进程了。

## Pause代码
    static void sigdown(int signo) {
      psignal(signo, "Shutting down, got signal");
      exit(0);
    }
    
    static void sigreap(int signo) {
      while (waitpid(-1, NULL, WNOHANG) > 0);
    }
    
    int main() {
      if (getpid() != 1)
        /* Not an error because pause sees use outside of infra containers. */
        fprintf(stderr, "Warning: pause should be the first process\n");
    
      if (sigaction(SIGINT, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
        return 1;
      if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
        return 2;
      if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap,
                                                 .sa_flags = SA_NOCLDSTOP},
                    NULL) < 0)
        return 3;
    
    ## 关注这下面的for循环代码
      for (;;)
        pause();
      fprintf(stderr, "Error: infinite loop terminated\n");
      return 42;
    }

### 四、pod的网络通信 ###

在 Kubernetes 项目里，Pod 的实现需要使用一个中间容器，这个容器叫作 Infra 容器。在这个 Pod 中，Infra 容器永远都是第一个被创建的容器，而其他用户定义的容器，则通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。这样的组织关系，可以用下面这样一个示意图来表达：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 2][]

如上图所示，这个 Pod 里有两个用户容器 A 和 B，还有一个 Infra 容器。很容易理解，在 Kubernetes 项目里，Infra 容器一定要占用极少的资源，所以它使用的是一个非常特殊的镜像，叫作：k8s.gcr.io/pause。这个镜像是一个用汇编语言编写的、永远处于“暂停”状态的容器，解压后的大小也只有 100~200 KB 左右。而在 Infra 容器“Hold 住”Network Namespace 后，用户容器就可以加入到 Infra 容器的 Network Namespace 当中了

*  这也就意味着，对于 Pod 里的容器 A 和容器 B 来说：
 *  它们可以直接使用 localhost 进行通信；
 *  它们看到的网络设备跟 Infra 容器看到的完全一样；
 *  一个 Pod 只有一个 IP 地址，也就是这个 Pod 的 Network Namespace 对应的 IP 地址；
 *  当然，其他的所有网络资源，都是一个 Pod 一份，并且被该 Pod 中的所有容器共享；
 *  Pod 的生命周期只跟 Infra 容器一致，而与容器 A 和 B 无关。

而对于同一个 Pod 里面的所有用户容器来说，它们的进出流量，也可以认为都是通过 Infra 容器完成的。这一点很重要，因为将来如果你要为 Kubernetes 开发一个网络插件时，应该重点考虑的是如何配置这个 Pod 的 Network Namespace，而不是每一个用户容器如何使用你的网络配置，这是没有意义的。

这就意味着，如果你的网络插件需要在容器里安装某些包或者配置才能完成的话，是不可取的：Infra 容器镜像的 rootfs 里几乎什么都没有，没有你随意发挥的空间。当然，这同时也意味着你的网络插件完全不必关心用户容器的启动与否，而只需要关注如何配置 Pod，也就是 Infra 容器的 Network Namespace 即可。

### 五、Pod容器共享Volume ###

Volume类型包括：emtyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、gitRepo、secret、nfs、scsi、glusterfs、persistentVolumeClaim、rbd、flexVolume、cinder、cephfs、flocker、downwardAPI、fc、azureFile、configMap、vsphereVolume等等，可以定义多个Volume，每个Volume的name保持唯一。在同一个pod中的多个容器能够共享pod级别的存储卷Volume。Volume可以定义为各种类型，多个容器各自进行挂载操作，讲一个Volume挂载为容器内需要的目录。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 3][]

### 六、 sidecar容器与Init Container容器 ###

*  sidecar： 伴生容器，指的就是我们可以在一个 Pod 中，启动一个辅助容器，来完成一些独立于主进程（主容器）之外的工作。
 *  Init Container：初始化容器 就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会被启动。我们知道一个Pod里面的所有容器是共享数据卷和网络命名空间的，所以Init Container里面产生的数据可以被主容器使用到的。

例如：我们现在有一个 Java Web 应用的 WAR 包，它需要被放在 Tomcat 的 webapps 目录下运行起来。假如，你现在只能用 Docker 来做这件事情，那该如何处理这个组合关系呢？

*  一种方法是，把 WAR 包直接放在 Tomcat 镜像的 webapps 目录下，做成一个新的镜像运行起来。可是，这时候，如果你要更新 WAR 包的内容，或者要升级 Tomcat 镜像，就要重新制作一个新的发布镜像，非常麻烦。
 *  另一种方法是，你压根儿不管 WAR 包，永远只发布一个 Tomcat 容器。不过，这个容器的 webapps 目录，就必须声明一个 hostPath 类型的 Volume，从而把宿主机上的 WAR 包挂载进 Tomcat 容器当中运行起来。不过，这样你就必须要解决一个问题，即：如何让每一台宿主机，都预先准备好这个存储有 WAR 包的目录呢？这样来看，你只能独立维护一套分布式存储系统了。

实际上，有了 Pod 之后，这样的问题就很容易解决了。我们可以把 WAR 包和 Tomcat 分别做成镜像，然后把它们作为一个 Pod 里的两个容器“组合”在一起。这个 Pod 的配置文件如下所示：

apiVersion: v1
    kind: Pod
    metadata:
      name: javaweb-2
    spec:
      initContainers:
      - image: geektime/sample:v2
        name: war
        command: ["cp", "/sample.war", "/app"]
        volumeMounts:
        - mountPath: /app
          name: app-volume
      containers:
      - image: geektime/tomcat:7.0
        name: tomcat
        command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
        volumeMounts:
        - mountPath: /root/apache-tomcat-7.0.42-v2/webapps
          name: app-volume
        ports:
        - containerPort: 8080
          hostPort: 8001 
      volumes:
      - name: app-volume
        emptyDir: {}

在这个 Pod 中，我们定义了两个容器，第一个容器使用的镜像是geektime/sample:v2，这个镜像里只有一个 WAR 包（sample.war）放在根目录下。而第二个容器则使用的是一个标准的 Tomcat 镜像。不过，你可能已经注意到，WAR 包容器的类型不再是一个普通容器，而是一个 Init Container 类型的容器。在 Pod 中，所有 Init Container 定义的容器，都会比 spec.containers 定义的用户容器先启动。并且，Init Container 容器会按顺序逐一启动，而直到它们都启动并且退出了，用户容器才会启动。所以，这个 Init Container 类型的 WAR 包容器启动后，我执行了一句"cp /sample.war /app"，把应用的 WAR 包拷贝到 /app 目录下，然后退出。而后这个 /app 目录，就挂载了一个名叫 app-volume 的 Volume。接下来就很关键了。Tomcat 容器，同样声明了挂载 app-volume 到自己的 webapps 目录下。所以，等 Tomcat 容器启动时，它的 webapps 目录下就一定会存在 sample.war 文件：这个文件正是 WAR 包容器启动时拷贝到这个 Volume 里面的，而这个 Volume 是被这两个容器共享的。像这样，我们就用一种“组合”方式，解决了 WAR 包与 Tomcat 容器之间耦合关系的问题。实际上，这个所谓的“组合”操作，正是容器设计模式里最常用的一种模式，它的名字叫：sidecar。

在我们的这个应用 Pod 中，Tomcat 容器是我们要使用的主容器，而 WAR 包容器的存在，只是为了给它提供一个 WAR 包而已。所以，我们用 Init Container初始化容器的方式优先运行 WAR 包容器，扮演了一个 sidecar 的角色。

### **七、Pod资源使用机制** ###

我们前面提到过Pod好比一个虚拟机，虚拟机我们是能分配固定的CPU、Mem、Disk、网络资源的。同理，Pod也是如此，那么Pod如何使用和控制这些分配的资源呢？首先，我们先了解下CPU资源的分配模式：

计算机里CPU的资源是按“时间片”的方式分配给请求的，系统里的每一个操作都需要CPU的处理，我们知道CPU的单位是Hz、GHz（1Hz = 1/s，即在单位时间内完成振动的次数，1GHz = 1 000 000 000 Hz = 1 000 000 000 次/s），频率越大，单位时间内完成的处理次数就越多。所以，哪个任务要是申请的CPU时间片越多，那么它得到的CPU资源就越多。

其次，我们再了解一些Cgroup里资源的换算单位：

CPU换算单位

1 CPU = 1000 millicpu（1 Core = 1000m）

0.5 CPU = 500 millicpu （0.5 Core = 500m）

这里的 m 就是毫、毫核的意思，K8S集群中的每一个节点可以通过操作系统的命令来确认本节点的CPU内核数量，然后将这个数量乘以1000，得到的就是节点总CPU总毫数。比如一个节点有四核，那么该节点的CPU总毫量为4000m。如果你要使用0.5 core，则你要求的是 4000\*0.5 = 2000m。

K8S里是通过以下两个参数来限制和请求CPU的资源的：

*  spec.containers\[\].resources.limits.cpu CPU上限值，可以短暂超过，容器也不会被停止。
 *  spec.containers\[\].resources.requests.cpu CPU请求值，K8S调度算法里的依据值，可以超过。

这里需要明白的是，如果resources.requests.cpu设置的值大于集群里每个Node的最大CPU核心数，那么这个Pod将无法调度（很容易理解，没有Node能满足它）。

例子，我们在YAML里定义一个容器CPU资源如下：

resources:
      requests:
        memory: 50Mi
        cpu: 50m
      limits:
        memory: 100Mi
        cpu: 100m

这里，CPU我们给的是50m，也就是0.05core，这0.05 core也就是占了1 CPU里的5%的资源时间。另外，我们还要知道K8S CPU资源这块，它是一个可压缩性的资源。**如果容器达到了CPU设定值会开始限制，容器性能会下降，但是不会终止和退出。**

最后我们了解下MEM这块的资源控制：

单位换算：1 MiB = 1024 KiB ， 这里注意的是MiB ≠ MB，MB是十进制单位，MiB 是二进制，平时我们以为MB等于1024KB，其实1MB=1000KB，1MiB才等于1024KiB。中间带字母 i 的是国际电工协会（IEC）定的，走1024乘积；KB、MB、GB是国际单位制，走1000乘积。

内存这块在K8S里一般用的是Mi单位，当然你也可以使用Ki、Gi甚至Pi，看具体的业务需求和资源容量。这里要注意的是，**内存这里不是可压缩性资源，如果容器使用内存资源到达了上限，那么会OOM，造成内存溢出，容器就会终止和退出。**

### 八、pod的生命周期管理 ###

Pod在整个生命周期过程中被定义为各种状态，熟悉Pod的各种状态有助于理解如何设置Pod的调度策略、重启策略Pod的状态包含以下几种，如图：

![20200712180615710.png][]

Pod的重启策略（RestartPolicy）应用于Pod内所有的容器，并且仅在Pod所处的Node上由kubelet进行判断和重启操作。当某哥容器异常退出或者健康检查石柏师，kubelet将根据RestartPolicy的设置进行相应的操作。Pod的重启策略包括Always、OnFailure及Nerver，默认值为Always。kubelet重启失效容器的时间间隔以sync-frequency乘以2n来计算，例如1、2、4、8倍等，最长延时5分钟，并且成功重启后的10分钟后重置该事件。

Pod的重启策略和控制方式息息相关，当前可用于管理Pod的控制器宝库ReplicationController、Job、DaemonSet及直接通过kubelet管理（静态Pod），每种控制器对Pod的重启策略要求如下：

*  RC和DaemonSet：必须设置为Always，需要保证该容器持续运行
 *  Job：OnFailure或Nerver，确保容器执行完成后不再重启
 *  kubelet：在Pod失效时重启他，不论RestartPolicy设置什么值，并且也不会对Pod进行健康检查。

###  九、pod的健康检查 ###

对Pod的健康检查可以通过两类探针来检查：**LivenessProbe**和**ReadinessProbe**

1.  LivenessProbe探针：用于判断容器是否存活（running状态），如果LivenessProbe探针探测到容器不健康，则kubelet杀掉该容器，并根据容器的重启策略做响应处理
2.  ReadinessProbe探针：用于判断容器是否启动完成（ready状态），可以接受请求。如果ReadinessProbe探针探测失败，则Pod的状态被修改。Endpoint Controller将从service的Endpoint中删除包含该容器所在的Pod的Endpoint。

kubelet定制执行LivenessProbe探针来诊断容器的健康状况。LivenessProbe有三种事项方式。

1）ExecAction：在容器内部执行一个命令，如果该命令的返回值为0，则表示容器健康。例：

apiVersion:v1
    kind: Pod
    metadata:
      name: liveness-exec
      label:
        name: liveness
    spec:
      containers:
      - name: tomcat
        image: grc.io/google_containers/tomcat
        args:
        -/bin/sh
        - -c
        -echo ok >/tmp.health;sleep10; rm -fr /tmp/health;sleep600
        livenessProbe:
          exec:
            command:
            -cat
            -/tmp/health
          initianDelaySeconds:15
          timeoutSeconds:1

**（2）TCPSocketAction：通过容器ip地址和端口号执行TCP检查，如果能够建立tcp连接表明容器健康。**例：

kind: Pod
    metadata:
      name: pod-with-healthcheck
    spec:
      containers:
      - name: nginx
        image: nginx
        livenessProbe:
          tcpSocket:
            port: 80
          initianDelaySeconds:30
          timeoutSeconds:1

**3）HTTPGetAction：通过容器Ip地址、端口号及路径调用http get方法，如果响应的状态吗大于200且小于400，则认为容器健康**。例：

apiVersion:v1
    kind: Pod
    metadata:
      name: pod-with-healthcheck
    spec:
      containers:
      - name: nginx
        image: nginx
        livenessProbe:
          httpGet:
            path:/_status/healthz
            port: 80
          initianDelaySeconds:30
          timeoutSeconds:1

对于每种探针方式，都需要设置initialDelaySeconds和timeoutSeconds两个参数，它们含义如下：

*  initialDelaySeconds：启动容器后首次监控检查的等待时间，单位秒
 *  timeouSeconds：健康检查发送请求后等待响应的超时时间，单位秒。当发生超时就被认为容器无法提供服务无，该容器将被重启。

【参考文章】

1、参考文章1：[https://cloud.tencent.com/developer/article/1443520][https_cloud.tencent.com_developer_article_1443520]

2.参考文章2：[https://www.jianshu.com/p/d1e1de86d6d6][https_www.jianshu.com_p_d1e1de86d6d6]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70]: /images/20230209/ae1d31720b76456f91e8cc39ea5481f0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 1]: /images/20230209/a51a5d56cf804d20b3601b2dc067d47e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 2]: /images/20230209/c9c10e1f66374771bd2e8ca04b304ca7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MDQ0OTMwMA_size_16_color_FFFFFF_t_70 3]: /images/20230209/f53a845ffd3544feab69a22c91ac416c.png
[20200712180615710.png]: /images/20230209/f0c417b46daa4edab2599bd5d46bfc9e.png
[https_cloud.tencent.com_developer_article_1443520]: https://cloud.tencent.com/developer/article/1443520
[https_www.jianshu.com_p_d1e1de86d6d6]: https://www.jianshu.com/p/d1e1de86d6d6