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 instanceHelm (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
striimdbwill 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.
Log into GCP.
gcloud auth login gcloud config set project <GCP project ID>
Configure Docker/Helm for Artifact Registry.
gcloud auth configure-docker us-docker.pkg.dev
Get cluster credentials.
gcloud container clusters get-credentials <CLUSTER_NAME> \ --region <region of GCP project> --project <GCP project ID>
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 |
|---|---|
|
|
| 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.
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
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
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
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.
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
adminand the admin password you specified inmy-values.yaml.
Updating Striim's configuration in GKE
To update your Striim cluster's configuration:
Edit
my-values.yamlto reflect the desired new configuration.To add more memory or additional CPUs, edit the
resourcessection: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
Apply the updated configuration:
helm upgrade striim ./helm/striim \ --namespace striim \ -f my-values.yaml
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):
Plan and announce a maintenance window as there will be a brief service down time.
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.
Edit
my-values.yamlto specify the new version:patch: striimVersion: "5.4.0.4"
Apply the updated configuration:
helm upgrade striim ./helm/striim \ --namespace striim \ -f my-values.yaml
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.
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
Edit
my-values.yamlto enable the upgrade and clear anypatchvalue:upgrade: enabled: true ... patch: striimVersion: ""
Run the upgrade:
helm upgrade striim ./helm/striim \ --namespace striim \ -f my-values.yaml
Follow the rollout:
kubectl rollout status statefulset/striim -n striim
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.Edit
my-values.yamlto set the upgrade flag back tofalse: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 |
| DB credentials, DB reachability, DB user permissions |
Pod stuck ContainerCreating over 5 min |
| Image pull failure or wrong registry |
Pod CrashLoopBackOff immediately |
| Bad license key, missing required password, DB schema mismatch |
Pod CrashLoopBackOff after a patch or upgrade |
| New image incompatible with on-disk state — restore from pre-rollout snapshot |
Pod stuck Pending |
| Node lacks resources, or nodeSelector/tolerations mismatch |
ManagedCertificate stuck Provisioning over 60 min |
| DNS A record not pointing at the LB IP |
502 / 503 from ingress |
| Health check probe path or NEG attachment problem |
helm upgrade hangs over 20 min |
| Stuck migration Job, stuck snapshot Job, missing snapshot CRDs |
VolumeSnapshot stuck readyToUse=false |
| CSI snapshotter pod down, or quota exhausted on the cloud-provider snapshot service |
Hourly snapshots not running |
| CronJob suspended, RBAC missing, or snapshots.hourly.enabled=false |
NetworkPolicy denies traffic to a new source |
| Missing customEgressRules entry |
UI loads but login fails | Confirm striim.adminPassword matches what is in the rendered Secret: | Password drift between my-values.yaml and what was last applied |
UI keeps logging me out | Increase | Default is 15000 seconds (~4 hours) — UIs often expect longer |
Recommended regular health checks
Check | How | Frequency |
|---|---|---|
Pod is Ready |
| Continuous (Prometheus / liveness probes) |
PVC usage |
| Daily |
Hourly snapshot success |
| Daily |
metadata repository database reachability | Run a psql test from inside the cluster | After every configuration change |
ManagedCertificate Active (GKE) |
| Continuous |
Striim license expiry | UI -> Help -> About | Monthly |
Helm release status |
| After every change |
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'