-
Notifications
You must be signed in to change notification settings - Fork 14
Concepts & Terminologies
ArgoCD is a Kubernetes Native continues deployment engine that leverages application manifests that are stored in a Git repository to deploy users apps into a Kubernetes cluster. Arlon’s primary link to ArgoCD are Arlon Profiles which consist of independent, reusable units of configuration, Arlon Bundle. Example: a set of RBAC rules, a cluster add-on, or an application. A profile is a set of bundles. . Arlon constructs an argocd app-of-apps tree in Git from the cluster spec, profile, and bundles, it leverages the app-of-apps pattern, it doesn't try to replace it
This is where all objects are written for gitops for managing the clusterSpecs and Profiles in git. When a cluster is created the ClusterSpec is read from here, so too the Profile.
ClusterAPI is an open source project - a Kubernetes sub project - that is focused on providing declarative APIs to create Kubernetes clusters and manage cluster lifecycle.
Crossplane is an open source Kubernetes add-on to create & manage clusters via declarative workflows.
A Kubernetes cluster that hosts the following components:
- ArgoCD
- Arlon
- Cluster management stack e.g. Cluster API and/or Crossplane The Arlon state and controllers reside in the arlon namespace.
A configuration bundle (or just "bundle") is grouping of data files that produce a set of Kubernetes manifests via a tool. This closely follows ArgoCD's definition of tool types. Consequently, the list of supported bundle types mirrors ArgoCD's supported set of manifest-producing tools. Each bundle is defined using a Kubernetes ConfigMap resource in the arlon namespace.
A static bundle embeds the manifest's YAML data itself ("static bundle"). A cluster consuming a static bundle will always have a snapshot copy of the bundle at the time the cluster was created, and is not affected by subsequent changes to the bundle's manifest data.
A dynamic bunlde contains a reference to the manifest data stored in git. A dynamic bundle is distinguished by having these fields set to non-empty values: git URL of the repo Directory path within the repo The git URL must be registered in ArgoCD as a valid repository. The content of the specified directory can contain manifests in any of the tool formats supported by ArgoCD, including plain YAML, Helm and Kustomize. When the user updates a dynamic bundle in git, all clusters consuming that bundle (through a profile specified at cluster creation time) will acquire the change.
A bundle can also have a comma-separated list of tags, and a description. Tags can be useful for classifying bundles, for e.g. by type ("addon", "cni", "rbac", "app").
A cluster specification contains desired settings when creating a new cluster. They currently include: Stack: the cluster provisioning stack, for e.g. cluster-api or crossplane Provider: the specific cluster management provider under that stack, if applicable. Example: for cluster-api, the possible values are eks and kubeadm Other settings that specify the "shape" of the cluster, such as the size of the control plane and the initial number of nodes of the data plane. The pod networking technology (under discussion: this may be moved to a bundle because most if not all CNI providers can be installed as manifests) Profile Profile A profile expresses a desired configuration for a Kubernetes cluster. It is just a set of references to bundles (static, dynamic, or a combination). A profile can be static or dynamic.
When a cluster consumes a static profile at creation time, the set of bundles for the cluster is fixed at that time and does not change over time even when the static bundle is updated. (Note: the contents of some of those bundles referenced by the static profile may however change over time if they are dynamic). A static profile is stored as an item in the Arlon database (specifically, as a configmap in the Management Cluster).
A dynamic profile, on the other hand, has two components: the specification stored in the Arlon database, and a compiled component living in the workspace repository at a path specified by the user. (Note: this repository is usually the workspace repo, but it technically doesn't have to be, as long as it's a valid repo registered in ArgoCD) The compiled component is essentially a Helm chart of multiple ArgoCD app resources, each one pointing to a bundle. Arlon automatically creates and maintains the compiled component. When a user updates the composition of a dynamic profile, meaning redefines its bundle set, the Arlon library updates the compiled component to point to the bundles specified in the new set. Any cluster consuming that dynamic profile will be affected by the change, meaning it may lose or acquire new bundles in real time.
(Generated at runtime from the Cluster Specification) The cluster chart is a Helm chart that creates (and optionally applies) the manifests necessary to create a cluster and deploy desired configurations and applications to it. When a user uses Arlon to create and configure a cluster, he or she specifies a profile. The profile's cluster specification, bundle list and other settings are used to generate values for the chart, and the chart is deployed as a Helm release into the arlon namespace in the management cluster. Here is a summary of the kinds of resources generated and deployed by the chart: A unique namespace with a name based on the cluster's name. All subsequent resources below are created inside of that namespace. The stack-specific resources to create the cluster (for e.g. Cluster API resources) A ClusterRegistration to automatically register the cluster with ArgoCD A GitRepoDir to automatically create a git repo and/or directory to host a copy of the expanded bundles. Every bundle referenced by the profile is copied/unpacked into its own subdirectory. One ArgoCD Application resource for each bundle.