【问题标题】:Why my pod error "Back-off restarting failed container" when I have `imagePullPolicy: "Always"`当我有`imagePullPolicy:“Always”`时,为什么我的 pod 错误“Back-off restarting failed container”
【发布时间】:2022-01-22 18:48:28
【问题描述】:

当我有 imagePullPolicy: "Always" 时,为什么我的 pod 错误“Back-off restarting failed container”,之前它工作但今天我将它部署到其他机器上,它显示该错误

我的 Yaml:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: couchdb
  labels:
    app: couch
spec:
  replicas: 3
  serviceName: "couch-service"
  selector:
    matchLabels:
      app: couch
  template:
    metadata:
      labels:
        app: couch # pod label
    spec:
      containers:
      - name: couchdb
        image: couchdb:2.3.1
        imagePullPolicy: "Always"
        env:
        - name: NODE_NETBIOS_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: NODENAME
          value: $(NODE_NETBIOS_NAME).couch-service # FQDN in vm.args
        - name: COUCHDB_USER
          value: admin
        - name: COUCHDB_PASSWORD
          value: admin
        - name: COUCHDB_SECRET
          value: b1709267
        - name: ERL_FLAGS
          value: "-name couchdb@$(NODENAME)"
        - name: ERL_FLAGS
          value: "-setcookie b1709267" #   the “password” used when nodes connect to each other.
        ports:
        - name: couchdb
          containerPort: 5984
        - name: epmd
          containerPort: 4369
        - containerPort: 9100
        volumeMounts:
          - name: couch-pvc
            mountPath: /opt/couchdb/data
  volumeClaimTemplates:
  - metadata:
      name: couch-pvc
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi
      selector:
        matchLabels:
          volume: couch-volume      

我描述它:

Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  23s                default-scheduler  Successfully assigned default/couchdb-0 to b1709267node1
  Normal   Pulled     17s                kubelet            Successfully pulled image "couchdb:2.3.1" in 4.368553213s
  Normal   Pulling    16s (x2 over 22s)  kubelet            Pulling image "couchdb:2.3.1"
  Normal   Created    10s (x2 over 17s)  kubelet            Created container couchdb
  Normal   Started    10s (x2 over 17s)  kubelet            Started container couchdb
  Normal   Pulled     10s                kubelet            Successfully pulled image "couchdb:2.3.1" in 6.131837401s
  Warning  BackOff    8s (x2 over 9s)    kubelet            Back-off restarting failed container

我该怎么办?谢谢

【问题讨论】:

  • 嘿! imagePullPolicy 只会配置您获取 docker 图像的方式。不是您的应用程序对失败的反应。您可能需要检查日志和事件(描述您的 pod)以查看“为什么”它正在重新启动。也可以查看kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/…。对于调试,将其设置为“从不”会有所帮助
  • 以前当我添加 imagePullPolicy: "Always" 时它工作。但是现在不行了
  • 您的容器正在崩溃,重复拉取相同的图像不会有任何影响。
  • 请阅读有关 imagePullPolicy 和 RestartPolicy 字段的更多信息,更好地了解您将能够了解您的失败来自何处。也可以查看一些 google 资源:komodor.com/learn/how-to-fix-crashloopbackoff-kubernetes-error

标签: kubernetes couchdb kubernetes-pod kubernetes-statefulset


【解决方案1】:

ImagePullPolicy 与容器重启并没有太大关系。它只决定在什么情况下应该从容器注册表中拉取镜像,read more here

如果 pod 中的容器不断重启 - 这通常是因为作为该容器入口点的命令中有一些错误。您应该可以在 2 个地方找到可以为您指明解决方案的其他信息:

  • pod 日志(使用kubectl logs _YOUR_POD_NAME_ 命令检查)
  • pod 描述(使用kubectl describe _YOUR_POD_NAME_ 命令检查)

【讨论】:

  • 我描述了它,它显示一个错误Back-off restarting failed container
  • 那么请查看日志
  • 我检查了日志,但没有显示任何内容
  • 绝对没有日志的可能性很小,但容器正在产生错误。也许您应该考虑的是使用 Helm 图表安装 CouchDB - artifacthub.io/packages/helm/couchdb/couchdb - 这至少应该为您提供一个工作示例,您可以使用它来找出您的案例中出了什么问题。
【解决方案2】:

您使用的 CouchDB k8s 示例已经过时并且包含错​​误(例如,ERL_FLAGS 被定义了两次)。您应该改用CouchDB helm chart。可以安装一个基本的 CouchDB:

helm repo add couchdb https://apache.github.io/couchdb-helm

helm install couchdb couchdb --set couchdbConfig.couchdb.uuid=$(curl https://www.uuidgenerator.net/api/version4 2>/dev/null | tr -d -)

kubectl get secret couchdb-couchdb -o go-template='{{ .data.adminPassword }}' | base64 -d

【讨论】:

    【解决方案3】:

    检查您是否使用正确的凭据创建了秘密并添加了秘密

    【讨论】:

      猜你喜欢
      • 2020-08-18
      • 1970-01-01
      • 2019-02-05
      • 2020-09-10
      • 2020-07-19
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多