将 PVC 卷安装到 pod 时超时

Question

我正在尝试部署一个安装在 Persistent Volume 上的有状态集。

我通过 kops 在 AWS 上安装了 Kubernetes。

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"d2835416544f298c919e2ead3be3d0864b52323b", GitTreeState:"clean", BuildDate:"2018-02-07T12:22:21Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"d2835416544f298c919e2ead3be3d0864b52323b", GitTreeState:"clean", BuildDate:"2018-02-07T11:55:20Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}

根据this issue我需要先创建PVC：

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: zk-data-claim
spec:
  storageClassName: default
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: zk-logs-claim
spec:
  storageClassName: default
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

default存储类存在，PVC绑定一个PV成功：

$ kubectl get sc
NAME            PROVISIONER             AGE
default         kubernetes.io/aws-ebs   20d
gp2 (default)   kubernetes.io/aws-ebs   20d
ssd (default)   kubernetes.io/aws-ebs   20d

$ kubectl get pvc
NAME            STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
zk-data-claim   Bound     pvc-5584fdf7-3853-11e8-a73b-02bb35448afe   2Gi        RWO            default        11m
zk-logs-claim   Bound     pvc-5593e249-3853-11e8-a73b-02bb35448afe   2Gi        RWO            default        11m

我可以在 EC2 EBS 卷列表中看到这两个卷一开始是“可用的”，但后来变成“正在使用”。

然后在我的 StatefulSet 中摄取它

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: zk
spec:
  serviceName: zk-cluster
  replicas: 3
  template:
    metadata:
      labels:
        app: zookeeper
    spec:
      volumes:
        - name: zk-data
          persistentVolumeClaim:
            claimName: zk-data-claim
        - name: zk-logs
          persistentVolumeClaim:
            claimName: zk-logs-claim

      containers:
      ....
        volumeMounts:
        - name: zk-data
          mountPath: /opt/zookeeper/data
        - name: zk-logs
          mountPath: /opt/zookeeper/logs

失败了

Unable to mount volumes for pod "zk-0_default(83b8dc93-3850-11e8-a73b-02bb35448afe)": timeout expired waiting for volumes to attach/mount for pod "default"/"zk-0". list of unattached/unmounted volumes=[zk-data zk-logs]

我在默认命名空间中工作。

任何想法可能导致此失败？

Answer 1

问题是我的集群是由 C5 节点组成的。 C5 和 M5 节点遵循不同的命名约定 (NVMe)，并且无法识别命名。

使用 t2 类型节点重新创建集群。

Answer 2

是的，这是 AWS 和 kubernetes 的一个非常非常众所周知的问题。大多数情况下，它是由另一个节点上的陈旧目录引起的，导致从另一个节点的角度来看，EBS 卷仍处于“使用中”，因此当 AWS API 请求时，Linux 机器不会松开设备。你会在 kubelet.service 期刊上看到很多关于这个的讨论，在有 EBS 的机器上和想要 EBS 的机器上。

根据我的经验，只有通过 SSH 连接到当前附加 EBS 卷的节点，找到挂载，卸载它们，然后等待指数回退计时器到期才能解决： -(

挥手版是：

## cleaning up stale docker containers might not be a terrible idea
docker rm $(docker ps -aq -f status=exited)

## identify any (and there could very well be multiple) mounts
## of the EBS device-name
mount | awk '/dev\/xvdf/ {print $2}' | xargs umount

## or sometimes kubernetes will actually name the on-disk directory ebs~ so:
mount | awk '/ebs~something/{print $2}' | xargs umount

在该过程中，您也可能会在涉及 lsof 的过程中体验到一些成功，但希望（！）清理退出的容器将消除对此类事情的需要。