Kubernetes pod 挂在 Init 状态

Question

我的豆荚遇到了一个奇怪的问题。我在我的 env 中启动了大约 20 个 pod，每次它们中的一些随机 3-4 个 pod 以 Init:0/1 状态挂起。在检查 pod 状态时，Init 容器显示运行状态，任务完成后应终止，应用程序容器显示 Waiting/Pod Initializing 阶段。在所有 20 个 pod 中使用相同的 init 容器映像和规范，但这个问题每次都会发生在一些随机 pod 中。并且在终止这些卡住的 Pod 时，它会卡在终止状态。如果我在启动此 pod 的节点上 ssh 并运行 docker ps，它会向我显示处于运行状态的 init 容器，但在运行 docker exec 时它会抛出容器不存在的错误。这个 init 容器正在从 Consul Server 中提取配置并检查音量（从 docker inspect 中获得），我发现它已正确提取所有键值对并将其保存在定义的文件名中。我已经检查了所有节点上的资源，并且所有节点上的资源都绰绰有余。

下面是 pod 上的详细示例。

Kubectl 版本：

kubectl version 
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.0", GitCommit:"925c127ec6b946659ad0fd596fa959be43f0cc05", GitTreeState:"clean", BuildDate:"2017-12-15T21:07:38Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} 
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.2", GitCommit:"5fa2db2bd46ac79e5e00a4e6ed24191080aa463b", GitTreeState:"clean", BuildDate:"2018-01-18T09:42:01Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} 

豆荚：

kubectl get pods -n dev1|grep -i session-service 
session-service-app-75c9c8b5d9-dsmhp               0/1       Init:0/1           0          10h 
session-service-app-75c9c8b5d9-vq98k               0/1       Terminating        0          11h 

豆荚状态：

kubectl describe pods session-service-app-75c9c8b5d9-dsmhp -n dev1 
Name:           session-service-app-75c9c8b5d9-dsmhp 
Namespace:      dev1 
Node:           ip-192-168-44-18.ap-southeast-1.compute.internal/192.168.44.18 
Start Time:     Fri, 27 Apr 2018 18:14:43 +0530 
Labels:         app=session-service-app 
                pod-template-hash=3175746185 
                release=session-service-app 
Status:         Pending 
IP:             100.96.4.240 
Controlled By:  ReplicaSet/session-service-app-75c9c8b5d9 
Init Containers: 
  initpullconsulconfig: 
    Container ID:  docker://c658d59995636e39c9d03b06e4973b6e32f818783a21ad292a2cf20d0e43bb02 
    Image:         shr-u-nexus-01.myops.de:8082/utils/app-init:1.0 
    Image ID:      docker-pullable://shr-u-nexus-01.myops.de:8082/utils/app-init@sha256:7b0692e3f2e96c6e54c2da614773bb860305b79922b79642642c4e76bd5312cd 
    Port:          <none> 
    Args: 
      -consul-addr=consul-server.consul.svc.cluster.local:8500 
    State:          Running 
      Started:      Fri, 27 Apr 2018 18:14:44 +0530 
    Ready:          False 
    Restart Count:  0 
    Environment: 
      CONSUL_TEMPLATE_VERSION:  0.19.4 
      POD:                      sand 
      SERVICE:                  session-service-app 
      ENV:                      dev1 
    Mounts: 
      /var/lib/app from shared-volume-sidecar (rw) 
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-bthkv (ro) 
Containers: 
  session-service-app: 
    Container ID: 
    Image:          shr-u-nexus-01.myops.de:8082/sand-images/sessionservice-init:sitv12 
    Image ID: 
    Port:           8080/TCP 
    State:          Waiting 
      Reason:       PodInitializing 
    Ready:          False 
    Restart Count:  0 
    Environment:    <none> 
    Mounts: 
      /etc/appenv from shared-volume-sidecar (rw) 
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-bthkv (ro) 
Conditions: 
  Type           Status 
  Initialized    False 
  Ready          False 
  PodScheduled   True 
Volumes: 
  shared-volume-sidecar: 
    Type:    EmptyDir (a temporary directory that shares a pod's lifetime) 
    Medium: 
  default-token-bthkv: 
    Type:        Secret (a volume populated by a Secret) 
    SecretName:  default-token-bthkv 
    Optional:    false 
QoS Class:       BestEffort 
Node-Selectors:  <none> 
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s 
                 node.kubernetes.io/unreachable:NoExecute for 300s 
Events:          <none> 

节点上的容器状态：

sudo docker ps|grep -i session 
c658d5999563        shr-u-nexus-01.myops.de:8082/utils/app-init@sha256:7b0692e3f2e96c6e54c2da614773bb860305b79922b79642642c4e76bd5312cd                                       "/usr/bin/consul-t..."   10 hours ago        Up 10 hours                             k8s_initpullconsulconfig_session-service-app-75c9c8b5d9-dsmhp_dev1_c2075f2a-4a18-11e8-88e7-02929cc89ab6_0 

da120abd3dbb        gcr.io/google_containers/pause-amd64:3.0                                                                                                                      "/pause"                 10 hours ago        Up 10 hours                             k8s_POD_session-service-app-75c9c8b5d9-dsmhp_dev1_c2075f2a-4a18-11e8-88e7-02929cc89ab6_0 

f53d48c7d6ec        shr-u-nexus-01.myops.de:8082/utils/app-init@sha256:7b0692e3f2e96c6e54c2da614773bb860305b79922b79642642c4e76bd5312cd                                       "/usr/bin/consul-t..."   10 hours ago        Up 10 hours                             k8s_initpullconsulconfig_session-service-app-75c9c8b5d9-vq98k_dev1_42837d12-4a12-11e8-88e7-02929cc89ab6_0 

c26415458d39        gcr.io/google_containers/pause-amd64:3.0                                                                                                                      "/pause"                 10 hours ago        Up 10 hours                             k8s_POD_session-service-app-75c9c8b5d9-vq98k_dev1_42837d12-4a12-11e8-88e7-02929cc89ab6_0 

运行 Docker exec（与 kubectl exec 结果相同）：

sudo docker exec -it c658d5999563 bash 
rpc error: code = 2 desc = containerd: container not found 

Answer 1

由于多种原因，Pod 可能会陷入 Init 状态。

\n

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

\n

\n\n\n

收集信息

\n

对于这些情况，最好是收集信息，作为根本原因可能不同。

\n

\n

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

  \n
\n

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

  \n
\n

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

  \n

  

  \n

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

  \n

  

  \n

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

  \n
\n

\n

额外的：

\n

\n

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

  \n
\n

• kubectl get events列出集群事件。

  \n
\n

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

  \n
\n

\n\n

解决方案

\n

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

\n

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

\n

一些例子：

\n

1 > 删除 init 容器时会发生这种情况，可以通过删除 pod 来修复它，以便重新创建它或重新部署它。1.1中的情况相同。

\n

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

\n

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

\n

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

\n

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

\n