kubeplus VS labs

We went through this migration/upgrade in our KubePlus project (https://github.com/cloud-ark/kubeplus). It has an embedded webhook in it, fyi.

You might want to check out - KubePlus (https://github.com/cloud-ark/kubeplus), which has already been referenced in the thread and is exactly designed for building managed application services. I am the originator and core contributor to this project. KubePlus is a Kubernetes Operator that takes an application Helm chart and represents it as a Kubernetes API (CRD) on the cluster. This API allows you to create instances of the application in separate namespaces automatically ensuring a secure perimeter around each instance using NetworkPolicy, Resource Quota, and RBAC. These soft multi-tenancy measures are already mentioned in the thread along with the namespace. KubePlus has automated all of them for you under an API. This API not only allows the creation of the application instances but also supports day-2 operations such as monitoring, troubleshooting, and upgrades to simplify the end-to-end functioning of any managed application service. We are currently seeing interest from teams that want to create managed services for different types of containerized applications, including open-source platforms such as WordPress, Moodle, Ozone/OpenMRS, AI/ML workloads, etc. KubePlus has been tested successfully with all (90+) Bitnami Helm charts. For anyone who wants to deliver a managed application with minimal / no Kubernetes access to their customers, KubePlus can help by accelerating the implementation of namespace-based multi-tenancy on Kubernetes. With the ability to set NetworkPolicy and Resource Quota per application instance, the blast radius is restricted, if something goes wrong in an application instance. KubePlus does not need admin permissions on your cluster. This makes it possible to use KubePlus to manage your application instances on your customer's cluster as well.

We have an FAQ about Operators here: https://github.com/cloud-ark/kubeplus/blob/master/Operator-F...

It should be helpful if you are new to the Operator concept.

Operators are generally useful for handling domain-specific actions - for example, performing database backups, installing plugins on Moodle/Wordpress, etc. If you are looking for application deployment then a Helm chart should be sufficient.

If you are currently delivering your SaaS as a separate instance of your application per customer, you might want to check out our open-source project KubePlus - https://github.com/cloud-ark/kubeplus

A more commerical offering is from Cloudark who have designed a specific solution for operating your Helm application as a SaaS offering. I have never used it (ArgoCD being my poison) but you might find it fits your usecase better

As part of your data platform are you planning to create a separate instance of the database for your end customer? If so, you might find our KubePlus Operator helpful. Check it out here: https://github.com/cloud-ark/kubeplus

We have been helping organizations build such multi-instance multi-tenant cloud-native applications. We start with an application Helm chart and create separate release of it per customer/user of that organization. We have an open source Kubernetes Operator that aids in this: https://github.com/cloud-ark/kubeplus

You might also want to checkout Operator guidelines and Operator FAQ: - Operator Maturity Model guidelines: https://github.com/cloud-ark/kubeplus/blob/master/Guidelines.md

The project that is getting some traction recently is our KubePlus Operator that delivers Helm charts as-a-service: https://github.com/cloud-ark/kubeplus

Cool! I would be interested in knowing how it goes. From experience one thing I would like to mention is to give due consideration on how you model the Spec properties of your Custom Resource. Say, for user creation, you could take just user names as input or you could take the actual command to create user as input. If you do latter then the Operator essentially just acts like a pass-through for running whatever commands that are provided in the Spec. While this might seem appealing, especially since you are targeting multiple different databases, it is also problematic since such an approach is not 'declarative'. For a purely declarative approach you want to just take the names of the users to be created as input and not the actual command. The command should be part of the Operator's implementation. Advantage of such a declarative approach is that if say the Custom Resource users were to re-apply a Custom Resource, then your Operator will be easily able to determine if from the provided usernames, which ones already exist in the underlying database and which ones need to be added new. Btw, the reason I say from experience is because we made this mistake while implementing our Postgres Operator. Here is an example Custom Resource YAML from our Operator for reference - https://github.com/cloud-ark/labs/blob/master/postgres-crd-v2/artifacts/examples/add-user.yaml . Originally we were taking complete commands as input and ran into problem when determining the diffs.