Bundle Lifecycle

A bundle is an internal resource used for the orchestration of resources from git. When a GitRepo is scanned it will produce one or more bundles.

To demonstrate the life cycle of a Fleet bundle, we will use multi-cluster/helm as a case study.

  1. User will create a GitRepo that points to the multi-cluster/helm repository.
  2. The gitjob-controller will sync changes from the GitRepo and detect changes from the polling or webhook event. With every commit change, the gitjob-controller will create a job that clones the git repository, reads content from the repo such as fleet.yaml and other manifests, and creates the Fleet bundle.

Note: The job pod with the image name rancher/tekton-utils will be under the same namespace as the GitRepo.

  1. The fleet-controller then syncs changes from the bundle. According to the targets, the fleet-controller will create BundleDeployment resources, which are a combination of a bundle and a target cluster.
  2. The fleet-agent will then pull the BundleDeployment from the Fleet controlplane. The agent deploys bundle manifests as a Helm chart from the BundleDeployment into the downstream clusters.
  3. The fleet-agent will continue to monitor the application bundle and report statuses back in the following order: bundledeployment > bundle > GitRepo > cluster.

This diagram shows the different rendering stages a bundle goes through until deployment.

Bundle Stages

Examining the Bundle Lifecycle With the CLI

Several fleet CLI commands help with debugging bundles.

fleet apply

Apply renders a folder with Kubernetes resources, such as a Helm chart, manifests, or kustomize folders, into a Fleet bundle resource.

  1. git clone https://github.com/rancher/fleet-test-data
  2. cd fleet-test-data
  3. fleet apply -n fleet-local -o bundle.yaml testbundle simple-chart/

More information on how to create bundles with fleet apply can be found in the section on bundles.

fleet target

Target reads a bundle from a file and works with a live cluster to print out the bundledeployment & content resource, which fleetcontroller would create. It takes a namespace as an argument, so it can look in that namespace for e.g. cluster resources. It can also dump the data structure which is used during “targeting”, so decisions taken regarding labels and cluster names can be checked.

fleet deploy

Deploy takes the output of fleet target, or a dumped bundledeployment/content resource and deploys it to a cluster, just like fleet-agent would. It supports a dry run mode, to print out the resources which would be created, instead of installing them with helm. Since the command doesn’t create the input resources, a running fleet-agent would likely garbage collect the deployment.

The deploy command can be used to bring bundles to air-gapped clusters.

Lifecycle CLI Example

  1. git clone https://github.com/rancher/fleet-test-data
  2. cd fleet-test-data
  3. # for information about apply see https://fleet.rancher.io/bundle-add
  4. fleet apply -n fleet-local -o bundle.yaml testbundle simple-chart/
  5. fleet target --bundle-file bundle.yaml --list-inputs  > bd.yaml
  6. fleet deploy --input-file bd.yaml --dry-run