diff --git a/content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md b/content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md index cb74a60097a..d8bc7910d9c 100644 --- a/content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md +++ b/content/rancher/v2.x/en/backups/backups/single-node-backups/_index.md @@ -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- \ /backup/rancher-data-backup-.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 `` 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 `` with the ID of your Rancher container. ``` # Restart Rancher server diff --git a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md index bc8eeb1b7d5..95b0d30042f 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/examples/vsphere/_index.md @@ -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 //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 /`. 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 //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 /`. 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