mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-26 04:58:07 +00:00
Remove unneeded intermediate folders
This commit is contained in:
Billy Tat
@@ -0,0 +1,68 @@
|
||||
---
|
||||
title: Namespaces
|
||||
weight: 2520
|
||||
---
|
||||
|
||||
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.0-v2.4/en/k8s-in-rancher/workloads/)
|
||||
- [Load Balancers/Ingress]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/load-balancers-and-ingress/)
|
||||
- [Service Discovery Records]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/service-discovery/)
|
||||
- [Persistent Volume Claims]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/volumes-and-storage/persistent-volume-claims/)
|
||||
- [Certificates]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/certificates/)
|
||||
- [ConfigMaps]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/configmaps/)
|
||||
- [Registries]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/registries/)
|
||||
- [Secrets]({{<baseurl>}}/rancher/v2.0-v2.4/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.0-v2.4/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.0-v2.4/en/k8s-in-rancher/workloads/deploy-workloads/), [certificates]({{<baseurl>}}/rancher/v2.0-v2.4/en/k8s-in-rancher/certificates/), [ConfigMaps]({{<baseurl>}}/rancher/v2.0-v2.4/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.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/resource-quotas) in effect, you can override the default resource **Limits** (which places a cap on the resources that the namespace can consume).
|
||||
|
||||
1. 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.0-v2.4/en/k8s-in-rancher/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.0-v2.4/en/project-admin//resource-quotas/override-namespace-default/).
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
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.0-v2.4/en/concepts/ci-cd-pipelines/
|
||||
- /rancher/v2.0-v2.4/en/tasks/pipelines/
|
||||
- /rancher/v2.0-v2.4/en/tools/pipelines/configurations/
|
||||
---
|
||||
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.0-v2.4/en/k8s-in-rancher/pipelines) section.
|
||||
+31
@@ -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.0-v2.4/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.0-v2.4/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.0-v2.4/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.0-v2.4/en/project-admin/editing-projects/
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/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.
|
||||
|
||||
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.0-v2.4/en/project-admin/project-members)
|
||||
- Assign users [specific roles in a project]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#project-roles). A role can be owner, member, read-only, or [custom]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/default-custom-roles/)
|
||||
- [Set resource quotas]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/resource-quotas/)
|
||||
- [Manage namespaces]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/namespaces/)
|
||||
- [Configure tools]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/tools/)
|
||||
- [Set up pipelines for continuous integration and deployment]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/pipelines)
|
||||
- [Configure pod security policies]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/pod-security-policies)
|
||||
|
||||
### Authorization
|
||||
|
||||
Non-administrative users are only authorized for project access after an [administrator]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/), [cluster owner or member]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owner]({{<baseurl>}}/rancher/v2.0-v2.4/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.0-v2.4/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,55 @@
|
||||
---
|
||||
title: Adding Users to Projects
|
||||
weight: 2505
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/tasks/projects/add-project-members/
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/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.0-v2.4/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.0-v2.4/en/k8s-in-rancher/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.0-v2.4/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.0-v2.4/en/admin-settings/rbac/default-custom-roles).
|
||||
> - To remove roles from the list, [Lock/Unlock Roles]({{<baseurl>}}/rancher/v2.0-v2.4/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.
|
||||
+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.0-v2.4/en/k8s-in-rancher/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.
|
||||
|
||||
> **Note:** Before v2.2.0, you could not launch catalog applications that did not have any limits set. With v2.2.0, you can set a default container resource limit on a project and launch any catalog applications.
|
||||
|
||||
Once a container default resource limit is configured on a namespace, the default will be pre-populated for any containers created in that namespace. These limits/reservations can always be overridden during workload creation.
|
||||
|
||||
### 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 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.0-v2.4/en/k8s-in-rancher/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.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/)
|
||||
|
||||
### Editing Namespace Resource Quotas
|
||||
|
||||
If there is a [resource quota]({{<baseurl>}}/rancher/v2.0-v2.4/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 **⋮ > 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.0-v2.4/en/k8s-in-rancher/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.
|
||||
+24
@@ -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 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.
|
||||
+41
@@ -0,0 +1,41 @@
|
||||
---
|
||||
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.
|
||||
|
||||
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,48 @@
|
||||
---
|
||||
title: Project Resource Quotas
|
||||
weight: 2515
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/k8s-in-rancher/projects-and-namespaces/resource-quotas
|
||||
---
|
||||
|
||||
_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.
|
||||
|
||||
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.0-v2.4/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
|
||||
|
||||
_Available as of v2.0.1_
|
||||
|
||||
Edit [resource quotas]({{<baseurl>}}/rancher/v2.0-v2.4/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 **⋮ > 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,252 @@
|
||||
---
|
||||
title: Project Alerts
|
||||
weight: 2526
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/project-admin/tools/alerts
|
||||
- /rancher/v2.0-v2.4/en/monitoring-alerting/legacy/alerts/project-alerts
|
||||
- /rancher/v2.0-v2.4/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-alerts/project-alerts
|
||||
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-alerts/project-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.
|
||||
|
||||
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.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles) and [project owners]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#project-roles) of events they need to address.
|
||||
|
||||
Before you can receive alerts, one or more [notifier]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/notifiers) must be configured at the cluster level.
|
||||
|
||||
Only [administrators]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#project-roles) can manage project alerts.
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [Alerts scope](#alerts-scope)
|
||||
- [Default project-level alerts](#default-project-level-alerts)
|
||||
- [Adding project alerts](#adding-project-alerts)
|
||||
- [Managing project alerts](#managing-project-alerts)
|
||||
- [Project Alert Rule Configuration](#project-alert-rule-configuration)
|
||||
- [Pod Alerts](#pod-alerts)
|
||||
- [Workload Alerts](#workload-alerts)
|
||||
- [Workload Selector Alerts](#workload-selector-alerts)
|
||||
- [Metric Expression Alerts](#metric-expression-alerts)
|
||||
|
||||
|
||||
# Alerts Scope
|
||||
|
||||
The scope for alerts can be set at either the [cluster level]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/alerts/) or project level.
|
||||
|
||||
At the project level, Rancher monitors specific deployments and sends alerts for:
|
||||
|
||||
* Deployment availability
|
||||
* Workloads status
|
||||
* Pod status
|
||||
* The Prometheus expression cross the thresholds
|
||||
|
||||
# Default Project-level Alerts
|
||||
|
||||
When you enable monitoring for the project, some project-level alerts are provided. You can receive these alerts if a [notifier]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/notifiers) for them is configured at the cluster level.
|
||||
|
||||
| Alert | Explanation |
|
||||
|-------|-------------|
|
||||
| Less than half workload available | A critical alert is triggered if less than half of a workload is available, based on workloads where the key is `app` and the value is `workload`. |
|
||||
| Memory usage close to the quota | A warning alert is triggered if the workload's memory usage exceeds the memory resource quota that is set for the workload. You can see the memory limit in the Rancher UI if you go to the workload under the **Security & Host Config** tab. |
|
||||
|
||||
For information on other default alerts, refer to the section on [cluster-level alerts.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/alerts/default-alerts)
|
||||
|
||||
# Adding Project Alerts
|
||||
|
||||
>**Prerequisite:** Before you can receive project alerts, you must add a notifier.
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure project alerts for. Select **Tools > Alerts**. In versions before v2.2.0, you can choose **Resources > Alerts**.
|
||||
|
||||
1. Click **Add Alert Group**.
|
||||
|
||||
1. Enter a **Name** for the alert that describes its purpose, you could group alert rules for the different purpose.
|
||||
|
||||
1. Based on the type of alert you want to create, fill out the form. For help, refer to the [configuration](#project-alert-rule-configuration) section below.
|
||||
|
||||
1. Continue adding more alert rules to the group.
|
||||
|
||||
1. Finally, choose the [notifiers]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/notifiers/) that send you alerts.
|
||||
|
||||
- You can set up multiple notifiers.
|
||||
- You can change notifier recipients on the fly.
|
||||
|
||||
1. Click **Create.**
|
||||
|
||||
**Result:** Your alert is configured. A notification is sent when the alert is triggered.
|
||||
|
||||
|
||||
# Managing Project Alerts
|
||||
|
||||
To manage project alerts, browse to the project that alerts you want to manage. Then select **Tools > Alerts**. In versions before v2.2.0, you can choose **Resources > Alerts**. You can:
|
||||
|
||||
- Deactivate/Reactive alerts
|
||||
- Edit alert settings
|
||||
- Delete unnecessary alerts
|
||||
- Mute firing alerts
|
||||
- Unmute muted alerts
|
||||
|
||||
|
||||
# Project Alert Rule Configuration
|
||||
|
||||
- [Pod Alerts](#pod-alerts)
|
||||
- [Workload Alerts](#workload-alerts)
|
||||
- [Workload Selector Alerts](#workload-selector-alerts)
|
||||
- [Metric Expression Alerts](#metric-expression-alerts)
|
||||
|
||||
# Pod Alerts
|
||||
|
||||
This alert type monitors for the status of a specific pod.
|
||||
|
||||
Each of the below sections corresponds to a part of the alert rule configuration section in the Rancher UI.
|
||||
|
||||
### When a
|
||||
|
||||
Select the **Pod** option, and then select a pod from the drop-down.
|
||||
|
||||
### Is
|
||||
|
||||
Select a pod status that triggers an alert:
|
||||
|
||||
- **Not Running**
|
||||
- **Not Scheduled**
|
||||
- **Restarted <x> times within the last <x> Minutes**
|
||||
|
||||
### Send a
|
||||
|
||||
Select the urgency level of the alert. The options are:
|
||||
|
||||
- **Critical**: Most urgent
|
||||
- **Warning**: Normal urgency
|
||||
- **Info**: Least urgent
|
||||
|
||||
Select the urgency level of the alert based on pod state. For example, select **Info** for Job pod which stop running after job finished. However, if an important pod isn't scheduled, it may affect operations, so choose **Critical**.
|
||||
|
||||
### Advanced Options
|
||||
|
||||
By default, the below options will apply to all alert rules within the group.
|
||||
|
||||
You can disable these advanced options when configuring a specific rule.
|
||||
|
||||
- **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
|
||||
- **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
|
||||
- **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
|
||||
|
||||
# Workload Alerts
|
||||
|
||||
This alert type monitors for the availability of a workload.
|
||||
|
||||
Each of the below sections corresponds to a part of the alert rule configuration section in the Rancher UI.
|
||||
|
||||
### When a
|
||||
|
||||
Choose the **Workload** option. Then choose a workload from the drop-down.
|
||||
|
||||
### Is
|
||||
|
||||
Choose an availability percentage using the slider. The alert is triggered when the workload's availability on your cluster nodes drops below the set percentage.
|
||||
|
||||
### Send a
|
||||
|
||||
Select the urgency level of the alert.
|
||||
|
||||
- **Critical**: Most urgent
|
||||
- **Warning**: Normal urgency
|
||||
- **Info**: Least urgent
|
||||
|
||||
Select the urgency level of the alert based on the percentage you choose and the importance of the workload.
|
||||
|
||||
### Advanced Options
|
||||
|
||||
By default, the below options will apply to all alert rules within the group.
|
||||
|
||||
You can disable these advanced options when configuring a specific rule.
|
||||
|
||||
- **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
|
||||
- **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
|
||||
- **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
|
||||
|
||||
# Workload Selector Alerts
|
||||
|
||||
This alert type monitors for the availability of all workloads marked with tags that you've specified.
|
||||
|
||||
Each of the below sections corresponds to a part of the alert rule configuration section in the Rancher UI.
|
||||
|
||||
### When a
|
||||
|
||||
Select the **Workload Selector** option, and then click **Add Selector** to enter the key value pair for a label. If one of the workloads drops below your specifications, an alert is triggered. This label should be applied to one or more of your workloads.
|
||||
|
||||
### Is
|
||||
|
||||
Choose an availability percentage using the slider. The alert is triggered when the workload's availability on your cluster nodes drops below the set percentage.
|
||||
|
||||
### Send a
|
||||
|
||||
Select the urgency level of the alert.
|
||||
|
||||
- **Critical**: Most urgent
|
||||
- **Warning**: Normal urgency
|
||||
- **Info**: Least urgent
|
||||
|
||||
Select the urgency level of the alert based on the percentage you choose and the importance of the workload.
|
||||
|
||||
### Advanced Options
|
||||
|
||||
By default, the below options will apply to all alert rules within the group.
|
||||
|
||||
You can disable these advanced options when configuring a specific rule.
|
||||
|
||||
- **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
|
||||
- **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
|
||||
- **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
|
||||
|
||||
# Metric Expression Alerts
|
||||
_Available as of v2.2.4_
|
||||
|
||||
If you enable [project monitoring]({{<baseurl>}}/rancher/v2.0-v2.4/en/project-admin/tools/#monitoring), this alert type monitors for the overload from Prometheus expression querying.
|
||||
|
||||
Each of the below sections corresponds to a part of the alert rule configuration section in the Rancher UI.
|
||||
|
||||
### When A
|
||||
|
||||
Input or select an **Expression**. The dropdown shows the original metrics from Prometheus, including:
|
||||
|
||||
- [**Container**](https://github.com/google/cadvisor)
|
||||
- [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
|
||||
- **Customize**
|
||||
- [**Project Level Grafana**](http://docs.grafana.org/administration/metrics/)
|
||||
- **Project Level Prometheus**
|
||||
|
||||
### Is
|
||||
|
||||
Choose a comparison.
|
||||
|
||||
- **Equal**: Trigger alert when expression value equal to the threshold.
|
||||
- **Not Equal**: Trigger alert when expression value not equal to the threshold.
|
||||
- **Greater Than**: Trigger alert when expression value greater than to threshold.
|
||||
- **Less Than**: Trigger alert when expression value equal or less than the threshold.
|
||||
- **Greater or Equal**: Trigger alert when expression value greater to equal to the threshold.
|
||||
- **Less or Equal**: Trigger alert when expression value less or equal to the threshold.
|
||||
|
||||
If applicable, choose a comparison value or a threshold for the alert to be triggered.
|
||||
|
||||
### For
|
||||
|
||||
Select a duration for a trigger alert when the expression value crosses the threshold longer than the configured duration.
|
||||
|
||||
### Send a
|
||||
|
||||
Select the urgency level of the alert.
|
||||
|
||||
- **Critical**: Most urgent
|
||||
- **Warning**: Normal urgency
|
||||
- **Info**: Least urgent
|
||||
|
||||
Select the urgency level of the alert based on its impact on operations. For example, an alert triggered when a expression for container memory close to the limit raises above 60% deems an urgency of **Info**, but raised about 95% deems an urgency of **Critical**.
|
||||
|
||||
### Advanced Options
|
||||
|
||||
By default, the below options will apply to all alert rules within the group. You can disable these advanced options when configuring a specific rule.
|
||||
|
||||
- **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
|
||||
- **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
|
||||
- **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
|
||||
+115
@@ -0,0 +1,115 @@
|
||||
---
|
||||
title: Project Logging
|
||||
shortTitle: Project Logging
|
||||
weight: 2527
|
||||
aliases:
|
||||
- /rancher/v2.0-v2.4/en/project-admin/tools/logging
|
||||
- /rancher/v2.0-v2.4/en/logging/legacy/project-logging
|
||||
- /rancher/v2.0-v2.4/en/logging/v2.0.x-v2.4.x/project-logging
|
||||
- /rancher/v2.x/en/logging/v2.0.x-v2.4.x/project-logging/
|
||||
- /rancher/v2.x/en/monitoring-alerting/v2.0.x-v2.4.x/cluster-monitoring/project-monitoring/
|
||||
---
|
||||
|
||||
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.0-v2.4/en/logging/v2.0.x-v2.4.x/cluster-logging/#how-logging-integrations-work)
|
||||
|
||||
Rancher supports the following services:
|
||||
|
||||
- Elasticsearch
|
||||
- Splunk
|
||||
- Kafka
|
||||
- Syslog
|
||||
- Fluentd
|
||||
|
||||
>**Note:** You can only configure one logging service per cluster or per project.
|
||||
|
||||
Only [administrators]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/global-permissions/), [cluster owners or members]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#cluster-roles), or [project owners]({{<baseurl>}}/rancher/v2.0-v2.4/en/admin-settings/rbac/cluster-project-roles/#project-roles) can configure Rancher to send Kubernetes logs to a logging service.
|
||||
|
||||
# Requirements
|
||||
|
||||
The Docker daemon on each node in the cluster should be [configured](https://docs.docker.com/config/containers/logging/configure/) with the (default) log-driver: `json-file`. You can check the log-driver by running the following command:
|
||||
|
||||
```
|
||||
$ docker info | grep 'Logging Driver'
|
||||
Logging Driver: json-file
|
||||
```
|
||||
|
||||
# Advantages
|
||||
|
||||
Setting up a logging service to collect logs from your cluster/project has several advantages:
|
||||
|
||||
- Logs errors and warnings in your Kubernetes infrastructure to a stream. The stream informs you of events like a container crashing, a pod eviction, or a node dying.
|
||||
- Allows you to capture and analyze the state of your cluster and look for trends in your environment using the log stream.
|
||||
- Helps you when troubleshooting or debugging.
|
||||
- Saves your logs to a safe location outside of your cluster, so that you can still access them even if your cluster encounters issues.
|
||||
|
||||
# Logging Scope
|
||||
|
||||
You can configure logging at either cluster level or project level.
|
||||
|
||||
- [Cluster logging]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging/) writes logs for every pod in the cluster, i.e. in all the projects. For [RKE clusters]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-provisioning/rke-clusters), it also writes logs for all the Kubernetes system components.
|
||||
|
||||
- Project logging writes logs for every pod in that particular project.
|
||||
|
||||
Logs that are sent to your logging service are from the following locations:
|
||||
|
||||
- Pod logs stored at `/var/log/containers`.
|
||||
|
||||
- Kubernetes system components logs stored at `/var/lib/rancher/rke/logs/`.
|
||||
|
||||
# Enabling Project Logging
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure project logging.
|
||||
|
||||
1. Select **Tools > Logging** in the navigation bar. In versions before v2.2.0, you can choose **Resources > Logging**.
|
||||
|
||||
1. Select a logging service and enter the configuration. Refer to the specific service for detailed configuration. Rancher supports the following services:
|
||||
|
||||
- [Elasticsearch]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging/elasticsearch/)
|
||||
- [Splunk]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging/splunk/)
|
||||
- [Kafka]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging/kafka/)
|
||||
- [Syslog]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging/syslog/)
|
||||
- [Fluentd]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging/fluentd/)
|
||||
|
||||
1. (Optional) Instead of using the UI to configure the logging services, you can enter custom advanced configurations by clicking on **Edit as File**, which is located above the logging targets. This link is only visible after you select a logging service.
|
||||
|
||||
- With the file editor, enter raw fluentd configuration for any logging service. Refer to the documentation for each logging service on how to setup the output configuration.
|
||||
|
||||
- [Elasticsearch Documentation](https://github.com/uken/fluent-plugin-elasticsearch)
|
||||
- [Splunk Documentation](https://github.com/fluent/fluent-plugin-splunk)
|
||||
- [Kafka Documentation](https://github.com/fluent/fluent-plugin-kafka)
|
||||
- [Syslog Documentation](https://github.com/dlackty/fluent-plugin-remote_syslog)
|
||||
- [Fluentd Documentation](https://docs.fluentd.org/v1.0/articles/out_forward)
|
||||
|
||||
- If the logging service is using TLS, you also need to complete the **SSL Configuration** form.
|
||||
1. Provide the **Client Private Key** and **Client Certificate**. You can either copy and paste them or upload them by using the **Read from a file** button.
|
||||
|
||||
- You can use either a self-signed certificate or one provided by a certificate authority.
|
||||
|
||||
- You can generate a self-signed certificate using an openssl command. For example:
|
||||
|
||||
```
|
||||
openssl req -x509 -newkey rsa:2048 -keyout myservice.key -out myservice.cert -days 365 -nodes -subj "/CN=myservice.example.com"
|
||||
```
|
||||
2. If you are using a self-signed certificate, provide the **CA Certificate PEM**.
|
||||
|
||||
1. (Optional) Complete the **Additional Logging Configuration** form.
|
||||
|
||||
1. **Optional:** Use the **Add Field** button to add custom log fields to your logging configuration. These fields are key value pairs (such as `foo=bar`) that you can use to filter the logs from another system.
|
||||
|
||||
1. Enter a **Flush Interval**. This value determines how often [Fluentd](https://www.fluentd.org/) flushes data to the logging server. Intervals are measured in seconds.
|
||||
|
||||
1. **Include System Log**. The logs from pods in system project and RKE components will be sent to the target. Uncheck it to exclude the system logs.
|
||||
|
||||
1. Click **Test**. Rancher sends a test log to the service.
|
||||
|
||||
> **Note:** This button is replaced with _Dry Run_ if you are using the custom configuration editor. In this case, Rancher calls the fluentd dry run command to validate the configuration.
|
||||
|
||||
1. Click **Save**.
|
||||
|
||||
**Result:** Rancher is now configured to send logs to the selected service. Log into the logging service so that you can start viewing the logs.
|
||||
|
||||
# Related Links
|
||||
|
||||
[Logging Architecture](https://kubernetes.io/docs/concepts/cluster-administration/logging/)
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: Tools for Logging, Monitoring, and More
|
||||
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 -->
|
||||
|
||||
- [Notifiers](#notifiers)
|
||||
- [Alerts](#alerts)
|
||||
- [Logging](#logging)
|
||||
- [Monitoring](#monitoring)
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
# Notifiers
|
||||
|
||||
[Notifiers]({{<baseurl>}}/rancher/v2.0-v2.4/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.
|
||||
|
||||
# Alerts
|
||||
|
||||
[Alerts]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/alerts) are rules that trigger 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.
|
||||
|
||||
For details on project-level alerts, see [this page.](./project-alerts)
|
||||
|
||||
# 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 debug and troubleshoot problems
|
||||
|
||||
Rancher can integrate with Elasticsearch, splunk, kafka, syslog, and fluentd.
|
||||
|
||||
For details on setting up logging at the cluster level, refer to the [logging section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/logging)
|
||||
|
||||
For details on project-level logging, see [this section.](./project-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. For details, refer to the [monitoring section.]({{<baseurl>}}/rancher/v2.0-v2.4/en/cluster-admin/tools/cluster-monitoring)
|
||||
Reference in New Issue
Block a user