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.

‍

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.

‍

‍

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 SveltosCluster resource 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 SveltosCluster instance 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-mgmt

‍

This 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 ./private

‍

This 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.yaml

‍

You 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.yaml

‍

This 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 seltosclusters.lib.projectsveltos.io -A

‍

The 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 projectsveltos

‍

The 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 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
EOF

‍

The 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 wide

‍

Your 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-private

‍

The 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.

‍