CRDs in the Cluster

12 Dec, 2023

My Repo for this project can be found at k8sFMS

Embarking on a recent project, I have explored the full potential of Kubernetes within the realm of application development. Specifically, I have crafted a bespoke Kubernetes Flight Management System (K8s FMS) that intricately utilizes the Kubernetes API to dynamically manage objects within the cluster. This innovative approach allows for the orchestration of various decisions, such as the addition or removal of defined objects, effectively utilizing the Kubernetes etcd data store as a central database for the application.

In this blog, I will delve into the intricacies of this project, shedding light on the thoughtful design choices and considerations that have gone into creating a robust and scalable Flight Management System for a basic airline. While the application is not deemed "production-ready" at this stage, it serves as a compelling thought experiment, offering insights into how one might approach the design and implementation of such a system.

Central to the architecture is an exploration of Custom Resource Definitions (CRDs) and their pivotal role in extending application capabilities within the Kubernetes ecosystem. CRDs essentially define custom objects within Kubernetes, enabling the creation of specialized entities. This brings us to a fundamental question: How does this concept translate into practical utility?

Consider the scenario earlier this year when United Airlines experienced a system-wide outage, leaving countless passengers stranded at airports nationwide for several days. While speculation arose attributing this incident to outdated systems, its veracity remains unverified and isn't the focal point of this discourse.

This event triggered a thought: envision a Flight Management System built on a modern framework like Kubernetes. Motivated by this, I embarked on the endeavor of conceptualizing such a system.

The crux of my design revolves around the inception of diverse Custom Resources, defined through CRDs. These specifically crafted Custom Resources encompass Airlines, Spokes, Hubs, and Flights. Within this framework, each Airline is tethered to a central hub airport, serving as the primary transit point for numerous flights. For instance, Delta Airlines operates a hub in Atlanta, Georgia, facilitating various flight connections. Spokes denote smaller airports linked to their respective hubs, forming a network of travel routes. Flights are defined as objects delineating travel between airports.

IaC in my home lab

Subsequently, I architected a Python application, tailored to operate as a Terminal User Interface within a Kubernetes pod. This application empowers users to create, access, and visualize these objects, presenting them in an organized, list-based format. Functionally, the Python application interfaces with the Kubernetes API, leveraging a service account with restricted permissions within its namespace. Furthermore, I encapsulated this entire solution into a Helm chart, streamlining deployment for interested contributors or viewers.

While developing the application in Python, I utilized the Python Kubernetes client to interface with the Kubernetes kubeconfig. This kubeconfig is constructed through a script executed within an init container, utilizing the attached service account to create the kubeconfig and grant the Kubernetes client access to permitted objects via the Kubernetes API.

To craft the Terminal User Interface of the application, I used Textualize, a Rapid Application Development framework for Python developed by Textualize.io. This framework, along with the Python Kubernetes client, provided the necessary tools to create custom objects within my Kubernetes cluster and present them in a beneficial manner to the user.

In the future it would make since to expand this system to a front-end web interface mirroring the capabilities of the existing Terminal User Interface but accessible through a browser. While the initial focus of this project was on the terminal interface for expedited development, a future iteration could seamlessly integrate a browser-based interface. This addition would not only enhance user convenience but also eliminate the need for individuals to execute commands within a pod.

Now, let's talk about how the terminal interface is structured. When the user initially runs the application, it displays a home screen with a footer that acts as a menu to get to other pages. Each of these screens are tied to viewing a specific custom resource: flights, hubs, spokes, or airlines. There is also a create screen to initiate the creation of new flights, hubs, spokes, or airlines. I will display each of these screens below:

App Screens: