From f68ca037a8f291dff191d7b4905c295dad9fd679 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Wed, 18 Jul 2018 18:39:03 -0700 Subject: [PATCH 01/10] adding skeleton --- .../v2.x/en/kubernetes-in-rancher/_index.md | 30 +++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index 7c86eae8388..812e75542b3 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -7,6 +7,36 @@ aliases: - /rancher/v2.x/en/concepts/resources/ --- +After you provision a Kubernetes (K8s) cluster in Rancher, you can begin using powerful K8s features from the Rancher UI to manage the cluster, allowing you to deploy and scale your containerized applications in development, testing, or production environments. + +## Advanced Cluster Interaction + +## Node Management + +## Projects and Namespaces + +Rancher extends the application of the Kubernetes namespace resources listed above to [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-namespaces/), which are Rancher-specific constructs. In the hierarchy of Rancher objects, projects contain namespaces. Therefore, any resources available within a project are available for all namespaces within that project. + + +## Workloads + +## Load Balancing and Ingress + +## Service Discovery + +## Volumes and Storage + +## Kubernetes Resources + +## Cluster Resources + + - node management + - storage + - load balancing + - service discovery + - volumes + + Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within this scope, resources include: From d02115f14aceb7997a6f42c2c4b539847b793c5e Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 19 Jul 2018 15:33:02 -0700 Subject: [PATCH 02/10] added high level for CLI, Node management, and Projects and Namespaces --- .../v2.x/en/kubernetes-in-rancher/_index.md | 71 ++++++++++++++++++- .../projects-and-namespaces/_index.md | 2 + 2 files changed, 72 insertions(+), 1 deletion(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index 812e75542b3..b701634ee32 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -9,14 +9,83 @@ aliases: After you provision a Kubernetes (K8s) cluster in Rancher, you can begin using powerful K8s features from the Rancher UI to manage the cluster, allowing you to deploy and scale your containerized applications in development, testing, or production environments. +Do Lorem ut et quis laboris dolore enim ad voluptate. Veniam reprehenderit mollit id anim in labore ipsum voluptate anim ut nostrud. Nulla laborum voluptate culpa veniam ullamco ad laboris enim. Sint qui proident laboris aliquip veniam in enim reprehenderit officia nostrud pariatur pariatur. + +Magna est sint irure adipisicing dolor. Pariatur duis sunt commodo esse ex do deserunt. Et adipisicing velit mollit nisi do commodo. Velit do anim aliqua consectetur. + +Occaecat esse amet nulla cupidatat Lorem velit. Quis eu ex dolor pariatur id sit aliqua. Ex enim elit voluptate sint deserunt proident veniam occaecat occaecat velit exercitation deserunt dolore. + ## Advanced Cluster Interaction +Although the primary method of interacting with your Kubernetes clusters created using Rancher is the Rancher UI, you have additional options for controlling your clusters: + +- **kubectl** + + You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), to control your clusters. You have two options for using kubectl: + + - **Rancher kubectl shell** + + You can interact with your clusters by launching the kubectl shell available in the Rancher UI. This option requires no configuration actions on your part. + + For more information, see [Accessing Clusters with kubectl Shell]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/kubectl/#accessing-clusters-with-kubectl-shell). + + - **Terminal remote connection**: + + You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and then copying your cluster's kubeconfig file from the Rancher UI to your local `~/.kube/config` directory. + + For more information, see [Accessing Clusters with kubectl and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/kubectl/#accessing-clusters-with-kubectl-and-a-kubeconfig-file). + +- **Rancher CLI** + + You can interact with your clusters by downloading Rancher's own command-line interface, [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli/). + +- **Rancher API** + + Finally, you can interact with your clusters over the Rancher API. However, before you use the API, you must obtain an [API key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/) using the Rancher UI. + ## Node Management +After you launch a Rancher cluster, you can edit many of the settings you configured during its initial launch, including: + +- The cluster's [members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#membership-and-role-assignment) and [roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). +- Its [Kubernetes options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/), including: + + - The version of Kubernetes installed. + - Whether the cluster allows unsupported versions of Docker to run. + - Whether the cluster uses a cloud provider. + - Whether the cluster applies a pod security policy. + + >**Note:** You cannot edit the clusters Network Provider after its initial launch. + +- The [node pools]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) configured for the cluster. + +For instructions on how to edit a cluster's settings, see [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters). + +Additionally, you can also edit individual nodes using the **Nodes** tab, from which you can complete the following actions: + +- Enter custom names and descriptions for each node. +- Add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to each node. +- Pause nodes using the **Cordon** button. +- **Delete** nodes. +- Scale the number of nodes in the cluster up or down. +- Download the access keys for each node. + ## Projects and Namespaces -Rancher extends the application of the Kubernetes namespace resources listed above to [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-namespaces/), which are Rancher-specific constructs. In the hierarchy of Rancher objects, projects contain namespaces. Therefore, any resources available within a project are available for all namespaces within that project. +In use cases where many users share use of a cluster, you can divide it into different [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) and [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) to prevent conflicts. +- [Namespaces]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/#namespaces) + + Namespaces are objects you can use to restrict cluster resources among groups of users and applications. Using namesspaces, you can limit the cluster objects that users can access, including: + + - **[Workloads](#workloads)**: standard workloads, load balancers, service discovery records, and storage. + - **[Resources](#kubernetes-resources)**: certificates, ConfigMaps, registries, and secrets. + +- [Projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) + + Projects are a feature available in Rancher, but not the base version of Kubernetes. Projects allows you to group different namespaces a single object. You can then use your project to set user access and pod security policies using a single object (the project) rather than many (namespaces). + + You can also assign the workloads and resources mentioned above to a project. Therefore, any resources available within a project are available for all namespaces within that project. ## Workloads diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/_index.md index 316621fed6e..a04ea3c5612 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/_index.md @@ -7,6 +7,8 @@ aliases: - /rancher/v2.x/en/tasks/projects/create-project/ --- +## Projects + _Projects_ are a new concept introduced by Rancher. They are not a native Kubernetes construct. A project captures a set of policies for a set of namespaces. A user can be assigned a specific role in a project. A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/). Policies include Kubernetes Role-Based Access Control (RBAC) policies and pod security policies. Rancher 2.0 also implements a canned network policy that isolates containers in different projects. Future versions of Rancher will implement more flexible network policies. ## Authorization From 0371e29d811ba85662d956c297acc52559cb50e9 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 19 Jul 2018 16:13:31 -0700 Subject: [PATCH 03/10] workloads high level --- .../v2.x/en/kubernetes-in-rancher/_index.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index b701634ee32..fd986539173 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -87,8 +87,23 @@ In use cases where many users share use of a cluster, you can divide it into dif You can also assign the workloads and resources mentioned above to a project. Therefore, any resources available within a project are available for all namespaces within that project. +For more information on creating project and attaching objects and membership to them, see: + +- [Projects and Namespaces]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) +- [Project Members]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/project-members/) + ## Workloads +Deploy applications to your cluster nodes using [workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/), which are objects that contain pods that run your apps, along with metadata that set rules for the deployment's behavior. Workloads can deployed within the scope of the entire clusters, or within a namespace. + +When deploying a workload, you can deploy any application hosted on [Docker Hub](https://hub.docker.com/). There are variety of [workload types]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/#workload-types) to choose from. + +Following a workload deployment, you can continue working with it. You can: + + - [Upgrade]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/upgrade-workloads) the workload to a newer version of the application it's running. + - [Roll back]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/rollback-workloads) a workload, if an issue occurs during upgrade. + - [Add a sidecar]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/add-a-sidecar), which is a workload that supports a primary workload. + ## Load Balancing and Ingress ## Service Discovery From 0336ee35b6fd401cb8fb6338f8a58b52f8343584 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 19 Jul 2018 16:24:10 -0700 Subject: [PATCH 04/10] kub resouces high level --- .../v2.x/en/kubernetes-in-rancher/_index.md | 22 +++++++++---------- 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index fd986539173..913f42d9e40 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -112,6 +112,16 @@ Following a workload deployment, you can continue working with it. You can: ## Kubernetes Resources +Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within Kubernetes, certificates, registries, and secrets are all considered [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, these resources must have unique names to avoid conflicts. Although secrets are primarily used to carry sensitive information, they have other uses as well. + +Resources include: + +- [Certificates]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/certificates/): files used to encrypt/decrypt data entering or leaving the cluster. +- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/configmaps/): files that store general configuration information, such as a group of config files. +- [Secrets]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/): files that store sensitive data like passwords, tokens, or keys +- [Registries]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/registries/): files that carry credentials used to authenticate with private registries. + + ## Cluster Resources - node management @@ -121,15 +131,3 @@ Following a workload deployment, you can continue working with it. You can: - volumes - - -Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within this scope, resources include: - -- [Certificates]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/certificates/) -- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/configmaps/) -- [Secrets]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/) -- [Registries]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/registries/) - -Rancher extends the application of the Kubernetes namespace resources listed above to [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/), which are Rancher-specific constructs. In the hierarchy of Rancher objects, projects contain namespaces. Therefore, any resources available within a project are available for all namespaces within that project. - -Within Kubernetes, certificates, registries, and secrets are all considered [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, these resources must have unique names to avoid conflicts. Although secrets are primarily used to carry sensitive information, they have other uses as well. From 6f6019d17841584cb68a42498a4980fdcdfa8c2e Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 19 Jul 2018 16:45:30 -0700 Subject: [PATCH 05/10] high level volumes and storage --- .../v2.x/en/kubernetes-in-rancher/_index.md | 22 +++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index 913f42d9e40..dfd06109699 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -110,16 +110,30 @@ Following a workload deployment, you can continue working with it. You can: ## Volumes and Storage +For workloads that need to retain their state, you must add storage to the workload. Storage volumes are locations outside your of your pods where applications can store their data. Because the storage is external to the workload, if a container fails, the container that replaces it can restore the external data, making recovery appear seamless. + +Within Rancher, you can create persistent storage using one of two methods: + +- [Persistent Volumes]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#persistent-volumes) + + Persistent volumes are pre-provisioned storage volumes that you can bind to pods later using Persistent Volume Claims. + +- [Storage Classes]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#storage-classes) + + Storage classes are objects that provision storage volumes upon request. When a pod submits a Persistent Volume Claim to the storage class, the class creates a storage volume for the pod. + +After you deploy a workload, they request storage using a [Persistent Volume Claim]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/persistent-volume-claims), which is like a voucher used to claim storage space available within the cluster. + ## Kubernetes Resources Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within Kubernetes, certificates, registries, and secrets are all considered [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, these resources must have unique names to avoid conflicts. Although secrets are primarily used to carry sensitive information, they have other uses as well. Resources include: -- [Certificates]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/certificates/): files used to encrypt/decrypt data entering or leaving the cluster. -- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/configmaps/): files that store general configuration information, such as a group of config files. -- [Secrets]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/): files that store sensitive data like passwords, tokens, or keys -- [Registries]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/registries/): files that carry credentials used to authenticate with private registries. +- [Certificates]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/certificates/): Files used to encrypt/decrypt data entering or leaving the cluster. +- [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/configmaps/): Files that store general configuration information, such as a group of config files. +- [Secrets]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/): Files that store sensitive data like passwords, tokens, or keys +- [Registries]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/registries/): Files that carry credentials used to authenticate with private registries. ## Cluster Resources From 90644883685c5de124d905cc6035e9acefdd5fd3 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 19 Jul 2018 17:33:51 -0700 Subject: [PATCH 06/10] high leve load balancer and ingress descriptions --- .../v2.x/en/kubernetes-in-rancher/_index.md | 35 +++++++++++++------ 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index dfd06109699..beffbfbb447 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -9,12 +9,6 @@ aliases: After you provision a Kubernetes (K8s) cluster in Rancher, you can begin using powerful K8s features from the Rancher UI to manage the cluster, allowing you to deploy and scale your containerized applications in development, testing, or production environments. -Do Lorem ut et quis laboris dolore enim ad voluptate. Veniam reprehenderit mollit id anim in labore ipsum voluptate anim ut nostrud. Nulla laborum voluptate culpa veniam ullamco ad laboris enim. Sint qui proident laboris aliquip veniam in enim reprehenderit officia nostrud pariatur pariatur. - -Magna est sint irure adipisicing dolor. Pariatur duis sunt commodo esse ex do deserunt. Et adipisicing velit mollit nisi do commodo. Velit do anim aliqua consectetur. - -Occaecat esse amet nulla cupidatat Lorem velit. Quis eu ex dolor pariatur id sit aliqua. Ex enim elit voluptate sint deserunt proident veniam occaecat occaecat velit exercitation deserunt dolore. - ## Advanced Cluster Interaction Although the primary method of interacting with your Kubernetes clusters created using Rancher is the Rancher UI, you have additional options for controlling your clusters: @@ -100,17 +94,38 @@ When deploying a workload, you can deploy any application hosted on [Docker Hub] Following a workload deployment, you can continue working with it. You can: - - [Upgrade]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/upgrade-workloads) the workload to a newer version of the application it's running. - - [Roll back]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/rollback-workloads) a workload, if an issue occurs during upgrade. - - [Add a sidecar]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/add-a-sidecar), which is a workload that supports a primary workload. +- [Upgrade]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/upgrade-workloads) the workload to a newer version of the application it's running. +- [Roll back]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/rollback-workloads) a workload, if an issue occurs during upgrade. +- [Add a sidecar]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/add-a-sidecar), which is a workload that supports a primary workload. ## Load Balancing and Ingress +### Load Balancers + +After you launch an application, the app is only available within the cluster. It can't be reached from outside the cluster. + +If you want your applications to be externally accessible, you must add a load balancer to your cluster. Load balancers create a gateway for external connections to access your cluster, provided that the user knows the load balancer's IP address and the application's port number. + +Rancher supports two types of load balancers: + +- [Layer-4 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#layer-4-load-balancer) +- [Layer-7 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#layer-7-load-balancer) + +For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers). + +#### Ingress + +Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. + +To address this issue, you can set up an Ingress. Ingress is a controller that sits behind a load balancer. When the load balancer receives a request for one of the services running in your cluster, the load balancer passes it to your Ingress. Ingress then routes the request to the correct service based on service subdomains or path rules that you've configured. + +For more information, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress). + ## Service Discovery ## Volumes and Storage -For workloads that need to retain their state, you must add storage to the workload. Storage volumes are locations outside your of your pods where applications can store their data. Because the storage is external to the workload, if a container fails, the container that replaces it can restore the external data, making recovery appear seamless. +For workloads that need to retain their state, you must add external storage for the workload. Storage volumes are locations outside your of your pods where applications can store their data. Because the storage is external to the workload, if a container fails, the container that replaces it can restore the external data, making recovery appear seamless. Within Rancher, you can create persistent storage using one of two methods: From df85b7711b63e7dbcdea0351a74111d34d6ed633 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 19 Jul 2018 17:46:35 -0700 Subject: [PATCH 07/10] service discovery high level --- content/rancher/v2.x/en/kubernetes-in-rancher/_index.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index beffbfbb447..b65195b808e 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -123,6 +123,10 @@ For more information, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-i ## Service Discovery +After you expose your cluster to external requests using a load balancer and/or ingress, it's only available by IP address. To create a resolveable hostname, you must create a Service Record, which is record that maps a IP address, external hostname, DNS record alias, workloads, or labled pods to a specific hostname. + +For more information, see [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/service-discovery). + ## Volumes and Storage For workloads that need to retain their state, you must add external storage for the workload. Storage volumes are locations outside your of your pods where applications can store their data. Because the storage is external to the workload, if a container fails, the container that replaces it can restore the external data, making recovery appear seamless. From 342bfbb1d382bf98372e7c91a8ec050e55cce254 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 19 Jul 2018 18:07:00 -0700 Subject: [PATCH 08/10] cleaned up typos --- .../v2.x/en/kubernetes-in-rancher/_index.md | 37 +++++++------------ 1 file changed, 13 insertions(+), 24 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index b65195b808e..a17caab83f8 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -7,11 +7,11 @@ aliases: - /rancher/v2.x/en/concepts/resources/ --- -After you provision a Kubernetes (K8s) cluster in Rancher, you can begin using powerful K8s features from the Rancher UI to manage the cluster, allowing you to deploy and scale your containerized applications in development, testing, or production environments. +After you provision a Kubernetes cluster in Rancher, you can begin using powerful Kubernetes features from the Rancher UI to manage the cluster, allowing you to deploy and scale your containerized applications in development, testing, or production environments. ## Advanced Cluster Interaction -Although the primary method of interacting with your Kubernetes clusters created using Rancher is the Rancher UI, you have additional options for controlling your clusters: +Although the primary method of interacting with your Kubernetes clusters is the Rancher UI, you have additional options for controlling your clusters: - **kubectl** @@ -23,7 +23,7 @@ Although the primary method of interacting with your Kubernetes clusters created For more information, see [Accessing Clusters with kubectl Shell]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/kubectl/#accessing-clusters-with-kubectl-shell). - - **Terminal remote connection**: + - **Terminal remote connection** You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and then copying your cluster's kubeconfig file from the Rancher UI to your local `~/.kube/config` directory. @@ -39,9 +39,9 @@ Although the primary method of interacting with your Kubernetes clusters created ## Node Management -After you launch a Rancher cluster, you can edit many of the settings you configured during its initial launch, including: +After you launch a cluster, you can edit many of the settings you configured during its initial launch, including: -- The cluster's [members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#membership-and-role-assignment) and [roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). +- The users that can access the cluster, using [members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#membership-and-role-assignment) and [roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). - Its [Kubernetes options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/), including: - The version of Kubernetes installed. @@ -49,7 +49,7 @@ After you launch a Rancher cluster, you can edit many of the settings you config - Whether the cluster uses a cloud provider. - Whether the cluster applies a pod security policy. - >**Note:** You cannot edit the clusters Network Provider after its initial launch. + >**Note:** You cannot edit the cluster's Network Provider after its initial launch. - The [node pools]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) configured for the cluster. @@ -77,11 +77,11 @@ In use cases where many users share use of a cluster, you can divide it into dif - [Projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) - Projects are a feature available in Rancher, but not the base version of Kubernetes. Projects allows you to group different namespaces a single object. You can then use your project to set user access and pod security policies using a single object (the project) rather than many (namespaces). + Projects are a feature available in Rancher, but not the base version of Kubernetes. Projects allows you to group different namespaces into a single object. You can then use your project to set user access and pod security policies using a single object (the project) rather than many (namespaces). You can also assign the workloads and resources mentioned above to a project. Therefore, any resources available within a project are available for all namespaces within that project. -For more information on creating project and attaching objects and membership to them, see: +For more information on creating projects and attaching objects and membership to them, see: - [Projects and Namespaces]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) - [Project Members]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/project-members/) @@ -95,7 +95,7 @@ When deploying a workload, you can deploy any application hosted on [Docker Hub] Following a workload deployment, you can continue working with it. You can: - [Upgrade]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/upgrade-workloads) the workload to a newer version of the application it's running. -- [Roll back]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/rollback-workloads) a workload, if an issue occurs during upgrade. +- [Roll back]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/rollback-workloads) a workload to a previous version, if an issue occurs during upgrade. - [Add a sidecar]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/add-a-sidecar), which is a workload that supports a primary workload. ## Load Balancing and Ingress @@ -117,13 +117,13 @@ For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/kuber Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. -To address this issue, you can set up an Ingress. Ingress is a controller that sits behind a load balancer. When the load balancer receives a request for one of the services running in your cluster, the load balancer passes it to your Ingress. Ingress then routes the request to the correct service based on service subdomains or path rules that you've configured. +To address this issue, you can set up an ingress. Ingress is a controller that sits behind a load balancer. When the load balancer receives a request for one of the services running in your cluster, the load balancer passes it to your Ingress. Ingress then routes the request to the correct service based on service subdomains or path rules that you've configured. For more information, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress). ## Service Discovery -After you expose your cluster to external requests using a load balancer and/or ingress, it's only available by IP address. To create a resolveable hostname, you must create a Service Record, which is record that maps a IP address, external hostname, DNS record alias, workloads, or labled pods to a specific hostname. +After you expose your cluster to external requests using a load balancer and/or ingress, it's only available by IP address. To create a resolveable hostname, you must create a service record, which is a record that maps an IP address, external hostname, DNS record alias, workload(s), or labled pods to a specific hostname. For more information, see [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/service-discovery). @@ -145,22 +145,11 @@ After you deploy a workload, they request storage using a [Persistent Volume Cla ## Kubernetes Resources -Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within Kubernetes, certificates, registries, and secrets are all considered [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, these resources must have unique names to avoid conflicts. Although secrets are primarily used to carry sensitive information, they have other uses as well. +Within the context of a Rancher project or namespace, _resources_ are files and data that support operation of your pods. Within Rancher, certificates, registries, and secrets are all considered resources. However Kubernetes considers resources as different types of [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). Therefore, within a single project or namespace, individual resources must have unique names to avoid conflicts. Although resources are primarily used to carry sensitive information, they have other uses as well. Resources include: - [Certificates]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/certificates/): Files used to encrypt/decrypt data entering or leaving the cluster. - [ConfigMaps]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/configmaps/): Files that store general configuration information, such as a group of config files. -- [Secrets]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/): Files that store sensitive data like passwords, tokens, or keys +- [Secrets]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/secrets/): Files that store sensitive data like passwords, tokens, or keys. - [Registries]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/registries/): Files that carry credentials used to authenticate with private registries. - - -## Cluster Resources - - - node management - - storage - - load balancing - - service discovery - - volumes - - From 93adecce187e2bf8f5bacac6e7bc73fc7c960b09 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Fri, 20 Jul 2018 14:56:56 -0700 Subject: [PATCH 09/10] updating ingress description --- content/rancher/v2.x/en/kubernetes-in-rancher/_index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index a17caab83f8..47e0f765eae 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -115,9 +115,9 @@ For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/kuber #### Ingress -Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. +Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. You can get around this issue using an ingress. -To address this issue, you can set up an ingress. Ingress is a controller that sits behind a load balancer. When the load balancer receives a request for one of the services running in your cluster, the load balancer passes it to your Ingress. Ingress then routes the request to the correct service based on service subdomains or path rules that you've configured. +Ingress is a set or rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the ingress to direct the request to the correct service based on service subdomains or path rules that you've configured. For more information, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress). From 7163dfb632f54ef22f40fe5eb649c69abc61a843 Mon Sep 17 00:00:00 2001 From: Denise Date: Fri, 20 Jul 2018 20:44:35 -0700 Subject: [PATCH 10/10] Update _index.md --- .../v2.x/en/kubernetes-in-rancher/_index.md | 86 ++++++++----------- 1 file changed, 37 insertions(+), 49 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md index 47e0f765eae..cb07ca2171d 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/_index.md @@ -7,81 +7,69 @@ aliases: - /rancher/v2.x/en/concepts/resources/ --- -After you provision a Kubernetes cluster in Rancher, you can begin using powerful Kubernetes features from the Rancher UI to manage the cluster, allowing you to deploy and scale your containerized applications in development, testing, or production environments. +After you provision a Kubernetes cluster in Rancher, you can begin using powerful Kubernetes features from the Rancher to manage the cluster, allowing you to deploy and scale your containerized applications in development, testing, or production environments. -## Advanced Cluster Interaction +## Interacting with Clusters -Although the primary method of interacting with your Kubernetes clusters is the Rancher UI, you have additional options for controlling your clusters: +- **Rancher UI** + +Rancher provides an intuitive user interface to allow you to interact with your Kubernetes clusters. All options that are provided in the UI are using the Rancher API, so anything that can be done in the UI is possible to do using the Rancher CLI or Rancher API. - **kubectl** - You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), to control your clusters. You have two options for using kubectl: + You can use the Kubernetes command-line tool, [kubectl](https://kubernetes.io/docs/reference/kubectl/overview/), to manage your clusters. You have two options for using kubectl: - **Rancher kubectl shell** - You can interact with your clusters by launching the kubectl shell available in the Rancher UI. This option requires no configuration actions on your part. + You can interact with your clusters by launching a kubectl shell available in the Rancher UI. This option requires no configuration actions on your part. For more information, see [Accessing Clusters with kubectl Shell]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/kubectl/#accessing-clusters-with-kubectl-shell). - **Terminal remote connection** - You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and then copying your cluster's kubeconfig file from the Rancher UI to your local `~/.kube/config` directory. + You can also interact with your clusters by installing [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) on to your local desktop and then copying the cluster's kubeconfig file to your local `~/.kube/config` directory. For more information, see [Accessing Clusters with kubectl and a kubeconfig File]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/kubectl/#accessing-clusters-with-kubectl-and-a-kubeconfig-file). - **Rancher CLI** - You can interact with your clusters by downloading Rancher's own command-line interface, [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli/). + You can interact with your clusters by downloading Rancher's own command-line interface, [Rancher CLI]({{< baseurl >}}/rancher/v2.x/en/cli/). Rancher's CLI tool has the ability to interact directly with different clusters and projects as well as run `kubectl` commands on these clusters. - **Rancher API** - Finally, you can interact with your clusters over the Rancher API. However, before you use the API, you must obtain an [API key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/) using the Rancher UI. + Finally, you can interact with your clusters over the Rancher API. However, before you use the API, you must obtain an [API key]({{< baseurl >}}/rancher/v2.x/en/user-settings/api-keys/) using the Rancher UI. In order to view the different resource fields and actions of an API object, you can find these parameters in the API UI, which can be found by clicking on **View in API** on any object within Rancher's UI. -## Node Management +## Editing Clusters -After you launch a cluster, you can edit many of the settings you configured during its initial launch, including: +After you launch a cluster, you can edit many of the settings you configured during its initial launch. For any type of cluster, you can edit the cluster membership. The cluster membership includes the users that can access the cluster as well as their roles within the cluster, using [members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#membership-and-role-assignment) and [roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). -- The users that can access the cluster, using [members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#membership-and-role-assignment) and [roles]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). -- Its [Kubernetes options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/), including: +Depending on how you provisioned your clusters, you have different options available for editing your cluster size and options of your cluster. - - The version of Kubernetes installed. - - Whether the cluster allows unsupported versions of Docker to run. - - Whether the cluster uses a cloud provider. - - Whether the cluster applies a pod security policy. +- For clusters provisioned in a [hosted kubernetes provider]({{< baseurl>}}/rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/), you can edit the options that were made available during cluster provisioning. These options are dependent on your hosted kubernetes provider. + +- For any clusters where [Rancher Launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/),there are many options that you can edit. - >**Note:** You cannot edit the cluster's Network Provider after its initial launch. + - [Kubernetes options]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/options/), including: + + - The version of Kubernetes installed. + - Whether the cluster allows unsupported versions of Docker to run. + - Whether the cluster uses a cloud provider. + - Whether the cluster applies a pod security policy. -- The [node pools]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) configured for the cluster. + >**Note:** You cannot edit the cluster's network provider after its initial launch. + + - The scale and [roles of your nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) can be updated based on if you launched [node pools]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/#node-pools) or have [custom nodes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/custom-nodes/). + + - For node pools, you can add/remove/edit node pools to the cluster. Remember that node pools are set to a specific scale, so removing nodes individually will not cause any changes to the size of the cluster unless you actually change the scale of the node pool. + - For custom nodes, you are provided the Docker command to add nodes or it can be used to edit the roles of existing nodes. If you want to remove nodes, you would need to go to the **Nodes** page of the cluster and delete the nodes you want to remove. -For instructions on how to edit a cluster's settings, see [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters). - -Additionally, you can also edit individual nodes using the **Nodes** tab, from which you can complete the following actions: - -- Enter custom names and descriptions for each node. -- Add [labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) to each node. -- Pause nodes using the **Cordon** button. -- **Delete** nodes. -- Scale the number of nodes in the cluster up or down. -- Download the access keys for each node. +To see what is available to edit your cluster's settings, see [Editing Clusters]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/editing-clusters). ## Projects and Namespaces -In use cases where many users share use of a cluster, you can divide it into different [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) and [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) to prevent conflicts. +In order to support multi-tenancy on a cluster, Rancher [projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) can be created, which allow you to group several [namespaces]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/#namespaces) into a single object. You can set user access and pod security policies to each project, which allows groups of users to access different sets of namespaces while using the same cluster. Projects are a feature available in Rancher, but not the base version of Kubernetes. -- [Namespaces]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/#namespaces) - - Namespaces are objects you can use to restrict cluster resources among groups of users and applications. Using namesspaces, you can limit the cluster objects that users can access, including: - - - **[Workloads](#workloads)**: standard workloads, load balancers, service discovery records, and storage. - - **[Resources](#kubernetes-resources)**: certificates, ConfigMaps, registries, and secrets. - -- [Projects]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) - - Projects are a feature available in Rancher, but not the base version of Kubernetes. Projects allows you to group different namespaces into a single object. You can then use your project to set user access and pod security policies using a single object (the project) rather than many (namespaces). - - You can also assign the workloads and resources mentioned above to a project. Therefore, any resources available within a project are available for all namespaces within that project. - -For more information on creating projects and attaching objects and membership to them, see: +For more information on how to manage projects, see: - [Projects and Namespaces]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/) - [Project Members]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/projects-and-namespaces/project-members/) @@ -90,7 +78,7 @@ For more information on creating projects and attaching objects and membership t Deploy applications to your cluster nodes using [workloads]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/), which are objects that contain pods that run your apps, along with metadata that set rules for the deployment's behavior. Workloads can deployed within the scope of the entire clusters, or within a namespace. -When deploying a workload, you can deploy any application hosted on [Docker Hub](https://hub.docker.com/). There are variety of [workload types]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/#workload-types) to choose from. +When deploying a workload, you can deploy from any image. There are variety of [workload types]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/workloads/#workload-types) to choose from to determine how your application should run. Following a workload deployment, you can continue working with it. You can: @@ -117,7 +105,7 @@ For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/kuber Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. You can get around this issue using an ingress. -Ingress is a set or rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the ingress to direct the request to the correct service based on service subdomains or path rules that you've configured. +Ingress is a set or rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the load balancer to direct the request to the correct service based on service subdomains or path rules that you've configured. For more information, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress). @@ -129,19 +117,19 @@ For more information, see [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/ku ## Volumes and Storage -For workloads that need to retain their state, you must add external storage for the workload. Storage volumes are locations outside your of your pods where applications can store their data. Because the storage is external to the workload, if a container fails, the container that replaces it can restore the external data, making recovery appear seamless. +For workloads that need to retain their state, you must add external storage for the workload. Storage volumes are locations outside of your pods where applications can store their data. Because the storage is external to the workload, if a container fails, the container that replaces it can restore the external data, making recovery appear seamless. Within Rancher, you can create persistent storage using one of two methods: - [Persistent Volumes]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#persistent-volumes) - Persistent volumes are pre-provisioned storage volumes that you can bind to pods later using Persistent Volume Claims. + Persistent volumes are pre-provisioned storage volumes that you can bind to pods later using persistent volume claims. - [Storage Classes]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/#storage-classes) - Storage classes are objects that provision storage volumes upon request. When a pod submits a Persistent Volume Claim to the storage class, the class creates a storage volume for the pod. + Storage classes are objects that provision storage volumes upon request. When a pod submits a persistent volume claim to the storage class, the class creates a storage volume for the pod. -After you deploy a workload, they request storage using a [Persistent Volume Claim]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/persistent-volume-claims), which is like a voucher used to claim storage space available within the cluster. +After you deploy a workload, they request storage using a [persistent volume claim]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/volumes-and-storage/persistent-volume-claims), which is like a voucher used to claim storage space available within the cluster. ## Kubernetes Resources