Scaling Event-Driven Applications Made Easy With Sveltos Cross-Cluster Configuration
How Sveltos turns multi-cluster Kubernetes management from an operational burden into a declarative, event-reactive system — and why its cross-cluster model changes how distributed teams scale.
Multi-cluster Kubernetes is no longer a niche architecture reserved for the largest enterprise deployments. Teams running microservices across availability zones, mixing managed cloud offerings like GKE or EKS with on-premises CAPI-provisioned clusters, or building edge computing platforms all end up managing a fleet of clusters rather than a single one. The tooling, however, has not always kept pace. Helm releases and Argo CD applications are fundamentally single-cluster primitives, and wiring them together across cluster boundaries quickly produces a tangle of custom scripts and fragile CI pipelines.
Project Sveltos is an open-source Kubernetes add-on controller specifically designed for this environment. It runs in a single management cluster and from there orchestrates the deployment of Helm charts, Kustomize overlays, raw YAML manifests, and Carvel packages to any number of managed clusters — matching them by label selectors rather than explicit per-cluster configuration. More than a deployment tool, though, Sveltos includes a built-in event-driven framework that lets you react to what actually happens inside those clusters. That event framework is what this article explores, with particular attention to how Sveltos extends it across cluster boundaries.
What Sveltos Is — and What It Is Not
Before going further, it is worth being precise about Sveltos’s position in the ecosystem. It is not a replacement for GitOps controllers like Argo CD or Flux CD. Rather, Sveltos complements them by adding a fleet-management layer on top. Where Argo CD or Flux reconcile a single cluster to a desired state in Git, Sveltos answers the prior question: which clusters should receive which configurations, and when?
Concretely, Sveltos discovers clusters automatically — it understands ClusterAPI-provisioned clusters natively and lets you register any other cluster, including GKE, EKS, or AKS — and continuously reconciles add-ons onto every cluster whose labels match a given ClusterProfile. New clusters that join the fleet inherit the right configurations immediately. Clusters that drift get corrected automatically. The result is a management plane where humans define intent, and Sveltos enforces it continuously.
In one sentence: Sveltos is the control plane for your Kubernetes fleet, handling add-on distribution, policy enforcement, configuration drift correction, and — crucially — event-driven reactions across all your clusters from a single management cluster.
The Event-Driven Framework: Core Concepts
Standard cluster management is reactive only to desired-state changes: you update a manifest, and the controller reconciles. Sveltos’s event framework inverts this — it lets you define conditions in the cluster itself as the trigger for deploying or updating resources. This is the shift that makes Sveltos particularly well-suited for dynamic, distributed applications.
The framework revolves around three custom resource definitions (CRDs) that work together in a clear pipeline. Understanding each one individually makes the overall architecture easy to reason about.
EventSource
Defines what to watch for — a Kubernetes resource type plus a matching condition written in Lua or CEL. When a matching resource appears, changes, or is deleted, an event fires.
EventReport
The bridge between managed and management cluster. The Sveltos agent on the managed cluster sends an EventReport to the management cluster whenever an EventSource condition matches, optionally including the matching resource data.
EventTrigger
Defines what to do when an event occurs — which add-ons to deploy, in which clusters, using which templates. It references an EventSource and a set of resources or Helm charts to instantiate.
Together, these three CRDs form a clean separation of concerns: observation (EventSource), reporting (EventReport), and reaction (EventTrigger). Platform engineers define events in terms of real cluster conditions, not arbitrary time-based polling, which makes the system both more responsive and more efficient.
How the Pipeline Flows
1. An EventSource is deployed to the management cluster. It describes which Kubernetes resource kind to watch and what condition — expressed as a Lua or CEL script — qualifies as an event. For example: any Service with a specific label, or any Pod in a CrashLoopBackOff state.
2. The Sveltos agent in each managed cluster consumes the EventSource. It continuously evaluates the condition against the live state of the cluster. This evaluation is lightweight, happening in-process without additional infrastructure.
3. When a match occurs, the agent creates an EventReport. If collectResources is set to true on the EventSource, the report includes the full resource data — labels, annotations, spec fields — that the management cluster can use for templating.
4. The event-manager in the management cluster consumes the EventReport. It finds the matching EventTrigger, instantiates the referenced ConfigMap or Helm chart templates using data from the event, and generates a ClusterProfile on the fly.
5. The ClusterProfile is reconciled into the target cluster(s). Sveltos deploys the add-ons, applying all the usual guarantees: drift detection, ordering, multi-tenancy boundaries.
Sveltos Event Pipeline — Time-to-Reaction vs. Traditional Approaches
Cross-Cluster Configuration: The Key Differentiator
By default, when Sveltos detects an event in a managed cluster, it deploys the resulting add-ons into that same cluster. That alone is powerful — it means you can automatically provision a NetworkPolicy the moment a Service matching certain labels appears, without anyone writing a custom operator. But Sveltos goes a significant step further, and this is where it separates itself from most comparable tools.
The EventTrigger CRD includes an optional field called destinationClusterSelector — a standard Kubernetes label selector. When this field is set, events detected in one cluster trigger deployments in a different set of clusters. The source cluster and the destination clusters can be entirely separate, running in different cloud providers, different regions, or different organizational units. Sveltos handles the coordination transparently from the management cluster.
This pattern is, in fact, what enterprise distributed systems often need but rarely have a clean way to express. Consider a concrete scenario: a GKE cluster exposes a microservice via a LoadBalancer service. A CAPI-provisioned cluster in a different region needs to route to that service. Traditionally, this requires either shared DNS, manual endpoint configuration, or a service mesh with cross-cluster discovery — all of which introduce operational complexity and coupling. With Sveltos, you define an EventSource that matches any Service of type LoadBalancer with an assigned external IP, and an EventTrigger whose destinationClusterSelector targets the downstream clusters. When the load balancer IP is allocated, Sveltos automatically creates the corresponding selector-less Service and Endpoints resources in every downstream cluster — populated with the real IP extracted from the event data.
What this means in practice: Infrastructure that previously required custom controllers, external service registries, or manual runbooks becomes a two-CRD declaration. New clusters that match the destination selector automatically receive updated endpoint configurations whenever the source changes — no human intervention required.
Dynamic Templates: Turning Event Data into Configuration
Cross-cluster configuration would not be particularly useful if the resources deployed were static. Sveltos’s templating system closes this gap. When an EventSource has collectResources: true, the full matching resource — including its metadata, spec, and status — travels with the EventReport to the management cluster. The EventTrigger can then reference templates that use this data to generate dynamic manifests.
This means the IP address of a newly-provisioned load balancer, the name of a namespace from an incoming request, or the credentials from a Secret in a services cluster can all flow directly into the resources Sveltos creates in other clusters. The templates use standard Go template syntax, with cluster metadata — cluster name, labels, region — available as well. As a result, one EventTrigger can serve an entire fleet of clusters, each receiving a correctly-parameterized configuration derived from what actually exists in the source cluster.
The OneForEvent field on the EventTrigger provides further control. When set to true, Sveltos creates a separate ClusterProfile per matching resource — meaning each individual event gets its own dedicated response. When set to false (the default), a single ClusterProfile covers all resources matching the EventSource. The right choice depends on whether your add-ons are data-driven per-resource (use true) or a single shared deployment that should trigger once per cluster regardless of how many matching resources exist (use false).
Drift Detection and Sync Modes
Event-driven deployment is only half the reliability story. Even after Sveltos correctly deploys a resource in response to an event, someone — a developer applying a quick patch, a misconfigured admission webhook, an operator mistake — can change that resource in the managed cluster. Without a mechanism to detect and correct such drift, the carefully designed event-driven state gradually diverges from the desired state.
Sveltos addresses this through three sync modes on every ClusterProfile. OneTime deploys once and does not reconcile again — suitable for bootstrapping components that should never be overwritten. Continuous reconciles any time the ClusterProfile is updated — good for actively developed configurations. ContinuousWithDriftDetection goes further: Sveltos deploys a lightweight agent into each managed cluster that watches every resource deployed by that profile, and the moment any watched resource’s spec, labels, or annotations change outside of Sveltos’s own updates, the agent notifies the management cluster, which immediately re-applies the profile. This brings the managed cluster back to the declared state without waiting for a polling interval.
| Sync Mode | Reconciles on profile change? | Corrects drift automatically? | Best for |
|---|---|---|---|
OneTime | No | No | Bootstrap / initial setup only |
Continuous | Yes | No | Actively updated configurations |
ContinuousWithDriftDetection | Yes | Yes | Production workloads, compliance environments |
Feature Coverage — Sveltos vs. Common Alternatives
Real-World Scenarios Where This Architecture Shines
The abstractions Sveltos provides are general-purpose, but certain classes of problems benefit from them disproportionately. It is worth naming a few concrete scenarios, because they illustrate why the cross-cluster event model is meaningfully different from what came before.
Multi-Region Service Discovery
Teams running services in multiple regions frequently need each cluster to have a local representation of services that live in another cluster — a pattern sometimes called service mirroring. With Sveltos, an EventSource watches for LoadBalancer services with a specific annotation in region A, and an EventTrigger with destinationClusterSelector targets all clusters in regions B and C. Every time a new service appears or an IP address changes in region A, the downstream clusters automatically receive updated endpoint configurations. No service mesh, no external registry, no manual runbook.
PostgreSQL Cluster Provisioning on Demand
A realistic internal developer platform scenario: application teams request a PostgreSQL cluster by creating a SveltosCluster object with a postgres: required label. An EventSource watches for exactly this condition on the management cluster. The corresponding EventTrigger deploys a CloudNativePG cluster to a dedicated services cluster and, once the load balancer endpoint is ready, propagates the connection details back to the requesting team’s cluster via a templated ConfigMap. The entire lifecycle — from request to working connection string — happens without any human operator involvement.
vCluster Lifecycle Automation
Developer sandbox environments built on vClusters benefit from the same pattern. Each vCluster can be requested by creating a labeled Service resource. Sveltos detects the service, provisions the vCluster using the Helm chart (with exportKubeConfig enabled), and then chains a second EventTrigger to detect when the resulting kubeconfig secret appears — at which point it registers the new vCluster into the fleet automatically. The whole chain is declarative and requires no custom operator code.
Multi-Tenancy and the Management Layer
Large organizations managing shared Kubernetes infrastructure need more than deployment automation — they need permission boundaries between teams. Sveltos addresses this through two distinct resource types: ClusterProfile (cluster-scoped, for platform administrators) and Profile (namespace-scoped, for tenant administrators). Tenant admins can define their own deployment profiles and event triggers within their assigned namespaces, without gaining visibility into other teams’ clusters or configurations. Platform admins retain control over which clusters are visible to which tenants via Sveltos’s RoleRequest mechanism.
This matters for the event-driven framework specifically: a tenant’s EventTrigger can only deploy to clusters the tenant has been granted access to. Cross-cluster configuration therefore respects the same permission model as static deployment — there is no escalation path where an event-driven workflow accidentally reaches into another team’s infrastructure.
Beyond Kubernetes Events: NATS and CEL Support
Sveltos’s event framework is not limited to watching Kubernetes resources. The platform also integrates with NATS and JetStream, which means you can trigger cluster configuration changes from any system that can publish to a NATS subject — an application emitting a business event, a CI/CD system signaling a successful deployment, or a monitoring system detecting a capacity threshold. When Sveltos receives a CloudEvent on a subscribed subject, it evaluates the EventSource condition and fires the corresponding EventTrigger in exactly the same way it would for a Kubernetes resource event.
On the condition-evaluation side, Sveltos supports both Lua and CEL (Common Expression Language) for writing event conditions. CEL is lighter-weight and more familiar to teams already using it in admission webhooks or policy engines, while Lua provides full scripting flexibility for complex multi-field conditions. Both are evaluated in-process by the Sveltos agent without any external runtime dependency.
| Event source type | Mechanism | Condition language | Typical use case |
|---|---|---|---|
| Kubernetes resource | Sveltos agent watch | Lua or CEL | Service creation, Pod state changes, CRD events |
| NATS / JetStream | CloudEvent subscription | CEL on event payload | App-level events, CI signals, external triggers |
| Management cluster resource | Direct EventSource on mgmt cluster | Lua or CEL | SveltosCluster creation, Secret appearance |
Observability: Dashboard and MCP Server
A distributed event-driven system is only as trustworthy as your ability to observe it. Sveltos addresses this with a built-in dashboard and, more recently, a native MCP Server for AI-assisted operations. The dashboard provides a single view of all EventTriggers, their linked EventSources, and every cluster that matched — with the ability to drill down into individual clusters and inspect exactly which resources triggered the event. This makes debugging a misfiring trigger or tracing the origin of an unexpected deployment significantly faster than parsing controller logs.
The MCP Server extends this further by exposing Sveltos’s internal state to AI SRE tools, allowing natural-language queries like “which clusters have a pending event that has not been acted on?” or “show me all EventTriggers referencing this EventSource.” This is particularly valuable in large fleets where the sheer volume of events makes manual inspection impractical.
When Sveltos Is the Right Choice
Sveltos is not the right tool for every Kubernetes team. If you run a single cluster with a mature GitOps setup, adding a management cluster and a fleet-management layer is unnecessary overhead. However, as soon as you cross into multi-cluster territory, the economics shift rapidly in Sveltos’s favour.
| Scenario | Sveltos a good fit? | Primary reason |
|---|---|---|
| Single cluster, established GitOps | Not needed | Argo CD / Flux already cover the job |
| 2–5 clusters, manual Helm per cluster | Consider | Label-based targeting removes repetition fast |
| Fleet of 10+ clusters, mixed providers | Strong fit | ClusterProfile + ClusterSelector scales linearly |
| Event-driven cross-cluster provisioning | Strong fit | destinationClusterSelector is unique to Sveltos |
| Compliance-sensitive environments | Strong fit | ContinuousWithDriftDetection enforces desired state |
| Edge / air-gapped deployments | Strong fit | Pull-mode agent works behind firewalls |
What We Learned
Sveltos brings genuine architectural clarity to multi-cluster Kubernetes management. We covered its core event-driven pipeline — EventSource defines the condition, EventReport carries the match back to the management cluster, and EventTrigger translates the event into concrete deployments. More importantly, we examined the destinationClusterSelector field that enables true cross-cluster configuration: events detected in one cluster can automatically provision or update resources in a different set of clusters, turning what was previously a custom-operator problem into a two-CRD declaration.
We also saw how Sveltos’s three sync modes — culminating in ContinuousWithDriftDetection — give production teams the assurance that desired state is continuously enforced, and how the multi-tenancy model ensures that event-driven workflows respect the same permission boundaries as static deployments. Together, these capabilities make Sveltos a compelling control plane for teams whose infrastructure has outgrown single-cluster GitOps and needs something that scales with the fleet.
