diff --git a/content/rancher/v2.x/en/best-practices/index.md b/content/rancher/v2.x/en/best-practices/_index.md similarity index 94% rename from content/rancher/v2.x/en/best-practices/index.md rename to content/rancher/v2.x/en/best-practices/_index.md index 030a583efb6..c476f4f9d08 100644 --- a/content/rancher/v2.x/en/best-practices/index.md +++ b/content/rancher/v2.x/en/best-practices/_index.md @@ -1,13 +1,9 @@ --- title: Best Practices Guide weight: 1000 - --- -# Best Practices Guide ---- - -The purpose of this site is to consolidate best practices for Rancher implementations. This also includes recommendations to related technologies, such as Kubernetes, Docker, containers, and more. The objective is to improve the outcome of a Rancher implementation using the operational experience of Rancher and its customers. If you have any questions about how these might apply to your use case, please contact your Customer Success Manager or Support. +The purpose of this site is to consolidate best practices for Rancher implementations. This also includes recommendations to related technologies, such as Kubernetes, Docker, containers, and more. The objective is to improve the outcome of a Rancher implementation using the operational experience of Rancher and its customers. If you have any questions about how these might apply to your use case, please contact your Customer Success Manager or Support. Use the navigation bar on the left to find the current best practices for managing and deploying Rancher Server @@ -15,4 +11,4 @@ Additional resources that can be consulted are: Rancher Homepage
Rancher Docs
-Rancher Forum
\ No newline at end of file +Rancher Forum
diff --git a/content/rancher/v2.x/en/best-practices/containers/index.md b/content/rancher/v2.x/en/best-practices/containers/_index.md similarity index 85% rename from content/rancher/v2.x/en/best-practices/containers/index.md rename to content/rancher/v2.x/en/best-practices/containers/_index.md index 88d113d67d5..1d3485be954 100644 --- a/content/rancher/v2.x/en/best-practices/containers/index.md +++ b/content/rancher/v2.x/en/best-practices/containers/_index.md @@ -1,5 +1,5 @@ --- -title: Container Best Practices +title: Container Best Practices weight: 100 --- @@ -9,5 +9,5 @@ Running well built containers can greatly impact the overall performance and sec - If your microservice is a standalone static binary, use a FROM scratch container. This will have the smallest attack surface and smallest image size. - When possible, use a non-privileged user when running processes within your container. While container runtimes provide isolation, vulnerabilities and attacks are still possible. Inadvertent or accidental host mounts can also be impacted if the container is running as root. - Apply CPU and memory limits to your pods. This can help manage the resources on your worker nodes and avoid a malfunctioning microservice from impacting other microservices. -- Also apply CPU and memory requirements to your pods. This is crucial for informing the scheduler which type of compute node your pod needs to be placed on, and ensuring it does not overprovision that node. Without this the scheduler makes assumptions that will likely not be helpful to your application once the cluster experiences load. +- Also apply CPU and memory requirements to your pods. This is crucial for informing the scheduler which type of compute node your pod needs to be placed on, and ensuring it does not over-provision that node. Without this the scheduler makes assumptions that will likely not be helpful to your application once the cluster experiences load. - Set up liveness and readiness probes for your container. Unless your container completely crashes, Kubernetes will not know it's unhealthy unless you create an endpoint or mechanism that can report container status. Alternatively, make sure you container halts and crashes if unhealthy. diff --git a/content/rancher/v2.x/en/best-practices/deployment-strategies/_index.md b/content/rancher/v2.x/en/best-practices/deployment-strategies/_index.md new file mode 100644 index 00000000000..4688b5fcfaf --- /dev/null +++ b/content/rancher/v2.x/en/best-practices/deployment-strategies/_index.md @@ -0,0 +1,46 @@ +--- +title: Rancher Deployment Strategies +weight: 100 +--- + +There are 2 recommended deployment strategies. 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) +* [Regional](#regional) + +## Hub & Spoke +--- + +![Hub and Spoke Deployment]({{< baseurl >}}/img/rancher/bpg/hub-and-spoke.png) + +In this deployment scenario, there is a single Rancher control plane managing Kubernetes clusters across the globe. The control plane would be run in an HA configuration, and there would be impact due to latencies. + +### 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 loosing connectivity to the Rancher control plane. + +### Cons: + +* Subject to network latencies +* If control plane goes out global provisioning of new services is unavailable until restored. However each Kubernetes cluster can continue to be managed individually. + +## Regional +--- + +![Regional Deployment]({{< baseurl >}}/img/rancher/bpg/regional.png) + +In the regional deployment model a control plane is deployed in close proximity to the compute nodes. + +### Pros: + +* Rancher functionality in regions stay operational if a control plane in another region go down. +* Network latency is greatly reduced, improving the performance of functionality in Rancher +* Upgrades of 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. diff --git a/content/rancher/v2.x/en/best-practices/deployment-strategies/hub-and-spoke/index.md b/content/rancher/v2.x/en/best-practices/deployment-strategies/hub-and-spoke/index.md deleted file mode 100644 index af793adbf97..00000000000 --- a/content/rancher/v2.x/en/best-practices/deployment-strategies/hub-and-spoke/index.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Rancher Deployment Strategies -weight: 100 ---- - -## Hub & Spoke ---- -Hub & Spoke deployment - -In this deployment scenario, there is a single Rancher control plane managing Kubernetes clusters across the globe. The control plane would be run in an HA configuration, and there would be impact due to latencies. - -### 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 loosing connectivity to the Rancher control plane. - -### Cons: - -* Subject to network latencies -* If control plane goes out global provisioning of new services is unavailable until restored. However each Kubernetes cluster can continue to be managed indvidually. diff --git a/content/rancher/v2.x/en/best-practices/deployment-strategies/regional/index.md b/content/rancher/v2.x/en/best-practices/deployment-strategies/regional/index.md deleted file mode 100644 index 0e8469bfc19..00000000000 --- a/content/rancher/v2.x/en/best-practices/deployment-strategies/regional/index.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Rancher Deployment Strategies -weight: 100 ---- - -## Regional ---- -Regional deployment - -In the regional deployment model a control plane is deployed in close proximity to the compute nodes. - -### Pros: - -* Rancher functionality in regions stay operational if a control plane in another region go down. -* Network latency is greatly reduced, improving the performance of functionality in Rancher -* Upgrades of 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. \ No newline at end of file diff --git a/content/rancher/v2.x/en/best-practices/deployment-types/index.md b/content/rancher/v2.x/en/best-practices/deployment-types/_index.md similarity index 96% rename from content/rancher/v2.x/en/best-practices/deployment-types/index.md rename to content/rancher/v2.x/en/best-practices/deployment-types/_index.md index 8b086fab0e9..394cf4b92ae 100644 --- a/content/rancher/v2.x/en/best-practices/deployment-types/index.md +++ b/content/rancher/v2.x/en/best-practices/deployment-types/_index.md @@ -6,6 +6,5 @@ weight: 100 For production and any installation deemed as "important" should use a three-node installation. Having multiple Rancher instances running on multiple nodes ensures high availability that cannot be accomplished with a single node environment. It's also strongly recommended to have a "staging" or "pre-production" Rancher HA environment that mirrors your production environment as closely as possible in terms of software and hardware configuration. Also consider the following points for your Rancher HA setup: - 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. - Don't run other workloads / microservices in your Rancher HA cluster. - - Run Rancher HA within the system and hardware requirements as closely as possible. The more you deviate from this, the more risk you take. However metrics-driven capacity planning analysis should be the ultimate guidance for scaling Rancher as published requirements take into account a variety of workload types. You can use the including Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale. + - Run Rancher HA within the system and hardware requirements as closely as possible. The more you deviate from this, the more risk you take. However metrics-driven capacity planning analysis should be the ultimate guidance for scaling Rancher as published requirements take into account a variety of workload types. You can use the including Prometheus and Grafana monitoring framework to establish a baseline for key metrics as you scale. - Don't run Rancher HA in a hosted Kubernetes environment such as GKE, EKS, or AKS. Rancher upgrades and rollbacks are not supported due to etcd snapshot support - diff --git a/content/rancher/v2.x/en/best-practices/management/index.md b/content/rancher/v2.x/en/best-practices/management/_index.md similarity index 94% rename from content/rancher/v2.x/en/best-practices/management/index.md rename to content/rancher/v2.x/en/best-practices/management/_index.md index 78394a88953..cb597805378 100644 --- a/content/rancher/v2.x/en/best-practices/management/index.md +++ b/content/rancher/v2.x/en/best-practices/management/_index.md @@ -3,8 +3,9 @@ title: Rancher & Kubernetes Management weight: 100 --- -Rancher Operating System and Docker -Rancher is container based and can potentially run on any Linux-based operating system. However, only operating systems listed in the requirements documentation (see https://rancher.com/docs/rancher/v2.x/en/installation/requirements/) should be used along with a supported version of Docker. These versions have been most thoroughly tested and can be properly supported by the Rancher Support team. +## Rancher Operating System and Docker + +Rancher is container based and can potentially run on any Linux-based operating system. However, only operating systems listed in the [requirements documentation]({{< baseurl >}}/rancher/v2.x/en/installation/requirements/) should be used along with a supported version of Docker. These versions have been most thoroughly tested and can be properly supported by the Rancher Support team. ## Kubernetes Clusters Rancher allows you to set up numerous combinations of configurations. Some configurations are more appropriate for development and testing, while there are other best practices for production environments for maximum availability and fault tolerance. The following best practices should be followed for production: @@ -17,14 +18,14 @@ Rancher allows you to set up numerous combinations of configurations. Some confi - When possible, use Rancher to provision your Kubernetes cluster rather than importing a cluster. This will ensure the best compatibility and supportability. - Have multiple people in your organization set up calendar reminders for certificate renewal. Rancher provisioned Kubernetes clusters will use certificates that expire in one year. Clusters provisioned by other means may have a longer or shorter expiration. Certificates can be renewed for Rancher provisioned clusters through the user interface. Consider renewing the certificate two weeks to one month in advance. If you have multiple certificates to track, consider using monitoring and alerting mechanisms to tracking certificate expiration. - Closely monitor and scale your nodes as needed. Use the included Prometheus and Grafana options (see “Monitoring” sections of documentation) as a starting point to achieve this. -- Keep your Kubernetes cluster up to date with a recent and supported version. Typically the Kubernetes community will support the current version and previous 3 minor releases (for example, 1.14.x, 1.13.x, 1.12.x, and 1.11.x). Once a new version is released, older version will be EOL'd. Running on an EOL release can be a risk if a security issues are found and patches are not available. The community typically makes minor releases every quarter (3 months). Rancher’s SLA’s are not community dependent but as Kubernetes is a community driven software, the quality of experience will degrade as you get farther away from their supported target. +- Keep your Kubernetes cluster up to date with a recent and supported version. Typically the Kubernetes community will support the current version and previous 3 minor releases (for example, 1.14.x, 1.13.x, 1.12.x, and 1.11.x). Once a new version is released, older version will be EOL'd. Running on an EOL release can be a risk if a security issues are found and patches are not available. The community typically makes minor releases every quarter (3 months). Rancher’s SLA’s are not community dependent but as Kubernetes is a community driven software, the quality of experience will degrade as you get farther away from their supported target. - Run chaoskube or a similar mechanism to randomly kill pods in your test environment. This will test the resiliency of your infrastructure and the ability of Kubernetes to self-heal. It's not recommended to run this in your production environment. -Kubernetes Orchestration -- Rancher's "Add Cluster" UI is preferable for getting started with Kubernetes cluster orchestration or for simple use cases, however for more complex or demanding use cases using a CLI/API driven approach is preferred. Terraform is recommended as the tooling to implement this. Using terraform with version control and a CI/CD environment you can have high assurances of consistency and reliability when deploying Kubernetes clusters. This approach also gives you the most customization options. +Kubernetes Orchestration +- Rancher's "Add Cluster" UI is preferable for getting started with Kubernetes cluster orchestration or for simple use cases, however for more complex or demanding use cases using a CLI/API driven approach is preferred. Terraform is recommended as the tooling to implement this. Using terraform with version control and a CI/CD environment you can have high assurances of consistency and reliability when deploying Kubernetes clusters. This approach also gives you the most customization options. - Rancher maintains a terraform provider for working with Rancher 2.0 Kubernetes called the rancher2 provider. Network Topology - Kubernetes clusters are best served by low-latency networks. This is especially true for the control plane components and etcd where lots of coordination / leader election traffic occurs. Networking between Rancher server and the Kubernetes clusters it manages are more tolerant of latency. -- Limit the use of proxies or load balancers between Rancher server and Kubernetes clusters. As Rancher is maintaining a long-lived web sockets connection, these intermediaries can interfere with the connection lifecycle as they often weren't configured with this use case in mind. +- Limit the use of proxies or load balancers between Rancher server and Kubernetes clusters. As Rancher is maintaining a long-lived web sockets connection, these intermediaries can interfere with the connection lifecycle as they often weren't configured with this use case in mind. ### Rancher Software Updates diff --git a/src/img/rancher/bpg/high-availability-2.png b/src/img/rancher/bpg/high-availability-2.png deleted file mode 100644 index 69875ffa6b2..00000000000 Binary files a/src/img/rancher/bpg/high-availability-2.png and /dev/null differ diff --git a/src/img/rancher/bpg/high-availability.png b/src/img/rancher/bpg/high-availability.png deleted file mode 100644 index 1c6a57ffcdf..00000000000 Binary files a/src/img/rancher/bpg/high-availability.png and /dev/null differ diff --git a/src/img/rancher/bpg/kubernetes.png b/src/img/rancher/bpg/kubernetes.png deleted file mode 100644 index 70576baf127..00000000000 Binary files a/src/img/rancher/bpg/kubernetes.png and /dev/null differ diff --git a/src/img/rancher/bpg/non-critical.png b/src/img/rancher/bpg/non-critical.png deleted file mode 100644 index 8852b5f393c..00000000000 Binary files a/src/img/rancher/bpg/non-critical.png and /dev/null differ diff --git a/src/img/rancher/bpg/proof-of-concept.png b/src/img/rancher/bpg/proof-of-concept.png deleted file mode 100644 index 728b6cb36c8..00000000000 Binary files a/src/img/rancher/bpg/proof-of-concept.png and /dev/null differ diff --git a/src/img/rancher/bpg/hub-and-spoke.png b/static/img/rancher/bpg/hub-and-spoke.png similarity index 100% rename from src/img/rancher/bpg/hub-and-spoke.png rename to static/img/rancher/bpg/hub-and-spoke.png diff --git a/src/img/rancher/bpg/regional.png b/static/img/rancher/bpg/regional.png similarity index 100% rename from src/img/rancher/bpg/regional.png rename to static/img/rancher/bpg/regional.png