mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-18 10:55:21 +00:00
Merge pull request #2164 from catherineluse/project-admin-reorg
Reorganize project administration section
This commit is contained in:
Catherine Luse
GitHub
@@ -7,9 +7,21 @@ aliases:
|
||||
- /rancher/v2.x/en/tasks/projects/
|
||||
- /rancher/v2.x/en/tasks/projects/create-project/
|
||||
- /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/
|
||||
- /rancher/v2.x/en/tasks/projects/create-project/
|
||||
---
|
||||
|
||||
## Projects
|
||||
This section describes how projects and namespaces work with Rancher. It covers the following topics:
|
||||
|
||||
- [About projects](#about-projects)
|
||||
- [The cluster's default project](#the-cluster-s-default-project)
|
||||
- [The system project](#the-system-project)
|
||||
- [Project authorization](#project-authorization)
|
||||
- [Pod security policies](#pod-security-policies)
|
||||
- [Creating projects](#creating-projects)
|
||||
- [Switching between clusters and projects](#switching-between-clusters-and-projects)
|
||||
- [Namespaces](#namespaces)
|
||||
|
||||
# About Projects
|
||||
|
||||
A project is a group of multiple [namespaces](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) and access control policies within a cluster. A project is a concept introduced by Rancher, not Kubernetes, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.x/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.x/en/k8s-in-rancher/)
|
||||
|
||||
@@ -34,12 +46,11 @@ When you create a cluster, two projects are automatically created within it:
|
||||
- [Default Project](#default-project)
|
||||
- [System Project](#system-project)
|
||||
|
||||
### The Cluster's Default Project
|
||||
|
||||
### Default Project
|
||||
When you provision a cluster with Rancher, it automatically creates a `default` project for the cluster. This is a project you can use to get started with your cluster, but you can always delete it and replace it with projects that have more descriptive names.
|
||||
|
||||
When you provision a cluster, it automatically creates a `default` project for the cluster. This is a project you can use to get started with your cluster, but you can always delete it and replace it with projects that have more descriptive names.
|
||||
|
||||
### System Project
|
||||
### The System Project
|
||||
|
||||
_Available as of v2.0.7_
|
||||
|
||||
@@ -61,18 +72,18 @@ The `system` project:
|
||||
>
|
||||
>The `system` project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health.
|
||||
|
||||
### Authorization
|
||||
# Project Authorization
|
||||
|
||||
Non-administrative users are only authorized for project access after an administrator, cluster owner or cluster member explicitly adds them to the project's **Members** tab.
|
||||
|
||||
>**Exception:**
|
||||
> Non-administrative users can access projects that they create themselves.
|
||||
|
||||
### Pod Security Policies
|
||||
# Pod Security Policies
|
||||
|
||||
Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) at the project level in addition to the cluster level. However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
|
||||
Rancher extends Kubernetes to allow the application of [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) at the [project level]({{<baseurl>}}/rancher/v2.x/en/project-admin/pod-security-policies) in addition to the [cluster level.](../pod-security-policy) However, as a best practice, we recommend applying Pod Security Policies at the cluster level.
|
||||
|
||||
### Creating Projects
|
||||
# Creating Projects
|
||||
|
||||
1. From the **Global** view, choose **Clusters** from the main menu. From the **Clusters** page, open the cluster from which you want to create a project.
|
||||
|
||||
@@ -137,7 +148,7 @@ Rancher extends Kubernetes to allow the application of [Pod Security Policies](h
|
||||
|
||||
**Result:** Your project is created. You can view it from the cluster's **Projects/Namespaces** view.
|
||||
|
||||
## Switching between Clusters/Projects
|
||||
# Switching between Clusters and Projects
|
||||
|
||||
To switch between clusters and projects, use the **Global** drop-down available in the main menu.
|
||||
|
||||
@@ -148,7 +159,7 @@ Alternatively, you can switch between projects and clusters using the main menu.
|
||||
- To switch between clusters, open the **Global** view and select **Clusters** from the main menu. Then open a cluster.
|
||||
- To switch between projects, open a cluster, and then select **Projects/Namespaces** from the main menu. Select the link for the project that you want to open.
|
||||
|
||||
## Namespaces
|
||||
# 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.
|
||||
|
||||
|
||||
@@ -56,7 +56,7 @@ For more information, see [Service Discovery]({{< baseurl >}}/rancher/v2.x/en/k8
|
||||
|
||||
## Pipelines
|
||||
|
||||
After your project has been [configured to a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), you can add the repositories and start configuring a pipeline for each repository.
|
||||
After your project has been [configured to a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines/#version-control-providers), you can add the repositories and start configuring a pipeline for each repository.
|
||||
|
||||
For more information, see [Pipelines]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/).
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ aliases:
|
||||
>- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1.
|
||||
>- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x).
|
||||
|
||||
Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitbucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments.
|
||||
Before setting up any pipelines, review the [pipeline overview]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines/) and ensure that the project has [configured authentication to your version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines/#version-control-providers), e.g. GitHub, GitLab, Bitbucket. If you haven't configured a version control provider, you can always use [Rancher's example repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/example/) to view some common pipeline deployments.
|
||||
|
||||
If you can access a project, you can enable repositories to start building pipelines. Only an [administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can authorize version control providers.
|
||||
|
||||
@@ -233,7 +233,7 @@ timeout: 30
|
||||
|
||||
Run your pipeline for the first time. From the project view in Rancher, go to **Resources > Pipelines.** (In versions prior to v2.3.0, go to the **Pipelines** tab.) Find your pipeline and select the vertical **Ellipsis (...) > Run**.
|
||||
|
||||
During this initial run, your pipeline is tested, and the following [pipeline components]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/#how-pipelines-work) are deployed to your project as workloads in a new namespace dedicated to the pipeline:
|
||||
During this initial run, your pipeline is tested, and the following [pipeline components]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines/#how-pipelines-work) are deployed to your project as workloads in a new namespace dedicated to the pipeline:
|
||||
|
||||
- `docker-registry`
|
||||
- `jenkins`
|
||||
|
||||
@@ -11,7 +11,7 @@ Rancher ships with several example repositories that you can use to familiarize
|
||||
- Maven
|
||||
- php
|
||||
|
||||
> **Note:** The example repositories are only available if you have not [configured a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines).
|
||||
> **Note:** The example repositories are only available if you have not [configured a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines).
|
||||
|
||||
## Configure Repositories
|
||||
|
||||
@@ -67,4 +67,4 @@ After enabling an example repository, run the pipeline to see how it works.
|
||||
|
||||
## What's Next?
|
||||
|
||||
For detailed information about setting up your own pipeline for your repository, [configure a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines), [enable a repository](#configure-repositories) and finally [configure your pipeline]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#pipeline-configuration).
|
||||
For detailed information about setting up your own pipeline for your repository, [configure a version control provider]({{< baseurl >}}/rancher/v2.x/en/project-admin/pipelines), [enable a repository](#configure-repositories) and finally [configure your pipeline]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#pipeline-configuration).
|
||||
|
||||
@@ -38,7 +38,7 @@ The Rancher API server is built on top of an embedded Kubernetes API server and
|
||||
- **Provisioning Kubernetes clusters:** The Rancher API server can [provision Kubernetes]({{<baseurl>}}/rancher/v2.x/en/cluster-provisioning/) on existing nodes, or perform [Kubernetes upgrades.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/upgrading-kubernetes)
|
||||
- **Catalog management:** Rancher provides the ability to use a [catalog of Helm charts]({{<baseurl>}}/rancher/v2.x/en/catalog/) that make it easy to repeatedly deploy applications.
|
||||
- **Managing projects:** A project is a group of multiple namespaces and access control policies within a cluster. A project is a Rancher concept, not a Kubernetes concept, which allows you manage multiple namespaces as a group and perform Kubernetes operations in them. The Rancher UI provides features for [project administration]({{<baseurl>}}/rancher/v2.x/en/project-admin/) and for [managing applications within projects.]({{<baseurl>}}/rancher/v2.x/en/k8s-in-rancher/)
|
||||
- **Pipelines:** Setting up a [pipeline]({{<baseurl>}}/rancher/v2.x/en/project-admin/tools/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
|
||||
- **Pipelines:** Setting up a [pipeline]({{<baseurl>}}/rancher/v2.x/en/project-admin/pipelines/) can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
|
||||
- **Istio:** Our [integration with Istio]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/istio/) is designed so that a Rancher operator, such as an administrator or cluster owner, can deliver Istio to developers. Then developers can use Istio to enforce security policies, troubleshoot problems, or manage traffic for green/blue deployments, canary deployments, or A/B testing.
|
||||
|
||||
### Working with Cloud Infrastructure
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
title: Project Administration
|
||||
weight: 2500
|
||||
aliases:
|
||||
- /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/
|
||||
- /rancher/v2.x/en/project-admin/editing-projects/
|
||||
---
|
||||
|
||||
_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.
|
||||
@@ -18,10 +21,11 @@ You can use projects to perform actions like:
|
||||
|
||||
- [Assign users access to a group of namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/project-members)
|
||||
- Assign users [specific roles in a project]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/default-custom-roles/)
|
||||
- [Edit project settings]({{< baseurl >}}/rancher/v2.x/en/project-admin/editing-projects/)
|
||||
- [Set resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/)
|
||||
- [Manage namespaces]({{< baseurl >}}/rancher/v2.x/en/project-admin/namespaces/)
|
||||
- [Configure tools]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/)
|
||||
- [Set up pipelines for continuous integration and deployment]({{<baseurl>}}/rancher/v2.x/en/project-admin/pipelines)
|
||||
- [Configure pod security policies]({{<baseurl>}}/rancher/v2.x/en/project-admin/pod-security-policies)
|
||||
|
||||
### Authorization
|
||||
|
||||
|
||||
@@ -1,125 +0,0 @@
|
||||
---
|
||||
title: Editing Projects
|
||||
weight: 2510
|
||||
aliases:
|
||||
- /rancher/v2.x/en/tasks/projects/create-project/
|
||||
- /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/
|
||||
---
|
||||
|
||||
After projects are created, there are certain aspects that can be changed later.
|
||||
|
||||
## Adding Members
|
||||
|
||||
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.x/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.
|
||||
>
|
||||
>- 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.x/en/admin-settings/rbac/default-custom-roles).
|
||||
> - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/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.
|
||||
|
||||
## Editing the Pod Security Policy
|
||||
|
||||
>**Note:** These cluster options are only available for [clusters that Rancher has launched Kubernetes]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/).
|
||||
|
||||
You can always assign a 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.x/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 [Existing Cluster: Adding a Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/#adding-changing-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**.
|
||||
|
||||
3. Find the project that you want to add a PSP to. From that project, select **Vertical Ellipsis (...) > Edit**.
|
||||
|
||||
4. 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.
|
||||
|
||||
5. 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 if it complies with the PSP. Workloads would need to be cloned or upgraded to see if they pass the PSP.
|
||||
|
||||
## Editing Resource Quotas
|
||||
|
||||
_Available as of v2.0.1_
|
||||
|
||||
Edit [resource quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/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 **Ellipsis (...) > Edit**.
|
||||
|
||||
1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas.
|
||||
|
||||
1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/#resource-quota-types).
|
||||
|
||||
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, Rancher won't let you save your changes.
|
||||
|
||||
|
||||
## Editing Container Default Resource Limit
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
Edit [container default resource limit]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#setting-container-default-resource-limit) 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 **Ellipsis (...) > Edit**.
|
||||
|
||||
1. Expand **Container Default Resource Limit** and edit the values.
|
||||
@@ -60,21 +60,6 @@ Cluster admins and members may occasionally need to move a namespace to another
|
||||
|
||||
### Editing Namespace Resource Quotas
|
||||
|
||||
If there is a [resource quota]({{< baseurl >}}/rancher/v2.x/en/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.
|
||||
You can always 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 **Ellipsis (...) > 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 Quota Types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
|
||||
|
||||
>**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:** The namespace's default resource quota is overwritten with your override.
|
||||
For more information, see how to [edit namespace resource quotas]({{< baseurl >}}/rancher/v2.x/en/project-admin//resource-quotas/override-namespace-default/#editing-namespace-resource-quotas).
|
||||
+17
-1
@@ -1,13 +1,29 @@
|
||||
---
|
||||
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: 2529
|
||||
weight: 4000
|
||||
aliases:
|
||||
- /rancher/v2.x/en/concepts/ci-cd-pipelines/
|
||||
- /rancher/v2.x/en/tasks/pipelines/
|
||||
- /rancher/v2.x/en/tools/pipelines/
|
||||
- /rancher/v2.x/en/tools/pipelines/configurations/
|
||||
- /rancher/v2.x/en/project-admin/tools/pipelines
|
||||
---
|
||||
Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline.
|
||||
|
||||
To set up a pipeline, you'll first need to authorize Rancher using your GitHub settings. Directions are provided in the Rancher UI. After authorizing Rancher in GitHub, provide Rancher with a client ID and secret to authenticate.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
A _pipeline_ is a software delivery process that is broken into different stages and steps. Setting up a pipeline can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
|
||||
|
||||
+1
@@ -3,6 +3,7 @@ title: v2.0.x Pipeline Documentation
|
||||
weight: 9000
|
||||
aliases:
|
||||
- /rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x
|
||||
- /rancher/v2.x/en/project-admin/tools/pipelines/docs-for-v2.0.x
|
||||
---
|
||||
|
||||
>**Note:** This section describes the pipeline feature as implemented in Rancher v2.0.x. If you are using Rancher v2.1 or later, where pipelines have been significantly improved, please refer to the new documentation for [v2.1 or later]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines).
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: Pod Security Policies
|
||||
weight: 5600
|
||||
---
|
||||
|
||||
> These cluster options are only available for [clusters in which Rancher has launched Kubernetes]({{< baseurl >}}/rancher/v2.x/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.x/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 [Existing Cluster: Adding a Pod Security Policy]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/editing-clusters/#adding-changing-a-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 **Vertical Ellipsis (...) > 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.
|
||||
@@ -8,14 +8,46 @@ aliases:
|
||||
|
||||
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.x/en/cluster-provisioning/cluster-members/) instead.
|
||||
|
||||
There are two contexts where you can add project members:
|
||||
### Adding Members to a New Project
|
||||
|
||||
- [Adding Members when Creating New Projects]({{< baseurl >}}/rancher/v2.x/en/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.]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/)
|
||||
|
||||
You can add members to a project as you create it (recommended if possible).
|
||||
### Adding Members to an Existing Project
|
||||
|
||||
- [Adding Members to an Existing Project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/)
|
||||
Following project creation, you can add users as project members so that they can access its resources.
|
||||
|
||||
You can always add members to a project later.
|
||||
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.x/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.
|
||||
>
|
||||
>- 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.x/en/admin-settings/rbac/default-custom-roles).
|
||||
> - To remove roles from the list, [Lock/Unlock Roles]({{< baseurl >}}/rancher/v2.x/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.
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Resource Quotas
|
||||
title: Project Resource Quotas
|
||||
weight: 2515
|
||||
aliases:
|
||||
- /rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/
|
||||
@@ -9,107 +9,40 @@ _Available as of v2.1.0_
|
||||
|
||||
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.
|
||||
|
||||
## Resource Quotas in Rancher
|
||||
This page is a how-to guide for creating resource quotas in existing 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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#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.x/en/cluster-admin/projects-and-namespaces/#creating-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.
|
||||
> 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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects). For details on how resource quotas work with projects in Rancher, refer to [this page.](./quotas-for-projects)
|
||||
|
||||
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.
|
||||
### Applying Resource Quotas to Existing Projects
|
||||
|
||||
<sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
|
||||
|
||||
_Available as of v2.0.1_
|
||||
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), 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](#overriding-the-default-limit-for-a-namespace).
|
||||
Edit [resource quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) when:
|
||||
|
||||
The resource quota includes two limits, which you set while creating or editing a project:
|
||||
<a id="project-limits"></a>
|
||||
- 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.
|
||||
|
||||
- **Project Limits:**
|
||||
1. From the **Global** view, open the cluster containing the project to which you want to apply a resource quota.
|
||||
|
||||
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.
|
||||
1. From the main menu, select **Projects/Namespaces**.
|
||||
|
||||
- **Namespace Default Limits:**
|
||||
1. Find the project that you want to add a resource quota to. From that project, select **Ellipsis (...) > Edit**.
|
||||
|
||||
This value is the default resource limit available for each namespace. When the resource quota is set on 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](#namespace-default-limit-overrides).
|
||||
1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas.
|
||||
|
||||
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`).
|
||||
1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/#resource-quota-types).
|
||||
|
||||
<sup>Rancher: Resource Quotas Propagating to Each Namespace</sup>
|
||||
|
||||
1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
|
||||
|
||||
The following table explains the key differences between the two quota types.
|
||||
| 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. |
|
||||
|
||||
| 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.
|
||||
1. **Optional:** Add more quotas.
|
||||
|
||||
1. Click **Create**.
|
||||
|
||||
## Creating Resource Quotas
|
||||
|
||||
You can create resource quotas in the following contexts:
|
||||
|
||||
- [While creating projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#creating-projects)
|
||||
- [While editing projects]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/editing-projects/#editing-resource-quotas)
|
||||
|
||||
## Resource Quota Types
|
||||
|
||||
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. As of v2.2.0, a [container default resource limit](#setting-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.
|
||||
|
||||
## Overriding the Default Limit for a Namespace
|
||||
|
||||
Although the **Namespace Default Limit** propagates from the project to each namespace, in some cases, you may need to increase (or decrease) the performance 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 performs better. Therefore, the administrator [raises the namespace limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) 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.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas)
|
||||
|
||||
### 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.x/en/project-admin/namespaces/#editing-namespace-resource-quota/).
|
||||
|
||||
## Setting Container Default Resource Limit
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
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.
|
||||
|
||||
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:** Prior to v2.2.0, you could not launch catalog applications that did not have any limits set. With v2.2.0, you will be able to 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.
|
||||
|
||||
| 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.
|
||||
**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, Rancher won't let you save your changes.
|
||||
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
---
|
||||
title: Setting Container Default Resource Limits
|
||||
weight: 3
|
||||
---
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
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
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
Edit [container default resource limit]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#setting-container-default-resource-limit) 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 **Ellipsis (...) > 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.
|
||||
|
||||
> **Note:** Prior to 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.
|
||||
|
||||
### 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.
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
---
|
||||
title: Overriding the Default Limit for a Namespace
|
||||
weight: 2
|
||||
---
|
||||
|
||||
Although the **Namespace Default Limit** propagates from the project to each namespace, in some cases, you may need to increase (or decrease) the performance 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 performs better. Therefore, the administrator [raises the namespace limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas) 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.x/en/k8s-in-rancher/projects-and-namespaces/#editing-namespace-resource-quotas)
|
||||
|
||||
### Editing Namespace Resource Quotas
|
||||
|
||||
If there is a [resource quota]({{< baseurl >}}/rancher/v2.x/en/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.
|
||||
|
||||
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 **Ellipsis (...) > 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 Quota Types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
|
||||
|
||||
>**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:** The namespace's default resource quota is overwritten with your override.
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: Resource Quota Type Reference
|
||||
weight: 4
|
||||
---
|
||||
|
||||
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. As of v2.2.0, a [container default resource limit](#setting-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.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
title: How Resource Quotas Work in Rancher Projects
|
||||
weight: 1
|
||||
---
|
||||
|
||||
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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#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]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), 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](#overriding-the-default-limit-for-a-namespace).
|
||||
|
||||
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 set on 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](#namespace-default-limit-overrides).
|
||||
|
||||
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`).
|
||||
|
||||
<sup>Rancher: Resource Quotas Propagating to Each Namespace</sup>
|
||||
|
||||
|
||||
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.
|
||||
@@ -1,76 +1,41 @@
|
||||
---
|
||||
title: Configuring Tools
|
||||
title: Tools for Logging, Monitoring, and Visibility
|
||||
weight: 2525
|
||||
---
|
||||
|
||||
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 -->
|
||||
|
||||
- [Alerts](#alerts)
|
||||
- [Notifiers and Alerts](#notifiers-and-alerts)
|
||||
- [Logging](#logging)
|
||||
- [Pipelines](#pipelines)
|
||||
- [Monitoring](#monitoring)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
## Alerts
|
||||
## Notifiers and Alerts
|
||||
|
||||
To keep your clusters and applications healthy and driving your organizational productivity forward, you need stay informed of events occurring in your clusters, both planned and unplanned. To help you stay informed of these events, Rancher allows you to configure alerts.
|
||||
Notifiers and alerts are two features that work together to inform you of events in the Rancher system.
|
||||
|
||||
_Alerts_ are sets of rules, chosen by you, to monitor for specific events. The scope for alerts can be set at either the cluster or project level.
|
||||
[Notifiers]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/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.
|
||||
|
||||
Some examples of alert events are:
|
||||
|
||||
- A Kubernetes [master component]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/#kubernetes-cluster-node-components) entering an unhealthy state.
|
||||
- A node or [workload]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/workloads/) error occurring.
|
||||
- A scheduled deployment taking place as planned.
|
||||
- A node's hardware resources becoming overstressed.
|
||||
|
||||
When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions.
|
||||
|
||||
Additionally, you can set an urgency level for each alert. This urgency appears in the notification you receive, helping you to prioritize your response actions. For example, if you have an alert configured to inform you of a routine deployment, no action is required. These alerts can be assigned a low priority level. However, if a deployment fails, it can critically impact your organization, and you need to react quickly. Assign these alerts a high priority level.
|
||||
|
||||
You can configure alerts at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/alerts/).
|
||||
[Alerts]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/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
|
||||
|
||||
Rancher can integrate with popular external services used for event streams, telemetry, or search. Rancher can integrate with the following services:
|
||||
Logging is helpful because it allows you to:
|
||||
|
||||
- Elasticsearch
|
||||
- splunk
|
||||
- kafka
|
||||
- syslog
|
||||
- fluentd
|
||||
- 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
|
||||
|
||||
These services collect container log events, which are saved to the `/var/log/containers` directory on each of your nodes. The service collects both standard and error events. You can then log into your services to review the events collected, leveraging each service's unique features.
|
||||
Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.
|
||||
|
||||
When configuring Rancher to integrate with these services, you'll have to point Rancher toward the service's endpoint and provide authentication information. Additionally, you'll have the opportunity to enter key value pairs to filter the log events collected. The service will only collect events for containers marked with your configured key value pairs.
|
||||
|
||||
You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/logging/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/logging/).
|
||||
|
||||
## Pipelines
|
||||
|
||||
Using Rancher, you can integrate with a GitHub repository to setup a continuous integration (CI) pipeline.
|
||||
|
||||
To set up a pipeline, you'll first need to authorize Rancher using your GitHub settings. Directions are provided in the Rancher UI. After authorizing Rancher in GitHub, provide Rancher with a client ID and secret to authenticate.
|
||||
|
||||
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 more information, see [Pipelines]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/pipelines/).
|
||||
For details, refer to the [logging section.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/logging)
|
||||
|
||||
## Monitoring
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
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. Prometheus provides a _time series_ of your data, which is a stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster.
|
||||
|
||||
In other words, Prometheus let's you view metrics from your different Rancher and Kubernetes objects. Using timestamps, you can query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported.
|
||||
|
||||
You can configure these services to collect logs at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) or [project level]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/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.x/en/cluster-admin/tools/monitoring)
|
||||
|
||||
@@ -3,11 +3,13 @@ title: Alerts
|
||||
weight: 2526
|
||||
---
|
||||
|
||||
To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. To help you stay informed of these events, you can configure alerts.
|
||||
To keep your clusters and applications healthy and driving your organizational productivity forward, you need to stay informed of events occurring in your clusters and projects, both planned and unplanned. When an event occurs, your alert is triggered, and you are sent a notification. You can then, if necessary, follow up with corrective actions.
|
||||
|
||||
Alerts are sets of rules, chosen by you, to monitor for specific events.
|
||||
Notifiers and alerts are built on top of the [Prometheus Alertmanager](https://prometheus.io/docs/alerting/alertmanager/). Leveraging these tools, Rancher can notify [cluster owners]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address.
|
||||
|
||||
Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can manage project alerts.
|
||||
Before you can receive alerts, one or more [notifier]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/notifiers) must be configured at the cluster level.
|
||||
|
||||
Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{<baseurl>}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can manage project alerts.
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
@@ -18,7 +20,7 @@ This section covers the following topics:
|
||||
|
||||
## Alerts Scope
|
||||
|
||||
The scope for alerts can be set at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or project level.
|
||||
The scope for alerts can be set at either the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/alerts/) or project level.
|
||||
|
||||
At the project level, Rancher monitors specific deployments and sends alerts for:
|
||||
|
||||
@@ -29,7 +31,7 @@ At the project level, Rancher monitors specific deployments and sends alerts for
|
||||
|
||||
## Default Project-level Alerts
|
||||
|
||||
When you enable monitoring for the project, some project-level alerts are provided.
|
||||
When you enable monitoring for the project, some project-level alerts are provided. You can receive these alerts if a [notifier]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/notifiers) for them is configured at the cluster level.
|
||||
|
||||
| Alert | Explanation |
|
||||
|-------|-------------|
|
||||
|
||||
@@ -5,6 +5,8 @@ weight: 2527
|
||||
|
||||
Rancher can integrate with a variety of popular logging services and tools that exist outside of your Kubernetes clusters.
|
||||
|
||||
For background information about how logging integrations work, refer to the [cluster administration section.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/logging/#how-logging-integrations-work)
|
||||
|
||||
Rancher supports the following services:
|
||||
|
||||
- Elasticsearch
|
||||
|
||||
@@ -5,15 +5,19 @@ weight: 2528
|
||||
|
||||
_Available as of v2.2.4_
|
||||
|
||||
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. Prometheus provides a _time series_ of your data, which is, according to [Prometheus documentation](https://prometheus.io/docs/concepts/data_model/):
|
||||
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.
|
||||
|
||||
>A stream of timestamped values belonging to the same metric and the same set of labeled dimensions, along with comprehensive statistics and metrics of the monitored cluster.
|
||||
> For more information about how Prometheus works, refer to the [cluster administration section.]({{<baseurl>}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#about-prometheus)
|
||||
|
||||
In other words, Prometheus lets you view metrics from your different Rancher and Kubernetes objects. Using timestamps, Prometheus lets you query and view these metrics in easy-to-read graphs and visuals, either through the Rancher UI or [Grafana](https://grafana.com/), which is an analytics viewing platform deployed along with Prometheus. By viewing data that Prometheus scrapes from your cluster control plane, nodes, and deployments, you can stay on top of everything happening in your cluster. You can then use these analytics to better run your organization: stop system emergencies before they start, develop maintenance strategies, restore crashed servers, etc. Multi-tenancy support in terms of cluster and project-only Prometheus instances are also supported.
|
||||
This section covers the following topics:
|
||||
|
||||
Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can configure project level monitoring. Project members can only view monitoring metrics.
|
||||
- [Monitoring scope](#monitoring-scope)
|
||||
- [Permissions to configure project monitoring](#permissions-to-configure-project-monitoring)
|
||||
- [Configuring project monitoring](#configuring-project-monitoring)
|
||||
- [Project-level monitoring resource requirements](#project-level-monitoring-resource-requirements)
|
||||
- [Project metrics](#project-metrics)
|
||||
|
||||
## Monitoring Scope
|
||||
### Monitoring Scope
|
||||
|
||||
Using Prometheus, you can monitor Rancher at both the [cluster level]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) and project level. For each cluster and project that is enabled for monitoring, Rancher deploys a Prometheus server.
|
||||
|
||||
@@ -25,7 +29,11 @@ Using Prometheus, you can monitor Rancher at both the [cluster level]({{< baseur
|
||||
|
||||
- Project monitoring allows you to view the state of pods running in a given project. Prometheus collects metrics from the project's deployed HTTP and TCP/UDP workloads.
|
||||
|
||||
## Configuring Project Monitoring
|
||||
### Permissions to Configure Project Monitoring
|
||||
|
||||
Only [administrators]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/cluster-project-roles/#project-roles) can configure project level monitoring. Project members can only view monitoring metrics.
|
||||
|
||||
### Configuring Project Monitoring
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure project monitoring.
|
||||
|
||||
@@ -35,7 +43,7 @@ Using Prometheus, you can monitor Rancher at both the [cluster level]({{< baseur
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
### Project Level Monitoring Resource Requirements
|
||||
### Project-Level Monitoring Resource Requirements
|
||||
|
||||
Container| CPU - Request | Mem - Request | CPU - Limit | Mem - Limit | Configurable
|
||||
---------|---------------|---------------|-------------|-------------|-------------
|
||||
@@ -45,14 +53,11 @@ Grafana | 100m | 100Mi | 200m | 200Mi | No
|
||||
|
||||
**Result:** A single application,`project-monitoring`, is added as an [application]({{< baseurl >}}/rancher/v2.x/en/catalog/apps/) to the project. After the application is `active`, you can start viewing [project metrics](#project-metrics) through the [Rancher dashboard]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#rancher-dashboard) or directly from [Grafana]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/#grafana).
|
||||
|
||||
## Project Metrics
|
||||
### Project Metrics
|
||||
|
||||
If [cluster monitoring]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/) is also enabled for the project, [workload metrics]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/monitoring/cluster-metrics/#workload-metrics) are available for the project.
|
||||
|
||||
You can monitor custom metrics from any [exporters](https://prometheus.io/docs/instrumenting/exporters/) as long as project monitoring is enabled. You can also expose some custom endpoints on deployments without needing to configure Prometheus for your project.
|
||||
|
||||
### Example
|
||||
|
||||
A [Redis](https://redis.io/) application is deployed in the namespace `redis-app` in the project `Datacenter`. It is monitored via [Redis exporter](https://github.com/oliver006/redis_exporter).
|
||||
|
||||
After enabling project monitoring, you can edit the application to configure the **Advanced Options -> Custom Metrics** section. Enter the `Container Port` and `Path` and select the `Protocol`.
|
||||
> **Example:**
|
||||
> A [Redis](https://redis.io/) application is deployed in the namespace `redis-app` in the project `Datacenter`. It is monitored via [Redis exporter](https://github.com/oliver006/redis_exporter). After enabling project monitoring, you can edit the application to configure the <b>Advanced Options -> Custom Metrics</b> section. Enter the `Container Port` and `Path` and select the `Protocol`.
|
||||
|
||||
Reference in New Issue
Block a user