有道云分享：管理Pod资源对象
Pod是Kubernetes系统的基础单元，是资源对象模型中可用用户创建或部署的最小组件，也是在Kubernetes系统上运行容器话应用的资源对象。其他的大多数资源对象都是用于支撑和扩展Pod对象功能的，例如：用于管理Pod运行的StatefulSet和Delpoyment等控制器对象，用于暴露Pod应用的Service和Ingress对象，为Pod提高存储的PersistentVolume存储资源对象等。
Pod对象是一组容器的集合，这些容器共享Network,UTS及IPC名称空间，因此具有相同的域名，主机名和网络接口，并可通过IPC直接通信，为一个Pod对象中的各容器提供网络名称空间等共享机制的是底层基础容器pause
将多个应用分别构建到多个而非单个Pod中，这样也更能符合容器的轻量化设计，运行目的
Pod也是Kubernetes进行系统规模伸缩的基础单元
分布式系统设计通常包含以下几种模型
管理Pod对象的容器【https://blog.csdn.net/chenvast/article/details/78600957】
一个Pod对象中至少要存在一个容器，因此，containers字段是定义Pod时其嵌套字段Spec中的必选项，用于为Pod制定要创建的容器列表。进行容器配置时，name为必选字段，用于指定容器名称，image字段为可选，以方便更高级别的管理类资源等能覆盖此字段
容器的“imagePullPolicy”字段用于为其指定镜像获取策略，它的可用值如下：
Always：镜像标签为"latest"或镜像不存在时总是从指定的仓库中获取镜像
IfNotPresent：仅当本地镜像缺失时方才从目标仓库下载镜像
Never：禁止从仓库下载镜像，即仅使用本地镜像
容器的ports字段的值是一个列表，由一到多个端口对象组成，它的常用嵌套字段包括如下：
containerPort<integer>：必选字段，指定在Pod对象的Ip地址上暴露的容器端口，有效范围为（0，65535）；使用时，应该总是指定容器应用正常监听着的端口
name<string>：当前端口的名称，必须符合IANA_SVC_NAME规范且当前Pod内必须是唯一的；此端口名可被Service资源调用。
protocol：端口相关的协议，其值仅可为TCP或UDP，默认为TCP.
Pod对象的IP地址仅在当前集群内可达，它们无法直接接收来自集群外部客户端的请求流量，尽管它们的服务可达性不受工作节点边境的约束，但依然受制于集群边境。一个简单的解决方案是通过其所在的工作节点的IP地址和端口将其暴露到集群外部
hostPort<integer>：主机端口，它将接收到的请求通过NAT机制转发至由containerPort字段指定的容器端口
hostIP<string>：主机端口要绑定的主机IP，默认为0.0.0.0，即主机之上所有可用的IP地址；考虑到托管的Pod对象是由调度器调度运行的，工作节点的IP地址难以明确指定，因此此字段通常使用默认值。
需要注意的是，hostPort与NodePort类型的Service对象暴露端口的方式不同，NodePort是通过所有节点暴露容器服务，而hostPort则是经由Pod对象所在节点的IP地址来进行
通过环境变量配置容器化应用时，需要在容器配置段中嵌套使用env字段，它的值是一个由环境变量构成的列表。环境变量通常由name和value字段组成
name<string>：环境变量的名称，必选字段。
value<string>：传递给环境变量的值，通过$(VAR_NAME)引用，逃逸格式为“$$(VAR_NAME)”,默认值为空
Pod 安全策略 是集群级别的资源，它能够控制 Pod 运行的行为，以及它具有访问什么的能力。
PodSecurityPolicy对象定义了一组条件，指示 Pod 必须按系统所能接受的顺序运行。
控制面 字段名称
已授权容器的运行 privileged
为容器添加默认的一组能力 defaultAddCapabilities
为容器去掉某些能力 requiredDropCapabilities
容器能够请求添加某些能力 allowedCapabilities
控制卷类型的使用 volumes
主机网络的使用 hostNetwork
主机端口的使用 hostPorts
主机 PID namespace 的使用 hostPID
主机 IPC namespace 的使用 hostIPC
主机路径的使用 allowedHostPaths
容器的 SELinux 上下文 seLinux
用户 ID runAsUser
配置允许的补充组 supplementalGroups
分配拥有 Pod 数据卷的 FSGroup fsGroup
必须使用一个只读的 root 文件系统 readOnlyRootFilesystem
Pod 安全策略 由设置和策略组成，它们能够控制 Pod 访问的安全特征。
设置分为如下三类：
基于布尔值控制：这种类型的字段默认为最严格限制的值。
基于被允许的值集合控制：这种类型的字段会与这组值进行对比，以确认值被允许。
基于策略控制：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。
Kubernetes Pod 生命周期：
Pod phase：
Pod 的 status 定义在 PodStatus 对象中，其中有一个 phase 字段。
Pod 的相位（phase）是 Pod 在其生命周期中的简单宏观概述。
Pod 相位的数量和含义是严格指定的。
下面是 phase 可能的值：
挂起（Pending）： Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间，这可能需要花点时间。
运行中（Running）： 该 Pod 已经绑定到了一个节点上，Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态。
成功（Succeeded）： Pod 中的所有容器都被成功终止，并且不会再重启。
失败（Failed）： Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
未知（Unknown）： 因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败。
Pod 状态：
Pod 有一个 PodStatus 对象，其中包含一个 PodCondition 数组。
PodCondition 数组的每个元素都有一个 type 字段和一个 status 字段。
type 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。
status 字段是一个字符串，可能的值有 True、False 和 Unknown。
Pod的创建过程
容器探针：
探针 是由 kubelet 对容器执行的定期诊断。
kubelet 调用由容器实现的 Handler。
有三种类型的处理程序：
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一：
成功：容器通过了诊断。
失败：容器未通过诊断。
未知：诊断失败，因此不会采取任何行动。
Kubelet 可以选择是否执行在容器上运行的两种探针执行和做出反应：
livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
该什么时候使用存活（liveness）和就绪（readiness）探针?
如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活探针; kubelet 将根据 Pod 的restartPolicy 自动执行正确的操作。
Pod健康监测
报告的 Pod 状态信息取决于当前的 ContainerState
重启策略：
PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never。
默认为 Always。
restartPolicy 适用于 Pod 中的所有容器。
restartPolicy 仅指通过同一节点上的 kubelet 重新启动容器。
Pod 的生命：
一般来说，Pod 不会消失，直到人为销毁他们。
唯一例外是成功或失败的 phase 超过一段时间的Pod将过期并被自动销毁。
有三种可用的控制器：
使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。
所有这三种类型的控制器都包含一个 PodTemplate。
建议创建适当的控制器，让它们来创建 Pod，而不是直接自己创建 Pod。
这是因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。
状态示例：
Pod 中只有一个容器并且正在运行。容器成功退出。
记录完成事件。
如果 restartPolicy 为：
Always：重启容器；Pod phase 仍为 Running。
OnFailure：Pod phase 变成 Succeeded。
Never：Pod phase 变成 Succeeded。
Pod 中只有一个容器并且正在运行。容器退出失败。
记录失败事件。
如果 restartPolicy 为：
Always：重启容器；Pod phase 仍为 Running。
OnFailure：重启容器；Pod phase 仍为 Running。
Never：Pod phase 变成 Failed。
Pod 中有两个容器并且正在运行。有一个容器退出失败。
记录失败事件。
如果 restartPolicy 为：
Always：重启容器；Pod phase 仍为 Running。
OnFailure：重启容器；Pod phase 仍为 Running。
Never：不重启容器；Pod phase 仍为 Running。
如果有一个容器没有处于运行状态，并且两个容器退出：
记录失败事件。
如果 restartPolicy 为：
Always：重启容器；Pod phase 仍为 Running。
OnFailure：重启容器；Pod phase 仍为 Running。
Never：Pod phase 变成 Failed。
Pod 中只有一个容器并处于运行状态。容器运行时内存超出限制：
容器以失败状态终止。
记录 OOM 事件。
如果 restartPolicy 为：
Always：重启容器；Pod phase 仍为 Running。
OnFailure：重启容器；Pod phase 仍为 Running。
Never: 记录失败事件；Pod phase 仍为 Failed。
Pod 正在运行，磁盘故障：
杀掉所有容器。
记录适当事件。
Pod phase 变成 Failed。
如果使用控制器来运行，Pod 将在别处重建。
Pod 正在运行，其节点被分段。
节点控制器等待直到超时。
节点控制器将 Pod phase 设置为 Failed。
如果是用控制器来运行，Pod 将在别处重建。
如果要仅在探测成功时才开始向 Pod 发送流量，请指定就绪探针。
如果您希望容器能够自行维护，您可以指定一个就绪探针，该探针检查与存活探针不同的端点。
Pod终止过程
Pod 健康监测：