pod详解

[4.2.4，Kubernetes 中Init 容器（初始化容器）的核心运行规则总结，其内容是对 Init 容器在 Pod 生命周期中行为逻辑的约束，以下是结构化解读及实践意义：](#4.2.4，Kubernetes 中Init 容器（初始化容器）的核心运行规则总结，其内容是对 Init 容器在 Pod 生命周期中行为逻辑的约束，以下是结构化解读及实践意义：)

[五，Pod 的镜像拉取策略（重点）](#五，Pod 的镜像拉取策略（重点）)

[5.1. Always](#5.1. Always)

[5.2. IfNotPresent](#5.2. IfNotPresent)

[5.3. Never](#5.3. Never)

5.4、关键注意事项

[5.5 Pod 的重启策略](#5.5 Pod 的重启策略)

[六， Pod 资源限制](#六， Pod 资源限制)

[6.1、核心概念：Request vs Limit](#6.1、核心概念：Request vs Limit)

七，健康检查：又称为探针（Probe）

[7.1 探针是由kubelet对容器执行的定期诊断。](#7.1 探针是由kubelet对容器执行的定期诊断。)

7.2，三种探针的核心规则

[7.2.1. 存活探针（livenessProbe）：检测容器 "是否存活"](#7.2.1. 存活探针（livenessProbe）：检测容器 “是否存活”)

[7.2.2.就绪探针（readinessProbe）：检测容器 "是否就绪（能接收请求）"](#7.2.2.就绪探针（readinessProbe）：检测容器 “是否就绪（能接收请求）”)

[7.2.3，启动探针（startupProbe）：检测应用 "是否启动完成"](#7.2.3，启动探针（startupProbe）：检测应用 “是否启动完成”)

小结

结语

前言

Pod作为Kubernetes（K8s）中最小的部署、调度与管理单元，是深入理解K8s容器编排体系的基础核心。掌握Pod的相关概念与配置规则，是实现容器化应用稳定部署、高效运维的关键前提。本文围绕Pod展开系统梳理，全面覆盖Pod基础定义、核心特性、组成结构（含基础容器Pause）、两种核心使用方式（单/多容器Pod），以及Pod运行过程中的关键配置规则------包括共享资源机制、初始化容器特性、镜像拉取策略、重启策略、资源限制配置，同时详解保障Pod运行稳定性的三种探针（存活、就绪、启动探针）。通过结构化的知识点拆解与逻辑串联，帮助读者建立对Pod的完整认知体系，明晰各核心知识点的关联与实践价值，为后续K8s控制器、服务发现等进阶内容的学习奠定基础。

一，Pod基础概念

1.1、核心定义

Pod 是 Kubernetes（K8s）中最小的部署、调度和管理单元 ，而非单个容器。它是一个或多个紧密耦合的容器的集合，这些容器共享网络、存储等资源，并且会被原子性地调度到同一个节点上运行。

一句话总结：Pod 是 K8s 对「应用实例」的抽象，你可以把它理解为一个「逻辑主机」，里面运行着一个或多个相互依赖的容器。

最小部署的单元
包含一个或者多个容器（一组容器的集合）
一个 pod 中的容器共享网络命名空间和存储资源
pod 本身是一次性、非持久的，故障后通常会被重建而非修复

二，k8s中单容器 Pod、多容器 Pod 这两种核心使用方式

2.1、单容器 Pod（最主流的使用方式）

2.1.1，定义

一个 Pod 内仅包含 1 个业务容器（K8s 会自动添加 Pause 基础设施容器，但用户实际操作 / 感知的是 "单业务容器"）。

2.1.2，典型场景

所有独立运行、无需依赖其他容器的服务，比如：

静态资源服务：Nginx
后端应用：Spring Boot/Django 服务
中间件实例：Redis 单机节点、MySQL 单机实例

2.1.3，核心优势

管理简单：只需要维护一个业务容器的配置、镜像、日志
资源隔离清晰：容器的资源（CPU / 内存）独立分配，不会和其他容器抢占
扩缩容灵活：可以通过 Deployment 轻松扩缩副本数（每个副本都是独立的单容器 Pod）
故障排查容易：日志、进程都集中在一个业务容器，定位问题更高效

2.1.4，适用场景

90% 以上的生产服务，只要服务是 "独立运行、不需要和其他容器强依赖" 的，都用单容器 Pod。

2.2，多容器 Pod（仅用于 "紧密耦合" 的场景）

2.2.1，定义

一个 Pod 内包含2 个及以上业务容器 ，这些容器满足「强依赖、共享资源（网络 / 存储）、生命周期绑定」的条件 ------ 简单说：这些容器必须 "绑在一起才能用"。

2.2.2，核心前提：什么是 "紧密耦合"？

满足以下至少 1 个条件，才适合放在同一个 Pod：

容器缺一不可：比如主应用容器必须依赖日志收集容器才能输出日志
容器高频交互：比如数据交换频率极高，用网络通信不如共享存储高效
容器共享唯一资源：比如共享同一个本地文件、同一个网络端口（对外表现为一个服务）

2.2.3，核心优势

简化主容器逻辑：主容器不用写日志收集、配置拉取的代码，专注业务
复用辅助能力：Sidecar 容器（比如 Fluentd）可以在多个 Pod 中复用，不用重复开发
统一资源管理：所有相关容器的网络、存储都由 Pod 统一管理，对外表现为一个服务

2.2.4，关键注意事项（踩坑点）

禁止放不相关容器：比如不能把 Nginx 和 MySQL 放一个 Pod------ 两者生命周期、扩缩容需求完全不同（Nginx 需要多副本，MySQL 需要单实例）
容器生命周期要匹配：比如主容器停止后，Sidecar 容器也应该自动停止（避免 "僵尸 Sidecar" 占用资源）
资源分配要合理：避免 Sidecar 容器抢占主容器的 CPU / 内存（比如给主容器分配更多资源）

2.2.5适用场景

仅用于「主容器需要固定辅助能力，且辅助能力和主容器强绑定」的场景，比如：

主应用 + 日志收集容器
主应用 + 配置同步容器
主应用 + 网络代理容器

三， Pause 容器

Pause 容器（也叫 Infra 容器）是 Kubernetes 中 Pod 的 "基础设施容器"，是每个 Pod 里默认会自动创建的第一个容器，专门用来支撑 Pod 内其他业务容器的资源共享：

3.1. 核心定位

Pause 容器是 Pod 的 "底层支撑容器"------ 用户不用手动创建它，K8s 在创建 Pod 时会自动启动它，它是 Pod 内所有业务容器（比如 "应用""侧车容器"）的资源共享基础。

3.2 主要作用

它的核心功能是帮 Pod 内的业务容器 "统一资源环境"：

维护 Pod 的网络命名空间 ：Pause 容器会先创建 Pod 的 IP、端口、路由等网络资源，后续所有业务容器都 "加入这个网络命名空间"，所以 Pod 内的容器能共享同一个 IP，用localhost直接通信。
持有存储卷挂载点：Pod 定义的存储卷（比如共享日志的 Volume）会先挂载到 Pause 容器，业务容器再从 Pause 容器继承挂载点，实现数据共享。
回收僵尸进程：Pause 容器是 Pod 内 PID 为 1 的进程，会自动回收业务容器退出后产生的 "僵尸进程"，避免节点资源被无效进程占用。

3.3. 启动流程

当 K8s 创建一个 Pod 时：

先启动 Pause 容器，初始化网络、存储等资源；
再启动 Pod 内的业务容器（应用、侧车等），并让这些容器 "加入 Pause 容器的资源命名空间"；
最终所有业务容器都共享 Pause 容器的资源，形成一个统一的 Pod 环境。

3.4. 特点

Pause 容器本身几乎不消耗资源------ 它的镜像体积通常只有几 MB，运行时占用的 CPU / 内存可以忽略不计，只负责 "撑住" Pod 的资源环境。

3.5，Pod中的共享资源

3.5.1. 共享「网络命名空间」

这是 Pod 内容器最核心的共享资源：

共享内容 ：Pod 内所有容器共用同一个IP 地址、端口空间、网络路由、DNS 配置。
具体表现 ：
- 容器之间可以直接通过 localhost:端口 通信（无需跨网络）；
- 整个 Pod 对外表现为一个单一的网络端点，K8s 会为 Pod 分配唯一的集群内 IP（Cluster IP）；
- 注意：Pod 内的容器不能使用相同的端口，否则会出现端口冲突。
示例：Pod 内的 Nginx 容器（占用 80 端口）和日志收集容器，可以通过 localhost:80 访问 Nginx 的服务。

3.5.2. 共享存储卷（Volume）

Pod 内的容器可以通过共享 Volume 实现数据互通或持久化：

共享内容 ：Pod 定义的所有存储卷（如 emptyDir、PersistentVolume 等），会被挂载到 Pod 内的所有容器中。
具体表现 ：
- 一个容器写入 Volume 的数据，其他容器可以直接读取；
- Volume 是 Pod 级别的资源，与 Pod 生命周期绑定（除非用持久卷）。
示例：应用容器将日志写入共享的 emptyDir 卷，Sidecar 日志容器从该卷读取日志并发送到 ELK。

3.5.3. 共享「IPC 命名空间」

Pod 内的容器共享进程间通信的资源：

共享内容 ：共用信号量、消息队列、共享内存等 IPC 资源。
具体表现 ：容器之间可以通过 Linux 的 IPC 机制（如 System V 共享内存、POSIX 消息队列）直接通信，无需通过网络。
示例：计算容器将中间结果写入共享内存，分析容器直接从共享内存读取数据，提升通信效率。

3.5.4. 共享「UTS 命名空间」

Pod 内的容器共用同一个主机名和域名：

共享内容：Pod 的主机名（默认是 Pod 的名称）、域名解析配置会被所有容器共享。
具体表现 ：在任意容器内执行 hostname 命令，得到的都是 Pod 的名称。

四，Pod容器的分类：基础容器与初始化容器

4.1. 基础容器（Pause/Infra 容器）

是 K8s 为每个 Pod 自动创建的 "资源支撑容器"，无需用户配置，作用是搭建 Pod 的资源环境（共享网络、存储等），是 Pod 内所有容器的 "底层底座"。

4.1.1核心作用

它的存在是为了让 Pod 内的业务容器能共享资源，主要做 3 件事：

创建并持有 Pod 的命名空间：包括网络、IPC、UTS 等命名空间（比如先分配 Pod 的 IP），后续业务容器直接 "加入" 这些命名空间，实现共享。
挂载 Pod 的存储卷：Pod 定义的存储卷会先挂载到基础容器，业务容器再继承这些挂载点，实现数据共享。
回收僵尸进程：作为 Pod 内 PID 为 1 的进程，自动清理业务容器退出后残留的无效进程，避免节点资源浪费。

4.1.2. 启动流程（和业务容器的关系）

当 K8s 创建一个 Pod 时：

先启动基础容器，初始化 Pod 的网络、存储等资源环境；
再启动 Pod 内的所有业务容器（应用、Sidecar 等），并让这些业务容器 "接入基础容器的资源环境"；
最终，所有业务容器共享基础容器的资源，形成一个统一的 Pod 单元。

4.1.3. 关键特点

无业务逻辑：它不运行任何业务代码，只做资源支撑；
资源消耗极低：镜像体积通常只有几 MB，运行时几乎不占 CPU / 内存；
用户无感知：用户操作的是 Pod 内的业务容器，基础容器由 K8s 自动管理。

4.2. 初始化容器（Init Container）

4.2.1、核心定义

是用户手动定义的 "前置任务容器" ，在 Pod 的业务容器（主容器）启动之前运行，专门用来完成初始化任务（比如拉取配置、等待依赖服务启动），任务完成后就自动退出。

4.2.2、核心作用

初始化容器的唯一目标是 "为业务容器准备好运行环境"，常见场景包括：

拉取 / 同步配置文件：从配置中心（比如 Nacos、ConfigMap）拉取业务容器需要的配置文件，写入共享存储卷，供业务容器使用；
等待依赖服务就绪：比如等待数据库、Redis 等中间件启动完成（避免业务容器启动后连不上依赖服务）；
初始化环境：创建业务容器需要的目录、修改文件权限、初始化数据库表结构等；
预处理数据：比如下载业务容器需要的静态资源、解密敏感文件等。

4.2.3、启动流程（和 Pod 内其他容器的顺序）

初始化容器的启动是严格按 "顺序前置" 来的，完整流程：

K8s 创建 Pod→先启动基础容器（Pause），搭建 Pod 的共享资源环境；
按用户定义的顺序启动初始化容器（如果有多个，必须前一个成功退出，才会启动下一个）；
所有初始化容器都成功退出（退出码为 0）；
启动 Pod 内的业务主容器（应用、Sidecar 等）。

4.2.4，Kubernetes 中Init 容器（初始化容器）的核心运行规则总结，其内容是对 Init 容器在 Pod 生命周期中行为逻辑的约束，以下是结构化解读及实践意义：

启动时序与执行要求

逻辑：Init 容器在 Pod 的网络、数据卷初始化完成后按定义顺序启动，且前一个容器必须成功退出，后一个才会启动。
实践意义：保证了前置初始化任务的有序性、依赖性（比如先拉取配置，再等待依赖服务），避免任务执行混乱。

失败重试逻辑

逻辑：Init 容器运行失败时，会按照 Pod 的restartPolicy策略重试；若restartPolicy为Always，失败后也会触发重试。
实践意义：需确保 Init 容器的任务是幂等的（重复执行不会产生异常结果，比如重复拉取配置不会覆盖正常文件）。

对 Pod 状态的影响

逻辑：所有 Init 容器未成功前，Pod 不会进入Ready状态；Init 容器的端口不会被 Service 聚合；此时 Pod 处于Pending状态，同时标记Initializing=true。
实践意义：Init 容器的执行进度直接影响 Pod 的服务可用性 ------ 未完成初始化的 Pod 不会被业务流量访问，避免了服务未就绪就接收请求的问题。

Pod 重启后的行为

逻辑：若 Pod 发生重启，所有 Init 容器会重新执行。
实践意义：Init 容器的任务需设计为 "可重复执行"（比如拉取配置时先检查文件是否存在，避免重复下载）。

配置修改限制

逻辑：仅 Init 容器的image字段修改会生效，修改其他字段无作用；修改image字段等价于重启 Pod。
实践意义：Init 容器的配置变更成本较高，需提前规划好初始化逻辑，避免频繁修改。

探针配置限制

逻辑：Init 容器不能定义readinessProbe（就绪探针），仅以 "执行完成" 作为唯一状态。
实践意义：Init 容器的状态仅通过 "退出码" 判断（0 为成功），无需额外配置就绪检测。

容器名称唯一性

逻辑：Pod 内的 Init 容器与业务容器（app 容器）名称必须唯一，重复会导致配置验证失败。
实践意义：配置 Pod 时需注意容器名称的唯一性，避免命名冲突导致 Pod 创建失败。

五，Pod 的镜像拉取策略（重点）

5.1. `Always`

行为逻辑 ：每次创建或重启 Pod 时，都会强制尝试从镜像仓库拉取最新镜像，无论本地节点是否已存在该镜像。
适用场景：需要始终使用最新版本镜像的场景（如开发环境的镜像频繁更新）。
特殊说明 ：当镜像标签为latest时，K8s 默认会将imagePullPolicy设为Always。

5.2. `IfNotPresent`

行为逻辑 ：仅当本地节点不存在该镜像时，才从仓库拉取；若本地已存在，则直接使用本地镜像。
适用场景：镜像版本稳定、无需频繁更新的生产环境（避免重复拉取镜像消耗网络资源）。
特殊说明 ：当镜像使用固定标签 （如nginx:1.25）时，K8s 默认会将imagePullPolicy设为IfNotPresent。

5.3. `Never`

行为逻辑 ：完全不与镜像仓库交互，仅使用本地节点已存在的镜像；若本地无该镜像，则 Pod 启动失败。
适用场景：离线环境（无法访问外部镜像仓库）、或需要严格使用本地指定版本镜像的测试场景。

5.4、关键注意事项

镜像标签的影响 ：
- 标签为latest时，默认策略是Always；
- 标签为固定版本（如v1.0.0）时，默认策略是IfNotPresent。
私有仓库的适配 ：若镜像位于私有仓库，需为 Pod 配置imagePullSecrets（存储仓库账号密码），否则拉取会失败。
镜像更新的限制 ：若使用IfNotPresent策略，本地镜像版本与仓库不一致时，Pod 不会自动更新镜像，需手动删除本地镜像或重启节点后重新拉取

5.5 Pod的重启策略

Pod 的重启策略（restartPolicy）是配置在 Pod spec中的规则，用于定义Pod 内容器终止后，节点 Kubelet 对容器的重启逻辑（注意：该策略仅作用于容器重启，而非 Pod 重建；Pod 重建需依赖 Deployment 等控制器）。其核心包含 3 种策略，具体说明如下：

核心策略类型

策略类型	行为逻辑	适用场景	典型控制器搭配
`Always`	无论容器以何种状态终止（正常 / 异常），Kubelet 都会持续重启容器（默认策略）	长期运行的服务类容器（如 Nginx、后端应用）	Deployment、ReplicaSet
`OnFailure`	仅当容器以非零退出码终止（异常崩溃）时重启；正常退出则不重启	批处理 / 任务类容器（如数据同步脚本）	Job、CronJob
`Never`	无论容器终止状态如何，均不重启容器	无需重试的一次性任务（如初始化脚本）	自主式 Pod、需人工介入的 Job

关键实践细节

重启延迟机制 ：Kubelet 重启容器采用指数退避策略：重启间隔从 10 秒开始，依次递增为 20 秒、40 秒，最大间隔 5 分钟；若容器稳定运行超 10 分钟，退避计时器会重置为初始值。
控制器的策略约束：
- 任务类控制器（Job/CronJob）不支持Always策略（避免任务完成后容器持续重启）；
- 服务类控制器（Deployment）通常要求restartPolicy为Always（保证服务持续可用）。
作用范围限制：重启策略仅重启当前 Pod 内的容器，若 Pod 所在节点故障，需依赖控制器在其他节点重建新 Pod。

六， Pod资源限制

在 Kubernetes 中，为了合理管理集群中的资源，容器的 CPU 和内存资源都可以设置请求值
（ requests ）和限制值（ limits ）。这些设置确保了容器的资源分配和限制，避免资源争用和过度使用。
资源请求与限制（ Request & Limit ）
请求（ request ）：当容器启动时， Kubernetes 会根据容器的资源请求来决定容器应该调度到哪
个节点上。这个值表示容器在运行时 最少需要 的资源。
限制（ limit ）：容器在运行时可以使用的最大资源量。如果容器超过了这个限制， Kubernetes 会
采取措施来控制容器的资源使用，防止过度消耗。

6.1、核心概念：Request vs Limit

Pod 的资源限制主要针对CPU 和内存（Memory） 两类核心资源，两者的作用和规则完全不同：

配置项	核心作用	单位说明
`resources.requests`	1. 调度依据：K8s 调度器会根据 request 值，把 Pod 调度到有足够空闲资源的节点；2. 资源保障：节点会为 Pod 预留至少 request 量的资源，优先满足 Pod 使用	CPU：核心数（1=1 核）、毫核（m，1000m=1 核）；内存：Mi（1Mi=1024×1024 字节）、Gi（1Gi=1024Mi）
`resources.limits`	运行时上限：Pod 运行中使用的资源不能超过limit 值，超限制会触发资源管控	CPU：同 request；内存：超 limit 会直接被内核终止容器

七，健康检查：又称为探针（Probe）

7.1 探针是由kubelet对容器执行的定期诊断。

7.2，三种探针的核心规则

7.2.1. 存活探针（livenessProbe）：检测容器 "是否存活"

核心作用 ：判断容器内的应用是否处于 "运行且正常" 状态（而非卡死 / 假死），若探测失败，Kubelet 会按 Pod 的restartPolicy重启容器。
触发逻辑：容器启动后，按配置的间隔持续探测；失败次数达到阈值→触发容器重启。
适用场景：解决应用 "进程存在但无法提供服务" 的问题（比如 Java 应用死锁、Nginx 卡死）。

7.2.2.就绪探针（readinessProbe）：检测容器 "是否就绪（能接收请求）"

核心作用：判断容器是否具备接收业务流量的能力，若探测失败，K8s 会将该 Pod 从对应 Service 的端点列表中移除（不再转发流量），直到探测恢复。
触发逻辑：容器启动后立即探测；失败→Pod 标记为 "未就绪"，移除流量；恢复→重新加入 Service 端点。
适用场景：避免给未准备好的 Pod 发请求（比如应用还在加载配置 / 初始化数据库连接）。

7.2.3，启动探针（startupProbe）：检测应用 "是否启动完成"

核心作用：适配启动慢的应用（比如大型 Java 应用、机器学习服务），避免存活探针在应用启动过程中误判 "未存活" 而重启容器。
触发逻辑：容器启动后开始探测；失败→按重启策略重启容器；成功→停止启动探针，转而启用存活 / 就绪探针。
关键特性：优先级最高，启动探针未成功前，存活 / 就绪探针不会生效。

小结

探测方式 ：除了httpGet，还支持exec（执行命令，比如exec: ["cat", "/tmp/healthy"]）、tcpSocket（检测端口是否通），按需选择。
参数配置 ：initialDelaySeconds（初始延迟）需匹配应用启动时间，避免探测过早导致误判。
优先级：启动探针 > 存活探针 > 就绪探针（启动探针未成功，后两者不生效）。
存活探针（livenessProbe）：管 "容器是否活"，失败→重启容器；
就绪探针（readinessProbe）：管 "容器是否能接请求"，失败→移除流量；
启动探针（startupProbe）：管 "应用是否启动完"，适配慢启动应用，避免存活探针误判。

结语

本文系统介绍了Pod从基础概念到实践配置的全量核心知识点，涵盖了Pod的本质定位、内部组成逻辑、资源共享特性，以及支撑Pod稳定运行的各类关键策略与探针机制。从基础容器Pause对Pod资源环境的支撑，到初始化容器对业务容器启动环境的前置保障；从镜像拉取、重启策略对容器生命周期的管控，到资源限制与QoS等级对节点资源分配的优化；再到三种探针对容器存活状态、就绪状态及启动过程的精准检测，这些知识点相互衔接、层层递进，共同构成了Pod运行与管理的完整逻辑体系。掌握本文所梳理的内容，能够帮助读者快速解决Pod部署与运维中的常见问题，合理配置Pod参数以适配不同业务场景需求。后续可基于本文基础，进一步深入学习K8s控制器（如Deployment、StatefulSet）对Pod的管理机制，以及Service、Ingress等服务发现与流量调度相关内容，实现对K8s容器编排体系的全面掌握。

前言

一，Pod****基础概念

1.1、核心定义

二，k8s中单容器 Pod、多容器 Pod 这两种核心使用方式

2.1、单容器 Pod（最主流的使用方式）

2.1.1，定义

2.1.2，典型场景

2.1.3，核心优势

2.1.4，适用场景

2.2，多容器 Pod（仅用于 "紧密耦合" 的场景）

2.2.1，定义

2.2.2，核心前提：什么是 "紧密耦合"？

2.2.3，核心优势

2.2.4，关键注意事项（踩坑点）

2.2.5适用场景

三， Pause 容器

3.1. 核心定位

3.2 主要作用

3.3. 启动流程

3.4. 特点

3.5，Pod****中的共享资源

3.5.1. 共享「网络命名空间」

3.5.2. 共享 存储卷（Volume）

3.5.3. 共享「IPC 命名空间」

3.5.4. 共享「UTS 命名空间」

**四，Pod****容器的分类：**基础容器与初始化容器

4.1. 基础容器（Pause/Infra 容器）

4.1.1核心作用

4.1.2. 启动流程（和业务容器的关系）

4.1.3. 关键特点

4.2. 初始化容器（Init Container）

4.2.1、核心定义

4.2.2、核心作用

4.2.3、启动流程（和 Pod 内其他容器的顺序）

4.2.4，Kubernetes 中Init 容器（初始化容器）的核心运行规则总结，其内容是对 Init 容器在 Pod 生命周期中行为逻辑的约束，以下是结构化解读及实践意义：

五 ，Pod 的镜像拉取策略（重点）

5.1. Always

5.2. IfNotPresent

5.3. Never

5.4、关键注意事项

5.5 Pod****的重启策略

六， Pod****资源限制

6.1、核心概念：Request vs Limit

七，健康检查：又称为探针（Probe）

7.1 探针是由kubelet对容器执行的定期诊断。

**7.2，**三种探针的核心规则

7.2.1. 存活探针（livenessProbe）：检测容器 "是否存活"

7.2.2.就绪探针（readinessProbe）：检测容器 "是否就绪（能接收请求）"

7.2.3，启动探针（startupProbe）：检测应用 "是否启动完成"

小结

结语

一，Pod基础概念

3.5，Pod中的共享资源

3.5.2. 共享存储卷（Volume）

四，Pod容器的分类：基础容器与初始化容器

五，Pod 的镜像拉取策略（重点）

5.1. `Always`

5.2. `IfNotPresent`

5.3. `Never`

5.5 Pod的重启策略

六， Pod资源限制

7.2，三种探针的核心规则