4.2 KiB
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:
- a Kubernetes cluster managed by Fleet
- a
Clusterresource in Fleet's API, which Fleet uses to manage that Kubernetes cluster
Continuous Delivery
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
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
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
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
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
Resources
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.