首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >指定了K8S startupProbe和initialDelaySeconds的Pod等待时间太长,无法准备就绪

指定了K8S startupProbe和initialDelaySeconds的Pod等待时间太长,无法准备就绪
EN

Stack Overflow用户
提问于 2020-12-02 17:23:57
回答 1查看 7.4K关注 0票数 14

我一直试图调试K8S部署中一个非常奇怪的延迟。我追踪到了下面的简单复制。看起来,如果我在一个启动探针上设置了一个initialDelaySeconds,或者让它保持为0,并且有一个失败,那么这个探测在一段时间内不会再次运行,最后至少会延迟1-1.5分钟进入就绪状态:true状态。

我在本地运行Ubutunu18.04和microk8s v1.19.3,其版本如下:

  • kubelet: v1.19.3-34+a 56971609ff35a
  • kube-proxy: v1.19.3-34+a 56971609ff35a
  • 集装箱d://1.3.7
代码语言:javascript
复制
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: microbot
  name: microbot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: microbot
  strategy: {}
  template:
    metadata:
      labels:
        app: microbot
    spec:
      containers:
      - image: cdkbot/microbot-amd64
        name: microbot
        command: ["/bin/sh"]
        args: ["-c", "sleep 3; /start_nginx.sh"]
        #args: ["-c", "/start_nginx.sh"]
        ports:
        - containerPort: 80
        startupProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 0  # 5 also has same issue
          periodSeconds: 1
          failureThreshold: 10
          successThreshold: 1
        ##livenessProbe:
        ##  httpGet:
        ##    path: /
        ##    port: 80
        ##  initialDelaySeconds: 0
        ##  periodSeconds: 10
        ##  failureThreshold: 1
        resources: {}
      restartPolicy: Always
      serviceAccountName: ""
status: {}
---
apiVersion: v1
kind: Service
metadata:
  name: microbot
  labels:
    app: microbot
spec:
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: microbot

问题是,如果我在startupProbe中有任何延迟,或者如果出现了初始故障,则吊舱进入初始化:true状态,但已就绪:False和ContainersReady:False。它在1-1.5分钟内不会从这个状态改变。我还没有找到设置的模式。

我也在注释设置中留了下来,这样你就可以看到我想要达到的目的。我所拥有的是一个启动容器,它提供的服务需要几秒钟才能开始。我想让startupProbe稍等一会儿,然后每秒钟检查一次,看看我们是否准备好了。配置似乎有效,但是有一个延迟,我无法跟踪。即使在启动探针经过之后,它也不会将吊舱转换为准备超过一分钟的时间。

在k8s的其他地方是否存在延迟时间的设置,如果一开始还没有准备好的话,那么Pod就可以进入就绪状态了吗?

任何想法都会受到极大的赞赏。

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2020-12-07 08:40:12

实际上,我在注释中犯了一个错误,您可以在startupProbe中使用startupProbe,但是您应该选择使用failureThresholdperiodSeconds

如前所述,这里

Kubernetes探针

Kubernetes支持≤1.15版本的就绪性和活性探测。启动探针在1.16中添加为alpha特性,在1.18中升级到beta (警告: 1.16不支持几个Kubernetes API。使用此迁移指南检查兼容性)。所有探针都具有以下参数:

  • initialDelaySeconds :启动活性或准备状态探针之前要等待的秒数
  • periodSeconds:多长时间检查一次探针
  • timeoutSeconds:将探针标记为超时前的秒数(未通过健康检查)
  • successThreshold :探测通过的最少连续成功检查次数
  • failureThreshold :在将探针标记为失败之前的重试次数。对于活性探针,这将导致吊舱重新启动。对于准备好的探测器,这将标志着吊舱还没有准备好。

那么,为什么要使用failureThresholdperiodSeconds

考虑一个应用程序,它偶尔需要下载大量数据或在进程开始时执行昂贵的操作。由于initialDelaySeconds是一个静态数字,所以我们总是不得不采取最坏的情况(或者扩展可能影响长时间运行行为的failureThreshold ),并且等待很长时间,即使应用程序不需要执行长时间运行的初始化步骤。使用启动探测,我们可以配置failureThresholdperiodSeconds来更好地建模这种不确定性。例如,将failureThreshold设置为15,将periodSeconds设置为5,意味着应用程序将在失败前启动15 (15)x5(5)= 75s。

另外,如果您需要更多的信息,请查看这个媒体上的文章

引用kubernetes 文档关于用启动探针保护慢速启动容器的话

有时,您必须处理遗留应用程序,这些应用程序在第一次初始化时可能需要额外启动时间。在这种情况下,很难设置活性探测参数,而不影响对触发这种探测的死锁的快速响应。诀窍是使用相同的命令HTTP或TCP设置一个启动探测,其failureThreshold * periodSeconds足够长,足以覆盖更糟糕的启动时间。 因此,前面的示例将成为:

代码语言:javascript
复制
ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

由于启动探针,应用程序将有最多5分钟(30 * 10 =300 s)来完成它的启动。一旦启动探测成功一次,活性探测将接管以提供对容器死锁的快速响应。如果启动探针从未成功,容器在300 s后就会被关闭,并且受制于容器的restartPolicy。

票数 11
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/65113084

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档