Best practice for Skupper site topology in multi-cluster, multi-service namespaces

[DayaLiuzzo]

Hi 👋

I’m looking for guidance on Skupper site topology in a multi-cluster Kubernetes environment.

In our setup:

• Namespaces act as an isolation boundary (e.g. tenant / org)
• Each namespace hosts multiple services
• Some services need to be exposed across clusters using Skupper

We’re currently considering:

• one Skupper site per namespace
• multiple connectors per site, one per service that needs exposure

Before locking this in, I wanted to ask:

• Is a site-per-namespace model the recommended approach in this case?
• Are there known concerns with scaling many connectors per site?
• Or is a site-per-cluster model generally preferred?

Any pointers to docs or real-world experience would be appreciated. Thanks!

[ajssmith]

Hi,

Yes, the recommended pattern for skupper deployments is to have an application per VAN where each site is per namespace. This provides application isolation and the greatest flexibility in configuring/tuning the distribution of the components that make up each application.

The placement of your connectors would be in the site/namespace that the target service resides. We have seen deployments where 100s of connectors are defined for a namespace. In the case where multiple applications want to have a shared resources (e.g. postgres datbase), Skupper has the concept of an attached connector where the shared resource can be securely accessed by multiple VANs.

The primary factor to consider when scaling Skupper for your workload is router CPU. We generally recommend two cpu cores (2,000 millicores) per skupper-router (e.g. site) as a good starting point. It includes some headroom and provides low latencies for a large set of workloads. If the peak throughput by your workload is low, it is possible to achieve satisfactory latencies with less router CPU.

Some workloads are sensitive to network latency. In these cases, the overhead introduced by the router can limit the achievable throughput. This is when CPU amounts higher than two cores per router may be required.

On the flip side, some workloads are tolerant of network latency. In these cases, one core or less may be sufficient.

Router memory use scales with the number of open connections. In general, a good starting point is 4G.

You can find documentation and examples at the skupper.io website. If there are specific questions you have, just let us know.