True Network Engineers would be unhappy if you're relying on overlay and NAT, as you lose performance, visibility and breaks end to end IP connectivity. IP per containers brings operational overhead, which can be resolved with software and best practices. But using overlay brings IP Packets overhead, which will impact your performance (no matter hardware offload). NAT will complicate troubleshooting when you trace a request origin down to a server with 200 containers... which one made that request ? and others down falls. as a network dude I always advocate for IP per container in production workloads.
Correct, and many Devs and Many DevOPS have no fucking clue how their Network works to be honest.. 😅 as someone with a network background now immersed on this world I can tell the lack of knowledge is huge among my peers.
haha, same came to my mind in the 1/2 of this presentation. Like application admins had no clue about the network, so they created their own on top of it :D
Which network driver do I need to opt, if I want to access the service in a container from my LAN. The docker host has two ethernet interfaces, one is configured with LAN IP addr. The other one is connected to internet, but not configured with any IP addr. The internet facing interface of the host need to be bridged to the container, which needs to be configured with internet ip addr. So that the container can speak to internet but not with LAN, and I can access the service via browser from LAN.
