一、概述

当容器与 pause 容器共享网络（Network）、IPC（进程间通信）和 PID（进程命名空间）后，二者形成了一种紧密的 "共享命名空间" 关系，共同构成了 Kubernetes 中 "Pod 内容器" 的核心协作模式

InitC 初始化容器
        initc不能相交单线程执行，一个失败全部重建、、容器死亡后退出码必须是0，否则重建第一个initC，来保证每一个initC容器都是连贯的
        执行危险操作、阻塞特性
MainC，
          不限次数，并发   、pod所在节点的kubelet，
        钩子、启动后、关闭前
        探针、就绪探测老版本是一段时间，存活探测保证Pod在存活且能为用户提供访问，否则杀死

二、initC

1、特性

init容器与普通的容器区别:

init容器总是运行到成功完成为止
每个init容器都必须在下一个init容器启动之前成功完成

init重启规则

如果Pod的Init容器失败,Kubernetes会不断地重启该Pod,直到Init容器成功为止。
然而,如果Pod对应的restartPolicy为Never,它不会重新启动

其它

InitC与应用容器具备不同的镜像,可以把一些危险的工具放置在initC中,进行使用
initC多个之间是线性启动的,所以可以做一些延迟性的操作
initC无法定义就绪探测,其它以外同应用容器定义无异

2、检测intiC的阻塞性

资源清单

apiVersion: v1
kind: Pod
metadata:name: initc-1labels:app: initc
spec:containers:- name: myapp-containerimage: wangyanglinux/tools:busyboxcommand: ['sh', '-c', 'echo The app is running! && sleep 3600']initContainers:- name: init-myserviceimage: wangyanglinux/tools:busyboxcommand: ['sh', '-c', 'until nslookup myservice; do echo waiting for 
myservice; sleep 2; done;']- name: init-mydbimage: wangyanglinux/tools:busyboxcommand: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 
2; done;']#until 为假循环为真退出

$ kubectl create svc clusterip myservice --tcp=80:80
$ kubectl create svc clusterip mydb --tcp=80:80

结论

第一，initC启动是线性的

第二，每个initC的返回码必须是0

三、探针

1、概述

# 容器探针（kubelet 诊断）核心总结
1. **定义**：由 kubelet 对容器执行的定期诊断，需调用容器实现的 Handler（处理程序）。
2. **三种 Handler 类型**：
- **ExecAction**：在容器内执行指定命令，命令返回码为 0 则诊断成功。
- **TCPSocketAction**：对容器 IP 地址的指定端口做 TCP 检查，端口打开则诊断成功。
- **HTTPGetAction**：对容器 IP 地址的指定端口+路径发 HTTPGet 请求，响应状态码 200-399 则诊断成功。
3. **三种探测结果**：
- 成功：容器通过诊断。
- 失败：容器未通过诊断。
- 未知：诊断本身失败，不采取任何行动。

2、分类

startupProbe 准备、

livenessProbe、就绪

readinessProbe、存活

3、readinessProbe 就绪探针

注意

如果pod内部的C不添加就绪探测,默认就绪。如果添加了就绪探测,
只有就绪通过以后,才标记修改为就绪状态。当前pod内的所有的C都就绪,才标记当前Pod就绪

成功:将当前的C标记为就绪
失败:静默
未知:静默

deployment，容器控制器
labelS，标签选择器

存活探针用于解决容器进程仍在运行但应用程序已无响应（即“活死人”）的问题。Kubernetes 通过定期探测并在失败时重启容器来恢复服务。

其核心配置参数如下：

initialDelaySeconds：容器启动后，等待多少秒才开始第一次探测。
- 默认值：0秒
- 最小值：0
periodSeconds：每次执行探测的间隔时间。
- 默认值：10秒
- 最小值：1
timeoutSeconds：单次探测请求等待响应的超时时间。
- 默认值：1秒
- 最小值：1
successThreshold：探测失败后，需要连续成功多少次才被重新认定为成功。
- 默认值：1
- 最小值：1
failureThreshold：探测失败的重试次数，超过该次数后即认定本次探测彻底失败。
- 默认值：3
- 最小值：1

定义就绪探测

基于 HTTP Get 方式

apiVersion: v1
kind: Pod
metadata:name: readiness-httpget-podnamespace: defaultlabels:app: myappenv: test
spec:containers:- name: readiness-httpget-containerimage: wangyanglinux/myapp:v1.0imagePullPolicy: IfNotPresentreadinessProbe:httpGet:port: 80path: /index1.htmlinitialDelaySeconds: 1periodSeconds: 3

vi 4.pod.yaml //编辑资源清单
kubectl create -f 4.pod.yaml //启动pod
kubectl get pod --show-labels //查看节点信息

启动，未就绪。因为这里没有index.html文件，负载均衡不会到pod-3（标签不匹配）和 rediness-htttpget-pod（未就绪）

查看pod事件
kubectl describe pod rediness-htttpget-pod

就绪探测失败.

进入容器恢复html文件

进入容器
kubectl exec -it rediness-htttpget-pod -- /bin/bash
cd
cd /usr/local/nginx/html/
追加内容到 index1文件中
echo "wangyang daociyiyou" >> index1.html
exit

就绪了，此时去负载均衡访问，也会出现了

基于 EXEC 方式

这里启动命令，是在60s后删除live文件，就绪探测是检测这个live文件，所以会出现就绪----未就绪的状态

apiVersion: v1
kind: Pod
metadata:name: readiness-exec-podnamespace: default
spec:containers:- name: readiness-exec-containerimage: wangyanglinux/tools:busyboximagePullPolicy: IfNotPresentcommand: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; 
sleep
3600"]readinessProbe:exec:command: ["test","-e","/tmp/live"]initialDelaySeconds: 1periodseconds: 3

监视，打印当前资源对象的变化情况
kubectl get pod -w

补充：基于 T C P C h e c k 方式

不常用，有瑕疵，这种情况多用httpget

apiVersion: v1
kind: Pod
metadata:name: readiness-tcp-pod
spec:containers:- name: readiness-exec-containerimage: wangyanglinux/myapp:v1.0readinessProbe:initialDelaySeconds: 5timeoutSeconds: 1tcpSocket:port: 80

4、livenessProbe 存活探针

存活探测

如果pod内部不指定存活探测，可能会发生容器在运行但是无法提供访问的情况

成功：静默

失败：根据重启策略进行重启

未知：静默

查看详细信息和重启策略
kubectl get pod podname -o

# K8s存活探针核心总结
1. **核心作用**：解决容器“存活但功能失效”问题，确保仅正常工作的容器运行。
2. **关键配置参数（含默认值/最小值）**：
- `initialDelaySeconds`：容器启动后延迟多久开始探测，单位秒，默认0、最小0。
- `periodSeconds`：探测执行间隔，单位秒，默认10、最小1。
- `timeoutSeconds`：探测请求等待响应的超时时间，单位秒，默认1、最小1。
- `successThreshold`：探测失败后判定为成功的最小次数，默认1、最小1（需为1才能激活启动）。
- `failureThreshold`：探测失败的重试次数，超过次数判定为失败，默认3、最小1。

基于命令的存活探测 - - Exec

根据资源清单预估pod状态

运行 --- 死了 ---- 重启 --- 运行 --- 死了 ...

apiVersion: v1
kind: Pod
metadata:name: liveness-exec-podnamespace: default
spec:containers:- name: liveness-exec-containerimage: wangyanglinux/tools/busboximagePullPolicy: IfNotPresentcommand: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 3600"]livenessProbe:exec:command: ["/test","-e","/tmp/live"]initialDelaySeconds: 1periodSeconds: 3

监视
kubectl get pod -w

基于 HTTP Get 方式

apiVersion: v1
kind: Pod
metadata:name: liveness-httpget-podnamespace: default
spec:containers:- name: liveness-httpget-containerimage: wangyanglinux/myapp:v1.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: 80

编辑资源清单
vi 8.pod.yaml
启动
kubectl create -f 8.pod.yaml

搞破坏，干掉当前的内部容器
kubectl exec -it liveness-httpget-pod -- /bin/bash

这里被踢出了

再次进入

进入pod所在节点查查看

docker ps |grep liveness-httpget-pod

1代表重启次数（从0开始）

补充：基于 T C P C h e c k 方式

apiVersion: v1
kind: Pod
metadata:name: liveness-httpget-podnamespace: default
spec:containers:- name: liveness-httpget-containerimage: wangyanglinux/myapp:v1.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80livenessProbe:httpGet:port: 80

5、startupProbe 启动探针

在 1.16 之后新增，保障存活探针在执行的时候不会陷入死循环活着延期很长的情况

成功：开始允许存活探针和就绪探针开始执行

失败：静默

apiVersion: v1
kind: Pod
metadata:name: startupprobe-1namespace: default
spec:containers:- name: myapp-containerimage: wangyanglinux/myapp:v1.0imagePullPolicy: IfNotPresentports:- name: httpcontainerPort: 80readinessProbe:httpGet:port: 80path: /index2.htmlinitialDelaySeconds: 1periodSeconds: 3startupProbe:httpGet:path: /index1.htmlport: 80failureThreshold: 30periodSeconds: 10//应用程序将会有最多 5 分钟 failureThreshold * periodSeconds（30 * 10 = 300s）的时间来完成
其启动过程。

创建启动pod

先满足启动探测的html1，才会去执行就绪探测

四、钩子 hook

# Pod Hook（钩子）总结
1. **发起主体与运行时机**：由Kubernetes管理的kubelet发起，运行于容器生命周期内，具体为容器进程启动前或终止前。
2. **配置范围**：可同时为Pod中的所有容器配置。
3. **类型分类**：
- **exec**：执行一段命令
- **HTTP**：发送HTTP请求

--------------------------------------------------

启动前钩子在容器初始化后，有可能末端和启动命令部分重合

启动后钩子在关闭命令前执行

lifecycle

apiVersion: v1
kind: Pod
metadata:name: lifecycle-exec-pod
spec:containers:- name: lifecycle-exec-containerimage: wangyanglinux/myapp:v1lifecycle:postStart:exec:command: ["/bin/sh", "-c", "echo postStart > /usr/share/message"]preStop:exec:command: ["/bin/sh", "-c", "echo preStop > /usr/share/message"]

基于 HTTP Get 方式

# 端口01，开启一个测试 webServer，检测是否有请求
$ docker run -it --rm -p 1234:80 wangyanglinux/myapp:v1.0

端口02创建执行pod

apiVersion: v1
kind: Pod
metadata:name: lifecycle-httpget-podlabels:name: lifecycle-httpget-pod
spec:containers:- name: lifecycle-httpget-containerimage: wangyanglinux/myapp:v1.0ports:- containerPort: 80lifecycle:postStart:httpGet:host: 192.168.66.11path: index.htmlport: 1234preStop:httpGet:host: 192.168.125.101path: hostname.htmlport: 1234

杀死pod

关于关闭前钩子

# K8s Pod终止相关总结
1. **Pod优雅释放的常见问题**：部分Pod无法顺利优雅释放，常见原因包括Pod卡死、优雅退出逻辑存在BUG（如陷入死循环）、代码问题导致执行命令无效。
2. **grace period（宽限期）的作用与配置**：
- 定义：k8s Pod终止流程中“最多可容忍的时间”，用于应对上述优雅释放问题，超时后会强制kill Pod。
- 配置方式：通过`pod.spec.terminationGracePeriodSeconds`字段定义，默认30秒；执行`kubectl delete`时，可通过`--grace-period`参数指定值覆盖Pod原有配置。
3. **关键注意事项**：grace period与preStopHook、SIGTERM信号并行发生，k8s不会等待preStopHook完成；若应用在宽限期结束前完成关闭并退出，k8s会立即进入终止流程的下一步。

五、整合

删除所有pod和除kubernetes之外的 service

apiVersion: v1
kind: Pod
metadata:name: lifecycle-podlabels:app: lifecycle-pod
spec:containers:- name: busybox-containerimage: wangyanglinux/tools:busyboxcommand: ["/bin/sh", "-c", "touch /tmp/live ; sleep 600; rm -rf /tmp/live; sleep 3600"]livenessProbe:exec:command: ["test", "-e", "/tmp/live"]initialDelaySeconds: 1periodSeconds: 3lifecycle:postStart:httpGet:host: 192.168.66.11path: index.htmlport: 1234preStop:httpGet:host: 192.168.66.11path: hostname.htmlport: 1234- name: myapp-containerimage: wangyanglinux/myapp:v1.0livenessProbe:httpGet:port: 80path: /index.htmlinitialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 3readinessProbe:httpGet:port: 80path: /index1.htmlinitialDelaySeconds: 1periodSeconds: 3initContainers:- name: init-myserviceimage: wangyanglinux/tools:busyboxcommand: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']- name: init-mydbimage: wangyanglinux/tools:busyboxcommand: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

编写、启动、创建

这里初始化需要 myservice 、 mydb的 service，没有，所以会卡这

创建myservice、初始化通过1

创建mydb，初始化通过

kubectl create svc clusterip mydb --tcp=80:80

启动容器提供服务，主
docker run --name test -p 1234:80 -d wangyanglinux/myapp:v1.0

现在就绪为1，因为有个就绪探测需要满足

一、概述

二、initC

1、特性

init容器与普通的容器区别:

init重启规则

其它

2、检测intiC的阻塞性

结论

三、探针

1、概述

2、分类

3、readinessProbe 就绪探针

注意

定义就绪探测

基于 HTTP Get 方式

进入容器恢复html文件

基于 EXEC 方式

补充：基 于 T C P C h e c k 方 式

4、livenessProbe 存活探针

基于命令的存活探测 - - Exec

基于 HTTP Get 方式

补充：基 于 T C P C h e c k 方 式

5、startupProbe 启动探针

四、钩子 hook

lifecycle

基于 HTTP Get 方式

关于关闭前钩子

五、整合

相关文章

补充：基于 T C P C h e c k 方式

补充：基于 T C P C h e c k 方式