Container Standards & Interfaces: An Update

Transcript

1. Brandon Philips @brandonphilips | brandon.philips@coreos.com Container Standards & Interfaces An

   Update
2. None

3. Build, Store and Distribute your Containers quay.io

4. None

5. Container Image Format Specification Requirements

6. The "*app*" perspective is how the app processes inside the

   pod see the environment. This example pod will use a set of three apps: | Name | Version | Image hash |------------------------------------|---------|--------------------------------------------- | example.com/reduce-worker | 1.0.0 | sha512-277205b3ae3eb3a8e042a62ae46934b470e43 | example.com/worker-backup | 1.0.0 | sha512-3e86b59982e49066c5d813af1c2e2579cbf57 | example.com/reduce-worker-register | 1.0.0 | sha512-86298e1fdb95ec9a45b5935504e26ec29b8fe #### Filesystem Setup Each app in a pod will start chrooted into its own unique read-write filesystem before execut An app's filesystem must be *rendered* in an empty directory by the following process (or equ - The `rootfs` contained in the ACI is extracted - If the ACI contains a non-empty `dependencies` field in its `ImageManifest`, the `rootfs` o is extracted, in the order in which they are listed - If the ACI contains a non-empty `pathWhitelist` field in its `ImageManifest`, *all* paths n must be removed Every execution of an app MUST start from a clean copy of this rendered filesystem. The simplest implementation will take an ACI (with no dependencies) and extract it into a new

7. What we want? Image Format Storytime!

8. you

9. you as a sw engineer

10. your with Ada.Text_IO; procedure Hello_World is use Ada.Text_IO; begin Put_Line("Hello,

    world!"); end; #include <stdio.h> int main() { printf("Hello, world!\n"); } package main import "fmt" func main() { fmt.Println("Hello, world!") }

11. your container image

12. your /bin/java /opt/app.jar /lib/libc

13. your /bin/python /opt/app.py /lib/libc

14. your example.com/app d474e8c57737625c

15. your d474e8c57737625c Signed By: Alice

16. you as an ops engineer

17. your

18. your example.com/app x3

19. your example.com/app x3

20. your ??? example.com/app x3

21. None

22. Towards a Standard Journey to OCI

23. An image format A container runtime A log collection daemon

    An init system and process babysitter A container image build system

24. An image format

25. 17 Months Ago November 2014

26. Docker Image Format Circa 2014 - Very fluid format and

    evolution - Not content-addressable - No name delegation/discovery - Like MX records - No mechanism for signing

27. 16 Months Ago December 2014

28. App Container (appc) github.com/appc appc-dev@googlegroups.com

29. appc image in a nutshell • Image Format (ACI) ◦

    what does an application consist of? • Image Discovery ◦ how can an image be located? • Content-addressing ◦ what is the cryptographic id of an image? • Signing ◦ how is an image signed?

30. a modern, secure container runtime a simple, composable tool (CLI)

    an implementation of an open standard (appc)

31. shell scripts docker2aci acbuild goaci deb2aci

32. 12 Months Ago April 2015

33. Docker v2.2 Image Format Circa 2014 - Versioned v2.0, v2.1,

    v2.2 schema - Content-addressable - No name delegation/discovery - Like MX records - Optional and non-prescribed signing

34. 10 Months Ago December 1st, 2014

35. Open Containers Initiative

36. • Runtime ◦ start/stop verbs ◦ filesystem layout OCI Runtime

    Spec

37. • Runtime ◦ start/stop verbs ◦ filesystem layout OCI Spec

    v0.4.0

38. Last Week April 2016 (blog post)

39. • A serialized image format • Content-addressable Optional stuff ◦

    Signatures that are based on signing image content address ◦ Naming that is federated based on DNS and can be delegated OCI Image Format Spec Project

40. Where are we going? • Goal: standard container ◦ Runtime

    ◦ Image ◦ Identity & Signing ◦ Discovery & Naming ◦ Distribution • Goal: Enable Innovation ◦ Build systems ◦ Runtimes

41. Container Networking Connectivity and Beyond

42. Container Networking Interface Initially designed for rkt, used lots of

    places github.com/appc/cni

43. Connectivity for "pod" network model - IP per pod -

    Pods in the cluster can be addressed by their IP

44. How to network containers together? linux-bridge macvlan ipvlan Open vSwitch

    Weave Project Calico flannel GCE networking AWS VPC

45. How to allocate IP addresses? - From a fixed block

    on a host - DHCP - IPAM system backed by SQL database - SDN assigned: e.g. Weave

46. Container Runtime (e.g. k8s) veth macvlan ipvlan OVS Container Networking

    Interface (CNI)

47. CNI - Container can join multiple networks - Network described

    by JSON config - Plugin supports two commands - Add container to the network - Remove container from the network

48. User configures a network $ cat /etc/cni/net.d/10-mynet.conf { "name": "mynet",

    "type": "bridge", "ipam": { "type": "host-local", "subnet": "10.10.0.0/16" } }

49. CNI: Step 1 Container runtime creates network namespace and gives

    it a named handle $ cd /var/lib/cni $ touch myns $ unshare -n mount --bind /proc/self/ns/net myns

50. 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

51. CNI Flexibility - Plugins manage their own state - Essential

    for network vendors who often have complex control planes - Process model exposes full Linux network stack - External plugins implement the API and get out of the way - Metaswitch networks, Weaveworks

52. CNI Community - Maintainers from CoreOS, Pivotal, and Weaveworks -

    Used by rkt, Kubernetes, Cloud Foundry, kurma, and usable with runC - External plugins from - Metaswitch networks, Weaveworks - Discussions around CNCF project

53. Container Networking Model CNM is implemented in github. com/docker/libnetwork

54. Defining a new network model - Network - A logical

    network (think vlan) - Endpoint - Connects a sandbox to a network - Sandbox - A container level network configuration for DNS, routes, etc

55. CNM for Cluster and Local Networking

56. "Battery Included Plugins" - Bridge - "Default Docker Networking" -

    Overlay - VXLAN and coordinated internally using libkv - Remote - Everyone else uses this

57. Remote Plugins - Operate a long running plugin API service

    - Linux networking features restricted to API - External plugins - Difficult to integrate because of API model - Existing control planes don't get useful metadata

58. - Maintainers from Docker, and Tencent - Used by docker

    engine - External plugins from - Metaswitch networks, Weaveworks libnetwork Community

59. Container Networking Conclusions

60. CNM creates a new interface to the network world -

    Hard to integrate into existing systems like Kubernetes - Exposes networking concepts through new API/model - Adopted by Docker Engine CNI is a simple model for container networking - Simple to integrate with process based workflow - Exposes full Linux network stack - Adopted by rkt, kurma, Kubernetes, Cloud Foundry, and easy integration with runC

61. coreos.com/fest - @coreosfest May 9 & 10, 2016 - Berlin,

    Germany

62. Thank you! Brandon Philips @brandonphilips | brandon@coreos.com | coreos.com We’re

    hiring in all departments! Email: careers@coreos.com Positions: coreos.com/ careers