We are launching Arlon – a Kubernetes native tool for complete end-to-end cluster configuration and lifecycle management, security policy and application, using a declarative approach.
In this post, I will discuss why declarative management of infrastructure is important for your Kubernetes clusters, challenges around Kubernetes cluster lifecycle management and how the Cluster API (CAPI) project addresses it. Learn the approach Arlon takes towards solving these problems.
“It Works On My Cluster”
As Kubernetes deployments are starting to scale, enterprises are starting to deal with a chaotic environment of cluster and workload sprawl.
The problem looks something like this – distributed dev and ops teams within a large company start deploying multiple Kubernetes clusters – across their local workstations, data centers, public clouds, edge sites, and at times, on-premises at end-customer sites.
Clusters deployed by different teams are created using a combination of homegrown automation, hand-crafted clusters, or using tools like kubeadm. This divergence in how the clusters are deployed means that the desired configurations are not fully replicated across different clusters. So, different clusters may not meet the same configuration for node size, autoscaling, networking, and RBAC policies that are critical for governance and security.
The result? Bugs that appear only on production sites and that are not replicated on dev or staging. The issue is not with the app, but the configuration of infrastructure on which the app is running.
The Benefit of the Cluster API
The CAPI project helps address some of the challenges mentioned above. The project uses Kubernetes-style declarative APIs and constructs to fully automate cluster lifecycle management, across a broad range of infrastructure and public cloud options. This means operators can define their clusters using the familiar yaml format, then use the CAPI tooling to deploy the clusters.
Today, CAPI is a key Kubernetes project with many users and contributors.
The Cluster Creation Assembly Line Problem
While the CAPI project makes a significant contribution towards simplifying the cluster creation problem, it does not fully address the problem of creating what we call “complete clusters” in a repeatable and predictable manner. Let me explain why.
In a typical large organization, the creation of a production Kubernetes cluster that is considered “ready” to deploy production applications is a multi-step process. The cluster infrastructure configuration is only a part of this process. The cluster must go through several steps of processing before it’s ready for prime time.
For example, let’s say that you are using AWS for all your k8s deployments. Once the basic cluster is created with the right infrastructure configuration,
- The DevOps team needs to ensure that the right observability tools are deployed on it to ensure correct monitoring for the cluster.
- The Security team must ensure that the cluster has proper access control rules configured, that network security policies are set up properly, etc.
- The App Developers must ensure that the prerequisite middleware applications that the application relies on are installed.
- Finally, the application itself gets deployed on the cluster and is launched.
The greater the number of steps, the higher the likelihood of things going wrong in the middle if not properly automated, especially at scale.
Existing CD tools like ArgoCD or FluxCD focus primarily on solving the problem of deploying applications on a cluster. They do not get into the process of creating the cluster itself. As a result, operators build homegrown solutions to address this problem.
Introducing Arlon – Your Assembly Line To Manage Complete Clusters
We created Arlon to solve the above problem, using standard open source components for cluster lifecycle automation and continuous delivery.
Arlon consists of three key components:
- Declarative Cluster Lifecycle – This is handled using Cluster API
- Continuous Delivery – This is handled using ArgoCD
- Continuous Reconciliation – This is handled by Arlon
Essentially, Arlon lets you leverage current open source standards for declarative cluster lifecycle management and continuous delivery, and in turn, gives you a complete cluster creation assembly line.
What Arlon Does
Arlon introduces the following concepts:
- A Cluster spec: A Cluster spec is a description of the cluster infrastructure and external settings of a cluster. Kubernetes version, cloud provider, cluster type, and node instance type are some examples of properties that are captured in a Cluster spec.
- A Profile: A Profile is a grouping of configuration bundles that will be installed into the cluster
- A Configuration bundle: A Configuration bundle is a unit of configuration that contains, or references, one or more Kubernetes manifests. A bundle can encapsulate anything that can be deployed onto a cluster: an RBAC ruleset, an infrastructure add-on such as Prometheus, an application, etc.
How Arlon Works
Arlon is composed of a controller, a library, and a CLI that exposes the library’s functions as commands. In the future, we have plans to build an API server that uses the Arlon library behind the scenes.
Arlon requires a “management cluster” that will have all the required tooling, along with Arlon custom resources installed.
Sample Arlon profile:
description: sample profile number 4
- bundle: monitoring
- bundle: monitoring
- bundle: monitoring
Next Steps. Get Involved!
This recorded video provides a detailed overview of how Arlon works, with examples:
We would love to hear your feedback on Arlon, what features you’d like to see added, and what use cases you’d like to see supported.
- Introducing Arlon! Your Kubernetes ClusterManagement Assembly Line - September 20, 2022
- Watch My GeekWire Talk: Not Your Mother’s Cloud – Best Practices for Enterprise Hybrid Cloud - July 3, 2018
- Kubernetes Networking: Achieving High Performance with Calico - April 17, 2018