Skip to content

You can install SC4S on Google Cloud Platform with GKE (Google Kubernetes Engine). To do this, you can use the SC4S Helm chart with GCP-specific configuration.

Refer to the GCP documentation for the following setup steps before proceeding:

Before you begin you also need to have kubectl and helm installed. Both are pre-installed in GCP Cloud Shell — a browser-based terminal available in the GCP Console.

Note

GCP automatically provisions a Passthrough Network Load Balancer when service.type: LoadBalancer is set on GKE. No manual load balancer setup is required.

Prepare your initial configuration

  1. First create the sc4s namespace that the rest of the resources will be deployed into:
kubectl create namespace sc4s
  1. Add the SC4S Helm repository:
helm repo add splunk-connect-for-syslog https://splunk.github.io/splunk-connect-for-syslog
helm repo update
  1. Create a values.yaml file with the following GCP-specific configuration:
replicaCount: 2

splunk:
  hec_url: "https://<your-splunk-host>:8088"
  hec_token: "<your-hec-token>"
  hec_verify_tls: "yes"

image:
  repository: ghcr.io/splunk/splunk-connect-for-syslog/container3
  pullPolicy: IfNotPresent
  tag: ""

service:
  type: LoadBalancer
  usemetallb: false
  externalTrafficPolicy: Local

persistence:
  enabled: true
  size: "10Gi"

resources:
  requests:
    cpu: "1000m"
    memory: "512Mi"
  limits:
    cpu: "2000m"
    memory: "2Gi"

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50
  1. Add firewall rules to allow inbound syslog traffic:
gcloud compute firewall-rules create allow-sc4s-tcp \
  --network=default \
  --allow=tcp:514,tcp:601,tcp:6514 \
  --source-ranges=<your-syslog-sender-ip-ranges>

gcloud compute firewall-rules create allow-sc4s-udp \
  --network=default \
  --allow=udp:514 \
  --source-ranges=<your-syslog-sender-ip-ranges>

Warning

GCP blocks all inbound traffic by default. These firewall rules are required for syslog traffic to reach SC4S. Replace <your-syslog-sender-ip-ranges> with the actual IP ranges of your syslog senders in CIDR notation (e.g. 10.0.0.0/8). Avoid using 0.0.0.0/0 in production as it opens the ports to the entire internet.

Deploy SC4S with your configuration

  1. Install SC4S using the Helm chart:
helm install sc4s splunk-connect-for-syslog/splunk-connect-for-syslog \
  -f values.yaml \
  -n sc4s
  1. Check that pods are running:
kubectl get pods -n sc4s
  1. Get the external IP addresses assigned by GCP:
kubectl get services -n sc4s

You should see two LoadBalancer services with external IPs assigned — one for TCP and one for UDP. GCP provisions these automatically.

  1. Check the logs to confirm SC4S started successfully:
kubectl logs {your_pod_name} -n sc4s

You should see something like this:

SC4S_ENV_CHECK_HEC: Splunk HEC connection test successful to index=main for sourcetype=sc4s:fallback...
SC4S_ENV_CHECK_HEC: Splunk HEC connection test successful to index=main for sourcetype=sc4s:events...
syslog-ng checking config
sc4s version=3.42.1
Configuring the health check port to: 8080
starting syslog-ng

If a pod does not start, debug it with:

kubectl describe pod {your_pod_name} -n sc4s

Configure HPA (Horizontal Pod Autoscaler)

HPA is already enabled in the values.yaml above. Verify it is active after deployment:

kubectl get hpa -n sc4s

You should see cpu: 1%/50% with MINPODS: 2 and MAXPODS: 10.

Enable GKE Node Autoscaler (Required)

The SC4S Helm chart enforces hard pod anti-affinity — each SC4S pod must run on its own dedicated node. This prevents CPU saturation caused by multiple SC4S pods sharing a node, which would cause new pods to crash-loop during scale-up.

Because of this, when HPA requests more pods than there are available nodes, the new pods stay in Pending state. The GKE Node Autoscaler detects Pending pods and automatically adds new nodes to the cluster — allowing the pods to start cleanly.

Warning

Without the Node Autoscaler enabled, new pods will stay Pending indefinitely when all nodes are occupied — HPA cannot scale beyond the initial node count. Previously, without hard pod anti-affinity, new pods were scheduled on already-saturated nodes and entered CrashLoopBackOff because syslog-ng could not initialize under CPU contention. Hard anti-affinity (built into the chart) prevents this by blocking co-location, but requires the Node Autoscaler to provide new nodes on demand.

Enable the Node Autoscaler with the following example:

gcloud container clusters update <your-cluster-name> \
  --enable-autoscaling \
  --min-nodes=1 \
  --max-nodes=5 \
  --region=<your-region> \
  --node-pool=default-pool

Refer to the GKE cluster autoscaler documentation for more details.

How HPA + Node Autoscaler work together:

  1. Traffic increases → CPU rises above 50% threshold
  2. HPA requests more SC4S pods
  3. Hard anti-affinity blocks scheduling on existing nodes → pods go Pending
  4. Node Autoscaler detects Pending pods → adds a new node
  5. Pod schedules on the new dedicated node → starts cleanly
  6. Traffic decreases → HPA scales pods back down → Node Autoscaler removes unused nodes

Validate your configuration

SC4S performs checks to ensure that the container starts properly and that the syntax of the underlying syslog-ng configuration is correct. Once the checks are complete, validate that SC4S properly communicates with Splunk. To do this, execute the following search in Splunk:

index=* sourcetype=sc4s:events "starting up"

Update SC4S

Whenever the image is upgraded or when you want your configuration changes to be applied, run:

helm upgrade sc4s splunk-connect-for-syslog/splunk-connect-for-syslog \
  -f values.yaml \
  -n sc4s

Stop SC4S

To delete the deployment run:

helm uninstall sc4s -n sc4s