以前知道kubernetes，简称k8s。原来这个简称是因为k和s之间有8个字母#_#. 言归正传，此篇整理关于pod相关的内容。
理解 Pod Preset
Pod Preset 是一种 API 资源，在 Pod 创建时，用户可以用它将额外的运行时需求信息注入 Pod。 使用标签选择器（label selector）来指定 Pod Preset 所适用的 Pod。
Kubernetes 提供了准入控制器 (PodPreset)，该控制器被启用时，会将 Pod Preset 应用于接收到的 Pod 创建请求中。 当出现 Pod 创建请求时，系统会执行以下操作：
- 检索所有可用 PodPresets 。
- 检查 PodPreset 的标签选择器与要创建的 Pod 的标签是否匹配。
- 尝试合并 PodPreset 中定义的各种资源，并注入要创建的 Pod。
- 发生错误时抛出事件，该事件记录了 pod 信息合并错误，同时在 不注入 PodPreset 信息的情况下创建 Pod。
- 为改动的 Pod spec 添加注解，来表明它被 PodPreset 所修改。 注解形如： podpreset.admission.kubernetes.io/podpreset-": ""。
一个 Pod 可能不与任何 Pod Preset 匹配，也可能匹配多个 Pod Preset。 同时，一个 PodPreset 可能不应用于任何 Pod，也可能应用于多个 Pod。 当 PodPreset 应用于一个或多个 Pod 时，Kubernetes 修改 pod spec。 对于 Env、 EnvFrom 和 VolumeMounts 的改动， Kubernetes 修改 pod 中所有容器的规格，对于卷的改动，Kubernetes 修改 Pod spec。
注意： 适当时候，Pod Preset 可以修改 Pod 规范中的以下字段： - .spec.containers 字段 - initContainers 字段 (需要 Kubernetes 1.14.0 或更高版本)。
Init 容器能做什么？
因为 Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：
- Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。例如，没有必要仅为了在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具而去FROM 一个镜像来生成一个新的镜像。
- Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
- 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
- Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具>5. 有访问 Secrets 的权限，而应用容器不能够访问。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。
因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。 特别地，基于 EmptyDirs 写文件的代码，应该对输出文件可能已经存在做好准备。
Pod 重启的原因
Pod重启导致 Init 容器重新执行，主要有如下几个原因：
用户更新 Pod 的 Spec 导致 Init 容器镜像发生改变。Init 容器镜像的变更会引起 Pod 重启. 应用容器镜像的变更仅会重启应用容器。
Pod 的基础设施容器 (译者注：如 pause 容器) 被重启。 这种情况不多见，必须由具备 root 权限访问 Node 的人员来完成。
当 restartPolicy 设置为 Always，Pod 中所有容器会终止而强制重启，由于垃圾收集导致 Init 容器的完成记录丢失。
你可以在Pod的规格信息中与containers数组同级的位置指定 Init 容器。
容器探针
Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：
livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。
Pod 的生命
有三种可用的控制器：
使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod 。
所有这三种类型的控制器都包含一个 PodTemplate。建议创建适当的控制器，让它们来创建 Pod，而不是直接自己创建 Pod。这是因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。
网友评论