Post by Project Sveltos

Static ClusterProfiles handle the steady-state well: deploy these add-ons to these clusters. But some deployment needs are dynamic, they depend on what's 𝘩𝘢𝘱𝘱𝘦𝘯𝘪𝘯𝘨 inside the cluster at runtime. Sveltos Event Framework handles this with two resources: 𝗘𝘃𝗲𝗻𝘁𝗦𝗼𝘂𝗿𝗰𝗲 (what to watch) and 𝗘𝘃𝗲𝗻𝘁𝗧𝗿𝗶𝗴𝗴𝗲𝗿 (what to do). 𝗦𝗰𝗲𝗻𝗮𝗿𝗶𝗼: every time a new namespace is created with label 𝘵𝘦𝘢𝘮: 𝘣𝘢𝘤𝘬𝘦𝘯𝘥, automatically deploy a NetworkPolicy isolating that namespace. 𝗦𝘁𝗲𝗽 𝟭 — 𝗱𝗲𝗳𝗶𝗻𝗲 𝘁𝗵𝗲 𝗲𝘃𝗲𝗻𝘁: ```yaml apiVersion: https://lnkd.in/dA3iUwVH kind: EventSource metadata:  name: new-backend-namespace spec:  collectResources: true  resourceSelectors:  - group: ""    version: v1    kind: Namespace    labelFilters:    - key: team     operation: Equal     value: backend ``` 𝗦𝘁𝗲𝗽 𝟮 — 𝗱𝗲𝗳𝗶𝗻𝗲 𝘁𝗵𝗲 𝗿𝗲𝘀𝗽𝗼𝗻𝘀𝗲: ```yaml apiVersion: https://lnkd.in/dA3iUwVH kind: EventTrigger metadata:  name: isolate-backend-namespace spec:  eventSourceName: new-backend-namespace  sourceClusterSelector:    matchLabels:     env: production  policyRefs:  - kind: ConfigMap    name: backend-network-policy    namespace: projectsveltos  oneForEvent: false ``` The ConfigMap 𝘣𝘢𝘤𝘬𝘦𝘯𝘥-𝘯𝘦𝘵𝘸𝘰𝘳𝘬-𝘱𝘰𝘭𝘪𝘤𝘺 holds the NetworkPolicy manifest, which can itself use templates referencing the triggering namespace: {{ .𝘙𝘦𝘴𝘰𝘶𝘳𝘤𝘦.𝘮𝘦𝘵𝘢𝘥𝘢𝘵𝘢.𝘯𝘢𝘮𝘦 }}. When the EventSource fires, Sveltos automatically generates a ClusterProfile scoped to that specific event. No manual reconciliation loop, no custom controller, no Operator SDK. For more complex matching logic, the EventSource evaluation block accepts 𝗟𝘂𝗮 𝘀𝗰𝗿𝗶𝗽𝘁𝘀 or 𝗖𝗘𝗟 𝗲𝘅𝗽𝗿𝗲𝘀𝘀𝗶𝗼𝗻𝘀— enabling conditions on arbitrary resource fields, cross-field comparisons, or stateful evaluation across multiple resources. The event framework turns cluster state into a trigger. The ClusterProfile machinery handles the rest. https://lnkd.in/dT7cW4jq #Kubernetes #MultiCluster #EventDriven #PlatformEngineering #CloudNative #OpenSource