Yes, this is a fairly common issue, especially with legacy or network-sensitive protocols.

The protocol often works perfectly on bare metal because it was designed with assumptions about networking, host identity, latency, or direct communication. Once it’s deployed in containers or Kubernetes, those assumptions can break down.

Some common causes include:

• Dynamic IP addresses instead of fixed hosts.

• NAT and overlay networking.

• Service discovery differences.

• Network policies restricting traffic.

• Load balancing affecting stateful connections.

• Multicast or broadcast traffic not behaving as expected.

In many cases, the protocol itself isn’t failing. It’s encountering an environment it wasn’t originally designed for.

I’ve seen teams spend days troubleshooting an application, only to discover the real issue was a networking assumption that worked on bare metal but didn’t translate to a Kubernetes architecture

This is a common challenge when moving workloads from bare metal to containers.

The protocol itself often isn’t broken. The environment has changed.

Many protocols were designed with assumptions about networking, latency, IP addressing, or direct host communication. Containers and Kubernetes introduce overlays, NAT, service discovery layers, proxies, and security policies that can disrupt those assumptions.

Some of the most common issues include:

• Broadcast and multicast traffic not working as expected.

• Dynamic pod IPs affecting stateful connections.

• Additional network hops increasing latency.

• Service meshes and ingress layers altering traffic behavior.

• Network policies blocking communication that worked on bare metal.

In my experience, the key question isn’t whether a protocol supports Kubernetes.

It’s whether the protocol’s networking assumptions align with a cloud-native environment.

Has anyone found a protocol that required significant redesign—or even replacement, when moving from bare metal to Kubernetes? 

A lot of protocols behave perfectly on bare metal and then become unpredictable once containers and Kubernetes enter the picture.

The protocol usually isn’t the problem. The environment is.

Containers introduce additional networking layers, NAT, overlays, service meshes, proxies, and security policies. Protocols that rely on direct host communication, multicast, broadcast discovery, fixed ports, or low-latency connections often run into issues when those assumptions no longer hold.

A few common examples:

• Service discovery protocols that depend on broadcast traffic may fail across Kubernetes networks.

• Stateful protocols can struggle when pods are rescheduled and IP addresses change.

• Low-latency or real-time communication protocols may be affected by overlay networking and additional hops.

• Security policies, ingress controllers, and service meshes can unintentionally block or modify traffic.

In my experience, the question is less:

“Does this protocol work in Kubernetes?”

and more:

“What assumptions does this protocol make about the network?”

The closer those assumptions are to a traditional bare-metal environment, the more testing and adaptation is usually required when moving to containers.

Has anyone encountered a protocol that required significant redesign or reconfiguration before it worked reliably in Kubernetes?