mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-24 20:18:18 +00:00
Fix links
This commit is contained in:
+1
-1
@@ -73,7 +73,7 @@ We recommend adding PSPs during cluster and project creation instead of adding i
|
||||
|
||||
2. Name the policy.
|
||||
|
||||
3. Complete each section of the form. Refer to the [Kubernetes documentation]((https://kubernetes.io/docs/concepts/policy/pod-security-policy/)) for more information on what each policy does.
|
||||
3. Complete each section of the form. Refer to the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for more information on what each policy does.
|
||||
|
||||
|
||||
# Configuration
|
||||
|
||||
+1
-1
@@ -10,7 +10,7 @@ There are two main ways to set up private registries in Rancher: by setting up t
|
||||
|
||||
This section is about configuring the global default private registry, and focuses on how to configure the registry from the Rancher UI after Rancher is installed.
|
||||
|
||||
For instructions on setting up a private registry with command line options during the installation of Rancher, refer to the [air gapped Docker installation](installation/air-gap-single-node) or [air gapped Kubernetes installation](installation/air-gap-high-availability) instructions.
|
||||
For instructions on setting up a private registry with command line options during the installation of Rancher, refer to the [air gapped Docker installation](../../../pages-for-subheaders/air-gap-helm2.md) or [air gapped Kubernetes installation](../../../pages-for-subheaders/air-gap-helm2.md) instructions.
|
||||
|
||||
If your private registry requires credentials, it cannot be used as the default registry. There is no global way to set up a private registry with authorization for every Rancher-provisioned cluster. Therefore, if you want a Rancher-provisioned cluster to pull images from a private registry with credentials, you will have to [pass in the registry credentials through the advanced cluster options](#setting-a-private-registry-with-credentials-when-deploying-a-cluster) every time you create a new cluster.
|
||||
|
||||
|
||||
+2
-2
@@ -9,7 +9,7 @@ aliases:
|
||||
|
||||
If you want to provide a user with access and permissions to _all_ projects, nodes, and resources within a cluster, assign the user a cluster membership.
|
||||
|
||||
>**Tip:** Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members](k8s-in-rancher/projects-and-namespaces/project-members/) instead.
|
||||
>**Tip:** Want to provide a user with access to a _specific_ project within a cluster? See [Adding Project Members](../../manage-projects/add-users-to-projects.md) instead.
|
||||
|
||||
There are two contexts where you can add cluster members:
|
||||
|
||||
@@ -42,7 +42,7 @@ Cluster administrators can edit the membership for a cluster, controlling which
|
||||
|
||||
>**Note:** If you are logged in as a local user, external users do not display in your search results. For more information, see [External Authentication Configuration and Principal Users](../../../../pages-for-subheaders/about-authentication.md#external-authentication-configuration-and-principal-users).
|
||||
|
||||
4. Assign the user or group **Cluster** roles.
|
||||
4. Assign the user or group **Cluster** roles.
|
||||
|
||||
[What are Cluster Roles?](../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)
|
||||
|
||||
|
||||
+2
-2
@@ -13,9 +13,9 @@ This kubeconfig file and its contents are specific to the cluster you are viewin
|
||||
|
||||
After you download the kubeconfig file, you will be able to use the kubeconfig file and its Kubernetes [contexts](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration) to access your downstream cluster.
|
||||
|
||||
_Available as of v2.4.6_
|
||||
_Available as of v2.4.6_
|
||||
|
||||
If admins have [enforced TTL on kubeconfig tokens](../../../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens), the kubeconfig file requires [rancher cli](cluster-admin/cluster-access/cli) to be present in your PATH.
|
||||
If admins have [enforced TTL on kubeconfig tokens](../../../../reference-guides/about-the-api/api-tokens.md#setting-ttl-on-kubeconfig-tokens), the kubeconfig file requires [rancher cli](../../../../pages-for-subheaders/cli-with-rancher.md) to be present in your PATH.
|
||||
|
||||
|
||||
### Two Authentication Methods for RKE Clusters
|
||||
|
||||
+4
-4
@@ -27,10 +27,10 @@ When cleaning nodes provisioned using Rancher, the following components are dele
|
||||
| All resources create under the `management.cattle.io` API Group | ✓ | ✓ | ✓ | |
|
||||
| All CRDs created by Rancher v2.x | ✓ | ✓ | ✓ | |
|
||||
|
||||
[1]: cluster-provisioning/rke-clusters/node-pools/
|
||||
[2]: cluster-provisioning/rke-clusters/custom-nodes/
|
||||
[3]: cluster-provisioning/hosted-kubernetes-clusters/
|
||||
[4]: cluster-provisioning/imported-clusters/
|
||||
[1]: ../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md
|
||||
[2]: ../../../pages-for-subheaders/use-existing-nodes.md
|
||||
[3]: ../../../pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers.md
|
||||
[4]: ../../new-user-guides/kubernetes-clusters-in-rancher-setup/import-existing-clusters.md
|
||||
|
||||
## Removing a Node from a Cluster by Rancher UI
|
||||
|
||||
|
||||
+2
-2
@@ -21,7 +21,7 @@ To provision new storage for your workloads, follow these steps:
|
||||
|
||||
- To set up persistent storage, the `Manage Volumes` [role](../../../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#project-role-reference) is required.
|
||||
- If you are provisioning storage for a cluster hosted in the cloud, the storage and cluster hosts must have the same cloud provider.
|
||||
- The cloud provider must be enabled. For details on enabling cloud providers, refer to [this page.](cluster-provisioning/rke-clusters/options/cloud-providers/)
|
||||
- The cloud provider must be enabled. For details on enabling cloud providers, refer to [this page.](../../../../../pages-for-subheaders/set-up-cloud-providers.md)
|
||||
- Make sure your storage provisioner is available to be enabled.
|
||||
|
||||
The following storage provisioners are enabled by default:
|
||||
@@ -38,7 +38,7 @@ Local | `local`
|
||||
Network File System | `nfs`
|
||||
hostPath | `host-path`
|
||||
|
||||
To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.](installation/options/feature-flags/enable-not-default-storage-drivers/)
|
||||
To use a storage provisioner that is not on the above list, you will need to use a [feature flag to enable unsupported storage drivers.](../../../../../getting-started/installation-and-upgrade/advanced-options/enable-experimental-features/unsupported-storage-drivers.md)
|
||||
|
||||
### 1. Add a storage class and configure it to use your storage
|
||||
|
||||
|
||||
+1
-1
@@ -5,7 +5,7 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/tasks/clusters/adding-storage/provisioning-storage/vsphere/
|
||||
---
|
||||
|
||||
To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume StorageClass. This practice dynamically provisions vSphere storage when workloads request volumes through a [persistent volume claim](k8s-in-rancher/volumes-and-storage/persistent-volume-claims/).
|
||||
To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume StorageClass. This practice dynamically provisions vSphere storage when workloads request volumes through a [persistent volume claim](../../../../../pages-for-subheaders/create-kubernetes-persistent-storage.md).
|
||||
|
||||
In order to dynamically provision storage in vSphere, the vSphere provider must be [enabled.](../../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/set-up-cloud-providers/other-cloud-providers/vsphere.md)
|
||||
|
||||
|
||||
+4
-4
@@ -43,10 +43,10 @@ The following table lists which node options are available for each type of clus
|
||||
| [Download Keys](#ssh-into-a-node-hosted-by-an-infrastructure-provider) | ✓ | | | | Download SSH key for in order to SSH into the node. |
|
||||
| [Node Scaling](#scaling-nodes) | ✓ | | | | Scale the number of nodes in the node pool up or down. |
|
||||
|
||||
[1]: cluster-provisioning/rke-clusters/node-pools/
|
||||
[2]: cluster-provisioning/rke-clusters/custom-nodes/
|
||||
[3]: cluster-provisioning/hosted-kubernetes-clusters/
|
||||
[4]: cluster-provisioning/imported-clusters/
|
||||
[1]: ../../../pages-for-subheaders/use-new-nodes-in-an-infra-provider.md
|
||||
[2]: ../../../pages-for-subheaders/use-existing-nodes.md
|
||||
[3]: ../../../pages-for-subheaders/set-up-clusters-from-hosted-kubernetes-providers.md
|
||||
[4]: ../../new-user-guides/kubernetes-clusters-in-rancher-setup/import-existing-clusters.md
|
||||
|
||||
### Nodes Hosted by an Infrastructure Provider
|
||||
|
||||
|
||||
+7
-7
@@ -6,7 +6,7 @@ aliases:
|
||||
- /rancher/v2.0-v2.4/en/concepts/projects/
|
||||
- /rancher/v2.0-v2.4/en/tasks/projects/
|
||||
- /rancher/v2.0-v2.4/en/tasks/projects/create-project/
|
||||
- /rancher/v2.0-v2.4/en/tasks/projects/create-project/
|
||||
- /rancher/v2.0-v2.4/en/tasks/projects/create-project/
|
||||
---
|
||||
|
||||
A namespace is a Kubernetes concept that allows a virtual cluster within a cluster, which is useful for dividing the cluster into separate "virtual clusters" that each have their own access control and resource quotas.
|
||||
@@ -42,7 +42,7 @@ You can assign the following resources directly to namespaces:
|
||||
- [Workloads](../../../pages-for-subheaders/workloads-and-pods.md)
|
||||
- [Load Balancers/Ingress](../../../pages-for-subheaders/load-balancer-and-ingress-controller.md)
|
||||
- [Service Discovery Records](../../new-user-guides/kubernetes-resources-setup/create-services.md)
|
||||
- [Persistent Volume Claims](k8s-in-rancher/volumes-and-storage/persistent-volume-claims/)
|
||||
- [Persistent Volume Claims](../../../pages-for-subheaders/create-kubernetes-persistent-storage.md)
|
||||
- [Certificates](../../new-user-guides/kubernetes-resources-setup/encrypt-http-communication.md)
|
||||
- [ConfigMaps](../../new-user-guides/kubernetes-resources-setup/configmaps.md)
|
||||
- [Registries](../../new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md)
|
||||
@@ -60,7 +60,7 @@ This means that when standard users with project-scoped permissions create a nam
|
||||
|
||||
If your permissions are restricted to the project level, it is better to [create a namespace through Rancher](../manage-projects/manage-namespaces.md) to ensure that you will have permission to access the namespace.
|
||||
|
||||
If a standard user is a project owner, the user will be able to create namespaces within that project. The Rancher UI will prevent that user from creating namespaces outside the scope of the projects they have access to.
|
||||
If a standard user is a project owner, the user will be able to create namespaces within that project. The Rancher UI will prevent that user from creating namespaces outside the scope of the projects they have access to.
|
||||
|
||||
# About Projects
|
||||
|
||||
@@ -75,7 +75,7 @@ In the base version of Kubernetes, features like role-based access rights or clu
|
||||
|
||||
You can use projects to perform actions such as:
|
||||
|
||||
- Assign users to a group of namespaces (i.e., [project membership](k8s-in-rancher/projects-and-namespaces/project-members)).
|
||||
- Assign users to a group of namespaces (i.e., [project membership](../manage-projects/add-users-to-projects.md)).
|
||||
- Assign users specific roles in a project. A role can be owner, member, read-only, or [custom](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/custom-roles.md).
|
||||
- Assign resources to the project.
|
||||
- Assign Pod Security Policies.
|
||||
@@ -163,7 +163,7 @@ By default, your user is added as the project `Owner`.
|
||||
>
|
||||
>- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
|
||||
>
|
||||
>- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
>- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
>
|
||||
>- Choose `Custom` to create a custom role on the fly: [Custom Project Roles](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#custom-project-roles).
|
||||
|
||||
@@ -177,12 +177,12 @@ To add members:
|
||||
|
||||
_Available as of v2.1.0_
|
||||
|
||||
Resource quotas limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas](k8s-in-rancher/projects-and-namespaces/resource-quotas).
|
||||
Resource quotas limit the resources that a project (and its namespaces) can consume. For more information, see [Resource Quotas](../../../pages-for-subheaders/manage-project-resource-quotas.md).
|
||||
|
||||
To add a resource quota,
|
||||
|
||||
1. Click **Add Quota**.
|
||||
1. Select a Resource Type. For more information, see [Resource Quotas.](k8s-in-rancher/projects-and-namespaces/resource-quotas/).
|
||||
1. Select a Resource Type. For more information, see [Resource Quotas.](../../../pages-for-subheaders/manage-project-resource-quotas.md).
|
||||
1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
|
||||
1. **Optional:** Specify **Container Default Resource Limit**, which will be applied to every container started in the project. The parameter is recommended if you have CPU or Memory limits set by the Resource Quota. It can be overridden on per an individual namespace or a container level. For more information, see [Container Default Resource Limit](../../../pages-for-subheaders/manage-project-resource-quotas.md) Note: This option is available as of v2.2.0.
|
||||
1. Click **Create**.
|
||||
|
||||
+1
-1
@@ -109,7 +109,7 @@ If the group of etcd nodes loses quorum, the Kubernetes cluster will report a fa
|
||||
|
||||
5. Run the revised command.
|
||||
|
||||
6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster](../../../pages-for-subheaders/use-existing-nodes.md) and you want to reuse an old node, you are required to [clean up the nodes](faq/cleaning-cluster-nodes/) before attempting to add them back into a cluster.
|
||||
6. After the single nodes is up and running, Rancher recommends adding additional etcd nodes to your cluster. If you have a [custom cluster](../../../pages-for-subheaders/use-existing-nodes.md) and you want to reuse an old node, you are required to [clean up the nodes](./clean-cluster-nodes.md) before attempting to add them back into a cluster.
|
||||
|
||||
# Enabling Snapshot Features for Clusters Created Before Rancher v2.2.0
|
||||
|
||||
|
||||
+5
-5
@@ -10,11 +10,11 @@ If you want to provide a user with access and permissions to _specific_ projects
|
||||
|
||||
You can add members to a project as it is created, or add them to an existing project.
|
||||
|
||||
>**Tip:** Want to provide a user with access to _all_ projects within a cluster? See [Adding Cluster Members](cluster-provisioning/cluster-members/) instead.
|
||||
>**Tip:** Want to provide a user with access to _all_ projects within a cluster? See [Adding Cluster Members](../manage-clusters/access-clusters/add-users-to-clusters.md) instead.
|
||||
|
||||
### Adding Members to a New Project
|
||||
|
||||
You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.](k8s-in-rancher/projects-and-namespaces/)
|
||||
You can add members to a project as you create it (recommended if possible). For details on creating a new project, refer to the [cluster administration section.](../manage-clusters/projects-and-namespaces.md)
|
||||
|
||||
### Adding Members to an Existing Project
|
||||
|
||||
@@ -28,13 +28,13 @@ Following project creation, you can add users as project members so that they ca
|
||||
|
||||
If external authentication is configured:
|
||||
|
||||
- Rancher returns users from your external authentication source as you type.
|
||||
- Rancher returns users from your external authentication source as you type.
|
||||
|
||||
- A drop-down allows you to add groups instead of individual users. The dropdown only lists groups that you, the logged in user, are included in.
|
||||
|
||||
>**Note:** If you are logged in as a local user, external users do not display in your search results.
|
||||
|
||||
1. Assign the user or group **Project** roles.
|
||||
1. Assign the user or group **Project** roles.
|
||||
|
||||
[What are Project Roles?](../authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md)
|
||||
|
||||
@@ -42,7 +42,7 @@ Following project creation, you can add users as project members so that they ca
|
||||
>
|
||||
>- Users assigned the `Owner` or `Member` role for a project automatically inherit the `namespace creation` role. However, this role is a [Kubernetes ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole), meaning its scope extends to all projects in the cluster. Therefore, users explicitly assigned the `Owner` or `Member` role for a project can create namespaces in other projects they're assigned to, even with only the `Read Only` role assigned.
|
||||
>
|
||||
>- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
>- By default, the Rancher role of `project-member` inherits from the `Kubernetes-edit` role, and the `project-owner` role inherits from the `Kubernetes-admin` role. As such, both `project-member` and `project-owner` roles will allow for namespace management, including the ability to create and delete namespaces.
|
||||
>
|
||||
>- For `Custom` roles, you can modify the list of individual roles available for assignment.
|
||||
>
|
||||
|
||||
+2
-2
@@ -14,7 +14,7 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
|
||||
- Build your application from code to image.
|
||||
- Validate your builds.
|
||||
- Deploy your build images to your cluster.
|
||||
- Run unit tests.
|
||||
- Run unit tests.
|
||||
- Run regression tests.
|
||||
|
||||
For details, refer to the [pipelines](k8s-in-rancher/pipelines) section.
|
||||
For details, refer to the [pipelines](../../../pages-for-subheaders/pipelines.md) section.
|
||||
+4
-4
@@ -12,7 +12,7 @@ Resources that you can assign directly to namespaces include:
|
||||
- [Workloads](../../../pages-for-subheaders/workloads-and-pods.md)
|
||||
- [Load Balancers/Ingress](../../../pages-for-subheaders/load-balancer-and-ingress-controller.md)
|
||||
- [Service Discovery Records](../../new-user-guides/kubernetes-resources-setup/create-services.md)
|
||||
- [Persistent Volume Claims](k8s-in-rancher/volumes-and-storage/persistent-volume-claims/)
|
||||
- [Persistent Volume Claims](../../../pages-for-subheaders/provisioning-storage-examples.md)
|
||||
- [Certificates](../../new-user-guides/kubernetes-resources-setup/encrypt-http-communication.md)
|
||||
- [ConfigMaps](../../new-user-guides/kubernetes-resources-setup/configmaps.md)
|
||||
- [Registries](../../new-user-guides/kubernetes-resources-setup/kubernetes-and-docker-registries.md)
|
||||
@@ -35,7 +35,7 @@ Create a new namespace to isolate apps and resources in a project.
|
||||
|
||||
1. From the main menu, select **Namespace**. The click **Add Namespace**.
|
||||
|
||||
1. **Optional:** If your project has [Resource Quotas](k8s-in-rancher/projects-and-namespaces/resource-quotas) in effect, you can override the default resource **Limits** (which places a cap on the resources that the namespace can consume).
|
||||
1. **Optional:** If your project has [Resource Quotas](../../../pages-for-subheaders/manage-project-resource-quotas.md) in effect, you can override the default resource **Limits** (which places a cap on the resources that the namespace can consume).
|
||||
|
||||
1. Enter a **Name** and then click **Create**.
|
||||
|
||||
@@ -54,7 +54,7 @@ Cluster admins and members may occasionally need to move a namespace to another
|
||||
>**Notes:**
|
||||
>
|
||||
>- Don't move the namespaces in the `System` project. Moving these namespaces can adversely affect cluster networking.
|
||||
>- You cannot move a namespace into a project that already has a [resource quota](k8s-in-rancher/projects-and-namespaces/resource-quotas/) configured.
|
||||
>- You cannot move a namespace into a project that already has a [resource quota](../../../pages-for-subheaders/manage-project-resource-quotas.md) configured.
|
||||
>- If you move a namespace from a project that has a quota set to a project with no quota set, the quota is removed from the namespace.
|
||||
|
||||
1. Choose a new project for the new namespace and then click **Move**. Alternatively, you can remove the namespace from all projects by selecting **None**.
|
||||
@@ -65,4 +65,4 @@ Cluster admins and members may occasionally need to move a namespace to another
|
||||
|
||||
You can always override the namespace default limit to provide a specific namespace with access to more (or less) project resources.
|
||||
|
||||
For more information, see how to [edit namespace resource quotas](project-admin//resource-quotas/override-namespace-default/).
|
||||
For more information, see how to [edit namespace resource quotas](./manage-project-resource-quotas/override-default-limit-in-namespaces.md).
|
||||
+4
-4
@@ -5,16 +5,16 @@ weight: 2
|
||||
|
||||
Although the **Namespace Default Limit** propagates from the project to each namespace when created, in some cases, you may need to increase (or decrease) the quotas for a specific namespace. In this situation, you can override the default limits by editing the namespace.
|
||||
|
||||
In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it has more resources available. Therefore, the administrator [raises the namespace limits](k8s-in-rancher/projects-and-namespaces/) for `Namespace 3` so that the namespace can access more resources.
|
||||
In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it has more resources available. Therefore, the administrator [raises the namespace limits](../../manage-clusters/projects-and-namespaces.md) for `Namespace 3` so that the namespace can access more resources.
|
||||
|
||||
<sup>Namespace Default Limit Override</sup>
|
||||

|
||||
|
||||
How to: [Editing Namespace Resource Quotas](k8s-in-rancher/projects-and-namespaces/)
|
||||
How to: [Editing Namespace Resource Quotas](../../manage-clusters/projects-and-namespaces.md)
|
||||
|
||||
### Editing Namespace Resource Quotas
|
||||
|
||||
If there is a [resource quota](k8s-in-rancher/projects-and-namespaces/resource-quotas) configured for a project, you can override the namespace default limit to provide a specific namespace with access to more (or less) project resources.
|
||||
If there is a [resource quota](../../../../pages-for-subheaders/manage-project-resource-quotas.md) configured for a project, you can override the namespace default limit to provide a specific namespace with access to more (or less) project resources.
|
||||
|
||||
1. From the **Global** view, open the cluster that contains the namespace for which you want to edit the resource quota.
|
||||
|
||||
@@ -24,7 +24,7 @@ If there is a [resource quota](k8s-in-rancher/projects-and-namespaces/resource-q
|
||||
|
||||
1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured project limits.
|
||||
|
||||
For more information about each **Resource Type**, see [Resource Quotas](k8s-in-rancher/projects-and-namespaces/resource-quotas/).
|
||||
For more information about each **Resource Type**, see [Resource Quotas](../../../../pages-for-subheaders/manage-project-resource-quotas.md).
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
|
||||
+2
-2
@@ -13,7 +13,7 @@ To avoid setting these limits on each and every container during workload creati
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
Edit [container default resource limit](k8s-in-rancher/projects-and-namespaces/resource-quotas/) when:
|
||||
Edit [container default resource limit](../../../../pages-for-subheaders/manage-project-resource-quotas.md) when:
|
||||
|
||||
- You have a CPU or Memory resource quota set on a project, and want to supply the corresponding default values for a container.
|
||||
- You want to edit the default container resource limit.
|
||||
@@ -27,7 +27,7 @@ Edit [container default resource limit](k8s-in-rancher/projects-and-namespaces/r
|
||||
|
||||
When the default container resource limit is set at a project level, the parameter will be propagated to any namespace created in the project after the limit has been set. For any existing namespace in a project, this limit will not be automatically propagated. You will need to manually set the default container resource limit for any existing namespaces in the project in order for it to be used when creating any containers.
|
||||
|
||||
> **Note:** Before v2.2.0, you could not launch catalog applications that did not have any limits set. With v2.2.0, you can set a default container resource limit on a project and launch any catalog applications.
|
||||
> **Note:** Before v2.2.0, you could not launch catalog applications that did not have any limits set. With v2.2.0, you can set a default container resource limit on a project and launch any catalog applications.
|
||||
|
||||
Once a container default resource limit is configured on a namespace, the default will be pre-populated for any containers created in that namespace. These limits/reservations can always be overridden during workload creation.
|
||||
|
||||
|
||||
+1
-1
@@ -87,4 +87,4 @@ This procedure creates a backup that you can restore if Rancher encounters a dis
|
||||
docker start <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
|
||||
**Result:** A backup tarball of your Rancher Server data is created. See [Restoring Backups: Docker Installs](backups/restorations/single-node-restoration) if you need to restore backup data.
|
||||
**Result:** A backup tarball of your Rancher Server data is created. See [Restoring Backups: Docker Installs](./restore-docker-installed-rancher.md) if you need to restore backup data.
|
||||
|
||||
+3
-3
@@ -41,7 +41,7 @@ You can obtain `<RANCHER_CONTAINER_TAG>` and `<RANCHER_CONTAINER_NAME>` by loggi
|
||||
|
||||
## Restoring Backups
|
||||
|
||||
Using a [backup](backups/backups/single-node-backups/) that you created earlier, restore Rancher to its last known healthy state.
|
||||
Using a [backup](./back-up-docker-installed-rancher.md) that you created earlier, restore Rancher to its last known healthy state.
|
||||
|
||||
1. Using a remote Terminal connection, log into the node running your Rancher Server.
|
||||
|
||||
@@ -50,9 +50,9 @@ Using a [backup](backups/backups/single-node-backups/) that you created earlier,
|
||||
```
|
||||
docker stop <RANCHER_CONTAINER_NAME>
|
||||
```
|
||||
1. Move the backup tarball that you created during completion of [Creating Backups—Docker Installs](backups/backups/single-node-backups/) onto your Rancher Server. Change to the directory that you moved it to. Enter `dir` to confirm that it's there.
|
||||
1. Move the backup tarball that you created during completion of [Creating Backups—Docker Installs](./back-up-docker-installed-rancher.md) onto your Rancher Server. Change to the directory that you moved it to. Enter `dir` to confirm that it's there.
|
||||
|
||||
If you followed the naming convention we suggested in [Creating Backups—Docker Installs](backups/backups/single-node-backups/), it will have a name similar to `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`.
|
||||
If you followed the naming convention we suggested in [Creating Backups—Docker Installs](./back-up-docker-installed-rancher.md), it will have a name similar to `rancher-data-backup-<RANCHER_VERSION>-<DATE>.tar.gz`.
|
||||
|
||||
1. Enter the following command to delete your current state data and replace it with your backup data, replacing the placeholders. Don't forget to close the quotes.
|
||||
|
||||
|
||||
+4
-4
@@ -12,7 +12,7 @@ aliases:
|
||||
- /rancher/v2.x/en/backups/v2.0.x-v2.4.x/restore/rke-restore/
|
||||
---
|
||||
|
||||
This procedure describes how to use RKE to restore a snapshot of the Rancher Kubernetes cluster.
|
||||
This procedure describes how to use RKE to restore a snapshot of the Rancher Kubernetes cluster.
|
||||
This will restore the Kubernetes configuration and the Rancher database and state.
|
||||
|
||||
> **Note:** This document covers clusters set up with RKE >= v0.2.x, for older RKE versions refer to the [RKE Documentation](https://rancher.com/docs/rke/latest/en/etcd-snapshots/restoring-from-backup).
|
||||
@@ -32,9 +32,9 @@ This will restore the Kubernetes configuration and the Rancher database and stat
|
||||
|
||||
It is advised that you run the restore from your local host or a jump box/bastion where your cluster yaml, rke statefile, and kubeconfig are stored. You will need [RKE](https://rancher.com/docs/rke/latest/en/installation/) and [kubectl](../../../faq/install-and-configure-kubectl.md) CLI utilities installed locally.
|
||||
|
||||
Prepare by creating 3 new nodes to be the target for the restored Rancher instance. We recommend that you start with fresh nodes and a clean state. For clarification on the requirements, review the [Installation Requirements](https://rancher.com/docs/rancher/v2.0-v2.4/en/installation/requirements/).
|
||||
Prepare by creating 3 new nodes to be the target for the restored Rancher instance. We recommend that you start with fresh nodes and a clean state. For clarification on the requirements, review the [Installation Requirements](https://rancher.com/docs/rancher/v2.0-v2.4/en/installation/requirements/).
|
||||
|
||||
Alternatively you can re-use the existing nodes after clearing Kubernetes and Rancher configurations. This will destroy the data on these nodes. See [Node Cleanup](faq/cleaning-cluster-nodes/) for the procedure.
|
||||
Alternatively you can re-use the existing nodes after clearing Kubernetes and Rancher configurations. This will destroy the data on these nodes. See [Node Cleanup](../../advanced-user-guides/manage-clusters/clean-cluster-nodes.md) for the procedure.
|
||||
|
||||
You must restore each of your etcd nodes to the same snapshot. Copy the snapshot you're using from one of your nodes to the others before running the `etcd snapshot-restore` command.
|
||||
|
||||
@@ -137,5 +137,5 @@ kube-system tiller-deploy-56c4cf647b-j4whh 1/1 Running 1
|
||||
|
||||
#### Finishing Up
|
||||
|
||||
Rancher should now be running and available to manage your Kubernetes clusters.
|
||||
Rancher should now be running and available to manage your Kubernetes clusters.
|
||||
> **IMPORTANT:** Remember to save your updated RKE config (`rancher-cluster.yml`) state file (`rancher-cluster.rkestate`) and `kubectl` credentials (`kube_config_rancher-cluster.yml`) files in a safe place for future maintenance for example in a version control system.
|
||||
|
||||
+2
-2
@@ -10,7 +10,7 @@ aliases:
|
||||
If you are rolling back to versions in either of these scenarios, you must follow some extra instructions in order to get your clusters working.
|
||||
|
||||
- Rolling back from v2.1.6+ to any version between v2.1.0 - v2.1.5 or v2.0.0 - v2.0.10.
|
||||
- Rolling back from v2.0.11+ to any version between v2.0.0 - v2.0.10.
|
||||
- Rolling back from v2.0.11+ to any version between v2.0.0 - v2.0.10.
|
||||
|
||||
Because of the changes necessary to address [CVE-2018-20321](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20321), special steps are necessary if the user wants to roll back to a previous version of Rancher where this vulnerability exists. The steps are as follows:
|
||||
|
||||
@@ -28,7 +28,7 @@ Because of the changes necessary to address [CVE-2018-20321](https://cve.mitre.o
|
||||
|
||||
2. After executing the command a `tokens.json` file will be created. Important! Back up this file in a safe place.** You will need it to restore functionality to your clusters after rolling back Rancher. **If you lose this file, you may lose access to your clusters.**
|
||||
|
||||
3. Rollback Rancher following the [normal instructions](upgrades/rollbacks/).
|
||||
3. Rollback Rancher following the [normal instructions](../../../../getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/rollbacks.md).
|
||||
|
||||
4. Once Rancher comes back up, every cluster managed by Rancher (except for Imported clusters) will be in an `Unavailable` state.
|
||||
|
||||
|
||||
+2
-2
@@ -75,7 +75,7 @@ In the **Upgrades** section, select the upgrade strategy to use, when you decide
|
||||
|
||||
### Roles
|
||||
|
||||
In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications](catalog/launching-apps), that specific user's permissions are used for creation of all workloads/resources that is required by the app.
|
||||
In the **Roles** section, you define the role of the multi-cluster application. Typically, when a user [launches catalog applications](./helm-charts-in-rancher/launching-apps.md), that specific user's permissions are used for creation of all workloads/resources that is required by the app.
|
||||
|
||||
For multi-cluster applications, the application is deployed by a _system user_ and is assigned as the creator of all underlying resources. A _system user_ is used instead of the actual user due to the fact that the actual user could be removed from one of the target projects. If the actual user was removed from one of the projects, then that user would no longer be able to manage the application for the other projects.
|
||||
|
||||
@@ -101,7 +101,7 @@ If the Helm chart that you are deploying contains a `questions.yml` file, Ranche
|
||||
|
||||
### Key Value Pairs for Native Helm Charts
|
||||
|
||||
For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a [custom Helm chart repository](catalog/custom/), answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
|
||||
For native Helm charts (i.e., charts from the **Helm Stable** or **Helm Incubator** catalogs or a [custom Helm chart repository](./helm-charts-in-rancher/creating-apps.md), answers are provided as key value pairs in the **Answers** section. These answers are used to override the default values.
|
||||
|
||||
### Members
|
||||
|
||||
|
||||
+7
-8
@@ -42,7 +42,7 @@ _Available as of v2.2.0_
|
||||
|
||||
Private catalog repositories can be added using credentials like Username and Password. You may also want to use the OAuth token if your Git or Helm repository server supports that.
|
||||
|
||||
For more information on private Git/Helm catalogs, refer to the [custom catalog configuration reference.](catalog/catalog-config)
|
||||
For more information on private Git/Helm catalogs, refer to the [custom catalog configuration reference.](./catalog-config.md)
|
||||
|
||||
1. From the **Global** view, choose **Tools > Catalogs** in the navigation bar. In versions before v2.2.0, you can select **Catalogs** directly in the navigation bar.
|
||||
2. Click **Add Catalog**.
|
||||
@@ -52,18 +52,17 @@ For more information on private Git/Helm catalogs, refer to the [custom catalog
|
||||
|
||||
# Adding Global Catalogs
|
||||
|
||||
>**Prerequisites:** In order to manage the [built-in catalogs](catalog/built-in/) or manage global catalogs, you need _one_ of the following permissions:
|
||||
>**Prerequisites:** In order to manage the [built-in catalogs](./built-in.md) or manage global catalogs, you need _one_ of the following permissions:
|
||||
>
|
||||
>- [Administrator Global Permissions](../../advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)
|
||||
>- [Custom Global Permissions](../../advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#custom-global-permissions) with the [Manage Catalogs](../../advanced-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md) role assigned.
|
||||
|
||||
1. From the **Global** view, choose **Tools > Catalogs** in the navigation bar. In versions before v2.2.0, you can select **Catalogs** directly in the navigation bar.
|
||||
2. Click **Add Catalog**.
|
||||
3. Complete the form. Select the Helm version that will be used to launch all of the apps in the catalog. For more information about the Helm version, refer to [this section.](
|
||||
helm-charts/legacy-catalogs/#catalog-helm-deployment-versions)
|
||||
3. Complete the form. Select the Helm version that will be used to launch all of the apps in the catalog. For more information about the Helm version, refer to [this section.](../../../pages-for-subheaders/helm-charts-in-rancher.md#catalog-helm-deployment-versions)
|
||||
4. Click **Create**.
|
||||
|
||||
**Result**: Your custom global catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [multi-cluster apps](catalog/multi-cluster-apps/) or [applications in any project](catalog/launching-apps/) from this catalog.
|
||||
**Result**: Your custom global catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [multi-cluster apps](../deploy-apps-across-clusters.md) or [applications in any project](./launching-apps.md) from this catalog.
|
||||
|
||||
# Adding Cluster Level Catalogs
|
||||
|
||||
@@ -82,7 +81,7 @@ _Available as of v2.2.0_
|
||||
helm-charts/legacy-catalogs/#catalog-helm-deployment-versions)
|
||||
5. Click **Create**.
|
||||
|
||||
**Result**: Your custom cluster catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [applications in any project in that cluster](catalog/apps/) from this catalog.
|
||||
**Result**: Your custom cluster catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [applications in any project in that cluster](../../../pages-for-subheaders/helm-charts-in-rancher.md) from this catalog.
|
||||
|
||||
# Adding Project Level Catalogs
|
||||
|
||||
@@ -102,8 +101,8 @@ _Available as of v2.2.0_
|
||||
helm-charts/legacy-catalogs/#catalog-helm-deployment-versions)
|
||||
5. Click **Create**.
|
||||
|
||||
**Result**: Your custom project catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [applications in that project](catalog/apps/) from this catalog.
|
||||
**Result**: Your custom project catalog is added to Rancher. Once it is in `Active` state, it has completed synchronization and you will be able to start deploying [applications in that project](../../../pages-for-subheaders/helm-charts-in-rancher.md) from this catalog.
|
||||
|
||||
# Custom Catalog Configuration Reference
|
||||
|
||||
Refer to [this page](catalog/catalog-config) more information on configuring custom catalogs.
|
||||
Refer to [this page](./catalog-config.md) more information on configuring custom catalogs.
|
||||
+2
-2
@@ -9,7 +9,7 @@ aliases:
|
||||
|
||||
There are default global catalogs packaged as part of Rancher.
|
||||
|
||||
Within Rancher, there are default catalogs packaged as part of Rancher. These can be enabled or disabled by an administrator.
|
||||
Within Rancher, there are default catalogs packaged as part of Rancher. These can be enabled or disabled by an administrator.
|
||||
|
||||
>**Prerequisites:** In order to manage the built-in catalogs or manage global catalogs, you need _one_ of the following permissions:
|
||||
>
|
||||
@@ -20,7 +20,7 @@ Within Rancher, there are default catalogs packaged as part of Rancher. These ca
|
||||
|
||||
2. Toggle the default catalogs that you want to be enabled or disabled:
|
||||
|
||||
- **Library:** The Library Catalog includes charts curated by Rancher. Rancher stores charts in a Git repository to expedite the fetch and update of charts. This catalog features Rancher Charts, which include some [notable advantages](helm-charts/legacy-catalogs/creating-apps/#rancher-charts) over native Helm charts.
|
||||
- **Library:** The Library Catalog includes charts curated by Rancher. Rancher stores charts in a Git repository to expedite the fetch and update of charts. This catalog features Rancher Charts, which include some [notable advantages](./creating-apps.md#rancher-charts) over native Helm charts.
|
||||
- **Helm Stable:** This catalog, which is maintained by the Kubernetes community, includes native [Helm charts](https://helm.sh/docs/chart_template_guide/). This catalog features the largest pool of apps.
|
||||
- **Helm Incubator:** Similar in user experience to Helm Stable, but this catalog is filled with applications in **beta**.
|
||||
|
||||
|
||||
+5
-5
@@ -38,7 +38,7 @@ In Rancher, you can add the custom Helm chart repository with only a catalog nam
|
||||
|
||||
# Catalog Fields
|
||||
|
||||
When [adding your catalog](catalog/custom/adding/) to Rancher, you'll provide the following information:
|
||||
When [adding your catalog](./adding-catalogs.md) to Rancher, you'll provide the following information:
|
||||
|
||||
|
||||
| Variable | Description |
|
||||
@@ -49,7 +49,7 @@ When [adding your catalog](catalog/custom/adding/) to Rancher, you'll provide th
|
||||
| Username (Optional) | Username or OAuth Token |
|
||||
| Password (Optional) | If you are authenticating using a username, enter the associated password. If you are using an OAuth token, use `x-oauth-basic`. |
|
||||
| Branch | For a Git repository, the branch name. Default: `master`. For a Helm Chart repository, this field is ignored. |
|
||||
| Helm version | The Helm version that will be used to deploy all of the charts in the catalog. This field cannot be changed later. For more information, refer to the [section on Helm versions.](helm-charts/legacy-catalogs/#catalog-helm-deployment-versions) |
|
||||
| Helm version | The Helm version that will be used to deploy all of the charts in the catalog. This field cannot be changed later. For more information, refer to the [section on Helm versions.](../../../pages-for-subheaders/helm-charts-in-rancher.md#catalog-helm-deployment-versions) |
|
||||
|
||||
# Private Repositories
|
||||
|
||||
@@ -59,7 +59,7 @@ Private Git or Helm chart repositories can be added into Rancher using either cr
|
||||
|
||||
### Using Username and Password
|
||||
|
||||
1. When [adding the catalog](catalog/custom/adding/), select the **Use private catalog** checkbox.
|
||||
1. When [adding the catalog](./adding-catalogs.md), select the **Use private catalog** checkbox.
|
||||
|
||||
2. Provide the `Username` and `Password` for your Git or Helm repository.
|
||||
|
||||
@@ -70,6 +70,6 @@ Read [using Git over HTTPS and OAuth](https://github.blog/2012-09-21-easier-buil
|
||||
1. Create an [OAuth token](https://github.com/settings/tokens)
|
||||
with `repo` permission selected, and click **Generate token**.
|
||||
|
||||
2. When [adding the catalog](catalog/custom/adding/), select the **Use private catalog** checkbox.
|
||||
2. When [adding the catalog](./adding-catalogs.md), select the **Use private catalog** checkbox.
|
||||
|
||||
3. For `Username`, provide the Git generated OAuth token. For `Password`, enter `x-oauth-basic`.
|
||||
3. For `Username`, provide the Git generated OAuth token. For `Password`, enter `x-oauth-basic`.
|
||||
|
||||
+1
-1
@@ -128,4 +128,4 @@ This reference contains variables that you can use in `questions.yml` nested und
|
||||
|
||||
# Tutorial: Example Custom Chart Creation
|
||||
|
||||
For a tutorial on adding a custom Helm chart to a custom catalog, refer to [this page.](catalog/tutorial)
|
||||
For a tutorial on adding a custom Helm chart to a custom catalog, refer to [this page.](./tutorial.md)
|
||||
|
||||
+4
-4
@@ -39,7 +39,7 @@ The following table lists the first version of Rancher each provider debuted.
|
||||
|
||||
# Global DNS Entries
|
||||
|
||||
For each application that you want to route traffic to, you will need to create a Global DNS Entry. This entry will use a fully qualified domain name (a.k.a FQDN) from a global DNS provider to target applications. The applications can either resolve to a single [multi-cluster application](catalog/multi-cluster-apps/) or to specific projects. You must [add specific annotation labels](#adding-annotations-to-ingresses-to-program-the-external-dns) to the ingresses in order for traffic to be routed correctly to the applications. Without this annotation, the programming for the DNS entry will not work.
|
||||
For each application that you want to route traffic to, you will need to create a Global DNS Entry. This entry will use a fully qualified domain name (a.k.a FQDN) from a global DNS provider to target applications. The applications can either resolve to a single [multi-cluster application](../deploy-apps-across-clusters.md) or to specific projects. You must [add specific annotation labels](#adding-annotations-to-ingresses-to-program-the-external-dns) to the ingresses in order for traffic to be routed correctly to the applications. Without this annotation, the programming for the DNS entry will not work.
|
||||
|
||||
# Permissions for Global DNS Providers and Entries
|
||||
|
||||
@@ -91,13 +91,13 @@ Permission checks are relaxed for removing target projects in order to support s
|
||||
1. For the Global DNS entry that you want to edit, click the **⋮ > Edit**.
|
||||
|
||||
|
||||
# Global DNS Entry Configuration
|
||||
# Global DNS Entry Configuration
|
||||
|
||||
| Field | Description |
|
||||
|----------|--------------------|
|
||||
| FQDN | Enter the **FQDN** you wish to program on the external DNS. |
|
||||
| Provider | Select a Global DNS **Provider** from the list. |
|
||||
| Resolves To | Select if this DNS entry will be for a [multi-cluster application](catalog/multi-cluster-apps/) or for workloads in different [projects](k8s-in-rancher/projects-and-namespaces/). |
|
||||
| Resolves To | Select if this DNS entry will be for a [multi-cluster application](../deploy-apps-across-clusters.md) or for workloads in different [projects](../../advanced-user-guides/manage-clusters/projects-and-namespaces.md). |
|
||||
| Multi-Cluster App Target | The target for the global DNS entry. You will need to ensure that [annotations are added to any ingresses](#adding-annotations-to-ingresses-to-program-the-external-dns) for the applications that you want to target. |
|
||||
| DNS TTL | Configure the DNS time to live value in seconds. By default, it will be 300 seconds. |
|
||||
| Member Access | Search for any users that you want to have the ability to manage this Global DNS entry. |
|
||||
@@ -158,4 +158,4 @@ In order for the DNS to be programmed, the following requirements must be met:
|
||||
* The ingress routing rule must be set to use a `hostname` that matches the FQDN of the Global DNS entry.
|
||||
* The ingress must have an annotation (`rancher.io/globalDNS.hostname`) and the value of this annotation should match the FQDN of the Global DNS entry.
|
||||
|
||||
Once the ingress in your [multi-cluster application](catalog/multi-cluster-apps/) or in your target projects is in an `active` state, the FQDN will be programmed on the external DNS against the Ingress IP addresses.
|
||||
Once the ingress in your [multi-cluster application](../deploy-apps-across-clusters.md) or in your target projects is in an `active` state, the FQDN will be programmed on the external DNS against the Ingress IP addresses.
|
||||
Reference in New Issue
Block a user