DOCSEARCHbyAlgolia
Submit Docs

Fleet for Rancher

website·Indexed 35 days ago

https://fleet.rancher.io/

Continuous Delivery for Rancher, providing tools to manage applications and cluster configurations across multiple clusters. Includes documentation for the Fleet CLI, fleet-controller, and fleet-agent, as well as specifications for Custom Resource Definitions (CRDs) like GitRepo and Bundle resources.

Tokens
406.9K
Snippets
1.6K
Records
3K
Agent score
60%

What's inside Fleet

  1. Overview of Fleet HelmOps

    HelmOps is a simplified way of creating bundles by pointing directly to a Helm repository or an OCI registry, removing the need for a git repository (GitOps). While GitOps uses a git repository as the source of truth, HelmOps uses a Helm registry. Fleet creates lightweight bundles that point to the referenced charts without downloading them to the manager; instead, charts are downloaded directly by the downstream clusters. Fleet resolves chart versions to ensure consistency across targeted clusters, supporting both static versions and semantic versioning constraints (e.g., 0.1.x, < 2.0.0).

  2. Overview of OCI Storage in Fleet

    By default, Fleet stores Kubernetes bundle resources in etcd. Because etcd has strict size limits and is not optimized for large workloads, you can use an OCI registry as a storage backend. This offloads large bundle content and provides a standardized storage backend for large manifests or Helm charts. To further reduce bundle size, it is recommended to compress and base64-encode bundle content before uploading to the OCI registry.

  3. Overview of Fleet Rollout Strategy

    Fleet uses a rollout strategy to control the order and grouping of app deployments across clusters. It evaluates the Ready status of BundleDeployment objects to determine when to proceed to the next partition. During a rollout, the GitRepo status reflects progress: clusters may be NotReady (currently deploying/failed), Pending (deployment not yet started), or OutOfSync (waiting for the rollout to reach them).

  4. Overview of HelmOps in Fleet

    HelmOps provides a simplified way to create bundles by pointing directly to a Helm repository or OCI registry, removing the need for a Git repository (GitOps). While GitOps uses a git repository as the source of truth, HelmOps uses a Helm registry. Fleet creates lightweight bundles that point to the referenced charts; the charts themselves are downloaded by the downstream clusters, meaning those clusters must have network access to the Helm registries.

  5. Overview of Fleet Webhooks vs Polling

    By default, Fleet polls Git repositories every 15 seconds. For larger deployments or to reduce the latency between a Git push and Fleet processing the change, webhooks should be used instead. When a webhook is configured, the polling interval automatically increases to one hour. Fleet supports the following providers: Azure DevOps, GitHub, GitLab, Bitbucket, Bitbucket Server, and Gogs.

  7. Overview of Fleet HelmOps

    HelmOps is a simplified deployment method in Fleet that uses a Helm registry as the source of truth instead of a Git repository. By creating a HelmOp custom Kubernetes resource, Fleet creates lightweight bundles pointing to referenced Helm charts. The Fleet HelmOps controller resolves chart versions (supporting wildcards and semantic versioning constraints) to ensure consistent deployment across downstream clusters. Note that Helm charts are downloaded directly by the downstream clusters, so those clusters must have network access to the Helm registries.

  8. Overview of OCI Storage in Fleet

    By default, Fleet stores Kubernetes bundle resources in etcd. For large workloads that exceed etcd size limits, Fleet can use an OCI registry as a storage backend. This reduces etcd load and provides a standardized way to handle large manifests or Helm charts. To optimize storage, bundle content should be compressed and base64-encoded before being uploaded to the OCI registry. Fleet verifies the integrity of OCI artifacts and tags them as latest.

  9. Overview of Fleet Webhooks vs Polling

    By default, Fleet pulls from Git repositories using polling every 15 seconds. For installations with many repositories or requirements for lower latency between a Git push and Fleet's reaction, webhooks are recommended. When a webhook is configured, the polling interval automatically increases to one hour. Supported providers include Azure DevOps, GitHub, GitLab, Bitbucket, Bitbucket Server, and Gogs.

  10. Overview of Fleet Webhooks vs Polling

    By default, Fleet polls Git repositories every 15 seconds. For larger deployments with many repositories, webhooks are recommended to reduce the delay between a Git push and Fleet processing the change. When a webhook is configured, the polling interval automatically increases to one hour. Fleet supports the following providers: Azure DevOps, GitHub, GitLab, Bitbucket, Bitbucket Server, and Gogs. Note that only application/json payloads are supported.

  11. Overview of Fleet cluster registration methods

    Fleet supports two styles of registering downstream clusters:

    1. Agent-Initiated Registration: The downstream cluster installs an agent that makes an outbound HTTPS request to the Fleet manager. This is the typical workflow and is ideal when the manager does not have direct network access to the downstream clusters.
    2. Manager-Initiated Registration: The Fleet manager makes an API call to an existing downstream cluster to deploy the agent. This requires the manager to have network access to the downstream cluster's API server. This is preferred for GitOps workflows using tools like cluster-api or Rancher.

  12. Overview of Fleet Target Customizations

    Target customizations allow you to modify how bundles are deployed to specific clusters without creating separate bundles or GitRepos. Defined in fleet.yaml, these rules can override namespace settings, Helm values/sources, Kustomize overlays, YAML overlays, deployment options (atomic, force), and drift correction settings.