public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-05-17 18:37:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

Syncing with main

Browse Source 
Signed-off-by: Sunil Singh <sunil.singh@suse.com>
This commit is contained in:
Sunil Singh
2024-11-07 12:51:04 -08:00
parent 3b847a904f
commit 1584fa9cfc
75 changed files with 641 additions and 519 deletions
Download Patch File Download Diff File Expand all files Collapse all files
versioned_docs/version-2.9/api/workflows/projects.md
+1 -72
View File
@@ -91,77 +91,6 @@ spec:
limitsMemory: 100Mi
requestsCpu: 50m
requestsMemory: 50Mi
EOF
```
## Adding a Member to a Project
Look up the project ID to specify the `metadata.namespace` field and `projectName` field values.
```bash
kubectl --namespace c-m-abcde get projects
```
Look up the role template ID to specify the `roleTemplateName` field value (e.g. `project-member` or `project-owner`).
```bash
kubectl get roletemplates
```
When adding a user member specify the `userPrincipalName` field:
```bash
kubectl create -f - <<EOF
apiVersion: management.cattle.io/v3
kind: ProjectRoleTemplateBinding
metadata:
generateName: prtb-
namespace: p-vwxyz
projectName: c-m-abcde:p-vwxyz
roleTemplateName: project-member
userPrincipalName: keycloak_user://user
EOF
```
When adding a group member specify the `groupPrincipalName` field instead:
```bash
kubectl create -f - <<EOF
apiVersion: management.cattle.io/v3
kind: ProjectRoleTemplateBinding
metadata:
generateName: prtb-
namespace: p-vwxyz
projectName: c-m-abcde:p-vwxyz
roleTemplateName: project-member
groupPrincipalName: keycloak_group://group
EOF
```
Create a projectroletemplatebinding for each role you want to assign to the project member.
## Listing Project Members
Look up the project ID:
```bash
kubectl --namespace c-m-abcde get projects
```
to list projectroletemplatebindings in the project's namespace:
```bash
kubectl --namespace p-vwxyz get projectroletemplatebindings
```
## Deleting a Member From a Project
Lookup the projectroletemplatebinding IDs containing the member in the project's namespace as decribed in the [Listing Project Members](#listing-project-members) section.
Delete the projectroletemplatebinding from the project's namespace:
```bash
kubectl --namespace p-vwxyz delete projectroletemplatebindings prtb-qx874 prtb-7zw7s
```
## Creating a Namespace in a Project
@@ -203,4 +132,4 @@ Delete the project under the cluster namespace:
kubectl --namespace c-m-abcde delete project p-vwxyz
```
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
Note that this command doesn't delete the namespaces and resources that formerly belonged to the project.
versioned_docs/version-2.9/reference-guides/best-practices/rancher-managed-clusters/disconnected-clusters.md
+19
View File
@@ -0,0 +1,19 @@
---
title: Best Practices for Disconnected Clusters
---
<head>
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/best-practices/disconnected-clusters"/>
</head>
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. At the moment there are no known issues with disconnected clusters in the latest released Rancher version.
While a managed cluster is disconnected from Rancher, management operations will be unavailable, and the Rancher UI will not allow navigation to the cluster. However, once the connection is reestablished, functionality is fully restored.
### Best Practices for Managing Disconnected Clusters
- **Cluster Availability During Rancher Upgrades**: It is recommended to have all, or at least most, managed clusters online during a Rancher upgrade. The reason is that upgrading Rancher automatically upgrades the Rancher agent software running on managed clusters. Keeping the agent and Rancher versions aligned ensures consistent functionality. Any clusters that are disconnected during the upgrade will have their agents updated as soon as they reconnect.
- **Cleaning Up Disconnected Clusters**: Regularly remove clusters that will no longer reconnect to Rancher (e.g., clusters that have been decommissioned or destroyed). Keeping such clusters in the Rancher management system consumes unnecessary resources, which could impact Rancher's performance over time.
- **Certificate Rotation Considerations**: When designing processes that involve regularly shutting down clusters, whether connected to Rancher or not, take into account certificate rotation policies. For example, RKE/RKE2/K3s clusters may rotate certificates on startup if they exceeded their lifetime.
versioned_docs/version-2.9/reference-guides/best-practices/rancher-managed-clusters/rancher-managed-clusters.md
+4
View File
@@ -14,6 +14,10 @@ Refer to [this guide](logging-best-practices.md) for our recommendations for clu
Configuring sensible monitoring and alerting rules is vital for running any production workloads securely and reliably. Refer to this [guide](monitoring-best-practices.md) for our recommendations.
### Disconnected clusters
Rancher supports managing clusters that may not always be online due to network disruptions, control plane availability, or because all cluster nodes are down. Refer to this [guide](disconnected-clusters.md) for our recommendations.
### Tips for Setting Up Containers
Running well-built containers can greatly impact the overall performance and security of your environment. Refer to this [guide](tips-to-set-up-containers.md) for tips.