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
|
||||
|
||||
Reference in New Issue
Block a user