3-2-7、k8s学习-pod生命周期和重启策略

xuebo1129927648

126人浏览 · 2025-07-01 14:41:58

xuebo1129927648 · 2025-07-01 14:41:58 发布

1、K8s Pod 生命周期详解

一、Pod 生命周期概述

Pod 是 Kubernetes 中最小的调度单元，其生命周期由 Kubernetes 控制平面管理，主要包括以下阶段：

Pending（挂起）：Pod 已创建但尚未就绪
Running（运行中）：所有容器已启动且至少一个容器正在运行
Succeeded（成功）：所有容器已终止且成功退出
Failed（失败）：所有容器已终止但至少一个容器失败退出
Unknown（未知）：无法获取 Pod 状态

二、Pod 生命周期详细阶段解析

1. Pending 阶段

当用户创建 Pod 后，首先进入 Pending 状态，此时 Kubernetes 执行以下操作：

调度决策：调度器（Scheduler）根据资源需求、节点亲和性等规则选择合适节点。
示例：若 Pod 要求 GPU 资源，调度器仅会选择有 GPU 的节点。
容器创建准备：节点上的 kubelet 接收 Pod 创建请求，开始拉取镜像、分配资源。
可能阻塞原因：镜像拉取超时、节点资源不足、网络配置错误。

2. Running 阶段

Pod 被调度到节点后，进入 Running 状态，执行流程如下：

初始化容器（Init Containers）执行：
- 初始化容器按顺序运行，每个容器必须成功退出后才会启动主容器。
- 用途：预处理数据、等待依赖服务（如等待数据库启动）。
yaml
```
# 示例：初始化容器等待数据库就绪
initContainers:
- name: wait-for-db
  image: busybox
  command: ['sh', '-c', 'until nc -z db-service 3306; do sleep 1; done']
```
主容器（Main Containers）启动：
- 主容器启动后，Kubernetes 开始执行健康检查（探针）。
探针（Probes）机制：
- Liveness Probe（存活探针）：检测容器是否存活，失败时重启容器。
- Readiness Probe（就绪探针）：检测容器是否准备好接收流量，失败时从服务端点移除。
yaml
```
# 示例：HTTP存活探针
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
```

3. 状态转换：Succeeded/Failed

Succeeded：
- 所有主容器正常终止（退出码 0），Pod 不再重启（根据重启策略）。
Failed：
- 主容器以非零状态退出，或被系统终止（如 OOM Kill）。

4. Unknown 状态

原因：节点通信失败、kubelet 异常，无法获取 Pod 最新状态。

三、Pod 终止流程（优雅关闭）

当删除 Pod 或节点故障时，Kubernetes 执行优雅终止：

发送 SIGTERM 信号：默认等待 30 秒（terminationGracePeriodSeconds可配置）。
容器处理退出逻辑：如保存数据、关闭连接。
强制终止：若超时未结束，发送 SIGKILL 信号。

yaml

# 示例：配置优雅终止时间
apiVersion: v1
kind: Pod
metadata:
  name: gracefully-shutdown
spec:
  terminationGracePeriodSeconds: 60
  containers:
  - name: app
    image: nginx

四、Pod 重启策略（Restart Policy）

决定 Pod 内容器失败时的重启行为，定义在 Pod.spec 中：

Always（默认）：容器失败时始终重启。
OnFailure：仅当容器异常退出时重启。
Never：不重启容器。

五、查看 Pod 生命周期状态

通过命令行工具监控 Pod 状态：

bash

# 查看Pod当前状态
kubectl get pods <pod-name> -o wide

# 查看Pod详细事件（排查问题）
kubectl describe pod <pod-name>

# 查看容器日志（主容器/初始化容器）
kubectl logs <pod-name>              # 主容器
kubectl logs <pod-name> -c init-container  # 初始化容器

六、常见问题与最佳实践

Pending 状态排查：
- 检查调度失败原因：kubectl describe pod查看Events中的调度错误。
- 确认节点资源：kubectl top node检查 CPU / 内存是否充足。
初始化容器阻塞：
- 确保初始化容器逻辑无死循环（如等待超时设置）。
健康检查优化：
- 对启动慢的应用增加initialDelaySeconds，避免误判。

通过理解 Pod 的生命周期，可更高效地管理 Kubernetes 应用，解决部署、调度和故障排查中的问题。

2、Init容器和pause容器详解

Init 容器与 Pause 容器深度解析

一、Init 容器（Init Containers）详解

1. 核心定义与特性

Init 容器是 Pod 中特殊的初始化容器，在主容器启动前按顺序执行，具备以下特点：

执行顺序性：多个 Init 容器按定义顺序依次运行，前一个成功后才会启动下一个。
资源隔离性：每个 Init 容器拥有独立的资源配置（CPU / 内存）。
生命周期独立性：Init 容器完成任务后即终止，不会持续运行。

2. 核心用途与场景

Init 容器主要解决主容器启动前的依赖问题，典型场景包括：

环境预处理：创建数据目录、生成配置文件。
服务依赖等待：等待数据库、缓存服务就绪。
权限 / 安全校验：验证访问凭证、初始化安全上下文。
多环境适配：根据不同环境注入差异化配置。

3. 与主容器的关键区别

维度	Init 容器	主容器（Main Containers）
执行时机	主容器启动前	Init 容器全部成功后启动
重启策略	不支持重启（失败则 Pod 失败）	按 Pod.spec.restartPolicy 配置
持续运行	仅执行一次即终止	持续运行或按规则重启
资源共享	不与主容器共享文件系统	共享 Pod 的 Volume 和网络命名空间

4. 实战配置示例

yaml

apiVersion: v1
kind: Pod
metadata:
  name: init-container-demo
spec:
  containers:
  - name: app
    image: nginx:latest
    ports:
    - containerPort: 80
  initContainers:
  - name: create-dir
    image: busybox
    command: ['sh', '-c', 'mkdir -p /data/app && chmod 777 /data/app']
    volumeMounts:
    - name: data-volume
      mountPath: /data
  - name: wait-for-db
    image: busybox
    command: ['sh', '-c', 'until nc -z mysql-service 3306; do sleep 1; done']
  volumes:
  - name: data-volume
    emptyDir: {}

5. 最佳实践与注意事项

避免长耗时操作：Init 容器阻塞会导致 Pod 无法启动，建议设置超时机制。
错误处理：Init 容器失败会导致 Pod 进入 Failed 状态，需确保逻辑健壮。
资源限制：为 Init 容器设置合理的资源配额，避免抢占主容器资源。

二、Pause 容器（基础容器）详解

1. 本质与核心作用

Pause 容器是每个 Pod 的 “基础容器”，由 Kubernetes 自动注入，其核心功能包括：

命名空间共享：创建并维护 Pod 的网络、UTS、IPC 命名空间，使主容器共享同一网络栈。
PID 命名空间管理：作为 Pod 的 PID 1 进程，管理容器进程生命周期（如僵尸进程回收）。
资源隔离基础：为 Pod 提供统一的 Linux 命名空间边界，实现容器间资源共享。

2. 技术实现细节

镜像与代码：
常用镜像为k8s.gcr.io/pause（或registry.k8s.io/pause），本质是一个轻量级二进制程序，主要功能为：

// pause容器核心逻辑简化示例
int main() {
  // 创建并共享命名空间
  create_namespaces();
  // 进入暂停状态，等待信号
  for(;;) sleep(1000);
}

资源占用：
Pause 容器资源消耗极低（内存约 5MB，CPU 几乎为 0），仅运行必要的内核线程。

3. Pause 容器与 Pod 的关系

网络共享机制：
所有主容器通过docker container join命令加入 Pause 容器的网络命名空间，实现：
- 共享 IP 地址和端口空间
- 共享网络设备（如 eth0）
- 共享路由表和 DNS 配置
存储共享基础：
Pause 容器与主容器共享 Pod 定义的 Volume，通过 VolumeMount 挂载到各容器文件系统。

4. 为什么 Pod 需要 Pause 容器？

Kubernetes 设计哲学：
Pod 作为 “逻辑主机”，需确保内部容器在同一网络和存储环境中运行，Pause 容器提供了这一基础架构。
兼容性与标准化：
屏蔽不同容器运行时（Docker、Containerd）的差异，统一 Pod 的资源隔离模型。

5. 查看 Pause 容器的方法

bash

# 通过Docker命令查看Pod中的Pause容器（假设Pod在节点node1上）
# 1. 获取Pod的Pause容器ID
POD_NAME="your-pod-name"
NODE_NAME="node1"
CONTAINER_ID=$(kubectl get pod $POD_NAME -n default -o jsonpath='{.status.containerStatuses[0].containerID}' | cut -d '/' -f 2)

# 2. 查看Pause容器详情
docker inspect $CONTAINER_ID | grep "Image"  # 查看镜像
docker top $CONTAINER_ID                    # 查看进程

三、Init 容器与 Pause 容器的协同工作机制

Pod 创建流程：

图片

代码

graph TD
A[创建Pod] --> B[调度到节点]
B --> C[启动Pause容器]
C --> D[启动Init容器1]
D --> E[启动Init容器2]
E --> F[启动主容器]

关键交互点：
- Pause 容器先于所有 Init 容器启动，创建命名空间环境。
- Init 容器在 Pause 容器的命名空间中执行，可直接访问主容器的网络和存储资源。

四、常见问题与深度理解

1. 为什么 Init 容器失败会导致 Pod 无法启动？

Init 容器设计为 “前置条件检查”，若失败则认为 Pod 不满足运行条件，避免启动后因依赖缺失导致故障。

2. 能否删除 Pod 中的 Pause 容器？

不能。Pause 容器是 Kubernetes 架构的核心组件，删除会导致 Pod 网络和资源共享机制失效。

3. Init 容器如何传递数据给主容器？

通过共享 Volume 实现：Init 容器写入 Volume 的数据，主容器可直接读取（如配置文件、预处理数据）。

通过深入理解 Init 容器与 Pause 容器的设计原理，可更清晰地掌握 Kubernetes Pod 的运行机制，在应用部署、复杂依赖管理和故障排查中更高效地解决问题。

4.pod重启时，init容器会重启吗？还是只重启主容器？

Pod 重启时 Init 容器的行为解析

一、Pod 重启场景与 Init 容器的执行规则

Pod 重启时 Init 容器的行为取决于重启触发原因和Kubernetes 的设计机制，核心逻辑如下：

二、不同重启场景下 Init 容器的表现

1. 因 Pod 重启策略（restartPolicy）触发的重启

场景描述：主容器因故障退出，Pod 按restartPolicy配置自动重启。
Init 容器行为：不重启。
- 原因：Init 容器的设计目标是 “Pod 初始化”，仅在 Pod 首次创建时执行，后续重启时跳过。
- 示例：若主容器因 OOM 退出，Pod 重启时直接启动主容器，不再运行 Init 容器。

2. 因 Pod 重建触发的重启

场景描述：
- 用户主动删除 Pod 后重新创建；
- 节点故障导致 Pod 漂移到其他节点重建；
- 修改 Pod 配置（如镜像版本）触发重建。
Init 容器行为：重新执行。
- 原因：Pod 重建相当于全新创建，初始化流程重新开始，所有 Init 容器按顺序执行。

三、Init 容器的 “一次性” 特性本质

Init 容器的设计遵循 “前置条件初始化” 原则：

仅在 Pod 生命周期开始时执行：用于准备环境、校验依赖等一次性任务。
不参与主容器的循环重启：避免重复执行耗时操作（如重复创建已存在的目录、重复等待服务）。

四、实战验证：Init 容器在重启时的行为

yaml

# 测试用Pod配置（包含Init容器）
apiVersion: v1
kind: Pod
metadata:
  name: init-restart-test
spec:
  restartPolicy: Always  # 主容器失败时自动重启
  containers:
  - name: app
    image: busybox
    command: ["sh", "-c", "echo '主容器启动' && sleep 3600"]
  initContainers:
  - name: log-init-time
    image: busybox
    command: ["sh", "-c", "date > /data/init-time.txt && echo 'Init容器执行时间：' $(date)"]
    volumeMounts:
    - name: data-volume
      mountPath: /data
  volumes:
  - name: data-volume
    emptyDir: {}

验证步骤

首次创建 Pod：
- Init 容器执行，在/data/init-time.txt中写入时间。

手动终止主容器：

bash

kubectl exec init-restart-test -- kill 1  # 终止主容器进程

观察重启行为：
- 主容器重启，但 Init 容器不执行，init-time.txt内容不变。
删除 Pod 并重建：
bash
```
kubectl delete pod init-restart-test
kubectl apply -f pod.yaml
```
Init 容器重新执行，init-time.txt时间更新。

五、核心结论与实践建议

Init 容器仅在 Pod 首次创建或重建时执行，主容器因重启策略触发的常规重启不会触发 Init 容器。
若需在每次 Pod 重启时执行初始化逻辑，可将任务移至主容器的启动脚本中（如通过preStop和postStart钩子配合实现）。
注意数据持久化：若 Init 容器生成的数据需在 Pod 重建后保留，需使用持久化 Volume（如 PVC）而非临时存储。

通过理解 Init 容器的生命周期特性，可更合理地设计 Pod 初始化逻辑，避免因重启机制导致的意外行为。

3、Pod 容器重启策略详解

一、重启策略的核心定义

Pod 的重启策略（restartPolicy）决定了容器终止后（正常退出或异常退出）Pod 的行为。该策略仅作用于主容器（Main Containers），对 Init 容器无效（Init 容器失败会导致 Pod 整体失败）。

重启策略定义在 Pod 的.spec.restartPolicy字段中，支持以下三种取值：

Always（默认）
OnFailure
Never

二、三种重启策略的行为对比

1. Always（始终重启）

行为：无论容器以何种方式终止（正常退出或异常退出），Kubernetes 都会自动重启容器。
适用场景：
- 长期运行的服务（如 Web 服务器、数据库）。
- 需要保持高可用性的应用。

示例配置：

yaml

apiVersion: v1
kind: Pod
spec:
  restartPolicy: Always
  containers:
  - name: nginx
    image: nginx

2. OnFailure（仅失败时重启）

行为：仅当容器以非零状态码（异常）退出时重启，正常退出（状态码 0）不重启。
适用场景：
- 批处理作业（如数据导入、定时任务）。
- 执行完即退出的一次性任务。

示例配置：

yaml

apiVersion: v1
kind: Pod
spec:
  restartPolicy: OnFailure
  containers:
  - name: batch-job
    image: my-batch-processor
    command: ["/app/process.sh"]

3. Never（从不重启）

行为：容器终止后，无论状态码如何，均不重启。Pod 状态直接转为Succeeded或Failed。
适用场景：
- 一次性执行的任务（如初始化脚本、CI/CD 构建）。
- 依赖外部系统监控和重启的应用。

示例配置：

yaml

apiVersion: v1
kind: Pod
spec:
  restartPolicy: Never
  containers:
  - name: init-script
    image: alpine
    command: ["sh", "-c", "echo '执行初始化'"]

三、重启策略与 Pod 状态的关系

重启策略直接影响 Pod 的最终状态：

重启策略	容器正常退出（状态码 0）	容器异常退出（非零状态码）
Always	重启容器，Pod 保持`Running`	重启容器，Pod 保持`Running`
OnFailure	Pod 状态变为`Succeeded`	重启容器，Pod 保持`Running`
Never	Pod 状态变为`Succeeded`	Pod 状态变为`Failed`

四、重启策略与控制器的协作

在实际使用中，重启策略常与 Kubernetes 控制器（如 Deployment、Job）配合：

Deployment/StatefulSet：
- 强制使用restartPolicy: Always，确保 Pod 始终运行。
- 控制器通过 ReplicaSet 管理 Pod 副本数，重启策略用于处理单个容器故障。
Job/CronJob：
- 通常使用restartPolicy: OnFailure或Never，配合控制器的completions和backoffLimit参数控制重试次数。

五、高级特性：重启延迟与指数退避

当容器需要重启时，Kubernetes 采用指数退避算法（Exponential Backoff）避免频繁重启：

初始延迟：首次重启延迟10秒。
最大延迟：每次失败后延迟时间翻倍，最大延迟5分钟。
重置条件：容器成功运行 10 分钟后，延迟计数器重置为初始值。

该机制可防止故障容器耗尽系统资源，同时给予足够的重试机会。

六、实战场景与最佳实践

1. 长期运行服务

yaml

# Deployment自动设置restartPolicy=Always
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: api-server
        image: my-api:v1

2. 批处理作业

yaml

# Job配置示例
apiVersion: batch/v1
kind: Job
spec:
  backoffLimit: 4  # 最多重试4次
  template:
    spec:
      restartPolicy: OnFailure
      containers:
      - name: data-processor
        image: data-processor:v1

3. 容器健康检查与重启策略结合

yaml

apiVersion: v1
kind: Pod
spec:
  restartPolicy: Always
  containers:
  - name: app
    image: my-app
    livenessProbe:  # 存活探针失败会触发容器重启
      httpGet:
        path: /health
        port: 8080

七、常见问题排查

Pod 持续重启（CrashLoopBackOff）：
- 检查容器退出状态码（kubectl describe pod）。
- 排查应用程序错误日志（kubectl logs）。
Job 未按预期重试：
- 确认restartPolicy为OnFailure且backoffLimit设置合理。
Deployment 中 Pod 频繁重建：
- 检查容器是否存在内存泄漏或启动失败问题，导致重启策略触发重建。

通过合理配置重启策略，可有效管理容器的生命周期，提升应用的可用性和可靠性。

开源鸿蒙跨平台开发者社区

开源鸿蒙跨平台开发社区汇聚开发者与厂商，共建“一次开发，多端部署”的开源生态，致力于降低跨端开发门槛，推动万物智联创新。

更多推荐

react navite调试方案：Flipper、远程调试

开源鸿蒙跨平台开发者社区

刷机全流程SD-eMMC-单分区—【万物智能之开源鸿蒙OpenHarmony系统实战开发系列教程】

开源鸿蒙跨平台开发者社区

开启RN之旅——React基础

文件格式: 后缀名为.json的纯JSON格式文件，包含大括号包裹的多个字段定义核心作用: 管理React Native工程的所有配置和依赖关系name: 应用名称，如示例中的"demo"version: 应用版本号，格式为"主版本.次版本.修订号"，如"0.0.1"private: 布尔值，设为true可防止工程被意外发布到npm仓库注意: 当设置为true时，执行npm publish会报错s

开源鸿蒙跨平台开发者社区

所有评论(0)

查看更多评论

xuebo1129927648

@xuebo1129927648

已为社区贡献4条内容

3-2-7、k8s学习-pod生命周期和重启策略

xuebo1129927648

1、K8s Pod 生命周期详解

一、Pod 生命周期概述

二、Pod 生命周期详细阶段解析

1. Pending 阶段

2. Running 阶段

3. 状态转换：Succeeded/Failed

4. Unknown 状态

三、Pod 终止流程（优雅关闭）

四、Pod 重启策略（Restart Policy）

五、查看 Pod 生命周期状态

六、常见问题与最佳实践

2、Init容器和pause容器详解

Init 容器与 Pause 容器深度解析

一、Init 容器（Init Containers）详解

1. 核心定义与特性

2. 核心用途与场景

3. 与主容器的关键区别

4. 实战配置示例

5. 最佳实践与注意事项

二、Pause 容器（基础容器）详解

1. 本质与核心作用

2. 技术实现细节

3. Pause 容器与 Pod 的关系

4. 为什么 Pod 需要 Pause 容器？

5. 查看 Pause 容器的方法

三、Init 容器与 Pause 容器的协同工作机制

四、常见问题与深度理解

1. 为什么 Init 容器失败会导致 Pod 无法启动？

2. 能否删除 Pod 中的 Pause 容器？

3. Init 容器如何传递数据给主容器？

4.pod重启时，init容器会重启吗？还是只重启主容器？

Pod 重启时 Init 容器的行为解析

一、Pod 重启场景与 Init 容器的执行规则

二、不同重启场景下 Init 容器的表现

1. 因 Pod 重启策略（restartPolicy）触发的重启

2. 因 Pod 重建触发的重启

三、Init 容器的 “一次性” 特性本质

四、实战验证：Init 容器在重启时的行为

验证步骤

五、核心结论与实践建议

3、Pod 容器重启策略详解

一、重启策略的核心定义

二、三种重启策略的行为对比

1. Always（始终重启）

2. OnFailure（仅失败时重启）

3. Never（从不重启）

三、重启策略与 Pod 状态的关系

四、重启策略与控制器的协作

五、高级特性：重启延迟与指数退避

六、实战场景与最佳实践

1. 长期运行服务

2. 批处理作业

3. 容器健康检查与重启策略结合

七、常见问题排查

所有评论(0)

温馨提示：您尚未绑定手机号

xuebo1129927648