pod立即释放PersistentVolumeClaims (重复2次)

Question

我正在使用AKS，我试图用yaml的pvc创建一个状态集。它看起来像是成功地创建了pvc，并且是绑定的。但是，当我在吊舱上使用“描述”时，我发现荚状态是CrashLoopBackOff，我得到了以下事件：

  Type     Reason                  Age                    From                                        Message
  ----     ------                  ----                   ----                                        -------
  Warning  FailedScheduling        38m (x2 over 38m)      default-scheduler                           pod has unbound immediate PersistentVolumeClaims (repeated 2 times)
  Normal   Scheduled               38m                    default-scheduler                           Successfully assigned default/janusgraph-test3-0 to aks-agentpool-26199593-vmss000000
  Normal   SuccessfulAttachVolume  37m                    attachdetach-controller                     AttachVolume.Attach succeeded for volume "pvc-00b88841-a21d-430c-9f2f-b65307b156c2"
  Normal   Pulled                  34m (x4 over 37m)      kubelet, aks-agentpool-26199593-vmss000000  Successfully pulled image "janusgraph/janusgraph:latest"
  Normal   Created                 34m (x4 over 37m)      kubelet, aks-agentpool-26199593-vmss000000  Created container janusgraph-test3
  Normal   Started                 34m (x4 over 37m)      kubelet, aks-agentpool-26199593-vmss000000  Started container janusgraph-test3
  Normal   Pulling                 32m (x5 over 37m)      kubelet, aks-agentpool-26199593-vmss000000  Pulling image "janusgraph/janusgraph:latest"
  Warning  BackOff                 2m42s (x124 over 36m)  kubelet, aks-agentpool-26199593-vmss000000  Back-off restarting failed container

PVC是：

  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "default"
        resources:
          requests:
            storage: 7Gi

当我在PVC上运行descibe时，我得到了这个事件(这意味着一切都好！)：

  Type       Reason                 Age   From                         Message
  ----       ------                 ----  ----                         -------
  Normal     ProvisioningSucceeded  19m   persistentvolume-controller  Successfully provisioned volume pvc-00b88841-a21d-430c-9f2f-b65307b156c2 using kubernetes.io/azure-disk

以下是详细描述的pvc信息：

Name:          data-janusgraph-test3-0
Namespace:     default
StorageClass:  default
Status:        Bound
Volume:        pvc-00b88841-a21d-430c-9f2f-b65307b156c2
Labels:        app=janusgraph-test3
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/azure-disk
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      7Gi
Access Modes:  RWO
VolumeMode:    Filesystem
Events:
  Type       Reason                 Age   From                         Message
  ----       ------                 ----  ----                         -------
  Normal     ProvisioningSucceeded  19m   persistentvolume-controller  Successfully provisioned volume pvc-00b88841-a21d-430c-9f2f-b65307b156c2 using kubernetes.io/azure-disk
Mounted By:  janusgraph-test3-0

基于上面的信息，我不知道到底出了什么问题，当我在网络上看到类似的问题时，我可以发现它通常与不同的读/写访问有关，但是这里显然不是这样，因为在这个问题上没有错误。此外，我已经在我的AKS中创建了另外两个有状态集，它们使用相同类型的配置，只是使用不同的状态集名称。

--更新:此外，在吊舱上运行kubectl日志显示：

waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
waiting for storage...
Error occurred during initialization of VM
agent library failed to init: instrument
Error opening zip file or JAR manifest missing : /var/lib/janusgraph/jmx_prometheus_javaagent-0.13.0.jar

正如您现在所看到的，容器存储由于某种原因并没有被真正连接(我猜JAR的错误只是一个副作用)。知道吗？

Answer 1

Pods处于CrashLoopBackOff状态意味着在容器中运行的脚本有一些问题。

检查kubectl logs命令的输出，以了解吊舱崩溃的原因。