Minikube client app unable to connect to cp-all-in-one broker

Hi all

so I’m running the cp-all-in-one stack.
I’m producing from a golang app native / OS… aka outside docker and K8s. ← working
I’m trying to consume from a app thats deployed inside minikube.

I followed Robin’s doc : https://www.confluent.io/blog/kafka-client-cannot-connect-to-broker-on-aws-on-docker-etc/?_ga=2.52473832.1725757469.1620368537-58895641.1620368537 #4 for the production side, thats working.

The consumption side is not wanting to work. which of the options would I follow… although minikube is running inside docker, I don’t think it’s valid to consider my app is in docker / on the same network ?

Interesting enough… I can’t access control-centre or schema-manager either (tried schema-manager via curl)

G

Hi,

is minikube running on the same machine as cp-all-in-one stack?

is there a need to run the app inside minikube?

yes, I have docker on MBP, in which cp-all-in-one run’s.

I then use minikube, which run’s inside the same docker to simulate a k8s cluster,

The app is a development investigation, the first part needs to run outside, this part is working, it’s reaching/talking to the Kafka cluster, the fix was #4 of Robin’s network document,
The 2nd part of the app is 4 pods running inside the minikube environment, with various containerised databases, these pods connect to the kafka topic/partitions, or well it tries to, failing atm.

G

ok I see
did you try to ping or telnet the kafka broker from one of the minikube pods?

@georgelza You could also try connecting to the kafka broker/cluster with kafkacat and use the metadata listing option (-L) to see how the brokers are advertising their listener. GitHub - edenhill/kafkacat: Generic command line non-JVM Apache Kafka producer and consumer

… I"ll try and do this, just want to first fix this issue of docker-compose every time I do a docker-compose up pulling the entire stack… data/bandwidth is seriously expensive and this is not a small pull every time. Once thats resolved and I can stop/start the stack repeatedly will dig deeper into this.

Got to be honest though (now that I recall another “issue” I had, which I eventually fixed by simply deploying the code inside minikube), don’t think this is cp-all-in-one caused… this is apps deployed inside minicube not knowing how to get to apps not in minikube, be that native on the OS or in this case inside docker.

G