Glossary

In SUSE® Rancher Prime Continuous Delivery’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.

A bundle is a SUSE® Rancher Prime Continuous Delivery-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 SUSE® Rancher Prime Continuous Delivery from a path of a git repository.

See (Helm charts documentation.

A cluster refers to: * a Kubernetes cluster managed by SUSE® Rancher Prime Continuous Delivery * a Cluster resource in Fleet’s API, which SUSE® Rancher Prime Continuous Delivery uses to manage that Kubernetes cluster

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: SUSE® Rancher Prime Continuous Delivery’s goal is to make it easier to automate deployments.

See kubernetes custom resource official documentation. In short, a custom resource is a resource defined for the purposes of an application (in our case SUSE® Rancher Prime Continuous Delivery), to extend the set of resources supported by the Kubernetes API (pods, deployments, services, etc).

See kubernetes custom resource definitions official documentation from the Kubernetes docs.

A deployment may refer to: * a Kubernetes deployment, whether part of a user workload or part of SUSE® Rancher Prime Continuous Delivery itself, such as an agent deployment, controller deployments. * the action of deploying a user workload, which means SUSE® Rancher Prime Continuous Delivery reading configuration (GitRepo, fleet.yaml, etc) and, as a result, creating resources on target clusters.

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.

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 fleet.yaml.

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.

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

Refers to a Kubernetes label.

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

Refers to a Kubernetes namespace.

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.

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, SUSE® Rancher Prime Continuous Delivery is able to deploy workloads to that cluster.

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. SUSE® Rancher Prime Continuous Delivery 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. SUSE® Rancher Prime Continuous Delivery is able to install Helm charts and apply user-defined configuration to them.

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 SUSE® Rancher Prime Continuous Delivery itself, which defines GitRepo, Bundle, Bundledeployment and a few others.

SUSE® Rancher Prime Continuous Delivery uses this word in the context of determining where a workload will run. This represents a destination cluster for a workload.

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

A workload represents what users want to deploy through SUSE® Rancher Prime Continuous Delivery. 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, SUSE® Rancher Prime Continuous Delivery deploys workloads.