无法在 kubernetes pod 中挂载只读卷（使用 AWS EKS 中的 EFS CSI 驱动程序）答案

【问题标题】：cannot mount read-only volume in kubernetes pod (using EFS CSI driver in AWS EKS)无法在 kubernetes pod 中挂载只读卷（使用 AWS EKS 中的 EFS CSI 驱动程序）
【发布时间】：2020-04-29 06:35:39
【问题描述】：

我安装了EFS CI driver 并让他们的Static Provisioning 示例工作：我能够启动一个附加到 EFS 卷上文件的 pod。我可以删除 pod 并启动另一个 pod 来检查该文件并确认第一个 pod 写入的数据仍然存在。但我真正需要做的是以只读方式安装卷，我没有运气。

请注意，在成功运行该示例后，我启动了一个 EC2 实例，并在其中安装了 EFS 文件系统，然后添加了我的 pod 需要以只读方式访问的数据。然后我卸载了 EFS 文件系统并终止了实例。

使用下面的配置，基于上面引用的静态配置示例，我的 pod 没有启动Running；它仍保留在ContainerCreating。

存储类：

$ kubectl get sc efs-sc -o yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"efs-sc"},"provisioner":"efs.csi.aws.com"}
  creationTimestamp: "2020-01-12T05:36:13Z"
  name: efs-sc
  resourceVersion: "809880"
  selfLink: /apis/storage.k8s.io/v1/storageclasses/efs-sc
  uid: 71ecce62-34fd-11ea-8a5f-124f4ee64e8d
provisioner: efs.csi.aws.com
reclaimPolicy: Delete
volumeBindingMode: Immediate

Persistent Volume（这是集群中唯一使用 EFS 存储类的 PV）：

$ kubectl get pv efs-pv-ro -o yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"PersistentVolume","metadata":{"annotations":{},"name":"efs-pv-ro"},"spec":{"accessModes":["ReadOnlyMany"],"capacity":{"storage":"5Gi"},"csi":{"driver":"efs.csi.aws.com","volumeHandle":"fs-26120da7"},"persistentVolumeReclaimPolicy":"Retain","storageClassName":"efs-sc","volumeMode":"Filesystem"}}
    pv.kubernetes.io/bound-by-controller: "yes"
  creationTimestamp: "2020-01-12T05:36:59Z"
  finalizers:
  - kubernetes.io/pv-protection
  name: efs-pv-ro
  resourceVersion: "810231"
  selfLink: /api/v1/persistentvolumes/efs-pv-ro
  uid: 8d54a80e-34fd-11ea-8a5f-124f4ee64e8d
spec:
  accessModes:
  - ReadOnlyMany
  capacity:
    storage: 5Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: efs-claim-ro
    namespace: default
    resourceVersion: "810229"
    uid: e0498cae-34fd-11ea-8a5f-124f4ee64e8d
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-26120da7
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  volumeMode: Filesystem
status:
  phase: Bound

Persistent Volume Claim（这是集群中唯一尝试使用 EFS 存储类的 PVC：

$ kubectl get pvc efs-claim-ro -o yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"PersistentVolumeClaim","metadata":{"annotations":{},"name":"efs-claim-ro","namespace":"default"},"spec":{"accessModes":["ReadOnlyMany"],"resources":{"requests":{"storage":"5Gi"}},"storageClassName":"efs-sc"}}
    pv.kubernetes.io/bind-completed: "yes"
    pv.kubernetes.io/bound-by-controller: "yes"
  creationTimestamp: "2020-01-12T05:39:18Z"
  finalizers:
  - kubernetes.io/pvc-protection
  name: efs-claim-ro
  namespace: default
  resourceVersion: "810234"
  selfLink: /api/v1/namespaces/default/persistentvolumeclaims/efs-claim-ro
  uid: e0498cae-34fd-11ea-8a5f-124f4ee64e8d
spec:
  accessModes:
  - ReadOnlyMany
  resources:
    requests:
      storage: 5Gi
  storageClassName: efs-sc
  volumeMode: Filesystem
  volumeName: efs-pv-ro
status:
  accessModes:
  - ReadOnlyMany
  capacity:
    storage: 5Gi
  phase: Bound

这里是 Pod。它保留在ContainerCreating，不会切换到Running：

$ kubectl get pod efs-app -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"efs-app","namespace":"default"},"spec":{"containers":[{"args":["infinity"],"command":["sleep"],"image":"centos","name":"app","volumeMounts":[{"mountPath":"/data","name":"persistent-storage","subPath":"mmad"}]}],"volumes":[{"name":"persistent-storage","persistentVolumeClaim":{"claimName":"efs-claim-ro"}}]}}
    kubernetes.io/psp: eks.privileged
  creationTimestamp: "2020-01-12T06:07:08Z"
  name: efs-app
  namespace: default
  resourceVersion: "813420"
  selfLink: /api/v1/namespaces/default/pods/efs-app
  uid: c3b8421b-3501-11ea-b164-0a9483e894ed
spec:
  containers:
  - args:
    - infinity
    command:
    - sleep
    image: centos
    imagePullPolicy: Always
    name: app
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /data
      name: persistent-storage
      subPath: mmad
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-z97dh
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: ip-192-168-254-51.ec2.internal
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim-ro
  - name: default-token-z97dh
    secret:
      defaultMode: 420
      secretName: default-token-z97dh
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-01-12T06:07:08Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2020-01-12T06:07:08Z"
    message: 'containers with unready status: [app]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2020-01-12T06:07:08Z"
    message: 'containers with unready status: [app]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2020-01-12T06:07:08Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - image: centos
    imageID: ""
    lastState: {}
    name: app
    ready: false
    restartCount: 0
    state:
      waiting:
        reason: ContainerCreating
  hostIP: 192.168.254.51
  phase: Pending
  qosClass: BestEffort
  startTime: "2020-01-12T06:07:08Z"

我不确定subPath 是否可以使用此配置，但无论subPath 是否在 Pod 配置中都会出现同样的问题。

问题似乎出在音量上。如果我注释掉 volumes 和 volumeMounts 部分，pod 就会运行。

PVC 似乎绑定了正确的 PV，但 pod 没有启动。我在上面的任何输出中都没有看到任何线索，但也许我遗漏了什么？

Kubernetes 版本：

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.8", GitCommit:"211047e9a1922595eaa3a1127ed365e9299a6c23", GitTreeState:"clean", BuildDate:"2019-10-15T12:11:03Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.9-eks-c0eccc", GitCommit:"c0eccca51d7500bb03b2f163dd8d534ffeb2f7a2", GitTreeState:"clean", BuildDate:"2019-12-22T23:14:11Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

aws-efs-csi-driver 版本：v.0.2.0。

【问题讨论】：

标签： amazon-web-services kubernetes amazon-eks nfs amazon-efs

【解决方案1】：

请注意，其中一项要求是安装了版本 1.13.4+ 的 Golang，但您安装了 go1.12.12。所以你必须更新它。如果您要从旧版本的 Go 升级，您必须首先删除现有版本。看这里：upgrading-golang。

Kubernetes 1.14 版及更高版本的 Amazon EKS 集群和工作线程节点支持此驱动程序。 Amazon EKS 集群不支持 Amazon EFS CSI 驱动程序的 Alpha 版功能。无法在 kubernetes pod 中挂载只读卷（使用 AWS EKS 中的 EFS CSI 驱动程序）。尝试将访问模式更改为：

accessModes:
 - ReadWriteMany

您可以在此处找到更多信息：efs-csi-driver。

确保在创建 EFS 文件系统时，可以从 Kuberenetes 集群访问它。这可以通过在与 Kubernetes 集群相同的 VPC 内创建文件系统或使用 VPC 对等来实现。

静态配置 - EFS 文件系统需要首先手动创建，然后可以使用驱动程序将其作为持久卷 (PV) 安装在容器内。挂载选项 - 可以在持久卷 (PV) 中指定挂载选项，以定义卷的挂载方式。除了正常的挂载选项外，您还可以将 tls 指定为挂载选项以启用 EFS 文件系统传输中的加密。

由于 Amazon EFS 是一个弹性文件系统，它不会强制执行任何文件系统容量限制。持久卷和持久卷声明中的实际存储容量值创建文件系统时不使用。但是，由于存储容量是必填项在 Kubernetes 中，您必须指定一个有效值，例如本例中的 5Gi。这个值确实不限制您的 Amazon EFS 文件系统的大小

【讨论】：