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.
Great stuff.
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.
Vicente De Luca I never be a fan of overlay network. but it is so popular
Get with the times grandpa. Don't get left in the dust.
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 type is the best practice then at scale? Some type of discovery service?
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.
Willkommen im Schnakerparadies mit PowerPoint-Karaoke was für ein unbrauchbares Video.
nice one .Can please share the slides please ?
The slides are available on slideshare.