Code of Conduct

• I have read and agree to the Weaviate's Contributor Guide and Code of Conduct

What part of document/web-page on weaviate.io is affected?

https://weaviate.io/developers/academy/deployment/k8s/access_weaviate

Issue

As seen below, by default, in a Kubernetes cluster, Weaviate exposes the container at port 8080 and 50051.

    name: weaviate
    ports:
    - containerPort: 8080
      protocol: TCP
    - containerPort: 50051
      name: grpc
      protocol: TCP

Therefore, it expects these container ports to be reachable by default to the host. The current documentation is incomplete about this.

As seen below, the minikube tunnel command creates unique external IP addresses for each Weaviate service, allowing them to be accessible from the host.

kubectl get service

NAME                TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)           AGE
weaviate            LoadBalancer   10.99.192.19     10.99.192.19     80:32551/TCP      35s
weaviate-grpc       LoadBalancer   10.110.147.194   10.110.147.194   50051:30508/TCP   35s

For example, a simple curl command to the external IP address of the HTTP load balancer service returns a JSON response from the API.

curl 10.99.192.19

{"links":{"href":"/v1","name":"api v1","documentationHref":"https://weaviate.io/developers/weaviate/current/"}}

However, when trying to interact with your pod via a client like the Weaviate Python client for example, the connection fails because the external IP generated for the weaviate and weaviate-grpc services are unique. So, a user may need to use a single unique hostname or IP address to fix this.

Fix

A quick solution is exposing the service's TCP traffic to the host via port-forwarding, so they are accessible via a single domain name like localhost or an IP address like 127.0.0.1.

The documentation currently lacks a command to achieve this. Without it, users may encounter difficulties accessing the pod through a client.


Additionally, the documentation includes an example that assumes the external IP address is 127.0.0.1 for both services. This may confuse users if there’s no additional configuration specifying that the services need to be exposed to localhost.

Are you working on this?

Yes, I’ll be opening a PR soon.

Additional comments?

No response