关于kubernetes:eks使用efs-dynamic-provisioning-创建非root容器提示Operation-not-permitted

作者：SRE 运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/220125450139/
相干话题：https://www.cnsre.cn/tags/eks/

前言

之前在 aws 中创立了 eks，在数据存储这一块中，我抉择了应用 AWS 的 EFS 具体部署配置参考 Amazon EKS 中 EFS 持久性存储。文章中的动静供应是 AWS 官网给的示例，应用的是 root 用户启动的容器。在我前面的测试中发现，我在应用非 root 用户启动容器的时候，发现应用动态供应是有权限并且没有报错的。然而在应用静载供应的时候呈现了 Operation not permitted 的报错。

问题形容

我依据 efs dynamic_provisioning 创立了 dynamic provisioning
root 用户的容器运行没有问题，然而非 root 用户容器运行时提醒“Operation not permitted”

pod 配置清单：

apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

StorageClass 配置清单：

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-xxxxx
  directoryPerms: "700"
  gidRangeStart: "1000" # optional
  gidRangeEnd: "2000" # optional
  basePath: "/dynamic_provisioning" # optional

剖析和查看

该报错是因为采纳了 dynamic provisioning PV 部署形式，这种模式的实现须要利用 efs-ap：access point 拜访点 模式做 EFS 挂载。从 EFS 的角度来讲，EFS 的 access point 模式挂载的 EFS 卷，客户端不可批改 uid/gid，只领有使用权（读写）详情点击查看。从本人的 pod 环境也能够看到，客户端挂载目录/dynamic_provisioning 的 uid 跟 gid 都是一个随机数字。ls -l /dynamic_provisioning 能够看到是 `1018（不同环境 uid 会不同）。

EFS-AP 模式指的是 access point 拜访点模式。对于拜访点的介绍：
EFS Access Points：
An access point applies an operating system user, group, and file system path to any file system request made using the access point. The access point’s operating system user and group override any identity information provided by the NFS client.
简略来讲，EFS-AP 也就是 access point 拜访点挂载模式下，efs 客户端的门路 user/gid 是不可被批改的。的客户端用户只有使用权（读写），然而不能够批改 owner。因而遇到的报错是该配置的预期体现。

EFS-AP 模式的配置是在 storageclass 中定义的：provisioningMode: efs-ap，比方：

kind: StorageClass
apiVersion: storage.k8s.io/v1 
metadata:
  name: efs-sc-dynamic
provisioner: efs.csi.aws.com 
parameters:
  provisioningMode: efs-ap    <<<<<<<<<<<<<<------------------------------EFS 拜访点挂载模式
  fileSystemId: fs-xxxxxx
  directoryPerms: "700"
  gidRangeStart: "1000" # optional
  gidRangeEnd: "2000" # optional
  basePath: "/dynamic_provisioning" # optional

目前 AWS EFS 的 dynamic provisioning 模式的实现就是应用 storageclass 的 efs-sc-dynamic 模式。
这种模式的弊病曾经在 github 中有 issue 在跟踪, 详情点击查看，然而因为该模式也有肯定的设计意义 详情点击查看，所以目前还没有明确的论断。

长期解决办法

应用动态模式创立

能够创立 EKS pv/pvc 时应用 static 模式部署 PV，不会应用 access point 模式挂载 EFS 卷，那么能够顺利批改 uid/gid。
详情参考 Amazon EKS 中 EFS 持久性存储

在 pod 中指定 uid 和 gid

在创立 pod 之前，先创立 pvc 在创立完 pvc 后查看 uid 和 gid

[root@ip-10-0-100-206 ~]# ls -l /efs/dynamic_provisioning/
total 12
drwxr-xr-x 5 1015 1015 6144 Jan 20 02:44 pvc-40b922c7-8d4d-47d9-8783-60d25abe123
drwxr-xr-x 5 1017 1017 6144 Jan 20 04:22 pvc-4ee000a8-7ab2-4ffc-8fd3-72ef31b7123
drwx------ 5 1014 1014 6144 Jan 20 01:08 pvc-f6622cb3-7c24-4172-a427-d4b9a996122

将输入内容的 pvc 的 uid gid 记下并在 pod 的 yaml 清单中指定 uid 曾经 gid 让 pod 领有该目录的权限。
pod 配置清单：

apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  ports:
    - port: 3306
  selector:
    app: wordpress
    tier: mysql
  clusterIP: None
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: wordpress-mysql
  labels:
    app: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      securityContext:
        fsGroup: 1014
        runAsUser: 1014
        runAsGroup: 1014
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-pass
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim

查看

kubectl get pv|grep  mysql 
pvc-f6622cb3-7c24-4172-a427-d4b9a9962cd8   5Gi   RWX   Delete   Bound   default/mysql-pv-claim   efs-sc      5d23h

kubectl get  pvc
NAME             STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
mysql-pv-claim   Bound    pvc-f6622cb3-7c24-4172-a427-d4b9a9962cd8   5Gi        RWX            efs-sc         5d23h

kubectl get  pod
NAME                               READY   STATUS    RESTARTS   AGE
wordpress-mysql-6f6455f449-52zrp   1/1     Running   0          5d7h

作者：SRE 运维博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/220125450139/
相干话题：https://www.cnsre.cn/tags/eks/