写点什么

【云原生 | 从零开始学 Kubernetes】十二、k8spod 的生命周期与容器钩子

作者:泡泡
  • 2022 年 9 月 28 日
    河北
  • 本文字数:3781 字

    阅读完需:约 12 分钟

【云原生 | 从零开始学Kubernetes】十二、k8spod的生命周期与容器钩子

Init 容器

Pod 里面可以有一个或者多个容器,部署应用的容器可以称为主容器,在创建 Pod 时候,Pod 中 可以有一个或多个先于主容器启动的 Init 容器,这个 init 容器就可以成为初始化容器,初始化容器一旦执行完,它从启动开始到初始化代码执行完就退出了,它不会一直存在,所以在主容器启动之前执行初始化,初始化容器可以有多个,多个初始化容器是要串行执行的,先执行初始化容器 1,在执行初始化容器 2 等,等初始化容器执行完初始化就退出了,然后再执行主容器,主容器一退出,pod 就结束了,主容器退出的时间点就是 pod 的结束点,它俩时间轴是一致的;


Init 容器就是做初始化工作的容器。可以有一个或多个,如果多个按照定义的顺序依次执行,只有所有的初始化容器执行完后,主容器才启动。由于一个 Pod 里的存储卷是共享的,所以 Init Container 里产生的数据可以被主容器使用到,Init Container 可以在多种 K8S 资源里被使用到,如 Deployment、DaemonSet, StatefulSet、Job 等,但都是在 Pod 启动时,在主容器启动前执行,做初始化工作。


Init 容器与普通的容器区别是:


1、Init 容器不支持 Readiness,因为它们必须在 Pod 就绪之前运行完成


2、每个 Init 容器必须运行成功,下一个才能够运行


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


[root@k8smaster node]# vim init.yamlapiVersion: v1kind: Podmetadata:  name: myapp-pod  labels:    app: myappspec:  containers:  - name: myapp-container    image: busybox:1.28    command: ['sh', '-c', 'echo The app is running! && sleep 3600']  initContainers:  - name: init-myservice    image: busybox:1.28    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]  - name: init-mydb    image: busybox:1.28    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"] #上面两段长的是myservice的svc和mydb的svc[root@k8smaster node]# kubectl apply -f init.yaml pod/myapp-pod created[root@k8smaster node]# kubectl get pods NAME                    READY   STATUS     RESTARTS   AGEmyapp-pod               0/1     Init:0/2   0          7s#发现一直在初始化,查看一下日志[root@k8smaster node]# kubectl logs myapp-podError from server (BadRequest): container "myapp-container" in pod "myapp-pod" is waiting to start: PodInitializing#有个container是waiting状态,去yaml看看until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; #这是在解析myservice的svc,解析到才成功,不然就会一直循环,我们没有创建,所以一直卡在这里!
[root@k8smaster node]# vim service.yaml---apiVersion: v1kind: Servicemetadata: name: myservicespec: ports: - protocol: TCP port: 80 targetPort: 9376---apiVersion: v1kind: Servicemetadata: name: mydbspec: ports: - protocol: TCP port: 80 targetPort: 9377 [root@k8smaster node]# kubectl apply -f service.yaml service/myservice createdservice/mydb created
[root@k8smaster node]# kubectl get pods NAME READY STATUS RESTARTS AGEmyapp-pod 1/1 Running 0 4m46s#成功启动
[root@k8smaster node]# kubectl logs myapp-podThe app is running![root@k8smaster node]# kubectl describe pods myapp-pod#也可以看启动了哪些容器 在下面
复制代码

主容器

容器钩子

初始化容器启动之后,开始启动主容器,在主容器启动之前有一个 post start hook(容器启动后钩子)和 pre stop hook(容器结束前钩子),无论启动后还是结束前所做的事我们可以给它放两个钩子,这个钩子就表示用户可以用它来钩住一些命令,来执行它,做开场前的预设,结束前的清理,如 awk 有 begin,end,和这个效果类似。


postStart: 该钩子在容器被创建后立刻触发,通知容器它已经被创建。如果该钩子对应的 hook handler 执行失败,则该容器会被杀死,并根据该容器的重启策略决定是否要重启该容器,这个钩子不需要传递任何参数。


preStop: 该钩子在容器被删除前触发,其所对应的 hook handler 必须在删除该容器的请求发送 给 Docker daemon 之前完成。在该钩子对应的 hook handler 完成后不论执行的结果如何,Docker daemon 会发送一个 SGTERN 信号量给 Docker daemon 来删除该容器,这个钩子不需要传递任何参数。


在 k8s 中支持两类对 pod 的检测


第一类叫做 livenessprobe(pod 存活性探测): 存活探针主要作用是,用指定的方式检测 pod 中的容器应用是否正常运行,如果检测失败,则认为容器不健康,那么 Kubelet 将根据 Pod 中设置的 restartPolicy 来判断 Pod 是否要进行重启操作,如果容器配置中没有配置 livenessProbe,Kubelet 将认为存活探针探测一直为成功状态。 get pods 里的 status 就是存活探测


第二类是状态检 readinessprobe(pod 就绪性探测):用于判断容器中应用是否启动完成,当探测成功后才使 Pod 对外提供网络访问,设置容器 Ready 状态为 true,如果探测失败,则设置容器的 Ready 状态为 false。

创建 pod 需要经过哪些阶段?

当用户创建 pod 时,这个请求给 apiserver,apiserver 把创建请求的状态保存在 etcd 中;接下来 apiserver 会请求 scheduler 来完成调度,如果调度成功,会把调度的结果(如调度到哪个节点上了,运行在哪个节点上了,把它更新到 etcd 的 pod 资源状态中)保存在 etcd 中,一旦存到 etcd 中并且完成更新以后,如调度到 k8snode1 上,那么 node1 节点上的 kubelet 通过 apiserver 当中的状态变化知道有一些任务被执行了,所以此时此 kubelet 会拿到用户创建时所提交的清单,这个清单会在当前节点上运行或者启动这个 pod,如果创建成功或者失败会有一个当前状态,当前这个状态会发给 apiserver,apiserver 在存到 etcd 中;在这个过程 中,etcd 和 apiserver 一直在打交道,不停的交互,scheduler 也参与其中,负责调度 pod 到合适的 node 节点上,这个就是 pod 的创建过程.


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


1、初始化容器完成初始化


2、主容器启动后可以做启动后钩子


3、主容器结束前可以做结束前钩子


4、在主容器运行中可以做一些健康检测,如 liveness probe,readness probe

Pod 容器探测和钩子

容器钩子:postStart 和 preStop

postStart:容器创建成功后,运行前的任务,用于资源部署、环境准备等。


preStop:在容器被终止前的任务,用于优雅关闭应用程序、通知其他系统等。


...... containers: - image: sample name: war  lifecycle:   postStart:   #钩子   exec:    command:   #命令    - “cp”     - “/sample.war”     - “/app” prestop:     #钩子  httpGet:     #httpget的探针   host: monitor.com      path: /waring   port: 8080   scheme: HTTP ...... 
以上示例中,定义了一个 Pod,包含一个 JAVA 的 web 应用容器,其中设置了 PostStart和PreStop 回调函数。即在容器创建成功后,复制/sample.war 到/app 文件夹中。而在容器终止之前,发送 HTTP 请求到 http://monitor.com:8080/waring,即向监控系统发送警告。
#可以看帮助文档[root@k8smaster node]# kubectl explain pods.spec.containers.lifecycle
复制代码


优雅的删除资源对象


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


默认:K8S 通知 node 执行 docker stop 命令,docker 会先向容器中 PID 为 1 的进程发送系统信号 SIGTERM,然后等待容器中的应用程序终止执行,如果等待时间达到设定的超时时间,或者默认超时时间(30s),会继续发送 SIGKILL 的系统信号强行 kill 掉进程。


使用 pod 生命周期(利用 PreStop 回调函数),它执行在发送终止信号之前。默认情况下,所有的删除操作的优雅退出时间都在 30 秒以内。kubectl delete 命令支持--grace-period=的选项,以运行用户来修改默认值。0 表示删除立即执行,并且立即从 API 中删除 pod。在节点上,被设置了立即结束的的 pod,仍然会给一个很短的优雅退出时间段,才会开始被强制杀死。如下:


spec:  containers:  - name: nginx-demo  image: centos:nginx  lifecycle:  preStop: #钩子 exec:  command: ["/usr/local/nginx/sbin/nginx","-s","quit"]  #删除之前会先停掉nginx再删除容器 ports:  - name: http  containerPort: 80
复制代码

写在最后

创作不易,如果觉得内容对你有帮助,麻烦给个三连关注支持一下我!如果有错误,请在评论区指出,我会及时更改!

目前正在更新的系列:从零开始学 k8s

感谢各位的观看,文章掺杂个人理解,如有错误请联系我指出~

发布于: 2022 年 09 月 28 日阅读数: 21
用户头像

泡泡

关注

做最好的知识分享 云计算/云原生 2022.08.25 加入

CSDN万粉博主

评论

发布
暂无评论
【云原生 | 从零开始学Kubernetes】十二、k8spod的生命周期与容器钩子_Docker_泡泡_InfoQ写作社区