Post by Project Sveltos

Most event-driven systems act within a single cluster: something happens, something is deployed to the same cluster. Sveltos extends this to the multi-cluster case. An event in 𝘤𝘭𝘶𝘴𝘵𝘦𝘳 𝘈 can trigger a deployment in 𝘤𝘭𝘶𝘴𝘵𝘦𝘳 𝘉, or across an entire group of clusters matched by a selector. 𝗦𝗰𝗲𝗻𝗮𝗿𝗶𝗼: a Service of type 𝘓𝘰𝘢𝘥𝘉𝘢𝘭𝘢𝘯𝘤𝘦𝘳 is created in a workload cluster. The external IP needs to be registered as an allowed endpoint in a central gateway cluster. The Sveltos template has access to {{ .𝘙𝘦𝘴𝘰𝘶𝘳𝘤𝘦 }} (the Service that triggered the event), {{ .𝘊𝘭𝘶𝘴𝘵𝘦𝘳 }} (the source cluster metadata), and {{ .𝘔𝘢𝘵𝘤𝘩𝘪𝘯𝘨𝘙𝘦𝘴𝘰𝘶𝘳𝘤𝘦 }} (for ConfigMapGenerator output). This gives you the full context needed to construct a cross-cluster policy. 𝗧𝗵𝗲 𝘁𝗼𝗽𝗼𝗹𝗼𝗴𝘆 𝗶𝘀 𝗳𝗹𝗲𝘅𝗶𝗯𝗹𝗲: - One workload cluster → one gateway cluster (𝘥𝘦𝘴𝘵𝘪𝘯𝘢𝘵𝘪𝘰𝘯𝘊𝘭𝘶𝘴𝘵𝘦𝘳) - Many workload clusters → one shared gateway (𝘥𝘦𝘴𝘵𝘪𝘯𝘢𝘵𝘪𝘰𝘯𝘊𝘭𝘶𝘴𝘵𝘦𝘳𝘚𝘦𝘭𝘦𝘤𝘵𝘰𝘳) - One event source → fan-out to multiple destination clusters This pattern recurs across many real architectures: service mesh federation, DNS registration, firewall rule propagation, central secrets distribution. The source cluster is the observer; the destination cluster is the actor. 🔗 https://lnkd.in/dMtUcXCE #Kubernetes #MultiCluster #EventDriven #ServiceMesh #PlatformEngineering