Container Networking From Scratch - Kristen Jacobs, Oracle

CNCF [Cloud Native Computing Foundation]

Подписаться 116 тыс.

Просмотров 60 тыс.

50% 1

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Container Networking From Scratch - Kristen Jacobs, Oracle
Learn how to construct an overlay network across multiple hosts in just a few lines of bash! Containers in a system such as Kubernetes need to be able to communicate, and a common networking solution is to use an overlay network, for example, Flannel. In this talk we aim to 'demystify' container networking, and it's constituent elements such as Linux bridges, veth pairs, routing routes and TUN/TAP devices. Starting with defining a simple network namespace, we will work through networking between containers on the same machine (using the default docker model), up toward a full overlay network spanning multiple machines (as in Kubernetes). We will explain both how this works and why/when it is required, providing the necessary background for understanding and evaluating common existing Kubernetes networking solutions such as Flannel and Calico.
To learn more: sched.co/GrWx

Кино

Опубликовано:

31 май 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 50

@OliThomas4882 9 месяцев назад

Loving the Bristol accent. Cheers drive, lush networking stack mind!

@ajayd94 Год назад

Kris has to be the best you can learn anything cloud from. Had the privilege to learn as a part of his team at oracle.

@mloskot 5 месяцев назад

What a genius way of explaining the topic! Thanks

@liujian154 4 года назад

It's really a great presentation. Everything suddenly became crystal clear.

@claudiomfreitas 5 лет назад

Someone give this guy an award!

@user-do4xu4io9n Год назад

Great presentation, explains the missing chapters in many kubernetes guides

@jozsef.schild 4 года назад

Great presentation, thank you! I also like your humbleness and approach from 0:20 - 0:35.

@yiningchu5069 2 года назад

Great Video! The demo is very practical and illustrative for network newbees like me!

@lich1710 5 лет назад

Excellent!!! Amazed at how you can explain this complicated stuff simply. Thanks!

@atsadikov 5 лет назад

Excellent!!! Very detailed presentation

@tamerelfeky1721 5 лет назад

Clear to the goal , Thanks Kristen

@walkingtree5 5 лет назад

Thank you. You did an awesome job and helped me understand how to set this up on bare metal. Hats off to you sir.

@linjunhong2005 4 года назад

seeing this for free is a blessing. Thanks!

@aadhavanrajasekar3990 4 года назад

Great presentation to understand overlay network

@kimyves77 3 года назад

Great presentation, perfect demos ! Kudos

@followthetrawler 3 года назад

Very insightful presentation! Thanks for all the hard work.

@adityanagesh4922 3 года назад

Amazing presentation! Thanks a lot!

@JitenPalaparthi 2 года назад

Wonderful Presentation.

@tschlottke 3 года назад

excellent explanation, well structured

@cloudexpress9694 4 года назад

Very well presented. Thank you.

@vidhyadharp 3 года назад

Thanks, very helpful talk Kristen

@jkjlkhiugoo 3 года назад

Great, very well explained, thank you.

@whyzed603 2 года назад

Thank you, i cleared a lot of stuff here.

@tommasoborgato 4 года назад

Great presentation.... it’s the missing chapter in many Kubernetes books

@toenytv7946 3 года назад

Great packaging overview.

@vinaykaradia6530 5 лет назад

It was amazing. I was in very trouble to understand this stuff by my own, but couldn't link things with each other. Now I can. Thanks

@Indians-In-Germany-With-Dipak 3 года назад

Great thanks Awesome presentation !

@abdulrahmansattar2873 4 года назад

Awesome stuff!

@pengdu7751 3 года назад

great talk

@FredrikJanssonSe 5 лет назад

Awesome!

@lalitthakur1360 2 года назад

Amazing Stuff !!

@crazycsa 2 года назад

Clear ! Thanks!

@deepakgunjal2475 3 года назад

Excellent

@shivakumarhr3351 3 года назад

Immense thanks for this

@huabingzhao7685 4 года назад

Very clear explanation! Can I find the scripts used in the video on GitHub?

@jkristjanvalk Год назад

In your 4th and final scenario, containers are in different IP subnets. This does not play well as the idea of an overlay is that the containers can move between hosts and retain their IP address.

@alfredoboscabataller9899 4 года назад

Great talk! When you say multiple nodes (Case 3)... do you mean multiple Servers like could be CIsco UCS? Thanks!

@VinayKumar-gs4lc 3 года назад

Yes, we can setup multiple such nodes.

@avikjis27 4 года назад

Really very nice, neat and informative presentation. I tried to follow a similar approach for one of my session but stuck at some points as I mentioned below - What is the 9000 port at 25:23min? I cant see any rule that could route traffic to tun0 interface in 25:23. But you mentioned the same in 21:17. Am I missing something?

@bandisandeep 4 года назад

socat adds the route automatically. Any packet destined for 172.16.0.0/16 will be directed to tun0.

@avikjis27 4 года назад

@@bandisandeep Not really sure if it adds that route automatically. In my case, I have to explicitly add that route to make that work

@nickcollins5745 4 года назад

Can someone help me understand his answer to the UDP question around 23:00 , I don't understand where the reliability is coming from?

@nickcollins5745 4 года назад

Answering my own question: So let's say your container is interacting with another container using a TCP connection, and has to use the TUN device to get there. The connection’s reliability is already guaranteed by the upper layer protocol. Since our TUN device is using a UDP tunnel to load a website. Your browser would use TCP to connect to the port 80 of the server hosting the website. The browser has no idea your connection is going through a UDP tunnel and neither does the said TCP protocol. The TCP connection gets established and you get full advantage of all the features it has to offer. If the lower layer (The UDP stream) drops a packet, the TCP connection established inside it would notice and re-request it.

@parthibanns1485 4 года назад

Question! Secnario 2: You've shown veth and bridge, and it's also mentioned veth forwards traffic to other pod's veth by means of the bridge inbetween. I understand a Linux bridge operates at layer 2 of the TCP/IP which transports data as frames (as against packets in layer 3), and knows the destination to send the frames to by means of a MAC address (as against IP address used in layer 3) stored in a database in the bridge . I also understand veth interfaces have MAC addressses. So in this case, when traffic flows from one pod to another there's no need for using destination IP address. Is my assumption correct? Someone somewhere mentioned ARP comes in-between in here (which basically does the job of translating MAC to IP). I'm not sure if it is true that ARP is used here. Could someone clarify on this please? Refer: wiki.openvz.org/Virtual_Ethernet_device

@VinayKumar-gs4lc 3 года назад

For routing from one pod to another we communicate using the concept of using IP addresses. Because from pod to pod there's no need of network address translation needed. Here the packets transfer between pods is based on tcp/ip purely and uses the udp protocol. Only when the packet is meant for a pod running on in a different namespace does it require a tcp model of packet transfer which is handled by the cloud or the external network routing.

@davidmatthew4555 Год назад

I think you're right. Somebody correct me if I'm wrong, but from my understanding, when you have a layer 2 switch (which the linux virtual bridge acts like), it routes data based solely on the ethernet frame. Meaning the bridge won't unwrap the frame any further to look for an IP header or anything. The bridge would route the packets to the container correctly, but beyond that you'd have to figure out how to get the data to the process running in the container. The linux kernel has code that associates tcp/udp ports to different processes (layer 4). I'm not sure what mechanism there is to associate raw layer 2 data with a process. Maybe using dftables.