CrashLoopBackOff在pod上间歇性运行

Question

我有一个Kubernetes集群，使用AWS上的EKS(弹性Kubernetes服务)和ECR(弹性容器存储库)运行。我的一个具体部署运行良好的前两/三次重启，然后总是在图像拉初始化一个CrashLoopBackOff，等待BackOff的长度，然后运行良好，再重复这个过程。

这些pod由一个docker容器组成，它等待来自消息队列的消息，运行一个进程，然后docker容器停止，部署将重新启动容器，始终从ECR中拉出容器。

由于这些pod旨在处理大量流量并具有较短的运行时间(~1-30秒)，因此让每个pod在拉出时立即进入CrashLoopBackOff，然后在实际运行之前等待五分钟，等待时间很长，这很烦人。

我已经环顾四周的任何答案，但我所看到的所有问题都描述了CrashLoopBackOff继续无限期运行的情况，而不是pod进入CrashLoopBackOff然后在等待时间完成后成功运行。

我已经检查了有这个问题的pod的日志，没有任何东西表明有任何错误。我想知道是否有一种方法来"暂停"。容器后，它被拉，以确保它是在docker命令实际运行之前正确运行?或任何其他方式延迟CrashLoopBackOff可配置的秒数?我加了"睡眠15";到我的docker容器命令的开始，但这并没有帮助解决问题。

部署Yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: piml-xgboost
spec:
replicas: 5
selector:
matchLabels:
app: piml-xgboost
template:
metadata:
labels: 
app: piml-xgboost
spec:
serviceAccountName: cluster-service-account
containers:
- name: piml-unet
image: 'ecr_path'
imagePullPolicy: "Always"
resources:
requests:
memory: "500Mi"
limits:
memory: "4Gi"
env:
- name: BROKER_URL
value: 'amqp_broker_url'
- name: QUEUE
value: 'amqp_queue'
- name: method
value: xgboost
- name: k8s
value: 'True'

典型的'kubectl get pods'输出:

NAME                                    READY   STATUS             RESTARTS          AGE
piml-xgboost-77d48f9db8-5txmz           0/1     CrashLoopBackOff   959 (2m51s ago)   3d21h
piml-xgboost-77d48f9db8-gs542           0/1     CrashLoopBackOff   532 (108s ago)    2d1h
piml-xgboost-77d48f9db8-pmvlg           0/1     CrashLoopBackOff   979 (44s ago)     3d23h
piml-xgboost-77d48f9db8-wckmk           0/1     CrashLoopBackOff   533 (59s ago)     2d1h
piml-xgboost-77d48f9db8-wz657           0/1     CrashLoopBackOff   712 (2m39s ago)   2d21h

Dockerfile中的Docker命令

CMD sleep 5;/usr/bin/amqp-consume --url=$BROKER_URL -q $QUEUE -c 1 ./docker_script.py

Answer 1

部署不适合您的用例。部署是为永久运行的服务设计的，例如为rest服务或注册到消息队列的工作人员提供服务(似乎与您的用例紧密相关)。当容器停止时，kubernetes将重新启动它，但如果这种情况发生得更频繁，则认为它处于错误状态。

你可以有两个选择:

1. 重新设计应用程序，使其在完成工作后不停止，而是在队列中再次侦听新消息

2. 从部署切换到每5秒运行一次的cron作业(并从容器的命令中删除睡眠时间)