Container Networking and Openstack. Fernando Sanchez Fawad Khaliq March, 2016

Transcription

1 Container Networking and Openstack Fernando Sanchez Fawad Khaliq March, 2016

2 Agenda Containers, Orchestration and Networking Containers: runtimes Container Orchestration tools Container Networking models Early (host, bridge, container modes) Modern (CNM, CNI) Containers and Openstack Magnum Kuryr PLUMgrid's involvement in the container ecosystem

3 Containers, Orchestration and Networking

4 Containers: runtimes LXC - Linux standard Docker - Docker Rocket - CoreOS Drawbridge Microsoft LXD - Canonical (uses LXC) And also an open container project: runc

5 Containers: Orchestration Swarm (plus Docker Datacenter) - Docker Kubernetes - Google Mesos - Berkeley, Airbnb, Twitter, Apple. Mesosphere Fleet, Tectonic - CoreOS Rancher Rancher Labs others

6 Container Networking strategies Early: Bridge mode Host mode Container mode Evolution: Container Networking Model (CNM) Container Networking Interface (CNI)

7 Container networking(i) Bridge-mode Networking A private docker0 bridge is provisioned on the host A private namespace for each container is provisioned inside that bridge Containers ethx are mapped to private bridge interfaces NAT (w/iptables) is used to map between each private container and the host s public interface

8 Container networking(i) Bridge-mode Networking Each container needs a port mapped from eth0 into their private interface IPtables keeps a NAT session in the conntrack per each container mapping public/ private Different ports required on public per container Default mode of operation Use of NAT à Performance? Scalability? Operations? Orchestration?

9 Container networking (II) Host-mode Networking Docker reuses the networking namespace of the main host (it s virtually the same interface for the host and the container) The only way to share the interface is to use different ports per container. Recommended for production in Docker Faster but secure?

10 Container networking (III) Container-mode Networking Docker reuses the networking namespace of another container. Typically, create a container with bridge mode then create a set of containers sharing the interface with the first container The only way to share the interface is to use different ports per container. Kubernetes used work like this, where a set of containers sharing the bridge is a POD Recently moved to CNI (see later) On the way out? Nginx container 1 Nginx container 2 vethxxx vethxxx LO eth0 LO eth0 docker : :49155 iptables eth0 Docker host :80

11 libnetwork Docker s interface between the docker daemon and the network Docker libnetwork Native drivers (Null, Bridge, Overlay) Remote drivers (Weave, PLUMgrid, Kuryr, etc.)

12 Container networking (IV) CNM : Container Networking Model (Docker) Network Sandbox = Isolated environment for the container s network config. (similar to a network namespace ) Endpoint = Interface Network = Group of endpoints Copyright PLUMgrid, Inc.

13 Docker network CLI docker network create connect disconnect network inspect ls rm Create a network Connect container to a network Disconnect container from a Display network information List all networks Remove a network

14 Docker: create a network $ docker network create \ driver overlay \ subnet= /24 \ test-net

15 Docker: list networks $ docker network ls NETWORK ID NAME DRIVER a0ee12ceb7ed test-net overlay

16 Docker: connect a network $ docker network connect \ test-net test-cont $ docker run \ itd name=test-cont \ net=test-net test-image

17 Docker: disconnect a network $ docker network disconnect \ test-net test-cont

18 Docker: delete a network $ docker network delete test-net

19 Container networking modes (IV) CNI : Container Networking Interface (CoreOS, Kubernetes) Treats container / pod of containers synonymous to Linux network namespaces Networks described on JSON based format for network and IPAM config in /etc/ cni/net.d { "name": test-net", "type": bridge", COMMERCIAL "bridge": "cni0", "isgateway": true, "ipmasq": true, "ipam": { } } "type": "host-local", "subnet": " /16", "routes": [ { "dst": " /0" } ] #type of network/plugin bridge,macvlan,ipvlan, #can be used for pluggable ipams Plugin supports two commands: add/remove container to/from network Kubernetes has already adopted CNI and code went in for initial draft recently.

20 Containers and container networking in OpenStack Magnum: provides orchestration using Swarm, Mesos and Kubernetes Kuryr: provides networking for containers using Neutron as a backend.

21 Magnum: Container-as-a-service Provides container orchestration from an Openstack API, abstracting the underlying Container Orchestration Engines (Swarm, Kubernetes, Mesos). Uses Heat, Nova, Neutron, user-data, cloud-init. Uses Nova instances on Neutron networks to launch container orchestration engines (COEs) Containers are launched inside Nova instances. Support for bare metal container is not there yet. Use non-neutron networking options for container right now.

22 Kuryr: Networking for containers with OpenStack Works as a proxy for libnetwork to provide networking for Docker using Neutron as a backend. Plans to support both CNM and CNI. Kubernetes integration in discussion Is not integrated with Magnum yet. Kuryr is currently a remote driver for libnetwork.

23 Kuryr: Networking for containers with OpenStack Copyright PLUMgrid, Inc.

24 PLUMgrid s involvement in the container ecosystem

25 PLUMgrid libnetwork plugin Remote driver for libnetwork Available at: Uses PLUMgrid s Open Networking suite

26 PLUMgrid libnetwork plugin Copyright PLUMgrid, Inc.

27 PLUMgrid libnetwork plugin $ docker network create

28 PLUMgrid libnetwork plugin $ docker network connect

29 PLUMgrid libnetwork plugin $ docker network connect

30 Demo of PLUMgrid libnetwork plugin and integration with Swarm

31 Kuryr, Magnum, Neutron Integration: Nested container PLUMgrid is an active member of the Kuryr development community. Working on the nested container networking design in the OpenStack community. This will bring Neutron networking to Magnum containers. Design specification can be found here

32 What s the nested container problem? c1 c2 c1 c2 VM1 VM2 cnt-network1 cnt-network2 vm-network1 vm-network2 router1

33 References kubelet/network/cni mbox/%3CJIRA. an.jira%3e %E2%9C%93&q=cni