我一直试图调试K8S部署中一个非常奇怪的延迟。我追踪到了下面的简单复制。看起来,如果我在一个启动探针上设置了一个initialDelaySeconds,或者让它保持为0,并且有一个失败,那么这个探测在一段时间内不会再次运行,最后至少会延迟1-1.5分钟进入就绪状态:true状态。
我在本地运行Ubutunu18.04和microk8s v1.19.3,其版本如下:
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就可以进入就绪状态了吗?
任何想法都会受到极大的赞赏。
发布于 2020-12-07 08:40:12
实际上,我在注释中犯了一个错误,您可以在startupProbe中使用startupProbe,但是您应该选择使用failureThreshold和periodSeconds。
如前所述,这里
Kubernetes探针
Kubernetes支持≤1.15版本的就绪性和活性探测。启动探针在1.16中添加为alpha特性,在1.18中升级到beta (警告: 1.16不支持几个Kubernetes API。使用此迁移指南检查兼容性)。所有探针都具有以下参数:
那么,为什么要使用failureThreshold和periodSeconds?
考虑一个应用程序,它偶尔需要下载大量数据或在进程开始时执行昂贵的操作。由于initialDelaySeconds是一个静态数字,所以我们总是不得不采取最坏的情况(或者扩展可能影响长时间运行行为的failureThreshold ),并且等待很长时间,即使应用程序不需要执行长时间运行的初始化步骤。使用启动探测,我们可以配置failureThreshold和periodSeconds来更好地建模这种不确定性。例如,将failureThreshold设置为15,将periodSeconds设置为5,意味着应用程序将在失败前启动15 (15)x5(5)= 75s。
另外,如果您需要更多的信息,请查看这个媒体上的文章。
引用kubernetes 文档关于用启动探针保护慢速启动容器的话
有时,您必须处理遗留应用程序,这些应用程序在第一次初始化时可能需要额外启动时间。在这种情况下,很难设置活性探测参数,而不影响对触发这种探测的死锁的快速响应。诀窍是使用相同的命令HTTP或TCP设置一个启动探测,其failureThreshold * periodSeconds足够长,足以覆盖更糟糕的启动时间。 因此,前面的示例将成为:
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。
https://stackoverflow.com/questions/65113084
复制相似问题