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.
To install kubefirst cli for the first time
`brew tap kubefirst/tools`
`brew install kubefirst`
To upgrade kubefirst cli:
`brew upgrade kubefirst`
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`
kubefirst local is similar to kubefirst cluster create in the following ways:
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:
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.
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.