public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-28 05:59:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

vsphere formatting updates

Browse Source
This commit is contained in:
Denise Schannon
2018-07-27 10:20:57 -07:00
parent 5c0311d0f2
commit b11d677b37
1 changed files with 10 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md
+10 -10
View File
@@ -7,7 +7,7 @@ aliases:
>**Prerequisites:** >**Prerequisites:**
> >
>- Provisioning vSphere volumes requires the corresponding cloud provider to be enabled in the cluster, see [vSphere Cloud Provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere). >- Provisioning vSphere volumes requires the corresponding cloud provider to be enabled in the cluster, if you are having [Rancher provision Kubernetes for your cluster]({{< baseurl>}}/cluster-provisioning/rke-clusters/), please make sure to set the [cluster options]({{< baseurl >}}/http://localhost:9001/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/) with the [vSphere cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere).
The recommended approach for providing vSphere storage to stateful workloads is creating a vSphereVolume [storage class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes). This allows for dynamic provisioning of vSphere storage when workloads request volumes trough a [persistent volume claim]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/). The recommended approach for providing vSphere storage to stateful workloads is creating a vSphereVolume [storage class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes). This allows for dynamic provisioning of vSphere storage when workloads request volumes trough a [persistent volume claim]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/).
@@ -19,9 +19,9 @@ Let's walk through the steps of creating the storage class and then deploy a sta
> >
> These steps can also be performed using the `kubectl` command line tool. See [Kubernetes documentation on persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) for details. > These steps can also be performed using the `kubectl` command line tool. See [Kubernetes documentation on persistent volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) for details.
### 1. Create Storage Class ### Create A Storage Class
Storage classes for vSphereVolumes may be created with a number of different properties. Refer to the [available options](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/storageclass.htm). Storage classes for vSphereVolumes may be created with a number of different properties. Refer to the [vSphere documentation](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/storageclass.htm) for the available options.
1. Navigate to **Storage** > **Storage Classes** while on the cluster level in the Rancher UI. 1. Navigate to **Storage** > **Storage Classes** while on the cluster level in the Rancher UI.
2. Click on **Add Class**. 2. Click on **Add Class**.
@@ -31,36 +31,36 @@ Storage classes for vSphereVolumes may be created with a number of different pro
4. Click **Save**. 4. Click **Save**.
### 2. Create a workload with a vSphere volume ### Create a Workload with a vSphere Volume
1. Navigate to a project in your cluster and under **Workloads** click on **Deploy**. 1. Navigate to a project in your cluster and under **Workloads** click on **Deploy**.
2. Under **Workload Type** click **More Options** and select **Stateful set of 1 pod**. 2. Under **Workload Type** click **More Options** and select **Stateful set of 1 pod**.
3. Assing a **Name** and Docker image. 3. Assing a **Name** and Docker image.
4. Expand the **Volumes** section and click **Add Volume**. 4. Expand the **Volumes** section and click **Add Volume**.
5. Choose **Add a new persistent volume (claim)**. This will implicitly create the claim once you deploy the workload. 5. Choose **Add a new persistent volume (claim)**. This will implicitly create the claim once you deploy the workload.
6. Assign a **Name** for the claim, ie. *test-volume* and select the vSphere storage class created in the previous step. 6. Assign a **Name** for the claim, ie. `test-volume` and select the vSphere storage class created in the previous step.
7. Enter the required **Capacity** for the volume. Then click **Define**. 7. Enter the required **Capacity** for the volume. Then click **Define**.
![workload-add-volume]({{< baseurl >}}/img/rancher/workload-add-volume.png) ![workload-add-volume]({{< baseurl >}}/img/rancher/workload-add-volume.png)
8. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. */persistent*. 8. Assign a path in the **Mount Point** field. This is the full path where the volume will be mounted in the container file system, e.g. `/persistent`.
9. Click **Launch** to create the workload. 9. Click **Launch** to create the workload.
### 3. Verify persistence of the volume ### Verify Persistence of the Volume
1. In the context menu for the created workload, click on **Execute Shell**. 1. In the context menu for the created workload, click on **Execute Shell**.
2. Note the directory in the root (in this case */persistent*) where the volume has been mounted to. 2. Note the directory in the root (in this case `/persistent`) where the volume has been mounted to.
3. Create a file in the volume by executing the command `touch /<volumeMountPoint>/data.txt`. 3. Create a file in the volume by executing the command `touch /<volumeMountPoint>/data.txt`.
4. **Close** the shell window. 4. **Close** the shell window.
5. Click on the name of the workload to reveal detail information. 5. Click on the name of the workload to reveal detail information.
6. Open the context menu next to the Pod in the *Running* state. 6. Open the context menu next to the Pod in the *Running* state.
7. Delete the Pod by selecting **Delete** and confirming the prompt. 7. Delete the Pod by selecting **Delete** and confirming the prompt.
8. Observe how Kubernetes takes care of deleting it, then schedules a replacement pod in order to satsify the desired scale of the workload (= 1 replica). 8. Observe how Kubernetes takes care of deleting it, then schedules a replacement pod in order to satsify the desired scale of the workload (= 1 replica).
10. Once the replacement pod is running, open a shell to it. 10. Once the replacement pod is running, click on **Execute Shell** for it.
11. Inspect the content of the directory where the volume is mounted, ie. `ls -l /<volumeMountPoint>`. Note how the `file that was created in the now deleted pod is still present. 11. Inspect the content of the directory where the volume is mounted, ie. `ls -l /<volumeMountPoint>`. Note how the `file that was created in the now deleted pod is still present.
![workload-persistent-data]({{< baseurl >}}/img/rancher/workload-persistent-data.png) ![workload-persistent-data]({{< baseurl >}}/img/rancher/workload-persistent-data.png)
## Why you should use StatefulSets and not Deployments ## Why you should use StatefulSets and not Deployments
Since vSphere volumes are backed by VMDK block storage they only support an [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) of `ReadWriteOnce`, meaning that the volume can only be mounted to a single pod at a time, unless all pods consuming that volume are colocated on the same node. This makes a deployment resource unusable for scaling beyond a single replica if it consumes vSphere volumes. Since vSphere volumes are backed by VMDK block storage they only support an [access mode](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) of `ReadWriteOnce`, meaning that the volume can only be mounted to a single pod at a time, unless all pods consuming that volume are colocated on the same node. This makes a deployment resource unusable for scaling beyond a single replica if it consumes vSphere volumes.