Redpanda ran fine in docker-compose. The first time it started in Kubernetes, it crashed immediately:
posix_listen failed: Cannot assign requested address (10.96.207.132:33145)The address it couldn’t bind to was its own Service ClusterIP. That’s the lesson hiding in the crash.
// 01 — THE SETUP
The manifest told Redpanda to listen on its RPC address, set to the service name phronis-redpanda:33145. In Compose, a service name resolves to the container, and binding works. In Kubernetes, the same name resolves to something different.
// 02 — THE CULPRIT
phronis-redpanda in the cluster resolves to a Service ClusterIP, a virtual address owned by kube-proxy, not by any pod’s network interface. A process can only bind() to an address that exists on its own interfaces. The ClusterIP isn’t one of them, so the listen syscall fails with “cannot assign requested address.” The pod was trying to bind an IP it doesn’t own.
// 03 — THE FIX
Separate where you listen from how others reach you:
--rpc-addr=0.0.0.0:33145 # bind all local interfaces
--advertise-rpc-addr=phronis-redpanda:33145 # tell peers to route via the ServiceBind 0.0.0.0 (every interface the pod actually has), and advertise the Service name so other pods still route to it through Kubernetes. Listen locally, advertise globally.
TAKEAWAYS
- A pod cannot bind to its Service ClusterIP. That IP belongs to kube-proxy, not the pod. Bind
0.0.0.0. - Most brokers separate “listen address” from “advertised address” for exactly this reason. Bind to all interfaces; advertise the routable name.
- A config that’s correct in docker-compose can be wrong in Kubernetes without changing a character, because name resolution means something different in each.
NEXT
- Anomaly log: the init container that couldn’t reach localhost.
