mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-28 14:08:55 +00:00
Remove unneeded intermediate folders
This commit is contained in:
Billy Tat
+48
@@ -0,0 +1,48 @@
|
||||
---
|
||||
title: Rancher Deployment Strategy
|
||||
weight: 100
|
||||
aliases:
|
||||
- /rancher/v2.5/en/best-practices/v2.5/rancher-server/deployment-strategies
|
||||
- /rancher/v2.x/en/best-practices/v2.5/rancher-server/deployment-strategies/
|
||||
---
|
||||
|
||||
There are two recommended deployment strategies for a Rancher server that manages downstream Kubernetes clusters. Each one has its own pros and cons. Read more about which one would fit best for your use case:
|
||||
|
||||
* [Hub and Spoke](#hub-and-spoke-strategy)
|
||||
* [Regional](#regional-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.
|
||||
|
||||
{{< img "/img/rancher/bpg/hub-and-spoke.png" "Hub and Spoke Deployment">}}
|
||||
|
||||
### Pros
|
||||
|
||||
* Environments could have nodes and network connectivity across regions.
|
||||
* Single control plane interface to view/see all regions and environments.
|
||||
* Kubernetes does not require Rancher to operate and can tolerate losing connectivity to the Rancher control plane.
|
||||
|
||||
### Cons
|
||||
|
||||
* 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
|
||||
---
|
||||
In the regional deployment model a control plane is deployed in close proximity to the compute nodes.
|
||||
|
||||
{{< img "/img/rancher/bpg/regional.png" "Regional Deployment">}}
|
||||
|
||||
### Pros
|
||||
|
||||
* Rancher functionality in regions stay operational if a control plane in another region goes down.
|
||||
* Network latency is greatly reduced, improving the performance of functionality in Rancher.
|
||||
* Upgrades of the Rancher control plane can be done independently per region.
|
||||
|
||||
### Cons
|
||||
|
||||
* Overhead of managing multiple Rancher installations.
|
||||
* Visibility across global Kubernetes clusters requires multiple interfaces/panes of glass.
|
||||
* Deploying multi-cluster apps in Rancher requires repeating the process for each Rancher server.
|
||||
+40
@@ -0,0 +1,40 @@
|
||||
---
|
||||
title: Tips for Running Rancher
|
||||
weight: 100
|
||||
aliases:
|
||||
- /rancher/v2.5/en/best-practices/deployment-types
|
||||
- /rancher/v2.5/en/best-practices/v2.5/rancher-server/deployment-types
|
||||
- /rancher/v2.x/en/best-practices/v2.5/rancher-server/deployment-types/
|
||||
---
|
||||
|
||||
This guide is geared toward use cases where Rancher is used to manage downstream Kubernetes clusters. The high-availability setup is intended to prevent losing access to downstream clusters if the Rancher server is not available.
|
||||
|
||||
A high-availability Kubernetes installation, defined as an installation of Rancher on a Kubernetes cluster with at least three nodes, should be used in any production installation of Rancher, as well as any installation deemed "important." Multiple Rancher instances running on multiple nodes ensure high availability that cannot be accomplished with a single node environment.
|
||||
|
||||
If you are installing Rancher in a vSphere environment, refer to the best practices documented [here.](../rancher-in-vsphere)
|
||||
|
||||
When you set up your high-availability Rancher installation, consider the following:
|
||||
|
||||
### Run Rancher on a Separate Cluster
|
||||
Don't run other workloads or microservices in the Kubernetes cluster that Rancher is installed on.
|
||||
|
||||
### 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.4/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.
|
||||
|
||||
### Development and Production Environments Should be Similar
|
||||
It's strongly recommended to have a "staging" or "pre-production" environment of the Kubernetes cluster that Rancher runs on. This environment should mirror your production environment as closely as possible in terms of software and hardware configuration.
|
||||
|
||||
### Monitor Your Clusters to Plan Capacity
|
||||
The Rancher server's Kubernetes cluster should run within the [system and hardware requirements]({{<baseurl>}}/rancher/v2.5/en/installation/requirements/) as closely as possible. The more you deviate from the system and hardware requirements, the more risk you take.
|
||||
|
||||
However, metrics-driven capacity planning analysis should be the ultimate guidance for scaling Rancher, because the published requirements take into account a variety of workload types.
|
||||
|
||||
Using Rancher, you can monitor the state and processes of your cluster nodes, Kubernetes components, and software deployments through integration with Prometheus, a leading open-source monitoring solution, and Grafana, which lets you visualize the metrics from Prometheus.
|
||||
|
||||
After you [enable monitoring]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting) in the cluster, you can set up [a notification channel]({{<baseurl>}}/rancher/v2.5/en/monitoring-alerting/) and alerts to let you know if your cluster is approaching its capacity. You can also use the Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale.
|
||||
+94
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: Installing Rancher in a vSphere Environment
|
||||
shortTitle: On-Premises Rancher in vSphere
|
||||
weight: 3
|
||||
aliases:
|
||||
- /rancher/v2.5/en/best-practices/v2.5/rancher-server/rancher-in-vsphere
|
||||
- /rancher/v2.x/en/best-practices/v2.5/rancher-server/rancher-in-vsphere/
|
||||
---
|
||||
|
||||
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>
|
||||
|
||||
|
||||
|
||||
# 1. Load Balancer Considerations
|
||||
|
||||
A load balancer is required to direct traffic to the Rancher workloads residing on the RKE nodes.
|
||||
|
||||
### Leverage Fault Tolerance and High Availability
|
||||
|
||||
Leverage the use of an external (hardware or software) load balancer that has inherit high-availability functionality (F5, NSX-T, Keepalived, etc).
|
||||
|
||||
### Back Up Load Balancer Configuration
|
||||
|
||||
In the event of a Disaster Recovery activity, availability of the Load balancer configuration will expedite the recovery process.
|
||||
|
||||
### Configure Health Checks
|
||||
|
||||
Configure the Load balancer to automatically mark nodes as unavailable if a health check is failed. For example, NGINX can facilitate this with:
|
||||
|
||||
`max_fails=3 fail_timeout=5s`
|
||||
|
||||
### Leverage an External Load Balancer
|
||||
|
||||
Avoid implementing a software load balancer within the management cluster.
|
||||
|
||||
### Secure Access to Rancher
|
||||
|
||||
Configure appropriate Firewall / ACL rules to only expose access to Rancher
|
||||
|
||||
# 2. VM Considerations
|
||||
|
||||
### Size the VM's According to Rancher Documentation
|
||||
|
||||
https://rancher.com/docs/rancher/v2.5/en/installation/requirements/
|
||||
|
||||
### Leverage VM Templates to Construct the Environment
|
||||
|
||||
To facilitate the consistency of Virtual Machines deployed across the environment, consider the use of "Golden Images" in the form of VM templates. Packer can be used to accomplish this, adding greater customization options.
|
||||
|
||||
### Leverage DRS Anti-Affinity Rules (Where Possible) to Separate Rancher Cluster Nodes Across ESXi Hosts
|
||||
|
||||
Doing so will ensure node VM's are spread across multiple ESXi hosts - preventing a single point of failure at the host level.
|
||||
|
||||
### Leverage DRS Anti-Affinity Rules (Where Possible) to Separate Rancher Cluster Nodes Across Datastores
|
||||
|
||||
Doing so will ensure node VM's are spread across multiple datastores - preventing a single point of failure at the datastore level.
|
||||
|
||||
### Configure VM's as Appropriate 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.
|
||||
|
||||
# 3. Network Considerations
|
||||
|
||||
### Leverage Low Latency, High Bandwidth Connectivity Between ETCD Nodes
|
||||
|
||||
Deploy etcd members within a single data center where possible to avoid latency overheads and reduce the likelihood of network partitioning. For most setups, 1Gb connections will suffice. For large clusters, 10Gb connections can reduce the time taken to restore from backup.
|
||||
|
||||
### Consistent IP Addressing for VM's
|
||||
|
||||
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
|
||||
|
||||
### Leverage SSD Drives for ETCD Nodes
|
||||
|
||||
ETCD is very sensitive to write latency. Therefore, leverage SSD disks where possible.
|
||||
|
||||
# 5. Backups and Disaster Recovery
|
||||
|
||||
### Perform Regular Management Cluster Backups
|
||||
|
||||
Rancher stores its data in the ETCD datastore of the Kubernetes cluster it resides on. Like with any Kubernetes cluster, perform frequent, tested backups of this cluster.
|
||||
|
||||
### Back up Rancher Cluster Node VMs
|
||||
|
||||
Incorporate the Rancher management node VM's within a standard VM backup policy.
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
title: Best Practices for the Rancher Server
|
||||
shortTitle: Rancher Server
|
||||
weight: 1
|
||||
aliases:
|
||||
- /rancher/v2.5/en/best-practices/v2.5/rancher-server
|
||||
- /rancher/v2.x/en/best-practices/v2.5/rancher-server/
|
||||
---
|
||||
|
||||
This guide contains our recommendations for running the Rancher server, and is intended to be used in situations in which Rancher manages downstream Kubernetes clusters.
|
||||
|
||||
### Recommended Architecture and Infrastructure
|
||||
|
||||
Refer to this [guide](./deployment-types) for our general advice for setting up the Rancher server on a high-availability Kubernetes cluster.
|
||||
|
||||
### Deployment Strategies
|
||||
|
||||
This [guide](./deployment-strategies) is designed to help you choose whether a regional deployment strategy or a hub-and-spoke deployment strategy is better for a Rancher server that manages downstream Kubernetes clusters.
|
||||
|
||||
### Installing Rancher in a vSphere Environment
|
||||
|
||||
This [guide](./rancher-in-vsphere) outlines a reference architecture for installing Rancher in a vSphere environment, in addition to standard vSphere best practices as documented by VMware.
|
||||
Reference in New Issue
Block a user