一、Pod 的定义与基本用法
1. Pod 是什么
Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
Pod 不是进程，而是容器运行的环境。Pod 所建模的是特定于应用的“逻辑主机”，其中包含一个或多个应用容器。当 Pod 包含多个应用容器时，这些容器的应用之间应该是紧耦合的关系，同一个 Pod 内的多个容器之间共享存储、网络，以及怎样运行这些容器的声明，相互之间可通过 localhost 进行通信。
2. Pod 的 YAML 完整定义
<2>编译测试应用二进制
go build -o hello-world将编译好的二进制文件放到 /wjt-k8s/wjt-pod/hello-world/ 目录下。 （2）制作 Docker 镜像 <1>编写 Dockerfile
Dockerfile 路径：/wjt-k8s/wjt-pod/Dockerfile
<2>制作 Docker 镜像并推送
（3）创建 Pod
<1>编写 Pod yaml 配置文件
Pod yaml 配置文件路径：/wjt-k8s/wjt-pod/wjt-pod.yaml
<2>创建 Pod
（4）Pod 信息查看
<1>查看 Pod 详情
<2>查看 Pod 中容器应用日志信息
（5）删除 Pod
二、Pod 的生命周期 1. Pod 调度过程
每个 Pod 在其生命周期中只会被调度一次，一旦被调度到某个节点，就会一直在该节点运行，直到该 Pod 停止或被终止。
每个 Pod 会被赋予一个唯一的 ID（UID）。
Pod 被认为是相对临时性的实体，其自身不具备自愈能力，而是通过控制器进行管理，可以被一个新的、几乎完全相同的 Pod 替换掉。
2. Pod 状态
Pod 的 status 字段是一个 PodStatus 对象，其信息如下：
（1）Pod 阶段：status.phase
Pod 阶段（phase）是 Pod 在其生命周期中所处位置的简单宏观概述。其取值与含义如下：
（2）Pod 状况：status.conditions
Pod 状况是一个数组，保存了 Pod 可能通过也可能没通过的一些状况测试的信息，根据这些信息可以判断 Pod 具体是在哪一步出现了问题。每个状况测试项的含义如下：
<1>PodScheduled：Pod 已经被调度到某节点。
<2>PodReadyToStartContainers：Pod 沙箱被成功创建并且配置了网络（Alpha 特性，必须被显式启用）。
<3>ContainersReady：Pod 中所有容器都已就绪。
<4>Initialized：所有的 Init 容器都已成功完成。
<5>Ready：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。
每个状况测试项包含的字段与含义如下：
Pod 的启动与状况转变过程：
Pod 被调度到某节点并被节点接受，PodScheduled 被设置为 True。
[——> 若没有配置 Init 容器，Initialized 被设置为 True。]
——> Kubelet 将与容器运行时一起为 Pod 生成运行时沙箱并配置网络，挂载所需的卷，PodReadyToStartContainers 被设置为 True。
——> Kubelet 开始拉取容器镜像和创建容器。
[——> 若配置了 init 容器，kubelet 依据 Init 容器在 Pod 规约中的出现顺序依次逐个运行，所有 Init 容器成功完成后 Initialized 被设置为 True。]
——> 开始并行启动所有的应用容器，所有容器都启动成功后 ContainersReady 被设置为 True。
——> Pod 可以开始为请求提供服务，Ready 被设置为 True。
3. 静态 Pod
静态 Pod 是由 kubelet 进行管理的仅存在于特定 Node 上的 Pod。它们不能通过 API Server 进行管理，无法与 ReplicationController、Deployment 或者 DaemonSet 进行关联，并且 kubelet 无法对它们进行健康检查。静态 Pod 总是由 kubelet 创建的，并且总在 kubelet 所在的 Node 上运行。
创建静态 Pod 有两种方式：配置文件和 HTTP 方式。
（1）配置文件方式
首先，需要设置 kubelet 的启动参数 --pod-manifest-path （或者在 kubelet 配置文件中配置 staticPodPath，新版本推荐）指定 kebelet 需要监控的配置文件所在的目录，kubelet 会定期扫描该目录，并根据该目录下的 .yaml 或 .json 文件进行创建 Pod 的操作。
静态 Pod 无法通过 API server 直接管理，删除静态 Pod 的操作只能是到其所在 Node 上将其定义文件从 kubelet 扫描目录中删除。
（2）HTTP 方式
通过设置 kubelet 的启动参数 --manifest-url，kubelet 将会定期从该 URL 地址下载 Pod 的定义文件，并以 .yaml 或 .json 文件的格式进行接续，然后创建 Pod。其实现方式与配置文件方式是一致的。
三、容器
1. 容器状态与容器生命周期回调
（1）容器状态
一旦调度器将 Pod 分派给某个节点，kubelet 就通过容器运行时开始为 Pod 创建容器。Kubernetes 会跟踪 Pod 中每个容器的状态，其状态有三种：
<1>Waiting（等待）：容器仍在运行其完成启动所需要的操作，例如，从某个容器镜像仓库拉取容器镜像。
<2>Running（运行中）：容器正在执行状态并且没有问题发生。
<3>Terminated（已终止）：容器已经开始执行并且或者正常结束或者因为某些原因失败。
Pod 的 status 字段包含了 Pod 中各个容器的状态：
（2）容器生命周期回调
Kubernetes 为容器生命周期提供了两个回调：
<1>PostStart：在容器被创建之后立即被执行。不能保证回调会在容器入口点（ENTRYPOINT）之前执行。
<2>PreStop：在容器被终止之前被执行。在用来停止容器的 TERM 信号被发出之前，回调必须结束。Pod 的终止宽限周期在 PreStop 回调执行之前即开始计数，所以无论回调执行结果如何，容器最终都会在 Pod 的终止宽限期内被终止。
容器可以通过实现和注册回调的处理程序来访问回调，有三种实现方式可供选择：httpGet、tcpSocket、exec（与容器探针一样）。当调用容器生命周期管理回调时，Kubernetes 管理系统根据回调动作执行其处理程序，httpGet 和 tcpSocket 在 kubelet 进程执行，而 exec 则在容器内执行。
回调的递送应该是至少一次。如果 PostStart 或 PreStop 回调失败，它会杀死容器。
回调处理程序的日志不会在 Pod 事件中公开。
若容器配置了 PostStart 回调且当前处于 Running 状态，则 postStart 回调已经执行且已完成；若容器配置了 PreStop 回调，则 PreStop 会在容器进入 Terminated 状态之前执行。所以，容器状态及其生命周期回调之间的时间先后顺序为：
Waiting ——> PostStart 回调 ——> Running ——> PreStop 回调 ——> Terminated
2. 容器探针
probe 是由 kubelet 对容器执行的定期诊断。
（1）三种探测类型
<1>livenessProbe：存活态探测，判断容器是否正在运行。如果探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策做相应处理。
<2>readinessProbe：绪态探测探测，判断容器是否准备好为请求提供服务。如果探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。
<3>startupProbe：服务启动探测，判断容器中的应用是否已经启动。如果探测失败，kubelet 将杀死容器，并且容器将根据其重启策做相应处理。如果提供了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。
（2）四种探测方式
<1>exec：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
<2>grpc：使用 gRPC 执行一个远程过程调用。目标应该实现 gRPC 健康检查。如果响应的状态是 "SERVING"，则认为诊断成功。
<3>httpGet：对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。
<4>tcpSocket：对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。 如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。
（3）三种探测结果
<1>Success（成功）：容器通过了诊断。
<2>Failure（失败）：容器未通过诊断。
<3>Unknown（未知）：诊断失败，因此不会采取任何行动。
3. 容器重启策略
Pod 的重启策略（restartPolicy）应用于 Pod 内的所有容器，并且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。当某个容器异常退出或者健康检查失败时，kubelet 将根据 restartPolicy 的设置进行相应的操作。
Pod 的重启策略包括 Always、OnFailure 和 Never，默认值为 Always。
<1>Always：当容器失效时，由 kubelet 自动重启该容器。
<2>OnFailure：当容器停止运行且退出码不为 0 时，由 kubelet 自动重启该容器。
<3>Never：不论容器运行状态如何，kubelet 都不会重启该容器。
kubelet 重启失效容器的时间间隔以 sync-frequency 乘以 2n 来计算，例如 1、2、4、8 倍等，最长延时 5 min，并且在成功重启后的 10 min 后重置该时间。
Pod 的重启策略与控制方式息息相关，当前可用于管理 Pod 的控制器包括 ReplicationController、Job、DaemonSet，还可以通过 kubelet 管理（静态 Pod）。每种控制器对 Pod 的重启策略要求如下：
<1>RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运行。
<2>Job：OnFailure 或 Never，确保容器执行完成后不再重启。
<3>kubelet：在 Pod 失效时自动重启，不论将 restartPolicy 设置为什么值，也不会对 Pod 进行健康检查。
一些常见的状态转换场景：
四、Pod 与其容器 1. Init 容器 （1）Init 容器的作用 Init 容器是一种特殊容器，它们必须在 Pod 内的应用容器启动之前运行完成，可用于在应用容器启动之前完成一些前置操作。 （2）Init 容器的启动与运行 使用了 Init 容器的 Pod 的启动与运行顺序： <1>初始化网络和数据卷。 <2>kubelet 依据 Init 容器在 Pod 规约中的出现顺序依次逐个运行。每个 Init 容器必须运行成功，下一个才能够运行。 <3>Init 容器提供了一种机制来阻塞或延迟应用容器的启动，所有的 Init 容器都依次运行完成以后，所有的应用容器才会并行启动。 （3）Init 容器与应用容器的异同 <1>Init 容器可以包括一些应用容器中不存在的实用工具和安装脚本。Init 容器可以安全地运行实用程序或自定义代码，而在其他方式下运行这些实用程序或自定义代码可能会降低应用容器镜像的安全性。 通过将不必要的工具分开，你可以限制应用容器镜像的被攻击范围。 <2>与同一 Pod 中的多个应用容器相比，Init 容器能以不同的文件系统视图运行。因此，Init 容器可以被赋予访问应用容器不能访问的 Secret 的权限。 <3>Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe， 因为它们必须在 Pod 就绪之前运行完成。 <4>Init 容器是按声明顺序依次运行完成，此后，所有的应用容器才并行启动。 （4）Init 容器实践 考虑创建一个 Pod，该 Pod 包含一个应用容器和两个 Init 容器。应用容器名称为 web-service，直接使用上文的 wjt-pod 的容器镜像，开启一个 web 服务，看代码可知，请求路径 /config 对应的响应是读取文件 /etc/hello-world/hello-world.conf 的内容并打印出来。第一个 init 容器名称为 wait-for-myservice，它会 sleep 300 秒后结束，模拟等待某个 service 创建完成。第二个 init 容器名称为 config-maker，它与应用容器 web-service 挂载同一个卷，往配置文件写入内容供应用容器读取。 <1>制作第一个 init 容器 wait-for-myservice 的容器镜像 Dockerfile：
创建镜像并推送：
<2>制作第二个 init 容器 config-maker 的容器镜像
Dockerfile：
创建镜像并推送：
<3>创建 Pod init-container-pod
init-container-pod.yaml：
创建 Pod：
这里 Pod init-container-pod 的状态为 Init:0/2，表示 Pod 包含 2 个 Init 容器，目前运行完成个数为 0。
<4>查看 Pod 和容器状态
查看 Pod 状态：
查看 init 容器状态：
查看应用容器状态：
可以看到，第一个 init 容器 wait-for-myservice 处于 running 状态，第二个 init 容器 config-maker 和应用容器 web-service 都处于 waiting 状态，这是因为第一个 init 容器还在 sleep 当中，还未运行完成，所以第二个 init 容器和应用容器只能处于等待状态了。
<5>等待 300 秒后再次查看 Pod 和容器状态
查看 Pod 状态：
查看 init 容器状态：
查看应用容器状态：
可以看到，两个 init 容器都已是 terminated 状态，而应用容器则是 running 状态。
<6>应用容器服务验证
登录 Pod，请求：
可以看到，应用容器打印内容正是第二个 init 容器写入内容！
2. 临时容器
临时容器是一种特殊的容器，在现有 Pod 中临时运行，以便完成用户发起的操作。临时容器缺少对资源或执行的保证，并且永远不会自动重启， 因此不适用于构建应用程序，一般用于故障排查。
临时容器使用与常规容器相同的 ContainerSpec 节来描述，但许多字段是不兼容和不允许的，例如，临时容器没有端口配置，且其 Pod 资源分配是不可变的。
临时容器是使用 API 中的一种特殊的 ephemeralcontainers 处理器进行创建的， 而不是直接添加到 pod.spec 段，因此无法使用 kubectl edit 来添加一个临时容器。
3. Downward API
（1）什么是 Downward API
Downward API 允许容器在不使用 Kubernetes 客户端或 API 服务器的情况下获得自己或集群的信息。
在 Kubernetes 中，有两种方法可以将 Pod 和容器字段暴露给运行中的容器：
<1>环境变量：将 Pod 或 Container 信息设置为容器内的环境变量。
<2>Volume 挂载：将 Pod 或 Container 信息以文件的形式挂载到容器内部。
这两种暴露 Pod 和容器字段的方式统称为 Downward API。
（2）Downward API 使用示例
<1>环境变量 - 将 Pod 信息设置为容器内的环境变量
参考： 《Kubernetes 权威指南第 5 版》
标签：容器,Kubernetes,基本原理,init,kubelet,Init,应用,Pod From： https://www.cnblogs.com/wujuntian/p/18088279