目录
一、概述
二、Pod机制
2.1、共享网络
2.2、共享存储
三、Pod资源清单
四、 Pod 的分类
五、Pod阶段
六、Pod 镜像拉取策略
ImagePullBackOff
七、Pod 资源限制
八、容器重启策略
一、概述
Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。Pod 里面是由一个或多个容器组成【一组容器的集合】，这些容器共享存储、网络、以及怎样运行这些容器的声明。
Pod 是 Kubernetes 的最重要概念，每一个 Pod 都有一个特殊的被称为”根容器“的Pause容器。Pause 容器对应的镜像属于 Kubernetes 平台的一部分，除了Pause 容器，每个Pod还包含一个或多个紧密相关的用户业务容器。
Pod有以下一些特性：
- 资源共享
一个 Pod 里的多个容器可以共享存储和网络，可以看作一个逻辑的主机。共享namespace,cgroups 或者其他的隔离资源。
一个 Pod 里的多个容器可以共享存储卷，这个存储卷会被定义为 Pod 的一部分，并且可以挂载到该 Pod 里的所有容器的文件系统上 。
- 生命周期短暂
Pod 属于生命周期比较短暂的组件，比如，当 Pod 所在节点发生故障，那么该节点上的Pod会被调度到其他节点，但需要注意的是，被重新调度的 Pod 是一个全新的Pod，跟之前的Pod 没有任何关系。
- 平坦的网络
k8s 集群中的所有 Pod 都在同一个共享网络地址空间中，也就是说每个Pod 都可以通过其他 Pod 的 IP 地址来实现访问。
二、Pod机制
Pod 主要有以下两大机制：共享网络 和 共享存储。
2.1、共享网络
容器通过 namespace 和 group 进行隔离。通过Pause容器，把其它业务容器加入到Pause容器中，让所有业务容器在同一个名称空间中，可以实现网络共享。在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 localhost 发现对方。
2.2、共享存储
一个 Pod 可以设置一组共享的存储卷。 Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。 卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。
三、Pod资源清单
下面给出yaml文件定义的nginx Pod 的示例内容：
$ kubectl create deployment nginx --image=nginx
deployment.apps/nginx created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-748c667d99-mp4d6 0/1 ContainerCreating 0 5s
// 查看pod的yaml资源清单
$ kubectl get pods nginx-748c667d99-mp4d6 -o yaml
apiVersion: v1 //版本号
kind: Pod //资源类型，这里是Pod
metadata: //元数据
annotations: //pod注解信息
cni.projectcalico.org/containerID: 8190e79f9ce4ebc75058013e14bd247a8a92210b28b613f9f80bcc761975117b
cni.projectcalico.org/podIP: 192.168.1.3/32
cni.projectcalico.org/podIPs: 192.168.1.3/32
creationTimestamp: "2022-12-29T06:27:33Z"
generateName: nginx-748c667d99- //名称前缀
labels: //pod标签列表
app: nginx
pod-template-hash: 748c667d99
name: nginx-748c667d99-mp4d6 //pod名称
namespace: default //pod所在的命名空间，默认为default
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: ReplicaSet
name: nginx-748c667d99
uid: f09e2cff-2983-4af9-98e3-71e0d470eaa2
resourceVersion: "2873"
uid: 28f22749-7343-428e-a20a-d7973e4c5a94
spec: // 资源特征
containers: //pod 中的容器列表，可以有多个容器
- image: nginx //镜像地址，默认从docker hub拉取nginx镜像
imagePullPolicy: Always //获取镜像的策略，默认值为Always，每次都尝试重新下载镜像. 有三种取值：[Always|Never|IfNotPresent]
name: nginx //容器的名称
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts: //挂载到到容器内部的存储卷设置
- mountPath: /var/run/secrets/kubernetes.io/serviceaccount //存储卷在容器内部 Mount的绝对路径
name: kube-api-access-78n9q //引用的是kube-api-access-78n9这个容器卷，在下边有定义这个volume
readOnly: true //只读,默认值为读写
dnsPolicy: ClusterFirst
enableServiceLinks: true
nodeName: node01 //pod所在的节点名称,由调度器scheduler进行调度
preemptionPolicy: PreemptLowerPriority
priority: 0
restartPolicy: Always //重启策略
schedulerName: default-scheduler //使用默认的调度器，通常情况下使用默认的即可
securityContext: {}
serviceAccount: default
serviceAccountName: default
terminationGracePeriodSeconds: 30
tolerations: //污点容忍
- effect: NoExecute
key: node.kubernetes.io/not-ready
operator: Exists
tolerationSeconds: 300
- effect: NoExecute
key: node.kubernetes.io/unreachable
operator: Exists
tolerationSeconds: 300
volumes: //定义volume容器卷列表
- name: kube-api-access-78n9q
projected:
defaultMode: 420
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
- configMap:
items:
- key: ca.crt
path: ca.crt
name: kube-root-ca.crt
- downwardAPI:
items:
- fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
path: namespace
status:
conditions: //pod的状况
- lastProbeTime: null
lastTransitionTime: "2022-12-29T06:27:35Z"
status: "True"
type: Initialized
- lastProbeTime: null
lastTransitionTime: "2022-12-29T06:27:51Z"
status: "True"
type: Ready
- lastProbeTime: null
lastTransitionTime: "2022-12-29T06:27:51Z"
status: "True"
type: ContainersReady
- lastProbeTime: null
lastTransitionTime: "2022-12-29T06:27:35Z"
status: "True"
type: PodScheduled
containerStatuses:
- containerID: containerd://1c7e903816a0de4192f3ffe4b3026d59bee259aa75b15a036d48aa3250574ad2
image: docker.io/library/nginx:latest
imageID: docker.io/library/nginx@sha256:0047b729188a15da49380d9506d65959cce6d40291ccfb4e039f5dc7efd33286
lastState: {}
name: nginx
ready: true
restartCount: 0
started: true
state:
running:
startedAt: "2022-12-29T06:27:50Z"
hostIP: 172.30.2.2
phase: Running
podIP: 192.168.1.3
podIPs:
- ip: 192.168.1.3
qosClass: BestEffort
startTime: "2022-12-29T06:27:35Z"四、 Pod 的分类
Pod 有两种类型：
- （1）普通 Pod
普通 Pod 一旦被创建，就会被放入到 etcd 中存储，随后会被 Kubernetes Master 调度到某个具体的 Node 上并进行绑定，随后该 Pod 对应的 Node 上的 kubelet 进程实例化成一组相关的 Docker 容器并启动起来。在默认情 况下，当 Pod 里某个容器停止时，Kubernetes 会自动检测到这个问题并且重新启动这个 Pod 里某所有容器， 如果 Pod 所在的Node 宕机，则会将这个 Node 上的所有 Pod 重新调度到其它节点上。
- （2）静态 Pod
静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod，它们不能通过API Server进行管理，无法与 ReplicationController、Deployment 或 DaemonSet 进行关联，并且kubelet 也无法对它们进行健康检查。
五、Pod阶段
Pod 的 status 字段是一个 PodStatus 对象，其中包含一个 phase 字段。Pod 的阶段（Phase）是 Pod 在其生命周期中所处位置的简单宏观概述。
下面是 phase 可能的值：
| 状态 | 说明 |
| Pending（悬决） | api server已经创建了该pod，但pod中的一个或者多个容器的镜像还没有创建，包括镜像下载过程 |
| Running（运行中） | pod内所有容器已经创建，且至少一个容器处于运行状态、正在启动或者正在重启状态 |
| Succeeded（成功） | pod内所有容器均成功退出，且不会再重启 |
| Failed（失败） | pod内所有容器均已退出，但至少一个容器退出失败 |
| Unknown（未知） | 由于某种原因无法获取pod状态，例如网络通信不畅 |
当一个 Pod 被删除时，执行一些 kubectl 命令会展示这个 Pod 的状态为 Terminating（终止）。 这个 Terminating 状态并不是 Pod 阶段之一。 Pod 被赋予一个可以体面终止的期限，默认为 30 秒。 你可以使用 --force 参数来强制终止 Pod。
六、Pod 镜像拉取策略
容器的 imagePullPolicy 和镜像的标签会影响 kubelet 尝试拉取（下载）指定的镜像。
以下列表包含了 imagePullPolicy 可以设置的值，以及这些值的效果：
- IfNotPresent
只有当镜像在本地不存在时才会拉取。
- Always
每当 kubelet 启动一个容器时，kubelet 会查询容器的镜像仓库， 将名称解析为一个镜像摘要。 如果 kubelet 有一个容器镜像，并且对应的摘要已在本地缓存，kubelet 就会使用其缓存的镜像； 否则，kubelet 就会使用解析后的摘要拉取镜像，并使用该镜像来启动容器。
- Never
Kubelet 不会尝试获取镜像。如果镜像已经以某种方式存在本地， kubelet 会尝试启动容器；否则，会启动失败。
在生产环境中部署容器时，你应该避免使用 :latest 标签，因为这使得正在运行的镜像的版本难以追踪，并且难以正确地回滚。
相反，应指定一个有意义的标签，如 v1.42.0。
ImagePullBackOff
当 kubelet 使用容器运行时创建 Pod 时，容器可能因为 ImagePullBackOff 导致状态为 Waiting。
ImagePullBackOff 状态意味着容器无法启动， 因为 Kubernetes 无法拉取容器镜像（原因包括无效的镜像名称，或从私有仓库拉取而没有 imagePullSecret）。 BackOff 部分表示 Kubernetes 将继续尝试拉取镜像，并增加回退延迟。
Kubernetes 会增加每次尝试之间的延迟，直到达到编译限制，即 300 秒（5 分钟）。
七、Pod 资源限制
每个 Pod 都可以对其能使用的服务器上的计算资源设置限额，Kubernetes 中可以设置限额的计算资源有 CPU 与 Memory 两种，其中 CPU 的资源单位为 CPU 数量，是一个绝对值而非相对值。Memory 配额也是一个绝对值，它的单位是内存字节数。 Kubernetes 里，一个计算资源进行配额限定需要设定以下两个参数：
- Requests ：该资源最小申请数量，系统必须满足要求【表示调度所需的资源】 ；
- Limits ：该资源最大允许使用的量，不能突破，当容器试图使用超过这个量的资源时，可能会被 Kubernetes Kill 并重启 【表示最大所占用的资源】；
spec:
containers:
- name: mysql
image: mysql
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"上述代码表明 mysql 容器申请最少 0.25 个 CPU 以及 64MiB 内存，在运行过程中容器所能使用的资源配额为 0.5 个 CPU 以及 128MiB 内存。
八、容器重启策略
Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。
restartPolicy 适用于 Pod 中的所有容器，restartPolicy 仅针对同一节点上 kubelet 的容器重启动作。当 Pod 中的容器退出时，kubelet 会按指数回退方式计算重启的延迟（10s、20s、40s、...），其最长延迟为 5 分钟。 一旦某容器执行了 10 分钟并且没有出现问题，kubelet 对该容器的重启回退计时器执行重置操作。
重启策略（restartPolicy）主要分为以下三种：
- Always：当容器终止退出后，总是重启容器，默认策略 ；
- OnFailure：当容器异常退出且退出状态码非0时，才重启容器；
- Never：当容器终止退出，都不重启容器 ；
