Kubernetes对象之Pod

系列目录

Pod是Kubernetes调度的最小单元。一个Pod能够包含一个或多个容器，所以它能够被看做是内部容器的逻辑宿主机。Pod的设计理念是为了支持多个容器在一个Pod中共享网络和文件系统 所以处于一个Pod中的多个容器共享如下资源：

• PID命名空间：Pod中不一样的应用程序能够看到其余应用程序的进程ID。

• network命名空间：Pod中多个容器处于同一个网络命名空间，所以可以访问的IP和端口范围都是相同的。也能够经过localhost相互访问。

• IPC命名空间：Pod中的多个容器共享Inner-process Communication命名空间，所以能够经过SystemV IPC或POSIX进行进程间通讯。
  UTS命名空间：Pod中的多个容器共享同一个主机名。

• Volumes：Pod中各个容器能够共享在Pod中定义分存储卷（Volume）。

Pod，容器与Node（工做主机）之间的关系以下图所示：

1. Pod的定义

经过yaml文件或者json描述Pod和其内容器的运行环境和指望状态，例如一个最简单的运行nginx应用的pod，定义以下：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

在生产环境中，推荐使用诸如Deployment，StatefulSet，Job或者CronJob等控制器来建立Pod，而不是直接建立。

将上述pod描述文件保存为nginx-pod.yaml，使用kubectl apply命令运行pod

kubectl apply -f nginx-pod.yaml

下面简要分析一下上面的Pod定义文件：

• apiVersion： 使用哪一个版本的Kubernetes API来建立此对象
• kind：要建立的对象类型，例如Pod，Deployment等
• metadata：用于惟一区分对象的元数据，包括：name，UID和namespace
• labels：是一个个的key/value对，定义这样的label到Pod后，其余控制器对象能够经过这样的label来定位到此Pod，从而对Pod进行管理。（参见Deployment等控制器对象）

spec： 其它描述信息，包含Pod中运行的容器，容器中运行的应用等等。不一样类型的对象拥有不一样的spec定义。详情参见API文档：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/

Kubernetes在每一个Pod启动时，会自动建立一个镜像为gcr.io/google_containers/pause:version的容器，全部处于该Pod中的容器在启动时都会添加诸如--net=container:pause --ipc=contianer:pause --pid=container:pause的启动参数，所以pause容器成为Pod内共享命名空间的基础。全部容器共享pause容器的IP地址，也被称为Pod IP。

若是咱们但愿从外部访问这nginx应用，那么咱们还须要建立Service对象来暴露IP和port。

2. Pod的生命周期

Pod的生命周期是Replication Controller进行管理的。一个Pod的生命周期过程包括：

• 经过yaml或json对Pod进行描述

• apiserver（运行在Master主机）收到建立Pod的请求后，将此Pod对象的定义存储在etcd中

• scheduler（运行在Master主机）将此Pod分配到Node上运行

• Pod内全部容器运行结束后此Pod也结束

在整个过程当中，Pod一般处于如下的五种阶段之一：

• Pending：Pod定义正确，提交到Master，但其所包含的容器镜像还未彻底建立。一般，Master对Pod进行调度须要一些时间，Node进行容器镜像的下载也须要一些时间，启动容器也须要必定时间。（写数据到etcd，调度，pull镜像，启动容器）。

• Running：Pod已经被分配到某个Node上，而且全部的容器都被建立完毕，至少有一个容器正在运行中，或者有容器正在启动或重启中。

• Succeeded：Pod中全部的容器都成功运行结束，而且不会被重启。这是Pod的一种最终状态

• Failed：Pod中全部的容器都运行结束了，其中至少有一个容器是非正常结束的（exit code不是0）。这也是Pod的一种最终状态。

• Unknown：没法得到Pod的状态，一般是因为没法和Pod所在的Node进行通讯。

2.1 Restart policy

定义Pod时，能够指定restartPolicy字段，代表此Pod中的容器在何种条件下会重启。restartPolicy拥有三个候选值：

• Always：只要退出就重启

• OnFailure：失败退出时（exit code不为0）才重启

• Never：永远不重启

2.2 经过controller管理Pod

Pod自己不具有容错性，这意味着若是Pod运行的Node宕机了，那么该Pod没法恢复。所以推荐使用Deployment等控制器来建立Pod并管理。

通常来讲，Pod不会自动消失，只能手动销毁或者被预先定义好的controller销毁。但有一种特殊状况，当Pod处于Succeeded或Failed阶段，而且超过必定时间后（由master决定），会触发超时过时从而被销毁。

整体上来讲，Kubernetes中拥有三种类型的controller：

• Job。一般用于管理必定会结束的Pod。若是但愿Pod被Job controller管理，那么restartPolicy必须指定为OnFailure或Never。

• ReplicationController，ReplicaSet和Deployment。用于管理永远处于运行状态的Pod。若是但愿Pod被此类controller管理，那么restartPolicy必须指定为Always。

• DaemonSet。它可以保证你的Pod在每一台Node都运行一个副本。