eks使用efs dynamic provisioning 創(chuàng)建非root容器提示 Operation not permitted

作者：SRE運維博客
博客地址：https://www.cnsre.cn/
文章地址：https://www.cnsre.cn/posts/220125450139/
相關話題：https://www.cnsre.cn/tags/eks/

前言

之前在 aws 中創(chuàng)建了 eks，在數(shù)據(jù)存儲這一塊中，我選擇了使用 AWS 的 EFS 具體部署配置參考Amazon EKS 中 EFS 持久性存儲。文章中的動態(tài)供給是 AWS 官方給的示例，使用的是root用戶啟動的容器。在我后面的測試中發(fā)現(xiàn)，我在使用非root用戶啟動容器的時候，發(fā)現(xiàn)使用靜態(tài)供給是有權限并且沒有報錯的。但是在使用靜載供給的時候出現(xiàn)了 Operation not permitted 的報錯访锻。

問題描述

我根據(jù)efs dynamic_provisioning 創(chuàng)建了 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部署方式，這種模式的實現(xiàn)需要利用 efs-ap：access point訪問點 模式做 EFS 掛載期犬。從 EFS 的角度來講河哑，EFS 的 access point 模式掛載的 EFS 卷，客戶端不可修改 uid/gid 龟虎，只擁有使用權（讀寫）詳情點擊查看璃谨。從自己的pod環(huán)境也可以看到，客戶端掛載目錄/dynamic_provisioning 的uid跟gid都是一個隨機數(shù)字鲤妥。 ls -l /dynamic_provisioning可以看到是 `1018 （不同環(huán)境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衷模。因此遇到的報錯是該配置的預期表現(xiàn)。

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 模式的實現(xiàn)就是使用 storageclass 的 efs-sc-dynamic 模式阱冶。
這種模式的弊端已經(jīng)在 github 中有issue在跟蹤,詳情點擊查看，但是由于該模式也有一定的設計意義詳情點擊查看滥嘴，所以目前還沒有明確的結論熙揍。

臨時解決方法

使用靜態(tài)模式創(chuàng)建

可以創(chuàng)建EKS pv/pvc時使用static模式部署PV，不會使用access point模式掛載EFS卷氏涩，那么可以順利修改uid/gid。
詳情參考Amazon EKS 中 EFS 持久性存儲

在pod中指定 uid 和 gid

在創(chuàng)建pod之前有梆，先創(chuàng)建 pvc在創(chuàng)建完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

將輸出內(nèi)容的pvc的uid gid 記下并在pod的yaml清單中指定uid已經(jīng)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