Skip to content
CxJ edited this page Aug 23, 2022 · 20 revisions

Welcome to the arlon wiki!

This wiki captures key facts about Arlon, feature specifications and discussions on new/potential features.

Arlon_logo_h_color_trans

What is Arlon?

Arlon allows you to build templated clusters in any cloud, complete with applications and Kubernetes Policies (RBAC, Network, Security), all from Git using Cluster API (CAPI) and ArgoCD. Arlon is the glue that brings brings CAPI and ArgoCD together, but it doesn't stop there. Arlon is the command and control, it's the service you interact with and the service that keeps everything operating and reconciled.

Imagine this.

You want to operate 8 identical clusters across 5 AWS regions, the only parameters that should change are the cluster names and the regions they're deployed in, and thats it.

You also need them to be deployed and contain several critical platform applications, such as Kafka, Redis, FluentBit, Elastic and Kibana. Finally, you want everything to bet GitOps compliant, that is, defined as Yaml (or Helm, Kustomize) stored in your git repository and deployed from there. This includes the clusters specification (Cloud, Region, Instance Types, Nodes Pools, K8s Version, CNI, + the unique changes like the clusters name) and the applications you want to install.

You also want to ensure that any changes on the clusters are reverted to the declared state thats in Git and that any intentional changes in Git are applied to all clusters simultaneously and consistently.

Thats a lot to manage!

First, how do you create the clusters?? EKS CTL? Terraform? EKS Console? none of these are GitOps compliant. Sure you can store the inputs to Terraform and EKS CTL in a Git repo, but you either need to script or manually apply the changes, and this is only the first cluster! How do you leverage a single configuration and template the values? You can use Kustimize but now you have to manage the files, and integrate them with Terraform or EKS CTL.

Next you need to automate deploying the platform applications and Kubernetes policies. To do this you need a continuous deployment tool, one way to do this is use Terraform (with the issues above) and add Flux or maybe Argo into each cluster, creating more to manage. Or operate a central tools cluster with ArgoCD running and once each cluster is built write a script to automate connecting them. Or just do it manually, but this breaks the GitOps approach.

Then come the apps, if their application manifests are in Git already then you don't have much to do. Just define the ArgoCD app or Flux deployment and go.

What happens when you want to change the cluster, maybe add a new node pool? Do you change that once or in multiple files? What happens when you have a new platform app you want to deploy to all the clusters? What happens when you want to add a new cluster in a new region? Or, what happens when one of the clusters starts misbehaving?? do you troubleshoot, or just 'click' go, wait for the new cluster to be ready and cut the traffic over.

This is what Arlon is being built to solve

Completely automated cluster management that builds complete clusters; not just the infrastructure, the cluster, your critical applications and the policies you need. Arlon delivers more functionality than terraform and as is as powerful as continuous delivery.
Arlon allows you to define the cluster, your applications and all the Kubernetes polices in Git, and then use open source tools to manage the entire lifecycle of the cluster, in any cloud, including the applications you deploy and the policies the cluster must run with. All without the need to manually create and template each of the objects.


Use the links below to navigate around the wiki.

Read more about Arlon

Read about the core Arlon features:

🚧 Linked Mode
Cloned Mode
Notifications
Diff and Pre-flight Checks
Enforcement Modes

Arlon Stages/Lifecycle

Active

  • 0.9.0 - > 🏗️

https://github.com/arlonproj/arlon/milestone/1 The current focus of Arlon is on adapting design decisions made in the PoC to be more gitOps compliant, support ClusterAPI CRs directly and enhance the CLI with context management. Feature Goals: Bootstrap and the full ClusterAPI for AWS.

Future

Each future release is planned out to an 8 week cycle. Releases may be rescoped in length based on effort estimates.

  • 0.10.0 - > ⏳

https://github.com/arlonproj/arlon/milestone/5

  • 0.11.0 - > 🗓️

https://github.com/arlonproj/arlon/milestone/7

  • 0.12.0 - > 🗓️

https://github.com/arlonproj/arlon/milestone/8

  • 0.13.0 - > 🗓️

https://github.com/arlonproj/arlon/milestone/9

Closed

2022/04/01 -> Arlon Proof of Concept

The Arlon PoC is a prototype client tool that works with ClusterAPI, argoCD and a cluster-side controller that will build clusters in EKS based on three base objects leveraging git as the declared source of truth. The objects include: clusterSpec (ClusterAPI or CrossPlane - Cloud, K8s version, nodes, SSH Keys), Bundles (Applications or K8s Objects) and Profiles (list of bundles).

Want to help build Arlon or looking to understand when a feature will land?

The table below contains the effort scope for issue sizing and time estimates

Name Effort estimate in man weeks
XS 0.5
S 1
M 2
L 3
XL 4
XXL 6