0

My system is composed by a UDP client that sends a UDP ping message to a server spawned by a Kubernetes deployment. The server is composed by 2 replicas behind a metallb load balancer service.

The actual message routing acts as follow:

  • One of the pod (say POD1) receives the message
  • POD1 store it (with source ip and port) inside a cache
  • POD1 enters in a idle status
  • The other pod of the replicaset (POD2) get the cached message and source address
  • POD2 replies
  • POD2 receives a port unreachable ICMP error.

I think that, since my UDP response source IP is different from the destination IP of the original request, the service cannot map the final destination IP.

I feel I'm missing an annotation that solves my issue. Is metallb the responsible of the port mapping? Am I forced to use a UDP proxy server instead? If so can you share an already implemented solution?

RugUrmet
  • 13
  • 4

1 Answers1

0

My friend answered my question with message bellow. Basically is not an K8S problem, but just the way TCP and UDP is. My final solution was redesign the application to send/receive messages by same pod.

The application makes no sense. A request cannot start in one through and end in another, outside using specific physical network resources such as multicast. That's not how the K8S is thought of. The icmp is returned because that's what it's for, the ip stacks should send the routing errors response through it. ICMP is a control protocol, not a data transfer protocol. If your application has the same proposal, start the request in a post and respond in another, redesign your design. A socket, TCP/UDP is formed by the tuple source_ip:source_port:destination_ip:destination_port The load balancer works by registering the tuple in the input, rewriting the target part, and resending the packet. When the return occurs, this process is undone. If another Host responds to the request, there is no record of the incoming request to be sent back and the LB returns icmp destination unreachable to whoever sent a reply without a request.

Benedito Marques
  • 174
  • 1
  • 3