Convert line break tags causing errors

2026-09-25 12:38:05 +00:00 · 2022-07-18 16:53:33 -07:00
parent c7c1266582
commit 54f9da1dfa
23 changed files with 118 additions and 118 deletions
@@ -29,11 +29,11 @@ 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>
+<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
-``` 
+```

 ### 2. Restore from backup using a Restore custom resource

@@ -52,7 +52,7 @@ stringData:

 This secret can be created in any namespace, with the above example it will get created in the default namespace

-In the Restore custom resource, `prune` must be set to false. 
+In the Restore custom resource, `prune` must be set to false.

 Create a Restore custom resource like the example below:

@@ -76,18 +76,18 @@ spec:
      endpoint: s3.us-west-2.amazonaws.com
 ```

->**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:  
+>**Important:** The field `encryptionConfigSecretName` must be set only if your backup was created with encryption enabled. Provide the name of the Secret containing the encryption config file. If you only have the encryption config file, but don't have a secret created with it in this cluster, use the following steps to create the secret:

-1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:   
+1. The encryption configuration file must be named `encryption-provider-config.yaml`, and the `--from-file` flag must be used to create this secret. So save your `EncryptionConfiguration` in a file called `encryption-provider-config.yaml` and run this command:
    ```
    kubectl create secret generic encryptionconfig \
      --from-file=./encryption-provider-config.yaml \
      -n cattle-resources-system
    ```
-  
+
 1. Then apply the resource:
    ```
-    kubectl apply -f migrationResource.yaml 
+    kubectl apply -f migrationResource.yaml
    ```

 ### 3. Install cert-manager
@@ -20,9 +20,9 @@ If you encounter this issue, you can work around it by installing the initiator
 After installing the initiator tool on your nodes, edit the YAML for your cluster, editing the kubelet configuration to mount the iSCSI binary and configuration, as shown in the sample below.

 >**Notes:**
->  
->- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.</br>
-></br>
+>
+>- Before updating your Kubernetes YAML to mount the iSCSI binary and configuration, make sure either the `open-iscsi` (deb) or `iscsi-initiator-utils` (yum) package is installed on your cluster nodes. If this package isn't installed _before_ the bind mounts are created in your Kubernetes YAML, Docker will automatically create the directories and files on each node and will not allow the package install to succeed.<br/>
+><br/>
 >
 >- The example YAML below does not apply to K3s, but only to RKE clusters. Since the K3s kubelet does not run in a container, adding extra binds is not necessary. However, all iSCSI tools must still be installed on your K3s nodes.

@@ -187,7 +187,7 @@ spec:

 1. Generate a load for the service to test that your pods autoscale as intended. You can use any load-testing tool (Hey, Gatling, etc.), but we're using [Hey](https://github.com/rakyll/hey).

-1. Test that pod autoscaling works as intended.<br/></br>
+1. Test that pod autoscaling works as intended.<br/><br/>
  **To Test Autoscaling Using Resource Metrics:**
  {{% accordion id="observe-upscale-2-pods-cpu" label="Upscale to 2 Pods: CPU Usage Up to Target" %}}
 Use your load testing tool to scale up to two pods based on CPU Usage.
@@ -32,18 +32,18 @@ ServiceMonitors and PodMonitors declaratively specify targets, such as Services
 - Certain internal Kubernetes components are scraped via a proxy deployed as part of Monitoring V2 called **PushProx**. The Kubernetes components that expose metrics to Prometheus through PushProx are the following:
 `kube-controller-manager`, `kube-scheduler`, `etcd`, and `kube-proxy`.

- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet. 
-    
+- For each PushProx exporter, we deploy one PushProx client onto all target nodes. For example, a PushProx client is deployed onto all controlplane nodes for kube-controller-manager, all etcd nodes for kube-etcd, and all nodes for kubelet.
+
 - We deploy exactly one PushProx proxy per exporter. The process for exporting metrics is as follows:

-1. The PushProx Client establishes an outbound connection with the PushProx Proxy.    
+1. The PushProx Client establishes an outbound connection with the PushProx Proxy.
 1. The client then polls the proxy for scrape requests that have come into the proxy.
 1. When the proxy receives a scrape request from Prometheus, the client sees it as a result of the poll.
 1. The client scrapes the internal component.
 1. The internal component responds by pushing metrics back to the proxy.
-    

-<figcaption><br>Process for Exporting Metrics with PushProx:</br></figcaption>
+
+<figcaption><br/>Process for Exporting Metrics with PushProx:<br/></figcaption>

 ![Process for Exporting Metrics with PushProx]({{<baseurl>}}/img/rancher/pushprox-process.svg)

@@ -126,7 +126,7 @@ The Alertmanager handles alerts sent by client applications such as the Promethe
 ### Alerts Forwarded by alertingDrivers

 When alertingDrivers are installed, this creates a `Service` that can be used as the receiver's URL for Teams or SMS, based on the alertingDriver's configuration. The URL in the Receiver points to the alertingDrivers; so the Alertmanager sends alert first to alertingDriver, then alertingDriver forwards or sends alert to the proper destination.
-    
+
 ### Routing Alerts to Receivers

 Alertmanager coordinates where alerts are sent. It allows you to group alerts based on labels and fire them based on whether certain labels are matched. One top-level route accepts all alerts. From there, Alertmanager continues routing alerts to receivers based on whether they match the conditions of the next route.