K8s: 在Pod里面创建init容器与健康检查

关注

原创最新推荐文章于 2026-08-25 13:33:39 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

K8S学习指南(9)-k8s核心对象init pod Init容器是在Pod中运行的一个独立的容器，它负责在主容器启动之前执行初始化任务。这些初始化任务可以包括数据准备、配置检查、网络设置等。一旦Init容器中的任务成功完成，Kubernetes将启动主容器。Init容器的生命周期是独立于主容器的，这使得我们能够在应用程序启动之前执行必要的预处理工作。阅读详情

pod中init容器的创建

1 ）概述

每个 Pod 中可以包含多个容器，应用运行在这些容器里面
同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器
Init 容器与普通的容器非常像，除了如下两点
- a. 它们总是运行到完成。
- b. 每个都必须在下一个启动之前成功完成
如果 Pod 的 Init 容器失败，K8s 会不断地重启该 Pod，直到 Init 容器成功为止
然而，如果 Pod 对应的 restartPolicy 值为 Never，K8s 不会重新启动 Pod
与普通容器的不同之处如下
- a. Init 容器支持应用容器的全部属性和特性，包括资源限制、数据卷和安全设置。
- b. 同时 Init 容器不支持 lifecycle、livenessProbe、readinessProbe 和 startupProbe，因为它们必须在 Pod 就绪之前运行完成

2 ）Init Pod 的创建

下面的例子定义了一个有 init 容器和一个业务容器

创建 init-pod.yaml

apiVersion: v1
kind: Pod
metadata:
 name: init-pod-demo
 labels:
   name: init-pod
spec:
 containers:
 - name: busybox-container
   image: busybox:latest
   command: ['sh', '-c', 'date && sleep 3600']
   resources:
     limits:
       memory: "128Mi"
       cpu: "500m"
   ports:
   - containerPort: 80
 initContainers:
 - name: init-container
   image: busybox:latest
   command: ['sh', '-c', "date && sleep 10"]

$ kubectl apply -f init-pod.yaml 创建 pod
```
pod/init-pod-demo created
```

$ kubectl get po -w 查看pod的创建过程

init-pod-demo    0/1     Init:0/1          0          16s
init-pod-demo    0/1     PodInitializing   0          17s
init-pod-demo    1/1     Running           0          27s

$ kubectl logs init-pod-demo 查看 pod 日志
```
Thu Apr 18 07:31:59 UTC 2024
```
$ kubectl logs init-pod-demo -c init-container 进入init容器查看日志
```
Thu Apr 18 07:31:39 UTC 2024
```
从上面一系列输出中可以看到，在 PodInitializing 和 Running 两个阶段用了 10s
- 这个对应着在init容器中运行的脚本中打印时间后，睡了 10s
同时pod中和容器中打印的时间相差 20s，这两个相差的时间一定是大于睡了的10s的
也就是说，业务容器运行之前必须启动完成init容器

pod的健康检查

1 ）探针的作用

探针是由 kubelet 对容器执行的定期诊断
要执行诊断，kubelet 调用由容器实现的 Handler （处理程序）,有三种类型的处理程序：
- ExecAction
  - 在容器内执行指定命令
  - 如果命令退出时返回码为 0 则认为诊断成功
- TCPSocketAction
  - 对容器的 IP 地址上的指定端口执行 TCP 检查
  - 如果端口打开，则诊断被认为是成功的
- HTTPGetAction
  - 对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求
  - 如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的
每次探测都将获得以下三种结果之一
- Success（成功）：容器通过了诊断
- Failure（失败）：容器未通过诊断
- Unknown（未知）：诊断失败，因此不会采取任何行动

2 ) 使用启动探针

对于所包含的容器需要较长时间才能启动就绪的 Pod 而言，启动探针是有用的
你不再需要配置一个较长的存活态探测时间间隔，只需要设置另一个独立的配置选定
对启动期间的容器执行探测，从而允许使用远远超出存活态时间间隔所允许的时长
如果你的容器启动时间通常超出 initialDelaySeconds + failureThreshold × periodSeconds 总值
你应该设置一个启动探测，对存活态探针所使用的同一端点执行检查
periodSeconds 的默认值是 30 秒
你应该将其 failureThreshold 设置得足够高，以便容器有充足的时间完成启动
并且避免更改存活态探针所使用的默认值, 这一设置有助于减少死锁状况的发生

3 ) 创建一个 HTTP 请求的探针

创建一个 liveness.yaml 文件

apiVersion: v1
kind: Pod
metadata:
  name: liveness-http
  labels:
    test: liveness
spec:
  containers:
  - name: liveness
    image: mirrorgooglecontainers/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

这是官方曾经提供的一个案例
在这个配置文件中，可以看到 Pod 也只有一个容器
periodSeconds 字段指定了 kubelet 每隔 3 秒执行一次存活探测
initialDelaySeconds 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒
kubelet会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测
如果服务器上 /healthz 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的
如果处理程序返回失败代码，则 kubelet 会杀死这个容器并且重新启动它
任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。

可以有容器内运行服务的源码 server.go

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
	 duration := time.Now().Sub(started)
	 if duration.Seconds() > 10 {
		 w.WriteHeader(500)
		 w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
	 } else {
		 w.WriteHeader(200)
		 w.Write([]byte("ok"))
	 }
})

容器存活的最开始 10 秒中， /healthz 处理程序返回一个 200 的状态码
之后处理程序返回 500 的状态码
$ kubectl apply -f liveness.yaml 创建 pod
```
pod/liveness-http created
```

$ kubectl get po -w | grep live 监控 pod

liveness-http    0/1     ContainerCreating   0          2s
liveness-http    1/1     Running             0          5s
liveness-http    1/1     Running             1 (4s ago)   26s
liveness-http    1/1     Running             2 (3s ago)   46s
liveness-http    1/1     Running             3 (3s ago)   67s
liveness-http    1/1     Running             4 (3s ago)   88s
liveness-http    0/1     CrashLoopBackOff    4 (0s ago)   106s
liveness-http    1/1     Running             5 (56s ago)   2m42s
liveness-http    0/1     CrashLoopBackOff    5 (0s ago)    2m58s
liveness-http    1/1     Running             6 (95s ago)   4m33s
liveness-http    0/1     CrashLoopBackOff    6 (0s ago)    4m52s

可见一直在重启

$ kubectl describe pod liveness-http 查看 pod 详细问题

Name:         liveness-http
Namespace:    default
Priority:     0
Node:         node1.k8s/10.211.55.11
Start Time:   Thu, 18 Apr 2024 16:45:57 +0800
Labels:       test=liveness
Annotations:  <none>
Status:       Running
IP:           10.244.1.27
IPs:
  IP:  10.244.1.27
Containers:
  liveness:
    Container ID:  docker://0bde3a8c2ab79d2fd389659354771da10edbdfd29e3bb3d5c87fcbcb44f918b1
    Image:         mirrorgooglecontainers/liveness
    Image ID:      docker-pullable://mirrorgooglecontainers/liveness@sha256:854458862be990608ad916980f9d3c552ac978ff70ceb0f90508858ec8fc4a62
    Port:          <none>
    Host Port:     <none>
    Args:
      /server
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    2
      Started:      Thu, 18 Apr 2024 16:47:19 +0800
      Finished:     Thu, 18 Apr 2024 16:47:36 +0800
    Ready:          False
    Restart Count:  4
    Liveness:       http-get http://:8080/healthz delay=3s timeout=1s period=3s #success=1 #failure=3
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-nv6lw (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  kube-api-access-nv6lw:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                 From               Message
  ----     ------     ----                ----               -------
  Normal   Scheduled  114s                default-scheduler  Successfully assigned default/liveness-http to node1.k8s
  Normal   Pulled     111s                kubelet            Successfully pulled image "mirrorgooglecontainers/liveness" in 2.298827654s
  Normal   Pulled     92s                 kubelet            Successfully pulled image "mirrorgooglecontainers/liveness" in 1.281083837s
  Normal   Created    74s (x3 over 111s)  kubelet            Created container liveness
  Normal   Started    74s (x3 over 111s)  kubelet            Started container liveness
  Normal   Pulled     74s                 kubelet            Successfully pulled image "mirrorgooglecontainers/liveness" in 1.048779521s
  Warning  Unhealthy  58s (x9 over 100s)  kubelet            Liveness probe failed: HTTP probe failed with statuscode: 500
  Normal   Killing    58s (x3 over 94s)   kubelet            Container liveness failed liveness probe, will be restarted
  Normal   Pulling    57s (x4 over 114s)  kubelet            Pulling image "mirrorgooglecontainers/liveness"

这里可以看到
- Liveness probe failed: HTTP probe failed with statuscode: 500
- Container liveness failed liveness probe, will be restarted
返回 500 之后，进行了重启