资源请求，requests
CPU 预留显示在清单文件中的 .spec.containers[].resources.requests.cpu，实际用量可以超过 CPU 预留。
内存预留显示在清单文件中的 .spec.containers[].resources.requests.memory。实际用量可以超过内存预留，但节点内存不足时可能会清理容器
资源限制，limits
CPU 限制显示在清单文件中的 .spec.containers[].resources.limits.cpu。实际用量可以短时间超过 CPU 限制，容器不会被停止。
内存限制显示在清单文件中的 .spec.containers[].resources.limits.memory。实际用量不能超过内存限制，如果超过了，容器可能会被停止或者被调度到其他资源充足的机器上。
GPU 限制默认为不限制
健康检查
- 存活检查：使用存活探针检测容器是否在运行，该参数显示在 livenessProbe 字段。
- 就绪检查：使用就绪探针检测容器是否准备好处理请求，该参数显示在 readinessProbe 字段。
- 启动检查：使用启动探针检测容器应用程序是否已经启动，该参数显示在 startupProbe 字段。
存活、就绪和启动检查包含以下配置：
- HTTP 请求：在容器 IP 地址的指定端口和路径上执行 HTTP Get 请求，如果响应状态码大于等于 200 且小于 400，则认为诊断成功。支持的参数包括：路径：HTTP 或 HTTPS，由 scheme 指定；访问 HTTP 服务器的路径，由 path 指定；访问端口或端口名由容器暴露，端口号必须在 1 和 65535 之间，该值由 port 指定。 初始延迟（s）：容器启动后，存活探针启动之前等待的秒数，由 initialDelaySeconds 指定。默认为 0。 检查间隔（s）：探测频率（以秒为单位），由 periodSeconds 指定。默认为 10，最小值为 1。 超时时间（s）：探针超时的秒数，由 timeoutSeconds 指定。默认为 1，最小值为 1。 成功阈值：探测失败后，视为探测成功的最小连续成功次数，由 successThreshold 指定。默认为 1，存活探针和启动探针的该值必须为 1。最小值为 1。 失败阈值：探测成功后，视为探测失败的最小连续失败次数，由 failureThreshold 指定。默认为 3，最小值为 1。
- TCP 端口：在容器 IP 地址的指定端口上执行 TCP 检查。如果该端口打开，则认为诊断成功。支持的参数包括： 端口：访问端口或端口名由容器暴露。端口号必须在 1 和 65535 之间。该值由 port 指定。 初始延迟（s）：容器启动后，存活探针启动之前等待的秒数，由 initialDelaySeconds 指定。默认为 0。 检查间隔（s）：探测频率（以秒为单位），由 periodSeconds 指定。默认为 10，最小值为 1。 超时时间（s）：探针超时的秒数，由 timeoutSeconds 指定。默认为 1，最小值为 1。 成功阈值：探测失败后，视为探测成功的最小连续成功次数，由 successThreshold 指定。默认为 1，存活探针和启动探针的该值必须为 1。最小值为 1。 失败阈值：探测成功后，视为探测失败的最小连续失败次数，由 failureThreshold 指定。默认为 3，最小值为 1。
- 命令：在容器中执行指定命令。如果命令退出时返回代码为 0，则认为诊断成功。支持的参数包括：命令：用于检测容器健康状态的检测命令，由 exec.command 指定。 初始延迟（s）：容器启动后，存活探针启动之前等待的秒数，由 initialDelaySeconds 指定。默认为 0。 检查间隔（s）：探测频率（以秒为单位），由 periodSeconds 指定。默认为 10，最小值为 1。 超时时间（s）：探针超时的秒数，由 timeoutSeconds 指定。默认为 1，最小值为 1。 成功阈值：探测失败后，视为探测成功的最小连续成功次数，由 successThreshold 指定。默认为 1，存活探针和启动探针的该值必须为 1。最小值为 1。 失败阈值：探测成功后，视为探测失败的最小连续失败次数，由 failureThreshold 指定。默认为 3，最小值为 1。
启动命令
默认情况下，容器会运行默认镜像命令。 命令对应清单文件中容器的 command 字段。 参数对应清单文件中容器的 args 字段。
更新策略
不同工作负载使用不同的更新策略。
deploy
.spec.strategy 字段指定用于用新容器组替换旧容器组的策略。.spec.strategy.type 可以是 Recreate 或 RollingUpdate。默认值是 RollingUpdate。 滚动更新（推荐） 滚动更新将逐步用新版本的实例替换旧版本的实例。升级过程中，流量会同时负载均衡分布到新老版本的实例上，因此服务不会中断。 部署中的滚动更新设置与有状态副本集中的不同。 最大不可用容器组数量：升级过程中允许不可用的容器组的最大数量，由 maxUnavailable 指定。默认值是 25%。 最大多余容器组数量：可调度的超过期望数量的容器组的最大数量，由 maxSurge 指定。默认值是 25%。
滚动更新会创建出一定数量的新 Pod,同时删除一定数量的旧 Pod,以此来实现应用的无中断升级。 maxSurge 字段控制 Deployment 在升级过程中可以创建出的新 Pod 最大数量。它的值可以是整数,也可以是百分比形式,如 30%。 如果 maxSurge 的值为 3,则 Deployment 在升级过程中最多可以创建 3 个新的 Pod。当旧 Pod 被删除后,新 Pod 会继续创建,直到最多有 3 个新的 Pod。 如果 maxSurge 的值为 30%,则新 Pod 的最大数量是 Deployment replicas 字段值的 30%。例如如果 replicas=10,则 maxSurge=30% 意味着最多可以创建 3 个新的 Pod (10 * 30% = 3)。 当 Deployment 的 Pod 数量小于或等于 maxSurge 时,会继续创建新的 Pod。当数量超过 maxSurge 时,Deployment 会等到一定数量的旧 Pod 被删除后,再继续创建新的 Pod。 maxSurge 的目的是控制 Deployment 升级时新旧 Pod 的比例,避免在升级的过程中新 Pod 的数量过多而导致应用不可用。通过 maxSurge,我们可以更加平滑地进行 Deployment 的 rolling update。 同时更新 替换升级会先删除现有的容器组，再创建新的容器组。请注意，升级过程中服务会中断。
有状态副本集StatefulSet
更新策略下的下拉菜单显示在清单文件中有状态副本集的 .spec.updateStrategy 字段。您可以处理容器组容器、标签、资源预留或限制以及注解的更新。有两种策略： 滚动更新（推荐） 如果 .spec.template 已更新，有状态副本集中的容器组将被自动删除，并创建新的容器组来替换。容器组将按照反向顺序更新，依次删除和创建。前一个容器组更新完成并开始运行后，才会开始更新下一个新的容器组。 删除容器组时更新 如果 .spec.template 已更新，有状态副本集中的容器组将不会自动更新。您需要手动删除旧的容器组，控制器才会创建新的容器组。
容器组副本分组序号：如果您对更新进行分区，当更新有状态副本集的容器组配置时，所有序号大于等于该分区序号值的容器组都会被更新。该字段由 .spec.updateStrategy.rollingUpdate.partition 指定，默认值是 0
守护进程集(DaemonSet)
滚动更新（推荐） 如果 .spec.template 已更新，旧的守护进程集容器组将被终止，并以受控方式自动创建新的容器组。整个更新过程中，每个节点上至多只有一个守护进程集的容器组运行。 删除容器组时更新 如果 .spec.template 已更新，只有当您手动删除旧的守护进程集容器组时才会创建新的守护进程集容器组 守护进程集中的滚动更新设置与有状态副本集中的不同。
最大不可用容器组数量：升级过程中允许不可用的容器组的最大数量，由 maxUnavailable 指定。默认值是 20%。 容器组就绪最短运行时长（s）：新创建的守护进程集的容器组被视为可用之前的最少秒数，由 minReadySeconds 指定。默认值是 0。
守护进程集(DaemonSet)通常用于在每个 Node 上运行一个 Pod,常见的用途包括: 日志收集 daemon 节点监控 daemon 存储 daemon
守护进程集的 Pod 通常是一个容器,但也可以有多个容器,甚至可以指定 initContainers。所以守护进程集的 Pod 不仅限于一个容器。 守护进程集的 Pod 要在指定的 Node 上运行一个实例。当有 Node 加入集群时,也会在那个新 Node 上运行一个 Pod。当 Node 从集群移除时,那个 Node 上的 Pod 也会被回收。 更新守护进程集有几种方式: 更新 DaemonSet 的 Pod 模板。这会更新 DaemonSet 管理的所有 Pod,DaemomSet 会删除旧 Pod 并创建匹配新模板的 Pod。 执行 kubectl rolling-update 命令。这会gradually 更新集群中的 DaemonSet。新的 Pod 会被创建,并等待其变为 ready,然后旧 Pod 会被删除。这可以确保在任何时候,至少有最小数量的 Pod 是可用的
