文件存储类型

选择要供应的 类型 File Storage for Classic。

青铜，白银和黄金存储类

这些存储类供应耐久性存储器。 通过耐久性存储器，可以选择预定义 IOPS 层的存储器大小（以千兆字节为单位）。

定制存储类

此存储类供应性能存储器。 通过性能存储器，可以控制存储器和 IOPS 的大小。

IOPS

选择File Storage for Classic 的大小和 IOPS。 IOPS 的大小和数量定义了 IOPS（每秒输入/输出操作数）的总数，这用于指示存储器的速度。 存储器的总 IOPS 越高，处理读写操作的速度越快。

青铜，白银和黄金存储类

这些存储类别的每千兆字节 IOPS 数量是固定的，并在 SSD 硬盘上进行配置。 IOPS 的总数取决于您选择的存储器大小。 您可以在允许的大小范围内选择任意整数的千兆字节（例如，20 Gi、256 Gi、11854 Gi）。 要确定 IOPS 的总数，必须将 IOPS 乘以所选大小。 例如，如果您在银存储类别中选择了1000Gi File Storage for Classic大小（每 GB 4 IOPS），那么您的存储总共有 4000 IOPS。

定制存储类

选择这种存储类别时，您可以对所需的大小和 IOPS 进行更多控制。 对于大小，可以在允许的大小范围内选择任意整数的千兆字节。 选择的大小将确定可供您使用的 IOPS 范围。 您可以选择指定范围内是 100 的倍数的 IOPS。 您选择的 IOPS 是静态的，不会随存储器大小进行缩放。 例如，如果选择了 40 Gi 和 100 IOPS，那么总 IOPS 仍为 100。

IOPS 与千兆字节的比率还可确定供应的硬盘类型。 例如，如果对于 100 IOPS 选择了 500 Gi，那么 IOPS 与千兆字节的比率为 0.2。 比率小于或等于 0.3 的存储器在 SATA 硬盘上供应。 如果比率大于 0.3，那么会在 SSD 硬盘上供应存储器。

回收策略

选择在删除集群或持久卷声明 (PVC) 后是否要保留数据。

• 如果要保留数据，请选择 retain 存储类。 删除 PVC 时，仅会删除 PVC。 PV、IBM Cloud 基础架构帐户中的物理存储设备以及数据仍会存在。 要回收存储并再次在群集中使用，必须移除 PV，并按照 使用现有File Storage for Classic 步骤操作。
• 如果要在删除 PVC 时删除 PV、数据和物理 File Storage for Classic，请选择不带 retain 的存储类。

计费类型

选择每小时或每月。 查看 定价 以获取更多信息。

默认情况下，所有File Storage for Classic设备都是按小时计费的。

如果选择“每月”计费类型，那么除去持久性存储器时，即使只用了很短的时间，您也仍需支付该持久性存储器一个月的费用。

准备现有存储器

在开始将现有存储器安装到应用程序之前，必须检索 PV 的所有必要信息，并准备存储器以使其可供在集群中访问。

对于使用 retain 存储类配置的存储。

如果使用 retain 存储类供应了存储器，那么在除去 PVC 时，不会自动除去 PV 和物理存储设备。 要在集群中复用该存储器，必须首先除去剩余 PV。

要在供应现有存储器的集群之外的其他集群中使用该存储器，请执行在集群外部创建的存储器的步骤，以将存储器添加到工作程序节点的子网。

1. 列出现有 PV。

   kubectl get pv
   

   查找属于持久性存储器的 PV。 该 PV 处于 released 状态。

2. 获取该 PV 的详细信息。

   kubectl describe pv <pv_name>
   

3. 记下 CapacityGb、storageClass、failure-domain.beta.kubernetes.io/region、failure-domain.beta.kubernetes.io/zone、server 和 path。

4. 除去该 PV。

   kubectl delete pv <pv_name>
   

5. 验证 PV 是否已除去。

   kubectl get pv
   

对于在群集外配置的持久存储

如果要使用先前供应但从未在集群中使用的现有存储器，那么必须使存储器在工作程序节点所在的子网中可用。

1. 从 IBM Cloud基础架构门户，单击存储。
2. 单击 File Storage for Classic 并从“操作”菜单中选择“授权主机”。
3. 选择子网。
4. 从下拉列表中，选择工作程序节点连接到的专用 VLAN 子网。 要查找工作者节点的子网，请运行 ibmcloud ks worker ls --cluster <cluster_name> 并将工作者节点的 Private IP 与下拉列表中的子网进行比较。
5. 单击提交。
6. 单击File Storage for Classic 的名称。
7. 记录 Mount Point、size 和 Location 字段。 The Mount Point field is displayed as <nfs_server>:<file_storage_path>.

创建持久卷和持久卷声明

1. 为 PV 创建存储器配置文件。 包含先前检索到的值。

   apiVersion: v1
   kind: PersistentVolume
   metadata:
    name: mypv
    labels:
       failure-domain.beta.kubernetes.io/region: <region>
       failure-domain.beta.kubernetes.io/zone: <zone>
   spec:
    capacity:
      storage: "<size>"
    accessModes:
      - ReadWriteMany
    nfs:
      server: "<nfs_server>"
      path: "<file_storage_path>"
   

   name

   输入要创建的 PV 对象的名称。

   labels

   输入先前检索到的区域和专区。 必须在同一区域和专区中至少有一个工作程序节点。

   storage

   输入先前检索到的现有 NFS 文件共享的存储器大小。 输入的存储器大小必须以千兆字节为单位，例如 20Gi (20 GB) 或 1000Gi (1 TB)，并且大小必须与现有文件共享的大小相匹配。

   accessMode

   指定以下选项之一。

   • ReadWriteMany: The PVC can be mounted by multiple pods. 所有 pod 可对卷进行读取和写入。
   • ReadOnlyMany: The PVC can be mounted by multiple pods. 所有 pod 都具有只读访问权。
   • ReadWriteOnce: The PVC can be mounted by one pod only. 此 pod 可对卷进行读取和写入。

   server

   输入先前检索到的 NFS 文件共享服务器标识。

   path

   输入先前检索到的 NFS 文件共享的路径。

2. 在集群中创建 PV。

   kubectl apply -f mypv.yaml
   

3. 验证 PV 是否已创建。

   kubectl get pv
   

4. 创建另一个配置文件以创建 PVC。 为了使 PVC 与先前创建的 PV 相匹配，必须为 storage 和 accessMode 选择相同的值。 storage-class 字段必须为空字符串。 如果其中任何字段与 PV 不匹配，则会动态配置新的 PV 和新的物理存储实例。

   kind: PersistentVolumeClaim
   apiVersion: v1
   metadata:
     name: mypvc
   spec:
     accessModes:
      - ReadWriteMany
     resources:
       requests:
         storage: "<size>"
     storageClassName: ""
   

5. 创建 PVC。

   kubectl apply -f mypvc.yaml
   

6. 验证 PVC 是否已创建并与 PV 绑定。

   kubectl describe pvc mypvc
   

   示例输出

   Name: mypvc
   Namespace: default
   StorageClass:    ""
   Status: Bound
   Volume: pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   Labels: <none>
   Capacity: 20Gi
   Access Modes: RWX
   Events:
       FirstSeen LastSeen Count From        SubObjectPath Type Reason Message
       --------- -------- ----- ----        ------------- -------- ------ -------
       3m 3m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal Provisioning External provisioner is provisioning volume for claim "default/my-persistent-volume-claim"
       3m 1m     10 {persistentvolume-controller } Normal ExternalProvisioning can't find provisioner "ibm.io/ibmc-file", expecting that a volume for the claim is provisioned either manually or via external software
       1m 1m 1 {ibm.io/ibmc-file 31898035-3011-11e7-a6a4-7a08779efd33 } Normal ProvisioningSucceeded    Successfully provisioned volume pvc-0d787071-3a67-11e7-aafc-eef80dd2dea2
   

您已成功创建 PV，并将其绑定到 PVC。 现在，集群用户可以将 PVC 安装到其部署，并开始对 PV 对象执行读写操作。

使用动态供应创建有状态集时创建 PVC

如果要在创建有状态集时自动创建 PVC，请使用此选项。

开始之前 登录您的账户。 如果适用，请将相应的资源组设定为目标。 设置集群的上下文。

1. 验证集群中所有现有的有状态集是否已完全部署。 如果有状态数据集仍在部署中，则无法开始创建有状态数据集。 您必须等待集群中的所有有状态集完全部署，以避免发生意外结果。 列出集群中现有的有状态集。

   kubectl get statefulset --all-namespaces
   

   示例输出

   NAME              DESIRED   CURRENT   AGE
   mystatefulset     3         3         6s
   

2. 查看每个有状态集的 Pods Status，以确保有状态集部署完成。

   kubectl describe statefulset <statefulset_name>
   

   示例输出

   Name:               nginx
   Namespace:          default
   CreationTimestamp:  Fri, 05 Oct 2022 13:22:41 -0400
   Selector:           app=nginx,billingType=hourly,region=us-south,zone=dal10
   Labels:             app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   Annotations:        kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apps/v1","kind":"StatefulSet","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"podManagementPolicy":"Par..."
   Replicas:           3 desired | 3 total
   Pods Status:        0 Running / 3 Waiting / 0 Succeeded / 0 Failed
   Pod Template:
   Labels:  app=nginx
   billingType=hourly
   region=us-south
   zone=dal10
   

   在 CLI 输出的 Replicas 部分中找到的副本数等于 Pods Status 部分中 Running pod 的数目时，说明有状态集已完全部署。 如果有状态集尚未完全部署，请等待部署完成，然后再继续。

3. 为有状态集和用于公开有状态集的服务创建配置文件。

   指定区域的有状态设置示例。 以下示例显示了如何将 NGINX 部署为具有 3 个副本的有状态集。 根据 ibmc-file-retain-bronze 存储类中的规格，为每个副本配置一个 20GB 的File Storage for Classic设备。 所有存储设备都在 dal10 专区中供应。 由于File Storage for Classic无法从其他区域访问，因此有状态集的所有副本也都部署到位于 dal10 的工作节点上。

   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
    name: nginx
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: Parallel
     selector:
       matchLabels:
         app: nginx
         billingType: "hourly"
         region: "us-south"
         zone: "dal10"
     template:
       metadata:
         labels:
           app: nginx
           billingType: "hourly"
           region: "us-south"
           zone: "dal10"
       spec:
         containers:
         - name: nginx
           image: k8s.gcr.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol
             mountPath: /usr/share/nginx/html
       volumeClaimTemplates:
       - metadata:
          name: myvol
         spec:
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 20Gi
              iops: "300" #required only for performance storage
          storageClassName: ibmc-file-retain-bronze
   

   带有反亲和性规则和延迟File Storage for Classic创建的有状态数据集示例。 以下示例显示了如何将 NGINX 部署为具有 3 个副本的有状态集。 有状态设置未指定创建File Storage for Classic的区域和地区。 有状态集改为使用反亲缘关系规则来确保 pod 跨工作程序节点和专区分布。 工作程序节点反亲缘关系通过定义 app: nginx 标签来实现。 如果具有此标签的 pod 已在工作程序节点上运行，那么此标签指示 Kubernetes 调度程序不要将 pod 安排在此工作程序节点上。 topologykey: failure-domain.beta.kubernetes.io/zone 标签甚至进一步限制了此反亲缘关系规则：如果工作程序节点所在专区中，有已经运行具有 app: nginx 标签的 pod 的工作程序节点，那么此项会阻止 pod 安排在该工作程序节点上。 对于每个有状态集 pod，都会按照 volumeClaimTemplates 部分中的定义创建两个 PVC，但File Storage for Classic实例的创建会延迟，直到使用该存储的有状态集 pod 被调度。 这种设置被称为 拓扑感知卷调度。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: ibmc-file-bronze-delayed
   parameters:
     billingType: hourly
     classVersion: "2"
     iopsPerGB: "2"
     sizeRange: '[20-12000]Gi'
     type: Endurance
   provisioner: ibm.io/ibmc-file
   reclaimPolicy: Delete
   volumeBindingMode: WaitForFirstConsumer
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: nginx
     labels:
       app: nginx
   spec:
     ports:
     - port: 80
       name: web
     clusterIP: None
     selector:
       app: nginx
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: web
   spec:
     serviceName: "nginx"
     replicas: 3
     podManagementPolicy: "Parallel"
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         affinity:
           podAntiAffinity:
             preferredDuringSchedulingIgnoredDuringExecution:
             - weight: 100
               podAffinityTerm:
                 labelSelector:
                   matchExpressions:
                   - key: app
                     operator: In
                     values:
                     - nginx
                 topologyKey: failure-domain.beta.kubernetes.io/zone
         containers:
         - name: nginx
           image: k8s.gcr.io/nginx-slim:0.8
           ports:
           - containerPort: 80
             name: web
           volumeMounts:
           - name: myvol1
             mountPath: /usr/share/nginx/html
           - name: myvol2
             mountPath: /tmp1
     volumeClaimTemplates:
     - metadata:
         name: myvol1
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
     - metadata:
         name: myvol2
       spec:
         accessModes:
         - ReadWriteMany # access mode
         resources:
           requests:
             storage: 20Gi
         storageClassName: ibmc-file-bronze-delayed
   

   name

   在元数据中，输入有状态集的名称。 The name that you enter is used to create the name for your PVC in the format: <volume_name>-<statefulset_name>-<replica_number>.

   serviceName

   在规格部分，输入您要用于暴露有状态集的服务名称。

   replicas

   输入有状态集的副本数。

   podManagementPolicy

   输入要用于有状态集的 pod 管理策略。 在以下选项之间进行选择。

   • OrderedReady: With this option, stateful set replicas are deployed one after another. 例如，如果指定了 3 个副本，那么 Kubernetes 会为第一个副本创建 PVC，然后等待 PVC 绑定后，部署该有状态集副本，接着将 PVC 安装到该副本。 此部署完成后，将部署第二个副本。 有关此选项的更多信息，请参阅“OrderedReadyPod 管理”。
   • Parallel: With this option, the deployment of all stateful set replicas is started at the same time. 如果应用程序支持对副本进行并行部署，请使用此选项以节省 PVC 和有状态集副本的部署时间。

   matchLabels

   在“规格选择器”部分，输入要包含在有状态集和 PVC 中的所有标签。 Kubernetes 无法识别有状态集 volumeClaimTemplates 中包含的标签。 查看以下样本标签。

   • region and zone: If you want all your stateful set replicas and PVCs to be created in one specific zone, add both labels. 您还可以在使用的存储类中指定专区和区域。 如果未指定区域和地区，但拥有多区域群集，则会在轮循基础上选择调配存储的区域，以在所有区域间均衡卷请求。
   • billingType: Enter the billing type that you want to use for your PVCs. 在 hourly 或 monthly 之间进行选择。 如果不指定此标签，所有 PVC 都将以小时计费类型创建。

   labels

   在规范模板元数据部分中，输入添加到 spec.selector.matchLabels 部分的相同标签。

   affinity

   在规范模板规范亲缘关系部分中，指定反亲缘关系规则以确保有状态集 pod 分布在工作程序节点和区域中。 此示例显示了反亲缘关系规则，其中有状态集 pod 不希望安排在运行具有 app: nginx 标签的 pod 的工作程序节点上。 topologykey: failure-domain.beta.kubernetes.io/zone 甚至进一步限制了此反亲缘关系规则：如果工作程序节点与具有 app: nginx 标签的 pod 位于同一专区中，那么此项会阻止 pod 安排在该工作程序节点上。 通过使用此反亲缘关系规则，可以跨工作程序节点和专区实现反亲缘关系。

   name

   在规范卷声明模板元数据部分中，输入卷的名称。 使用与 spec.containers.volumeMount.name 部分中定义的相同名称。 The name that you enter here is used to create the name for your PVC in the format: <volume_name>-<statefulset_name>-<replica_number>.

   storage

   在“规范卷声明模板规范资源请求”部分中，输入 File Storage for Classic 的大小 (以千兆字节 (Gi) 为单位)。

   iops

   在“规范卷声明模板规范资源请求”部分中，如果要供应 性能存储器，请输入 IOPS 数。 如果使用耐久性存储类并指定了一些 IOPS，那么将忽略 IOPS 数， 而改为使用在存储类中指定的 IOPS。

   storageClassName

   在“规范卷声明模板规范”部分中，输入要使用的存储类。 要列出现有存储类，请运行 kubectl get sc | grep file。 如果未指定存储类别，则将使用群集中设置的默认存储类别创建 PVC。 确保默认存储类使用 ibm.io/ibmc-file 配置器，以便有状态数据集使用File Storage for Classic 进行配置。

4. 创建有状态集。

   kubectl apply -f statefulset.yaml
   

5. 等待有状态集进行部署。

   kubectl describe statefulset <statefulset_name>
   

要查看 PVC 的当前状态，请运行 kubectl get pvc。 PVC 的名称格式为 <volume_name>-<statefulset_name>-<replica_number>。

静态供应：将现有 PVC 用于有状态集

您可以在创建有状态集之前预先供应 PVC，也可以将现有 PVC 用于有状态集。

如果是在创建有状态集时动态供应 PVC，那么 PVC 的名称将根据在有状态集 YAML 文件中使用的值来指定。 为了使有状态集使用现有 PVC，PVC 的名称必须与使用动态供应时自动创建的名称相匹配。

开始之前 登录您的账户。 如果适用，请将相应的资源组设定为目标。 设置集群的上下文。

1. 如果要在创建有状态集之前预配置 PVC，请按照 为应用程序添加File Storage for Classic 中的步骤 1-3 为每个有状态集副本创建一个 PVC。 Make sure that you create your PVC with a name that follows the following format: <volume_name>-<statefulset_name>-<replica_number>.

   <volume_name>

   使用要在有状态设置的 spec.volumeClaimTemplates.metadata.name 部分指定的名称，如 nginxvol。

   <statefulset_name>

   使用要在有状态设置的 metadata.name 部分指定的名称，如 nginx_statefulset。

   <replica_number>

   输入从 0 开始的副本编号。

   例如，如果必须创建 3 个有状态集副本，请使用以下名称创建 3 个 PVC：nginxvol-nginx_statefulset-0、nginxvol-nginx_statefulset-1 和 nginxvol-nginx_statefulset-2。

   想要为现有File Storage for Classic实例创建 PVC 和 PV？ 请使用静态供应来创建 PVC 和 PV。

2. 执行动态供应：创建有状态集时创建 PVC 中的步骤来创建有状态集。 PVC 的名称格式为 <volume_name>-<statefulset_name>-<replica_number>。 确保在有状态设置规范中使用 PVC 名称中的以下值。

   spec.volumeClaimTemplates.metadata.name

   输入您的 PVC 名称的 <volume_name>。

   metadata.name

   输入您的 PVC 名称的 <statefulset_name>。

   spec.replicas

   输入要为有状态数据集创建的副本数量。 副本数必须等于早先创建的 PVC 数。

   如果您的 PVC 位于不同的区域，则不要在有状态设置中包含区域或区域标签。

3. 通过列出集群中的 pod 并标识属于有状态集的 pod，验证是否在有状态集副本 pod 中使用了 PVC。

   kubectl get pods
   

4. 验证现有 PVC 是否已安装到有状态集副本。 请在 CLI 输出的 ClaimName 部分中查看 Volumes。

   kubectl describe pod <pod_name>
   

   示例输出

   Name:           nginx-0
   Namespace:      default
   Node:           10.xxx.xx.xxx/10.xxx.xx.xxx
   Start Time:     Fri, 05 Oct 2022 13:24:59 -0400
   ...
   Volumes:
   myvol:
       Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
       ClaimName:  myvol-nginx-0
   ...
   

创建具有特定NFS版本的自定义存储类

1. 使用要供应的 NFS 版本创建定制存储类。

2. 在集群中创建存储类。

   kubectl apply -f nfsversion_storageclass.yaml
   

3. 验证是否已创建定制存储类。

   kubectl get sc
   

4. 为 File Storage for Classic 提供自定义存储类。

更改现有 PV 以使用不同的NFS版本

1. 获取要更改NFS版本的File Storage for Classic的 PV，并记下 PV 的名称。

   kubectl get pv
   

2. 向 PV 添加注释。 将 <version_number> 替换为要使用的NFS版本。 例如，要更改为 NFS V3.0，请输入 3。

   kubectl patch pv <pv_name> -p '{"metadata": {"annotations":{"volume.beta.kubernetes.io/mount-options":"vers=<version_number>"}}}'
   

3. 删除使用File Storage for Classic的 pod，然后重新创建 pod。

   1. 将 pod YAML 保存到本地计算机。

      kubect get pod <pod_name> -o yaml > <filepath/pod.yaml>
      

   2. 删除 pod。

      kubectl deleted pod <pod_name>
      

   3. 重新创建 pod。

      kubectl apply -f pod.yaml
      

4. 等待 pod 部署。 状态更改为 Running 时，说明 pod 已完全部署。

   kubectl get pods
   

5. 登录到 pod。

   kubectl exec -it <pod_name> sh
   

6. 验证File Storage for Classic是否已使用之前指定的NFS版本加载。

   mount | grep "nfs" | awk -F" |," '{ print $5, $8 }'
   

   示例输出

   nfs vers=3.0
   

设置定期快照

您可以 为File Storage for Classic设置定期快照，这是一种只读映像，可捕捉实例在某个时间点的状态。 要存储快照，必须在File Storage for Classic上申请快照空间。 快照会存储在同一专区的现有存储器实例上。 如果用户意外地从卷中除去了重要数据，那么可以通过快照来复原数据。

完成以下步骤以创建卷的快照。

1. 登录您的账户。 如果适用，请将相应的资源组设定为目标。 设置集群的上下文。

2. 登录到 ibmcloud sl CLI。

   ibmcloud sl init
   

3. 列出集群中的现有 PV。

   kubectl get pv
   

4. 获取要为其创建快照空间的 PV 的详细信息，并记下卷标识、大小和 IOPS。 卷 ID、大小和 IOPS 可在 CLI 输出的“标签” 部分找到。

   kubectl describe pv <pv_name>
   

5. 使用您在先前步骤中检索到的参数为现有卷创建快照大小。

   ibmcloud sl file snapshot-order <volume_ID> --size <size> --tier <iops>
   

6. 等待快照大小创建。 当 CLI 输出中的快照大小 (GB) 从 0 变为您订购的大小时，快照大小已成功配置。

   ibmcloud sl file volume-detail <volume_ID>
   

7. 为卷创建快照，并记下创建的快照的标识。

   ibmcloud sl file snapshot-create <volume_ID>
   

8. 验证快照是否已成功创建。

   ibmcloud sl file snapshot-list <volume_ID>
   

9. 设置快照调度。 有关可用于快照调度的选项的更多信息，请参阅 CLI 文档。

   ibmcloud sl block snapshot-enable VOLUME_ID <OPTIONS>
   

10. 要将数据从快照复原到现有卷，请运行以下命令。

    ibmcloud sl file snapshot-restore <volume_ID> <snapshot_ID>
    

将快照复制到另一区域

要保护数据不受区域故障影响，可以 将快照复制到 另一个区域中的File Storage for Classic实例。

数据只能从主存储器复制到备份存储器。 无法将复制的 File Storage for Classic 实例安装到集群。 主存储器发生故障时，可以手动将复制的备份存储器设置为主存储器。 然后，可以将其安装到集群。 复原主存储器后，可以从备份存储器复原数据。

正在复制存储器

您可以在与原始存储实例相同的区域 复制File Storage for Classic实例。

复制项所含的数据是其创建的那个时间点上原始存储器实例的数据。 与副本不同，复制项用作独立于原始项的存储器实例。 要进行复制，请首先为卷设置快照。

将数据备份到 IBM Cloud® Object Storage

您可以使用 ibm-backup-restore Helm图表 在集群中启动备份和还原 pod。

此 pod 包含一个脚本，用于对集群中的任何持久卷声明 (PVC) 运行一次性或定期备份。 数据存储在您在某个专区设置的 IBM Cloud® Object Storage 实例中。

要使数据具有更高可用性，并保护应用程序不受专区故障的影响，请设置第二个 IBM Cloud® Object Storage 实例，并在各个专区之间复制数据。 如果需要还原IBM Cloud® Object Storage实例中的数据，请使用Helm图表提供的还原脚本。

在 pod 和容器之间复制数据

您可以使用 kubectl cp 命令将文件和目录复制到集群中的 pod 或特定容器，也可以从 pod 或特定容器复制文件和目录。

开始之前 登录您的账户。 如果适用，请将相应的资源组设定为目标。 设置集群的上下文。 如果不使用 -c 指定容器，命令会使用 pod 中第一个可用的容器。

将数据从本地计算机复制到群集中的 pod。

kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath>

将数据从群集中的 pod 复制到本地计算机。

kubectl cp <namespace>/<pod>:<pod_filepath>/<filename></var> <local_filepath>/<filename>

将数据从本地计算机复制到在集群的 pod 中运行的特定容器。

kubectl cp <local_filepath>/<filename> <namespace>/<pod>:<pod_filepath> -c CONTAINER

创建拓扑感知存储器

要在多区集群中使用File Storage for Classic，您的 pod 必须与File Storage for Classic实例调度在同一区，这样才能读写卷。 在Kubernetes 引入拓扑感知卷调度之前，存储的动态调配会在创建 PVC 时自动创建File Storage for Classic实例。 然后，在创建 pod 时，Kubernetes调度器会尝试将 pod 部署到与File Storage for Classic实例位于同一数据中心的工作节点上。

在不知道 pod 约束条件的情况下创建File Storage for Classic实例可能会导致不必要的结果。 例如，可能会由于存储器所在的工作程序节点的资源不足，或者该工作程序节点有污点而不允许安排 pod，导致您的 pod 无法安排到该工作程序节点。 通过拓扑感知卷调度，File Storage for Classic实例会延迟到第一个使用该存储的 pod 创建完成。

下面的示例展示了如何创建存储类，将File Storage for Classic实例的创建延迟到第一个使用该存储的 pod 准备好调度时。 要延迟创建，必须包含 volumeBindingMode: WaitForFirstConsumer 选项。 如果不包含此选项，则 volumeBindingMode 会自动设置为 Immediate，并在创建 PVC 时创建File Storage for Classic实例。

耐力File Storage for Classic的示例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-bronze-delayed
parameters:
  billingType: hourly
  classVersion: "2"
  iopsPerGB: "2"
  sizeRange: '[20-12000]Gi'
  type: Endurance
  provisioner: ibm.io/ibmc-file
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer

性能File Storage for Classic 的示例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
 billingType: "hourly"
 classVersion: "2"
 sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
 type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

为多专区集群指定专区

如果要在特定区域创建File Storage for Classic，可以在自定义存储类中指定区域和地区。

如果要在特定区域 静态配置File Storage for Classic 请使用自定义存储类。 在其他所有情况下，请直接在 PVC 中指定专区。

创建定制存储类时，请指定集群和工作程序节点所在的区域和专区。 要获取群集的区域，请运行 ibmcloud ks cluster get --cluster <cluster_name_or_ID> 并在主 URL 中查找区域前缀，如 https://c2.eu-de.containers.cloud.ibm.com:11111 中的 eu-de。 要获取工作节点的区域，请运行 ibmcloud ks worker ls --cluster <cluster_name_or_ID>。

耐力File Storage for Classic的示例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-silver-mycustom-storageclass
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  type: "Endurance"
  iopsPerGB: "4"
  sizeRange: "[20-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
reclaimPolicy: Delete
volumeBindingMode: Immediate

性能File Storage for Classic 的示例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: ibmc-file-performance-storageclass
 labels:
   kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  zone: "dal12"
  region: "us-south"
  billingType: "hourly"
  classVersion: "2"
  sizeIOPSRange: |-
   "[20-39]Gi:[100-1000]"
   "[40-79]Gi:[100-2000]"
   "[80-99]Gi:[100-4000]"
   "[100-499]Gi:[100-6000]"
   "[500-999]Gi:[100-10000]"
   "[1000-1999]Gi:[100-20000]"
   "[2000-2999]Gi:[200-40000]"
   "[3000-3999]Gi:[200-48000]"
   "[4000-7999]Gi:[300-48000]"
   "[8000-9999]Gi:[500-48000]"
   "[10000-12000]Gi:[1000-48000]"
  type: "Performance"
reclaimPolicy: Delete
volumeBindingMode: Immediate

更改缺省 NFS 版本

以下定制存储类允许您定义要供应的 NFS 版本。 例如，要配置NFS 3.0 版本，请将 <nfs_version> 替换为 3.0。

耐力File Storage for Classic的示例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Endurance"
  iopsPerGB: "2"
  sizeRange: "[1-12000]Gi"
  reclaimPolicy: "Delete"
  classVersion: "2"
  mountOptions: nfsvers=<nfs_version>

性能File Storage for Classic 的示例。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: ibmc-file-mount
labels:
  kubernetes.io/cluster-service: "true"
provisioner: ibm.io/ibmc-file
parameters:
  type: "Performance"
  classVersion: "2"
  sizeIOPSRange: |-
    "[20-39]Gi:[100-1000]"
    "[40-79]Gi:[100-2000]"
    "[80-99]Gi:[100-4000]"
    "[100-499]Gi:[100-6000]"
    "[500-999]Gi:[100-10000]"
    "[1000-1999]Gi:[100-20000]"
    "[2000-2999]Gi:[200-40000]"
    "[3000-3999]Gi:[200-48000]"
    "[4000-7999]Gi:[300-48000]"
    "[8000-9999]Gi:[500-48000]"
    "[10000-12000]Gi:[1000-48000]"
  mountOptions: nfsvers=<nfs_version>

了解存储器除去选项

根据供应存储器的方式以及已除去的组件，从 IBM Cloud 帐户中除去持久性存储器的操作会有所不同。

删除群集时，我的持久存储会被删除吗？

在集群删除期间，您可以选择除去持久性存储器。 但是，根据存储器的供应方式，除去存储器时，可能不会包含所有存储组件。 如果您使用设置了 reclaimPolicy: Delete 的存储类动态配置了存储，那么在删除群集时，您的 PVC、PV 和存储实例会被自动删除。 对于静态配置的存储或使用设置 reclaimPolicy: Retain 的存储类配置的存储，在删除群集时，PVC 和 PV 会被移除，但存储实例和数据会保留。 您仍将为存储器实例付费。 此外，如果删除的是状态为运行状况不佳的集群，那么即使选择除去存储器，存储器也可能会仍然存在。

当我想保留群集时，如何删除存储？

使用设置了 reclaimPolicy: Delete 的存储类动态供应存储器时，可以通过除去 PVC 来启动持久性存储器的删除过程。 这将自动除去 PVC、PV 和存储器实例。 对于静态配置的存储或使用设置 reclaimPolicy: Retain 的存储类配置的存储，必须手动删除 PVC、PV 和存储实例，以避免进一步收费。

删除存储后，如何停止计费？

根据您删除的存储组件和删除时间，计费周期可能不会立即停止。 如果删除了 PVC 和 PV，但未删除 IBM Cloud 帐户中的存储器实例，那么该实例仍然存在，因此仍需要为此付费。

如果删除了 PVC、PV 和存储器实例，那么计费周期会停止，具体取决于在供应存储器时选择的 billingType 以及选择的存储器删除方式。

• 从IBM Cloud控制台或 CLI 手动取消持久存储实例时，计费会按如下方式停止：

  • 按小时计费存储器：将立即停止计费。 取消存储器后，可能最长 72 小时内仍会在控制台中看到该存储器实例。
  • 按月计费存储器：可以选择立即取消或在周年日期取消。 在这两种情况下，将计费到当前计费周期结束，并停止对下一个计费周期的计费。 取消存储器后，可能最长 72 小时内仍会在控制台或 CLI 中看到该存储器实例。
  • 立即取消：选择此选项可立即除去存储器。 您或您的用户都无法再使用存储器，也无法恢复数据。
  • 周年日期：选择此选项可在下一个周年日期取消存储器。 存储器实例会一直保持活动状态，直到下一个周年日期为止，并且在此日期之前，您可以继续使用这些存储器实例，例如让团队有时间来备份数据。

• 使用设置了 reclaimPolicy: Delete 的存储类动态供应存储器时，如果您选择除去 PVC，将立即除去 PV 和存储器实例。 对于按小时计费的存储器，计费会立即停止。 对于按月计费的存储器，您仍需要为该月的剩余时间付费。 除去存储器并且计费停止后，可能最长 72 小时内仍会在控制台或 CLI 中看到该存储器实例。

删除持久存储前需要注意什么？

清除持久性存储器时，将删除其中存储的所有数据。 如果您需要数据的副本，请进行备份。

我删除了我的存储实例。 为什么我还能看到我的实例？

除去持久性存储器后，除去操作可能最长需要 72 小时才能完全处理好，在此之后存储器不会再显示在 IBM Cloud 控制台或 CLI 中。

清除持久性存储器

从 IBM Cloud 帐户中除去 PVC、PV 和存储器实例，可避免对持久性存储器进一步收费。

开始之前：

• 确保备份了要保留的所有数据。
• 登录您的账户。 如果适用，请将相应的资源组设定为目标。 设置集群的上下文。

要清除持久数据，请执行以下操作：

1. 列出集群中的 PVC，并记下 PVC 的 NAME、STORAGECLASS 以及绑定到该 PVC 并显示为 VOLUME 的 PV 的名称。

   kubectl get pvc
   

   示例输出

   NAME                  STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS            AGE
   claim1   Bound     pvc-06886b77-102b-11e8-968a-f6612bb731fb   20Gi       RWO           class       78d
   claim2     Bound     pvc-457a2b96-fafc-11e7-8ff9-b6c8f770356c   4Gi        RWX           class 105d
   claim3      Bound     pvc-1efef0ba-0c48-11e8-968a-f6612bb731fb   24Gi       RWX           class        83d
   

2. 查看存储类的 ReclaimPolicy 和 billingType。

   kubectl describe storageclass <storageclass_name>
   

   如果回收策略显示 Delete，那么在除去 PVC 时会除去 PV 和物理存储器。 如果回收策略显示 Retain，或者所供应的存储器不具有存储类，那么在除去 PVC 时不会除去 PV 和物理存储器。 PVC、PV 和物理存储器必须分别进行除去。

   如果存储器按月收费，那么即使在计费周期结束之前除去了存储器，也仍需要按整月付费。

3. 除去安装了 PVC 的所有 pod。 列出安装了 PVC 的所有 pod。 如果 CLI 输出中没有返回 pod，则说明没有 pod 使用 PVC。

   kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.persistentVolumeClaim.claimName}{" "}{end}{end}' | grep "<pvc_name>"
   

   示例输出

   depl-12345-prz7b:    claim1
   

4. 除去使用 PVC 的 pod。 如果 pod 是部署的一部分，请除去该部署。

   kubectl delete pod <pod_name>
   

5. 验证 pod 是否已除去。

   kubectl get pods
   

6. 除去 PVC。

   kubectl delete pvc <pvc_name>
   

7. 查看 PV 的阶段状态。 使用先前检索到的显示为 VOLUME 的 PV 的名称。 除去 PVC 时，会释放绑定到该 PVC 的 PV。 如果 PV 是自动删除的，那么该 PV 会进入 Deleting 状态；如果必须手动删除 PV，那么该 PV 会进入 Released 状态，具体取决于存储器的供应方式。 注：对于自动删除的 PV，在删除之前，阶段状态可能会短暂地显示为 Released。 请在几分钟后重新运行该命令以查看该 PV 是否已除去。

   kubectl get pv <pv_name>
   

8. 如果 PV 未删除，请手动除去该 PV。

   kubectl delete pv <pv_name>
   

9. 验证 PV 是否已除去。

   kubectl get pv
   

10. 列出 PV 指向的物理存储器实例，并记下物理存储器实例的 id。

    ibmcloud sl file volume-list --columns id  --columns notes | grep <pv_name>
    

    File Storage for Classic 的输出示例。

    id         notes   
    12345678   {"plugin":"ibm-file-plugin-5b55b7b77b-55bb7","region":"us-south","cluster":"aa1a11a1a11b2b2bb22b22222c3c3333","type":"Endurance","ns":"default","pvc":"mypvc","pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7","storageclass":"ibmc-file-gold"}
    

    "plugin":"ibm-file-plugin-5b55b7b77b-55bb7"

    群集使用的存储插件。

    "region":"us-south"

    群集所在的区域。

    "cluster":"aa1a11a1a11b2b2bb22b22222c3c3333"

    与存储实例相关联的群集 ID。

    "type":"Endurance"

    文件或块存储的类型，可以是 Endurance 或 Performance。

    "ns":"default"

    存储实例部署到的命名空间。

    "pvc":"mypvc"

    与存储实例相关联的 PVC 的名称。

    "pv":"pvc-d979977d-d79d-77d9-9d7d-d7d97ddd99d7"

    与存储实例相关联的 PV。

    "storageclass":"ibmc-file-gold"

    存储类别：铜、银、金或定制。

11. 除去物理存储器实例。

    ibmcloud sl file volume-cancel <classic_file_id>
    

12. 验证物理存储器实例是否已除去。

    ibmcloud sl file volume-list
    

删除过程最长可能需要 72 小时才能完成。