我有一个Kubernetes集群在AWS上使用EKS(弹性Kubernetes服务)和ECR(弹性容器存储库)运行。我的一个特定部署在前两三次重新启动时运行良好,然后总是在映像拉取时初始化CrashLoopBackOff,等待BackOff的长度,然后运行良好,然后重复该过程。
这些pod由一个Docker容器组成,该容器等待来自消息队列的消息,运行一个进程,然后Docker容器停止,部署将在此时重新启动容器,始终从ECR中拉取容器。
由于这些Pod旨在处理大量流量,并且运行时间较短(~1-30秒),因此让每个Pod在拉取时立即进入CrashLoopBackoff,然后等待五分钟才真正运行,这会带来大量的等待时间,令人恼火。
我已经四处寻找了这个问题的答案,但是我看到的所有问题都描述了CrashLoopBackOff无限期继续运行的情况,而不是pod进入CrashLoopBackOff然后在等待时间结束后成功运行的情况。
我已经检查了有这个问题的pod的日志,没有任何东西表明有任何错误。我想知道是否有一种方法可以在容器被拉出来之后“暂停”它,以确保它在docker命令实际运行之前正确启动和运行?或者有任何其他方法可以延迟CrashLoopBackOff一个可配置的秒数?我已经添加了“睡眠15;“开始我的码头集装箱命令,但这并没有帮助的问题。
展开月
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 pod”输出:
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
1条答案
按热度按时间vddsk6oq1#
部署不适合您的用例。部署是为永久运行的服务而设计的,例如,为注册到消息队列的rest服务或worker提供服务(似乎与您的用例紧密相关)。当容器停止时,如您所指出的,kubernetes将重新启动它,但如果这种情况经常发生,则认为它处于错误状态。
您可能有两种选择:
1.重新设计应用程序,使其在完成工作后不会停止,而是再次侦听队列中的新消息
1.从部署切换到每5秒运行一次的cron作业(并从容器命令中删除睡眠时间)