The v1.0.0 release of Sveltos introduces an exciting new capability: Pull Mode. In this article, we will explore what Pull Mode is, how it works, and why it matters, especially when managing Kubernetes clusters behind a firewall.
Before we go into Pull Mode, let’s take a quick look at how Sveltos works by default and the problem this new feature solves.
Sveltos is a multi-cluster management tool that helps administrators manage workloads across multiple Kubernetes clusters. It ensures consistent configurations across environments such as development, staging, and production by continuously monitoring clusters and pushing updates to keep them in sync with the desired state.
This push-based approach works well for most fleets where clusters are accessible over the public internet. However, it can be challenging in environments with private clusters that don’t expose their API servers. That’s where Pull Mode comes in.
The limitations of the push model
Sveltos’ traditional push-based approach works well in many scenarios, but it is built on one key assumption: the management cluster must be able to communicate directly with every managed cluster.
In practice, this assumption can become a major challenge in enterprise environments where security policies, compliance requirements, and network design introduce strict boundaries.
Figure 1: Sveltos Kubernetes add-ons management across clusters
Why the push model alone isn’t enough
Before pull mode, Sveltos could not manage clusters that:
We’re in private networks or behind restrictive firewalls: If the management cluster couldn't directly reach the managed cluster's API server due to network segmentation or security rules, it was unmanageable.
Operated in disconnected or air-gapped environments: Clusters without external network ingress or internet access were beyond Sveltos's reach.
Exposed only private API endpoints: Cloud clusters configured with private API access (e.g., in their own VPC/VNet, without peering or private links to the management cluster) were inaccessible.
These limitations effectively excluded entire categories of production environments from Sveltos' management. Organizations with stringent security requirements, regulated industries with air-gapped systems, or complex network topologies found themselves unable to leverage Sveltos' powerful multi-cluster capabilities where they needed them most.
Introducing Pull Mode for Sveltos
Pull Mode in Sveltos flips the connectivity model on its head.
Instead of requiring the management cluster to push changes into a managed cluster behind a private network, the managed cluster initiates the connection to the management cluster.
This simple inversion removes the limitations of the traditional push model while preserving everything that makes Sveltos powerful. You still define your desired state declaratively, and Sveltos still ensures clusters stay aligned with that state. The difference lies entirely in how communication happens.
Figure 2: Sveltos Pull Mode In Action
When a cluster is registered in Pull Mode, administrators continue to use ClusterProfile configurations to specify workloads and policies. The key change is that a lightweight Sveltos agent is deployed on the managed cluster.
This agent establishes a secure outbound connection to the central management plane, acting as a bridge that lets private, firewalled, or air‑gapped clusters be managed without exposing their API server to the public internet.
Push vs Pull Mode
Understanding the fundamental differences between push and pull modes is crucial for choosing the right approach for your environment.
While both modes achieve the same end goal of maintaining the desired cluster state, they operate through different communication patterns.
How push mode works
When a cluster is registered in push mode:
SveltosCluster instance: A
SveltosClusterresource is created in the management cluster and labeled to match relevant profiles.
Secret with Kubeconfig: The managed cluster kubeconfig is stored in a Secret in the management cluster.
Deployment flow: Anytime Sveltos needs to deploy something to that managed cluster, it fetches this kubeconfig Secret, creates a Kubernetes client using it to access the managed cluster's API server, and then directly deploys the necessary resources.
This approach assumes the management cluster has direct, immediate access to every managed cluster's API endpoint.
How pull mode works
When a cluster is registered in Pull Mode:
SveltosCluster instance: A
SveltosClusterinstance is created in the management cluster, labeled, and explicitly marked for pull mode.
Agent ServiceAccount: A highly-permissioned (strict permissions) ServiceAccount is created within the managed cluster for the agent that will operate on the managed cluster.
Deployment flow: When a resource needs to be deployed, Sveltos prepares the resources and stores them in the management cluster. The agent, deployed in the managed cluster, will then fetch these resources and apply them to its cluster.
In this mode, many clusters behind private networks can still reach the internet and, by extension, the management cluster, with the exception of airgapped environments. Which will largely depend on how the airgapped deployment set up. In cases where no external network access is permitted, both management and managed clusters will need to reside within the same isolated environment.
Sveltos Pull Mode In Action (DEMO)
With a lot of the theory out of the way, here is a quick look at Pull Mode with Sveltos. If you would like to follow along with this demo section, you will need the following installed locally:
Sveltosctl: This will be used to register your clusters.
Kubectl: This is used for applying manifests and interacting with your clusters
KinD: This is used for this demonstration. KinD will be used as a managed cluster as it can not be reached from the public internet, only on your machine.
A hosted Kubernetes cluster: This will act as your management cluster. Civo will be used in this demonstration, but EKS, GKE, or any other provider will work.
Civo CLI (optional): If you choose to go this route, you will need the Civo CLI to launch a cluster under your account.
Launch a management cluster with Civo (optional)
If you already have one set up, feel free to skip this step. If not, run the following command:
civo k3s create --create-firewall --nodes 1 -m --save --switch --wait sveltos-mgmtThis command would launch a one-node Kubernetes cluster called sveltos-mgmt under your Civo account, and point your kubeconfig to your newly created cluster.
Step 1: Create a managed cluster
As mentioned earlier, KinD will act as the managed cluster. To create one, head back to your terminal and run the following command:
kind create cluster --name kind-cluster --kubeconfig ./privateThis command will launch a new KinD cluster and save the kubeconfig to the current directory with the file name private.
Deploy Sveltos
While pointing to your management cluster, run the following commands to install Sveltos:
kubectl apply -f https://raw.githubusercontent.com/projectsveltos/sveltos/v1.0.0/manifest/manifest.yamlYou can verify all Sveltos components are running correctly using:
kubectl get all -n projectsveltos The output is similar to:
NAME READY STATUS RESTARTS AGE
pod/addon-controller-bbdfc69c4-2rgqf 1/1 Running 0 20h
pod/sc-manager-7f9b4f59fb-rh9gx 1/1 Running 0 20h
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/addon-controller ClusterIP 10.43.33.168 <none> 80/TCP 20h
service/sc-manager ClusterIP 10.43.233.28 <none> 80/TCP 20h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/addon-controller 1/1 1 1 20h
deployment.apps/sc-manager 1/1 1 1 20h
NAME DESIRED CURRENT READY AGE
replicaset.apps/addon-controller-bbdfc69c4 1 1 1 20h
replicaset.apps/sc-manager-7f9b4f59fb 1 1 1 20h
Step 2: Register your KinD cluster
Using sveltosctl, you can now register your KinD cluster:
sveltosctl register cluster --namespace=default --cluster=kind-private --labels=env=staging --pullmode > applier.yamlThis command registers a cluster named kind-private in Pull Mode with the env=staging label, which allows it to match ClusterProfile selectors targeting staging environments.
The --pullmode flag is crucial here; it tells Sveltos to generate the necessary components for pull-based management rather than traditional push mode.
When registering a cluster in Pull Mode, Sveltos generates a ServiceAccount with tightly scoped permissions that the agent will use to communicate with the management cluster.
This ServiceAccount is configured with a Role which grants the agent permission to fetch configuration from the management cluster, while the agent deploys resources with cluster admin permissions in the managed cluster.
At this stage, you can check on the cluster using kubectl:
kubectl get sveltosclusters.lib.projectsveltos.io -AThe output is similar to:
The output shows your KinD cluster; however, it is not ready, and Sveltos is not yet aware of the Kubernetes version running.
Complete the cluster registration by applying the manifest generated earlier:
KUBECONFIG=private kubectl apply -f applier.yaml Verify the Sveltos agent is running:
KUBECONFIG=private k get pods -n projectsveltosThe output is similar to:
NAME READY STATUS RESTARTS AGE
sveltos-applier-manager-d5b5d4799-lw9c8 1/1 Running 66 (8m6s ago) 28h
Confirm registration
On your management cluster, run:
kubectl get sveltosclusters.lib.projectsveltos.io -A The output is similar to:
From the output above, notice Sveltos has now pulled in the Kubernetes version of the managed cluster(KinD), and it is now in a ready state.
Step 3: Deploy a resource to a managed cluster
Up until this point, the only information Sveltos has about the managed cluster is the information you provided via the registration command; Sveltos has no way to connect directly to the managed cluster.
To further illustrate, deploy a ClusterProfile to the managed cluster and see how the Sveltos agent on the managed cluster reacts:
kubectl apply -f - <<EOF
apiVersion: config.projectsveltos.io/v1beta1
kind: ClusterProfile
metadata:
name: kyvernooinstall
spec:
clusterSelector:
matchLabels:
env: staging
helmCharts:
- repositoryURL: https://kyverno.github.io/kyverno/
repositoryName: kyverno
chartName: kyverno/kyverno
chartVersion: v3.3.3
releaseName: kyverno-latest
releaseNamespace: kyverno
helmChartAction: Install
EOFThe important bit to note here is in spec.clusterSelector.matchLabels, where you specify what clusters you want this deployment to go to, which is env=staging. Beyond that, this ClusterProfile deploys Kyverno using its helm chart.
Step 4: Monitoring deployments
Sveltos provides a neat CRD to monitor deployments to managed clusters in the form of cluster summaries.
Run the following command on your management cluster to obtain a cluster summary for the Kyverno install.
kubectl get clustersummaries.config.projectsveltos.io -o wideYour output is similar to:
The output contains information about the deployment's current state. In this case, it has been provisioned. For deployments that are still in progress, it should be Provisioning.
If at any point you need to figure out what is happening with your ClusterProfile, you can debug by looking at the events under the ClusterProfile CRD:
kubectl describe clustersummaries.config.projectsveltos.io/kyvernooinstall-sveltos-kind-privateThe output should be similar to:
This gives a summary of the resources deployed via Deployed GVKs, and any Events related to the deployment will be displayed under the Events section.
Multi-cluster management beyond the firewall
Pull mode in Sveltos directly addresses one of the biggest pain points for teams operating in restricted network environments.
Organizations such as banks, government agencies, and enterprises with strict security policies can now manage private clusters without compromising on their network boundaries.
An added benefit is that pull and push modes are not mutually exclusive.
You can mix and match both approaches in the same environment, choosing the model that best fits each cluster. There’s no trade‑off, only flexibility.
