【问题标题】:readinessProbe does not seem to wait for initial delayreadinessProbe 似乎没有等待初始延迟
【发布时间】:2020-09-25 17:16:37
【问题描述】:

概述

这是我第一次设置 readinessProbe,所以我可能会遗漏一些非常基本的东西。

我有一个包含两个 pod 的部署。一个运行 nginx,另一个构建应用程序并将资产放入构建目录,这是两个容器共享的卷。构建资产的容器需要一两分钟才能完成。这是我的 deployment.yaml(删节):

 ...
  containers:
  - name: personal-site-container
    readinessProbe:
      exec:
        command:
        - ls
        - /opt/dist/js/app.*.js
      initialDelaySeconds: 120
    image: <username>/<image>:latest
    volumeMounts:
    - name: build-volume
      mountPath: /opt/dist
  - name: nginx-server
    readinessProbe:
      exec:
        command:
        - ls
        - /usr/share/nginx/html/js/app.*.js
      initialDelaySeconds: 120
    image: nginx:1.19.0
    ports:
    - containerPort: 80
    volumeMounts:
    - name: build-volume
      mountPath: /usr/share/nginx/html

我预计会发生什么

因为ls命令会在资产构建完成时成功,但在同名资产不存在时会失败,所以我预计探针将在两分钟后运行,然后将两个容器的状态设置为就绪.

实际发生的情况

当我应用此部署时,对于第一个几乎,一切都按预期进行(个人站点容器中的日志显示静态资产正在构建并且 0/2 容器处于就绪状态)1分钟,然后 pod 进入崩溃退避循环。当我查看事件时:

k get event --field-selector involvedObject.name=personal-site-5b595d46db-tmsrb

我看到一个“后退重启失败的容器”事件,该事件属于“警告”类型,但没有任何类型的错误。

问题

我还能做些什么来调查为什么 readinessProbe 在更改就绪状态之前似乎没有等待 120 秒?如果解决方案很明显,我在这里缺少什么?

【问题讨论】:

  • 你的容器在他生成文件后做了什么?它是睡觉还是存在?你知道哪个容器崩溃了吗?你有 pod 日志吗?

标签: kubernetes


【解决方案1】:

“Back-off restarting failed container”与就绪探测无关。失败的就绪探测永远不会导致容器被杀死或重新启动。它只负责考虑容器准备好服务请求并将其添加到服务的负载均衡器中。

另一个构建应用程序并将资产放入构建目录

我在这里怀疑的是个人站点容器构建资产并退出。由于默认重启策略为always,容器重启,以此类推,进入“退避重启”循环。

顺便说一句,个人站点容器的就绪性探测没有多大意义。首先,它不属于任何服务,其次它是为了完成工作并退出(据我所知)。你可能想看看 Kubernetes jobs

【讨论】:

  • 就是这样,谢谢!实际上,我最终只是重写了图像,以便在构建图像时构建资产。
  • 我很想知道是否可以在部署后进行构建,但结果令人头疼。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-12-06
  • 1970-01-01
  • 1970-01-01
  • 2019-06-03
  • 2018-10-09
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多