public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-09-26 21:18:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'main' into main-to-release/v2.7

Browse Source
This commit is contained in:
Billy Tat
2022-11-16 10:29:26 -08:00
parent 3597c79a43 c8fd4b6102
commit 421d791dd2
257 changed files with 1947 additions and 1888 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference-guides/backup-restore-configuration/examples.md
+2 -2
View File
@@ -242,7 +242,7 @@ spec:
encryptionConfigSecretName: test-encryptionconfig
```
# Example Credential Secret for Storing Backups in S3
## Example Credential Secret for Storing Backups in S3
```yaml
apiVersion: v1
@@ -255,7 +255,7 @@ data:
secretKey: <Enter your base64-encoded secret key>
```
# Example EncryptionConfiguration
## Example EncryptionConfiguration
The snippet below demonstrates two different types of secrets and their relevance with respect to Backup and Restore of custom resources.
docs/reference-guides/best-practices/rancher-managed-clusters/rancher-managed-clusters-in-vsphere.md
+4 -4
View File
@@ -13,7 +13,7 @@ This guide outlines a reference architecture for provisioning downstream Rancher
![Solution Overview](/img/solution_overview.drawio.svg)
# 1. VM Considerations
## 1. VM Considerations
### Leverage VM Templates to Construct the Environment
@@ -31,7 +31,7 @@ Doing so will ensure node VM's are spread across multiple datastores - preventin
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.
# 2. Network Considerations
## 2. Network Considerations
### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes
@@ -41,13 +41,13 @@ Deploy etcd members within a single data center where possible to avoid latency
Each node used should have a static IP configured. In the case of DHCP, each node should have a DHCP reservation to make sure the node gets the same IP allocated.
# 3. Storage Considerations
## 3. Storage Considerations
### Leverage SSD Drives for ETCD Nodes
ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible.
# 4. Backups and Disaster Recovery
## 4. Backups and Disaster Recovery
### Perform Regular Downstream Cluster Backups
docs/reference-guides/cli-with-rancher/kubectl-utility.md
+1 -1
View File
@@ -2,7 +2,7 @@
title: kubectl Utility
---
# kubectl
## kubectl
Interact with Rancher using kubectl.
docs/reference-guides/rancher-manager-architecture/architecture-recommendations.md
+6 -6
View File
@@ -4,7 +4,7 @@ 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
## Separation of Rancher and User Clusters
A user cluster is a downstream Kubernetes cluster that runs your apps and services.
@@ -14,7 +14,7 @@ If Rancher is intended to manage downstream Kubernetes clusters, the Kubernetes
![Separation of Rancher Server from User Clusters](/img/rancher-architecture-separation-of-rancher-server.svg)
# Why HA is Better for Rancher in Production
## Why HA is Better for Rancher in Production
We recommend installing the Rancher server on a high-availability Kubernetes cluster, primarily because it protects the Rancher server data. In a high-availability installation, a load balancer serves as the single point of contact for clients, distributing network traffic across multiple servers in the cluster and helping to prevent any one server from becoming a point of failure.
@@ -36,7 +36,7 @@ In an RKE installation, the cluster data is replicated on each of three etcd nod
![Architecture of an RKE Kubernetes cluster running the Rancher management server](/img/rke-server-storage.svg)
# Recommended Load Balancer Configuration for Kubernetes Installations
## Recommended Load Balancer Configuration for Kubernetes Installations
We recommend the following configurations for the load balancer and Ingress controllers:
@@ -49,13 +49,13 @@ We recommend the following configurations for the load balancer and Ingress cont
![Rancher HA](/img/ha/rancher2ha.svg)
# Environment for Kubernetes Installations
## Environment for Kubernetes Installations
It is strongly recommended to install Rancher on a Kubernetes cluster on hosted infrastructure such as Amazon's EC2 or Google Compute Engine.
For the best performance and greater security, we recommend a dedicated Kubernetes cluster for the Rancher management server. Running user workloads on this cluster is not advised. After deploying Rancher, you can [create or import clusters](../../pages-for-subheaders/kubernetes-clusters-in-rancher-setup.md) for running your workloads.
# Recommended Node Roles for Kubernetes Installations
## Recommended Node Roles for Kubernetes Installations
The below recommendations apply when Rancher is installed on a K3s Kubernetes cluster or an RKE Kubernetes cluster.
@@ -97,7 +97,7 @@ Because no additional workloads will be deployed on the Rancher server cluster,
For more best practices for downstream clusters, refer to the [production checklist](../../pages-for-subheaders/checklist-for-production-ready-clusters.md) or our [best practices guide.](../../pages-for-subheaders/best-practices.md)
# Architecture for an Authorized Cluster Endpoint (ACE)
## Architecture for an Authorized Cluster Endpoint (ACE)
If you are using an [authorized cluster endpoint (ACE),](../../pages-for-subheaders/rancher-manager-architecture.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.
docs/reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md
+4 -4
View File
@@ -71,11 +71,11 @@ Like the authorized cluster endpoint, the `kube-api-auth` authentication service
> **Example scenario:** Let's say that the Rancher server is located in the United States, and User Cluster 1 is located in Australia. A user, Alice, also lives in Australia. Alice can manipulate resources in User Cluster 1 by using the Rancher UI, but her requests will have to be sent from Australia to the Rancher server in the United States, then be proxied back to Australia, where the downstream user cluster is. The geographical distance may cause significant latency, which Alice can reduce by using the authorized cluster endpoint.
With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`.
With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`.
You will need to use a context defined in this kubeconfig file to access the cluster if Rancher goes down. Therefore, we recommend exporting the kubeconfig file so that if Rancher goes down, you can still use the credentials in the file to access your cluster. For more information, refer to the section on accessing your cluster with [kubectl and the kubeconfig file.](../../how-to-guides/new-user-guides/manage-clusters/access-clusters/use-kubectl-and-kubeconfig.md)
# Important Files
## Important Files
The files mentioned below are needed to maintain, troubleshoot and upgrade your cluster:
@@ -87,7 +87,7 @@ The files mentioned below are needed to maintain, troubleshoot and upgrade your
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.
# Tools for Provisioning Kubernetes Clusters
## Tools for Provisioning Kubernetes Clusters
The tools that Rancher uses to provision downstream user clusters depends on the type of cluster that is being provisioned.
@@ -113,7 +113,7 @@ Rancher provisions this type of cluster using [kontainer-engine.](https://github
In this type of cluster, Rancher connects to a Kubernetes cluster that has already been set up. Therefore, Rancher does not provision Kubernetes, but only sets up the Rancher agents to communicate with the cluster.
# Rancher Server Components and Source Code
## Rancher Server Components and Source Code
This diagram shows each component that the Rancher server is composed of:
docs/reference-guides/system-tools.md
+3 -3
View File
@@ -8,11 +8,11 @@ System Tools has been deprecated since June 2022.
:::
# Logs
## Logs
Please use [logs-collector](https://github.com/rancherlabs/support-tools/tree/master/collection/rancher/v2.x/logs-collector) to collect logs from your cluster.
# Stats
## Stats
If you want to replicate the stats command, you can run the following command on your cluster nodes:
@@ -26,6 +26,6 @@ This command below requires the package `sysstat` on the cluster node.
/usr/bin/sar -u -r -F 1 1
```
# Remove
## Remove
Please use the [Rancher Cleanup](https://github.com/rancher/rancher-cleanup) tool.