Questions and more Documentation needed

[VincentS]

I really like the potential of the project. I have several questions regarding it:

1. In the description you say that you can route telemetry data (logs, metrics and traces) but in the CRDs I can see logSourceNamespaceSelectors how can I route other telemetry signals ?

2. In our scenario we have multi tenancy by namespace on the K8s cluster. Is it possible to have the Tenants CRD instance optional and just generate it automatically when a Subscription CRD instance is created with Subscription CRD Namespace is equal to the selected namespace in the generated Tenants CRD or some form of additional abstraction for it instead of creating a Tenant for each namespace on the cluster ?

[OverOrion]

Hey @VincentS, thanks for opening this issue, we are glad that you like it :).

In the description you say that you can route telemetry data (logs, metrics and traces) but in the CRDs I can see logSourceNamespaceSelectors how can I route other telemetry signals ?

Currently only logs are supported, but we are planning to support other telemetry signals. Would you mind telling which one would be your most needed?

In our scenario we have multi tenancy by namespace on the K8s cluster. Is it possible to have the Tenants CRD instance optional and just generate it automatically when a Subscription CRD instance is created with Subscription CRD Namespace is equal to the selected namespace in the generated Tenants CRD or some form of additional abstraction for it instead of creating a Tenant for each namespace on the cluster ?

The original idea was that Tenant resources could only be created by the administrators, not by the actual tenants themselves (that's why it is a cluster-scoped resource). Nevertheless I can see why it would make more sense in your use case, so let me run this through the others and we'll get back to you.

The documentation is currently being revamped, is there anything that you would like to see in the docs specifically?
By the way not sure if you've already seen it, but this blog post covers the basics.

[VincentS]

Thank you for your thorough answers @OverOrion :)

Currently only logs are supported, but we are planning to support other telemetry signals. Would you mind telling which one would be your most needed?

For us the highest priority would be metrics and then traces.

The original idea was that Tenant resources could only be created by the administrators, not by the actual tenants themselves (that's why it is a cluster-scoped resource). Nevertheless I can see why it would make more sense in your use case, so let me run this through the others and we'll get back to you.

The main goal for us is to provide logs / metrics and later traces of shared components in Kubernetes e.g. K8s API Server, Nginx ingress, External DNS, External Secrets Operator, ... where each team receives for their namespace relevant metrics / logs / traces (filtered with some config or enforced through e.g. self defined Kyverno rules) and can send them to the Observability SaaS provider of their choice.

The documentation is currently being revamped, is there anything that you would like to see in the docs specifically?

If you open a public PR for it I am also happy to contribute to it. Code would be also possible but some kind of roadmap or transparency what is worked on / planned would be great to drive the project in a common direction that also aligns with your vision.

[pepov]

In our scenario we have multi tenancy by namespace on the K8s cluster. Is it possible to have the Tenants CRD instance optional and just generate it automatically when a Subscription CRD instance is created with Subscription CRD Namespace is equal to the selected namespace in the generated Tenants CRD or some form of additional abstraction for it instead of creating a Tenant for each namespace on the cluster ?

This is something that can be built any time I beleive. Tenant is a necessary building block, but nothing stops anyone to generate it automatically using some sort of automation or a policy engine for example. We could also consider to build something like that, but I'm wondering how frequent this use case is among multi-tenant platforms (Capsule and Rancher for example implement multi-namespace tenants).

Have you considered implementing something like that using kyverno, as you've just mentioned that tool specifically? (create a tenant automatically for each namespace)

[pepov]

@VincentS do you use an existing product or built your own in-house solution for multi-tenancy?

[VincentS]

Sorry for the delay just got back from vacation. We use a self build solution based on AKS where tenant == namespace. Ideally each tenant can subscribe to metrics / traces / logs that is related to the specific namespace they are in for globally shared components like:

• External DNS
• Nginx
• External Secrets
• Node Exporter
• Kube State Metrics

So we have to define selectors for each of these tools + namespace annotation to select the target namespace where the observability signals should be rooted to.

We try to have a "multi cast" approach for it instead that each product deploys their own scraping for these tools / endpoint and congest the API of e.g. the kube API Server by having 100 + products hitting the same endpoint in short intervalls.

[pepov]

That's a very good use case that we are going to address. For Nginx ingress logs we already have a working solution, but for the others we don't have that yet. We have some other priorities, but happy to discuss further over slack or discord: https://kube-logging.dev/docs/community/