一、initc、mainc、探针、钩子理论组件什么时候干干不好会怎样是否持续运行InitC初始化容器主容器启动前串行执行Pod卡住主容器永远不启动❌ 干完就退MainC主容器InitC 全部成功后启动崩溃了就被重启✅ 必须常驻PostStart钩子MainC刚启动时执行MainC直接被杀启动失败❌ 只执行一次PreStop钩子MainC被删除前执行阻塞删除直至执行完毕❌ 只执行一次startupProbe启动探针MainC 启动初期失败则触发liveness 重启✅ 启动成功后停用readinessProbe就绪探针MainC运行时持续检查踢出 Service不杀容器✅ 持续检测livenessProbe存活探针MainC运行时持续检查杀死容器并重启✅ 持续检测二、initc代码举例apiVersion: v1 # API 版本 kind: Pod # 资源类型 metadata: # 元数据 name: initc-1 # Pod 名称 labels: # 标签 app: initc # 标签键值对 spec: # 规格定义 #这个是mainc主容器列表 containers: # 主容器列表 - name: myapp-container # 主容器名称 image: wangyanglinux/tools:busybox # 镜像地址 command: [sh, -c, echo The app is running! sleep 3600] # 启动命令输出信息并睡眠1小时 #这个initContainers是就是initc初始化容器列表 initContainers: # 初始化容器列表串行执行 - name: init-myservice # 第一个初始化容器检查 myservice image: wangyanglinux/tools:busybox # 镜像地址 command: [sh, -c, until nslookup myservice; do echo waiting for myservice; sleep 2; done;] # 轮询解析 myservice 直到成功 - name: init-mydb # 第二个初始化容器检查 mydb image: wangyanglinux/tools:busybox # 镜像地址 command: [sh, -c, until nslookup mydb; do echo waiting for mydb; sleep 2; done;] # 轮询解析 mydb 直到成功特性维度核心说明大白话解释对应示例/影响1. 执行顺序严格串行执行按定义顺序一个接一个运行绝不并行。第1个InitC不干完退出第2个连动都不动。你YAML里init-myservice必须先成功退出init-mydb才能启动。2. 生命周期一次性任务必须主动退出Exit 0不能是常驻进程。“临时工”干完活就立刻下班绝不赖在办公室里。里面不能写sleep 3600或while true否则主容器永远进不来。3. 失败阻断任意InitC失败非0退出码主容器不创建Pod卡在Init:Error。“一票否决制”——后台没把食材备好大厨连厨房门都摸不着。如果nslookup myservice永远失败myapp-container永远不会启动。4. 健康检查不支持探针liveness/readiness和钩子PostStart/PreStop只看退出码0成功。老师不看你过程只看你最终交没交卷卷面分是不是0分。无法用livenessProbe监控它成功与否全看nslookup返回0还是非0。5. 资源调度调度时取所有InitC资源请求最大值与所有MainC资源总和的较大者。哪怕InitC只疯跑几秒钟也得按它的“峰值饭量”给分配个大桌子。InitC若请求2G内存MainC只请求1G调度器会按2G找节点。6. 重启策略无独立策略完全继承Pod的restartPolicyAlways/Never/OnFailure。小跟班没有话语权老大Pod让重试就重试让放弃就放弃。Pod设restartPolicy: NeverInitC失败了就直接躺平不再重试。三、mainc特性特性维度核心说明大白话解释对应示例/影响1. 执行方式并行启动。同一个 Pod 内的多个 MainC 同时启动无先后顺序。厨房里的多个大厨同时开火炒菜谁也不等谁。你的myapp-1和busybox-1同时抢 80 端口导致bind 98错误。2. 生命周期常驻进程长跑选手。必须持续运行不能主动退出除非被杀死或崩了。正式员工每天必须待在工位上不能干完活就走。命令必须写成sleep 3600或启动 Web 服务如果写成echo hello执行完就退容器会立即 Crash。3. 启动条件必须等所有 InitC 全部成功退出才会被允许创建和启动。后勤InitC不把食材备好大厨MainC连厨房门都摸不着。你的 YAML 中myapp-container必须等init-myservice和init-mydb都成功退出才启动。4. 健康检查完全支持探针liveness/readiness/startup和钩子PostStart/PreStop。配备专职保镖探针和门禁系统钩子随时监控和干预。livenessProbe失败了直接杀掉容器readiness失败了踢出流量PostStart失败则容器起不来。5. 资源计算累加求和。调度器计算节点资源时将所有 MainC 的 Requests/Limits 直接相加。多个大厨的饭量累加算总账厨房必须能同时管饱所有人。MainC-1 要 1G 内存MainC-2 要 1G调度器就按2G去找节点而 InitC 是取最大值。6. 重启策略崩溃立即重启除非 Pod 的restartPolicy: Never。容器退出无论成功或失败都会触发立即重建。大厨晕倒了崩溃立马抬走换一个新大厨上来且不耽误出菜。进程崩溃退出码非 0Kubelet 马上重启不同于 InitC失败会卡住重试而这里是直接重启进程。7. 命名空间共享补充分类共享网络、IPC、UTS 命名空间PID 默认不共享需手动开启。几个大厨共用一个灶台IP和一口锅IPC但各自有自己的工牌号PID。共享网络 端口冲突你的bind 98共享 IPC 能用共享内存通信PID 默认隔离 ps看不到对方进程。四、探针4.1就绪探测readinessProbe1. HTTP GET 就绪探针readiness-httpget-pod容器启动后kubelet 每 3 秒向http://PodIP:80/index1.html发送 GET 请求。若返回状态码在 200~399 之间则标记为就绪否则未就绪。由于镜像中可能没有/index1.html该探针通常失败Pod 将一直处于READY 0/1状态。apiVersion: v1 kind: Pod metadata: name: readiness-httpget-pod # Pod 名称 namespace: default # 所属命名空间 labels: # 自定义标签便于选择 app: myapp env: test spec:#期望 containers: - name: readiness-httpget-container # 容器名称 image: wangyanglinux/myapp:v1.0 # 容器镜像内部运行一个简单 Web 服务 imagePullPolicy: IfNotPresent # 本地有镜像则优先使用否则拉取 readinessProbe: # 就绪探针定义 httpGet: # 探针类型HTTP GET 请求 port: 80 # 目标端口 path: /index1.html # 请求路径如果有这个文件探针探到会成功。这里我设置一个不存在的文件用于演示就绪检查失败的情况 initialDelaySeconds: 1 # 容器启动后等待 1 秒再开始探测 periodSeconds: 3 # 每隔 3 秒探测一次2. 命令执行Exec就绪探针readiness-exec-pod容器启动后立即创建/tmp/live因此前 60 秒内test -e /tmp/live返回 0成功Pod 为就绪状态。60 秒后文件被删除探测命令返回非 0失败Pod 变为未就绪。该示例演示了探针随时间动态变化的效果。apiVersion: v1 kind: Pod metadata: name: readiness-exec-pod # Pod 名称 namespace: default # 默认命名空间 spec: containers: - name: readiness-exec-container # 容器名称 image: wangyanglinux/tools:busybox # 基于 busybox 的工具镜像 imagePullPolicy: IfNotPresent # 本地优先 command: # 容器启动命令多行写法 - /bin/sh - -c - | touch /tmp/live # 启动时创建 /tmp/live 文件 sleep 60 # 等待 60 秒 rm -rf /tmp/live # 60 秒后删除该文件 sleep 3600 # 保持容器运行 1 小时便于观察后续状态 readinessProbe: # 就绪探针 exec: # 探针类型执行命令 command: # 执行的命令列表 - test # test 命令 - -e # -e 选项检查文件是否存在 - /tmp/live # 检查目标文件结果肯定先探测到60s后就探测不到了pod就失败了 initialDelaySeconds: 1 # 启动后 1 秒开始探测 periodSeconds: 3 # 每 3 秒探测一次3.TCP Socket 就绪探针readiness-tcp-podkubelet 尝试与容器的 80 端口建立 TCP 连接。如果连接成功表示服务已在监听则认为就绪若连接失败端口未开放或拒绝连接则未就绪。该探针适合检查服务是否已启动并绑定了指定端口。apiVersion: v1 kind: Pod metadata: name: readiness-tcp-pod # Pod 名称 spec: containers: - name: readiness-exec-container # 容器名称注意此处名称与 exec 示例相同实际可随意 image: wangyanglinux/myapp:v1.0 # 镜像包含 Web 服务监听 80 端口 readinessProbe: # 就绪探针 initialDelaySeconds: 5 # 启动后等待 5 秒再开始探测 timeoutSeconds: 1 # 每次探测超时时间秒连接超时即视为失败 tcpSocket: # 探针类型TCP 连接检查 port: 80 # 目标端口4.2存活探测livenessProbe1. 基于 Exec 方式的存活探针liveness-exec-pod容器启动后立即创建/tmp/live因此前 60 秒内test -e /tmp/live返回 0成功Pod 被视为存活。60 秒后文件被删除探测命令返回非 0失败kubelet 将根据restartPolicy默认为 Always重启容器。该示例演示了存活探针如何检测应用内部状态如临时文件并触发容器重启。apiVersion: v1 kind: Pod metadata: name: liveness-exec-pod # Pod 名称 namespace: default # 默认命名空间 spec: containers: - name: liveness-exec-container # 容器名称 image: wangyanglinux/tools:busybox # 基于 busybox 的工具镜像 imagePullPolicy: IfNotPresent # 本地有镜像则使用否则拉取 command: # 容器启动命令 - /bin/sh - -c - | touch /tmp/live # 启动时创建 /tmp/live 文件 sleep 60 # 等待 60 秒 rm -rf /tmp/live # 60 秒后删除该文件 sleep 3600 # 保持容器运行 1 小时便于观察后续行为 livenessProbe: # 存活探针定义 exec: # 探针类型执行命令 command: # 执行的命令列表 - test # test 命令检查文件是否存在 - -e # -e 选项 - /tmp/live # 目标文件路径 initialDelaySeconds: 1 # 容器启动后等待 1 秒再开始探测 periodSeconds: 3 # 每隔 3 秒探测一次2.基于 HTTP GET 方式的存活探针liveness-httpget-podkubelet 每隔 3 秒向http://PodIP:80/index.html发送 GET 请求。如果返回的 HTTP 状态码在 200~399 之间则视为存活否则视为失败。若连续失败次数达到阈值默认由failureThreshold控制默认为 3容器将被重启。该探针适合检查 Web 服务是否正常响应。apiVersion: v1 kind: Pod metadata: name: liveness-httpget-pod # Pod 名称 namespace: default # 默认命名空间 spec: containers: - name: liveness-httpget-container # 容器名称 image: wangyanglinux/myapp:v1.0 # 镜像包含一个 Web 服务监听 80 端口 imagePullPolicy: IfNotPresent ports: # 声明容器端口便于阅读非强制 - name: http containerPort: 80 # 实际监听端口 livenessProbe: # 存活探针 httpGet: # 探针类型HTTP GET 请求 port: 80 # 目标端口 path: /index.html # 请求路径镜像中通常存在该文件探测成功 initialDelaySeconds: 1 # 启动后 1 秒开始探测 periodSeconds: 3 # 每 3 秒探测一次 timeoutSeconds: 3 # 超时时间秒超时视为失败3.基于 TCP Socket 方式的存活探针liveness-tcp-podkubelet 尝试与容器的 80 端口建立 TCP 连接。如果连接成功则认为容器存活否则失败。该探针适用于检查服务是否已启动并绑定端口但不关心具体业务逻辑如 HTTP 响应状态。适用于数据库、缓存等 TCP 服务。apiVersion: v1 kind: Pod metadata: name: liveness-tcp-pod # Pod 名称 spec: containers: - name: liveness-tcp-container # 容器名称 image: wangyanglinux/myapp:v1.0 # 镜像中的服务监听 80 端口 livenessProbe: # 存活探针 initialDelaySeconds: 5 # 启动后等待 5 秒再开始探测 timeoutSeconds: 1 # 连接超时时间秒超时视为失败 tcpSocket: # 探针类型TCP 连接检查 port: 80 # 目标端口总结存活探测如果发现pod异常或者说死了并且你设置了自动重启会创建一个新的pod。4.3启动探测startupProbeapiVersion: v1 kind: Pod metadata: name: startupprobe-1 # Pod 名称 namespace: default # 命名空间 spec: containers: - name: myapp-container # 容器名称 image: wangyanglinux/myapp:v1.0 # 镜像包含 Web 服务监听 80 端口 imagePullPolicy: IfNotPresent # 本地优先 ports: # 声明容器端口便于阅读 - name: http containerPort: 80 # 实际监听端口 readinessProbe: # 就绪探针检查业务是否就绪 httpGet: port: 80 path: /index2.html # 注意此路径可能不存在用于演示失败 initialDelaySeconds: 1 # 启动后 1 秒开始探测 periodSeconds: 3 # 每 3 秒探测一次 startupProbe: # 启动探针延迟其他探针直到启动成功 httpGet: path: /index1.html # 启动期间检查 /index1.html 是否存在 port: 80 failureThreshold: 30 # 允许连续失败 30 次 periodSeconds: 10 # 每 10 秒探测一次总结只有启动探测启动就绪探测才可以启动。五、钩子Podhook钩子是由Kubernetes管理的kubelet发起的当容器中的进程启动前或者容器中的进程终止之前运行这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hook。Hook的类型包括两种exec:执行一段命令HTTP发送HTTP请求钩子类型postStart 钩子在容器启动后但入口进程启动前立即执行启动后钩子preStop 钩子在容器被终止前执行启动前钩子5.1exec类型作用在容器的内部文件系统中直接执行一段指定的命令或脚本。# 指定 Kubernetes API 版本v1 表示核心稳定版本 apiVersion: v1 # 声明要创建的资源类型为 Pod kind: Pod # 元数据部分定义 Pod 的名称等属性 metadata: # Pod 的名称用于在命名空间中唯一标识 name: lifecycle-exec-pod # 规格部分定义 Pod 的具体运行配置 spec: # 定义 Pod 包含的容器列表 containers: # 第一个容器的配置 - name: lifecycle-exec-container # 使用的基础镜像注意此镜像可能已下架如拉取失败可换成 nginx:latest image: wangyanglinux/myapp:v1.0 # 生命周期钩子配置 lifecycle: # postStart 钩子在容器启动后但入口进程启动前立即执行 # 适用于初始化操作如配置加载、环境准备 postStart: # 执行命令的方式 exec: # 要执行的命令使用 /bin/sh 执行 shell 脚本 # 将 postStart 字符串写入 /usr/share/message 文件 command: [/bin/sh, -c, echo postStart /usr/share/message] # preStop 钩子在容器被终止前执行 # 适用于优雅关闭如保存状态、通知其他服务、清理连接 preStop: exec: # 将 preStop 字符串写入 /usr/share/message 文件 command: [/bin/sh, -c, echo preStop /usr/share/message]这个结果就是你生成容器会往/usr/share/message里写内容当你删除容器容器删除前还是会往/usr/share/message里重定向内容。5.2http类型作用Kubernetes 的 kubelet 进程从容器外部宿主机网络层面向容器内监听的 HTTP/HTTPS 端口发送一个 GET 请求。第一步启动一个你nginx容器 [rootk8s-master01 xuexi]# docker run -it --rm -p 1234:80 wangyanglinux/myapp:v1.0 Unable to find image wangyanglinux/myapp:v1.0 locally v1.0: Pulling from wangyanglinux/myapp 10f623ae1ff6: Pull complete 87f35c454b8f: Pull complete 9398808236ff: Pull complete 10840918b3c8: Pull complete 03ce7c584195: Pull complete 95045127ee09: Pull complete 3f34dbc1d74e: Pull complete Digest: sha256:77d7ec4cd4c00f79304ee9e53ca3d72e0aba22fbaf7a86797528649e3fc66e41 Status: Downloaded newer image for wangyanglinux/myapp:v1.0 第二步新增pod内容如下 apiVersion: v1 kind: Pod metadata: name: lifecycle-httpget-pod labels: name: lifecycle-httpget-pod spec: containers: - name: lifecycle-httpget-container image: wangyanglinux/myapp:v1.0 ports: - containerPort: 80 lifecycle: postStart: httpGet: host: 192.168.66.11 path: index.html port: 1234 preStop: httpGet: host: 192.168.66.11 path: hostname.html port: 1234 第三步启动pod然后再关闭pod nginx的打印如下 192.168.66.13 - - [08/Sep/2026:09:26:07 0800] GET /index.html HTTP/1.1 200 48 - kube-lifecycle/1.29 192.168.66.13 - - [08/Sep/2026:09:27:23 0800] GET /hostname.html HTTP/1.1 200 13 - kube-lifecycle/1.295.3一个综合案例# # Pod 定义包含 Init Container、两个业务容器、探针和生命周期钩子 # apiVersion: v1 kind: Pod metadata: name: lifecycle-pod # Pod 名称 labels: app: lifecycle-pod # 标签用于选择器 spec: # # Init Containers在业务容器启动前按顺序执行全部成功后才启动主容器 # initContainers: # --- Init Container 1检查 myservice 服务是否可解析 --- - name: init-myservice image: wangyanglinux/tools:busybox # 镜像包含 nslookup 等工具 command: # 启动命令循环解析 myservice直到成功 - sh - -c - until nslookup myservice; do echo waiting for myservice; sleep 2; done; # --- Init Container 2检查 mydb 服务是否可解析 --- - name: init-mydb image: wangyanglinux/tools:busybox command: - sh - -c - until nslookup mydb; do echo waiting for mydb; sleep 2; done; # # 主容器列表两个业务容器 # containers: # -------- 容器 1busybox-container -------- # 作用模拟业务容器通过创建/删除文件来演示存活探针 - name: busybox-container image: wangyanglinux/tools:busybox command: # 启动命令按顺序执行 - /bin/sh - -c - touch /tmp/live ; sleep 600; rm -rf /tmp/live; sleep 3600 # 解释 # 1. touch /tmp/live – 创建存活标记文件 # 2. sleep 600 – 等待 600 秒10 分钟 # 3. rm -rf /tmp/live – 删除标记文件此时探针会失败触发重启 # 4. sleep 3600 – 再等待 3600 秒1 小时容器保持运行 # --- 存活探针livenessProbe --- # 作用检查 /tmp/live 文件是否存在若不存在则重启容器 livenessProbe: exec: # 执行命令方式 command: - test # test 命令 - -e # -e 检查文件是否存在 - /tmp/live initialDelaySeconds: 1 # 容器启动后 1 秒开始探测 periodSeconds: 3 # 每 3 秒探测一次 # --- 生命周期钩子lifecycle --- lifecycle: # postStart容器启动后立即执行注意与主命令异步不阻塞 postStart: httpGet: # 发送 HTTP GET 请求 host: 192.168.66.11 # 目标主机 IP此处写死为 Master IP需确保可达 path: index.html # 请求路径 port: 1234 # 目标端口 # preStop容器终止前执行用于优雅关闭 preStop: httpGet: host: 192.168.66.11 path: hostname.html port: 1234 # -------- 容器 2myapp-container -------- # 作用Web 服务容器演示 httpGet 探针 - name: myapp-container image: wangyanglinux/myapp:v1.0 # 镜像可能已下架建议替换为 nginx 等测试 # --- 存活探针livenessProbe --- # 作用检查 /index.html 是否可访问失败则重启容器 livenessProbe: httpGet: port: 80 # 容器监听端口 path: /index.html # 健康检查路径 initialDelaySeconds: 1 # 启动后 1 秒开始探测 periodSeconds: 3 # 每 3 秒探测一次 timeoutSeconds: 3 # 超时时间 3 秒 # --- 就绪探针readinessProbe --- # 作用检查 /index1.html 是否可访问失败则从 Service 端点移除 # 注意该文件可能不存在会导致 Pod 永远 NotReady可根据实际情况调整 readinessProbe: httpGet: port: 80 path: /index1.html # 就绪检查路径注意此文件可能不存在 initialDelaySeconds: 1 periodSeconds: 3描述细节┌─────────────────────────────────────────────────────────────────────┐ │ 阶段 1提交 YAML │ │ 用户执行 kubectl create -f lifecycle-pod.yaml │ │ → API Server 接收请求进行语法和权限校验 │ │ → 校验通过后Pod 对象被存入 etcd │ │ ⚠️ 阻塞点YAML 语法错误 / 权限不足 → 直接拒绝创建 │ └─────────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────────┐ │ 阶段 2调度Scheduling │ │ API Server 通知调度器Scheduler有新的 Pod 需要调度 │ │ → 调度器根据资源、亲和性、污点等规则为 Pod 选择一个合适的 Node │ │ → 调度结果写回 etcdPod 的 nodeName 字段被赋值 │ │ ⚠️ 阻塞点所有 Node 资源不足 / 不满足调度条件 → Pod 永久 Pending │ │ 可通过 kubectl describe pod 查看 Events 排查 │ └─────────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────────┐ │ 阶段 3kubelet 开始创建 Pod │ │ 目标 Node 上的 kubelet 监听到有新的 Pod 分配到自己 │ │ → 开始执行 Pod 创建流程 │ │ → 先创建 Pod 的 pause 容器Infra Container申请网络和存储资源 │ │ ⚠️ 阻塞点pause 容器创建失败如网络插件未就绪→ Pod 卡在 Pending│ └─────────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────────┐ │ 阶段 4Init Container 阶段初始化容器 │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 按 YAML 中定义的顺序依次执行串行前一个成功才执行下一个│ │ │ │ │ │ │ │ ① init-myservice │ │ │ │ 命令until nslookup myservice; do sleep 2; done; │ │ │ │ 作用循环检查 DNS 中 myservice 这个域名是否可解析 │ │ │ │ │ │ │ │ ② init-mydb │ │ │ │ 命令until nslookup mydb; do sleep 2; done; │ │ │ │ 作用循环检查 DNS 中 mydb 这个域名是否可解析 │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ ⚠️ 全局阻塞点任一 Init Container 执行失败命令返回非 0 │ │ → 停止执行后续 Init Container │ │ → 主容器Main Containers永远不会被启动 │ │ → Pod 状态PendingConditions.Initialized False │ │ → 直至所有 Init Container 全部成功才进入下一阶段 │ └─────────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────────┐ │ 阶段 5主容器启动阶段两个容器并行启动 │ │ Init Container 全部成功 → 开始同时启动 YAML 中定义的所有主容器 │ │ │ │ ┌─────────────────────────────────────────────────────────────────┐│ │ │ 容器 Abusybox-container ││ │ │ ├── ① 执行 postStart 钩子httpGet ← 此处有钩子 ││ │ │ │ → 向 192.168.66.11:1234/index.html 发 GET 请求 ││ │ │ │ ⚠️ 钩子失败超时/非2xx响应 ││ │ │ │ → 该容器被终止不会执行主命令 ││ │ │ │ → 容器重启根据 restartPolicy ││ │ │ │ ││ │ │ └── ② 执行主命令touch /tmp/live; sleep 600; rm -rf ... ││ │ │ → 主命令正常执行容器保持运行 ││ │ │ → 主命令退出异常退出或 sleep 结束后退出 ││ │ │ → 容器被重启取决于 restartPolicy ││ │ ├─────────────────────────────────────────────────────────────────┤│ │ │ 容器 Bmyapp-container ││ │ │ ├── ① 无 postStart 钩子 → 直接跳过 ││ │ │ └── ② 启动 Web 服务进程监听 80 端口 ││ │ │ → 主进程运行正常容器保持 Running ││ │ │ → 主进程崩溃退出 → 容器被重启 ││ │ └─────────────────────────────────────────────────────────────────┘│ │ │ │ 两个容器的 postStart 互不影响 │ │ 一个容器的 postStart 失败不会影响另一个容器的启动 │ └─────────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────────┐ │ 阶段 6探针检测阶段容器持续运行期间周期执行 │ │ │ │ ┌──────────────────────────────────────────────────────────────┐ │ │ │ 容器 Abusybox-container │ │ │ │ ├── livenessProbe存活探针 │ │ │ │ │ 方式exec → 执行 test -e /tmp/live │ │ │ │ │ 频率初始延迟 1s之后每 3s 探测一次 │ │ │ │ │ ✅ 返回 0 → 容器健康继续运行 │ │ │ │ │ ❌ 返回非 0 → kubelet 认为容器“不存活” │ │ │ │ │ → 直接重启该容器无论主命令是否还在执行 │ │ │ │ └── 无 readinessProbe此容器未定义 │ │ │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 容器 Bmyapp-container │ │ │ │ ├── livenessProbe存活探针 │ │ │ │ │ 方式httpGet → GET /index.html:80 │ │ │ │ │ 频率初始延迟 1s之后每 3s 探测一次 │ │ │ │ │ ✅ 返回 2xx/3xx → 容器健康继续运行 │ │ │ │ │ ❌ 返回非 2xx/3xx 或超时 → kubelet 重启该容器 │ │ │ │ │ │ │ │ │ └── readinessProbe就绪探针 │ │ │ │ 方式httpGet → GET /index1.html:80 │ │ │ │ 频率初始延迟 1s之后每 3s 探测一次 │ │ │ │ ✅ 返回 2xx/3xx → Pod 标记为 Ready │ │ │ │ → Service 开始将流量转发到这个 Pod │ │ │ │ ❌ 返回非 2xx/3xx 或超时 → Pod 标记为 NotReady │ │ │ │ → Service 不会将流量转发到这个 Pod │ │ │ │ → 但 Pod 中的容器不会因此被重启 │ │ │ └──────────────────────────────────────────────────────────────┘ │ │ │ │ 两个探针的区别 │ │ liveness 失败 → 重启容器粗暴恢复 │ │ readiness 失败 → 摘除流量不影响容器运行给时间自我修复 │ └─────────────────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────────────────┐ │ 阶段 7Running稳态运行 │ │ 所有容器都已启动且通过存活探针检查 │ │ → Pod 状态变为 Running │ │ → 如果 readinessProbe 也通过Pod 变为 Ready可接收 Service 流量 │ │ → 在运行期间 │ │ • livenessProbe 持续监测发现异常则重启容器 │ │ • readinessProbe 持续监测发现异常则摘除流量 │ │ • 主容器进程持续运行或按业务逻辑执行任务 │ └─────────────────────────────────────────────────────────────────────┘ ↓ 收到删除信号 —— kubectl delete pod lifecycle-pod ↓ ┌─────────────────────────────────────────────────────────────────────┐ │ 阶段 8终止阶段Graceful Shutdown │ │ API Server 收到删除请求Pod 状态变为 Terminating │ │ │ │ ① 执行 preStop 钩子并行执行所有容器的 preStop │ │ ┌─────────────────────────────────────────────────────────────────┐│ │ │ 容器 Abusybox-container 有 preStop 钩子httpGet ││ │ │ → 向 192.168.66.11:1234/hostname.html 发 GET 请求 ││ │ │ ✅ 成功 → 记录事件继续 ││ │ │ ❌ 失败 → 记录事件Warning但继续执行后续流程 ││ │ │ ⏱️ 钩子执行超时 → 进入下一步不阻塞 ││ │ │ ││ │ │ 容器 Bmyapp-container 无 preStop 钩子 → 直接跳过 ││ │ └─────────────────────────────────────────────────────────────────┘│ │ │ │ ② 向所有容器发送 SIGTERM 信号优雅终止信号 │ │ → 容器内进程收到信号开始执行优雅退出逻辑 │ │ → 应用应在此阶段完成关闭连接、保存状态、释放资源 │ │ ⏱️ 等待宽限期terminationGracePeriodSeconds默认 30 秒 │ │ │ │ ③ 宽限期结束强制终止 │ │ → 发送 SIGKILL 信号给仍未退出的容器 │ │ → 强制杀死所有残留进程 │ │ │ │ ④ 清理资源 │ │ → 删除 Pod 的网络和存储资源Volume 等 │ │ → 从 etcd 中删除 Pod 记录 │ │ → Pod 彻底消失 │ └─────────────────────────────────────────────────────────────────────┘简易版总结1. 提交 YAML → API Server 存入 etcd 2. 调度器分配 Node 3. kubelet 创建 pause 容器申请网络/存储 4. Init Container按顺序串行执行 → 全部成功才继续否则主容器永不启动 5. 主容器启动所有主容器并行启动 ├── 容器1busybox │ ├── postStart 钩子有→ 失败则容器被重启 │ └── 主命令执行 └── 容器2myapp ├── postStart 钩子无→ 直接跳过 └── 主进程启动 6. 探针持续监测容器运行期间 ├── livenessProbe失败 → 重启容器 └── readinessProbe失败 → 摘除流量不重启 7. Pod 进入 Running/Ready 稳态 8. 收到删除信号 → preStop 钩子 → SIGTERM → 宽限期结束 → SIGKILL → 删除