Why I Ditched the GKE Marketplace Deployment for Weaviate

May 9, 2025

While working with Weaviate on GKE, I ran into a subtle but frustrating problem around configuring secure API key authentication using the Google Cloud Marketplace deployment.

The Problem

The Marketplace version of Weaviate installs a Helm chart under the hood, but it’s abstracted away — you don’t manage it directly with helm upgrade, and it doesn’t show up in helm list.

Instead, the configuration is split between:

  • A mounted ConfigMap (conf.yaml) passed via --config-file
  • A StatefulSet defining environment variables
  • Optional Kubernetes Secrets that should be usable for sensitive values like API keys

The catch? The --config-file flag makes the ConfigMap take precedence over all environment variables — even if you inject them correctly by patching the StatefulSet.

Worse, you can’t reference secrets inside a ConfigMap, and yet that’s the only configuration file that Weaviate truly honors in this setup. So I ended up in a contradiction:

  • I can’t store secrets in the ConfigMap (it's insecure)
  • I can’t use secrets via env vars, because the config file overrides them
  • I can’t remove the config file without rewriting the entire deployment model

My Fix

I abandoned the Marketplace deployment and installed Weaviate directly via Helm using this official GKE tutorial.

This gave me full control:

  • I could reference Kubernetes Secrets securely via envSecrets
  • I dropped the ConfigMap override entirely
  • I managed ingress, TLS, and authentication all from values.yaml

Final Thoughts

It’s one of those Kubernetes oddities where the interplay between declarative configs and cloud-managed abstractions turns into a dead end. If you're deploying Weaviate on GKE and need secure API key authentication, skip the Marketplace and go with the Helm chart directly. It’s simpler, safer, and far more flexible in the long run.

PS: In case you are following the official GKE tutorial, I have a tip. As of writing this blog on 09-05-2025, the line in the guide provided by Google: kubectl get weaviate -n weaviate --watch is wrong, as it tries to reference weaviate as a resource type of Kubernetes, where as we know that Weaviate is a service. It'll return error: the server does not have a resource type "weaviate". The correct command is kubectl get svc -n weaviate --watch.