四、kubernetes 1.29 之 Pod 生命周期

一、概述

當容器與?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，因為有個就緒探測需要滿足