diff --git a/docs/reference-guides/prometheus-federator/rbac.md b/docs/reference-guides/prometheus-federator/rbac.md index 47887415d85..8b54ce9559f 100644 --- a/docs/reference-guides/prometheus-federator/rbac.md +++ b/docs/reference-guides/prometheus-federator/rbac.md @@ -2,6 +2,10 @@ title: Role-Based Access Control --- + + + + This section describes the expectations for Role-Based Access Control (RBAC) for Prometheus Federator. As described in the section on [namespaces](../../pages-for-subheaders/prometheus-federator.md#namespaces), Prometheus Federator expects that Project Owners, Project Members, and other users in the cluster with Project-level permissions (e.g. permissions in a certain set of namespaces identified by a single label selector) have minimal permissions in any namespaces except the Project Registration Namespace (which is imported into the project by default) and those that already comprise their projects. Therefore, in order to allow Project Owners to assign specific chart permissions to other users in their Project namespaces, the Helm Project Operator will automatically watch the following bindings: diff --git a/docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md b/docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md index d68f5b9320c..1ece990ff8c 100644 --- a/docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md +++ b/docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md @@ -2,6 +2,10 @@ title: Architecture Recommendations --- + + + + If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters) ## Separation of Rancher and User Clusters diff --git a/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index cc266462e91..497bb53a5b3 100644 --- a/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -2,6 +2,10 @@ title: Communicating with Downstream User Clusters --- + + + + This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services. The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters. diff --git a/docs/reference-guides/rancher-manager-architecture/rancher-server-and-components.md b/docs/reference-guides/rancher-manager-architecture/rancher-server-and-components.md index bb1cf170e7a..e9fec332622 100644 --- a/docs/reference-guides/rancher-manager-architecture/rancher-server-and-components.md +++ b/docs/reference-guides/rancher-manager-architecture/rancher-server-and-components.md @@ -2,6 +2,10 @@ title: Rancher Server and Components --- + + + + The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment. The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service). diff --git a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/architecture-recommendations.md b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/architecture-recommendations.md index 36794f75b40..b7fc1fc46a0 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/architecture-recommendations.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/architecture-recommendations.md @@ -2,6 +2,10 @@ title: Architecture Recommendations --- + + + + Kubernetes cluster. If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the cluster running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters) ## Separation of Rancher and User Clusters diff --git a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index fabdcd6f8b9..e45c9e17140 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -2,6 +2,10 @@ title: Communicating with Downstream User Clusters --- + + + + This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services. The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters. diff --git a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/rancher-server-and-components.md b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/rancher-server-and-components.md index 6bf86ee8d7c..7c22dba7b10 100644 --- a/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/rancher-server-and-components.md +++ b/versioned_docs/version-2.0-2.4/reference-guides/rancher-manager-architecture/rancher-server-and-components.md @@ -2,6 +2,10 @@ title: Rancher Server and Components --- + + + + The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment. The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service). diff --git a/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/architecture-recommendations.md b/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/architecture-recommendations.md index b0a4a11590e..14230cf82dd 100644 --- a/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/architecture-recommendations.md +++ b/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/architecture-recommendations.md @@ -2,6 +2,10 @@ title: Architecture Recommendations --- + + + + Kubernetes cluster. If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters) ## Separation of Rancher and User Clusters diff --git a/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index b676e11d6ee..71a22d20698 100644 --- a/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -2,6 +2,10 @@ title: Communicating with Downstream User Clusters --- + + + + This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services. The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters. diff --git a/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/rancher-server-and-components.md b/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/rancher-server-and-components.md index edb00a9424c..c7092bcec23 100644 --- a/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/rancher-server-and-components.md +++ b/versioned_docs/version-2.5/reference-guides/rancher-manager-architecture/rancher-server-and-components.md @@ -2,6 +2,10 @@ title: Rancher Server and Components --- + + + + The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment. The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service). diff --git a/versioned_docs/version-2.6/reference-guides/prometheus-federator/rbac.md b/versioned_docs/version-2.6/reference-guides/prometheus-federator/rbac.md index 47887415d85..8b54ce9559f 100644 --- a/versioned_docs/version-2.6/reference-guides/prometheus-federator/rbac.md +++ b/versioned_docs/version-2.6/reference-guides/prometheus-federator/rbac.md @@ -2,6 +2,10 @@ title: Role-Based Access Control --- + + + + This section describes the expectations for Role-Based Access Control (RBAC) for Prometheus Federator. As described in the section on [namespaces](../../pages-for-subheaders/prometheus-federator.md#namespaces), Prometheus Federator expects that Project Owners, Project Members, and other users in the cluster with Project-level permissions (e.g. permissions in a certain set of namespaces identified by a single label selector) have minimal permissions in any namespaces except the Project Registration Namespace (which is imported into the project by default) and those that already comprise their projects. Therefore, in order to allow Project Owners to assign specific chart permissions to other users in their Project namespaces, the Helm Project Operator will automatically watch the following bindings: diff --git a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/architecture-recommendations.md b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/architecture-recommendations.md index 0440180b112..8940a45f8c1 100644 --- a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/architecture-recommendations.md +++ b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/architecture-recommendations.md @@ -2,6 +2,10 @@ title: Architecture Recommendations --- + + + + If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters) ## Separation of Rancher and User Clusters diff --git a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index cc266462e91..497bb53a5b3 100644 --- a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -2,6 +2,10 @@ title: Communicating with Downstream User Clusters --- + + + + This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services. The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters. diff --git a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/rancher-server-and-components.md b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/rancher-server-and-components.md index 7a588ac91b3..9d25e318ee3 100644 --- a/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/rancher-server-and-components.md +++ b/versioned_docs/version-2.6/reference-guides/rancher-manager-architecture/rancher-server-and-components.md @@ -2,6 +2,10 @@ title: Rancher Server and Components --- + + + + The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment. The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service). diff --git a/versioned_docs/version-2.7/reference-guides/prometheus-federator/rbac.md b/versioned_docs/version-2.7/reference-guides/prometheus-federator/rbac.md index 47887415d85..8b54ce9559f 100644 --- a/versioned_docs/version-2.7/reference-guides/prometheus-federator/rbac.md +++ b/versioned_docs/version-2.7/reference-guides/prometheus-federator/rbac.md @@ -2,6 +2,10 @@ title: Role-Based Access Control --- + + + + This section describes the expectations for Role-Based Access Control (RBAC) for Prometheus Federator. As described in the section on [namespaces](../../pages-for-subheaders/prometheus-federator.md#namespaces), Prometheus Federator expects that Project Owners, Project Members, and other users in the cluster with Project-level permissions (e.g. permissions in a certain set of namespaces identified by a single label selector) have minimal permissions in any namespaces except the Project Registration Namespace (which is imported into the project by default) and those that already comprise their projects. Therefore, in order to allow Project Owners to assign specific chart permissions to other users in their Project namespaces, the Helm Project Operator will automatically watch the following bindings: diff --git a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/architecture-recommendations.md b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/architecture-recommendations.md index d68f5b9320c..1ece990ff8c 100644 --- a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/architecture-recommendations.md +++ b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/architecture-recommendations.md @@ -2,6 +2,10 @@ title: Architecture Recommendations --- + + + + If you are installing Rancher on a single node, the main architecture recommendation that applies to your installation is that the node running Rancher should be [separate from downstream clusters.](#separation-of-rancher-and-user-clusters) ## Separation of Rancher and User Clusters diff --git a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md index 3a198c8ea94..cbe6c1c86ca 100644 --- a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md +++ b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md @@ -2,6 +2,10 @@ title: Communicating with Downstream User Clusters --- + + + + This section describes how Rancher provisions and manages the downstream user clusters that run your apps and services. The below diagram shows how the cluster controllers, cluster agents, and node agents allow Rancher to control downstream clusters. diff --git a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/rancher-server-and-components.md b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/rancher-server-and-components.md index bb1cf170e7a..e9fec332622 100644 --- a/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/rancher-server-and-components.md +++ b/versioned_docs/version-2.7/reference-guides/rancher-manager-architecture/rancher-server-and-components.md @@ -2,6 +2,10 @@ title: Rancher Server and Components --- + + + + The majority of Rancher 2.x software runs on the Rancher Server. Rancher Server includes all the software components used to manage the entire Rancher deployment. The figure below illustrates the high-level architecture of Rancher 2.x. The figure depicts a Rancher Server installation that manages two downstream Kubernetes clusters: one created by RKE and another created by Amazon EKS (Elastic Kubernetes Service).