Two Publishers in the same cluster, spread across nodes, both enrolled
as distinct Publishers in your tenant. Netskope load-balances NPA
traffic across all online Publishers for a given Private App, so two
healthy replicas survive a single node failure with no manual action.

Values

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
workload:
  type: statefulset
  replicas: 2

enrollment:
  mode: api
  commonName: prod-eu-publisher  # becomes prod-eu-publisher-0, prod-eu-publisher-1

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels:
            app.kubernetes.io/name: kubernetes-netskope-publisher
        topologyKey: kubernetes.io/hostname  # spread across nodes
        # use topology.kubernetes.io/zone in multi-AZ clusters

resources:
  requests:
    cpu: 500m
    memory: 384Mi
  limits:
    cpu: 1000m
    memory: 1Gi

Apply

1
2
helm upgrade --install kubernetes-netskope-publisher npa/kubernetes-netskope-publisher \
  -n npa-publisher -f my-values.yaml

Verify

1
2
kubectl get pods -n npa-publisher -o wide
# Expect: pods on different nodes

In the Netskope console you’ll see two Publishers with the suffixed
names. Attach the same Private App to both — Netskope handles the
traffic distribution.

Scaling

helm upgrade --set workload.replicas=3 adds a third member. Each new
pod enrolls itself via the API; no manual token shuffling.

Scale-down leaves the tenant-side Publisher record by default — the
Netskope API rejects deletion of Publishers with Private Apps
attached, so opt-in cleanup is safer than racing it. See
autoscaling
and the delete-publisher
flow for manual pruning.

For CPU-driven scaling without manual helm upgrade calls, see
autoscaling.