Do we really need yet another Managed Kubernetes service?

In discussions, we often face the question whether we truly need another Managed Kubernetes service provider.

In general, my answer to that is: yes! We need different approaches. Allow me to outline the factors that differentiate our service, metalstack.cloud, from others:

✓ Focused expertise: We concentrate on providing a developer-friendly and GDPR-compliant Managed Kubernetes service. Rather than offering a wide range of services like VMs and numerous databases, we dedicate ourselves to doing one thing exceptionally well.

✓ Bare-metal resources: Our service utilizes bare-metal resources as the foundation for further services. This approach is particularly beneficial for workloads that require native performance or demand exclusive server access due to regulatory requirements.

✓ German-based servers and team: Both our servers and team are located in Germany, providing you with the opportunity to establish dedicated contracts with us regarding data protection and service levels.

✓ Security out of the box: All our clusters come with built-in security measures enabled by default. Additionally, you have the option to encrypt persistent volumes with your own key, enhancing the security of your data.

However, these are just the highlights. Let's dive deeper into our distinguishing features.

Identity and Access Management

When you want to set up a Kubernetes cluster at a cloud service provider (CSP), you are faced with at least two questions regarding identity and access management (IAM):

• How do developers get access to the CSPs API a.k.a. order resources from a CSP?
• How are permissions managed within a Kubernetes cluster?

This is often done either with an IAM infrastructure of the CSP, or with an integration to systems like KeyCloak, LDAP, AD. That's really cumbersome – if you look at AWS policy files – that's difficult to write, maintain, and keep error-free. At metalstack.cloud we simply use GitHub for the first IAM question. With a social GitHub login flow, you can access our platform, and team membership and rights can be managed within GitHub – we saw this implemented by tailscale in this way, and we wanted to follow the same approach because it felt quite appealing. You have a personal space as well as spaces for the different organizations you are part of on GitHub. If a GitHub user is the owner of a GitHub team, he can manage billing settings and also create clusters on our platform.

For the second question, metalstack.cloud follows the default practice of the industry: users get a fully fledged kubeconfig for their cluster that is valid for eight hours. We did not want to couple that to the rights on GitHub because it's very dependent on the application use case you have. If you want to further customize that, configure a ServiceAccount for different cluster users or use OPA.

Security by default

Did you ever try to configure a Kubernetes cluster in a more secure manner? It takes some time to configure it all: VPC a.k.a. private node IPs, an internet gateway, firewall rules. It's cumbersome to set up and maintain, and it eats up scarce DevOps time and nerves.

We want to provide native performance with good separation to other customers: so we went to build our system on bare metal so your Kubernetes nodes are physical bare-metal machines, and we have an open-source bare-metal provisioning system underneath (metal-stack with SONiC and BGP) to separate clusters from a network perspective. This is nice to get away from risks like CPU bugs in shared hypervisor environments, and you don't need to use snake oil like TPM or secure enclaves.

With every metalstack.cloud cluster, you get a VPC with private worker nodes, an internet gateway, and firewall rules managed in a Kubernetes-native way.

Even more Security

If you require further regulation of incoming and outgoing traffic for your cluster, you can deploy ClusterwideNetworkpolicy manifests, which enforce rules on your cluster-dedicated firewall.

Ever wondered where packets are dropped in a Kubernetes cluster? Nowadays, with Cilium and Hubble there is good possibility to observe such drops within a cluster, but how does it look at firewalls in front of your clusters? On metalstack.cloud you can get insights about events at your dedicated cluster firewall with stern -n firewall *.

In the event that the default security measures are insufficient, we offer additional options. You can choose to protect your persistent volumes with your own key (BYOK: bring-your-own-key) by using storageClassName: encrypted.

The Full Managed Kubernetes Experience

As a Managed Kubernetes service provider, we take care of the entire lifecycle of Kubernetes clusters. This includes:

• API-driven cluster management, treating clusters as cattle rather than cats.
• A highly available control-plane.
• Replicated persistent volumes.
• Auto-updates of the worker node operating system during a user-specified maintenance window.
• Auto-updates of Kubernetes patch versions during a user-specified maintenance window.

We strive to provide a comprehensive and hassle-free Managed Kubernetes experience, ensuring that you can focus on your core business and leave the operational complexities to us.

In conclusion, metalstack.cloud offers a developer-friendly, GDPR-compliant Managed Kubernetes service with a distinct set of advantages. From our focused approach and use of bare-metal resources to our emphasis on security and comprehensive management, we are committed to delivering a high-quality service tailored to your needs.

Test metalstack.cloud

We are looking for beta testers to help us improve metalstack.cloud. As a beta tester, you will have the opportunity to experience the platform firsthand, free of charge and without obligation, and to provide us with valuable feedback. We are eager to hear your suggestions and ideas to improve and perfect metalstack.cloud.

If you are interested in participating in our beta program, visit metalstack.cloud and sign up today. No credit card needed!