我有一个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