Skip to main content

Running Striim in the Google Kubernetes Engine

Striim on Google Kubernetes Engine lets you deploy and operate Striim using the same Kubernetes platform, automation, and operational practices you use for other enterprise applications. Kubernetes provides a common way to deploy, scale, monitor, upgrade, and manage applications across cloud environments.

This deployment model is especially useful for organizations that have adopted infrastructure-as-code practices. Platform teams can manage Striim configuration, resource allocation, upgrades, and environment changes through repeatable Kubernetes and Helm workflows, instead of relying on manual host-level configuration.

Use Striim on GKE when your organization already uses Kubernetes as a standard application platform and wants Striim to fit into that operating model. With this approach, teams can apply existing cluster governance, CI/CD processes, version-controlled configuration, and Kubernetes controls for compute, memory, storage, and network access.

If your team does not yet operate Kubernetes, or if you prefer direct host-level control, running Striim on a virtual machine or on-premise server may still be the simpler option.

Prerequisites before deploying Striim on GKE

  • If not available already, install or deploy the following in your working environment:

    • Google Cloud Command Line Interface (gcloud) authenticated to the Google Cloud Platform project hosting the GKE instance where you will run Striim (see https://cloud.google.com/cli)

    • Kubernetes command line tool (kubectl) version 1.25 or higher (see https://kubernetes.io/docs/reference/kubectl/) with its context (kubectl config current-context) pointed at your GKE instance

    • Helm (see https://helm.sh/) 3.x installed locally and authenticated to the GKE instance

  • Configure a PostgreSQL instance for use as Striim's metadata repository and create a user for use by Striim. The user's password must contain only alphanumeric characters and underscores.:Give this user the CREATEDB privilege. The metadata repository database striimdb will be created by the Helm chart that deploys Striim.

  • Create the GKE cluster where you will deploy Striim. If you will run a multi-server Stirim cluster (see Adapting TQL applications for multi-server deployment), create a node for each replica. (In the Kubernetes environment you create multiple replicas of one server rather than installing multiple servers.)

  • Verify that Striim has provided you with the product key, license key, and admin, system, and keystore passwords for your new Striim cluster, as well as the Google Cloud service account key required to pull Helm charts and Docker images from our Artifact Registry.

Configure your local shell to access GKE

Run the following commands once to give your local shell access to GKE. If you will use more than one shell with GKE, run these commands on each of them.

  1. Log into GCP.

    gcloud auth login
    gcloud config set project <GCP project ID>
  2. Configure Docker/Helm for Artifact Registry.

    gcloud auth configure-docker us-docker.pkg.dev
  3. Get cluster credentials.

    gcloud container clusters get-credentials <CLUSTER_NAME> \
      --region <region of GCP project> --project <GCP project ID>
  4. Verify.

    kubectl get nodes 

Configure credentials for image pulls

Create a docker-registry Secret in the release namespace from the service account key provided by Striim.

kubectl create namespace striim
kubectl create secret docker-registry striim-pull \
  --namespace striim \
  --docker-server=us-docker.pkg.dev \
  --docker-username=_json_key \
  --docker-email=any@example.com \
  --docker-password="$(cat <path to and name of service account key JSON file>)"

Prepare the my-values.yaml file

We will provide you with a values.yaml file containing expected defaults. We recommend making a copy of this file named my-values.yaml. You may name it anything you like, but in the examples here we refer to your copy as .my-values.yaml Manage this copy with a version control system such as Git.

You must set the following values before deploying Striim.

default value

set to

cloud: ""

cloud: "gcp"

replicaCount: 1

Set to the number of Striim servers you will deploy. If you will have only a single Striim server, leave set to 1.

striim:
  adminPassword: ""
  systemPassword: "" 
  keystorePassword: ""

Specify the passwords we provided.

striim:
  adminPassword: ""
  systemPassword: "" 
  keystorePassword: "********"
startupProperties:
  HttpEnabled: true
  HttpsEnabled: true ...

Add the WAClusterName, ProductKey, and LicenseKey values provided by Striim.

startupProperties:
  WAClusterName: <cluster name provided by Striim>
  ProductKey: <product key provided by Striim>
  LicenceKey: <license key provided by Striim>
  HttpEnabled: true
  HttpsEnabled: true ...
db:
  host: ""
  port: "5432"
  name: "striimdb"
  type: "postgres"
  striimUsername: ""
  striimPassword: ""
  version: "15.0"

Specify the appropriate values for your PostgreSQL instance and its Striim user. Set the port and version as appropriate for your environment.

db:
  host: "<IP address of PostgreSQL server>"
  port: "5432"
  name: "striimdb"
  type: "postgres"
  striimUsername: "<name of the user you created for use by Striim>"
  striimPassword: "<password for that user>"
  version: "15.0"
image:
  pullPolicy: IfNotPresent
  pullSecrets: [] 
...
image:
  pullPolicy: IfNotPresent
  pullSecrets:
    - striim-pull
...

Deploy Striim

Caution

Always use helm ... -f my-values.yaml. Do not use helm ... --reuse-values: this tells Helm to ignore your values file and reuse whatever is currently in the cluster, which means you will not have a useable record of the current state if you need to restore or roll back.

  1. Authenticate Helm to Striim's Artifact Registry using the service account key we provided you.

    gcloud auth activate-service-account \
      --key-file=<path to and name of service account key JSON file>
    gcloud auth print-access-token | \
      helm registry login -u oauth2accesstoken --password-stdin us-docker.pkg.dev
  2. Verify that Helm can pull the chart.

    helm pull \
      oci://us-docker.pkg.dev/striim-infra-public-prd/striim-helm-charts/striim \
      --version 5.4.0
  3. Run. Helm install.

    helm install striim \
      oci://us-docker.pkg.dev/striim-infra-public-prd/striim-helm-charts/striim \
      --version 5.4.0 \
      --namespace striim --create-namespace \
      -f my-values.yaml
  4. Verify the installation.

    • Check pod status:

      kubectl get pods -n striim

      Expected output:

      striim-0  1/1  Running
    • Check network policy:

      kubectl get networkpolicy -n striim

      Expected output: you should see one NetworkPolicy named striim. Confirm its egress rules cover the PostgreSQL host.

  5. Log in to the Striim web UI.

    kubectl port-forward -n striim svc/striim 9080:9080

    Then with a web browser, log in at http://localhost:9080 with the username admin and the admin password you specified in my-values.yaml.

Updating Striim's configuration in GKE

To update your Striim cluster's configuration:

  1. Edit my-values.yaml to reflect the desired new configuration.

    • To add more memory or additional CPUs, edit the resources section:

      resources:
        requests:
          memory: "4Gi"
          cpu: "2"
        limits:
          memory: "32Gi"
          cpu: "8"

      If needed, GKE will automatically allocate more memory and CPUs up to the limits. Depending on your applications' requirements you may need to increase the limits.

    • To add more disk space:

      persistence:
      ...
        size: "500Gi"
    • To add additional Striim servers (replicas), edit replicaCount:

      replicaCount: 2
  2. Apply the updated configuration:

    helm upgrade striim ./helm/striim \
      --namespace striim \
      -f my-values.yaml
  3. Follow the rollout:

    kubectl rollout status statefulset/striim -n striim

Upgrading Striim in GKE

Performing an upgrade automatically triggers a snapshot of the data of the Striim cluster's local data.

To apply a patch upgrade (for example, 5.4.0.2 to 5.4.0.4):

  1. Plan and announce a maintenance window as there will be a brief service down time.

  2. Back up Striim's metadata repository (see Backing up the metadata repository host) This step is not necessary if the metadata repository host is managed PostgreSQL with point-in-time recovery enabled.

  3. Edit my-values.yaml to specify the new version:

    patch:
      striimVersion: "5.4.0.4"
  4. Apply the updated configuration:

    helm upgrade striim ./helm/striim \
      --namespace striim \
      -f my-values.yaml
  5. Follow the rollout:

    kubectl rollout status statefulset/striim -n striim

If the upgrade fails, Contact Striim support.

To perform a full version upgrade (for example 5.4.0 to 5.4.2, or 5.4 to 5.5):

  • Striim may be down for up to half an hour, so schedule this during a maintenance window.

  • Before starting the upgrade, back up the metadata repository.

  1. Pull and unpack the Helm chart for the new version:

    elm pull \
      oci://us-docker.pkg.dev/striim-infra-public-dev/striim-helm-charts/striim/
      --version 5.4.2.0
    tar -xf striim-5.4.2.0.tgz -C ./helm
  2. Edit my-values.yaml to enable the upgrade and clear any patch value:

    upgrade:
      enabled: true
    ...
    patch:
      striimVersion: ""
  3. Run the upgrade:

    helm upgrade striim ./helm/striim \
      --namespace striim \
      -f my-values.yaml
  4. Follow the rollout:

    kubectl rollout status statefulset/striim -n striim
  5. Verify the upgrade:

    kubectl get pods -n striim
    kubectl get pod striim-0 -n striim -o jsonpath='{.spec.containers[0].image}'

    The image tag should match the new chart's appVersion. In the Striim UI, navigate to Help > About and confirm the version.

  6. Edit my-values.yaml to set the upgrade flag back to false:

    upgrade:
      enabled: false

If the upgrade fails, Contact Striim support.

Operational considerations when running Striim in GKE

Striim Platform features not available when running in GKE

  • the SysOut adapter

Viewing the logs

Use the following commands to view the logs:

kubectl logs striim-0 -n striim
kubectl logs striim-0 -n striim --follow
kubectl logs striim-0 -n striim --previous   # last terminated container
kubectl get cronjob -n striim
kubectl logs -n striim --selector job-name=striim-snapshot-hourly --tail=200

Viewing the cluster state

Use the following commands to view the cluster state:

ubectl get all -n striim
kubectl get pvc -n striim
kubectl get networkpolicy -n striim
kubectl get cronjob -n striim
kubectl get volumesnapshot -n striim
kubectl get managedcertificate -n striim   # GKE only
kubectl describe pod striim-0 -n striim
helm get values striim -n striim
helm history striim -n striim

Troubleshooting

Symptom

First thing to check

Likely cause

Helm reports a failed pre-install Job

kubectl logs job/striim-mdr-migrate-install -n striim (set debug.keepHookResources=true first)

DB credentials, DB reachability, DB user permissions

Pod stuck ContainerCreating over 5 min

kubectl describe pod striim-0 -n striim Events

Image pull failure or wrong registry

Pod CrashLoopBackOff immediately

kubectl logs striim-0 -n striim --previous

Bad license key, missing required password, DB schema mismatch

Pod CrashLoopBackOff after a patch or upgrade

kubectl logs striim-0 -n striim --previous

New image incompatible with on-disk state — restore from pre-rollout snapshot

Pod stuck Pending

kubectl describe pod striim-0 -n striim scheduler events

Node lacks resources, or nodeSelector/tolerations mismatch

ManagedCertificate stuck Provisioning over 60 min

nslookup your ingress host from outside the cluster

DNS A record not pointing at the LB IP

502 / 503 from ingress

kubectl get ingress, BackendConfig health checks

Health check probe path or NEG attachment problem

helm upgrade hangs over 20 min

kubectl get jobs -n striim, kubectl logs job/<job name>

Stuck migration Job, stuck snapshot Job, missing snapshot CRDs

VolumeSnapshot stuck readyToUse=false

kubectl describe volumesnapshot <snap name>

CSI snapshotter pod down, or quota exhausted on the cloud-provider snapshot service

Hourly snapshots not running

kubectl get cronjob -n striim, kubectl get jobs -n striim

CronJob suspended, RBAC missing, or snapshots.hourly.enabled=false

NetworkPolicy denies traffic to a new source

kubectl get networkpolicy striim -n striim -o yaml

Missing customEgressRules entry

UI loads but login fails

Confirm striim.adminPassword matches what is in the rendered Secret: kubectl get secret striim-striim-secret -o jsonpath='{.data.adminPassword}' \| base64 -d

Password drift between my-values.yaml and what was last applied

UI keeps logging me out

Increase startupProperties.SessionTimeoutSecs

Default is 15000 seconds (~4 hours) — UIs often expect longer

Miscellaneous commands

# Show the active image tag
kubectl get pod striim-0 -n striim -o jsonpath='{.spec.containers[0].image}'

# Show all values currently applied
helm get values striim -n striim

# Show the rendered manifest (debugging template issues)
helm get manifest striim -n striim

# List all VolumeSnapshots grouped by lane
kubectl get volumesnapshot -n striim -L striim.io/snapshot-lane

# Tail Striim logs and grep for errors
kubectl logs striim-0 -n striim --follow --tail=500 | grep -i 'error\|exception'