mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 12:38:05 +00:00
Merge pull request #1893 from LucasSaintarbor/v2.12.0-rke1-removal-reference-guides-pages
Remove RKE1 references: Reference Guides pages
This commit is contained in:
Billy Tat
+1
-1
@@ -16,4 +16,4 @@ While a managed cluster is disconnected from Rancher, management operations will
|
||||
|
||||
- **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.
|
||||
- **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, RKE2/K3s clusters may rotate certificates on startup if they exceeded their lifetime.
|
||||
|
||||
+1
-3
@@ -30,9 +30,7 @@ Once you have created these _ClusterOutput_ objects, create a _ClusterFlow_ to c
|
||||
|
||||
### Kubernetes Components
|
||||
|
||||
_ClusterFlows_ have the ability to collect logs from all containers on all hosts in the Kubernetes cluster. This works well in cases where those containers are part of a Kubernetes pod; however, RKE containers exist outside of the scope of Kubernetes.
|
||||
|
||||
Currently the logs from RKE containers are collected, but are not able to easily be filtered. This is because those logs do not contain information as to the source container (e.g. `etcd` or `kube-apiserver`).
|
||||
_ClusterFlows_ have the ability to collect logs from all containers on all hosts in the Kubernetes cluster. This works well in cases where those containers are part of a Kubernetes pod.
|
||||
|
||||
A future release of Rancher will include the source container name which will enable filtering of these component logs. Once that change is made, you will be able to customize a _ClusterFlow_ to retrieve **only** the Kubernetes component logs, and direct them to an appropriate output.
|
||||
|
||||
|
||||
-3
@@ -54,9 +54,6 @@ Consider the following recommendations based on your needs:
|
||||
### Make sure nodes are configured correctly for Kubernetes
|
||||
It's important to follow K8s and etcd best practices when deploying your nodes, including disabling swap, double checking you have full network connectivity between all machines in the cluster, using unique hostnames, MAC addresses, and product_uuids for every node, checking that all correct ports are opened, and deploying with ssd backed etcd. More details can be found in the [kubernetes docs](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#before-you-begin) and [etcd's performance op guide](https://etcd.io/docs/v3.5/op-guide/performance/).
|
||||
|
||||
### When using RKE: Back up the Statefile
|
||||
RKE keeps record of the cluster state in a file called `cluster.rkestate`. This file is important for the recovery of a cluster and/or the continued maintenance of the cluster through RKE. Because this file contains certificate material, we strongly recommend encrypting this file before backing up. After each run of `rke up` you should backup the state file.
|
||||
|
||||
### Run All Nodes in the Cluster in the Same Datacenter
|
||||
For best performance, run all three of your nodes in the same geographic datacenter. If you are running nodes in the cloud, such as AWS, run each node in a separate Availability Zone. For example, launch node 1 in us-west-2a, node 2 in us-west-2b, and node 3 in us-west-2c.
|
||||
|
||||
|
||||
+1
-1
@@ -66,7 +66,7 @@ You should remove any remaining legacy apps that appear in the Cluster Manager U
|
||||
|
||||
### Using the Authorized Cluster Endpoint (ACE)
|
||||
|
||||
An [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) (ACE) provides access to the Kubernetes API of Rancher-provisioned RKE, RKE2, and K3s clusters. When enabled, the ACE adds a context to kubeconfig files generated for the cluster. The context uses a direct endpoint to the cluster, thereby bypassing Rancher. This reduces load on Rancher for cases where unmediated API access is acceptable or preferable. See [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) for more information and configuration instructions.
|
||||
An [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) (ACE) provides access to the Kubernetes API of Rancher-provisioned RKE2 and K3s clusters. When enabled, the ACE adds a context to kubeconfig files generated for the cluster. The context uses a direct endpoint to the cluster, thereby bypassing Rancher. This reduces load on Rancher for cases where unmediated API access is acceptable or preferable. See [Authorized Cluster Endpoint](../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) for more information and configuration instructions.
|
||||
|
||||
### Reducing Event Handler Executions
|
||||
|
||||
|
||||
-1
@@ -14,7 +14,6 @@ For information on editing cluster membership, go to [this page.](../../how-to-g
|
||||
|
||||
The cluster configuration options depend on the type of Kubernetes cluster:
|
||||
|
||||
- [RKE Cluster Configuration](rancher-server-configuration/rke1-cluster-configuration.md)
|
||||
- [RKE2 Cluster Configuration](rancher-server-configuration/rke2-cluster-configuration.md)
|
||||
- [K3s Cluster Configuration](rancher-server-configuration/k3s-cluster-configuration.md)
|
||||
- [EKS Cluster Configuration](rancher-server-configuration/eks-cluster-configuration.md)
|
||||
|
||||
-1
@@ -6,7 +6,6 @@ title: Rancher Server Configuration
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/reference-guides/cluster-configuration/rancher-server-configuration"/>
|
||||
</head>
|
||||
|
||||
- [RKE1 Cluster Configuration](rke1-cluster-configuration.md)
|
||||
- [RKE2 Cluster Configuration](rke2-cluster-configuration.md)
|
||||
- [K3s Cluster Configuration](k3s-cluster-configuration.md)
|
||||
- [EKS Cluster Configuration](eks-cluster-configuration.md)
|
||||
|
||||
+1
-41
@@ -32,14 +32,6 @@ One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s i
|
||||
|
||||
|
||||
|
||||
### RKE Kubernetes Cluster Installations
|
||||
|
||||
In an RKE installation, the cluster data is replicated on each of three etcd nodes in the cluster, providing redundancy and data duplication in case one of the nodes fails.
|
||||
|
||||
<figcaption>Architecture of an RKE Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
|
||||
## Recommended Load Balancer Configuration for Kubernetes Installations
|
||||
|
||||
We recommend the following configurations for the load balancer and Ingress controllers:
|
||||
@@ -61,7 +53,7 @@ For the best performance and greater security, we recommend a dedicated Kubernet
|
||||
|
||||
## Recommended Node Roles for Kubernetes Installations
|
||||
|
||||
The below recommendations apply when Rancher is installed on a K3s Kubernetes cluster or an RKE Kubernetes cluster.
|
||||
The below recommendations apply when Rancher is installed on a K3s Kubernetes cluster.
|
||||
|
||||
### K3s Cluster Roles
|
||||
|
||||
@@ -69,38 +61,6 @@ In K3s clusters, there are two types of nodes: server nodes and agent nodes. Bot
|
||||
|
||||
For the cluster running the Rancher management server, we recommend using two server nodes. Agent nodes are not required.
|
||||
|
||||
### RKE Cluster Roles
|
||||
|
||||
If Rancher is installed on an RKE Kubernetes cluster, the cluster should have three nodes, and each node should have all three Kubernetes roles: etcd, controlplane, and worker.
|
||||
|
||||
### Contrasting RKE Cluster Architecture for Rancher Server and for Downstream Kubernetes Clusters
|
||||
|
||||
Our recommendation for RKE node roles on the Rancher server cluster contrasts with our recommendations for the downstream user clusters that run your apps and services.
|
||||
|
||||
Rancher uses RKE as a library when provisioning downstream Kubernetes clusters. Note: The capability to provision downstream K3s clusters will be added in a future version of Rancher.
|
||||
|
||||
For downstream Kubernetes clusters, we recommend that each node in a user cluster should have a single role for stability and scalability.
|
||||
|
||||
|
||||
|
||||
RKE only requires at least one node with each role and does not require nodes to be restricted to one role. However, for the clusters that run your apps, we recommend separate roles for each node so that workloads on worker nodes don't interfere with the Kubernetes master or cluster data as your services scale.
|
||||
|
||||
We recommend that downstream user clusters should have at least:
|
||||
|
||||
- **Three nodes with only the etcd role** to maintain a quorum if one node is lost, making the state of your cluster highly available
|
||||
- **Two nodes with only the controlplane role** to make the master component highly available
|
||||
- **One or more nodes with only the worker role** to run the Kubernetes node components, as well as the workloads for your apps and services
|
||||
|
||||
With that said, it is safe to use all three roles on three nodes when setting up the Rancher server because:
|
||||
|
||||
* It allows one `etcd` node failure.
|
||||
* It maintains multiple instances of the master components by having multiple `controlplane` nodes.
|
||||
* No other workloads than Rancher itself should be created on this cluster.
|
||||
|
||||
Because no additional workloads will be deployed on the Rancher server cluster, in most cases it is not necessary to use the same architecture that we recommend for the scalability and reliability of downstream clusters.
|
||||
|
||||
For more best practices for downstream clusters, refer to the [production checklist](../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/checklist-for-production-ready-clusters/checklist-for-production-ready-clusters.md) or our [best practices guide.](../best-practices/best-practices.md)
|
||||
|
||||
## Architecture for an Authorized Cluster Endpoint (ACE)
|
||||
|
||||
If you are using an [authorized cluster endpoint (ACE),](../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) we recommend creating an FQDN pointing to a load balancer which balances traffic across your nodes with the `controlplane` role.
|
||||
|
||||
+5
-14
@@ -41,7 +41,7 @@ There is one cluster controller and one cluster agent for each downstream cluste
|
||||
- Watches for resource changes in the downstream cluster
|
||||
- Brings the current state of the downstream cluster to the desired state
|
||||
- Configures access control policies to clusters and projects
|
||||
- Provisions clusters by calling the required Docker machine drivers and Kubernetes engines, such as RKE and GKE
|
||||
- Provisions clusters by calling the required Docker machine drivers and Kubernetes engines, such as GKE
|
||||
|
||||
By default, to enable Rancher to communicate with a downstream cluster, the cluster controller connects to the cluster agent. If the cluster agent is not available, the cluster controller can connect to a [node agent](#3-node-agents) instead.
|
||||
|
||||
@@ -62,7 +62,7 @@ The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/do
|
||||
|
||||
An authorized cluster endpoint (ACE) allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.
|
||||
|
||||
> ACE is available on RKE, RKE2, and K3s clusters that are provisioned or registered with Rancher. It's not available on clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
> ACE is available on RKE2 and K3s clusters that are provisioned or registered with Rancher. It's not available on clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
|
||||
There are two main reasons why a user might need the authorized cluster endpoint:
|
||||
|
||||
@@ -178,11 +178,8 @@ If you see an error related to "impersonation" in the UI, pay close attention to
|
||||
|
||||
The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster:
|
||||
|
||||
- `rancher-cluster.yml`: The RKE cluster configuration file.
|
||||
- `kube_config_rancher-cluster.yml`: The Kubeconfig file for the cluster, this file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down.
|
||||
- `rancher-cluster.rkestate`: The Kubernetes cluster state file. This file contains credentials for full access to the cluster. Note: This state file is only created when using RKE v0.2.0 or higher.
|
||||
|
||||
> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
- `config.yaml`: The RKE2 and K3s cluster configuration file.
|
||||
- `rke2.yaml` or `k3s.yaml`: The Kubeconfig file for your RKE2 or K3s cluster. This file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down.
|
||||
|
||||
For more information on connecting to a cluster without the Rancher authentication proxy and other configuration options, refer to the [kubeconfig file](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md) documentation.
|
||||
|
||||
@@ -194,13 +191,7 @@ The tools that Rancher uses to provision downstream user clusters depends on the
|
||||
|
||||
Rancher can dynamically provision nodes in a provider such as Amazon EC2, DigitalOcean, Azure, or vSphere, then install Kubernetes on them.
|
||||
|
||||
Rancher provisions this type of cluster using [RKE](https://github.com/rancher/rke) and [docker-machine.](https://github.com/rancher/machine)
|
||||
|
||||
### Rancher Launched Kubernetes for Custom Nodes
|
||||
|
||||
When setting up this type of cluster, Rancher installs Kubernetes on existing nodes, which creates a custom cluster.
|
||||
|
||||
Rancher provisions this type of cluster using [RKE.](https://github.com/rancher/rke)
|
||||
Rancher provisions this type of cluster using [docker-machine.](https://github.com/rancher/machine)
|
||||
|
||||
### Hosted Kubernetes Providers
|
||||
|
||||
|
||||
-7
@@ -12,7 +12,6 @@ Rancher provides specific security hardening guides for each supported Rancher v
|
||||
|
||||
Rancher uses the following Kubernetes distributions:
|
||||
|
||||
- [**RKE**](https://rancher.com/docs/rke/latest/en/), Rancher Kubernetes Engine, is a CNCF-certified Kubernetes distribution that runs entirely within Docker containers.
|
||||
- [**RKE2**](https://docs.rke2.io/) is a fully conformant Kubernetes distribution that focuses on security and compliance within the U.S. Federal Government sector.
|
||||
- [**K3s**](https://docs.k3s.io/) is a fully conformant, lightweight Kubernetes distribution. It is easy to install, with half the memory requirement of upstream Kubernetes, all in a binary of less than 100 MB.
|
||||
|
||||
@@ -22,12 +21,6 @@ To harden a Kubernetes cluster that's running a distribution other than those li
|
||||
|
||||
Each self-assessment guide is accompanied by a hardening guide. These guides were tested alongside the listed Rancher releases. Each self-assessment guides was tested on a specific Kubernetes version and CIS benchmark version. If a CIS benchmark has not been validated for your Kubernetes version, you can use the existing guides until a guide for your version is added.
|
||||
|
||||
### RKE Guides
|
||||
|
||||
| Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|
||||
|--------------------|-----------------------|-----------------------|------------------|
|
||||
| Kubernetes v1.25/v1.26/v1.27 | CIS v1.7 | [Link](rke1-hardening-guide/rke1-self-assessment-guide-with-cis-v1.7-k8s-v1.25-v1.26-v1.27.md) | [Link](rke1-hardening-guide/rke1-hardening-guide.md) |
|
||||
|
||||
### RKE2 Guides
|
||||
|
||||
| Type | Kubernetes Version | CIS Benchmark Version | Self Assessment Guide | Hardening Guides |
|
||||
|
||||
+1
-1
@@ -25,6 +25,6 @@ If you require such features, combine Layer 7 firewalls with [external authentic
|
||||
You should protect the following ports behind an [external load balancer](../../how-to-guides/new-user-guides/kubernetes-resources-setup/load-balancer-and-ingress-controller/layer-4-and-layer-7-load-balancing.md#layer-4-load-balancer) that has SSL offload enabled:
|
||||
|
||||
- **K3s:** Port 6443, used by the Kubernetes API.
|
||||
- **RKE and RKE2:** Port 6443, used by the Kubernetes API, and port 9345, used for node registration.
|
||||
- **RKE2:** Port 6443, used by the Kubernetes API, and port 9345, used for node registration.
|
||||
|
||||
These ports have TLS SAN certificates which list nodes' public IP addresses. An attacker could use that information to gain unauthorized access or monitor activity on the cluster. Protecting these ports helps mitigate against nodes' public IP addresses being disclosed to potential attackers.
|
||||
|
||||
@@ -59,7 +59,7 @@ Each version of the hardening guide is intended to be used with specific version
|
||||
|
||||
The benchmark self-assessment is a companion to the Rancher security hardening guide. While the hardening guide shows you how to harden the cluster, the benchmark guide is meant to help you evaluate the level of security of the hardened cluster.
|
||||
|
||||
Because Rancher and RKE install Kubernetes services as Docker containers, many of the control verification checks in the CIS Kubernetes Benchmark don't apply. This guide will walk through the various controls and provide updated example commands to audit compliance in Rancher created clusters. The original benchmark documents can be downloaded from the [CIS website](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
This guide walks through the various controls and provide updated example commands to audit compliance in Rancher created clusters. The original benchmark documents can be downloaded from the [CIS website](https://www.cisecurity.org/benchmark/kubernetes/).
|
||||
|
||||
Each version of Rancher's self-assessment guide corresponds to specific versions of the hardening guide, Rancher, Kubernetes, and the CIS Benchmark.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user