Container Standards & Interfaces: An Update

Transcript

1. Brandon Philips @brandonphilips | brandon.philips@coreos.com Container Standards & Interfaces An Update
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. Towards a Standard Journey to OCI
22. An image format A container runtime A log collection daemon An init system and process babysitter A container image build system
23. An image format
24. 17 Months Ago November 2014
25. Docker Image Format Circa 2014 - Very fluid format and evolution - Not content-addressable - No name delegation/discovery - Like MX records - No mechanism for signing
26. 16 Months Ago December 2014
27. App Container (appc) github.com/appc appc-dev@googlegroups.com
28. 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?
29. a modern, secure container runtime a simple, composable tool (CLI) an implementation of an open standard (appc)
30. shell scripts docker2aci acbuild goaci deb2aci
31. 12 Months Ago April 2015
32. 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
33. 10 Months Ago December 1st, 2014
34. Open Containers Initiative
35. • Runtime ◦ start/stop verbs ◦ filesystem layout OCI Runtime Spec
36. • Runtime ◦ start/stop verbs ◦ filesystem layout OCI Spec v0.4.0
37. Next Week April 2016
38. • 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
39. Where are we going? • Goal: standard container ◦ Runtime ◦ Image ◦ Identity & Signing ◦ Discovery & Naming ◦ Distribution • Goal: Enable Innovation ◦ Build systems ◦ Runtimes
40. Container Networking Connectivity and Beyond
41. Container Networking Interface Initially designed for rkt, used lots of places github.com/appc/cni
42. Connectivity for "pod" network model - IP per pod - Pods in the cluster can be addressed by their IP
43. How to network containers together? linux-bridge macvlan ipvlan Open vSwitch Weave Project Calico flannel GCE networking AWS VPC
44. How to allocate IP addresses? - From a fixed block on a host - DHCP - IPAM system backed by SQL database - SDN assigned: e.g. Weave
45. Container Runtime (e.g. k8s) veth macvlan ipvlan OVS Container Networking Interface (CNI)
46. 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
47. 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" } }
48. 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
49. 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
50. 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
51. 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
52. Container Networking Model CNM is implemented in github. com/docker/libnetwork
53. 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
54. CNM for Cluster and Local Networking
55. "Battery Included Plugins" - Bridge - "Default Docker Networking" - Overlay - VXLAN and coordinated internally using libkv - Remote - Everyone else uses this
56. 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
57. - Maintainers from Docker, and Tencent - Used by docker engine - External plugins from - Metaswitch networks, Weaveworks libnetwork Community
58. Container Networking Conclusions
59. 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
60. coreos.com/fest - @coreosfest May 9 & 10, 2016 - Berlin, Germany
61. Thank you! Brandon Philips @brandonphilips | brandon@coreos.com | coreos.com We’re hiring in all departments! Email: careers@coreos.com Positions: coreos.com/ careers