Networking in Containers: Understanding Docker Network Models
•Transferir como PPTX, PDF•
3 gostaram•1,970 visualizações
This document discusses networking in Docker containers. It begins by explaining how networking works without Docker, using interfaces, routes and iptables rules. It then explains how Docker sets up networking for containers using bridges, network namespaces and veth pairs. It describes the basic bridged networking and overlay networking models. It also introduces the Container Network Model (CNM) and Docker's libnetwork plugin system for extending networking functionality through external drivers.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Networking in Containers: Understanding Docker Network Models
Semelhante a Networking in Containers: Understanding Docker Network Models (20)
Último
Último (20)
Networking in Containers: Understanding Docker Network Models
- 1. Page1 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Networking in Containers Attila Kanto
- 2. Page2 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Agenda • How networking works in Docker • Container Network Model • Networking plugin
- 3. Page3 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Containers • Isolate and package applications • Resources (CPU, memory, IO) • Namespaces (pid, users, network, uts, mnt ) • Storage (device mapper, overlayfs, aufs, btrfs) • Security (capabilities)
- 4. Page4 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Network • UTS namespace • isolate hostname • Network namespace • network interface(s) • loopback device • routing table • iptable rules
- 5. Page5 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Basic networking overview 5
- 6. Page6 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Networking without Docker eth0 iptables route
- 7. Page7 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Networking without Docker ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.100 netmask 255.255.255.0 broadcast 192.168.1.255 ether 33:83:5a:44:50:ff txqueuelen 0 (Ethernet) lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0
- 8. Page8 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Networking without Docker ifconfig eth0: inet 192.168.1.100 ether 33:83:5a:44:50:ff OSI Layers (1 – 4)
- 9. Page9 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Networking without Docker route -n Destination Gateway Genmask Iface 0.0.0.0 192.168.1.1 0.0.0.0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 eth0 iptables -t nat -L target prot opt source destination
- 10. Page10 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Networking without Docker eth0 iptables route 192.168.1.0/24 -> eth0 0.0.0.0 -> 192.168.1.1 (eth0) 192.168.1.100
- 11. Page11 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Networking with Docker 11
- 12. Page12 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Install Docker eth0 iptables MASQUERADE 172.17.0.0/16 route 192.168.1.0/24 -> eth0 0.0.0.0 -> 192.168.1.1 (eth0) 172.17.0.0/16 -> docker0 192.168.1.100 172.17.0.1 docker0
- 13. Page13 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Run container / bridged networking • Docker0 bridge • already there, created during install • Network namespace • container netns needs to be created • Veth pair • created during the creation of container • connects two network namespaces • External communication • Only through Network Address Translation (NAT)
- 14. Page14 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Run container / bridged networking / 8080 -> 9090 eth0 iptables MASQUERADE 172.17.0.0/16 DNAT dpt:9090 to:172.17.0.2:8080 route 192.168.1.0/24 -> eth0 0.0.0.0 -> 192.168.1.1 (eth0) 172.17.0.0/16 -> docker0 192.168.1.100 172.17.0.1 docker0 container1ns eth0vxx veth 172.17.0.2 route SRC DST Client Port 9090 Client IP 192.168.1.100 Client MAC MAC of eth0 SRC DST Client Port 8080 Client IP 172.17.0.2 SRC DST Client Port 8080 Client IP 172.17.0.2 MAC of docker0 MAC of eth0
- 15. Page15 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Overlay networking with Docker 15
- 16. Page16 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Run container / overlay networking • Bridges • docker_gwbridge created if does not exist • br0 in a “hidden” namespace associated with the overlay network • Network namespace • container netns needs to be created • Veth pairs • connects br0 and and eth0 of container • connects docker_gwbridge and eth1 of container • External communication • Through Network Address Translation (NAT) • Through VXLAN (other container using the same overlay network)
- 17. Page17 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Install Docker (again) eth0 iptables MASQUERADE 172.17.0.0/16 route 192.168.1.0/24 -> eth0 0.0.0.0 -> 192.168.1.1 (eth0) 172.17.0.0/16 -> docker0 192.168.1.100 172.17.0.1 docker0
- 18. Page18 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Run container / overlay networking eth0 iptables route 192.168.1.100 172.18.0.1 docker_gw container1ns eth1vxx veth 172.18.0.2 172.17.0.1 docker0 ns br0 eth0vyy veth 10.10.10.210.10.10.1 VXLAN route
- 19. Page19 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Software-defined networking (SDN) • Separation control and data plane of network • Control plane • makes decisions about where traffic is sent • Data plane • forward traffic to the selected destination
- 20. Page20 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Data Plane (in Docker overlay) • Virtual Extensible LAN (VXLAN) • overlay technology • encapsulates L2 frames as UDP packets • VTEP – VXLAN Tunnel End Point • originator and/or terminator of VXLAN tunnel • VNI – VXLAN Network Identifier • part of the VXLAN Header • similar to VLAN ID
- 21. Page21 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Data Plane (in Docker overlay) • Container sends a packet • ARP (neighbor) table is checked for destination container IP -> MAC interface mapping • L2 FDB (forwarding database) is checked to determine IP of destination VTEP for destination MAC on source VTEP • packet is encapsulated for destination VTEP with configured VNI and sent to destination • destination VTEP de-capsulates the packet • inner packet is received by the destination container
- 22. Page22 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Network Control Plane (in Docker overlay)
- 23. Page23 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Container Network Model 23
- 24. Page24 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Container Network Model (CNM) • Sandbox • holds the config of a container's network stack (DNS, routing, etc.) • multiple endpoints from multiple networks • Linux Network Namespace / FreeBSD Jail • Network • Group Endpoints that are able to communicate with each-other directly • Linux Bridge / VXLAN • Endpoint • joins Sandbox to Network • veth pair / ovs patch port
- 25. Page25 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Docker libnetwork • Docker’s networking library • Implements CNM • Built-in drivers (in process) • Network drivers (bridge, overlay) • IPAM drivers • Plugin mechanism (off process) • External Network drivers (Calico, Midonet, my own driver) • External IPAM drivers
- 26. Page26 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Libnetwork plugins • Implemented using libnetwork’s remote driver • Running off-process (not in Docker daemon) • HTTP POSTs with JSON payload • KV store API not exposed • can be implemented in any programming language • KV store • KV url / credentials needs to be passed in init time • Can be deployed as container
- 27. Page27 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Network plugin API (Network) • CreateNetwork • DeleteNetwork
- 28. Page28 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Network plugin API (Endpoint) • CreateEndpoint • DeleteEndpoint
- 29. Page29 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Network plugin API (Join) • Join • Join (resp)
- 30. Page30 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Floating IP network driver • Containers on same L2 network • Connected with Open vSwitch • IP Address Management • libnetwork built-in IPAM driver is used • Externally addressable IP / container • no Network Address Translation • no port collision • extremely fast • scalability
- 31. Page31 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Run container / floating driver iptables route 192.168.1.100 container1ns 172.17.0.1 docker0 floating_bridge eth0 192.168.10.2 eth1 veth2veth1 container2ns eth0 192.168.10.3 veth veth eth0
- 32. Page32 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Demo 32
- 33. Page33 © Hortonworks Inc. 2011 – 2015. All Rights Reserved How to use it in Hadoop world • Using multiple networks • overlay to create internal network • floating for exposing servers Data Node Data Node Data Node Ambari Master Node Data Node Data Node Data Node Master Node Edge Node OverlayFloating
- 34. Page34 © Hortonworks Inc. 2011 – 2015. All Rights Reserved Takeaways • Since 1.9 Docker networking has improved • Easy to write a plugin that does certain things better • Multiple networks can be used by the same container • Not everybody is happy with it • Kubernetes http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html • Mesos https://issues.apache.org/jira/browse/MESOS-3828
- 35. Page35 © Hortonworks Inc. 2011 – 2015. All Rights Reserved We are hiring! 35
Notas do Editor
- Containers are application focused, and from high level they are isolate and package apllictaions - Containers can limit resources available for application, cpu share, memory Isolate processes, users, network, etc. this means that containers have processes, users, network stack that is not visible for other containers Filesystem is also separated, every container can have own root fs that is not visible Basic security, lik ecapabilities, e.g. NET_ADMIN This presentation focus is on network
- Linux kernel feature, (UNIX Timesharing System, historical reasons Own network stack, achived by using Network Namespace - It is a Linux kernel feature, - Network stack means that it has an own
- Linux machine and one erhernet port Routing table And iptable rules What are this: Routing table,, it is a prefix matching table, containing an IP prefixes, if you have a destination IP, matching against this table and from there it can be figured out where to send it out You can think of it as a packet filtering and modification tool. Iptables is a userland tool to modify the tables and rules netfilter module of kernel
- Layer 2 ethernet frame Layer 3 ip packet Oversimplification, layer 2 ethernat frame contains source and dest mac address Oversimplification, layer 3 ethernat packet contains source and dest ip address
- Routing table table is prefix table, describes that how a layer 3 packet shall be forvarded based on ip address.
- Add the information what we have learned
- A bridge behaves like a virtual network switch, any real devices (e.g. eth0) and virtual devices (e.g. tap0) can be connected to it. Iptables rule which is related to Network address translation (NAT) This info can be figured out by using the rout ifconfig, iptables Network address translation (NAT) is a methodology of remapping one IP address space into another by modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device.[1]
- Docker0 not to much thing is cahnged there Veth pair connection What happens when we run a container and expose the port 8080 to 9090 - Container would like to talk other container connected todocker0 then it goes through bridge
- Network address translation (NAT) is a methodology of remapping one IP address space into another by modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device.[1]
- An overlay network is a computer network that is built on top of another network. Not a good name in Docker networking, since they created a vxlan based overlay network.
- An overlay network is a computer network that is built on top of another network
- A bridge behaves like a virtual network switch, any real devices (e.g. eth0) and virtual devices (e.g. tap0) can be connected to it. Iptables rule which is related to Network address translation (NAT) This info can be figured out by using the rout ifconfig, iptables Network address translation (NAT) is a methodology of remapping one IP address space into another by modifying network address information in Internet Protocol (IP) datagram packet headers while they are in transit across a traffic routing device.[1]
- Suppose network was alreadt created with docker network create , 10.10.10.0/24 VXLAN, what role does it play? We need to step back a little bit. Ton understand this we need to explain what is SDN, Softer Defined Networking is
- Basic concept of Software-defined networking is to Separate control and data plane of network.
- Overtlay technology, whcih can be translated that a network teachnology om the top ofanother network Main parts of it.
- Few things what are missing from the puzzle
- Serf is decentralised solution, for cluster membership, faliure detection, orchestration. Use efficient and lightweight gossip/epidemic protocol is used to communicate with other nodes. Serf can detect node failures and notify the rest of the cluster propagating changes to configuration to relevant nodes.
- Undesrand what is the concept, now we can check the implementation details.