High Availability (HA) Deployment - Kubernetes Production Setup
Deploy OpenObserve in high availability (HA) mode for production observability workloads. This guide walks through deploying on Kubernetes with Helm using object storage (S3, GCS, MinIO, Swift, Civo) and PostgreSQL or MySQL as the metadata store.
While OpenObserve can run in HA mode on bare metal servers, VMs, and other platforms, we officially provide installation via Helm charts for Kubernetes. Local disk storage is not supported in HA mode, so an object store is mandatory.
This guide will help you:
- Set up prerequisites (CLI tools, operator, bucket).
- Download and customize
values.yaml. - Configure object storage and the metadata store.
- Install OpenObserve with Helm.
- Verify the deployment.
Prerequisites
You need:
- A Kubernetes cluster you have admin access to.
kubectlandhelminstalled locally.- An object storage bucket created beforehand (S3, GCS, MinIO, Swift, or Civo). The bucket itself is not created by the chart.
- The Cloud Native PostgreSQL Operator installed in the cluster. This is required because the chart provisions its PostgreSQL cluster (1 primary + 1 replica) through cnpg.
Install the cnpg operator:
kubectl apply --server-side -f \
https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.23/releases/cnpg-1.23.1.yaml
Sizing the cluster
For recommended CPU, memory, and storage values per component, see Capacity planning.
Download values.yaml
For accessing the object store we recommend the best security practice of using IAM roles wherever possible. In case of Amazon EKS you can use IAM roles for Service Accounts (IRSA).
You must download the values.yaml file and make required changes. At a minimum you must provide the details of bucket to be used for data storage and credentials (IAM role or keys) to access it. You can download the file using the following command:
curl https://raw.githubusercontent.com/openobserve/openobserve-helm-chart/main/charts/openobserve/values.yaml -o values.yaml
Configure object storage
Amazon EKS + S3
You must set a minimum of 2 values:
- S3 bucket where data will be stored
- IAM role for the serviceAccount to gain AWS IAM credentials to access s3
Once you have configured the above in your values.yaml file, you can run the commands in Install OpenObserve below.
Follow AWS documentation to enable IRSA and create an IAM role that you can use. You can also refer to the IRSA introduction blog.
Sample IAM policy
{
"Id": "Policy1678319681097",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1678319677242",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:DeleteObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::<your-bucket>/*"
}
]
}
Video walkthrough
Any Kubernetes + S3
Add/Modify following to values.yaml
- S3 bucket where data will be stored
Any Kubernetes + MinIO
Add/Modify following to values.yaml
- S3 bucket where data will be stored
Any Kubernetes + GCS
Add/Modify following to values.yaml
- GCS bucket where data will be stored
You can generate keys for GCS bucket using following steps:
- Go to Google cloud console > Cloud Storage > Settings > Interoperability
- Make sure you are in the right project.
- Access keys for your user account > Click "CREATE A KEY"
Video walkthrough
Any Kubernetes + OpenStack Swift
Add/Modify following to values.yaml
- swift bucket where data will be stored
Any Kubernetes + Civo Object Store
Add/Modify following to values.yaml
- civo object store will store the data
Metadata store
You can use PostgreSQL or MySQL as metadata storage.
Default: bundled PostgreSQL
The official Helm chart (from Feb 23rd 2024 onward) uses PostgreSQL as the metadata store by default. It installs a PostgreSQL cluster (1 primary + 1 replica) for you via the cnpg operator. You don't need any additional configuration if you want to use the bundled instance.
PostgreSQL (external)
If you want to use external PostgreSQL, configure as below. Create the database first. In this example we use openobserve as the database name.
config:
ZO_META_STORE: "postgres"
auth:
ZO_META_POSTGRES_DSN: "postgres://postgres:12345678@localhost:5432/openobserve"
postgres:
enabled: false # disable bundled PostgreSQL
MySQL
Create the database first. In this example we use openobserve as the database name.
config:
ZO_META_STORE: "mysql"
ZO_META_MYSQL_DSN: "mysql://user:12345678@localhost:3306/openobserve"
NATS cluster coordinator
NATS is used by OpenObserve as the cluster coordinator. The official Helm chart configures NATS for you, so no additional configuration is required.
Install OpenObserve
Install the chart:
helm repo add openobserve https://charts.openobserve.ai
helm repo update
kubectl create ns openobserve
helm --namespace openobserve -f values.yaml install o2 openobserve/openobserve
Verify deployment
After running helm install, confirm every pod is healthy before pointing traffic at OpenObserve.
Verify
Verification step
# Watch pods come up (Ctrl+C once everything is Running)
kubectl -n openobserve get pods -w
# Final pod state. Confirm every pod is 1/1 (or 2/2 for NATS) and Running
kubectl -n openobserve get pods
Expected output
- ~12 pods, every one
READY 1/1(or2/2for NATS) andSTATUS Running. Components: NATS x3, postgres x2, openfga, alertmanager, router, ingester, querier, compactor, openfga-init. - Image:
o2cr.ai/openobserve/openobserve-enterprise:<tag>(or the OSS image, depending on your chart values). - If a pod is stuck in
ImagePullBackOff, checkkubectl -n openobserve describe pod <name>and verify outbound internet from the cluster.
Then port-forward the router service to reach the UI:
Open http://localhost:5080 and sign in with the credentials you set in values.yaml.
Uninstallation
Next steps
- Capacity planning: sizing CPU, memory, and storage for each component.
- Performance tuning: caching, configuration, and high-throughput tuning.
- Architecture: understand how the components interact.
- Environment variables: full reference for
ZO_*configuration.
Need some help?
- Join our Community Slack
- Or Contact support