kubernetes CrashLoopBackOff在pod上间歇运行

vwkv1x7d  于 2022-12-22  发布在  Kubernetes
关注(0)|答案(1)|浏览(171)

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

vddsk6oq1#

部署不适合您的用例。部署是为永久运行的服务而设计的,例如,为注册到消息队列的rest服务或worker提供服务(似乎与您的用例紧密相关)。当容器停止时,如您所指出的,kubernetes将重新启动它,但如果这种情况经常发生,则认为它处于错误状态。
您可能有两种选择:
1.重新设计应用程序,使其在完成工作后不会停止,而是再次侦听队列中的新消息
1.从部署切换到每5秒运行一次的cron作业(并从容器命令中删除睡眠时间)

相关问题