时间戳

首页 > 解决方案 > exec 类型容器探测超时

kubernetes - exec 类型容器探测超时

问题描述

我有一个关于 openshift/kubernetes 中 exec 类型容器探测超时的问题。我的 openshift 版本是 3.11，其中 kubernetes 版本是 1.11

我已经定义了一个准备就绪探测，如下所述

readinessProbe:
  exec:
    command:
    - /bin/sh
    - -c
    - check_readiness.sh
  initialDelaySeconds: 30
  periodSeconds: 30
  failureThreshold: 1

根据 openshift 文档 timeoutSeconds 参数对 exec 类型探针的容器探针没有影响。check_readiness.sh 脚本是一个长时间运行的脚本，可能需要 5 分钟以上才能返回。容器启动后，我登录到容器以检查脚本的状态。我发现大约 2 分钟后，另一个 check_readiness.sh 脚本启动了，而第一个脚本仍在运行，大约 2 分钟后又启动了另一个。

有人可以解释一下 openshift 或 kubernetes 在这种情况下对探测器做了什么吗？

标签： kubernetesopenshift

解决方案

是的，没错，容器执行检查不支持这个timeoutSeconds论点。但是，正如文档所述timeout，您可以使用以下命令实现类似的功能：

[...]
      readinessProbe:
        exec:
          command:
            - /bin/bash
            - '-c'
            - timeout 60 /opt/eap/bin/livenessProbe.sh 
        periodSeconds: 10
        successThreshold: 1
        failureThreshold: 3
[...]

因此，在您的情况下，我猜测正在发生以下情况：

  • 您的容器已启动。
  • 在持续时间initialDelaySeconds（在您的情况下为 30 秒）之后，将启动第一个就绪探测并执行您的脚本。
  • 然后，在periodSeconds（30 秒）之后启动下一个探测，在您的情况下，会导致脚本第二次执行。
  • 每隔 30 秒，脚本会再次启动，即使之前的迭代仍在运行。

因此，在您的情况下，您应该使用timeout文档中看到的命令或增加periodSeconds以确保两个脚本不会同时执行。

一般来说，我建议您确保您的就绪检查脚本返回的速度比几分钟快得多，以避免此类问题。

推荐阅读