eks使用efs dynamic provisioning 建立非root容器 #yyds幹貨盤#

作者：​​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運維部落格​​