Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
devspace-plugin-loft
Loft Plugin for DevSpace - adds commands like `devspace create space` or `devspace create vcluster` to DevSpace
-
-
-
Alternatively, it is also possible to use a multi-cloud or hybrid-cloud approach, which combines several cloud providers or even public and private clouds. Special tools such as Rancher and OpenShift can be very useful to run this type of system.
1. Local Clusters: Local clusters are special Kubernetes versions made for running on the engineers’ computers, such as minikube or kind. As such, they are necessarily limited to the locally available computing resources and do not have all Kubernetes features that exist in the “real” Kubernetes running in cloud environments. The local runtime environment further makes it impossible to streamline the setup process, so that it needs to be done by the engineers themselves, which requires some k8s expertise.
For most companies, however, just buying an existing solution may be the better option because the setup is much easier and faster, you do not have to dedicate permanent development resources to improve the platform and because you will automatically get some best practices. At the same time, such a solution has only limited options for customization, which is why it may not be feasible to use for very specialized companies. One advanced off-the-shelf internal Kubernetes platform solution is loft. loft works with any Kubernetes cluster, it provides a GUI, a CLI and is fully based on Kubernetes CRDs. It also takes care of the user management, allows SSO and has some additional features such as a sleep mode to save cost by shutting down unused namespaces and vClusters.
1. Local Clusters: Local clusters are special Kubernetes versions made for running on the engineers’ computers, such as minikube or kind. As such, they are necessarily limited to the locally available computing resources and do not have all Kubernetes features that exist in the “real” Kubernetes running in cloud environments. The local runtime environment further makes it impossible to streamline the setup process, so that it needs to be done by the engineers themselves, which requires some k8s expertise.
To find these areas and to generally get a better understanding of your cost structure, e.g. which team causes which cost, you should monitor the cost. For this, tools such as Kubecost or Replex can be very helpful.
One question in this area is how the platform users’ authentication will work as they will need accounts to access it. There are several options to care for this part of the user management. The simplest is to let admins create the user accounts centrally. This is a good option if you have a relatively small team and not so much fluctuation. In larger teams, it makes sense to let users sign-on themselves, e.g. by allowing users with a specific email address to create new accounts, or by implementing a Single-Sign-on (SSO) system that uses the user management of another service you already have in place, such as GitHub. For the implementation of such a system, you might take a look at dex which is an OpenID Connect provider that connects to many different services, such as LDAP, GitHub, GitLab, Google, Microsoft, and many others.