Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Container Network Interface: Network Abstractio...

Container Network Interface: Network Abstraction for Containers

CNI simplifies the interface for container executors and cluster orchestrators to configure the array of networks required for today's environments. (Open Networking Summit '16, Santa Clara)

Josh Wood

March 17, 2016
Tweet

More Decks by Josh Wood

Other Decks in Technology

Transcript

  1. CoreOS is running the world’s containers We’re hiring: [email protected] [email protected]

    90+ Projects on GitHub, 1,000+ Contributors coreos.com Support plans, training and more OPEN SOURCE ENTERPRISE
  2. What’s the problem? SDN, NFV is great -- all of

    them: Container engines and images, likewise...
  3. How to allocate IP addresses? - From a fixed block

    on a host - DHCP - IPAM system backed by SQL database - SDN assigned: e.g. Weave, flannel - Provider policy and API
  4. How do you mix and match? (macvlan | ipvlan) +

    (DHCP | Calico policy | [...]) (AWS + premises) | (GCP + …)
  5. Order matters! - macvlan + DHCP ◦ Create macvlan device

    ◦ Use the device to DHCP ◦ Configure device with allocated IP - Routed + IPAM ◦ Ask IPAM for an IP ◦ Create veth and routes on host and/or fabric ◦ Configure device with allocated IP
  6. Container Network Interface (CNI) Part of the appc effort: •

    Open source • Open specification • Composable, tools philosophy • CNI == Kubernetes network plugin model
  7. CNI: A VFS for Container Networking - Abstraction layer for

    network configuration - Single API to multiple, extensible networks - Narrow, simple API - Plugins for third-party implementations
  8. Container Network Interface - Container can join multiple networks -

    Network described by JSON config - Plugin supports two commands - Add container to the network - Remove container from the network
  9. CNI Network Configuration $ cat /etc/cni/net.d/10-mynet.conf { "name": "mynet", "type":

    "bridge", "ipam": { "type": "host-local", "subnet": "10.10.0.0/16" } }
  10. CNI: Step 1 Container runtime creates network namespace and gives

    it a name: $ cd /var/lib/cni $ touch myns $ unshare -n mount --bind /proc/self/ns/net myns
  11. CNI: Step 2 Container runtime invokes the CNI plugin $

    export CNI_COMMAND=ADD $ export CNI_NETNS=/var/lib/cni/myns $ export CNI_CONTAINERID=5248e9f8-3c91-11e5-... $ export CNI_IFNAME=eth0 $ $CNI_PATH/bridge </etc/cni/net.d/10-mynet.conf
  12. CNI: Step 3 Inside the bridge plugin (1): $ brctl

    addbr mynet $ ip link add veth123 type veth peer name $CNI_IFNAME $ brctl addif mynet veth123 $ ip link set $CNI_IFNAME netns $CNI_IFNAME $ ip link set veth123 up
  13. CNI: Step 3 Inside the bridge plugin (2): $ IPAM_PLUGIN=host-local

    # from network conf $ echo $IPAM_PLUGIN { "ip4": { "ip": "10.10.5.9/16", "gateway": "10.10.0.1" } }
  14. CNI: Step 3 Inside the bridge plugin (3): # switch

    to container namespace $ ip addr add 10.0.5.9/16 dev $CNI_IFNAME # Finally, print IPAM result JSON to stdout
  15. rkt A modern, secure container runtime Simple CLI tool -

    exorcism (no daemon) Composable with systemd, standard init systems
  16. rkt • Implements appc spec • Implements CNI • Cryptographic

    image validation, detached signatures • Logs to tamper-evident TPM facility on DTC systems
  17. rkt run • Isolates containers with the linux container primitives

    (cgroups, ns), systemd-nspawn • Container apps in a machine slice PID namespace • Manage with standard init tools: systemd
  18. $ rkt run --net=host quay.io/josh_wood/caddy rkt: using image from local

    store for image name coreos.com/rkt/stage1-coreos:0.15.0 rkt: using image from local store for image name quay.io/josh_wood/caddy [ 1161.330635] caddy[4]: Activating privacy features... done. [ 1161.333482] caddy[4]: :2015 $ rkt run
  19. Kubernetes + CNI + Docker - k8s starts "pause" container

    to create netns - k8s invokes CNI driver - CNI executes a CNI plugin - CNI plugin joins "pause" container to network - Pod containers use "pause" container netns
  20. Kubernetes + rkt - rkt natively supports CNI - Kubernetes

    delegates to rkt to invoke CNI plugins
  21. Kubernetes + rkt - rkt natively supports CNI - Kubernetes

    delegates to rkt to invoke CNI plugins - Example: Emulating Docker-style NAT
  22. CNI Network Configuration $ cat /etc/cni/net.d/10-br-host-local-nat.conf { "name": "br-host-local-nat", "type":

    "bridge", "bridge": "rkt-br-hl-nat", "ipMasq": true, "isGateway": true, "ipam": { "type": "host-local", "subnet": "10.0.0.0/24", "routes": [ { "dst": "0.0.0.0/0" } ]
  23. CNI: Step 2 Container runtime invokes the CNI plugin $

    export CNI_COMMAND=ADD $ export CNI_NETNS=/var/lib/cni/br-host-local-nat $ export CNI_CONTAINERID=5248e9f8-3c91-11e5-... $ export CNI_IFNAME=eth0 $ $CNI_PATH/bridge </etc/cni/net.d/10-br-host-local- nat.conf
  24. rkt and Kubernetes on CoreOS • rkt fly executes kubelet:

    packaging and distribution of containers, ns at host level • rkt is container execution engine, runs cluster work • Pod :: Pod • CNI networking: Native • Write plugins!
  25. See also: • coreos.com/rkt • github.com/appc/cni • blog.kubernetes.io/2016/01/why-Kubernetes- doesnt-use-libnetwork.html •

    https://docs.google. com/presentation/d/1aFraZcWg5kXKTpuWwDs m4XBM__BVcP70P0X1sNGUTi0/edit? usp=sharing