mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Convert line break tags causing errors
This commit is contained in:
Billy Tat
@@ -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]({{<baseurl>}}/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]({{<baseurl>}}/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:** </br>
|
||||
* **Temporary Workaround:** <br/>
|
||||
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).
|
||||
|
||||
---
|
||||
|
||||
@@ -17,30 +17,30 @@ For users looking to use another container runtime, Rancher has the edge-focused
|
||||
|
||||
### FAQ
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
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).
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
@@ -7,25 +7,25 @@ This FAQ is a work in progress designed to answers the questions our users most
|
||||
|
||||
See [Technical FAQ]({{<baseurl>}}/rancher/v2.6/en/faq/technical/), for frequently asked technical questions.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Is it possible to manage Azure Kubernetes Services with Rancher v2.x?**
|
||||
|
||||
Yes.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**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.]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters/windows-clusters/)
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher support Istio?**
|
||||
|
||||
@@ -33,37 +33,37 @@ As of Rancher 2.3.0, we support [Istio.]({{<baseurl>}}/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/)
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Does Rancher v2.x support RKT containers as well?**
|
||||
|
||||
At this time, we only support Docker.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**Are you going to integrate Longhorn?**
|
||||
|
||||
|
||||
@@ -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. <b>Note that this issue is resolved in v2.6.4.<b>
|
||||
>
|
||||
>- To work around this issue, first navigate to `https://<rancherserverurl>/v3/settings/windows-rke2-install-script`.
|
||||
>- To work around this issue, first navigate to `https://<rancherserverurl>/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 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
|
||||
<br>
|
||||
<br/>
|
||||
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
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 8007
|
||||
|
||||
The Hardening Guide is now located in the main [Security]({{<baseurl>}}/rancher/v2.6/en/security/) section.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
**What are the results of Rancher's Kubernetes cluster when it is CIS benchmarked?**
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ Before you create your own custom catalog, you should have a basic understanding
|
||||
|
||||
<figcaption>Rancher Chart with <code>questions.yml</code> (top) vs. Helm Chart without (bottom)</figcaption>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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:<br> - "ClusterIP" <br> - "NodePort" <br> - "LoadBalancer"|
|
||||
| options | []string | false | Specify the options when the variable type is `enum`, for example: options:<br/> - "ClusterIP" <br/> - "NodePort" <br/> - "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.|
|
||||
|
||||
+3
-3
@@ -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)<br> 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). <br> 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)<br/> 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). <br/> This option must be passed when rendering the Rancher Helm template. | no |
|
||||
|
||||
# Helm Chart Options for Air Gap Installations
|
||||
|
||||
|
||||
+10
-10
@@ -17,28 +17,28 @@ For users looking to use another container runtime, Rancher has the edge-focused
|
||||
|
||||
### FAQ
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
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.
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
+6
-6
@@ -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>
|
||||
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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
|
||||
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
```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.
|
||||
<br>
|
||||
<br/>
|
||||
|
||||
>**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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user