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

Fix tables of contents, headers and formatting

Browse Source
This commit is contained in:
Catherine Luse
2022-09-10 00:26:51 -07:00
parent 11ebb7d341
commit 5fdfa52386
336 changed files with 1249 additions and 3710 deletions
Download Patch File Download Diff File Expand all files Collapse all files
versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/on-premises-rancher-in-vsphere.md
+5 -10
View File
@@ -9,17 +9,12 @@ aliases:
This guide outlines a reference architecture for installing Rancher on an RKE Kubernetes cluster in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
- [1. Load Balancer Considerations](#1-load-balancer-considerations)
- [2. VM Considerations](#2-vm-considerations)
- [3. Network Considerations](#3-network-considerations)
- [4. Storage Considerations](#4-storage-considerations)
- [5. Backups and Disaster Recovery](#5-backups-and-disaster-recovery)
<figcaption>Solution Overview</figcaption>
![Solution Overview](/img/rancher-on-prem-vsphere.svg)
# 1. Load Balancer Considerations
## 1. Load Balancer Considerations
A load balancer is required to direct traffic to the Rancher workloads residing on the RKE nodes.
@@ -45,7 +40,7 @@ Avoid implementing a software load balancer within the management cluster.
Configure appropriate Firewall / ACL rules to only expose access to Rancher
# 2. VM Considerations
## 2. VM Considerations
### Size the VM's According to Rancher Documentation
@@ -67,7 +62,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.
# 3. Network Considerations
## 3. Network Considerations
### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes
@@ -77,13 +72,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.
# 4. Storage Considerations
## 4. Storage Considerations
### Leverage SSD Drives for ETCD Nodes
ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible.
# 5. Backups and Disaster Recovery
## 5. Backups and Disaster Recovery
### Perform Regular Management Cluster Backups
versioned_docs/version-2.5/reference-guides/best-practices/rancher-server/rancher-deployment-strategy.md
+2 -2
View File
@@ -11,7 +11,7 @@ There are two recommended deployment strategies for a Rancher server that manage
* [Hub and Spoke](#hub-and-spoke-strategy)
* [Regional](#regional-strategy)
# Hub & Spoke Strategy
## Hub & Spoke Strategy
---
In this deployment scenario, there is a single Rancher control plane managing Kubernetes clusters across the globe. The control plane would be run on a high-availability Kubernetes cluster, and there would be impact due to latencies.
@@ -29,7 +29,7 @@ In this deployment scenario, there is a single Rancher control plane managing Ku
* Subject to network latencies.
* If the control plane goes out, global provisioning of new services is unavailable until it is restored. However, each Kubernetes cluster can continue to be managed individually.
# Regional Strategy
## Regional Strategy
---
In the regional deployment model a control plane is deployed in close proximity to the compute nodes.