Kubernetes — Blixt Documentation

The Helm chart is in early access. Contact us to get the chart, and for help planning a production deployment.

What the chart deploys

Component	Kind	Default
Config server	Deployment	1 replica
File servers	Deployment with autoscaling	3–12 replicas
Cache servers	StatefulSet with persistent volumes	3 replicas
Write servers	StatefulSet with persistent volumes	3 replicas
Indexing, updater, replication	Deployments	1 replica each
NFS and SMB gateways	Deployments behind LoadBalancer Services	enabled
PostgreSQL	StatefulSet (or bring your own)	enabled
Notifier	Deployment	disabled

All pods run in one namespace, bfs in the examples below.

Prerequisites

A Kubernetes cluster with a default StorageClass for the cache, write and database volumes.
kubectl and Helm 3.
A bucket, and a way for pods to reach it: workload identity (recommended on GCP, AWS, Azure and Oracle) or a Secret holding keys.

Install

helm install bfs ./blixtfs -n bfs --create-namespace \
  --set backend=gcp \
  --set gcp.project=my-project \
  --set 'buckets={gs://my-bucket}' \
  --set auth.token="$(openssl rand -hex 32)"

auth.token is the shared token BlixtFS services use to authenticate each other. The chart stores it in the bfs-auth Secret. Always set your own: the chart’s default is a placeholder.

backend is one of gcp, aws, azure, oracle, minio, cloudflare, coreweave or local.

Wait for the pods, then find the gateway addresses:

kubectl -n bfs get pods
kubectl -n bfs get svc nfs smb

Mount from any client that can reach the NFS Service’s external IP:

sudo mount -t nfs -o vers=4 <EXTERNAL-IP>:/ /mnt/blixt

Credentials

Workload identity (GCP, AWS, Azure, Oracle): the chart annotates its service account for your cloud’s workload identity. Grant that identity access to the bucket in your cloud’s IAM, and no key is stored in the cluster.

Keys (MinIO, Cloudflare R2, CoreWeave): set them in your values file, and the chart stores them in a Secret (bfs-minio, bfs-cloudflare or bfs-coreweave):

backend: cloudflare
buckets:
  - r2://my-bucket
cloudflare:
  accountId: 0123456789abcdef
  accessKey: ...
  secretKey: ...
  apiToken: ...        # optional: change notifications

For production, keep keys out of values files that live in version control. Manage the Secrets with a tool such as Sealed Secrets or External Secrets.

Commonly changed values

Value	Purpose
`image.tag`	BlixtFS version. Pin it, for example `2.9.0`.
`buckets`	List of bucket specs to serve.
`file.replicas`, `file.autoscaling.*`	File server count and autoscaling.
`cache.replicas`, `write.replicas`	Size of the cache and write tiers.
`postgres.enabled`, `externalDatabase.*`	Use the bundled PostgreSQL or your own.
`protocol.nfs.enabled`, `protocol.smb.enabled`	Which gateways to run.
`auth.enabled`	Require the shared token between services.
`serviceMonitor.enabled`	Create a Prometheus Operator ServiceMonitor.
`eventLog.enabled`, `notifier.enabled`	Turn on the event log. Set both together.

Kubernetes workloads: the CSI driver

Pods inside the cluster can mount buckets as volumes through the BlixtFS CSI driver, instead of going through NFS. The driver can also provision a new bucket dynamically for a PersistentVolumeClaim. Contact us for the driver manifests while it is in early access.

Applying configuration changes

After changing values, upgrade the release and restart the config server so every server picks up the change:

helm upgrade bfs ./blixtfs -n bfs -f my-values.yaml
kubectl -n bfs rollout restart deploy/config

Security notes

The NFS gateway pod runs privileged, and the images currently run as root. Place BlixtFS in a dedicated namespace and restrict it with network policies.
Expose the NFS and SMB Services only to the networks that need them. The internal gRPC ports should never leave the cluster.