我是靠谱客的博主 神勇口红,最近开发中收集的这篇文章主要介绍【博客553】控制 Pod 内容器启动顺序1、对于单体服务,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

1、对于单体服务

解决方法:在 postStart 执行当前容器的健康检查代码就可以控制容器的启动顺序

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "Command to check if container is ready"]

原理:为什么在 postStart 执行当前容器的健康检查代码就可以控制容器的启动顺序

Kubernetes 在容器创建后立即发送 postStart 事件。 然而,postStart 处理函数的调用不保证早于容器的入口点(entrypoint)的执行。postStart 处理函数与容器的代码是异步执行的,但 Kubernetes 的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。

Containers startup is blocked by postStart lifecycle hook

在这个 Issue 里,提出者说某一个容器的 postStart 阻塞了其他容器的启动,K8S 的人却说这是 feature 而不是 bug。 K8S 文档中那句“postStart 处理函数与容器的代码是异步执行的”意思是 postStart Hook 不会阻塞容器启动,因为是“异步的”。

K8S 在启动同一个 Pod 里容器时,其启动顺序会按照配置文件中的顺序去启动(注意,在这里它并不会等容器启动完成才继续),而当你为某一个容器增加 postStart Hook 之后,K8S 的启动流程会被这个 Hook 给阻塞住,直到 Hook 完成了,才会继续往下执行。这样一来只需要在容器的 postStart Hook 里执行对当前容器的状态的查询代码、直到容器内进程或服务状态正常才退出,就可以保证在下一个容器启动前,该容器能正常提供服务。

这时候就能理解官方文档中的那句话:

“postStart 处理函数与容器的代码是异步执行的,但 Kubernetes 的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕。”。它的意思是——postStart 处理函数和容器启动是同时被调用的,但是双方的实际执行却是互不干涉的。Kubernetes 的容器管理逻辑不会等待容器启动完成,但是会一直阻塞等待 postStart 处理函数执行完毕。

具体细节:官方文档对于 “postStart 处理函数与容器的代码是异步执行的,但 Kubernetes 的容器管理逻辑会一直阻塞等待 postStart 处理函数执行完毕” 的描述

2、对于分布式服务

解决方法:

1、引入自定义调度器插件来做这个事

例如:官方sigs项目下的这个调度器插件

https://github.com/kubernetes-sigs/scheduler-plugins/blob/master/pkg/coscheduling/README.md

2、通过使用initContainers探测依赖的组件是否正常来决定是否启动自身,直到依赖的服务均正常再启动自己

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: reservation-server
    image: wh/activityreservation:dev
    ports:
      - name: http
        containerPort: 80
        protocol: TCP
    livenessProbe:
        httpGet:
            path: /health
            port: http
        initialDelaySeconds: 60
        periodSeconds: 10
    readinessProbe:
        httpGet:
            path: /api/notice
            port: http
        initialDelaySeconds: 60
        periodSeconds: 10
  initContainers:
    - name: init-redis
      image: busybox:1.31
      command: ['sh', '-c', 'until nslookup redis-server; do echo waiting for redis; sleep 2; done;']
    - name: init-mysql
      image: busybox:1.31
      command: ['sh', '-c', 'until nslookup mysql-server; do echo waiting for mysql; sleep 2; done;']

最后

以上就是神勇口红为你收集整理的【博客553】控制 Pod 内容器启动顺序1、对于单体服务的全部内容,希望文章能够帮你解决【博客553】控制 Pod 内容器启动顺序1、对于单体服务所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(38)

评论列表共有 0 条评论

立即
投稿
返回
顶部