当前位置: 首页 > 知识库问答 >
问题:

crashloopbackoff-back-off重新启动失败的容器

徐文彬
2023-03-14
    null
apiVersion: apps/v1
kind: Deployment
metadata:
  name: sv-premier
spec:
  selector:
    matchLabels:
      app: sv-premier
  template:
    metadata:
      labels:
        app: sv-premier
    spec:
      volumes:
      - name: google-cloud-key
        secret:
          secretName: gcp-key
      containers:
      - name: sv-premier
        image: gcr.io/proto/premiercore1:latest
        imagePullPolicy: Always
        command: ["echo", "Done deploying sv-premier"]
        volumeMounts:
        - name: google-cloud-key
          mountPath: /var/secrets/google
        env:
        - name: GOOGLE_APPLICATION_CREDENTIALS
          value: /var/secrets/google/key.json
        ports:
        - containerPort: 8080
      imagePullSecrets:
      - name: imagepullsecretkey

日志-

kubectl描述pods podname

==========================

标签:APP=SV-Premier

POD-TEMPLATE-HASH=6B77DDD747

注释:

Container ID:  docker://141126d732409427fe39b405865f88856ac4e1d8586112797fc5bf4fdfbe317c

Image:         gcr.io/proto/premiercore1:latest

Image ID:      docker-pullable://gcr.io/proto/premiercore1@sha256:b3800ccca3f30725d5c9235dd349548f0fcfe309f51883d8af16397aef2c3953

Port:          8080/TCP

Host Port:     0/TCP

Command:

  echo

  Done deploying sv-premier

State:          Waiting

  Reason:       CrashLoopBackOff

Last State:     Terminated

  Reason:       Completed

  Exit Code:    0

  Started:      Tue, 04 Feb 2020 15:00:51 +0530

  Finished:     Tue, 04 Feb 2020 15:00:51 +0530

Ready:          False

Restart Count:  13

Environment:

  GOOGLE_APPLICATION_CREDENTIALS:  /var/secrets/google/key.json

Mounts:

  /var/run/secrets/kubernetes.io/serviceaccount from default-token-s4jgd (ro)

  /var/secrets/google from google-cloud-key (rw)

条件:

类型状态

初始化为真

Type:        Secret (a volume populated by a Secret)

SecretName:  gcp-key

Optional:    false

默认值-token-s4jgd:

Type:        Secret (a volume populated by a Secret)

SecretName:  default-token-s4jgd

Optional:    false

QoS类:BestEffort

节点选择器:

             node.kubernetes.io/unreachable:NoExecute for 300s

正常启动45m(x4超过46m)库贝莱特,码头-桌面启动容器sv-premier

正常拉动45米(x5超过46米)kubelet,docker-desktop拉动图像“gcr.io/proto/premiercore1:最新”

警告退避92s(x207超过46m)kubelet,Docker-桌面退避重新启动容器失败

我很困惑为什么我的容器要退出。无法启动。

请指导。

共有1个答案

常光明
2023-03-14

用一个长时间运行的任务示例更新您的deployment.yaml。

command: ["/bin/sh"]
args: ["-c", "while true; do echo Done Deploying sv-premier; sleep 3600;done"]

这将使您的容器在部署后进入睡眠状态,并且每小时都会记录一次消息。

请在此阅读有关pod生命周期容器状态的更多信息

 类似资料:
  • 我有一个Ubuntu Xenial容器,在我的Arch Linux计算机上安装了amd64体系结构。容器工作正常。但是,当我第二次尝试启动容器时,出现以下错误: 容器启动失败。 要获得更多详细信息,请在前台模式下运行容器。 其他信息可以通过设置--logfile和--log优先级选项获得。 是什么原因造成的? 在使用-F、-logfile和--logpriority选项运行后得到了这个。 lxc开

  • 问题内容: 我在node.js应用程序中将kue用于延迟的工作。 我有一些问题需要弄清楚如何才能使用kue的API重新启动作业,而不必使用redis命令将作业的ID从失败的作业列表手动移至非活动的作业列表。 使用kue可以吗? 我不想设置固定的重试次数-我只想重试特定的作业。 也欢迎提出关于维护良好的替代kue的建议。 问题答案: 我不知道这是否有效,但是您可以尝试将作业的状态重置为活动状态,然后

  • 问题内容: 我遇到错误了; 问题答案: 错误是 看来您有一个指的是您尚未声明的。 您需要具有以下声明

  • 我有一个docker撰写yml文件,定义了几个容器: 数据库 网络服务 我在“web服务”中定义了“依赖于”,在“数据库”之后开始。这两个容器都定义为“始终重新启动”。 我一直在谷歌上搜索,在系统重启时找不到关于容器启动顺序的清晰信息。docker守护进程是否读取docker compose yml文件并启动数据库,然后启动web服务?或者它是如何工作的?

  • 问题内容: 今天,我使用appcontainers / mediawiki docker映像部署了MediaWiki实例,现在遇到一个新问题,无法找到任何线索。尝试使用以下方法附加到mediawiki前端容器后: 出于我忽略的原因,它在我的配置上做出回答,还尝试: 我确实收到错误消息附近的内容: 这是我的新问题,因为此容器永不停止重新启动。我看到使用总是返回STATUS的状态。 问题是,我能够停止