Container Standards & Interfaces: An Update

Transcript

1. Brandon Philips @brandonphilips | brandon.philips@coreos.com Container Standards & Interfaces An Update
3. Build, Store and Distribute your Containers quay.io
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
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