Pod 无限期地停留在 PodInitializing 状态

Question

我有一个 k8s cronjob，它由一个 init 容器和一个 pod 容器组成。如果 init 容器失败，主容器中的 Pod 永远不会启动，并无限期地停留在“PodInitializing”中。

如果初始化容器失败，我的意图是让作业失败。

---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: job-name
  namespace: default
  labels:
    run: job-name
spec:
  schedule: "15 23 * * *"
  startingDeadlineSeconds: 60
  concurrencyPolicy: "Forbid"
  successfulJobsHistoryLimit: 30
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
      # only try twice
      backoffLimit: 2
      activeDeadlineSeconds: 60
      template:
        spec:
          initContainers:
          - name: init-name
            image: init-image:1.0
          restartPolicy: Never
          containers:
          - name: some-name
            image: someimage:1.0
          restartPolicy: Never

pod 上的 kubectl 卡住会导致：

Name:               job-name-1542237120-rgvzl
Namespace:          default
Priority:           0
PriorityClassName:  <none>
Node:               my-node-98afffbf-0psc/10.0.0.0
Start Time:         Wed, 14 Nov 2018 23:12:16 +0000
Labels:             controller-uid=ID
                    job-name=job-name-1542237120
Annotations:        kubernetes.io/limit-ranger:
                      LimitRanger plugin set: cpu request for container elasticsearch-metrics; cpu request for init container elasticsearch-repo-setup; cpu requ...
Status:             Failed
IP:                 10.0.0.0
Controlled By:      Job/job-1542237120
Init Containers:
init-container-name:
    Container ID:  docker://ID
    Image:         init-image:1.0
    Image ID:      init-imageID
    Port:          <none>
    Host Port:     <none>
    State:          Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Wed, 14 Nov 2018 23:12:21 +0000
      Finished:     Wed, 14 Nov 2018 23:12:32 +0000
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:        100m
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-wwl5n (ro)
Containers:
  some-name:
    Container ID:  
    Image:         someimage:1.0
    Image ID:      
    Port:          <none>
    Host Port:     <none>
    State:          Waiting
      Reason:       PodInitializing
    Ready:          False
    Restart Count:  0
    Requests:
      cpu:        100m
    Environment:  <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-wwl5n (ro)
Conditions:
  Type              Status
  Initialized       False 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True

Answer 1

由于多种原因，Pod 可能会卡在 Init 状态。

PodInitializing 或 Init Status 表示 Pod 包含尚未完成的 Init container（Init 容器：在 Pod 中的应用程序容器之前运行的专用容器，init 容器可以包含实用程序或设置脚本）。如果 pods 状态为 'Init:0/1' 意味着一个 init 容器没有完成； init:N/M 表示 Pod 有 M 个 Init Container，目前 N 已经完成。

---

---

收集信息

对于这些情况，最好的办法是收集信息，因为每个 PodInitializing 问题的根本原因可能不同。

• kubectl describe pods pod-XXX 使用这个命令你可以得到很多关于pod的信息，你也可以检查是否有任何有意义的事件。保存初始化容器名称

• kubectl logs pod-XXX 此命令打印 pod 或指定资源中的容器的日志。

• kubectl logs pod-XXX -c init-container-xxx 这是最准确的，因为它可以打印 init 容器的日志。 您可以获取描述 pod 的初始化容器名称，以便将“init-container-XXX”替换为“copy-default-config”，如下所示：

  kubectl logs pod-XXX -c init-container-xxx 的输出可以抛出有意义的问题信息，参考：

  在上图中我们可以看到根本原因是init容器无法从jenkins下载插件（超时），现在我们可以检查连接配置、代理、dns；或者只是修改 yaml 以部署没有插件的容器。

补充：

• kubectl describe node node-XXX 描述 pod 将为您提供其节点的名称，您也可以使用此命令对其进行检查。

• kubectl get events 列出集群事件。

• journalctl -xeu kubelet | tail -n 10kubelet 登录 systemd（journalctl -xeu docker | tail -n 1 用于 docker）。

---

解决方案

解决方案取决于收集的信息，一旦找到根本原因。

当您找到深入了解根本原因的日志时，您可以调查该特定的根本原因。

一些例子：

1 > 当初始化容器被删除时发生这种情况，可以修复删除 pod 以便重新创建或重新部署它。 1.1 中的相同场景。

2 > 如果您发现“bad address 'kube-dns.kube-system'”PVC 可能无法正确回收，2 提供的解决方案正在运行/opt/kubernetes/bin/kube-restart.sh。

3> 那里，没有找到sh文件，解决办法是修改yaml文件，或者如果不需要的话，删除容器。

4> 发现一个FailedSync，在节点上重启docker解决了。

一般而言，您可以修改 yaml，例如避免使用过时的 URL，尝试重新创建受影响的资源，或者只是从部署中删除导致问题的 init 容器。但是具体的解决方案将取决于具体的根本原因。

Answer 2

既然您已经发现 initcontainers 应该成功运行到完成。如果您无法摆脱 init 容器，在这种情况下我会做的是确保 init 容器始终成功结束。 init 容器的结果可以写入一个 emptydir 卷，类似于状态文件，由您的 init 容器和您的工作容器共享。 我会将决定在 init 容器结束失败时做什么的责任委托给工作容器。

Answer 3

我认为您可能会错过这是 init 容器的预期行为。 规则是，在 initContainers 失败的情况下，如果 restartPolicy 设置为 Never，则 Pod 将不会重新启动，否则 Kubernetes 将继续重新启动它，直到它成功。

还有：

如果 init 容器失败，主容器中的 Pod 永远不会得到 已启动，并无限期地停留在“PodInitializing”中。

根据documentation:

在所有 Init Container 都成功之前，Pod 无法就绪。这 Init Container 上的端口不聚合在服务下。一个豆荚 正在初始化的是处于 Pending 状态，但应该有一个 条件初始化设置为真。

*我可以看到您尝试更改此行为，但我不确定您是否可以使用 CronJob 做到这一点，我看到了 Jobs 的示例。但我只是在理论上，如果这篇文章没有帮助您解决问题，我可以尝试在实验室环境中重新创建它。

Answer 4

要尝试解决这个问题，我会运行以下命令：

kubectl get pods - 如果需要，添加命名空间参数。

然后复制 pod 名称并运行：

kubectl describe pod {POD_NAME}

这应该会为您提供一些关于它为什么会停留在初始化状态的信息。