目录
1 Pod 特点
Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项，Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。
1.1 网络
每一个Pod都会被指派一个唯一的Ip地址，在Pod中的每一个容器共享网络命名空间，包括Ip地址和网络端口，在同一个Pod中的容器可以同locahost进行互相通信，当Pod中的容器需要与Pod外的实体进行通信时，则需要通过端口等共享的网络资源。
1.2 存储
Pod能够配置共享存储卷，在Pod中所有的容器能够访问共享存储卷，允许这些容器共享数据，存储卷也允许在一个Pod持久化数据，以防止其中的容器需要被重启。
2 使用方式
2.1 自主式Pod
这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上，直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上，Pod不会自愈。
如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除，同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。
2.2 控制器管理的Pod
Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。
例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的
3 自主运行Pod
3.1 创建资源清单
vi nginx-pod.yml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.12
ports:
- containerPort: 80
3.1.1 参数描述
- apiVersion： 使用哪个版本的Kubernetes API来创建此对象
- kind：要创建的对象类型，例如Pod，Deployment等
- metadata：用于唯一区分对象的元数据，包括：name，UID和namespace
- labels：是一个个的key/value对，定义这样的label到Pod后，其他控制器对象可以通过这样的label来定位到此Pod，从而对Pod进行管理。（参见Deployment等控制器对象）
- spec： 其它描述信息，包含Pod中运行的容器，容器中运行的应用等等。不同类型的对象拥有不同的spec定义。详情参见API文档
3.2 创建Pod
kubectl apply -f nginx-pod.yml
3.3 Pod操作
3.3.1 查看Pod列表
kubectl get pods
kubectl get pods -o wide
3.3.2 查看描述信息
kubectl describe pod nginx
3.3.3 访问pod
curl 10.244.1.10
3.3.4 删除Pod
kubectl delete pod nginx
4 控制器运行Pod
4.1 创建资源清单
vi nginx-pod.yml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.12
ports:
- containerPort: 80
4.2 参数描述
4.2.1 Replicas
spec.replicas 是可以选字段，指定期望的pod数量，默认是1。
4.2.2 Selector
.spec.selector是可选字段，用来指定 label selector ，圈定Deployment管理的pod范围。如果被指定， .spec.selector 必须匹配 .spec.template.metadata.labels，否则它将被API拒绝。如果 .spec.selector 没有被指定， .spec.selector.matchLabels 默认是.spec.template.metadata.labels。
在Pod的template跟.spec.template不同或者数量超过了.spec.replicas规定的数量的情况下，Deployment会杀掉label跟selector不同的Pod。
4.2.3 Pod Template
.spec.template 是 pod template，它跟 Pod有一模一样的schema，除了它是嵌套的并且不需要apiVersion 和 kind字段。
另外为了划分Pod的范围，Deployment中的pod template必须指定适当的label（不要跟其他controller重复了，参考selector）和适当的重启策略。
.spec.template.spec.restartPolicy 可以设置为 Always , 如果不指定的话这就是默认配置。
4.3 创建Pod
kubectl apply -f nginx-pod.yml
kubectl get pods -o wide
4.4 Pod操作
4.4.1 删除Pod
kubectl delete pod nginx-deployment-f77774fc5-cgs82
# 查看Pod详情
kubectl get pods -o wide
5 镜像拉取策略
- always（总是从官方下载镜像）
- never（从不下载镜像）
- ifnotpresent（如果本地没有镜像就从官方下载镜像）。
Kubernetes集群默认使用IfNotPresent策略
5.1 always
5.1.1 修改资源清单
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.12
imagePullPolicy: Always
ports:
- containerPort: 80
5.1.2 生效配置
kubectl apply -f nginx-pod.yml
5.1.3 查看创建过程
kubectl describe pod nginx-deployment
5.2 IfNotPresent
5.2.1 修改资源清单
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.12
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
5.2.2 生效配置
kubectl apply -f nginx-pod.yml
5.2.3 查看创建过程
kubectl describe pod nginx-deployment
6 Pod生命周期
6.1 各个阶段
| 状态值 | 说明 |
|---|---|
挂起（Pending） | Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建，等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。 |
运行中（Running） | 该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。 |
成功（Succeeded） | Pod 中的所有容器都被成功终止，并且不会再重启。 |
失败（Failed） | Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。 |
未知（Unknown） | 因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。 |
实际上还有一中状态Terminating，在代码和文档中都没有说明，但却是存在。这种情况出现杂无法获取所在主机的资源情况，一直在尝试建立连接。
6.2 Pod重启策略
Pod通过`restartPolicy`字段指定重启策略，重启策略类型为：Always、OnFailure 和 Never，默认为 Always。
重启策略对同一个Pod的所有容器起作用，容器的重启由Node上的kubelet执行。Pod支持三种重启策略，在配置文件中通过`restartPolicy`字段设置重启策略：
| 重启策略 | 说明 |
|---|---|
| Always | 当容器失效时，由kubelet自动重启该容器 |
| OnFailure | 当容器终止运行且退出码不为0时，由kubelet自动重启该容器 |
| Never | 不论容器运行状态如何，kubelet都不会重启该容器 |
注意：这里的重启是指在Pod的宿主Node上进行本地重启，而不是调度到其它Node上。
6.3 Pod状态转换
| Pod的容器数 | Pod当前状态 | 发生的事件 | Pod结果状态 | ||
|---|---|---|---|---|---|
| RestartPolicy=Always | RestartPolicy=OnFailure | RestartPolicy=Never | |||
| 包含一个容器 | Running | 容器成功退出 | Running | Succeeded | Succeeded |
| 包含一个容器 | Running | 容器失败退出 | Running | Running | Failure |
| 包含两个容器 | Running | 1个容器失败退出 | Running | Running | Running |
| 包含两个容器 | Running | 容器被OOM杀掉 | Running | Running | Failure |
6.4 生命周期行为
6.4.1 初始化容器
- 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么
kubernetes需要重启它直到成功完成。（注意：如果pod的spec.restartPolicy字段值为“Never”，那么运行失败的初始化容器不会被重启。） - 每个初始化容器都必须按定义的顺序串行运行。
6.4.2 容器探测
ExecAction：在容器内执行指定命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态。TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，否则为失败。
