capsule VS kubeplus

At the end is just a tool which helps to achieve multi tenancy(with all pros and cons) in Kubernetes. It takes a different approach from capsule for example as you have a dedicated control plane for each tenant which means you have an isolated api server that you can spin up in a matter of seconds and lets you also achieve better resource utilizations by using the same nodes shared among all tenants

For multi tenancy you could use this: https://github.com/clastix/capsule

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

I don't think there are any default values set for both cpu and memory. But by explicitly adding Pod cpu and memory resource requests and limits, you can ensure that K8s will grant that much resources to your application Pods. In case your application is available as a Helm chart, you can use our project KubePlus (https://github.com/cloud-ark/kubeplus) to define cpu and memory resource requests and limits at Helm chart level. KubePlus will mutate the Pods that are part of a Helm release to include the configured policies. The project README has an example. A detailed example is here: https://cloud-ark.github.io/kubeplus/docs/html/html/index.html

When you say capacity planning, can you elaborate on some use-case(s) that are being targeted with this feature? Is the idea that knowing the actual usage directly from the scheduler can help deployers, either from outside the cluster or in-cluster via GitOps, make informed decisions such as configuring node selectors on any future Pods? The reason I ask this is - in our project (KubePlus - https://github.com/cloud-ark/kubeplus ) we support Node selector policies at Helm chart level. This enables, for example, to create a Helm release on a specific worker node. Currently KubePlus is not using any metrics data to decide whether a particular node has enough spare capacity to accommodate the incoming Helm release. If the Pod metrics are available from the scheduler then we can correlate those with the nodes on which the Pods are running and then decide whether a node has enough remaining capacity to support the resources of the Helm release.

Kubernetes Operators FAQ: https://github.com/cloud-ark/kubeplus/blob/master/Operator-FAQ.md

Good to know that you are developing an Operator for this custom automation to be run inside the cluster. While Operators initially were targeted towards managing some stateful application's life-cycle in Kubernetes-native manner on the cluster (such as a database), now-a-days their scope has extended to handle automation for the cluster itself (like what you are doing) and to perform reconciliation actions on things that are outside the cluster as well (think provisioning of cloud managed services). So you are on the right track here. And since you mention that you might be looking for some feedback on the Operator once it reaches some level of completeness, I thought of sharing following pointers that can help while you are developing your Operator: 1. Operator FAQ: https://github.com/cloud-ark/kubeplus/blob/master/Operator-FAQ.md 2. Operator Maturity Model: https://github.com/cloud-ark/kubeplus/blob/master/Operator-Maturity-Model.md

The Redis Operator defines a Custom Resource (RedisEnterpriseCluster). The Operator creates several k8s resources behind the scene as part of handling this Custom Resource. Here is a graphical output showing all the resources that are created by the Operator: https://github.com/cloud-ark/kubeplus/blob/master/examples/redislabs/redis.png

In our KubePlus project (https://github.com/cloud-ark/kubeplus) we abstract MSP and their consumers under Provider and Consumer APIs. These are Kubernetes-native APIs that form the focal point of defining RBAC policies for providers (MSP team) and the consumers.

Note that you can skip cloning the repo. Just curl the Vagrantfile from to get started: https://github.com/cloud-ark/kubeplus/blob/master/Vagrantfile