Skip to main content

Access & Configure Weaviate

We have now spun up a Weaviate instance in our Kubernetes cluster. So what's next? In this section, we will look at how to access the Weaviate service, and how to configure it to suit your needs.

Access Weaviate

Although our Weaviate service is happily running, it is not yet accessible from the outside world. This is because we have not exposed the service to the outside world. Let's do that now.

Expose the services

Run the following command:

minikube tunnel

You will recall that we configured the weaviate service as a LoadBalancer type in our Helm chart. So, when we run minikube tunnel, it will expose the service to the outside world - or at least, to our local machine.

You will see a message like:

✅  Tunnel successfully started

📌 NOTE: Please do not close this terminal as this process must stay alive for the tunnel to be accessible ...

❗ The service/ingress weaviate requires privileged ports to be exposed: [80]
🔑 sudo permission will be asked for it.
🏃 Starting tunnel for service weaviate.
🏃 Starting tunnel for service weaviate-grpc.

At this point you will be asked for your password. Enter it and the tunnel will be established. Note that closing the terminal or stopping the process will close the tunnel, making the services inaccessible again.

About minikube tunnel

minikube tunnel creates a route between your local machine and the Minikube cluster. This allows services within your Minikube cluster that are exposed as LoadBalancer to be accessible on your local machine for development.

We suggest you only run the tunnel command when you need to access the service from your local machine. When you are done, you can stop the tunnel by pressing Ctrl+C.

Confirm access

Now, if you run:

kubectl get svc weaviate -n weaviate

You will see the external IP address of the service. For example:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
weaviate LoadBalancer 80:31230/TCP 61m

Navigate to http://<external-ip>:80/v1 in your browser (typically You should see the Weaviate REST root endpoint, with links to the various endpoints available in Weaviate.

Now, you might also recall that we've opened up the gRPC service in our Kubernetes configuration. This service is available on port 50051. You can confirm this by running:

kubectl get svc weaviate-grpc -n weaviate

Which will show:

NAME            TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)           AGE
weaviate-grpc LoadBalancer 50051:32150/TCP 90m
Another way to confirm access to the gRPC service

If you have netcat installed, you can also try:

nc -zv 50051

Which will show:

Connection to port 50051 [tcp/*] succeeded!

Note that not all systems have nc installed by default. It's okay if you don't have it - the kubectl get svc command output is sufficient to confirm access to the gRPC service.

Configure Weaviate

One of the best things about Kubernetes is that you can easily configure your services. Weaviate is no exception. You can configure Weaviate by updating the values.yaml file in the weaviate directory.

For example, you can enable additional modules such as text2vec-openai and generative-openai modules by setting them to true:


enabled: true # ⬅️ Set to true

# ... other settings not shown ...


enabled: true # ⬅️ Set to true

Or we can set resource limits for the Weaviate pods. Let's set them to utilize 30-50% of a CPU, and 150-300Mi of memory:

Where to set resource limits

The values.yaml file contains multiple instances of requests and limits for different services, such as for local vectorization models. Make sure to set the requests and limits for the scale replicas of Weaviate towards the top of the file with no indentation.

# Scale replicas of Weaviate. ...
cpu: '300m'
memory: '150Mi'
cpu: '500m'
memory: '300Mi'

To apply these changes, save the values.yaml file and run:

helm upgrade --install \
"weaviate" \
weaviate/weaviate \
--namespace "weaviate" \
--values ./values.yaml

You will note that this is the same command we used to deploy Weaviate. This command will simply update the Weaviate deployment with the new configuration.

There are a whole host of other configurations you can set in the values.yaml file, such as modifying authentication, authorization, backups, monitoring, resource allocation and so on. Please refer to the in-line documentation in the values.yaml file, and the Weaviate documentation for more information.

Before we go, however, let's take a look at expanding our Weaviate deployment to include more nodes. This can help us to scale our Weaviate deployment to handle more traffic or growth, or to provide redundancy in case of node failure.

We'll take a look at both in the next section.

Questions and feedback

If you have any questions or feedback, please let us know on our forum. For example, you can: