Illumina Innovates with Rancher and Kubernetes
Projects are organizational objects introduced in Rancher that ease the administrative burden of your cluster. You can use projects to support multi-tenancy.
Projects provide an extra level of organization in your Kubernetes clusters beyond namespaces. In terms of hierarchy:
Within Rancher, projects allow you manage multiple namespaces as a single entity. In the base version of 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 namespace.
You can use projects to perform actions like:
When you create a cluster, two project are automatically created within it:
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.
default
Available as of v2.0.7
When troubleshooting, you can view the system project to check if important namespaces in the Kubernetes system are working properly. This easily accessible project saves you from troubleshooting individual system namespace containers.
system
To open it, open the Global menu, and then select the system project for your cluster.
The system project:
v3/settings/system-namespaces
Note: In clusters where both: The Canal network plug-in is in use. The Project Network Isolation option is enabled. The system project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health.
Note: In clusters where both:
The system project overrides the Project Network Isolation option so that it can communicate with other projects, collect logs, and check health.
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.
Rancher extends Kubernetes to allow the application of Pod Security Policies 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.
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.
From the main menu, choose Projects/Namespaces. Then click Add Project.
Enter a Project Name.
Optional: Select a Pod Security Policy. Assigning a PSP to a project will:
Note: This option is only available if you’ve already created a Pod Security Policy. For instruction, see Creating Pod Security Policies.
Recommended: Add project members.
Use the Members section to provide other users with project access and roles.
By default, your user is added as the project Owner.
Owner
Click Add Member.
From the Name combo box, search for a user or group that you want to assign project access.
Note: You can only search for groups if external authentication is enabled.
From the Role drop-down, choose a role.
What are 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, 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. Choose Custom to create a custom role on the fly: Custom 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, 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.
Member
namespace creation
Read Only
Choose Custom to create a custom role on the fly: Custom Project Roles.
Custom
To add more members, repeat substeps a—c.
Optional: Add Resource Quotas, which limit the resources that a project (and its namespaces) can consume. For more information, see Resource Quotas.
Note: This option is available as of v2.1.0.
Click Add Quota.
Select a Resource Type.
Enter values for the Project Limit and the Namespace Default Limit.
Optional: Repeat these substeps to add more quotas.
Optional: Specify Container Default Resource Limit, which will be applied to every container started in the project. The parameter is recommended if you have CPU or Memory limits set by the Resource Quota. It can be overridden on per an individual namespace or a container level. For more information, see Container Default Resource Limit >Note: This option is available as of v2.2.0.
Click Create.
Result: Your project is created. You can view it from the cluster’s Projects/Namespaces view.
To switch between clusters and projects, use the Global drop-down available in the main menu.
Alternatively, you can switch between projects and clusters using the main menu.
Within Rancher, you can further divide projects into different 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 can 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:
Note: Although you can assign role-based access to namespaces in the base version of Kubernetes, you cannot assign roles to namespaces in Rancher. Instead, assign role-based access at the project level.
For more information, see Namespaces.