Converged Service Provisioning Location


To provision services converged on the same cluster, there are two approaches:

  • Run the resources in the same namespace where the claim originates from

  • Provision managed namespaces where the customer doesn’t have access to

Proposal 1: Managed Namespaces

With managed namespace we provision a new namespace for each new instance. The customer doesn’t have general access to k8s resources in those namespaces. The interaction between the customer and the service is limited to the connection details and APIs provided by the service itself.

  • Neatly separated services

  • The services feel like cloud services, where usually no access to the underlying VMs/containers is granted

  • Customers can’t manipulate the k8s resources and thus less prone to breaking

  • VSHN engineers don’t have to touch customer namespaces, no potential to break their own services

  • Makes implementation more complex

    • log access can’t be given easily

    • To use APPUiO’s own resource billing need to add the organization label and also do custom RBAC trickery to still prevent access

  • During operation the engineer needs additional steps to find the right namespaces

Proposal 2: In the Same Namespace

All resources that a customer orders are deployed in the same namespace where the claim resides.

  • The customer can do debugging on their own

  • For operations, finding related resources is easier

  • Resource names could clash, resulting in unexpected behaviors

  • Operations could be accused of breaking other things while trying to fix a broken AppCat service

  • It’s easier for customers to break services, resulting in more operations effort


Managed namespaces.


Managed services are supposed to be isolated to some degree. It limits the factors that can influence the service, so that stability can be guaranteed.