mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-05-27 07:08:27 +00:00
Add v2.14 preview docs (#2212)
This commit is contained in:
Lucas Saintarbor
GitHub
@@ -0,0 +1,12 @@
|
||||
---
|
||||
title: Fleet Architecture
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/architecture"/>
|
||||
</head>
|
||||
|
||||
Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, or Kustomize or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy everything in the cluster. This gives you a high degree of control, consistency, and auditability. Fleet focuses not only on the ability to scale, but to give one a high degree of control and visibility to exactly what is installed on the cluster.
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
title: Continuous Delivery with Fleet
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet"/>
|
||||
</head>
|
||||
|
||||
Fleet orchestrates and manages the continuous delivery of applications through the supply chain for fleets of clusters. Fleet organizes the supply chain to help teams deliver with confidence and trust in a timely manner using GitOps as a safe operating model.
|
||||
|
||||
## Fleet with Rancher
|
||||
|
||||
Many users often manage over 10 clusters at a time. Given the proliferation of clusters, continuous delivery is an important part of Rancher. Fleet ensures a reliable continuous delivery experience using GitOps, which is a safe and increasingly common operating model.
|
||||
|
||||
### When should I use Fleet?
|
||||
|
||||
- I need to deploy my monitoring stack (e.g., Grafana, Prometheus) across geographical regions, each with different retention policies.
|
||||
- I am a platform operator and want to provision clusters with all components using a scalable and safe operating model (GitOps).
|
||||
- I am an application developer and want my latest changes to automatically go into my development environment.
|
||||
|
||||
## Fleet with Rancher Prime
|
||||
|
||||
Fleet is already deeply integrated as the Continuous Delivery tool and GitOps Engine in Rancher.
|
||||
|
||||
<!--
|
||||
- In future, we can have additional value adds like sharding controller (Manage shards for user) or notification controller (Event dispatcher/receiver) for prime customer only.
|
||||
-->
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: Overview
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/overview"/>
|
||||
</head>
|
||||
|
||||
## What is Continuous Delivery with Fleet?
|
||||
|
||||
Continuous Delivery is Rancher's GitOps functionality, which is provided via integration with Fleet.
|
||||
|
||||
- *Cluster engine*: Fleet is a container management and deployment engine designed to offer users more control on the local cluster and constant monitoring through GitOps. Fleet focuses not only on the ability to scale, but it also gives users a high degree of control and visibility to monitor exactly what is installed on the cluster.
|
||||
|
||||
- *Deployment management*: Fleet can manage deployments from git of raw Kubernetes YAML, Helm charts, Kustomize, or any combination of the three. Regardless of the source, all resources are dynamically turned into Helm charts, and Helm is used as the engine to deploy all resources in the cluster. As a result, users can enjoy a high degree of control, consistency, and auditability of their clusters.
|
||||
|
||||
## Architecture
|
||||
|
||||
For information about how Fleet works, see the [Architecture](./architecture.md) page.
|
||||
|
||||
## Accessing Fleet in the Rancher UI
|
||||
|
||||
Fleet comes preinstalled in Rancher and is managed by the **Continuous Delivery** option in the Rancher UI. For additional information on Continuous Delivery and other Fleet troubleshooting tips, refer [here](https://fleet.rancher.io/troubleshooting).
|
||||
|
||||
Users can leverage continuous delivery to deploy their applications to the Kubernetes clusters in the git repository without any manual operation by following **gitops** practice.
|
||||
|
||||
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.
|
||||
|
||||
- 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. Select your [git repository](https://fleet.rancher.io/gitrepo-add) and [target clusters/cluster group](https://fleet.rancher.io/gitrepo-targets). You can also create the cluster group in the UI by clicking on **Cluster Groups** from the left navigation bar.
|
||||
|
||||
1. Once the gitrepo is deployed, you can monitor the application through the Rancher UI.
|
||||
|
||||
## Windows Support
|
||||
|
||||
For details on support for clusters with Windows nodes, see the [Windows Support](./windows-support.md) page.
|
||||
|
||||
## GitHub Repository
|
||||
|
||||
The Fleet Helm charts are available [here](https://github.com/rancher/fleet/releases).
|
||||
|
||||
## Using Fleet Behind a Proxy
|
||||
|
||||
For details on using Fleet behind a proxy, see the [Using Fleet Behind a Proxy](./use-fleet-behind-a-proxy.md) page.
|
||||
|
||||
## Helm Chart Dependencies
|
||||
|
||||
In order for Helm charts with dependencies to deploy successfully, you must run a manual command (as listed below), as it is up to the user to fulfill the dependency list. If you do not do this and proceed to clone your repository and run `helm install`, your installation will fail because the dependencies will be missing.
|
||||
|
||||
The Helm chart in the git repository must include its dependencies in the charts subdirectory. You must either manually run `helm dependencies update $chart` or run `helm dependencies build $chart` locally, then commit the complete charts directory to your git repository. Note that you will update your commands with the applicable parameters
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- **Known Issue**: clientSecretName and helmSecretName secrets for Fleet gitrepos are not included in the backup nor restore created by the [backup-restore-operator](../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md#1-install-the-rancher-backup-operator). We will update the community once a permanent solution is in place.
|
||||
|
||||
- **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).
|
||||
|
||||
- **Debug logging**: To enable debug logging of Fleet components, create a new **fleet** entry in the existing **rancher-config** ConfigMap in the **cattle-system** namespace with the value `{"debug": 1, "debugLevel": 1}`. The Fleet application restarts after you save the ConfigMap.
|
||||
|
||||
## Documentation
|
||||
|
||||
See the [official Fleet documentation](https://fleet.rancher.io/) to learn more.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
title: Using Fleet Behind a Proxy
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/use-fleet-behind-a-proxy"/>
|
||||
</head>
|
||||
|
||||
In this section, you'll learn how to enable Fleet in a setup that has a Rancher server with a public IP a Kubernetes cluster that has no public IP, but is configured to use a proxy.
|
||||
|
||||
Rancher does not establish connections with registered downstream clusters. The Rancher agent deployed on the downstream cluster must be able to establish the connection with Rancher.
|
||||
|
||||
To set up Fleet to work behind a proxy, you will need to set the **Agent Environment Variables** for the downstream cluster. These are cluster-level configuration options.
|
||||
|
||||
Through the Rancher UI, you can configure these environment variables for any cluster type, including registered and custom clusters. The variables can be added while editing an existing cluster or while provisioning a new cluster.
|
||||
|
||||
For public downstream clusters, it is sufficient to [set the required environment variables in the Rancher UI.](#setting-environment-variables-in-the-rancher-ui)
|
||||
|
||||
For private nodes or private clusters, the environment variables need to be set on the nodes themselves. Then the environment variables are configured from the Rancher UI, typically when provisioning a custom cluster or when registering the private cluster. For an example of how to set the environment variables on Ubuntu node in a K3s Kubernetes cluster, see [this section.](#setting-environment-variables-on-private-nodes)
|
||||
|
||||
## Required Environment Variables
|
||||
|
||||
When adding Fleet agent environment variables for the proxy, replace <PROXY_IP> with your private proxy IP.
|
||||
|
||||
:::caution
|
||||
|
||||
The `NO_PROXY` environment variable is not standardized, and the accepted format of the value can differ between applications. When configuring the `NO_PROXY` variable in Rancher, the value must adhere to the format expected by Golang.
|
||||
|
||||
Specifically, the value should be a comma-delimited string which only contains IP addresses, CIDR notation, domain names, or special DNS labels (e.g. `*`). For a full description of the expected value format, refer to the [**upstream Golang documentation**](https://pkg.go.dev/golang.org/x/net/http/httpproxy#Config)
|
||||
|
||||
:::
|
||||
|
||||
| Variable Name | Value |
|
||||
|------------------|--------|
|
||||
| `HTTP_PROXY` | http://<PROXY_IP>:8888 |
|
||||
| `HTTPS_PROXY` | http://<PROXY_IP>:8888
|
||||
| `NO_PROXY` | 127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local |
|
||||
|
||||
## Setting Environment Variables in the Rancher UI
|
||||
|
||||
To add the environment variable to an existing cluster:
|
||||
|
||||
<Tabs groupId="k8s-distro">
|
||||
<TabItem value="RKE2/K3s" default>
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you want to add environment variables and click **⋮ > Edit Config**.
|
||||
1. Click **Agent Environment Vars** under **Cluster configuration**.
|
||||
1. Click **Add**.
|
||||
1. Enter the [required environment variables](#required-environment-variables)
|
||||
1. Click **Save**.
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="RKE">
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
1. Go to the cluster where you want to add environment variables and click **⋮ > Edit Config**.
|
||||
1. Click **Advanced Options**.
|
||||
1. Click **Add Environment Variable**.
|
||||
1. Enter the [required environment variables](#required-environment-variables)
|
||||
1. Click **Save**.
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**Result:** The Fleet agent works behind a proxy.
|
||||
|
||||
## Setting Environment Variables on Private Nodes
|
||||
|
||||
For private nodes and private clusters, the proxy environment variables need to be set on the nodes themselves, as well as configured from the Rancher UI.
|
||||
|
||||
This example shows how the environment variables would be set up on an Ubuntu node in a K3s Kubernetes cluster:
|
||||
|
||||
```
|
||||
ssh -o ForwardAgent=yes ubuntu@<public_proxy_ip>
|
||||
ssh <k3s_ip>
|
||||
export proxy_private_ip=<private_proxy_ip>
|
||||
export HTTP_PROXY=http://${proxy_private_ip}:8888
|
||||
export HTTPS_PROXY=http://${proxy_private_ip}:8888
|
||||
export NO_PROXY=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local
|
||||
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
|
||||
```
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
title: Windows Support
|
||||
---
|
||||
|
||||
<head>
|
||||
<link rel="canonical" href="https://ranchermanager.docs.rancher.com/integrations-in-rancher/fleet/windows-support"/>
|
||||
</head>
|
||||
|
||||
Prior to Rancher v2.5.6, the `agent` did not have native Windows manifests on downstream clusters with Windows nodes. This would result in a failing `agent` pod for the cluster.
|
||||
|
||||
If you are upgrading from an older version of Rancher to v2.5.6+, you can deploy a working `agent` with the following workflow *in the downstream cluster*:
|
||||
|
||||
1. Cordon all Windows nodes.
|
||||
1. Apply the below toleration to the `agent` workload.
|
||||
1. Uncordon all Windows nodes.
|
||||
1. Delete all `agent` pods. New pods should be created with the new toleration.
|
||||
1. Once the `agent` pods are running, and auto-update is enabled for Fleet, they should be updated to a Windows-compatible `agent` version.
|
||||
|
||||
```yaml
|
||||
tolerations:
|
||||
- effect: NoSchedule
|
||||
key: cattle.io/os
|
||||
operator: Equal
|
||||
value: linux
|
||||
```
|
||||
Reference in New Issue
Block a user