mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 20:48:11 +00:00
Remove unneeded intermediate folders
This commit is contained in:
Billy Tat
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: Namespaces
|
||||
weight: 2520
|
||||
aliases:
|
||||
- /rancher/v2.x/en/project-admin/namespaces/
|
||||
---
|
||||
|
||||
Within Rancher, you can further divide projects into different [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/), which are virtual clusters within a project backed by a physical cluster. Should you require another level of organization beyond projects and the `default` namespace, you can use multiple namespaces to isolate applications and resources.
|
||||
|
||||
Although you assign resources at the project level so that each namespace in the project can use them, you can override this inheritance by assigning resources explicitly to a namespace.
|
||||
|
||||
Resources that you can assign directly to namespaces include:
|
||||
|
||||
- [Workloads]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/workloads/)
|
||||
- [Load Balancers/Ingress]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/load-balancers-and-ingress/)
|
||||
- [Service Discovery Records]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/service-discovery/)
|
||||
- [Certificates]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/certificates/)
|
||||
- [ConfigMaps]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/configmaps/)
|
||||
- [Registries]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/registries/)
|
||||
- [Secrets]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/secrets/)
|
||||
|
||||
To manage permissions in a vanilla Kubernetes cluster, cluster admins configure role-based access policies for each namespace. With Rancher, user permissions are assigned on the project level instead, and permissions are automatically inherited by any namespace owned by the particular project.
|
||||
|
||||
> **Note:** If you create a namespace with `kubectl`, it may be unusable because `kubectl` doesn't require your new namespace to be scoped within a project that you have access to. If your permissions are restricted to the project level, it is better to [create a namespace through Rancher]({{<baseurl>}}/rancher/v2.5/en/project-admin/namespaces) to ensure that you will have permission to access the namespace.
|
||||
|
||||
|
||||
### Creating Namespaces
|
||||
|
||||
Create a new namespace to isolate apps and resources in a project.
|
||||
|
||||
>**Tip:** When working with project resources that you can assign to a namespace (i.e., [workloads]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/workloads/deploy-workloads/), [certificates]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/certificates/), [ConfigMaps]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/configmaps), etc.) you can create a namespace on the fly.
|
||||
|
||||
1. From the **Global** view, open the project where you want to create a namespace.
|
||||
|
||||
>**Tip:** As a best practice, we recommend creating namespaces from the project level. However, cluster owners and members can create them from the cluster level as well.
|
||||
|
||||
1. From the main menu, select **Namespace**. The click **Add Namespace**.
|
||||
|
||||
1. **Optional:** If your project has [Resource Quotas]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/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. Enter a **Name** and then click **Create**.
|
||||
|
||||
**Result:** Your namespace is added to the project. You can begin assigning cluster resources to the namespace.
|
||||
|
||||
### Moving Namespaces to Another Project
|
||||
|
||||
Cluster admins and members may occasionally need to move a namespace to another project, such as when you want a different team to start using the application.
|
||||
|
||||
1. From the **Global** view, open the cluster that contains the namespace you want to move.
|
||||
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
|
||||
1. Select the namespace(s) that you want to move to a different project. Then click **Move**. You can move multiple namespaces at one.
|
||||
|
||||
>**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]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/resource-quotas/) 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**.
|
||||
|
||||
**Result:** Your namespace is moved to a different project (or is unattached from all projects). If any project resources are attached to the namespace, the namespace releases them and then attached resources from the new project.
|
||||
|
||||
### Editing Namespace Resource Quotas
|
||||
|
||||
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]({{<baseurl>}}/rancher/v2.5/en/project-admin/resource-quotas/override-namespace-default/).
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
title: Rancher's CI/CD Pipelines
|
||||
description: Use Rancher’s CI/CD pipeline to automatically checkout code, run builds or scripts, publish Docker images, and deploy software to users
|
||||
weight: 4000
|
||||
aliases:
|
||||
- /rancher/v2.5/en/concepts/ci-cd-pipelines/
|
||||
- /rancher/v2.5/en/tasks/pipelines/
|
||||
- /rancher/v2.5/en/tools/pipelines/configurations/
|
||||
- /rancher/v2.x/en/project-admin/pipelines/
|
||||
---
|
||||
Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline.
|
||||
|
||||
After configuring Rancher and GitHub, you can deploy containers running Jenkins to automate a pipeline execution:
|
||||
|
||||
- Build your application from code to image.
|
||||
- Validate your builds.
|
||||
- Deploy your build images to your cluster.
|
||||
- Run unit tests.
|
||||
- Run regression tests.
|
||||
|
||||
For details, refer to the [pipelines]({{<baseurl>}}/rancher/v2.5/en/k8s-in-rancher/pipelines) section.
|
||||
+33
@@ -0,0 +1,33 @@
|
||||
---
|
||||
title: Pod Security Policies
|
||||
weight: 5600
|
||||
aliases:
|
||||
- /rancher/v2.x/en/project-admin/pod-security-policies/
|
||||
---
|
||||
|
||||
> These cluster options are only available for [clusters in which Rancher has launched Kubernetes]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/rke-clusters/).
|
||||
|
||||
You can always assign a pod security policy (PSP) to an existing project if you didn't assign one during creation.
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- Create a Pod Security Policy within Rancher. Before you can assign a default PSP to an existing project, you must have a PSP available for assignment. For instruction, see [Creating Pod Security Policies]({{<baseurl>}}/rancher/v2.5/en/admin-settings/pod-security-policies/).
|
||||
- Assign a default Pod Security Policy to the project's cluster. You can't assign a PSP to a project until one is already applied to the cluster. For more information, see [the documentation about adding a pod security policy to a cluster]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/pod-security-policy).
|
||||
|
||||
### Applying a Pod Security Policy
|
||||
|
||||
1. From the **Global** view, find the cluster containing the project you want to apply a PSP to.
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
1. Find the project that you want to add a PSP to. From that project, select **⋮ > Edit**.
|
||||
1. From the **Pod Security Policy** drop-down, select the PSP you want to apply to the project.
|
||||
Assigning a PSP to a project will:
|
||||
|
||||
- Override the cluster's default PSP.
|
||||
- Apply the PSP to the project.
|
||||
- Apply the PSP to any namespaces you add to the project later.
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** The PSP is applied to the project and any namespaces added to the project.
|
||||
|
||||
>**Note:** Any workloads that are already running in a cluster or project before a PSP is assigned will not be checked to determine if they comply with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: Project Administration
|
||||
weight: 9
|
||||
aliases:
|
||||
- /rancher/v2.5/en/project-admin/editing-projects/
|
||||
- /rancher/v2.x/en/project-admin/
|
||||
---
|
||||
|
||||
_Projects_ are objects introduced in Rancher that help organize namespaces in your Kubernetes cluster. You can use projects to create multi-tenant clusters, which allows a group of users to share the same underlying resources without interacting with each other's applications.
|
||||
|
||||
In terms of hierarchy:
|
||||
|
||||
- Clusters contain projects
|
||||
- Projects contain namespaces
|
||||
|
||||
Within Rancher, projects allow you to manage multiple namespaces as a single entity. In native Kubernetes, which does not include projects, features like role-based access rights or cluster resources are assigned to individual namespaces. In clusters where multiple namespaces require the same set of access rights, assigning these rights to each individual namespace can become tedious. Even though all namespaces require the same rights, there's no way to apply those rights to all of your namespaces in a single action. You'd have to repetitively assign these rights to each namespace!
|
||||
|
||||
Rancher projects resolve this issue by allowing you to apply resources and access rights at the project level. Each namespace in the project then inherits these resources and policies, so you only have to assign them to the project once, rather than assigning them to each individual namespace.
|
||||
|
||||
You can use projects to perform actions like:
|
||||
|
||||
- [Assign users access to a group of namespaces]({{<baseurl>}}/rancher/v2.5/en/project-admin/project-members)
|
||||
- Assign users [specific roles in a project]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/default-custom-roles/)
|
||||
- [Set resource quotas]({{<baseurl>}}/rancher/v2.5/en/project-admin/resource-quotas/)
|
||||
- [Manage namespaces]({{<baseurl>}}/rancher/v2.5/en/project-admin/namespaces/)
|
||||
- [Configure tools]({{<baseurl>}}/rancher/v2.5/en/project-admin/tools/)
|
||||
- [Set up pipelines for continuous integration and deployment]({{<baseurl>}}/rancher/v2.5/en/project-admin/pipelines)
|
||||
- [Configure pod security policies]({{<baseurl>}}/rancher/v2.5/en/project-admin/pod-security-policies)
|
||||
|
||||
### Authorization
|
||||
|
||||
Non-administrative users are only authorized for project access after an [administrator]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#project-roles) adds them to the project's **Members** tab.
|
||||
|
||||
Whoever creates the project automatically becomes a [project owner]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/#project-roles).
|
||||
|
||||
## Switching between Projects
|
||||
|
||||
To switch between projects, use the drop-down available in the navigation bar. Alternatively, you can switch between projects directly in the navigation bar.
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure.
|
||||
|
||||
1. Select **Projects/Namespaces** from the navigation bar.
|
||||
|
||||
1. Select the link for the project that you want to open.
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
title: Adding Users to Projects
|
||||
weight: 2505
|
||||
aliases:
|
||||
- /rancher/v2.5/en/tasks/projects/add-project-members/
|
||||
- /rancher/v2.5/en/cluster-admin/projects-and-namespaces/project-members
|
||||
- /rancher/v2.x/en/project-admin/project-members/
|
||||
---
|
||||
|
||||
If you want to provide a user with access and permissions to _specific_ projects and resources within a cluster, assign the user a project membership.
|
||||
|
||||
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]({{<baseurl>}}/rancher/v2.5/en/cluster-provisioning/cluster-members/) 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.]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/)
|
||||
|
||||
### Adding Members to an Existing Project
|
||||
|
||||
Following project creation, you can add users as project members so that they can access its resources.
|
||||
|
||||
1. From the **Global** view, open the project that you want to add members to.
|
||||
|
||||
2. From the main menu, select **Members**. Then click **Add Member**.
|
||||
|
||||
3. Search for the user or group that you want to add to the project.
|
||||
|
||||
If external authentication is configured:
|
||||
|
||||
- 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.
|
||||
|
||||
[What are Project Roles?]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/cluster-project-roles/)
|
||||
|
||||
>**Notes:**
|
||||
>
|
||||
>- 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.
|
||||
>
|
||||
>- For `Custom` roles, you can modify the list of individual roles available for assignment.
|
||||
>
|
||||
> - To add roles to the list, [Add a Custom Role]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/default-custom-roles).
|
||||
> - To remove roles from the list, [Lock/Unlock Roles]({{<baseurl>}}/rancher/v2.5/en/admin-settings/rbac/locked-roles/).
|
||||
|
||||
**Result:** The chosen users are added to the project.
|
||||
|
||||
- To revoke project membership, select the user and click **Delete**. This action deletes membership, not the user.
|
||||
- To modify a user's roles in the project, delete them from the project, and then re-add them with modified roles.
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Setting Container Default Resource Limits
|
||||
weight: 3
|
||||
aliases:
|
||||
- /rancher/v2.x/en/project-admin/resource-quotas/override-container-default/
|
||||
---
|
||||
|
||||
When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required.
|
||||
|
||||
To avoid setting these limits on each and every container during workload creation, a default container resource limit can be specified on the namespace.
|
||||
|
||||
### Editing the Container Default Resource Limit
|
||||
|
||||
Edit [container default resource limit]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/resource-quotas/) 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.
|
||||
|
||||
1. From the **Global** view, open the cluster containing the project to which you want to edit the container default resource limit.
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
1. Find the project that you want to edit the container default resource limit. From that project, select **⋮ > Edit**.
|
||||
1. Expand **Container Default Resource Limit** and edit the values.
|
||||
|
||||
### Resource Limit Propagation
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
### Container Resource Quota Types
|
||||
|
||||
The following resource limits can be configured:
|
||||
|
||||
| Resource Type | Description |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| CPU Limit | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the container.|
|
||||
| CPU Reservation | The minimum amount of CPU (in millicores) guaranteed to the container. |
|
||||
| Memory Limit | The maximum amount of memory (in bytes) allocated to the container. |
|
||||
| Memory Reservation | The minimum amount of memory (in bytes) guaranteed to the container.
|
||||
+36
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: Overriding the Default Limit for a Namespace
|
||||
weight: 2
|
||||
aliases:
|
||||
- /rancher/v2.x/en/project-admin/resource-quotas/override-namespace-default/
|
||||
---
|
||||
|
||||
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]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/) for `Namespace 3` so that the namespace can access more resources.
|
||||
|
||||
<sup>Namespace Default Limit Override</sup>
|
||||
|
||||
|
||||
How to: [Editing Namespace Resource Quotas]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/)
|
||||
|
||||
### Editing Namespace Resource Quotas
|
||||
|
||||
If there is a [resource quota]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/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.
|
||||
|
||||
1. From the **Global** view, open the cluster that contains the namespace for which you want to edit the resource quota.
|
||||
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
|
||||
1. Find the namespace for which you want to edit the resource quota. Select **⋮ > Edit**.
|
||||
|
||||
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]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/resource-quotas/).
|
||||
|
||||
>**Note:**
|
||||
>
|
||||
>- If a resource quota is not configured for the project, these options will not be available.
|
||||
>- If you enter limits that exceed the configured project limits, Rancher will not let you save your edits.
|
||||
|
||||
**Result:** Your override is applied to the namespace's resource quota.
|
||||
+26
@@ -0,0 +1,26 @@
|
||||
---
|
||||
title: Resource Quota Type Reference
|
||||
weight: 4
|
||||
aliases:
|
||||
- /rancher/v2.x/en/project-admin/resource-quotas/quota-type-reference/
|
||||
---
|
||||
|
||||
When you create a resource quota, you are configuring the pool of resources available to the project. You can set the following resource limits for the following resource types.
|
||||
|
||||
| Resource Type | Description |
|
||||
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| CPU Limit* | The maximum amount of CPU (in [millicores](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu)) allocated to the project/namespace.<sup>1</sup> |
|
||||
| CPU Reservation* | The minimum amount of CPU (in millicores) guaranteed to the project/namespace.<sup>1</sup> |
|
||||
| Memory Limit* | The maximum amount of memory (in bytes) allocated to the project/namespace.<sup>1</sup> |
|
||||
| Memory Reservation* | The minimum amount of memory (in bytes) guaranteed to the project/namespace.<sup>1</sup> |
|
||||
| Storage Reservation | The minimum amount of storage (in gigabytes) guaranteed to the project/namespace. |
|
||||
| Services Load Balancers | The maximum number of load balancers services that can exist in the project/namespace. |
|
||||
| Services Node Ports | The maximum number of node port services that can exist in the project/namespace. |
|
||||
| Pods | The maximum number of pods that can exist in the project/namespace in a non-terminal state (i.e., pods with a state of `.status.phase in (Failed, Succeeded)` equal to true). |
|
||||
| Services | The maximum number of services that can exist in the project/namespace. |
|
||||
| ConfigMaps | The maximum number of ConfigMaps that can exist in the project/namespace. |
|
||||
| Persistent Volume Claims | The maximum number of persistent volume claims that can exist in the project/namespace. |
|
||||
| Replications Controllers | The maximum number of replication controllers that can exist in the project/namespace. |
|
||||
| Secrets | The maximum number of secrets that can exist in the project/namespace. |
|
||||
|
||||
>**<sup>*</sup>** When setting resource quotas, if you set anything related to CPU or Memory (i.e. limits or reservations) on a project / namespace, all containers will require a respective CPU or Memory field set during creation. A container default resource limit can be set at the same time to avoid the need to explicitly set these limits for every workload. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/#requests-vs-limits) for more details on why this is required.
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: How Resource Quotas Work in Rancher Projects
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.x/en/project-admin/resource-quotas/quotas-for-projects/
|
||||
---
|
||||
|
||||
Resource quotas in Rancher include the same functionality as the [native version of Kubernetes](https://kubernetes.io/docs/concepts/policy/resource-quotas/). However, in Rancher, resource quotas have been extended so that you can apply them to projects.
|
||||
|
||||
In a standard Kubernetes deployment, resource quotas are applied to individual namespaces. However, you cannot apply the quota to your namespaces simultaneously with a single action. Instead, the resource quota must be applied multiple times.
|
||||
|
||||
In the following diagram, a Kubernetes administrator is trying to enforce a resource quota without Rancher. The administrator wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The administrator has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually.
|
||||
|
||||
<sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
|
||||
|
||||
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the project, and then the quota propagates to each namespace, whereafter Kubernetes enforces your limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can override it.
|
||||
|
||||
The resource quota includes two limits, which you set while creating or editing a project:
|
||||
<a id="project-limits"></a>
|
||||
|
||||
- **Project Limits:**
|
||||
|
||||
This set of values configures an overall resource limit for the project. If you try to add a new namespace to the project, Rancher uses the limits you've set to validate that the project has enough resources to accommodate the namespace. In other words, if you try to move a namespace into a project near its resource quota, Rancher blocks you from moving the namespace.
|
||||
|
||||
- **Namespace Default Limits:**
|
||||
|
||||
This value is the default resource limit available for each namespace. When the resource quota is created at the project level, this limit is automatically propagated to each namespace in the project. Each namespace is bound to this default limit unless you override it.
|
||||
|
||||
In the following diagram, a Rancher administrator wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the administrator can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`) when created.
|
||||
|
||||
<sup>Rancher: Resource Quotas Propagating to Each Namespace</sup>
|
||||
|
||||
|
||||
Let's highlight some more nuanced functionality. If a quota is deleted at the project level, it will also be removed from all namespaces contained within that project, despite any overrides that may exist. Further, updating an existing namespace default limit for a quota at the project level will not result in that value being propagated to existing namespaces in the project; the updated value will only be applied to newly created namespaces in that project. To update a namespace default limit for existing namespaces you can delete and subsequently recreate the quota at the project level with the new default value. This will result in the new default value being applied to all existing namespaces in the project.
|
||||
|
||||
The following table explains the key differences between the two quota types.
|
||||
|
||||
| Rancher Resource Quotas | Kubernetes Resource Quotas |
|
||||
| ---------------------------------------------------------- | -------------------------------------------------------- |
|
||||
| Applies to projects and namespace. | Applies to namespaces only. |
|
||||
| Creates resource pool for all namespaces in project. | Applies static resource limits to individual namespaces. |
|
||||
| Applies resource quotas to namespaces through propagation. | Applies only to the assigned namespace.
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: Project Resource Quotas
|
||||
weight: 2515
|
||||
aliases:
|
||||
- /rancher/v2.5/en/cluster-admin/projects-and-namespaces/resource-quotas
|
||||
- /rancher/v2.x/en/project-admin/resource-quotas/
|
||||
---
|
||||
|
||||
In situations where several teams share a cluster, one team may overconsume the resources available: CPU, memory, storage, services, Kubernetes objects like pods or secrets, and so on. To prevent this overconsumption, you can apply a _resource quota_, which is a Rancher feature that limits the resources available to a project or namespace.
|
||||
|
||||
This page is a how-to guide for creating resource quotas in existing projects.
|
||||
|
||||
Resource quotas can also be set when a new project is created. For details, refer to the section on [creating new projects.]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/#creating-projects)
|
||||
|
||||
Resource quotas in Rancher include the same functionality as the [native version of Kubernetes](https://kubernetes.io/docs/concepts/policy/resource-quotas/). In Rancher, resource quotas have been extended so that you can apply them to projects. For details on how resource quotas work with projects in Rancher, refer to [this page.](./quotas-for-projects)
|
||||
|
||||
### Applying Resource Quotas to Existing Projects
|
||||
|
||||
Edit [resource quotas]({{<baseurl>}}/rancher/v2.5/en/cluster-admin/projects-and-namespaces/resource-quotas) when:
|
||||
|
||||
- You want to limit the resources that a project and its namespaces can use.
|
||||
- You want to scale the resources available to a project up or down when a research quota is already in effect.
|
||||
|
||||
1. From the **Global** view, open the cluster containing the project to which you want to apply a resource quota.
|
||||
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
|
||||
1. Find the project that you want to add a resource quota to. From that project, select **⋮ > Edit**.
|
||||
|
||||
1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas.
|
||||
|
||||
1. Select a Resource Type. For more information on types, see the [quota type reference.](./quota-type-reference)
|
||||
|
||||
1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
|
||||
|
||||
| Field | Description |
|
||||
| ----------------------- | -------------------------------------------------------------------------------------------------------- |
|
||||
| Project Limit | The overall resource limit for the project. |
|
||||
| Namespace Default Limit | The default resource limit available for each namespace. This limit is propagated to each namespace in the project. The combined limit of all project namespaces shouldn't exceed the project limit. |
|
||||
|
||||
1. **Optional:** Add more quotas.
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
**Result:** The resource quota is applied to your project and namespaces. When you add more namespaces in the future, Rancher validates that the project can accommodate the namespace. If the project can't allocate the resources, you may still create namespaces, but they will be given a resource quota of 0. Subsequently, Rancher will not allow you to create any resources restricted by this quota.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
title: Tools for Logging, Monitoring, and Visibility
|
||||
weight: 2525
|
||||
aliases:
|
||||
- /rancher/v2.x/en/project-admin/tools/
|
||||
---
|
||||
|
||||
Rancher contains a variety of tools that aren't included in Kubernetes to assist in your DevOps operations. Rancher can integrate with external services to help your clusters run more efficiently. Tools are divided into following categories:
|
||||
<!-- TOC -->
|
||||
|
||||
- [Notifiers and Alerts](#notifiers-and-alerts)
|
||||
- [Logging](#logging)
|
||||
- [Monitoring](#monitoring)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
## Notifiers and Alerts
|
||||
|
||||
Notifiers and alerts are two features that work together to inform you of events in the Rancher system. Before they can be enabled, the monitoring application must be installed.
|
||||
|
||||
Notifiers are services that inform you of alert events. You can configure notifiers to send alert notifications to staff best suited to take corrective action. Notifications can be sent with Slack, email, PagerDuty, WeChat, and webhooks.
|
||||
|
||||
Alerts are rules that trigger those notifications. Before you can receive alerts, you must configure one or more notifier in Rancher. The scope for alerts can be set at either the cluster or project level.
|
||||
|
||||
## Logging
|
||||
|
||||
Logging is helpful because it allows you to:
|
||||
|
||||
- Capture and analyze the state of your cluster
|
||||
- Look for trends in your environment
|
||||
- Save your logs to a safe location outside of your cluster
|
||||
- Stay informed of events like a container crashing, a pod eviction, or a node dying
|
||||
- More easily debugg and troubleshoot problems
|
||||
|
||||
Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.
|
||||
|
||||
For details, refer to the [logging section.]({{<baseurl>}}/rancher/v2.5/en/logging)
|
||||
|
||||
## Monitoring
|
||||
|
||||
Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with [Prometheus](https://prometheus.io/), a leading open-source monitoring solution. For details, refer to the [monitoring section.]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting)
|
||||
Reference in New Issue
Block a user