Kubefirst v1.10 Release Notes: Intro to Kubefirst local

A cloud native ecosystem for everyone

Adopting Kubernetes and cloud native can be difficult and time consuming. Kubefirst's mission is to change this by producing cloud native platforms that are preconfigured, operational, and fully-automated from a single command. Throughout our project's history, we've focused our efforts on Kubernetes environments in public clouds. With our `kubefirst cluster create` command, your empty cloud will transform into a self-hosted open-source cloud native ecosystem running workloads in production in minutes instead of the months it would take to build from scratch.

With our new 1.10 release, we're excited to announce that the Kubefirst team has just unlocked an incredible new set of localhost capabilities with our new `kubefirst local` command. With Kubefirst local, you can now explore many of the best parts of the Kubefirst platform all running for free on a local k3d cluster in less than 5 minutes without costs or inputs.

The `kubefirst local` command was pretty challenging to pull off. Though we try hard to minimize our public cloud dependencies, we have historically needed the cloud quite a bit. For our new kubefirst local implementation, we wanted to remove the need for a cloud account entirely, so that you can explore kubefirst without any prerequisites or costs.

Installing or upgrading the kubefirst cli

To install kubefirst cli for the first time

`brew tap kubefirst/tools`

`brew install kubefirst`‍

To upgrade kubefirst cli:

`brew upgrade kubefirst`

Creating, destroying, and cleaning for kubefirst local

To create a new kubefirst locally run

`kubefirst local`

This will add 4 repositories to your github account. The gitops repo powers the kubefirst platform. The `metaphor`, `metaphor-go`, and `metaphor-frontend` repos are your example sample microservices.

To destroy everything when you're done run

`kubefirst cluster destroy`

To clean terraform state resources and content from your localhost

`kubefirst clean`

Similarities and differences between cloud and local kubefirst platforms

kubefirst local is similar to kubefirst cluster create in the following ways:

• Single command to install (4 minutes local / 25 minutes cloud)
• Single command to destroy (1 minute local / 10 minutes cloud)
• GitHub Actions still run in your cluster and invoke Argo Workflows for cloud native continuous integration capabilities
• Sample applications are still delivered to your github account to demonstrate GitOps delivery patterns to a development, staging, and production environment, including environment-specific secrets and config, container publishing, helm publishing, and automated chart version management
• Hashicorp Vault is still the exclusive source of truth for all secrets on the platform
• A GitOps git repository is still delivered to your personal github with a customized registry of applications delivered to your cluster using Argo CD
• All of the Terraform infrastructure as code and configuration as code is still managed with atlantis

So it's basically the same platform functionally, but architecturally we had to make adjustments to the platform in order to accommodate the local environment. Here are the architecture shifts we made for kubefirst local:

• The VPC is now your laptop
• The EKS cluster became an automatically installed k3d cluster
• S3 storage for state and artifacts became minio localhost storage
• ECR container storage became GitHub container storage
• Helm chart storage is still in chartmuseum but backed by minio
• Vault's dynamodb backend became minio s3 storage
• Vault kms encryption at rest was removed
• All ingresses/hostnames became port-forwards on your localhost
• GitHub teams were removed from the local story so we could support GitHub users as a repo owners
• Ngrok is automatically added to your localhost and started so that your new GitOps repo can webhook to your local cluster's Atlantis for automatic terraform plans and applies that run from within your local cluster
• There is a localhost variation of our argo workflow templates being used that accommodate the local environment changes to continuous integration

Implications of the local kubefirst platform

Having a local kubefirst is going to be interesting to watch unfold. We've seen firsthand the impact this is having on our own team. Platform engineering teams, much like our own, have a difficult challenge on their hands where they need to make regular changes and updates to their platform and test those changes with a reasonable pace for iterations.

If it takes 30 minutes to provision your platform, testing changes to that platform can be a time consuming engineering task. With kubefirst local, we'll be able to establish a foundational localhost cloud native platform that provisions in less than 5 minutes, and you can lay your add-ons on top of it. This will let you verify your platform updates in a live local environment much more swiftly, preventing your platform engineers from context switching between iterations.

Being able to pull down your entire CI/CD ecosystem into a parallel universe on your localhost is particularly exciting to us as well. If you could run a command and have your entire platform with all your apps all running on your localhost - with automated IAC, gitops, secrets, and CI, engineers will be able to reproduce complex setups without any influence on the live system in a way we've never seen before. We're excited to see how the community uses the new local features.

Kubefirst console moves into the cluster

In 1.9 we introduced kubefirst console MVP at the conclusion of a kubefirst cluster install running on your localhost. In 1.10, we're making the kubefirst console app a more permanent fixture in your cluster so you can always easily reach your platform tools. Moving kubefirst into the cluster introduces a new kubefirst-api backend component to serve as a foundation for some of our upcoming cluster management features.