19

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

4 回答 4

22

为了尝试解决这个问题，我将运行以下命令：

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

然后复制 pod 名称并运行：

kubectl describe pod {POD_NAME}

这应该会给你一些信息，说明它为什么卡在初始化状态。

于 2018-11-15T08:01:20.053 回答
6

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

还：

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

根据文档：

在所有 Init Container 都成功之前，Pod 无法就绪。Init Container 上的端口不聚合在服务下。正在初始化的 Pod 处于 Pending 状态，但应将条件 Initializing 设置为 true。

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

于 2018-11-15T17:25:31.260 回答
5

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

PodInitializing 或 Init Status 表示 Pod 包含尚未完成的 Init 容器（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-xxxcan throw 有意义的问题信息的输出，参考：

    图像日志

    在上图中我们可以看到根本原因是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 容器。但是，具体的解决方案将取决于具体的根本原因。

于 2021-09-20T10:04:26.877 回答
1

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

于 2018-11-16T00:37:28.123 回答