Launched in 2018, MetalK8s was launched to make it easier to run Kubernetes (K8s) on bare-metal servers that need persistent storage.
Version 1.1 was based on Ansible and kubespray, while 2.X (starting with 2.0) is based on SaltStack as its deployment orchestrator. That makes MetalK8s 1.1 and 2.X completely different, independent orchestration tools, each with its own pros and cons.
In addition, MetalK8s 2.X (of which 2.4 is the main dev branch) ships with a more recent Kubernetes version (1.15 is the latest). MetalK8s 1.1 ships with Kuberbetes 1.11, which is fairly old.
The three top features added to MetalK8s 2.X include solution lifecycle management, with support for upgrade and downgrade, volume management, and a simplified user interface for managing Kubernetes resources.
The biggest challenge our team has faced stems from the architectural rethinking and redesign for MetalK8s. Starting from scratch is never the easiest, but it was required here. Finding engineers to do the job well, financial resources to do the same, and then reinventing the model to match our unique use case needed enormous inspiration.
What are the differences between object, NAS and file storage?
MetalK8s documentation is readily available in the project repository itself, and there’s also an HTML version, here. This documentation covers architectural design, a developers guide, implementation guides, and an operational guide, all publicly available for all interested parties.
The newly-designed User Interface (UI) was created to make sure that non-technical users can interact seamlessly with MetalK8s without having the core knowledge of the underlying system or how all the bits and pieces connect “under the hood.” This carefully created UI offers users control of nodes, volumes, solutions, versioning, and much more in an intuitive, useful way.
The shift from MetalK8s 1.0 to MetalK8s 2.X is an enormous one. The new orchestration tool uses SaltStack to drive the orchestration of the entire platform, mostly because of its underlying flexibility. It makes it easier to extend the deployment chain and seems better than the earlier version.
The core purpose here is to give freedom and control for people who create value with data. Setting up a MetalK8s playground should be quick and simple. The new version boasts a better build tool that should have most users up and running in just a few minutes, a marked improvement on the earlier system.
As far as the MetalK8s project is concerned, Ansible/kubespray is a thing of the past. We feel the new approach today is driven more on redefining value for long term support for all of our other projects. The state of the art is changing and we have an obligation to re-invent our models to remain relevant for our users.
MetalK8s is under active development, mainly by Scality’s core team and as such we cannot share too many details concerning the roadmap for now. This will certainly need to change down the road and very soon. There haven’t been too many contributions from the open source community, but the team always welcomes contributions from the community.