Kubernetes pod 仍处于“ContainerCreating”状态答案

【问题标题】：Kubernetes pod still in "ContainerCreating" statusKubernetes pod 仍处于“ContainerCreating”状态
【发布时间】：2018-02-28 06:03:30
【问题描述】：

我有一个关于 Kubernetes 环境的问题。我有 K8s 云，添加后将一个持久卷分配给一个 pod，这个 pod 仍处于“ContainerCreating”状态。此 PV 已正确分配 PVC。 PVC 位于具有副本 2 的两个外部 GlusterFS 服务器上。

PV 如下所示：

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    definitionVersion: "20170919"
  name: tarsier-pv
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 50Gi
  glusterfs:
    endpoints: glusterfs-cluster
    path: tarsier-prep
  persistentVolumeReclaimPolicy: Recycle

PVC 看起来像这样：

    apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: tarsier-pvc
  annotations:
    definitionVersion: "20170919"
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 50Gi
  volumeName: tarsier-pv
status:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 50Gi
  phase: Bound

Pods RC 如下所示：

    apiVersion: v1
kind: ReplicationController
metadata:
  name: xxx
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: xxxxx
    spec:
      volumes:
      - name: tarsier-pv
        persistentVolumeClaim:
          claimName: tarsier-pvc
        ...
      containers:
      - name: xxx
        ...
        volumeMounts:
        - name: tarsier-pv
          mountPath: "/shared_data/storage"

Kubectl describe pod xxx return no errors.

kubectl logs xxx 返回：

Error from server (BadRequest): container "xxx" in pod "xxx" is waiting to start: ContainerCreating.

你有什么想法可能是错误的，或者我可以在哪里找到任何详细的日志？提前 THX。

编辑： Gluster mount 正确安装在 Master 上，如果我手动添加任何文件，它会在两个 Gluster 服务器上正确复制

【问题讨论】：

先格式化上面粘贴的配置，这样更清晰
似乎没有 image 用于从上面的配置创建容器
您好，感谢您的回复，但这不是重点。该 RC 短路。在其他测试环境中它工作正常。如果没有可用的镜像，在 kubectl describe pod xxx 中会出现错误，并且 pod 的状态将为“ImagePullBackoff”。您还有其他想法吗？
用kubectl describe ...检查pv和pvc的状态。还可以使用kubectl get ev 检查事件。这应该会给你一些关于哪里出了问题的更多提示。

标签： kubernetes

【解决方案1】：

谢谢大家。 EP 上的配置错误。无论如何，所有可能的日志或“或 kubectl describe pod xxx”中都没有任何信息。

干杯

【讨论】：

我也面临类似的问题。什么是“EP”，请指教。

【解决方案2】：

要查看问题所在，请检查事件：

kubectl get events --sort-by=.metadata.creationTimestamp

【讨论】：

正如目前所写，您的答案尚不清楚。请edit 添加其他详细信息，以帮助其他人了解这如何解决所提出的问题。你可以找到更多关于如何写好答案的信息in the help center。