It’s Alive! The Rise of the FrankenCluster
To begin with, what even is a FrankenCluster? Well like anything that is prefixed with “Franken,” it is a cluster that is built or modified with components that make it unnatural (or grotesque). The cloud native space has exploded with a myriad of component options for platform builders; this is both a blessing and a curse.
The blessing is that there are options for all shapes and sizes of clusters, including myriad fantastic technologies. The curse, unfortunately, comes in when choosing the correct components, the Cloud Native Computing Foundation landscape is a fantastic first stop for finding a project that is labeled by technical category. But then it’s down to the builder to do their due diligence, which from experience doesn’t happen all that often. On occasion, I’ve come across clusters that have been created using a bleeding-edge project that a builder heard about on Twitter (Is that tweet-driven infrastructure 🤔?)
This image exists for a reason
How Did We Get to FrankenClusters?
It is a recurring theme within the IT industry, if we cast our minds back to the dark ages. It was a simpler time when a system administrator would maintain a number of servers by hand. These servers were so individual that they would normally be named after characters from Lord of the Rings or the Simpsons. Each server would have a single use. Marge was the database or Gandalf was the message queue and their maintenance was intrinsic knowledge that only a specific system administrator held.
This was great until server farms exploded in size, and then exploded even further with virtual machines and suddenly Homer was likely to be named something like lon-db-vm-small-01. A small team of administrators would simply drown trying to manage hundreds or thousands of artisanally-crafted server instances, so something had to be done.
Between automation tooling and IaC (Infrastructure as Code), most Ops teams reached a panacea of control, allowing for fleets of machines to be created, standardized, controlled and eventually decommissioned. For Kubernetes, this is still an ongoing journey, which has unfortunately left some end-users in a very precarious situation. A graveyard of projects exists that were initially created to make the deployment of clusters easy.
Unfortunately, early adopters of this tooling are now left with unsupported clusters or large technical debt trying to keep this abandoned tooling up to date with Kubernetes releases and the required add-on projects. Luckily a number of battle-hardened folks realized that this problem wasn’t going to go away by itself and after what I can only imagine was many late nights in the Special-Interest-Group for cluster lifecycle the Cluster-API project was created.
The Need for a FrankenCluster
We can mitigate the proliferation of random cluster sprawl by simplifying the deployment and ensuring that we manage the lifecycle of clusters. However, more often than not a one-size-fits-all approach won’t work for all use cases.
As new businesses and technologies adopt Kubernetes as their platform of choice, they will often find that off-the-shelf Kubernetes distributions aren’t flexible enough for their requirements. The adoption of 5g and telcos re-platforming to Kubernetes forced a number of distributions to adopt and support new networking technologies, however, not everyone will have the sway to force these changes.
This leaves a builder with the options of pushing a distribution out of support by modifying it to meet the needs of the application or building a FrankenCluster.
This ultimately leaves the business with a number of standardized clusters with support contracts and a number to call in the event of issues, and a FrankenCluster that a long-gone engineer built one weekend that no one understands or can support. The business either has to accept this technical debt (and hopefully hire or train internal support) or with enough bargaining (and money changing hands) convince their distribution of choice to adopt their FrankenCluster.
Standardize Clusters for End Users
In a past life, I’ve had the opportunity to work with various end-users to help design, implement and support their clusters. There were often times when a single company would have multiple clusters that in terms of architecture looked worlds apart. As is usually the case, we are encouraged to move fast and when a developer screams at Ops to provide a platform to run their app they will often hit a roadblock.
Roadblocks come in all shapes and sizes, from no available resources to being unable to provide the functionality that the developers require. The outcome for most Ops teams when hitting these roadblocks is to use some sneaky “Shadow IT.” Well, we’re now starting to see “Shadow Clusters.”
There have been times when an application team (including developers and Ops) have been tasked with creating the next version of their application and what they’ve delivered is not only the application but also a whole cluster that is now the platform for their application. Handing this over to a perplexed and overstretched support team isn’t going to win you any favors, but it’s too late to go back at this point … and here we are, with new random clusters appearing all over.
The Cluster-API project aims to alleviate some of those problems by providing a sane interface to the lifecycle of a cluster, namely creation/scaling/upgrading and deletion. This interface is extensible through the provider model, which means that all clusters would look the same regardless of where this cluster is created — such as in the cloud, edge or on-prem. That same applications team would now be able to create a “managed” cluster that can be controlled through its entire lifecycle.
This ideally starts to simplify the roadblocks, while providing standardized and managed clusters that can be quickly deployed. However, we can go even faster to provide developers with the environments they need to develop and test their applications!
The vcluster project from Loft Labs takes quick cluster deployments to the next level, allowing a developer to create brand new Kubernetes clusters (of differing versions) within an existing Kubernetes cluster. With both of these projects together we can quickly stand up a physical cluster in various environments and then create numerous virtual clusters that developers can consume to their heart’s content!
Conclusion
Originally I was thinking that perhaps FrankenCluster was the wrong term, perhaps Kubernetes expert Betty Junod was correct in her preference to call it “snowflake cluster” instead.
But then again most things start out as beautiful “snowflakes.” Even Dr. Frankenstein didn’t set out to originally create a monster. Although when he finally looked upon his creation his first impulse was to run away and honestly if I was asked to support a handcrafted EOL Kubernetes cluster made from long abandoned projects with no lifecycle automation, I’d probably choose to go live amongst the animals in the wilderness too.
Projects like Cluster-API (which recently went to v1.0+) are here to hopefully stop this from happening in the future. Simplifying the process to get a cluster deployed should hopefully stop the requirement for people creating their own “snowflakes.” Also projects like vcluster allow developers and operations to segment an existing cluster into numerous clusters, meaning developers can get the resources that they need without having to resort to “Shadow Clusters.”
There is always going to be a need for bespoke clusters for esoteric use cases, but if we can keep the numbers low we’ll make everyone’s lives easier. Everyone loves a snowflake (especially me as I’m a keen, but not very good snowboarder), but they probably don’t want to support one.