[Kubernetes]深入解析Pod对象

╰+哭是因爲堅強的太久メ 2022-03-25 08:07 179阅读 0赞

k8s集群搭建是比较容易的,但是我们为什么要搭建,里面涉及到的内容,我们为什么需要?  
这篇文章就尝试来讲讲,我们为什么需要一个Pod,对Pod对象来一个深入解析.

<table> 
 <tbody> 
  <tr> 
   <td><font>我们为什么需要Pod</font></td> 
  </tr> 
 </tbody> 
</table>

我们先来谈一个问题:那就是我们为什么需要Pod?在Linux容器中,Namespace做隔离,Cgroups做限制,rootfs做文件系统就可以了,那为什么需要Pod呢?  
再来问一个问题,容器的本质是什么?如果看过[\[Linux容器\]当我们谈容器的时候,我们在谈什么][Linux],你肯定会想到,容器的本质就是进程.如果看过[\[Kubernetes\]谈谈Kubernetes的本质][Kubernetes_Kubernetes]就可以知道,Kubernetes的本质,就是操作系统.  
在一个操作系统中,我们知道会有进程和进程组的关系.或者说,因为某些需要,某些应用必须部署在同一台机器上面.

举个例子:rsyslogd由三个进程组成:一个imklog模块,一个imuxsock模块,一个rsyslogd自己的main函数主进程,这三个进程一定要运行在同一台机器上面才行,否则它们之间的通信就会出现问题.那么当我给rsyslogd这个应用容器化时,由于受限于容器的"单进程模型",所以这三个模块必须被分别制作成三个不同的容器,在这三个容器运行时,它们设置的内存都是1G.  
假设现在Kubernetes集群上有两个节点:node1上面有3G可用,node2上面有2.5G可用,那么当我执行命令"docker run main",“docker run imklog”,"docker run imuxsock"创建容器时,其中的一个或者两个进程就有可能被调度到node2节点上,这样的话,我们就达不到目标了.  
但是当有Pod时,这个问题就很容易解决了.Pod是Kubernetes中的原子调度单位,也就是说,当Kubernetes调度时,是根据Pod而不是容器来调度的.  
此时,我们将imklog,imuxsock和main三个容器,放在一个Pod中,Kubernetes在调用时,会直接部署在node1上面,node2根本就不会考虑.  
这是我们为什么需要Pod的原因之一.

为什么我们需要Pod,还有一个更重要的层面:容器设计模式.  
在了解之前,我们需要了解一下,关于Pod最重要的一个事实:它只是一个逻辑概念.也就是说,Kubernetes真正处理的,还是宿主机操作系统上的Linux容器的Namespace和Cgroups,而并不存在一个所谓的Pod的边界或者隔离环境.那么,Pod又是怎么被"创建"出来的呢?Pod,其实就是一组共享了某些资源的容器.更详细的说就是,Pod里所有的容器,共享的是同一个Network Namespace,并且可以声明共享同一个Volume.  
基于此,尝试讲解一下容器设计模式.  
假设,现在我们有应用的war包,它需要被放在tomcat的相关目录下运行起来.

*  如果,你只能用Docker来做这件事情,那么你会如何处理war包与tomcat之间的关系呢?  
    
    
     *  1,把war包直接放在tomcat镜像的相关目录下,做成一个新的镜像运行起来.但是当我的war包进行了更新时,或者需要升级tomcat镜像,那我就要重新制作一个新的镜像,一次两次三次,你确定要去做这样的步骤很多次? 
     *  2,我才不管war包,我只发布一个tomcat容器.但是这个容器的目录,就必须声明一个hostPath类型的Volume,从而能将宿主机上的war包挂载进tomcat容器当中运行起来.这样的话,你需要解决另外一个问题:我怎么让每一台宿主机都预先准备好这个存储war包的目录呢?这样的话,就只能维护一套分布式存储系统了.
 *  是不是挺烦人的?那么我们有了Pod之后,这个问题就很容易解决了.我们可以把war包和tomcat分别做成镜像,然后把它们作为一个Pod里的两个容器"合"在一起.而这个操作,正是容器设计模式里最常用的一种模式:sidecar.
    
    希望你看到这里之后,能明白一些,我们为什么需要Pod,Pod出现之后,给我们带来了什么.
    
    <table> 
     <tbody> 
      <tr> 
       <td><font>深入剖析Pod</font></td> 
      </tr> 
     </tbody> 
    </table>
    
    在我们了解为什么需要Pod之后,再来详细解释一下,Pod对象.  
    首先,Pod不是容器,它是Kubernetes项目中的最小编排单位.我们可以把Pod看成传统环境中的"机器",基于此,凡是调度,网络,存储以及安全相关的属性,基本上都是Pod级别的.因为这些属性的共同特征是:它们描述的都是"机器"这个整体.  
    既然是深入剖析Pod,那么我们就来讲讲Pod中几个重要字段的含义和用法.
 *  1,NodeSelector:是一个供用户将Pod与Node进行绑定的字段
 *  用法如下:
    
        apiVersion: v1
        kind: Pod
        ...
        spec:
         nodeSelector:
           disktype: ssd
    
    这样的配置,意味着这个Pod永远只能运行在携带了"disktype:ssd"标签(Label)的节点上,否则,它将调度失败.
 *  2,NodeName:一旦Pod的这个字段被赋值,Kubernetes就会认为这个Pod已经经过了调度,调度的结果就是赋值的节点名字.因此这个字段一般由调度器负责设置.但当我们在测试或者调试时,需要跳过这一步时,我们可以通过设置这个字段来"骗过"调度器
 *  3,HostAliases:定义了Pod的hosts文件里的内容.
 *  咱们来一个实例:
    
        apiVersion: v1
        kind: Pod
        ...
        spec:
          hostAliases:
          - ip: "10.1.2.3"
            hostnames:
            - "foo.remote"
            - "bar.remote"
        ...
    
    在这个Pod的YAML文件中,可以看到,设置了一组IP和hostname的数据.当这个Pod启动后,我们可以查看到hosts文件的内容:
    
        cat /etc/hosts
        # Kubernetes-managed hosts file.
        127.0.0.1 localhost
        ...
        10.244.135.10 hostaliases-pod
        10.1.2.3 foo.remote
        10.1.2.3 bar.remote
    
    可以看到,最下面的两行记录,就是通过HostAliases字段设置的.  
    需要注意一下的就是,在Kubernetes中,如果要设置hosts文件里的内容,一定要通过这种方法,否则如果直接修改了hosts文件的话,在Pod被删除重建之后,Kubernetes会自动覆盖掉被修改的内容.
    
    关于Pod对象的相关内容到这里就介绍的差不多了.  
    经过以上的介绍,对于Pod这个看似复杂的API对象,实际上就是对容器的进一步抽象和封装而已.  
    说的更形象些,“容器"镜像虽然好用,但是容器这样一个"沙盒"的概念,对于描述应用来说,还是太过简单了.这就好比,集装箱固然好用,但是如果它四面都光秃秃的,吊车也没办法把这个集装箱吊起来.  
    但是有了Pod对象之后,就相当于对容器进行了组合,添加了更多的属性和字段.这就好比给集装箱四周安装了吊环,这样就使得Kubernetes这架"吊车”,可以更轻松地操作.  
    希望举的这个例子,能够让你更好的去理解Pod对象.
    
    以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.  
    感谢您的阅读~

[Linux]: https://blog.csdn.net/zll_0405/article/details/85881930
[Kubernetes_Kubernetes]: https://blog.csdn.net/zll_0405/article/details/86484277