rancher
/
fleet-docs
mirror of https://github.com/rancher/fleet-docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
fleet-docs/docs/glossary.md

6.2 KiB
Raw Permalink Blame History

Glossary

Agent

In Fleet's context, an agent is a Kubernetes deployment responsible for deploying workloads to its cluster. This entails monitoring a specific namespace on the upstream cluster, and deploying any bundle deployments, living in that namespace, to the downstream cluster where the agent lives.

Bundle

A bundle is a Fleet-specific resource (also known as a Custom Resource in Kubernetes) representing a workload, or set of user resources, to be deployed. It is typically generated by Fleet from a path of a git repository.

Chart

See this definition of a Helm chart.

Cluster

A cluster refers to:

Continuous Delivery/Deployment

Definitions and distinctions between Continuous Delivery and Continuous Deployment greatly vary, for instance depending on:

  • whether the deployment step is included in the process, and to which environment: production or other?
  • what triggers a deployment: is it a manual or automated step?

This much is clear, though: Fleet's goal is to make it easier to automate deployments.

Custom Resource

See this official definition. In short, a custom resource is a resource defined for the purposes of an application (in our case Fleet), to extend the set of resources supported by the Kubernetes API (pods, deployments, services, etc).

Custom Resource Definition

See this explanation from the Kubernetes docs.

Deployment

A deployment may refer to:

  • a Kubernetes deployment, whether part of a user workload or part of Fleet itself, such as an agent deployment, controller deployments.
  • the action of deploying a user workload, which means Fleet reading configuration (GitRepo, fleet.yaml, etc) and, as a result, creating resources on target clusters.

Downstream Cluster

A downstream cluster is a Kubernetes cluster where user workloads will run, without any Fleet controllers living there. It is a target cluster for Fleet, where only a Fleet agent lives beside user workloads.

fleet.yaml

A fleet.yaml file lives in a git repository and stores options for a bundle and bundle deployments to be generated from that bundle. More information is available here.

GitOps

GitOps refers to git-triggered operations, where git is the source of truth and changes to a git repository lead to changes being applied to the state of one or more clusters.

GitRepo

A GitRepo is a Fleet-specific resource, to be used as an entry point to using Fleet. Creating a GitRepo pointing to a set of paths in a git repository enables Fleet to monitor those paths and deploy resources stored or referenced there.

Label

Refers to a Kubernetes label.

Multi-Cluster

A multi-cluster setup involves more than one cluster: the upstream cluster, needed to manage deployment of workloads, and at least one downstream cluster.

Namespace

Refers to a Kubernetes namespace.

Reconcile

Reconciling is used in the context of states in Kubernetes clusters. Reconciling a resource means updating it so that its actual state matches its expected state, be it from configuration, eg. from a git repository, chart, etc.

When using GitOps, updates to a git repository may translate into new expected states for resources configured through that git repository. As a result, affected resources will be reconciled. A resource's state may also depend on another resource, leading to additional reconciliation. For instance, a cluster group's status depends on statuses of individual clusters contained in that cluster group. Therefore, a change in a cluster's state will result in any cluster group(s) to which that cluster belongs to being reconciled as well.

Registration

Cluster registration is the process of getting a Fleet agent, living in a downstream cluster, recognised by Fleet controllers in the upstream cluster. Once registration is complete for a downstream cluster, Fleet is able to deploy workloads to that cluster.

Repository

A repository may be:

  • a git repository, storing code, configuration or any kind of files and keeping track of changes made to those files through commits. Fleet can monitor a git repository for new commits pushed to a specific branch or revision, at one or more paths, through GitRepo resources.
  • a Helm repository, hosting Helm charts and an index file referencing them. Fleet is able to install Helm charts and apply user-defined configuration to them.

Resources

This usually refers to Kubernetes resources, which may be:

  • core resources defined by Kubernetes itself, such as config maps, deployments, pods, services, etc
  • custom resources defined by individual applications, such as Fleet itself, which defines GitRepo, Bundle, Bundledeployment and a few others.

Target

Fleet uses this word in the context of determining where a workload will run. This represents a destination cluster for a workload.

Upstream Cluster

A Kubernetes cluster where Fleet controllers run. This is the cluster where GitRepos, bundles and bundle deployments are created. Also called management cluster.

Workload

A workload represents what users want to deploy through Fleet. It may be a set of Helm charts, Kubernetes manifests, kustomize, etc, stored or referenced in a git repository.

When a user creates a GitRepo resource pointing to that git repository, and subsequently when relevant changes are found in that repository, Fleet deploys workloads.