| copyright | lastupdated | keywords | subcollection | ||
|---|---|---|---|---|---|
|
2021-03-22 |
kubernetes, iks |
containers |
{:DomainName: data-hd-keyref="APPDomain"} {:DomainName: data-hd-keyref="DomainName"} {:android: data-hd-operatingsystem="android"} {:api: .ph data-hd-interface='api'} {:apikey: data-credential-placeholder='apikey'} {:app_key: data-hd-keyref="app_key"} {:app_name: data-hd-keyref="app_name"} {:app_secret: data-hd-keyref="app_secret"} {:app_url: data-hd-keyref="app_url"} {:authenticated-content: .authenticated-content} {:beta: .beta} {:c#: data-hd-programlang="c#"} {:cli: .ph data-hd-interface='cli'} {:codeblock: .codeblock} {:curl: .ph data-hd-programlang='curl'} {:deprecated: .deprecated} {:dotnet-standard: .ph data-hd-programlang='dotnet-standard'} {:download: .download} {:external: target="_blank" .external} {:faq: data-hd-content-type='faq'} {:fuzzybunny: .ph data-hd-programlang='fuzzybunny'} {:generic: data-hd-operatingsystem="generic"} {:generic: data-hd-programlang="generic"} {:gif: data-image-type='gif'} {:go: .ph data-hd-programlang='go'} {:help: data-hd-content-type='help'} {:hide-dashboard: .hide-dashboard} {:hide-in-docs: .hide-in-docs} {:important: .important} {:ios: data-hd-operatingsystem="ios"} {:java: .ph data-hd-programlang='java'} {:java: data-hd-programlang="java"} {:javascript: .ph data-hd-programlang='javascript'} {:javascript: data-hd-programlang="javascript"} {:new_window: target="_blank"} {:note .note} {:note: .note} {:objectc data-hd-programlang="objectc"} {:org_name: data-hd-keyref="org_name"} {:php: data-hd-programlang="php"} {:pre: .pre} {:preview: .preview} {:python: .ph data-hd-programlang='python'} {:python: data-hd-programlang="python"} {:route: data-hd-keyref="route"} {:row-headers: .row-headers} {:ruby: .ph data-hd-programlang='ruby'} {:ruby: data-hd-programlang="ruby"} {:runtime: architecture="runtime"} {:runtimeIcon: .runtimeIcon} {:runtimeIconList: .runtimeIconList} {:runtimeLink: .runtimeLink} {:runtimeTitle: .runtimeTitle} {:screen: .screen} {:script: data-hd-video='script'} {:service: architecture="service"} {:service_instance_name: data-hd-keyref="service_instance_name"} {:service_name: data-hd-keyref="service_name"} {:shortdesc: .shortdesc} {:space_name: data-hd-keyref="space_name"} {:step: data-tutorial-type='step'} {:subsection: outputclass="subsection"} {:support: data-reuse='support'} {:swift: .ph data-hd-programlang='swift'} {:swift: data-hd-programlang="swift"} {:table: .aria-labeledby="caption"} {:term: .term} {:tip: .tip} {:tooling-url: data-tooling-url-placeholder='tooling-url'} {:troubleshoot: data-hd-content-type='troubleshoot'} {:tsCauses: .tsCauses} {:tsResolve: .tsResolve} {:tsSymptoms: .tsSymptoms} {:tutorial: data-hd-content-type='tutorial'} {:ui: .ph data-hd-interface='ui'} {:unity: .ph data-hd-programlang='unity'} {:url: data-credential-placeholder='url'} {:user_ID: data-hd-keyref="user_ID"} {:vbnet: .ph data-hd-programlang='vb.net'} {:video: .video}
{: #kube_concepts}
{: #pvc_pv}
Before you get started with provisioning storage, it is important to understand the Kubernetes concepts of a persistent volume and a persistent volume claim and how they work together in a cluster. {: shortdesc}
The following image shows the storage components in a cluster.
- Cluster: By default, every cluster is set up with a plug-in to provision file storage. You can choose to install other add-ons, such as the one for block storage. To use storage in a cluster, you must create a persistent volume claim, a persistent volume and a physical storage instance. When you delete the cluster, you have the option to delete related storage instances.
- App: To read from and write to your storage instance, you must mount the persistent volume claim (PVC) to your app. Different storage types have different read-write rules. For example, you can mount multiple pods to the same PVC for file storage. Block storage comes with a RWO (ReadWriteOnce) access mode so that you can mount the storage to one pod only.
- Persistent volume claim (PVC): A PVC is the request to provision persistent storage with a specific type and configuration. To specify the persistent storage flavor that you want, you use Kubernetes storage classes. The cluster admin can define storage classes, or you can choose from one of the predefined storage classes in {{site.data.keyword.containerlong_notm}}. When you create a PVC, the request is sent to the {{site.data.keyword.Bluemix}} storage provider. Depending on the configuration that is defined in the storage class, the physical storage device is ordered and provisioned into your IBM Cloud infrastructure account. If the requested configuration does not exist, the storage is not created.
- Persistent volume (PV): A PV is a virtual storage instance that is added as a volume to the cluster. The PV points to a physical storage device in your IBM Cloud infrastructure account and abstracts the API that is used to communicate with the storage device. To mount a PV to an app, you must have a matching PVC. Mounted PVs appear as a folder inside the container's file system.
- Physical storage: A physical storage instance that you can use to persist your data. Examples of physical storage in {{site.data.keyword.cloud_notm}} include File Storage, Block Storage, Object Storage, and local worker node storage that you can use as SDS storage with Portworx. {{site.data.keyword.cloud_notm}} provides high availability for physical storage instances. However, data that is stored on a physical storage instance is not backed up automatically. Depending on the type of storage that you use, different methods exist to set up backup and restore solutions.
For more information about how to create and use PVCs, PVs, and the physical storage device, see:
{: #dynamic_provisioning}
Use dynamic provisioning if you want to give developers the freedom to provision storage when they need it. {: shortdesc}
How does it work?
Dynamic provisioning is a feature that is native to Kubernetes and that allows a cluster developer to order storage with a pre-defined type and configuration without knowing all the details about how to provision the physical storage device. To abstract the details for the specific storage type, the cluster admin must create storage classes that the developer can use, or use the storage classes that are provided with the {{site.data.keyword.Bluemix}} storage plug-ins.
To order the storage, you must create a PVC. The PVC determines the specification for the storage that you want to provision. After the PVC is created, the storage device and the PV are automatically created for you.
The following image shows how file storage is dynamically provisioned in a cluster. This sample flow works similarly with other storage types, such as block storage.
Sample flow for dynamic provisioning of file storage with the pre-defined silver storage class
- The user creates a persistent volume claim (PVC) that specifies the storage type, storage class, size in gigabytes, number of IOPS, and billing type. The storage class determines the type of storage that is provisioned and the allowed ranges for size and IOPS. Creating a PVC in a cluster automatically triggers the storage plug-in for the requested type of storage to provision storage with the given specification.
- The storage device is automatically ordered and provisioned into your IBM Cloud infrastructure account. The billing cycle for your storage device starts.
- The storage plug-in automatically creates a persistent volume (PV) in the cluster, a virtual storage device that points to the actual storage device in your IBM Cloud infrastructure account.
- The PVC and PV are automatically connected to each other. The status of the PVC and the PV changes to
Bound. You can now use the PVC to mount persistent storage to your app. If you delete the PVC, the PV and related storage instance are also deleted.
When do I use dynamic provisioning?
Review the following common use cases for dynamic provisioning:
- Provision storage when needed: Instead of pre-providing persistent storage for developers and paying for storage that is not used, you can give developers the freedom to provision storage when they need it. To determine the type of storage that the developer can provision, you can define storage classes.
- Automate the creation of PVC, PV, and storage device: You want to automatically provision and deprovision storage without manual intervention from a cluster admin.
- Create and delete storage often: You have an app or set up a continuous delivery pipeline that creates and removes persistent storage regularly. Persistent storage that is dynamically provisioned with a non-retaining storage class can be removed by deleting the PVC.
For more information about how to dynamically provision persistent storage, see:
- Classic File Storage
- Classic Block Storage
- VPC Block Storage
- {{site.data.keyword.cos_full_notm}}
- Portworx
{: #static_provisioning}
If you have an existing persistent storage device in your IBM Cloud infrastructure account, you can use static provisioning to make the storage instance available to your cluster. {: shortdesc}
How does it work?
Static provisioning is a feature that is native to Kubernetes and that allows cluster administrators to make existing storage devices available to a cluster. As a cluster administrator, you must know the details of the storage device, its supported configurations, and mount options.
To make existing storage available to a cluster user, you must manually create the storage device, a PV, and a PVC.
The following image shows how to statically provision file storage in a cluster. This sample flow works similar with other storage types, such as block storage.
Sample flow for static provisioning of file storage
- The cluster admin gathers all the details about the existing storage device and creates a persistent volume (PV) in the cluster.
- Based on the storage details in the PV, the storage plug-in connects the PV with the storage device in your IBM Cloud infrastructure account.
- The cluster admin or a developer creates a PVC. Because the PV and the storage device already exist, no storage class is specified in the PVC.
- After the PVC is created, the storage plug-in tries to match the PVC to an existing PV. The PVC and the PV match when the same values for the size, IOPS, and access mode are used in the PVC and the PV. When PVC and PV match, the status of the PVC and the PV changes to
Bound. You can now use the PVC to mount persistent storage to your app. When you delete the PVC, the PV and the physical storage instance are not removed. You must remove the PVC, PV, and the physical storage instance separately.
When do I use static provisioning?
Review the following common use cases for static provisioning of persistent storage:
- Make retained data available to the cluster: You provisioned persistent storage with a retain storage class by using dynamic provisioning. You removed the PVC, but the PV, the physical storage in IBM Cloud infrastructure, and the data still exist. You want to access the retained data from an app in your cluster.
- Use an existing storage device: You provisioned persistent storage directly in your IBM Cloud infrastructure account and want to use this storage device in your cluster.
- Share persistent storage across clusters in the same zone: You provisioned persistent storage for your cluster. To share the same persistent storage instance with other clusters in the same zone, you must manually create the PV and matching PVC in the other cluster. Note: Sharing persistent storage across clusters is available only if the cluster and the storage instance are located in the same zone.
- Share persistent storage across namespaces in the same cluster: You provisioned persistent storage in a namespace of your cluster. You want to use the same storage instance for an app pod that is deployed to a different namespace in your cluster.
For more information about how to statically provision storage, see:
- Classic File Storage
- Classic Block Storage
- VPC Block Storage
- {{site.data.keyword.cos_full_notm}}
- Portworx{: external}
{: #storageclasses}
To dynamically provision persistent storage, you must define the type and configuration of the storage that you want. {: shortdesc}
A Kubernetes storage class{: external} is used to abstract the underlying storage platform that is supported in {{site.data.keyword.cloud_notm}} so that you do not have to know all the details about supported sizes, IOPS, or retention policies to successfully provision persistent storage in a cluster. {{site.data.keyword.containerlong_notm}} provides pre-defined storage classes for every type of storage that is supported. Each storage class is designed to abstract the supported storage tier while giving you the choice to decide on the size, IOPS, and retention policy that you want.
For the pre-defined storage class specifications, see:
Not finding what you are looking for? You can also create your own customized storage class to provision the type of storage that you want. {: tip}
{: #customized_storageclass}
If you cannot use one of the provided storage classes, you can create your own customized storage class. You might want to customize a storage class to specify configurations such as the zone, file system type, server type, or volume binding mode{: external} options (block storage only). {: shortdesc}
-
Create a customized storage class. You can start by using one of the pre-defined storage classes, or check out our sample customized storage classes.
- Pre-defined storage classes:
- Sample customized storage classes:
-
Create the customized storage class.
kubectl apply -f <local_file_path>{: pre}
-
Verify that the customized storage class is created.
kubectl get storageclasses{: pre}
-
Create a persistent volume claim (PVC) to dynamically provision storage with your customized storage class.
-
Verify that your PVC is created and bound to a persistent volume (PV). This process might take a few minutes to complete.
kubectl get pvc{: pre}
{: #update_storageclass}
When you dynamically provision persistent storage by using a storage class, you provision persistent storage with a specific configuration. You cannot change the name of the storage class or the type of storage that you provisioned. However, you have the option to scale your storage as shows in the following table. {: shortdesc}
| Storage solution | Scaling options |
|---|---|
| Classic File Storage | You can increase your storage size and assigned IOPS by [modifying your existing volume](/docs/containers?topic=containers-file_storage#file_change_storage_configuration). |
| Classic Block Storage | You can increase your storage size and assigned IOPS by [modifying your existing volume](/docs/containers?topic=containers-block_storage#block_change_storage_configuration). |
| VPC Block Storage | You cannot change the storage size or assigned IOPS. |
| {{site.data.keyword.cos_full_notm}} | Your volume automatically scales in size and you are charged based on your actual consumption. However, you cannot change the performance attributes of your volume as they are defined in the storage class that you used to create your bucket in {{site.data.keyword.cos_full_notm}}. To change to a different storage class, you must provision a new bucket by using the storage class that you want. Then, copy your data from the old bucket to the new one. |
| Portworx | You can increase your storage size by [changing your PVC specifications ](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/create-pvcs/resize-pvc/). |
{: #default_storageclass}
The default storage class is ibmc-file-gold. You can change the default storage class that a persistent volume (PV) uses if no storage class is specified in the persistent volume claim (PVC). You can have only one default storage class.
{: shortdesc}
- Log in to your account. If applicable, target the appropriate resource group. Set the context for your cluster.
- List available storage classes. Note the name of the storage class that you want to make the default, and the current default storage class that has
(default)in the Name.{: pre}kubectl get storageclasses - Create a default storage class, replacing
<storageclass>with the storage class that you want to use.{: pre}kubectl patch storageclass <storageclass> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' - Remove the previous default storage class.
{: pre}
kubectl patch storageclass <previous_default_storageclass> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' - Verify that the default storage class is set.
{: pre}
kubectl get storageclasses | grep "(default)"