k8s之pod

Pod是Kubernetes最重要的基本概念，如图1.4所示是Pod的组成示意 图，咱们看到每一个Pod都有一个特殊的被称为“根容器”的Pause容器。 Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器， 每一个Pod还包含一个或多个紧密相关的用户业务容器。

为何Kubernetes会设计出一个全新的Pod的概念而且Pod有这样特

殊的组成结构?

缘由之一:在一组容器做为一个单元的状况下，咱们难以简单地 对“总体”进行判断及有效地行动。好比，一个容器死亡了，此时算是整 体死亡么?是N/M的死亡率么?引入业务无关而且不易死亡的Pause容 器做为Pod的根容器，以它的状态表明整个容器组的状态，就简单、巧 妙地解决了这个难题。

缘由之二:Pod里的多个业务容器共享Pause容器的IP，共享Pause容 器挂接的V olume，这样既简化了密切关联的业务容器之间的通讯问 题，也很好地解决了它们之间的文件共享问题。

Kubernetes为每一个Pod都分配了惟一的IP地址，称之为Pod IP，一个 Pod里的多个容器共享Pod IP地址。Kubernetes要求底层网络支持集群内 任意两个Pod之间的TCP/IP直接通讯，这一般采用虚拟二层网络技术来 实现，例如Flannel、Open vSwitch等，所以咱们须要牢记一点:在 Kubernetes里，一个Pod里的容器与另外主机上的Pod容器可以直接通 信。

Pod其实有两种类型:普通的Pod及静态Pod(Static Pod)。后者比 较特殊，它并没被存放在Kubernetes的etcd存储里，而是被存放在某个 具体的Node上的一个具体文件中，而且只在此Node上启动、运行。而 普通的Pod一旦被建立，就会被放入etcd中存储，随后会被Kubernetes Master调度到某个具体的Node上并进行绑定(Binding)，随后该Pod被 对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。在 默认状况下，当Pod里的某个容器中止时，Kubernetes会自动检测到这个 问题而且从新启动这个Pod(重启Pod里的全部容器)，若是Pod所在的 Node宕机，就会将这个Node上的全部Pod从新调度到其余节点上。 Pod、容器与Node的关系如图1.5所示。

Kubernetes里的全部资源对象均可以采用Y AML或者JSON格式的文 件来定义或描述，下面是咱们在以前的Hello World例子里用到的myweb 这个Pod的资源定义文件:

Kind为Pod代表这是一个Pod的定义，metadata里的name属性为Pod 的名称，在metadata里还能定义资源对象的标签，这里声明myweb拥有 一个name=myweb的标签。在Pod里所包含的容器组的定义则在spec一节 中声明，这里定义了一个名为myweb、对应镜像为kubeguide/tomcat- app:v1的容器，该容器注入了名为MYSQL_SERVICE_HOST='mysql'和 MYSQL_SERVICE_PORT='3306'的环境变量(env关键字)，而且在 8080端口(containerPort)启动容器进程。Pod的IP加上这里的容器端口 (containerPort)，组成了一个新的概念—Endpoint，它表明此Pod里的 一个服务进程的对外通讯地址。一个Pod也存在具备多个Endpoint的情 况，好比当咱们把Tomcat定义为一个Pod时，能够对外暴露管理端口与

服务端口这两个Endpoint。

咱们所熟悉的Docker V olume在Kubernetes里也有对应的概念—Pod V olume，后者有一些扩展，好比能够用分布式文件系统GlusterFS实现 后端存储功能;Pod V olume是被定义在Pod上，而后被各个容器挂载到 本身的文件系统中的。

这里顺便提一下Kubernetes的Event概念。Event是一个事件的记 录，记录了事件的最先产生时间、最后重现时间、重复次数、发起者、 类型，以及致使此事件的缘由等众多信息。Event一般会被关联到某个 具体的资源对象上，是排查故障的重要参考信息，以前咱们看到Node的 描述信息包括了Event，而Pod一样有Event记录，当咱们发现某个Pod迟 迟没法建立时，能够用kubectl describe pod xxxx来查看它的描述信息， 以定位问题的成因，好比下面这个Event记录信息代表Pod里的一个容器 被探针检测为失败一次:

每一个Pod均可以对其能使用的服务器上的计算资源设置限额，当前 能够设置限额的计算资源有CPU与Memory两种，其中CPU的资源单位 为CPU(Core)的数量，是一个绝对值而非相对值。

对于绝大多数容器来讲，一个CPU的资源配额至关大，因此在 Kubernetes里一般以千分之一的CPU配额为最小单位，用m来表示。通 常一个容器的CPU配额被定义为100~300m，即占用0.1~0.3个CPU。由

于CPU配额是一个绝对值，因此不管在拥有一个Core的机器上，仍是在 拥有48个Core的机器上，100m这个配额所表明的CPU的使用量都是同样 的。与CPU配额相似，Memory配额也是一个绝对值，它的单位是内存 字节数。

在Kubernetes里，一个计算资源进行配额限定时须要设定如下两个 参数。

◎ Requests:该资源的最小申请量，系统必须知足要求。 ◎ Limits:该资源最大容许使用的量，不能被突破，当容器试图

使用超过这个量的资源时，可能会被Kubernetes“杀掉”并重启。

一般，咱们会把Requests设置为一个较小的数值，符合容器平时的 工做负载状况下的资源需求，而把Limit设置为峰值负载状况下资源占 用的最大量。下面这段定义代表MySQL容器申请最少0.25个CPU及 64MiB内存，在运行过程当中MySQL容器所能使用的资源配额为0.5个 CPU及128MiB内存:

本节最后给出Pod及Pod周边对象的示意图做为总结，如图1.6所 示，后面部分还会涉及这张图里的对象和概念，以进一步增强理解。

文章来源于Kubernetes权威指南