Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
DaoliNet
Lightweight and Simple
Networking for Docker
DaoliCloud Company
www.daolicloud.com
November, 2015
2
Docker is Awesome!
• A Linux Container Engine
• Highly efficient CPU virtualization, an X86 server can be
partitioned (v...
Docker Networking Question
3
• Every Docker host is created
independently, therefore containers
in different Docker hosts ...
To Know or Not to Know Each Other?
OpenFlow: Know your Controller is Enough
4
OpenFlow: from Clean Slate
Program at Stanfo...
OpenFlow for Docker Networking
Keep it Simple!
5
Let Docker hosts not know each other, leave communications
open, and let ...
DaoliNet: An Openflow Approach
6
Ubiquitously distributed Open-V-Switch in
Docker hosts: They will ask the Controller
what...
Connection of Trans-Docker-Host Containers
7
How it Works
What Controller can see from packet-in:
• src-mac = ID of communication
initiator (C1)
• dst-ip = ID of commu...
9
Overlay Network No Packet Encapsulation
Overlay/underlay
packets L2/L3/L4
header data are
NAT translated
When a packet t...
User-mode Connection of Overlay Network
Lightweight and Simple to Manage
2. Real-time configures
two OVSes letting them
co...
Improved Cloud Security
• Physically distributed controllers are only deployed in intranet,
protected by firewalls
• SSL s...
Lightweight and Simple
• NAT flows will be deleted from the flow table upon overtime of an
inactive network session, to re...
OVS on Every Docker Server: Completely
Distributed Switches, Routers and Gateways
• OVS in distributed Docker hosts form: ...
To Know More About DaoliNet
14
Open Source: github.com/daolinet (work in progress)
Demo System: www.daolicloud.com
DaoliNet: Lightweight and Simple Networking for Docker
Upcoming SlideShare
Loading in …5
×

DaoliNet: Lightweight and Simple Networking for Docker

OpenFlow technology for lightweight and simple networking solution for connecting Docker containers.

  • Be the first to comment

  • Be the first to like this

DaoliNet: Lightweight and Simple Networking for Docker

  1. 1. DaoliNet Lightweight and Simple Networking for Docker DaoliCloud Company www.daolicloud.com November, 2015
  2. 2. 2 Docker is Awesome! • A Linux Container Engine • Highly efficient CPU virtualization, an X86 server can be partitioned (virtualized) into thousands of Linux containers! • Likely to become future cloud CPUs!
  3. 3. Docker Networking Question 3 • Every Docker host is created independently, therefore containers in different Docker hosts are not connected one another by default • There are several Docker networking offers, e.g., Weave, Flannel, Libnetwork, Colico, etc., all seemingly require Docker hosts to know containers in other hosts, e.g., require containers to have externally visible IP addresses Containers: To know or not to know each other? That is the question. Better NOT to know! Too complex to mind other people’s business!
  4. 4. To Know or Not to Know Each Other? OpenFlow: Know your Controller is Enough 4 OpenFlow: from Clean Slate Program at Stanford University, for Software Defined Network (SDN) In Standardization by Open Network Foundation (ONF) Separation of control and forwarding planes: • Forwarding devices do not know each other; • Let a knowing-all Controller tell forwarding devices what to do, in real time of communications Network forwarding devices: they do not know each other Knowing everything Controller
  5. 5. OpenFlow for Docker Networking Keep it Simple! 5 Let Docker hosts not know each other, leave communications open, and let a Controller tell Docker hosts how to forward packets when containers start to communicate
  6. 6. DaoliNet: An Openflow Approach 6 Ubiquitously distributed Open-V-Switch in Docker hosts: They will ask the Controller what to do upon containers start talk
  7. 7. Connection of Trans-Docker-Host Containers 7
  8. 8. How it Works What Controller can see from packet-in: • src-mac = ID of communication initiator (C1) • dst-ip = ID of communication responder (C2) These IDs suffice Controller to judge legitimacy of the connection request Controller can also see • src,dst ports (32-bits): src-port is random, Controller can make use it 8 Controller can packet-out a NAT-out flow to OVS in Server1, and a NAT-in flow in Server2: these two NATs are uniquely identified by src-port of C1 Hot-plug connection is lightweight, and very simple to manage!
  9. 9. 9 Overlay Network No Packet Encapsulation Overlay/underlay packets L2/L3/L4 header data are NAT translated When a packet travels between a container and its Docker host, src-ip, dst-ip are those of containers The packet is an overlay packet When a packet travels between two Docker hosts, src-ip, dst-ip are NAT translated to those of the servers The packet is NAT translated to underlay packet These NAT translations are uniquely identified by src-port of the communication initiator container, i.e., src-port of C1 (in slide 8) Controller uses src-port of C1 to uniquely identify: NAT-out flow for Server1 NAT-in flow for Server2
  10. 10. User-mode Connection of Overlay Network Lightweight and Simple to Manage 2. Real-time configures two OVSes letting them co-work = hot-plug 1. Openflow Controller sees connection request a, b: plug a, c: unplug b, c: plug a, b: plug a, c: unplug b, c: plug Controller only sees and handles the first packet as connection request The remainder packets are shortcut directly between OVS servers 10 OVS OVS
  11. 11. Improved Cloud Security • Physically distributed controllers are only deployed in intranet, protected by firewalls • SSL security protocol to protect (1) synchronization of network metadata, and (2) packet-in and packet-out flows (Openflow standard • Overlay nodes can talk one another only if the Controller packet-out flows, thus, ARP attack using a wrong MAC address won’t work, even for containers in one Docker host 11
  12. 12. Lightweight and Simple • NAT flows will be deleted from the flow table upon overtime of an inactive network session, to release host resource • OVS never memorizes MAC addresses of containers over other OVS, no need of ARP flood, switching is purely enabled by packet-out flow from Controller • Controller only needs to record very few network metadata: MACs and IPs of containers, MACs and IPs of Docker servers, and security group information of containers • No packet encapsulation, therefore no packet fragmentation 12 Overlay/underlay packets L2/L3/L4 header data are NAT translated
  13. 13. OVS on Every Docker Server: Completely Distributed Switches, Routers and Gateways • OVS in distributed Docker hosts form: vSwitch, vRouter, vGateway, vFirewall for Docker networking • Containers in different Docker hosts, if allowed to connect, connect in layer 2 • Containers within the same Docker host: if not allowed to connect, are isolated one another • Containers have usual intranet IP subnets: 10.0.0/8, 172.16.0/16, 192.168.0/24, OVS forming distributed vRouters forwarding between these subnets • If a Docker host has external IP addresses, then OVS in the host forms a vGateway, and vFirewall, for containers to communicate with outside world 13
  14. 14. To Know More About DaoliNet 14 Open Source: github.com/daolinet (work in progress) Demo System: www.daolicloud.com

×