k8s-pod生命周期钩子函数

发表于 | 分类于 ， | 阅读次数：
本文字数： 9.6k | 阅读时长 ≈ 9 分钟

pod从开始创建到终止退出的时间范围称为Pod生命周期

pod生命周期

生命周期包含以下几个重要流程：

1
2
3
4
5
6
7
初始化容器（initContainers）
创建主容器（containers）是必须的操作
容器启动后钩子
启动探测
存活性探测
就绪性探测
容器停止前钩子

pod在整个生命周期的过程中总会处于以下几个状态：

1
2
3
4
5
6
Pending：创建了pod资源并存入etcd中，但尚未完成调度。
ContainerCreating：Pod 的调度完成，被分配到指定 Node 上。处于容器创建的过程中。通常是在拉取镜像的过程中。
Running：Pod 包含的所有容器都已经成功创建，并且成功运行起来。
Succeeded：Pod中的所有容器都已经成功终止并且不会被重启
Failed：所有容器都已经终止，但至少有一个容器终止失败，也就是说容器返回了非0值的退出状态或已经被系统终止。
Unknown：因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

pod生命周期的重要行为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1、在启动任何容器之前，先创建pause基础容器，它初始化Pod的环境并为后续加⼊的容器提供共享的名称空间。
2.初始化容器（initcontainer）：
一个pod可以拥有任意数量的init容器。init容器是按照顺序以此执行的，并且仅当最后一个init容器执行完毕才会去启动主容器。
3.生命周期钩子：
pod允许定义两种类型的生命周期钩子，启动后(post-start)钩子和停止前(pre-stop)钩子
这些生命周期钩子是基于每个容器来指定的，和init容器不同的是，init容器是应用到整个pod。而这些钩子是针对容器的，是在容器启动后和停止前执行的。
4.容器探测：
对Pod健康状态诊断。分为三种： Startupprobe、Livenessprobe(存活性探测)， Readinessprobe(就绪性检测)
Startup（启动探测）:探测容器是否正常运行
Liveness(存活性探测)：判断容器是否处于runnning状态，根据重启策略决定是否重启容器
Readiness(就绪性检测)：判断容器是否准备就绪并对外提供服务，将容器设置为不可用，不接受service转发的请求
三种探针用于Pod检测：
ExecAction：在容器中执行一个命令，并根据返回的状态码进行诊断，只有返回0为成功
TCPSocketAction：通过与容器的某TCP端口尝试建立连接
HTTPGetAction：通过向容器IP地址的某指定端口的path发起HTTP GET请求

容器的重启策略

1
2
3
4
5
6
定义是否重启Pod对象
Always：但凡Pod对象终止就重启，默认设置
OnFailure：仅在Pod出现错误时才重启
Never：从不

注：一旦Pod绑定到一个节点上，就不会被重新绑定到另一个节点上，要么重启，要么终止

pod的终止过程终止过程主要分为如下几个步骤：

1
2
3
4
5
6
7
8
9
(1)用户发出删除 pod 命令：kubectl delete pods ，kubectl delete -f yaml
(2)Pod 对象随着时间的推移更新，在宽限期（默认情况下30秒），pod 被视为“dead”状态
(3)将 pod 标记为“Terminating”状态
(4)第三步同时运行，监控到 pod 对象为“Terminating”状态的同时启动 pod 关闭过程
(5)第三步同时进行，endpoints 控制器监控到 pod 对象关闭，将pod与service匹配的 endpoints 列表中删除
(6)如果 pod 中定义了 preStop 钩子处理程序，则 pod 被标记为“Terminating”状态时以同步的方式启动执行；若宽限期结束后，preStop 仍未执行结束，第二步会重新执行并额外获得一个2秒的小宽限期
(7)Pod 内对象的容器收到 TERM 信号
(8)宽限期结束之后，若存在任何一个运行的进程，pod 会收到 SIGKILL 信号
(9)Kubelet 请求 API Server 将此 Pod 资源宽限期设置为0从而完成删除操作

初始化容器（init）

1
2
spec字段下有个initContainers字段(初始化容器)，Init容器就是做初始化工作的容器。可以有一个或多个，如果多个按照定义的顺序依次执行，先执行初始化容器1，再执行初始化容器2等，等初始化容器执行完具体操作之后初始化容器就退出了，只有所有的初始化容器执行完后，主容器才启动。
由于一个Pod里容器存储卷是共享的，所以Init Container里产生的数据可以被主容器使用到，Init Container可以在多种K8S资源里被使用到，如Deployment、DaemonSet, StatefulSet、Job等，但都是在Pod启动时，在主容器启动前执行，做初始化工作。

初始化容器与主容器区别是

1
2
1、初始化容器不支持 Readinessprobe,因为它们必须在Pod就绪之前运行完成
2、每个Init容器必须运行成功,下一个才能够运行

初始化容器应用：

[root@pengfei-master1 pod]# cat init-1.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
apiVersion: v1
kind: Pod
metadata:
  name: init-busybox
  labels:
    app: init-busybox
spec:
  initContainers:
  - name: install
    image: busybox
    imagePullPolicy: IfNotPresent
    command:
    - wget
    - "-O"
    - "/tmp/index.html"
    - "https://www.baidu.com"
    volumeMounts:
    - name: workdir
      mountPath: /tmp
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  dnsPolicy: Default
  volumes:
  - name: workdir
    emptyDir: {}

创建pod并查看pod：

1
2
3
4
[root@pengfei-master1 pod]# kubectl apply -f init-1.yaml
[root@pengfei-master1 pod]# kubectl get pods -owide
NAME           READY   STATUS    RESTARTS   AGE   IP              NODE            NOMINATED NODE   READINESS GATES
init-busybox   1/1     Running   0          16h   10.244.225.88   pengfei-node2   <none>           <none>

测试pod

1
[root@pengfei-master1 pod]# curl  10.244.225.88
1
2
3
4
5
6
7
8
9
10
11
12
[root@pengfei-master1 pod]# kubectl exec -it init-busybox /bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
Defaulted container "nginx" out of: nginx, install (init)
root@init-busybox:/# ls
bin   dev		   docker-entrypoint.sh  home  lib64  mnt  proc  run   srv  tmp  var
boot  docker-entrypoint.d  etc			 lib   media  opt  root  sbin  sys  usr
root@init-busybox:/# cd /usr/share/nginx
root@init-busybox:/usr/share/nginx# ls
html
root@init-busybox:/usr/share/nginx# cd html
root@init-busybox:/usr/share/nginx/html# ls
index.html

主容器

1
2
1、容器钩子
初始化容器启动之后，开始启动主容器，在主容器启动之后有一个post start hook（容器启动后钩子）和pre stop hook（容器结束前钩子），无论启动后还是结束前所做的事我们可以把它放到这两个钩子，这个钩子就表示用户可以用它来钩住一些命令，非必须选项
  • postStart：该钩子在容器被创建后立刻执行，如果该钩子对应的探测执行失败，则该容器会被杀死，并根据该容器的重启策略决定是否要重启该容器，这个钩子不需要传递任何参数。
  • preStop：该钩子在容器被删除前执行，主要用于释放资源和优雅关闭程序

容器钩子：postStart和preStop

postStart：容器创建之后立刻执行，用于资源部署、环境准备等。
preStop：在容器被终止前执行，用于优雅关闭应用程序、通知其他系统等

postStart和preStop用法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
......
containers:
- image: sample:v2  
     name: war
     lifecycle：
      postStart:
       exec:
         command:
          - “cp”
          - “/sample.war”
          - “/app”
      prestop:
       httpGet:
        host: monitor.com
        path: /waring
        port: 8080
        scheme: HTTP
......

#以上示例中，定义了一个Pod，包含一个JAVA的web应用容器，其中设置了PostStart和PreStop回调函数。即在容器创建成功后，复制/sample.war到/app文件夹中。而在容器终止之前，发送HTTP请求到http://monitor.com:8080/waring，即向监控系统发送警告。

测试启动和停止钩子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@pengfei-master1 pod]# cat >pre-start.yaml>>EOF
apiVersion: v1
kind: Pod
metadata:
  name: pre-start-demo1
  labels:
    app: pre-start-demo1
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
    lifecycle:
      postStart:
        exec:
          command: ["/bin/bash","-c", "echo 'test' >/usr/share/nginx/html/index.html"]
      preStop:
        exec:
          command: ["/bin/bash","-c","nginx -s stop"]
    ports:
    - containerPort: 80
      name: http   
EOF

查看pod

1
2
3
4
5
[root@pengfei-master1 pod]# kubectl get pods -o wide
NAME              READY   STATUS    RESTARTS   AGE   IP              NODE            NOMINATED NODE   READINESS GATES
pre-start-demo1   1/1     Running   0          61s   10.244.128.88   pengfei-node1   <none>           <none>
[root@pengfei-master1 pod]# curl 10.244.128.88
test

优雅的删除资源对象

当用户请求删除含有pod的资源对象时（如RC、deployment等），K8S为了让应用程序优雅关闭（即让应用程序完成正在处理的请求后，再关闭软件），K8S提供两种信息通知：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
1）默认：K8S通知node执行docker stop命令，docker会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认超时时间（30s），会继续发送SIGKILL的系统信号强行kill掉进程。
2）使用pod生命周期（利用PreStop回调函数），它执行在发送终止信号之前。
默认情况下，所有的删除操作的优雅退出时间都在30秒以内。kubectl delete命令支持--grace-period=的选项，以运行用户来修改默认值。0表示删除立即执行，并且立即从API中删除pod。在节点上，被设置了立即结束的的pod，仍然会给一个很短的优雅退出时间段，才会开始被强制杀死。如下:
......
    spec:
      containers:
      - name: nginx-demo
        image: centos:nginx
        lifecycle:
          preStop:
            exec:
              # nginx -s quit gracefully terminate while SIGTERM triggers a quick exit
              command: ["/usr/local/nginx/sbin/nginx","-s","quit"]
        ports:
          - name: http
            containerPort: 80    
......

总结：

pod在整个生命周期中有非常多的用户行为：

1
2
3
4
1、初始化容器完成初始化
2、主容器启动后可以做启动后钩子
3、主容器结束前可以做结束前钩子
4、在主容器运行中可以做一些健康检测，如startupprobe、livenessprobe，readnessprobe

实战：通过钩子优雅停机

背景

1
在 Kubernetes 中，每次微服务的代码发布都意味着创建新版本的 pod 并删除旧 pod，如果部署不够优雅的话，可能出现如下两个问题：
  1. 正在处理请求的pod被删除，在请求没有做幂等处理的情况下，就会出现数据重复、数据错误，亦或导致分布式系统数据不一致；
  2. Kubernetes 将流量路由到已被删除的 pod，导致处理请求失败造成用户体验不佳。
    所以，为了让代码发布的部署过程不影响业务的正常运行和用户无感知，我们需要实现容器的优雅停机。

容器的生命周期钩子

1
在介绍优雅停机之前，我们先来了解下k8s的容器都有哪些生命周期钩子？作用是什么？要怎么使用？

  • Kubernetes的容器有两种生命周期钩子（Lifecycle Hooks）：

    PostStart
    这个钩子会在容器被创建后立即执行，但无法保证会在容器的起始点 ENTRYPOINT之前执行，如果执行时间太长，将会阻止Pod状态进入running，可用于数据初始化、容器启动回调等场景。如果需要保证在应用程序启动前就要执行完的任务，可以考虑放在初始化容器( Init Containers)中去实现。
    PreStop
    这个钩子会在容器被结束前执行，执行期间Pod状态为 Terminating，运行时间受终止宽限期（ terminationGracePeriodSeconds）约束，超出宽限期Pod将被强制杀死，可用于容器回收前的数据清理、优雅停机等场景。

1
上述的两个钩子（PostStart 和 PreStop）都有四种类型，分别为：exec、httpGet、tcpSocket 和 sleep。由于这四种钩子类型在 PostStart 和 PreStop 中的使用方法一致，下面以 PreStop 为例介绍这四种钩子类型的使用方法
  • exec（执行shell指令，可以是指令或shell脚本， 退出状态码为 0则为成功）
1
2
3
4
5
6
7
8
9
10
11
# shell指令模式
lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "echo 'Container is stopping'"]

# shell脚本模式
lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "/data/scripts/preStop.sh"]
  • httpGet（执行http get请求，响应状态码在[200,400)区间则为成功
1
2
3
4
5
6
7
lifecycle:
  preStop:
    httpGet:
      path: /shutdown  # 请求的uri
      port: 8080       # 端口
      host: api.yilingyi.com  # 主机域名，不加该字段将请求Pod本身
      scheme: HTTP     # http协议，默认值HTTP，支持HTTP、HTTPS
  • tcpSocket（执行tcp socket请求， TCP连接成功建立则为成功）
1
2
3
4
lifecycle:
  preStop:
    tcpSocket:
      port: 8080
  • sleep（将容器暂停5秒，Kubernetes 1.30的新特性 PodLifecycleSleepAction，待验证）
1
2
3
4
lifecycle:
  preStop:
    sleep:
      seconds: 5

请注意，如果 PostStart 或 PreStop 回调失败，容器将被杀死，所以回调处理的程序应尽量轻量级及把控好执行的时间。

微服务优雅停机实现

1
本次将以k8s + SpringBoot + Nacos作为案例，介绍在实际业务场景中如何实现微服务的优雅停机，从而实现代码发布时的零宕机。
  • 首先，先看看pod的默认删除过程：
1
2
3
4
5
6
7
8
9
10
11
1. Kube-apiserver接收到pod的删除请求，在Etcd上更新pod的状态为Terminating；
2. Kubelet 清理节点上容器相关的资源，如存储、网络；
3. Kubelet向容器发送SIGTERM，如果容器内进程没有任何配置，则容器立即退出。
4. 如果容器在默认的 30 秒内没有退出，Kubelet 将发送 SIGKILL 并强制其退出。
	可以看出，在没有配置优雅停机之前，pod的删除相当暴力，所以为了更加优雅，我们加入了preStop hook，和将终止宽限期延长，具体实现如下：
1.  preStop hook做了两件事情：
    1）nacos反注册（也称 实例注销），确保在实例关闭期间不会再有新的请求被路由到该实例。
    2)  sleep 35s，nacos客户端的实例缓存为30s，30s后会重新拉取实例信息，超时为10s，一般不用10s这么长，所以我们设置为35s。
2.  springboot开启优雅停机后，最大等待时间为30s。
3.  terminationGracePeriodSeconds默认为30s，远小于preStop和springboot的时间之和，所以我们需要将其调大，我这里设置的是60s。
4.  其实在terminationGracePeriodSeconds耗尽后，k8s还给了一个2s的额外宽限期，最后才执行SIGKILL。
操作步骤
1
2
3
4
5
6
7
8
	在SpringBoot > 2.3.0的版本后支持应用程序优雅停机，需要在java微服务的配置中设置如下两个属性，这一步很重要！！！
server:
  # 默认值immediate:即立即关闭，graceful:即优雅停机
  shutdown: graceful
spring:
  lifecycle:
    # 优雅停机最大等待时间，默认30s
    timeout-per-shutdown-phase: 30s
  • 在微服务的yaml文件加上优雅停机的配置：通过env定义POD_IP获取当前Pod的ip，传递给preStop进行nacos反注册。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: v1
kind: Pod
metadata:
  name: sre-yilingyi
spec:
  containers:
  - name: sre-yilingyi
    image: 'sre/yilingyi:1.0.0'
    env:
      - name: POD_IP
        valueFrom:
          fieldRef:
            apiVersion: v1
            fieldPath: status.podIP
    lifecycle:
      preStop:
        exec:
          command:
            - /bin/sh
            - '-c'
            - >
              curl -s --connect-timeout 10 -m 20 -X POST "http://nacos.yilingyi.com:8848/nacos/v1/ns/instance?port=8080&healthy=true&ip=${POD_IP}&weight=1&enabled=false&serviceName=sre-yilingyi&encoding=GBK&namespaceId=production" && sleep 35
  terminationGracePeriodSeconds: 60

至此，完成微服务的优雅停机配置。

Thank you for your accept. mua！
-------------本文结束感谢您的阅读-------------