[Kubernetes]深入解析Pod对象

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

我们为什么需要Pod

我们先来谈一个问题:那就是我们为什么需要Pod?在Linux容器中,Namespace做隔离,Cgroups做限制,rootfs做文件系统就可以了,那为什么需要Pod呢?
再来问一个问题,容器的本质是什么?如果看过[Linux容器]当我们谈容器的时候,我们在谈什么,你肯定会想到,容器的本质就是进程.如果看过[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出现之后,给我们带来了什么.

  深入剖析Pod

  在我们了解为什么需要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>专栏文章之后的一些见解,有偏颇之处,还望指出.
  感谢您的阅读~