一、概述

当容器与 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-1
 labels:
   app: initc
spec:
 containers:
 - name: myapp-container
   image: wangyanglinux/tools:busybox
   command: ['sh', '-c', 'echo The app is running! && sleep 3600']
 initContainers:
 - name: init-myservice
   image: wangyanglinux/tools:busybox
   command: ['sh', '-c', 'until nslookup myservice; do echo waiting for 
myservice; sleep 2; done;']
 - name: init-mydb
   image: wangyanglinux/tools:busybox
   command: ['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-pod
 namespace: default
 labels:
   app: myapp
   env: test
spec:
 containers:
 - name: readiness-httpget-container
   image: wangyanglinux/myapp:v1.0
   imagePullPolicy: IfNotPresent
   readinessProbe:
     httpGet:
       port: 80
       path: /index1.html
     initialDelaySeconds: 1
     periodSeconds: 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-pod
 namespace: default
spec:
 containers:
 - name: readiness-exec-container
   image: wangyanglinux/tools:busybox
   imagePullPolicy: IfNotPresent
   command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; 
sleep
3600"]
   readinessProbe:
     exec:
        command: ["test","-e","/tmp/live"]
     initialDelaySeconds: 1
     periodseconds: 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-container
    image: wangyanglinux/myapp:v1.0
    readinessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        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-pod
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: wangyanglinux/tools/busbox
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh","-c","touch /tmp/live ; sleep 60; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["/test","-e","/tmp/live"]
    initialDelaySeconds: 1
    periodSeconds: 3

监视

kubectl get pod -w  

基于 HTTP Get 方式

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: wangyanglinux/myapp:v1.0
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      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-pod
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: wangyanglinux/myapp:v1.0
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: 80

5、startupProbe 启动探针

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

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

        失败：静默

apiVersion: v1
kind: Pod
metadata:
 name: startupprobe-1
 namespace: default
spec:
 containers:
 - name: myapp-container
   image: wangyanglinux/myapp:v1.0
   imagePullPolicy: IfNotPresent
   ports:
   - name: http
     containerPort: 80
   readinessProbe:
     httpGet:
       port: 80
       path: /index2.html
     initialDelaySeconds: 1
     periodSeconds: 3
   startupProbe:
     httpGet:
       path: /index1.html
       port: 80
     failureThreshold: 30
     periodSeconds: 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-container
   image: wangyanglinux/myapp:v1
   lifecycle:
     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-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.125.101
          path: hostname.html
          port: 1234

01

杀死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-pod
  labels:
    app: lifecycle-pod
spec:
  containers:
  - name: busybox-container
    image: wangyanglinux/tools:busybox
    command: ["/bin/sh", "-c", "touch /tmp/live ; sleep 600; rm -rf /tmp/live; sleep 3600"]
    livenessProbe:
      exec:
        command: ["test", "-e", "/tmp/live"]
      initialDelaySeconds: 1
      periodSeconds: 3
    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
  - name: myapp-container
    image: wangyanglinux/myapp:v1.0
    livenessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 3
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3
  initContainers:
  - name: init-myservice
    image: wangyanglinux/tools:busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: wangyanglinux/tools:busybox
    command: ['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，因为有个就绪探测需要满足

 

 

# kubernetes # 容器 # 云原生
Logo
开源鸿蒙跨平台开发者社区

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

更多推荐

cover

20分钟跑通流程：鸿蒙 Module 发布 OpenHarmony 实战（附完整配置）

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

Flutter For Openharmony第三方库：页面转场动画库 flutter_view 的鸿蒙化适配

flutter_view 是一个专注于页面转场效果的 Flutter 扩展库，其设计理念是将复杂的转场动画实现封装为简洁易用的 API 接口。开发者无需深入了解动画底层实现原理，只需选择合适的转场类型并配置相应参数，即可实现流畅自然的页面过渡效果。该库的核心设计目标包括三个方面。首先是跨平台一致性，确保转场动画在不同平台上的表现效果基本一致，特别是针对 OpenHarmony 平台进行了专门优化。

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

Flutter for OpenHarmony 跨平台开发：颜色选择器功能实战指南

Flutter是Google于2017年发布的开源UI框架，采用Dart语言进行开发。Flutter通过Skia渲染引擎实现自绘，不依赖平台原生组件，从而保证了不同平台上UI的一致性。这种自绘机制使得Flutter应用能够在保持高性能的同时，实现像素级的界面控制。OpenHarmony是由开放原子开源基金会孵化的开源操作系统项目，旨在构建万物智联的操作系统生态。

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