Open dcfranca opened 8 months ago
I have removed the tcp-https
on the service cloud-proxy-service, leaving only the tcp-grpc and tcp-http2 ones, and then I get an IP assigned to it (not sure if it is the right thing to do, but vzconn-service also doesn't have one
❯ kubectl get service cloud-proxy-service -n plc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
cloud-proxy-service LoadBalancer 10.43.209.160 192.168.5.1 4444:30058/TCP,5555:32671/TCP 43h
❯ kubectl get service vzconn-service -n plc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
vzconn-service LoadBalancer 10.43.53.124 192.168.5.1 51600:31468/TCP 19d
But still, ./dev_dns_updater
gets stuck, but now shows a bit more of logging
INFO[0000] DNS Entries entries="dev.withpixie.dev, work.dev.withpixie.dev" service=cloud-proxy-service
INFO[0003] Update addr=192.168.5.1 service=cloud-proxy-service
I manually added the host to the hosts file:
192.168.5.1 dev.withpixie.dev work.dev.withpixie.dev
Which at least resolve the address, but the connection to the server fails with a timeout
❯ curl -vv dev.withpixie.dev:5555
* Trying 192.168.5.1:5555...
* connect to 192.168.5.1 port 5555 failed: Operation timed out
* Failed to connect to dev.withpixie.dev port 5555 after 75002 ms: Couldn't connect to server
* Closing connection
curl: (28) Failed to connect to dev.withpixie.dev port 5555 after 75002 ms: Couldn't connect to server
Anyone?
Any suggestion on how I can solve this?
Do you need more details?
anyone?
@JamesMBartlett
Hi @dcfranca.
It's hard for us to debug issues in environments we don't officially support.
I'm not too familiar with Colima. However, it seems like they have an option to enable exposing an external IP: https://github.com/abiosoft/colima/blob/main/docs/FAQ.md#the-virtual-machines-ip-is-not-reachable
Have you tried running colima with that flag?
Describe the bug I'm deploying Pixie locally to a Colima cluster for testing and PoC purposes Running
./dev_dns_updater
seems to get stuck, so I checked the LoadBalancer services and I have a weird situationAs you can see
vzconn-service
worked fine and has an IP assigned, but for some reasoncloud-proxy-service
doesn't have it, which I think might be the root cause for the issue withdev_dns_updater
If both didn't have an IP I would assume that there is something wrong with the load balancer assignment, but if worked for one, why didn't work for the other?
I checked the pod events for the service and pod, but I don't see anything wrong there
The only thing I see are some warnings on the cloud-proxy-server container, but I don't think they are an issue:
Any idea what could be preventing the service of getting an external IP?
To Reproduce Steps to reproduce the behavior:
Expected behavior The External IP is assigned to the cloud-proxy-server
App information (please complete the following information):