EKS中使用EFS动态供给创建非root容器时的权限问题

在AWS的Elastic Kubernetes Service (EKS)中，配合Elastic File System (EFS)作为持久存储时，我们可能会遇到动态供给存储卷的问题。特别是当尝试以非root用户身份在容器中运行应用程序时，可能会遇到’Operation not permitted’的错误。

问题原因

这个错误通常是由于NFS（EFS基于NFS协议）的默认挂载选项不允许非root用户访问造成的。NFS默认只允许root用户挂载和访问，而Kubernetes的Pod默认并不以root用户运行。因此，当Pod尝试访问EFS挂载点时，就会因为权限不足而失败。

解决方案

要解决这个问题，我们可以采取以下几个步骤：

1. 修改NFS挂载选项

我们可以在NFS服务器的/etc/exports文件中，为对应的EFS目录添加no_root_squash和no_subtree_check选项。no_root_squash允许NFS客户端以root用户身份访问，而no_subtree_check则用于禁用子树检查，这可以提高性能。

例如，如果你的EFS目录是/efs/shared，你可以这样修改/etc/exports：

/efs/shared *(rw,sync,no_subtree_check,no_root_squash)

然后重新加载NFS配置：

exportfs -ra

rageclass">2. 修改Kubernetes的StorageClass

确保你的StorageClass配置正确，以便在Pod创建时自动挂载EFS。例如：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  fileSystemId: fs-xxxxxxxx  # 你的EFS文件系统ID

3. 在Pod Security Context中设置FSGroup

在Pod定义中，你可以设置securityContext的fsGroup字段，使其与容器中的应用程序用户组ID匹配。这样，该组的所有用户都可以在Pod内访问EFS卷。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  securityContext:
    fsGroup: 1001  # 应用程序用户组ID
  containers:
    - name: my-container
      image: my-image
      securityContext:
        runAsUser: 1001  # 应用程序运行用户ID

4. 确保应用程序用户ID和组ID正确

最后，确保你的应用程序在容器中以正确的用户ID和组ID运行。你可以使用USER和GROUP指令在Dockerfile中设置，或者在容器启动脚本中手动设置。

USER 1001:1001  # 用户ID:组ID

通过执行上述步骤，你应该能够在EKS中使用EFS动态供给创建非root容器，并解决’Operation not permitted’错误。确保在修改任何配置之前，备份相关文件，并在非生产环境中进行测试，以确保更改不会造成其他问题。