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

edited vsphere readability.

Browse Source
This commit is contained in:
Mark Bishop
2018-07-28 08:27:06 -07:00
committed by Denise
parent 9ea1648d45
commit 54e6b6bc0b
2 changed files with 53 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md
+2 -2
View File
@@ -6,7 +6,7 @@ aliases:
- /rancher/v2.x/en/installation/backups-and-restoration/single-node-backup-and-restoration/
---
After completing your single node installation of Rancher, you can create a backup of your current installation at any time. We recommend making a backup before [upgrading]({{< baseurl>>}}/rancher/v2.x/en/upgrades/single-node-upgrade/). Use this backup as a restoration point in disaster scenarios or when you need to [rollback]({{< baseurl>>}}/rancher/v2.x/en/backups/rollbacks/single-node-rollbacks/) to an older version.
After completing your single node installation of Rancher, you can create a backup of your current installation at any time. We recommend making a backup before [upgrading]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-upgrade/). Use this backup as a restoration point in disaster scenarios or when you need to [rollback]({{< baseurl >}}/rancher/v2.x/en/backups/rollbacks/single-node-rollbacks/) to an older version.
>**Prerequisite:** Open Rancher and write down the version number displayed in the lower-left of the browser (example: `v2.0.0`). You'll need this number during the backup process.
@@ -36,7 +36,7 @@ docker run --volumes-from rancher-data-<RANCHER_VERSION> \
/backup/rancher-data-backup-<RANCHER_VERSION>.tar.gz /var/lib/rancher
```
3. After you've created your backup, you can either restart Rancher server or [upgrade]({{< baseurl>>}}/rancher/v2.x/en/upgrades/single-node-upgrade/). Replace `<RANCHER_CONTAINER_ID>` with the ID of your Rancher container.
3. After you've created your backup, you can either restart Rancher server or [upgrade]({{< baseurl >}}/rancher/v2.x/en/upgrades/single-node-upgrade/). Replace `<RANCHER_CONTAINER_ID>` with the ID of your Rancher container.
```
# Restart Rancher server
content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md
+51 -37
View File
@@ -5,69 +5,83 @@ aliases:
- /rancher/v2.x/en/tasks/clusters/adding-storage/provisioning-storage/vsphere/
---
To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume [storage class]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#storage-classes). This practice dynamically provisions vSphere storage when workloads request volumes through a [persistent volume claim]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/).
>**Prerequisites:**
>
>- 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/).
## Steps
Let's walk through the steps of creating the storage class and then deploy a stateful workload in the Rancher UI.
>If you [provisioned your cluster using RKE]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), its [cluster options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/) must have the [vSphere cloud provider]({{< baseurl >}}/rke/v0.1.x/en/config-options/cloud-providers/vsphere) enabled.
>
> **Note:**
>
> 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.
### Create A Storage Class
### Creating A Storage Class
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.
2. Click on **Add Class**.
3. Assign a **Name** and select **VMWare vSphere Volume** under **Provisioner**.
1. From the Global view, open the cluster where you want to provide vSphere storage.
1. From the main menu, select **Storage > Storage Classes**. Then click **Add Class**.
1. Enter a **Name** for the class.
1. Under **Provisioner**, select **VMWare vSphere Volume**.
![vsphere-storage-class]({{< baseurl >}}/img/rancher/vsphere-storage-class.png)
4. Click **Save**.
### Create a Workload with a vSphere Volume
### Creating a Workload with a vSphere Volume
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**.
3. Assing a **Name** and Docker image.
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.
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**.
1. From the cluster where you configured vSphere storage, begin creating a workload as you would in [Deploying Workloads]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/deploy-workloads/).
1. For **Workload Type**, select **Stateful set of 1 pod**.
1. Expand the **Volumes** section and click **Add Volume**.
1. Choose **Add a new persistent volume (claim)**. This option will implicitly create the claim once you deploy the workload.
1. Assign a **Name** for the claim, ie. `test-volume` and select the vSphere storage class created in the previous step.
1. Enter the required **Capacity** for the volume. Then click **Define**.
![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`.
9. Click **Launch** to create the workload.
1. 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`.
### Verify Persistence of the Volume
1. Click **Launch** to create the workload.
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.
3. Create a file in the volume by executing the command `touch /<volumeMountPoint>/data.txt`.
4. **Close** the shell window.
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.
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).
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.
### Verifing Persistence of the Volume
1. From the context menu of the workload you just created, click **Execute Shell**.
1. Note the directory at root where the volume has been mounted to (in this case `/persistent`).
1. Create a file in the volume by executing the command `touch /<volumeMountPoint>/data.txt`.
1. **Close** the shell window.
1. Click on the name of the workload to reveal detail information.
1. Open the context menu next to the Pod in the *Running* state.
1. Delete the Pod by selecting **Delete**.
1. Observe that the pod is deleted. Then a new pod is scheduled to replace it so that the workload maintains its configured scale of a single stateful pod.
1. Once the replacement pod is running, click **Execute Shell**.
1. Inspect the contents of the directory where the volume is mounted by entering `ls -l /<volumeMountPoint>`. Note that the file you created earlier is still present.
![workload-persistent-data]({{< baseurl >}}/img/rancher/workload-persistent-data.png)
## Why you should use StatefulSets and not Deployments
## Why to Use StatefulSets Instead of 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.
You should always use [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) for workloads consuming vSphere storage, as this resource type is designed to address a VMDK block storage caveat.
Even using a deployment resource with just a single replica may result in a deadlock situation while updating the deployment: If the updated pod is scheduled to a node different from where the existing pod lives, it will fail to start because the VMDK is still attached to the other node.
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`. This setting restricts the volume so that it can only be mounted to a single pod at a time, unless all pods consuming that volume are co-located on the same node. This behavior makes a deployment resource unusable for scaling beyond a single replica if it consumes vSphere volumes.
That being said: You should always use [StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) for workloads consuming vSphere storage as this resource type has been designed to handle the caveats of `ReadWriteOnce` volumes.
Even using a deployment resource with just a single replica may result in a deadlock situation while updating the deployment. If the updated pod is scheduled to a node different from where the existing pod lives, it will fail to start because the VMDK is still attached to the other node.
## Related Links