云容器引擎 CCE-dew-provider:插件使用说明
插件使用说明
- 创建ServiceAccount。
- 创建ServiceAccount对象,其中声明了允许业务使用的凭据名称,若用户引用了未在此处声明的凭据,则挂载失败,最终导致Pod无法运行。
根据如下模板创建serviceaccount.yaml,在cce.io/dew-resource字段中声明允许业务使用的凭据名称。这里声明了secret_1和secret_2,表示允许业务引用这两个凭据对象。在后续的操作中,若用户在业务中引用了secret_3,则无法通过校验,从而导致无法正常挂载该凭据,最终业务Pod将无法运行。
apiVersion: v1kind: ServiceAccountmetadata: name: nginx-spc-sa annotations: cce.io/dew-resource: "[\"secret_1\",\"secret_2\"]" #secrets that allow pod to use
这里需要明确,此处声明的凭据应确保在凭据管理服务中是存在的,如下图所示。否则,即使通过了校验,最终向凭据管理服务中获取相应凭据的时候也会出错,从而导致Pod无法正常运行。
- 执行如下命令创建ServiceAccount对象。
- 查看ServiceAccount对象是否已经正常创建,如下所示:
$ kubectl get saNAME SECRETS AGEdefault 1 18d # 此为系统默认的ServiceAccount对象nginx-spc-sa 1 19s # 此为刚刚创建的ServiceAccount对象
至此,一个名为“nginx-spc-sa”的ServiceAccount对象已正常创建。该对象将在后续的业务Pod中被引用。
- 创建ServiceAccount对象,其中声明了允许业务使用的凭据名称,若用户引用了未在此处声明的凭据,则挂载失败,最终导致Pod无法运行。
- 创建SecretProviderClass。
- SecretProviderClass对象用于描述用户感兴趣的凭据信息(比如指定凭据的版本、凭据的名称等),由用户创建,并在业务Pod中进行引用。
根据如下模板创建secretproviderclass.yaml。用户主要关注parameters.objects字段,它是一个数组,用于声明用户想要挂载的凭据信息。
apiVersion: secrets-store.csi.x-k8s.io/v1kind: SecretProviderClassmetadata: name: spc-testspec: provider: cce # 固定为cce parameters: objects: | - objectName: "secret_1" objectVersion: "v1" objectType: "csms"
参数
参数类型
是否必选
参数说明
objectName
String
是
凭据名称。若同一个SecretProviderClass中定义了多个objectName,不允许重名,否则会挂载失败。
objectAlias
String
否
凭据写入到容器内的文件名称。若不指定,则凭据写入到容器内的文件名默认为objectName;若指定,则objectAlias与其他凭据的objectName和objectAlias均不允许重名,与自身的objectName也不允许重名,否则会挂载失败。
objectType
String
是
凭据类型。当前仅支持”csms”类型,其他均为非法输入。
objectVersion
String
是
凭据的版本。
- 指定某个具体的版本:v1,v2,…
- 指定最新版本:latest。当指定objectVersion为” latest”时,若在云凭据管理服务侧对应的凭据发生了更新,更新后的凭据值将在经过一定时间间隔后(即rotation_poll_interval)刷新至Pod内。
- 执行如下命令创建SecretProviderClass对象。
- 查看SecretProviderClass对象是否已经正常创建,如下所示:
$ kubectl get spcNAME AGEspc-test 20h
至此,一个名为“spc-test”的SecretProviderClass对象已正常创建。该对象将在后续的业务Pod中被引用。
- SecretProviderClass对象用于描述用户感兴趣的凭据信息(比如指定凭据的版本、凭据的名称等),由用户创建,并在业务Pod中进行引用。
- 创建业务Pod。
这里以创建一个nginx应用为例。
- 定义业务负载,在serviceAccountName中引用此前创建好的ServiceAccount对象,secretProviderClass中引用此前创建好的SPC对象,并在mountPath中指定容器内的挂载路径(这里需注意,用户不应该指定”/”,” /var/run”等特殊目录,否则可能影响容器的正常启动)。
apiVersion: apps/v1kind: Deploymentmetadata: name: nginx-spc labels: app: nginxspec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: serviceAccountName: nginx-spc-sa # 引用上面创建的ServiceAccount volumes: - name: secrets-store-inline csi: driver: secrets-store.csi.k8s.io readOnly: true volumeAttributes: secretProviderClass: "spc-test" # 引用上面创建的SPC containers: - name: nginx-spc image: nginx:alpine imagePullPolicy: IfNotPresent volumeMounts: - name: secrets-store-inline mountPath: "/mnt/secrets-store" # 定义容器内凭据的挂载路径 readOnly: true imagePullSecrets: - name: default-secret
- 执行 kubectl apply -f deployment.yaml 创建业务Pod。
- 查看Pod是否已经正常创建,如下所示:
$ kubectl get podNAME READY STATUS RESTARTS AGEnginx-spc-67c9d5b594-642np 1/1 Running 0 20s
- 进入容器,查看指定的凭据是否正常写入。如下所示:
$ kubectl exec -ti nginx-spc-67c9d5b594-642np -- /bin/bashroot@nginx-spc-67c9d5b594-642np:/# root@nginx-spc-67c9d5b594-642np:/# cd /mnt/secrets-store/root@nginx-spc-67c9d5b594-642np:/mnt/secrets-store# root@nginx-spc-67c9d5b594-642np:/mnt/secrets-store# lssecret_1
可以看到,用户在SPC对象中声明的secret_1已正常写入Pod。
此外,还可以通过获取spcPodStatus查看Pod与凭据的绑定情况。如下所示:
$ kubectl get spcpsNAME AGEnginx-spc-67c9d5b594-642np-default-spc-test 103s$ kubectl get spcps nginx-spc-67c9d5b594-642np-default-spc-test -o yaml......status:mounted: trueobjects: # 挂载的凭据信息- id: secret_1version: v1podName: nginx-spc-67c9d5b594-642np # 引用了SPC对象的PodsecretProviderClassName: spc-test # SPC对象targetPath: /mnt/paas/kubernetes/kubelet/pods/6dd29596-5b78-44fb-9d4c-a5027c420617/volumes/kubernetes.io~csi/secrets-store-inline/mount
- 定义业务负载,在serviceAccountName中引用此前创建好的ServiceAccount对象,secretProviderClass中引用此前创建好的SPC对象,并在mountPath中指定容器内的挂载路径(这里需注意,用户不应该指定”/”,” /var/run”等特殊目录,否则可能影响容器的正常启动)。