5.3. 共享资源 CSI Driver Operator

作为集群管理员，您可以在 OpenShift Container Platform 中使用 Shared Resource CSI Driver 来置备包含 Secret 或 ConfigMap 对象的内联临时卷。这样，pod 和其他 Kubernetes 类型用来公开卷挂载，OpenShift Container Platform 构建可以安全地在集群中的任何命名空间中使用这些对象的内容。要达到此目的，目前有两种类型的共享资源： Secret 对象的 SharedSecret 自定义资源，以及 ConfigMap 对象的 SharedConfigMap 自定义资源。

重要

Shared Resource CSI 驱动程序只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

注意

要启用共享资源 CSI 驱动程序，您必须使用功能门启用功能

5.3.1. 关于 CSI

在过去，存储厂商一般会把存储驱动作为 Kubernetes 的一个部分提供。随着容器存储接口 (CSI) 的实现，第三方供应商可以使用标准接口来提供存储插件，而无需更改核心 Kubernetes 代码。

CSI Operators 为 OpenShift Container Platform 用户提供了存储选项，如卷快照，它无法通过 in-tree 卷插件实现。

5.3.2. 在命名空间间共享 secret

要在集群中的命名空间间共享 secret，您可以为您要共享的 Secret 对象创建一个 SharedSecret 自定义资源(CR)实例。

先决条件

您必须具有执行以下操作的权限：

  • 在集群范围的级别上创建 sharedsecrets.sharedresource.openshift.io 自定义资源定义(CRD)的实例。
  • 管理集群中命名空间中的角色和角色绑定，以控制哪些用户可以获取、列出和监视这些实例。
  • 管理角色和角色绑定，以控制 Pod 指定的服务帐户是否可以挂载引用您要使用的 SharedSecret CR 实例的 Container Storage Interface(CSI)卷。
  • 访问包含您要共享 Secret 的命名空间。

流程

  • 为您要在集群中的命名空间之间共享的 Secret 对象创建一个 SharedSecret CR 实例： 

    $ oc apply -f - <<EOF
apiVersion: sharedresource.openshift.io/v1alpha1
kind: SharedSecret
metadata:
  name: my-share
spec:
  secretRef:
    name: <name of secret>
    namespace: <namespace of secret>
EOF

5.3.3. 在 pod 中使用 SharedSecret 实例

要从 Pod 访问 SharedSecret 自定义资源(CR)实例，您需要向给定的服务帐户 RBAC 权限授予该 SharedSecret CR 实例。

先决条件

  • 您已为要在集群中的命名空间间共享的 secret 创建 SharedSecret CR 实例。

  • 您必须具有执行以下操作的权限

    • 创建构建配置和启动构建。
    • 输入 oc get sharedsecrets 命令并返回非空列表来发现哪些 SharedSecret CR 实例可用。
    • 确定命名空间中的 builder 服务帐户是否可以使用给定的 SharedSecret CR 实例。也就是说，您可以运行 oc adm policy who-can use <identifier of specific SharedSecret> 来查看是否列出命名空间中的 builder 服务帐户。
注意

如果没有满足此列表中的最后两个先决条件，则建立或询问某人建立所需的基于角色的访问控制(RBAC)，以便您可以发现 SharedSecret CR 实例，并启用服务帐户使用 SharedSecret CR 实例。

流程

  1. 通过使用带有 YAML 内容的 oc apply，为给定服务帐户 RBAC 权限授予其 pod 中的 SharedSecret CR 实例：

    注意

    目前，kubectl 和 oc 具有硬编码的特殊大小写逻辑，以便将 use 动词的使用限制为只限于 pod 安全性相关的角色。因此，您无法使用 oc create role …​ 创建使用 SharedSecret CR 实例所需的角色。 

    $ oc apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: shared-resource-my-share
  namespace: my-namespace
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedsecrets
    resourceNames:
      - my-share
    verbs:
      - use
EOF

  2. 使用 oc 命令创建与角色关联的 RoleBinding ： 

    $ oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

  3. 从 Pod 访问 SharedSecret CR 实例： 

    $ oc apply -f - <<EOF
kind: Pod
apiVersion: v1
metadata:
  name: my-app
  namespace: my-namespace
spec:
  serviceAccountName: default

# containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume

    volumes:
    - name: my-csi-volume
      csi:
        readOnly: true
        driver: csi.sharedresource.openshift.io
        volumeAttributes:
          sharedSecret: my-share

EOF

5.3.4. 在命名空间间共享配置映射

要在集群中的命名空间间共享配置映射，您可以为该配置映射创建 SharedConfigMap 自定义资源(CR)实例。

先决条件

您必须具有执行以下操作的权限：

  • 在集群范围的级别上创建 sharedconfigmaps.sharedresource.openshift.io 自定义资源定义(CRD)的实例。
  • 管理集群中命名空间中的角色和角色绑定，以控制哪些用户可以获取、列出和监视这些实例。
  • 管理集群中命名空间中的角色和角色绑定，以控制挂载 Container Storage Interface(CSI)卷的 pod 中的哪些服务帐户可以使用这些实例。
  • 访问包含您要共享 Secret 的命名空间。

流程

  1. 为您要在集群中的命名空间之间共享的配置映射创建 SharedConfigMap CR 实例： 

    $ oc apply -f - <<EOF
apiVersion: sharedresource.openshift.io/v1alpha1
kind: SharedConfigMap
metadata:
  name: my-share
spec:
  configMapRef:
    name: <name of configmap>
    namespace: <namespace of configmap>
EOF

5.3.5. 在 pod 中使用 SharedConfigMap 实例

后续步骤

要从 pod 访问 SharedConfigMap 自定义资源(CR)实例，您需要授予给定服务帐户 RBAC 权限以使用该 SharedConfigMap CR 实例。

先决条件

  • 为您要在集群中的命名空间之间共享的配置映射创建 SharedConfigMap CR 实例。

  • 您必须具有执行以下操作的权限：

    • 创建构建配置和启动构建。
    • 输入 oc get sharedconfigmaps 命令并返回非空列表来发现哪些 SharedConfigMap CR 实例可用。
    • 确定命名空间中的 builder 服务帐户是否可以使用给定的 SharedSecret CR 实例。也就是说，您可以运行 oc adm policy who-can use <identifier of specific SharedSecret> 来查看是否列出命名空间中的 builder 服务帐户。
注意

如果没有满足此列表中的最后两个先决条件，则建立或询问某人建立所需的基于角色的访问控制(RBAC)，以便您可以发现 SharedConfigMap CR 实例，并启用服务帐户使用 SharedConfigMap CR 实例。

流程

  1. 通过使用带有 YAML 内容的 oc apply，为给定服务帐户 RBAC 权限授予其 pod 中的 SharedConfigMap CR 实例。

    注意

    目前，kubectl 和 oc 具有硬编码的特殊大小写逻辑，以便将 use 动词的使用限制为只限于 pod 安全性相关的角色。因此，您无法使用 oc create role …​ 创建使用 SharedConfigMap CR 实例所需的角色。 

    $ oc apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: shared-resource-my-share
  namespace: my-namespace
rules:
  - apiGroups:
      - sharedresource.openshift.io
    resources:
      - sharedconfigmaps
    resourceNames:
      - my-share
    verbs:
      - use
EOF

  2. 使用 oc 命令创建与角色关联的 RoleBinding ： 

    oc create rolebinding shared-resource-my-share --role=shared-resource-my-share --serviceaccount=my-namespace:builder

  3. 从 pod 访问 SharedConfigMap CR 实例： 

    $ oc apply -f - <<EOF
kind: Pod
apiVersion: v1
metadata:
  name: my-app
  namespace: my-namespace
spec:
  serviceAccountName: default

# containers omitted …. Follow standard use of ‘volumeMounts’ for referencing your shared resource volume

    volumes:
    - name: my-csi-volume
      csi:
        readOnly: true
        driver: csi.sharedresource.openshift.io
        volumeAttributes:
          sharedConfigMap: my-share

EOF

5.3.6. 共享资源 CSI 驱动程序的额外支持限制

共享资源 CSI 驱动程序有以下值得注意的限制：

  • 驱动程序会受 Container Storage Interface(CSI)内联临时卷的限制。
  • readOnly 字段的值必须是 true。否则，在 pod 启动过程中卷置备，驱动会返回 kubelet 错误。这个限制是保持上游 Kubernetes CSI Driver 推荐的最佳实践，以将 SELinux 标签应用到关联的卷。
  • 驱动程序忽略 FSType 字段，因为它仅支持 tmpfs 卷。
  • 驱动程序忽略 NodePublishSecretRef 字段。相反，它使用 SubjectAccessReviews 和 use 动词来评估 pod 是否可以获取包含 SharedSecret 或 SharedConfigMap 自定义资源(CR)实例的卷。

5.3.7. 有关共享资源 pod 卷上的 VolumeAttributes 的更多详情

以下属性通过多种方式影响共享资源 pod 卷：

  • volumeAttributes 属性中的 refreshResource 属性。
  • Shared Resource CSI Driver 配置中的 refreshResources 属性。
  • volumeAttributes 属性中的 sharedSecret 和 sharedConfigMap 属性。

5.3.7.1. refreshResource 属性

Shared Resource CSI Driver 遵循卷的 volumeAttributes 属性中的 refreshResource 属性。此属性用于控制，在卷作为 pod 启动的一部分被初始置备后，的过程中，对底层 Secret 或 ConfigMap 对象的内容的更新是否会被复制到卷中。refreshResource 的默认值为 true，这意味着内容会被更新。

重要

如果 Shared Resource CSI Driver 配置禁用了对 sharedSecret 和 SharedConfigMap 自定义资源(CR)实例的刷新，则 volumeAttribute 属性中的 refreshResource 属性没有作用。这个属性的目的是在通常允许刷新时为特定卷挂载禁用刷新。

5.3.7.2. refreshResources 属性

您可以使用全局开关启用或禁用共享资源刷新。这个开关是 Shared Resource CSI Driver 的 csi-driver-shared-resource-config 配置映射中的 refreshResources 属性，您可以在 openshift-cluster-csi-drivers 命名空间中找到。如果将这个 refreshResources 属性设置为 false，则卷的初始置备后不会更新卷中存储的 Secret 或 ConfigMap 对象相关内容。

重要

使用此共享资源 CSI 驱动程序配置来禁用刷新会影响所有使用共享资源 CSI Driver 的卷挂载，无论这些卷的 volumeAttributes 属性中的 refreshResource 属性是什么。

5.3.7.3. 在为 pod 置备共享资源卷前验证 volumeAttribute

在单个卷的 volumeAttributes 中，您必须将 sharedSecret 或 sharedConfigMap 属性的值设置为 SharedSecret 或 SharedConfigMap CS 实例的值。否则，当在 pod 启动过程中置备卷时，验证会检查该卷的 volumeAttributes，并在出现以下条件时向 kubelet 返回错误：

  • sharedSecret 和 sharedConfigMap 属性都指定了值。
  • sharedSecret 和 sharedConfigMap 属性都没有指定值。
  • sharedSecret 或 sharedConfigMap 属性的值与集群中的 SharedSecret 或 SharedConfigMap CR 实例的名称不对应。

5.3.8. 共享资源、Insights Operator 和 OpenShift Container Platform 构建之间的集成

共享资源、Insights Operator 和 OpenShift Container Platform 构建之间的集成可以在 OpenShift Container Platform 构建中更轻松地使用红帽订阅（RHEL 权利）。

在以前的版本中，在 OpenShift Container Platform 4.9.x 及更早版本中，您可以手动导入凭证并将其复制到运行构建的每个项目或命名空间中。

现在，在 OpenShift Container Platform 4.10 及更新的版本中，OpenShift Container Platform 构建可以通过引用共享资源和 Insights Operator 提供的简单内容访问功能来使用红帽订阅（RHEL 权利）：

  • 简单的内容访问功能将您的订阅凭证导入到众所周知的 Secret 对象。请参阅以下 "Additional resources" 部分的链接。
  • 集群管理员创建与该 Secret 对象相关的 SharedSecret 自定义资源(CR)实例，并授予特定项目或命名空间的权限。特别是，集群管理员会赋予 builder 服务帐户权限，以使用该 SharedSecret CR 实例。
  • 在这些项目或命名空间中运行的构建可以挂载一个 CSI 卷，该卷引用 SharedSecret CR 实例及其授权的 RHEL 内容。

其他资源