重用从属服务的就绪性探测以控制服务的启动

时间:2019-09-19 13:54:45

标签: kubernetes dependencies initialization kubernetes-helm readinessprobe

我有一个后端服务,可以使用Kubernetes(带有Helm图表)来控制。该后端服务连接到数据库(MonogoDB,它确实发生了)。在数据库准备好接收连接之前,没有必要启动后端服务(后端将通过重试来处理丢失的数据库,但是这样做会浪费资源并分散日志内容错误消息)。

为此,我相信我可以add an init container到后端,并让该初始化容器等待(或轮询)直到数据库准备就绪。看来这是init containers

的预期用途之一
  

由于init容器在任何应用程序容器开始运行之前便已完成,因此init容器提供了一种机制来阻止或延迟应用程序容器的启动,直到满足一系列前提条件为止。

也就是说,让 my 服务的初始化容器执行与数据库readiness probe相同的 操作。这又意味着将代码从数据库的配置(Helm图表)复制并粘贴到后端的配置(或Helm图表)。不理想。有更容易的方法吗?有没有办法我可以声明到Kubernetes,直到知道数据库已经准备就绪,才可以启动我的服务?

1 个答案:

答案 0 :(得分:-1)

如果我对您的理解正确。 从Mongo DB的角度来看,使用readinessprobe可以使一切正常运行:

根据documentation

  

kubelet使用就绪性探测器来了解何时Container准备开始接受流量。当Pod的所有容器都准备就绪时,即视为准备就绪。此信号的一种用法是控制将哪些Pod用作服务的后端。 未就绪的Pod将从服务负载平衡器中删除

从后端的角度来看,您可以使用initcontainer-一个缺点是,当您的后端服务将启动一次(成功初始化initcontainer之后)时,DB pod可以为流量提供服务了将失败,后端服务将填充您的错误消息-如前所述。

因此,我可以建议使用here中描述的解决方案。

在后端部署中,您可以结合其他准备情况探针来验证您的主部署是否准备好提供服务,可以使用sidecar容器来处理此过程(验证与主db服务的连接并在静态文件中写入fe信息每个特定时间段)。例如,请使用mongoDBCheck sidecar查看EKG library。 或者,只需将exec命令作为脚本在sidecar容器中运行的结果即可:

readinessProbe:
  exec:
    command:
      - find
      - alive.txt
      - -mmin
      - '-1'
  initialDelaySeconds: 5
  periodSeconds: 15

希望获得帮助