Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deploying an application #19

Open
gridworkz opened this issue Jun 24, 2022 · 7 comments
Open

Deploying an application #19

gridworkz opened this issue Jun 24, 2022 · 7 comments

Comments

@gridworkz
Copy link

gridworkz commented Jun 24, 2022

I'd like to get more info on how to launch an application onto Kubeslice. I've been trying to "Sassify" and "multi-tenant-ize" a single tenant application on Kubernetes for a while now and I'm finding that it's quite hard to do. Mattermost seems to have accomplished it and it's complicated. The idea is to have clients / organizations login to their own customer portal, buy a subscription and launch the app in the cloud. Seems pretty straightforward but boy it's not! Add SSO to the mix and it's a real treat.

If you have any thoughts, pointers for using Kubeslice in this use case I'd be grateful. Cheers, Dave

@eric978
Copy link
Collaborator

eric978 commented Jun 24, 2022

Hi Dave. Sure, with Kubeslice you can deploy applications (or multiple instances of a single application) across multiple isolated namespaces (aka Slices) in a single cluster (or extend those Slices across multiple clusters).

How do you want the service to appear to your customers? I mean do you want a single portal through which each tenant reaches their instance? Or do you want each customer to have their own/separate DNS/URL?

@gridworkz
Copy link
Author

gridworkz commented Jun 24, 2022

Hi Eric:

Thanks for getting back. I'll put together some finer details and get them over to you.

In the meantime...

The general flow for provisioning a new BillStreams installation is:

  1. Customer creates an account on the Customer Portal Server (CPS)
  2. CPS makes an HTTP API request to the Provisioning Server (PS) asking for a new installation of BillStreams
  3. PS evaluates the existing Kubernetes clusters and selects one that has capacity and correct affinity for a new installation
  4. PS instructs the BillStreams Operator (BO) of the selected cluster to create a BillStreams deployment
  5. MO deploys a new BillStreams installation potentially with database and other needed infrastructure
  6. When deployment completes, PS pushes an update to CPS
  7. CPS notifies customer that their installation is ready and provides login link

I've attached a diagram of our first iteration on this:
diagram1

To answer your question, we'll be sending users an email magic link to login and we'll also be breaking with tradition and provide SSO for everyone (not just enterprises). We need to kill passwords across the board :-)

@eric978
Copy link
Collaborator

eric978 commented Jun 24, 2022

Hi Dave. So yeah, at a high level, a "Billstream Installation X" could be deployed on a Kubeslice (which would have the effect of isolating instance X from instance Y and providing you some controls over how the pods in each slice are provisioned/scaled.

From your description, it sounds like customers will access their installation containers by going thru the customer portal and making requests that the BillStreams Operator will pass on to the appropriate installation? If so, that's fine. When provisioning a slice you have an option to say what other namespaces/etc should have access to a given slice. So, for example, if the "BillStreams Operator", "Logging/Monitoring", and "Teleport" pods were on the "billstreams" namespace, you could give "billstreams" access to all the slices (while denying anything else from getting into them).

@gridworkz
Copy link
Author

gridworkz commented Jun 24, 2022

Thanks, sounds good. Yeah, the users will interact with the operator only when signing up to the service via the customer portal, and getting a notification when their instance is ready. After that they'll only use the portal for subscription, billing, tokens, user management etc. Very similar to what MatterMost does. We're still up in the air whether to launch from within the portal or outside.

@eric978
Copy link
Collaborator

eric978 commented Jun 27, 2022

Say once a user has launched their instance of a BillStream installation, will they talk to the services inside that installation by going thru the portal? Or will a service in the installation be exposed for users to interact directly with it? (I.e., direct N/S traffic into the installation)?

Either way, Kubeslice can help to manage and isolate each installation from the others. Let us know if we can help you try something out.

@gridworkz
Copy link
Author

We're trying to convert this: https://www.getlago.com/ to Saas / Multi-tenant. We're leaning more towards doing things through the portal.

@Dheeraj-k8s
Copy link

@gridworkz

Hi Dave, was browsing thru kubeslice project and found this thread. Is this what you are trying to do?

Screen Shot 2022-07-28 at 3 51 03 PM

-D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants