From 54f9da1dfa2f7fbc3d4067d2542aabdd349d753d Mon Sep 17 00:00:00 2001 From: Billy Tat Date: Mon, 18 Jul 2022 16:53:33 -0700 Subject: [PATCH] Convert line break tags causing errors --- .../migrating-rancher/migrating-rancher.md | 8 +++---- docs/en/deploy-across-clusters/fleet/fleet.md | 12 +++++----- .../how-monitoring-works.md | 12 +++++----- .../creating-credentials.md | 6 ++--- .../en/faq/upgrades-to-2x/upgrades-to-2x.md | 20 ++++++++--------- .../creating-apps/creating-apps.md | 2 +- .../install-rancher/install-rancher.md | 4 ++-- .../populate-private-registry.md | 18 +++++++-------- .../testing-hpa/testing-hpa.md | 2 +- .../migrating-rancher/migrating-rancher.md | 14 ++++++------ .../iscsi-volumes/iscsi-volumes.md | 6 ++--- .../testing-hpa/testing-hpa.md | 2 +- .../how-monitoring-works.md | 12 +++++----- .../en/deploy-across-clusters/fleet/fleet.md | 12 +++++----- .../v2.6/en/faq/dockershim/dockershim.md | 20 ++++++++--------- versioned_docs/version-2.6/v2.6/en/faq/faq.md | 22 +++++++++---------- .../networking/cni-providers/cni-providers.md | 12 +++++----- .../v2.6/en/faq/security/security.md | 2 +- .../creating-apps/creating-apps.md | 4 ++-- .../install-rancher/install-rancher.md | 6 ++--- .../requirements/dockershim/dockershim.md | 20 ++++++++--------- .../how-monitoring-works.md | 12 +++++----- .../v2.6/en/pipelines/config/config.md | 8 +++---- 23 files changed, 118 insertions(+), 118 deletions(-) diff --git a/docs/en/backups/migrating-rancher/migrating-rancher.md b/docs/en/backups/migrating-rancher/migrating-rancher.md index be138345663..e18f04fcf16 100644 --- a/docs/en/backups/migrating-rancher/migrating-rancher.md +++ b/docs/en/backups/migrating-rancher/migrating-rancher.md @@ -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 ``` -
+
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 @@ -70,7 +70,7 @@ data: 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: @@ -96,11 +96,11 @@ spec: :::note 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: +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 \ diff --git a/docs/en/deploy-across-clusters/fleet/fleet.md b/docs/en/deploy-across-clusters/fleet/fleet.md index 1b129ee97f0..c1502c71664 100644 --- a/docs/en/deploy-across-clusters/fleet/fleet.md +++ b/docs/en/deploy-across-clusters/fleet/fleet.md @@ -30,12 +30,12 @@ Follow the steps below to access Continuous Delivery in the Rancher UI: 1. Click **☰ > Continuous Delivery**. -1. Select your namespace at the top of the menu, noting the following: - - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher. - - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters. +1. Select your namespace at the top of the menu, noting the following: + - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher. + - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters. - You can then manage clusters by clicking on **Clusters** on the left navigation bar. -1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace. +1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace. 1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar. @@ -64,9 +64,9 @@ The Helm chart in the git repository must include its dependencies in the charts # Troubleshooting --- -* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place. +* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place. -* **Temporary Workaround:**
+* **Temporary Workaround:**
By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow). --- diff --git a/docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md b/docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md index 30b19cdbc66..fcd70f138e8 100644 --- a/docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md +++ b/docs/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md @@ -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. - -

Process for Exporting Metrics with PushProx:
+ +

Process for Exporting Metrics with PushProx:
![Process for Exporting Metrics with PushProx]({{}}/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. diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md index ce7a1fe5d3a..1a3a57d155b 100644 --- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md +++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/cluster-provisioning/rke-clusters/node-pools/vsphere/creating-credentials/creating-credentials.md @@ -11,10 +11,10 @@ The following table lists the permissions required for the vSphere user account: | Privilege Group | Operations | |:----------------------|:-----------------------------------------------------------------------| -| Datastore | AllocateSpace
Browse
FileManagement (Low level file operations)
UpdateVirtualMachineFiles
UpdateVirtualMachineMetadata | +| Datastore | AllocateSpace
Browse
FileManagement (Low level file operations)
UpdateVirtualMachineFiles
UpdateVirtualMachineMetadata | | Network | Assign | | Resource | AssignVMToPool | -| Virtual Machine | Config (All)
GuestOperations (All)
Interact (All)
Inventory (All)
Provisioning (All) | +| Virtual Machine | Config (All)
GuestOperations (All)
Interact (All)
Inventory (All)
Provisioning (All) | The following steps create a role with the required privileges and then assign it to a new user in the vSphere console: @@ -37,7 +37,7 @@ The following steps create a role with the required privileges and then assign i 7. Create a new Global Permission. Add the user you created earlier and assign it the role you created earlier. Click **OK**. {{< img "/img/rancher/globalpermissionuser.png" "image" >}} - + {{< img "/img/rancher/globalpermissionrole.png" "image" >}} **Result:** You now have credentials that Rancher can use to manipulate vSphere resources. diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md index db5cc1e85b3..bae4da16a67 100644 --- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md +++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/faq/upgrades-to-2x/upgrades-to-2x.md @@ -13,25 +13,25 @@ This page contains frequently asked questions about the changes between Rancher Rancher v2.x is a complete container management platform built 100% on Kubernetes leveraging its Custom Resource and Controller framework. All features are written as a CustomResourceDefinition (CRD) which extends the existing Kubernetes API and can leverage native features such as RBAC. -
+
**Do you plan to implement upstream Kubernetes, or continue to work on your own fork?** We're still going to provide our distribution when you select the default option of having us create your Kubernetes cluster, but it will be very close to upstream. -
+
**Does this release mean that we need to re-train our support staff in Kubernetes?** Yes. Rancher will offer the native Kubernetes functionality via `kubectl` but will also offer our own UI dashboard to allow you to deploy Kubernetes workload without having to understand the full complexity of Kubernetes. However, to fully leverage Kubernetes, we do recommend understanding Kubernetes. We do plan on improving our UX with subsequent releases to make Kubernetes easier to use. -
+
**Is a Rancher compose going to make a Kubernetes pod? Do we have to learn both now? We usually use the filesystem layer of files, not the UI.** No. Unfortunately, the differences were enough such that we cannot support Rancher compose anymore in 2.x. We will be providing both a tool and guides to help with this migration. -
+
**If we use Kubernetes native YAML files for creating resources, should we expect that to work as expected, or do we need to use Rancher/Docker compose files to deploy infrastructure?** @@ -43,7 +43,7 @@ Absolutely. Cattle will not supported in v2.x as Rancher has been re-architected to be based on Kubernetes. You can, however, expect majority of Cattle features you use will exist and function similarly on Kubernetes. We will develop migration tools in Rancher v2.1 to help you transform your existing Rancher Compose files into Kubernetes YAML files. -
+
**Can I migrate existing Cattle workloads into Kubernetes?** @@ -55,19 +55,19 @@ Yes. In the upcoming Rancher v2.1 release we will provide a tool to help transla Yes. You can manage Kubernetes storage, networking, and its vast ecosystem of add-ons. -
+
**Are there changes to default roles available now or going forward? Will the Kubernetes alignment impact plans for roles/RBAC?** The default roles will be expanded to accommodate the new Rancher 2.x features, and will also take advantage of the Kubernetes RBAC (Role-Based Access Control) capabilities to give you more flexibility. -
+
**Will there be any functions like network policies to separate a front-end container from a back-end container through some kind of firewall in v2.x?** Yes. You can do so by leveraging Kubernetes' network policies. -
+
**What about the CLI? Will that work the same way with the same features?** @@ -81,7 +81,7 @@ Starting with 2.0, the concept of an environment has now been changed to a Kuber Kubernetes RKE Templates is on our roadmap for 2.x. Please refer to our Release Notes and documentation for all the features that we currently support. -
+
**Can you still add an existing host to an environment? (i.e. not provisioned directly from Rancher)** @@ -93,7 +93,7 @@ Yes. We still provide you with the same way of executing our Rancher agents dire Due to the technical difficulty in transforming a Docker container into a pod running Kubernetes, upgrading will require users to "replay" those workloads from v1.x into new v2.x environments. We plan to ship with a tool in v2.1 to translate existing Rancher Compose files into Kubernetes YAML files. You will then be able to deploy those workloads on the v2.x platform. -
+
**Is it possible to upgrade from Rancher v1.x to v2.x without any disruption to Cattle and Kubernetes clusters?** diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md index 73d1f6efe48..2b7c2e37b3a 100644 --- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md +++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/helm-charts/creating-apps/creating-apps.md @@ -117,7 +117,7 @@ This reference contains variables that you can use in `questions.yml` nested und | max_length | int | false | Max character length.| | min | int | false | Min integer length. | | max | int | false | Max integer length. | -| options | []string | false | Specify the options when the variable type is `enum`, for example: options:
- "ClusterIP"
- "NodePort"
- "LoadBalancer"| +| options | []string | false | Specify the options when the variable type is `enum`, for example: options:
- "ClusterIP"
- "NodePort"
- "LoadBalancer"| | valid_chars | string | false | Regular expression for input chars validation. | | invalid_chars | string | false | Regular expression for invalid input chars validation.| | subquestions | []subquestion | false| Add an array of subquestions.| diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md index ecf32661571..fed4dc7a211 100644 --- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md +++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/install-rancher/install-rancher.md @@ -61,8 +61,8 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec | Configuration | Chart option | Description | Requires cert-manager | | ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | -| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)
This is the **default** and does not need to be added when rendering the Helm template. | yes | -| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s).
This option must be passed when rendering the Rancher Helm template. | no | +| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)
This is the **default** and does not need to be added when rendering the Helm template. | yes | +| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s).
This option must be passed when rendering the Rancher Helm template. | no | ### C. Render the Rancher Helm Template diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md index 08e40ac80d1..0fe9734c28d 100644 --- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md +++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/installation/resources/advanced/air-gap-helm2/populate-private-registry/populate-private-registry.md @@ -29,9 +29,9 @@ By default, we provide the steps of how to populate your private registry assumi For Rancher servers that will only provision Linux clusters, these are the steps to populate your private registry. -A. Find the required assets for your Rancher version
-B. Collect all the required images
-C. Save the images to your workstation
+A. Find the required assets for your Rancher version
+B. Collect all the required images
+C. Save the images to your workstation
D. Populate the private registry ### Prerequisites @@ -115,9 +115,9 @@ For Rancher servers that will provision Linux and Windows clusters, there are di The Windows images need to be collected and pushed from a Windows server workstation. -A. Find the required assets for your Rancher version
-B. Save the images to your Windows Server workstation
-C. Prepare the Docker daemon
+A. Find the required assets for your Rancher version
+B. Save the images to your Windows Server workstation
+C. Prepare the Docker daemon
D. Populate the private registry {{% accordion label="Collecting and Populating Windows Images into the Private Registry"%}} @@ -189,9 +189,9 @@ Move the images in the `rancher-windows-images.tar.gz` to your private registry The Linux images needs to be collected and pushed from a Linux host, but _must be done after_ populating the Windows images into the private registry. These step are different from the Linux only steps as the Linux images that are pushed will actually manifests that support Windows and Linux images. -A. Find the required assets for your Rancher version
-B. Collect all the required images
-C. Save the images to your Linux workstation
+A. Find the required assets for your Rancher version
+B. Collect all the required images
+C. Save the images to your Linux workstation
D. Populate the private registry {{% accordion label="Collecting and Populating Linux Images into the Private Registry" %}} diff --git a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md index a003fdc2bbe..682484fc664 100644 --- a/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md +++ b/versioned_docs/version-2.0-2.4/v2.0-v2.4/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md @@ -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.

+1. Test that pod autoscaling works as intended.

**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. diff --git a/versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md b/versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md index e84fe21de1b..582498c1d19 100644 --- a/versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md +++ b/versioned_docs/version-2.5/v2.5/en/backups/migrating-rancher/migrating-rancher.md @@ -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 ``` -
+
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 diff --git a/versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md b/versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md index deaaaac4fc5..f9696d32730 100644 --- a/versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md +++ b/versioned_docs/version-2.5/v2.5/en/cluster-admin/volumes-and-storage/iscsi-volumes/iscsi-volumes.md @@ -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.
->
+> +>- 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.
+>
> >- 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. diff --git a/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md b/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md index 0816641dd5a..5f4a16b0367 100644 --- a/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md +++ b/versioned_docs/version-2.5/v2.5/en/k8s-in-rancher/horitzontal-pod-autoscaler/testing-hpa/testing-hpa.md @@ -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.

+1. Test that pod autoscaling works as intended.

**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. diff --git a/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md b/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md index 30b19cdbc66..fcd70f138e8 100644 --- a/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md +++ b/versioned_docs/version-2.5/v2.5/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md @@ -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. - -

Process for Exporting Metrics with PushProx:
+ +

Process for Exporting Metrics with PushProx:
![Process for Exporting Metrics with PushProx]({{}}/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. diff --git a/versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md b/versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md index 1b129ee97f0..c1502c71664 100644 --- a/versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md +++ b/versioned_docs/version-2.6/v2.6/en/deploy-across-clusters/fleet/fleet.md @@ -30,12 +30,12 @@ Follow the steps below to access Continuous Delivery in the Rancher UI: 1. Click **☰ > Continuous Delivery**. -1. Select your namespace at the top of the menu, noting the following: - - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher. - - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters. +1. Select your namespace at the top of the menu, noting the following: + - By default,`fleet-default` is selected which includes all downstream clusters that are registered through Rancher. + - You may switch to `fleet-local`, which only contains the `local` cluster, or you may create your own workspace to which you may assign and move clusters. - You can then manage clusters by clicking on **Clusters** on the left navigation bar. -1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace. +1. Click on **Gitrepos** on the left navigation bar to deploy the gitrepo into your clusters in the current workspace. 1. Select your [git repository](https://fleet.rancher.io/gitrepo-add/) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-structure/). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar. @@ -64,9 +64,9 @@ The Helm chart in the git repository must include its dependencies in the charts # Troubleshooting --- -* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place. +* **Known Issue:** clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator]({{}}/rancher/v2.6/en/backups/back-up-rancher/#1-install-the-rancher-backups-operator). We will update the community once a permanent solution is in place. -* **Temporary Workaround:**
+* **Temporary Workaround:**
By default, user-defined secrets are not backed up in Fleet. It is necessary to recreate secrets if performing a disaster recovery restore or migration of Rancher into a fresh cluster. To modify resourceSet to include extra resources you want to backup, refer to docs [here](https://github.com/rancher/backup-restore-operator#user-flow). --- diff --git a/versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md b/versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md index a9f79c0bddd..d9ce2fe6437 100644 --- a/versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md +++ b/versioned_docs/version-2.6/v2.6/en/faq/dockershim/dockershim.md @@ -17,30 +17,30 @@ For users looking to use another container runtime, Rancher has the edge-focused ### FAQ -
+
-Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim? +Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim? The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on Rancher 2.6 or above to have support for RKE with Kubernetes 1.21. See our [support matrix](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.6.0/) for details. -
+
-Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim? +Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim? A. The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and is not scheduled for removal upstream until Kubernetes 1.24. It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to Kubernetes 1.21 as you would normally, but should consider enabling the external Dockershim by Kubernetes 1.22. The external Dockershim will need to be enabled before upgrading to Kubernetes 1.24, at which point the existing implementation will be removed. For more information on the deprecation and its timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed). -
+
-Q: What are my other options if I don’t want to depend on the Dockershim? +Q: What are my other options if I don’t want to depend on the Dockershim? A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this. -
+
-Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options? +Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options? -A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl. +A: Rancher is exploring the possibility of an in-place upgrade path. Alternatively you can always migrate workloads from one cluster to another using kubectl. -
+
diff --git a/versioned_docs/version-2.6/v2.6/en/faq/faq.md b/versioned_docs/version-2.6/v2.6/en/faq/faq.md index 4fc0889d102..92b3894af2a 100644 --- a/versioned_docs/version-2.6/v2.6/en/faq/faq.md +++ b/versioned_docs/version-2.6/v2.6/en/faq/faq.md @@ -7,25 +7,25 @@ This FAQ is a work in progress designed to answers the questions our users most See [Technical FAQ]({{}}/rancher/v2.6/en/faq/technical/), for frequently asked technical questions. -
+
**Does Rancher v2.x support Docker Swarm and Mesos as environment types?** When creating an environment in Rancher v2.x, Swarm and Mesos will no longer be standard options you can select. However, both Swarm and Mesos will continue to be available as Catalog applications you can deploy. It was a tough decision to make but, in the end, it came down to adoption. For example, out of more than 15,000 clusters, only about 200 or so are running Swarm. -
+
**Is it possible to manage Azure Kubernetes Services with Rancher v2.x?** Yes. -
+
**Does Rancher support Windows?** As of Rancher 2.3.0, we support Windows Server 1809 containers. For details on how to set up a cluster with Windows worker nodes, refer to the section on [configuring custom clusters for Windows.]({{}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/) -
+
**Does Rancher support Istio?** @@ -33,37 +33,37 @@ As of Rancher 2.3.0, we support [Istio.]({{}}/rancher/v2.6/en/istio/) Furthermore, Istio is implemented in our micro-PaaS "Rio", which works on Rancher 2.x along with any CNCF compliant Kubernetes cluster. You can read more about it [here](https://rio.io/) -
+
**Will Rancher v2.x support Hashicorp's Vault for storing secrets?** -Secrets management is on our roadmap but we haven't assigned it to a specific release yet. +Secrets management is on our roadmap but we haven't assigned it to a specific release yet. -
+
**Does Rancher v2.x support RKT containers as well?** At this time, we only support Docker. -
+
**Does Rancher v2.x support Calico, Contiv, Contrail, Flannel, Weave net, etc., for embedded and registered Kubernetes?** Out-of-the-box, Rancher provides the following CNI network providers for Kubernetes clusters: Canal, Flannel, Calico and Weave. Always refer to the [Rancher Support Matrix](https://rancher.com/support-maintenance-terms/) for details about what is officially supported. -
+
**Are you planning on supporting Traefik for existing setups?** We don't currently plan on providing embedded Traefik support, but we're still exploring load-balancing approaches. -
+
**Can I import OpenShift Kubernetes clusters into v2.x?** Our goal is to run any upstream Kubernetes clusters. Therefore, Rancher v2.x should work with OpenShift, but we haven't tested it yet. -
+
**Are you going to integrate Longhorn?** diff --git a/versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md b/versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md index ea4bbde4872..a7104cc5dfc 100644 --- a/versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md +++ b/versioned_docs/version-2.6/v2.6/en/faq/networking/cni-providers/cni-providers.md @@ -46,7 +46,7 @@ CNI network providers using this network model include Calico and Cilium. Cilium ### RKE Kubernetes clusters -Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, and Weave. +Out-of-the-box, Rancher provides the following CNI network providers for RKE Kubernetes clusters: Canal, Flannel, and Weave. You can choose your CNI network provider when you create new Kubernetes clusters from Rancher. @@ -95,7 +95,7 @@ For more information, see the following pages: ### RKE2 Kubernetes clusters -Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium. +Out-of-the-box, Rancher provides the following CNI network providers for RKE2 Kubernetes clusters: [Canal](#canal) (see above section), Calico, and Cilium. You can choose your CNI network provider when you create new Kubernetes clusters from Rancher. @@ -111,7 +111,7 @@ Kubernetes workers should open TCP port `179` if using BGP or UDP port `4789` if >**Important:** In Rancher v2.6.3, Calico probes fail on Windows nodes upon RKE2 installation. Note that this issue is resolved in v2.6.4. > ->- To work around this issue, first navigate to `https:///v3/settings/windows-rke2-install-script`. +>- To work around this issue, first navigate to `https:///v3/settings/windows-rke2-install-script`. > >- There, change the current setting: `https://raw.githubusercontent.com/rancher/wins/v0.1.3/install.ps1` to this new setting: `https://raw.githubusercontent.com/rancher/rke2/master/windows/rke2-install.ps1`. @@ -126,12 +126,12 @@ For more information, see the following pages: ![Cilium Logo]({{}}/img/rancher/cilium-logo.png) -Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured. +Cilium enables networking and network policies (L3, L4, and L7) in Kubernetes. By default, Cilium uses eBPF technologies to route packets inside the node and VXLAN to send packets to other nodes. Unencapsulated techniques can also be configured. Cilium recommends kernel versions greater than 5.2 to be able to leverage the full potential of eBPF. Kubernetes workers should open TCP port `8472` for VXLAN and TCP port `4240` for health checks. In addition, ICMP 8/0 must be enabled for health checks. For more information, check [Cilium System Requirements](https://docs.cilium.io/en/latest/operations/system_requirements/#firewall-requirements). ##### Ingress Routing Across Nodes in Cilium -
+
By default, Cilium does not allow pods to contact pods on other nodes. To work around this, enable the ingress controller to route requests across nodes with a `CiliumNetworkPolicy`. After selecting the Cilium CNI and enabling Project Network Isolation for your new cluster, configure as follows: @@ -143,7 +143,7 @@ metadata: name: hn-nodes namespace: default spec: - endpointSelector: {} + endpointSelector: {} ingress: - fromEntities: - remote-node diff --git a/versioned_docs/version-2.6/v2.6/en/faq/security/security.md b/versioned_docs/version-2.6/v2.6/en/faq/security/security.md index 55eb76ee087..6759f6d2946 100644 --- a/versioned_docs/version-2.6/v2.6/en/faq/security/security.md +++ b/versioned_docs/version-2.6/v2.6/en/faq/security/security.md @@ -8,7 +8,7 @@ weight: 8007 The Hardening Guide is now located in the main [Security]({{}}/rancher/v2.6/en/security/) section. -
+
**What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?** diff --git a/versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md b/versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md index b4376f81ef7..3e8555a0f8c 100644 --- a/versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md +++ b/versioned_docs/version-2.6/v2.6/en/helm-charts/creating-apps/creating-apps.md @@ -68,7 +68,7 @@ Before you create your own custom catalog, you should have a basic understanding
Rancher Chart with questions.yml (top) vs. Helm Chart without (bottom)
- ![questions.yml]({{}}/img/rancher/rancher-app-2.6.png) + ![questions.yml]({{}}/img/rancher/rancher-app-2.6.png) ![values.yaml]({{}}/img/rancher/helm-app-2.6.png) @@ -118,7 +118,7 @@ This reference contains variables that you can use in `questions.yml` nested und | max_length | int | false | Max character length.| | min | int | false | Min integer length. | | max | int | false | Max integer length. | -| options | []string | false | Specify the options when the variable type is `enum`, for example: options:
- "ClusterIP"
- "NodePort"
- "LoadBalancer"| +| options | []string | false | Specify the options when the variable type is `enum`, for example: options:
- "ClusterIP"
- "NodePort"
- "LoadBalancer"| | valid_chars | string | false | Regular expression for input chars validation. | | invalid_chars | string | false | Regular expression for invalid input chars validation.| | subquestions | []subquestion | false| Add an array of subquestions.| diff --git a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md index a739fd07987..631cc6c4278 100644 --- a/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md +++ b/versioned_docs/version-2.6/v2.6/en/installation/other-installation-methods/air-gap/install-rancher/install-rancher.md @@ -9,7 +9,7 @@ This section is about how to deploy Rancher for your air gapped environment in a When the Rancher server is deployed in the Docker container, a local Kubernetes cluster is installed within the container for Rancher to use. Because many features of Rancher run as deployments, and privileged mode is required to run containers within containers, you will need to install Rancher with the `--privileged` option. -# Docker Instructions +# Docker Instructions If you want to continue the air gapped installation using Docker commands, skip the rest of this page and follow the instructions on [this page.](./docker-install-commands) @@ -56,8 +56,8 @@ When Rancher is installed on an air gapped Kubernetes cluster, there are two rec | Configuration | Chart option | Description | Requires cert-manager | | ------------------------------------------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | -| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)
This is the **default** and does not need to be added when rendering the Helm template. | yes | -| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s).
This option must be passed when rendering the Rancher Helm template. | no | +| Rancher Generated Self-Signed Certificates | `ingress.tls.source=rancher` | Use certificates issued by Rancher's generated CA (self signed)
This is the **default** and does not need to be added when rendering the Helm template. | yes | +| Certificates from Files | `ingress.tls.source=secret` | Use your own certificate files by creating Kubernetes Secret(s).
This option must be passed when rendering the Rancher Helm template. | no | # Helm Chart Options for Air Gap Installations diff --git a/versioned_docs/version-2.6/v2.6/en/installation/requirements/dockershim/dockershim.md b/versioned_docs/version-2.6/v2.6/en/installation/requirements/dockershim/dockershim.md index e4c3490c4b2..610eb3233e8 100644 --- a/versioned_docs/version-2.6/v2.6/en/installation/requirements/dockershim/dockershim.md +++ b/versioned_docs/version-2.6/v2.6/en/installation/requirements/dockershim/dockershim.md @@ -17,28 +17,28 @@ For users looking to use another container runtime, Rancher has the edge-focused ### FAQ -
+
-Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim? +Q. Do I have to upgrade Rancher to get Rancher’s support of the upstream Dockershim? A The upstream support of Dockershim begins for RKE in Kubernetes 1.21. You will need to be on a version of Rancher that supports RKE 1.21. See our support matrix for details. -
+
-Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim? +Q. I am currently on RKE with Kubernetes 1.20. Do I need to upgrade to RKE with Kubernetes 1.21 sooner to avoid being out of support for Dockershim? A. The version of Dockershim in RKE with Kubernetes 1.20 will continue to work and it is not deprecated until a later release. For information on the timeline, see the [Kubernetes Dockershim Deprecation FAQ](https://kubernetes.io/blog/2020/12/02/dockershim-faq/#when-will-dockershim-be-removed). It will only emit a warning of its future deprecation, which Rancher has mitigated in RKE with Kubernetes 1.21. You can plan your upgrade to 1.21 as you would normally. -
+
-Q: What are my other options if I don’t want to depend on the Dockershim? +Q: What are my other options if I don’t want to depend on the Dockershim? A: You can use a runtime like containerd with Kubernetes that does not require Dockershim support. RKE2 or K3s are two options for doing this. -
+
-Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options? +Q: If I am already using RKE1 and want to switch to RKE2, what are my migration options? -A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path. +A: Today, you can stand up a new cluster and migrate workloads to a new RKE2 cluster that uses containerd. Rancher is exploring the possibility of an in-place upgrade path. -
+
diff --git a/versioned_docs/version-2.6/v2.6/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md b/versioned_docs/version-2.6/v2.6/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md index 30b19cdbc66..fcd70f138e8 100644 --- a/versioned_docs/version-2.6/v2.6/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md +++ b/versioned_docs/version-2.6/v2.6/en/monitoring-alerting/how-monitoring-works/how-monitoring-works.md @@ -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. - -

Process for Exporting Metrics with PushProx:
+ +

Process for Exporting Metrics with PushProx:
![Process for Exporting Metrics with PushProx]({{}}/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. diff --git a/versioned_docs/version-2.6/v2.6/en/pipelines/config/config.md b/versioned_docs/version-2.6/v2.6/en/pipelines/config/config.md index 86b10606e47..333d4aff51f 100644 --- a/versioned_docs/version-2.6/v2.6/en/pipelines/config/config.md +++ b/versioned_docs/version-2.6/v2.6/en/pipelines/config/config.md @@ -130,7 +130,7 @@ PLUGIN_MIRROR | Docker daemon registry mirror PLUGIN_INSECURE | Docker daemon allows insecure registries PLUGIN_BUILD_ARGS | Docker build args, a comma separated list -
+
```yaml # This example shows an environment variable being used @@ -502,7 +502,7 @@ If you need to use security-sensitive information in your pipeline scripts (like ### Prerequisite Create a secret in the same project as your pipeline, or explicitly in the namespace where pipeline build pods run. -
+
>**Note:** Secret injection is disabled on [pull request events](#triggers-and-trigger-rules). @@ -556,7 +556,7 @@ Variable Name | Description # Global Pipeline Execution Settings -After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher. +After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher. ### Changing Pipeline Settings @@ -622,7 +622,7 @@ stages: >**Note:** Rancher sets default compute resources for pipeline steps except for `Build and Publish Images` and `Run Script` steps. You can override the default value by specifying compute resources in the same way. -### Custom CA +### Custom CA If you want to use a version control provider with a certificate from a custom/internal CA root, the CA root certificates need to be added as part of the version control provider configuration in order for the pipeline build pods to succeed.