Community Contributions
Edition 2026
GitOps at Scale: Why Your Hub-and-Spoke Architecture is a Security Risk
Hub-and-Spoke has become the default architecture for many GitOps based platforms. It is easy to understand, promises centralized control, and offers a single pane of glass for operating Kubernetes fleets. But at scale, this model becomes dangerous. In this talk, we explain why traditional (push) Hub-and-Spoke GitOps architectures fail when managing hundreds or thousands of clusters and especially when they are not agent-based. Centralizing privileged cluster credentials in a single management hub creates a "God-mode" security risk: compromise the hub, and you compromise the entire fleet. We start with a short comparison of Argo CD and Sveltos, two open-source GitOps tools with fundamentally different architectural approaches. From there, we dive deep into the real challenges of GitOps at scale: - Security risks caused by storing highly privileged cluster credentials in the hub - Hub scalability limits and bottlenecks (resources, performance, blast radius) - Why inbound connectivity (hub -> firewall -> cluster) is risky — or impossible in edge, semi-air-gapped, or regulated environments - How multi-tenancy breaks down when the hub deploys applications, add-ons, and third-party tools for many teams We show how an agent-based, pull-driven GitOps approach allows teams to keep the familiar Hub-and-Spoke model without inheriting its risks: no inbound access, no centralized superuser credentials, reduced blast radius, and clean multi-tenancy boundaries. This is not a theoretical discussion. We will prove it with a live demo, showing GitOps at scale using an agent-based push and pull architecture in practice.
One repo to rule them all: managing heterogeneous clusters with sveltos and gitops
Managing distributed Kubernetes infrastructures across multiple cloud providers GCP, AWS, Alibaba Cloud with a mix of shared and cluster-specific requirements is a significant challenge. How do you deploy cert-manager, Kyverno, or Ingress controllers across every cluster while handling different configurations for AWS NLBs versus GCP static IPs? How do you roll out AI services like LiteLLM only to specific environments? In this talk, we present a production-proven approach used to manage diverse client clusters from a single management hub, leveraging Sveltos as the distribution engine and ArgoCD as the delivery layer for CRDs. We will dive into Two-tier Hub-and-Spoke Architecture, Label-based Opt-in Model, Configuration Layering and other features.
Edition 2025
How to Use Kubernetes to Control a Vast Network of Clusters
Kubernetes is the container orchestration standard. It is expanding to distributed environments across datacenter, on-premises, public clouds. Managing multiple clusters for development, testing, and production in this complex landscape necessitates programmatic solutions. Solutions exist to programmatic create and manage Kubernetes clusters using Kubernetes itself. ClusterAPI is one such popular solution. It provides a declarative approach to creating, managing, and upgrading Kubernetes clusters from a central management cluster. Once a cluster is established, add-ons need to be deployed. In some cases, simply listing all required add-ons suffices. However, add-ons often have dependencies and require specific deployment orders. Additionally, external resources may need to be created and then utilised by applications within the cluster. Solutions exist for programmatically defining which add-ons should be deployed where. Event frameworks handle dependencies programmatically. For short-lived clusters, consistency and velocity are key, while long-lived clusters demand reduced administrative coordination. Consider a scenario where add-ons initially deployed to clusters running Kubernetes v1.30.x need to be updated to a new set upon upgrade to v1.31.x. Application administrators should only need to specify required add-ons for clusters in a particular state. Platform administrators can upgrade cluster and add-on updates automatically happens
Orchestrating Add-ons and Applications Across Multi-Cluster Kubernetes Environments with Sveltos
Managing Kubernetes add-ons and applications across multiple clusters is complex and error-prone. As environments scale, ensuring consistency, automating deployments, and handling cluster-specific configurations becomes increasingly difficult. Sveltos is a lightweight, Kubernetes-native solution that simplifies the management of add-ons and applications across any number of clusters. It lets you define desired configurations declaratively and automatically applies them to target clusters based on labels selectors. With Sveltos, platform teams can ensure consistent, policy-driven deployments while reducing manual effort and minimizing drift across environments.