1 Pod 特点
Pod是kubernetes中你可以创建和部署的最小也是最简的单位，一个Pod代表着集群中运行的一个进程。
Pod中封装着应用的容器（有的情况下是好几个容器），存储、独立的网络IP，管理容器如何运行的策略选项，Pod代表着部署的一个单位：kubernetes中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。
Pod有两个必须知道的特点
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 创建资源清单
通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下
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 参数描述
下面简要分析一下上面的Pod定义文件：
- 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创建pod
kubectl apply -f nginx-pod.yml
3.3 Pod操作
3.3.1 查看Pod列表
kubectl get pods
可以通过增加
-o wide查看详细信息
kubectl get pods -o wide
3.3.2 查看描述信息
可以通过
describe查看pod的详细信息
kubectl describe pod nginx
3.3.3 访问pod
可以通过
k8s创建的虚拟IP进行访问，可以在k8s的任何一个节点访问
curl 10.244.1.10
3.3.4 删除Pod
可以使用
delete删除Pod，删除后不能进行恢复
kubectl delete pod nginx
4 控制器运行Pod
Pod本身不具备容错性，这意味着如果Pod运行的Node宕机了，那么该Pod无法恢复，因此推荐使用Deployment等控制器来创建Pod并管理。
4.1 创建资源清单
通过yaml文件或者json描述Pod和其内容器的运行环境和期望状态，例如一个最简单的运行nginx应用的pod，定义如下
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 参数描述
下面简要分析一下上面的Pod定义文件：
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
Pod模板，.spec.template 是 .spec中唯一要求的字段。
.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
创建后发现，有两个nginx的pod在运行，符合我们的预期
4.4 Pod操作
4.4.1 删除Pod
这里可以尝试删除Pod
kubectl delete pod nginx-deployment-f77774fc5-cgs82
# 查看Pod详情
kubectl get pods -o wide
删除Pod后发现重新新建了一个Pod，这是因为有控制器发现少了一个Pod就会进行重新拉起来一个
5 镜像拉取策略
pod的镜像拉取策略分为三种：
- 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
Kubernetes集群的默认策略，如果有本地镜像就使用，没有则从远程仓库下载
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 各个阶段
POD中明确规定了如下几个阶段
| 状态值 | 说明 |
|---|---|
挂起（Pending） |
Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建，等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。 |
运行中（Running） |
该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。 |
成功（Succeeded） |
Pod 中的所有容器都被成功终止，并且不会再重启。 |
失败（Failed） |
Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。 |
未知（Unknown） |
因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。 |
实际上还有一中状态Terminating，在代码和文档中都没有说明，但却是存在。这种情况出现杂无法获取所在主机的资源情况，一直在尝试建立连接。
6.2 Pod重启策略
在Pod中的容器可能会由于异常等原因导致其终止退出，Kubernetes提供了重启策略以重启容器。
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 初始化容器
初始化容器（
init container）即应用程序的主容器启动之前要运行的容器，常用于为主容器执行一些预置操作，它们具有两种典型特征。
- 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么
kubernetes需要重启它直到成功完成。（注意：如果pod的spec.restartPolicy字段值为“Never”，那么运行失败的初始化容器不会被重启。） - 每个初始化容器都必须按定义的顺序串行运行。
6.4.2 容器探测
容器探测（
container probe）是Pod对象生命周期中的一项重要的日常任务，它是kubelet对容器周期性执行的健康状态诊断，诊断操作由容器的处理器（handler）进行定义，Kubernetes支持三种处理器用于Pod探测：文章来源：https://www.toymoban.com/news/detail-718574.html
-
ExecAction：在容器内执行指定命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表示成功，否则即为不健康状态。 -
TCPSocketAction：通过与容器的某TCP端口尝试建立连接进行诊断，端口能够成功打开即为正常，否则为不健康状态。 -
HTTPGetAction：通过向容器IP地址的某指定端口的指定path发起HTTP GET请求进行诊断，响应码为2xx或3xx时即为成功，否则为失败。
任何一种探测方式都可能存在三种结果：
“Success”（成功）、“Failure”（失败）、“Unknown”（未知），只有success表示成功通过检测。文章来源地址https://www.toymoban.com/news/detail-718574.html
到了这里，关于Kubernetes(k8s)容器编排Pod介绍和使用的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
