mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Fix links and formatting
This commit is contained in:
vickyhella
@@ -68,4 +68,5 @@ The storage controller and replicas are themselves orchestrated using Kubernetes
|
||||
You can learn more about its architecture [here.](https://longhorn.io/docs/latest/concepts/)
|
||||
|
||||
<figcaption>Longhorn Architecture</figcaption>
|
||||
|
||||
|
||||
|
||||
+3
@@ -55,6 +55,7 @@ To see the Alertmanager UI,
|
||||
For more information on configuring Alertmanager in Rancher, see [this page.](../../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/alertmanager.md)
|
||||
|
||||
<figcaption>The Alertmanager UI</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -91,6 +92,7 @@ To see the Prometheus Targets, install `rancher-monitoring`. Then:
|
||||
1. Click **Prometheus Targets**.
|
||||
|
||||
<figcaption>Targets in the Prometheus UI</figcaption>
|
||||
|
||||
|
||||
|
||||
### Viewing the PrometheusRules
|
||||
@@ -107,6 +109,7 @@ To see the PrometheusRules, install `rancher-monitoring`. Then:
|
||||
You can also see the rules in the Prometheus UI:
|
||||
|
||||
<figcaption>Rules in the Prometheus UI</figcaption>
|
||||
|
||||
|
||||
|
||||
For more information on configuring PrometheusRules in Rancher, see [this page.](../../../how-to-guides/advanced-user-guides/monitoring-v2-configuration-guides/advanced-configuration/prometheusrules.md)
|
||||
+2
@@ -165,7 +165,9 @@ To see the Grafana UI, install `rancher-monitoring`. Then:
|
||||
1. Click **Grafana**.
|
||||
|
||||
<figcaption>Cluster Compute Resources Dashboard in Grafana</figcaption>
|
||||
|
||||
|
||||
|
||||
<figcaption>Default Dashboards in Grafana</figcaption>
|
||||
|
||||
|
||||
@@ -82,9 +82,11 @@ The NeuVector security solution contains four types of security containers: Cont
|
||||
- **Updater:** Updates the CVE database for Neuvector (when run); redeploys scanner pods.
|
||||
|
||||
<figcaption>**NeuVector Security Containers:**</figcaption>
|
||||
|
||||
|
||||
|
||||
<figcaption>**NeuVector Architecture:**</figcaption>
|
||||
|
||||
|
||||
|
||||
To learn more about NeuVector's architecture, please refer [here](https://open-docs.neuvector.com/basics/overview#architecture).
|
||||
|
||||
+2
@@ -10,6 +10,7 @@ In a standard Kubernetes deployment, resource quotas are applied to individual n
|
||||
In the following diagram, a Kubernetes administrator is trying to enforce a resource quota without Rancher. The administrator wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The administrator has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually.
|
||||
|
||||
<sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
|
||||
|
||||
|
||||
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the project, and then the quota propagates to each namespace, whereafter Kubernetes enforces your limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can override it.
|
||||
@@ -30,6 +31,7 @@ The resource quota includes two limits, which you set while creating or editing
|
||||
In the following diagram, a Rancher administrator wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the administrator can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`) when created.
|
||||
|
||||
<sup>Rancher: Resource Quotas Propagating to Each Namespace</sup>
|
||||
|
||||
|
||||
|
||||
Let's highlight some more nuanced functionality for namespaces created **_within_** the Rancher UI. If a quota is deleted at the project level, it will also be removed from all namespaces contained within that project, despite any overrides that may exist. Further, updating an existing namespace default limit for a quota at the project level will not result in that value being propagated to existing namespaces in the project; the updated value will only be applied to newly created namespaces in that project. To update a namespace default limit for existing namespaces you can delete and subsequently recreate the quota at the project level with the new default value. This will result in the new default value being applied to all existing namespaces in the project.
|
||||
|
||||
+1
@@ -8,6 +8,7 @@ Although the **Namespace Default Limit** propagates from the project to each nam
|
||||
In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it has more resources available. Therefore, the administrator [raises the namespace limits](../../manage-clusters/projects-and-namespaces.md) for `Namespace 3` so that the namespace can access more resources.
|
||||
|
||||
<sup>Namespace Default Limit Override</sup>
|
||||
|
||||
|
||||
|
||||
How to: [Editing Namespace Resource Quotas](../../manage-clusters/projects-and-namespaces.md)
|
||||
|
||||
+1
-1
@@ -30,7 +30,7 @@ helm repo update
|
||||
helm install rancher-backup-crd rancher-charts/rancher-backup-crd -n cattle-resources-system --create-namespace --version $CHART_VERSION
|
||||
helm install rancher-backup rancher-charts/rancher-backup -n cattle-resources-system --version $CHART_VERSION
|
||||
```
|
||||
<br/>
|
||||
|
||||
For an **air-gapped environment**, use the option below to pull the `backup-restore-operator` image from your private registry when installing the rancher-backup-crd helm chart.
|
||||
```
|
||||
--set image.repository $REGISTRY/rancher/backup-restore-operator
|
||||
|
||||
+1
@@ -21,5 +21,6 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||
|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
@@ -33,7 +33,7 @@ Installing the `rancher-backup` chart by selecting the StorageClass option will
|
||||
|
||||
For information about creating storage classes refer to [this section.](../../how-to-guides/advanced-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/dynamically-provision-new-storage.md)
|
||||
|
||||
::: note Important:
|
||||
:::note Important:
|
||||
|
||||
It is highly recommended to use a StorageClass with a reclaim policy of "Retain". Otherwise if the PVC created by the `rancher-backup` chart gets deleted (either during app upgrade, or accidentally), the PV will get deleted too, which means all backups saved in it will get deleted.
|
||||
If no such StorageClass is available, after the PV is provisioned, make sure to edit its reclaim policy and set it to "Retain" before storing backups in it.
|
||||
|
||||
@@ -26,6 +26,7 @@ We don't recommend installing Rancher in a single Docker container, because if t
|
||||
One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s is Rancher's CNCF certified Kubernetes distribution. It is easy to install and uses half the memory of Kubernetes, all in a binary of less than 100 MB. Another advantage of K3s is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
|
||||
|
||||
<figcaption>Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
|
||||
### RKE Kubernetes Cluster Installations
|
||||
@@ -33,6 +34,7 @@ One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s i
|
||||
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
|
||||
@@ -45,6 +47,7 @@ We recommend the following configurations for the load balancer and Ingress cont
|
||||
* The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Rancher installed on a Kubernetes cluster with layer 4 load balancer, depicting SSL termination at Ingress controllers</figcaption>
|
||||
|
||||
|
||||
|
||||
# Environment for Kubernetes Installations
|
||||
|
||||
+1
@@ -29,6 +29,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx.
|
||||
>**Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.
|
||||
|
||||
<figcaption>Example NGINX config</figcaption>
|
||||
|
||||
```
|
||||
worker_processes 4;
|
||||
worker_rlimit_nofile 40000;
|
||||
|
||||
+1
@@ -23,6 +23,7 @@ This procedure walks you through setting up a 3-node cluster using the Rancher K
|
||||
In an HA setup that uses a layer 4 load balancer, the load balancer accepts Rancher client connections over the TCP/UDP protocols (i.e., the transport level). The load balancer then forwards these connections to individual cluster nodes without reading the request itself. Because the load balancer cannot read the packets it's forwarding, the routing decisions it can make are limited.
|
||||
|
||||
<sup>Rancher installed on a Kubernetes cluster with layer 4 load balancer, depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
|
||||
|
||||
## Installation Outline
|
||||
|
||||
+1
@@ -23,6 +23,7 @@ This procedure walks you through setting up a 3-node cluster using the Rancher K
|
||||
In an HA setup that uses a layer 7 load balancer, the load balancer accepts Rancher client connections over the HTTP protocol (i.e., the application level). This application-level access allows the load balancer to read client requests and then redirect to them to cluster nodes using logic that optimally distributes load.
|
||||
|
||||
<sup>Rancher installed on a Kubernetes cluster with layer 7 load balancer, depicting SSL termination at load balancer</sup>
|
||||
|
||||
|
||||
|
||||
## Installation Outline
|
||||
|
||||
+2
@@ -10,6 +10,7 @@ In a standard Kubernetes deployment, resource quotas are applied to individual n
|
||||
In the following diagram, a Kubernetes administrator is trying to enforce a resource quota without Rancher. The administrator wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The administrator has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually.
|
||||
|
||||
<sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
|
||||
|
||||
|
||||
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the project, and then the quota propagates to each namespace, whereafter Kubernetes enforces your limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can override it.
|
||||
@@ -28,6 +29,7 @@ The resource quota includes two limits, which you set while creating or editing
|
||||
In the following diagram, a Rancher administrator wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the administrator can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`) when created.
|
||||
|
||||
<sup>Rancher: Resource Quotas Propagating to Each Namespace</sup>
|
||||
|
||||
|
||||
|
||||
Let's highlight some more nuanced functionality. If a quota is deleted at the project level, it will also be removed from all namespaces contained within that project, despite any overrides that may exist. Further, updating an existing namespace default limit for a quota at the project level will not result in that value being propagated to existing namespaces in the project; the updated value will only be applied to newly created namespaces in that project. To update a namespace default limit for existing namespaces you can delete and subsequently recreate the quota at the project level with the new default value. This will result in the new default value being applied to all existing namespaces in the project.
|
||||
|
||||
+1
@@ -8,6 +8,7 @@ Although the **Namespace Default Limit** propagates from the project to each nam
|
||||
In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it has more resources available. Therefore, the administrator [raises the namespace limits](../../manage-clusters/projects-and-namespaces.md) for `Namespace 3` so that the namespace can access more resources.
|
||||
|
||||
<sup>Namespace Default Limit Override</sup>
|
||||
|
||||
|
||||
|
||||
How to: [Editing Namespace Resource Quotas](../../manage-clusters/projects-and-namespaces.md)
|
||||
|
||||
+1
@@ -23,6 +23,7 @@ We recommend configuring the database to take recurring snapshots.
|
||||
One main advantage of this K3s architecture is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
|
||||
|
||||
<figcaption>Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
|
||||
### Creating Snapshots and Restoring Databases from Snapshots
|
||||
|
||||
+1
@@ -22,6 +22,7 @@ This section describes how to create backups of your high-availability Rancher i
|
||||
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>Cluster Data within an RKE Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
|
||||
# Requirements
|
||||
|
||||
+1
@@ -21,5 +21,6 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||
|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+1
@@ -67,6 +67,7 @@ Using the v2.x UI, use the context menu to navigate to the `Project` view. Then
|
||||
Click **Add Record** to create new DNS records. Then view the various options supported to link to external services or to create aliases for another workload, DNS record, or set of pods.
|
||||
|
||||
<figcaption>Add Service Discovery Record</figcaption>
|
||||
|
||||
|
||||
|
||||
The following table indicates which alias options are implemented natively by Kubernetes and which options are implemented by Rancher leveraging Kubernetes.
|
||||
|
||||
@@ -21,6 +21,7 @@ This procedure walks you through setting up a 3-node cluster using the Rancher K
|
||||
In a Kubernetes setup that uses a layer 4 load balancer, the load balancer accepts Rancher client connections over the TCP/UDP protocols (i.e., the transport level). The load balancer then forwards these connections to individual cluster nodes without reading the request itself. Because the load balancer cannot read the packets it's forwarding, the routing decisions it can make are limited.
|
||||
|
||||
<sup>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
|
||||
|
||||
<br/>
|
||||
|
||||
@@ -22,6 +22,7 @@ This procedure walks you through setting up a 3-node cluster using the Rancher K
|
||||
In an Kubernetes setup that uses a layer 7 load balancer, the load balancer accepts Rancher client connections over the HTTP protocol (i.e., the application level). This application-level access allows the load balancer to read client requests and then redirect to them to cluster nodes using logic that optimally distributes load.
|
||||
|
||||
<sup>Kubernetes Rancher install with layer 7 load balancer, depicting SSL termination at load balancer</sup>
|
||||
|
||||
|
||||
|
||||
## 1. Provision Linux Hosts
|
||||
|
||||
@@ -28,6 +28,7 @@ This procedure walks you through setting up a 3-node cluster with Rancher Kubern
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||
|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
|
||||
+3
@@ -32,6 +32,7 @@ If you are installing Rancher v2.4 for the first time, we recommend installing i
|
||||
The option to install Rancher on a K3s cluster is a feature introduced in Rancher v2.4. K3s is easy to install, with half the memory of Kubernetes, all in a binary less than 100 MB.
|
||||
|
||||
<figcaption>Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
|
||||
### RKE Kubernetes Cluster Installations
|
||||
@@ -41,6 +42,7 @@ If you are installing Rancher before v2.4, you will need to install Rancher on a
|
||||
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
|
||||
@@ -53,6 +55,7 @@ We recommend the following configurations for the load balancer and Ingress cont
|
||||
* The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Rancher installed on a Kubernetes cluster with layer 4 load balancer, depicting SSL termination at Ingress controllers</figcaption>
|
||||
|
||||
|
||||
|
||||
# Environment for Kubernetes Installations
|
||||
|
||||
@@ -77,4 +77,5 @@ The storage controller and replicas are themselves orchestrated using Kubernetes
|
||||
You can learn more about its architecture [here.](https://longhorn.io/docs/1.0.2/concepts/)
|
||||
|
||||
<figcaption>Longhorn Architecture</figcaption>
|
||||
|
||||
|
||||
|
||||
+3
@@ -40,6 +40,7 @@ To see the Alertmanager UI, go to the **Cluster Explorer.** In the top left corn
|
||||
**Result:** The Alertmanager UI opens in a new tab. For help with configuration, refer to the [official Alertmanager documentation.](https://prometheus.io/docs/alerting/latest/alertmanager/)
|
||||
|
||||
<figcaption>The Alertmanager UI</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -65,6 +66,7 @@ To see what services you are monitoring, you will need to see your targets. Targ
|
||||
To see the Prometheus Targets, install `rancher-monitoring`. Then go to the **Cluster Explorer.** In the top left corner, click **Cluster Explorer > Monitoring.** Then click **Prometheus Targets.**
|
||||
|
||||
<figcaption>Targets in the Prometheus UI</figcaption>
|
||||
|
||||
|
||||
|
||||
### Viewing the PrometheusRules
|
||||
@@ -76,4 +78,5 @@ To see the PrometheusRules, install `rancher-monitoring`. Then go to the **Clust
|
||||
You can also see the rules in the Prometheus UI:
|
||||
|
||||
<figcaption>Rules in the Prometheus UI</figcaption>
|
||||
|
||||
|
||||
+2
@@ -163,7 +163,9 @@ However, users can choose to log in to Grafana as an [Admin](https://grafana.com
|
||||
To see the Grafana UI, install `rancher-monitoring`. Then go to the **Cluster Explorer.** In the top left corner, click **Cluster Explorer > Monitoring.** Then click **Grafana.
|
||||
|
||||
<figcaption>Cluster Compute Resources Dashboard in Grafana</figcaption>
|
||||
|
||||
|
||||
|
||||
<figcaption>Default Dashboards in Grafana</figcaption>
|
||||
|
||||
|
||||
+2
@@ -12,6 +12,7 @@ In a standard Kubernetes deployment, resource quotas are applied to individual n
|
||||
In the following diagram, a Kubernetes administrator is trying to enforce a resource quota without Rancher. The administrator wants to apply a resource quota that sets the same CPU and memory limit to every namespace in his cluster (`Namespace 1-4`) . However, in the base version of Kubernetes, each namespace requires a unique resource quota. The administrator has to create four different resource quotas that have the same specs configured (`Resource Quota 1-4`) and apply them individually.
|
||||
|
||||
<sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
|
||||
|
||||
|
||||
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the project, and then the quota propagates to each namespace, whereafter Kubernetes enforces your limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can override it.
|
||||
@@ -30,6 +31,7 @@ The resource quota includes two limits, which you set while creating or editing
|
||||
In the following diagram, a Rancher administrator wants to apply a resource quota that sets the same CPU and memory limit for every namespace in their project (`Namespace 1-4`). However, in Rancher, the administrator can set a resource quota for the project (`Project Resource Quota`) rather than individual namespaces. This quota includes resource limits for both the entire project (`Project Limit`) and individual namespaces (`Namespace Default Limit`). Rancher then propagates the `Namespace Default Limit` quotas to each namespace (`Namespace Resource Quota`) when created.
|
||||
|
||||
<sup>Rancher: Resource Quotas Propagating to Each Namespace</sup>
|
||||
|
||||
|
||||
|
||||
Let's highlight some more nuanced functionality. If a quota is deleted at the project level, it will also be removed from all namespaces contained within that project, despite any overrides that may exist. Further, updating an existing namespace default limit for a quota at the project level will not result in that value being propagated to existing namespaces in the project; the updated value will only be applied to newly created namespaces in that project. To update a namespace default limit for existing namespaces you can delete and subsequently recreate the quota at the project level with the new default value. This will result in the new default value being applied to all existing namespaces in the project.
|
||||
|
||||
+1
@@ -10,6 +10,7 @@ Although the **Namespace Default Limit** propagates from the project to each nam
|
||||
In the diagram below, the Rancher administrator has a resource quota in effect for their project. However, the administrator wants to override the namespace limits for `Namespace 3` so that it has more resources available. Therefore, the administrator [raises the namespace limits](../../manage-clusters/projects-and-namespaces.md) for `Namespace 3` so that the namespace can access more resources.
|
||||
|
||||
<sup>Namespace Default Limit Override</sup>
|
||||
|
||||
|
||||
|
||||
How to: [Editing Namespace Resource Quotas](../../manage-clusters/projects-and-namespaces.md)
|
||||
|
||||
+1
@@ -31,6 +31,7 @@ After installing NGINX, you need to update the NGINX configuration file, `nginx.
|
||||
> **Note:** See [NGINX Documentation: TCP and UDP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/tcp-udp-load-balancer/) for all configuration options.
|
||||
|
||||
<figcaption>Example NGINX config</figcaption>
|
||||
|
||||
```
|
||||
worker_processes 4;
|
||||
worker_rlimit_nofile 40000;
|
||||
|
||||
+1
@@ -23,5 +23,6 @@ For information on how Rancher works, regardless of the installation method, ref
|
||||
- The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Kubernetes Rancher install with layer 4 load balancer, depicting SSL termination at ingress controllers</figcaption>
|
||||
|
||||
|
||||
<sup>Kubernetes Rancher install with Layer 4 load balancer (TCP), depicting SSL termination at ingress controllers</sup>
|
||||
|
||||
+3
@@ -28,6 +28,7 @@ We don't recommend installing Rancher in a single Docker container, because if t
|
||||
One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s is Rancher's CNCF certified Kubernetes distribution. It is easy to install and uses half the memory of Kubernetes, all in a binary of less than 100 MB. Another advantage of K3s is that it allows an external datastore to hold the cluster data, allowing the K3s server nodes to be treated as ephemeral.
|
||||
|
||||
<figcaption>Architecture of a K3s Kubernetes Cluster Running the Rancher Management Server</figcaption>
|
||||
|
||||
|
||||
|
||||
### RKE Kubernetes Cluster Installations
|
||||
@@ -35,6 +36,7 @@ One option for the underlying Kubernetes cluster is to use K3s Kubernetes. K3s i
|
||||
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
|
||||
@@ -47,6 +49,7 @@ We recommend the following configurations for the load balancer and Ingress cont
|
||||
* The Ingress controller will forward traffic to port TCP/80 on the pod in the Rancher deployment.
|
||||
|
||||
<figcaption>Rancher installed on a Kubernetes cluster with layer 4 load balancer, depicting SSL termination at Ingress controllers</figcaption>
|
||||
|
||||
|
||||
|
||||
# Environment for Kubernetes Installations
|
||||
|
||||
Reference in New Issue
Block a user