Powerful K8s Management with Physical & Virtual Clusters

This is it, the moment you were all waiting for. Our most ambitious release in kubefirst’s history. The next steps in a glorious Kubernetes journey! You guessed it; the addition of physical multi-clusters and virtual clusters support.

With the 2.3 release, we are taking kubefirst from a tool creating a production-ready management cluster with the cloud native tools you like, and that we firmly believe you need to be successful, and turning it into a full-fledged cluster management platform (see what I did there?).

Physical Workload Clusters All the Way

Before 2.3, when you created a cluster using kubefirst, it was creating what we called, a management cluster: a cluster with the centralized tools you need to manage your cloud native platform. For simpler scenarios, you could definitely use it as your workload cluster, but we know that in most cases, you need multiple clusters, either for multiple parts of your platform, for different environments (development, staging, production), blue/green deployments or for different products. In all those cases, one cluster wasn’t enough. The good news is that it’s all things of the past! With 2.3, we added the physical multi-cluster support, meaning that you can now, on Civo (other cloud support will be added as soon as possible in the 2.3.x versions), create new workload clusters directly from the console UI of your new management cluster.

To do so, you’ll need to upgrade your CLI using the following command:

brew upgrade kubefirst

For other operating systems, please check the documentation for other installation options. Note that it’s not possible at the moment to upgrade from an existing cluster created with a previous version of kubefirst.

To do so click on “Add workload cluster”: a new pane will open to the right. You will have to define some information about the physical cluster you want to create:

• Cluster type: be sure to select “Physical”.
• Environment cluster will host: the environment the new cluster will be attached to.
• Cluster name: add a significant name to easily distinguish between the clusters.
• Cloud region: here, you can choose a different region than other workload clusters or even from the management one. Perfect to cater to a different geographical audience.
• Instance size: for now, we limited the option to a large RAM Optimized size, but we’ll soon add all the instances offered by Civo in patch releases.
• Number of nodes: you can select the number of nodes you want.

Now, press the “Create cluster” button, and let the magic happen. You’ll notice that as soon as you start adding a new cluster, it will appear in the list or graph view, but they won’t be created until you say so.

vCluster, as in Virtual Clusters

When we say the word cluster, by default, we all think about physical ones, but did you know that there is a technology developed by Loft Labs called vCluster, which is short for virtual clusters. The minute we learned about this technology, we decided to implement it into kubefirst, and the good news is that you don’t have to wait: it is available in all clouds we support (except k3d, for now).

So what is a virtual cluster? They are fully functional Kubernetes clusters, but virtual, which run inside a namespace of the underlying physical one. In kubefirst case, it will run in the management cluster. There are a lot of advantages to this technology: it's cheaper than creating separate full-blown physical clusters, it offers better multi-tenancy and isolation than regular namespaces, in addition to being faster to create in any cloud. We saw immediate advantages to it, specifically for development clusters.

To do so follow the same steps as with a physical cluster, by selecting the virtual cluster type this time. You won’t have to select the cloud region, and instance size.

Workload Clusters, Your New Playground

The three virtual clusters created by default (within the management cluster) are what we call workload clusters: the clusters used to add your enterprise applications, and manage the… workload. You will also be able to create physical workload clusters. If you used kubefirst, you may have used the management cluster, the cluster we created for you, as the only entity managing the cluster, and the workload. From now on, we highly suggest that the management cluster be used only for tools needed to manage your entire cluster ecosystem, and move anything else toward workload ones.

By design, those clusters won’t have as many applications set up initially like we do with the management one. It’s because they are integrated with your management cluster. Argo CD will continue to manage your cluster configurations stored in your `gitops` repository, including the new workload clusters. These clusters will also have access to the management cluster’s HashiCorp Vault instance so the authentication, and secrets management will be accessible everywhere. At creation, the management cluster will create 3 environments for you: development, staging, and production. You’ll be able to attach workload clusters to them, or create new ones as needed.

By default, the workload clusters have cert-manager, Ingress NGINX Controller, Kubernetes ExternalDNS, Kubernetes External Secrets Operator, and Reloader installed, and configured. Note that for this release, the GitOps Catalog won’t be available on workload clusters, but we plan to add that soon.

What’s next

With all these new features, comes the commercialization of kubefirst. We are, and will stay dedicated to open source, and making cluster management affordable, but as much as we love our jobs, we need to pay the bills, but bear with me, you’ll see how reasonable we are.

For now, while the physical multi-clusters feature is in beta, it is free. Even after we change its beta state, it will stay free unless you use a newer version of kubefirst. So we guarantee you that it’s not a “fall in love with multi-clusters when it’s free, and pay later” scenario. Even when we start to charge for cluster management, it will be for managing your clusters using our console application, our user interface. If you fancy doing things by yourself manually without any help on our side, we won’t charge you for that, isn't it fantastic? More information in the pricing page.

As for the virtual cluster… they are free… forever! Yes, we know how it is important to be able to properly test our platform, and provide the tools your development team needs without having to pay excessive bills.

On the subject of open source, as mentioned above, we will stay primarily an open source shop, and kubefirst, the open source platform, will too. The only slight change we are making is that now some features using our commercial API are now implemented in a private repository, meaning that you can still enjoy the open source version of kubefirst, if you do not plan to use the UI for cluster management: you can still use it for creating a new management cluster. I know some of you were curious about our monetization plans, and the seriousness of our projects, so we wanted to be transparent about what’s coming. We hope that, like us, you see how we can be a great open source citizen and provide business values while still being able to be profitable.

About the next patch releases, we still have a lot of things on our plate. We want to quickly add physical multi-clusters support to the remaining clouds, while moving out of beta Google Cloud, DigitalOcean, and Vultr. We also have plans for minor releases to implement applications, and users’ management directly from the UI, so that adding users and apps to kubefirst is as easy as we’ve made GitOps cluster creation!

As always, we are looking forward to hearing about your experience with this new release, or any feedback about what’s coming up, so join the fun on our Slack community.