Updating site structure per feedback

docs/integrations-in-rancher/fleet-gitops-at-scale/architecture.md

@@ -0,0 +1,8 @@
+---
+title: Architecture
+---
+
+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.
+
+![Architecture](/img/fleet-architecture.svg)
+

docs/integrations-in-rancher/fleet-gitops-at-scale/use-fleet-behind-a-proxy.md

@@ -0,0 +1,54 @@
+---
+title: Using Fleet Behind a Proxy
+---
+
+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.
+
+| 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,
+
+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**.
+
+**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
+```

docs/integrations-in-rancher/fleet-gitops-at-scale/windows-support.md

@@ -0,0 +1,22 @@
+---
+title: Windows Support
+---
+
+
+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
+```