Containerd

Containerd overview and design.

Transcript

1. container Kunal Kushwaha (@kunalkushwaha) The universal container runtime
2. Container Runtime
3. Container Runtime Component that provides core primitives to manage containers on a host • Container execution and supervision • Image distribution • Network Interfaces and management • Local storage • Native plumbing level API
4. Isn’t that... what Docker does? Docker provides much more than that, it is a platform • User interface • Backward compatibility with existing applications • Clustering with Swarm mode • Opinionated workflows and defaults, such as Docker Hub • Commercial support • Product direction not entirely community led Some people do not want those things.
5. Result….
7. Container A simple and dumb container runtime
8. containerd • Started in November 2015 to control runc, the OCI runtime • Used by Docker since 1.11 in 2016 as a container runtime • Relaunched in December 2016 with new scope • Docker now using 0.2 branch • 1.0 master branch is where the new work is taking place Entirely new scope, and donated to CNCF
9. “containerd is designed to be embedded into a larger system, rather than being used directly by developers or end-users. containerd will serve as a core container runtime for the CNCF ecosystem.”
10. Containerd’s role in ecosystem
11. “containerd is an evolution, not a rewrite”
12. containerd: roadmap to 1.0 Timetable is aggressive for 1.0 in 2Q 2017, but the evolution helps • Some code is reused from Docker • Some is rewritten and improved based on experience • The runtime code is already in production with lots of users • Focus on getting APIs clear and clean • Extensible via plugins • Will be supported for one year • Can evolve in new directions for 2.0, ... • Limited scope...
13. What is not in Containerd... Limit the scope to where there is agreement, and not to constrain platforms. • No networking • No volumes • No logging • No build
14. Limit the scope to where there is agreement • No networking in containerd ◦ This is what the users of containerd wanted ◦ https://github.com/docker/containerd/issues/362 ◦ continue to use CNI or other APIs as before • No volume management in containerd ◦ Storage layer can be hooked in at OCI layer ◦ The Container Storage Interface (CSI) is a proposed new industry standard for cluster-wide volume plugins. ◦ Joint proposal from a group of people who work on Docker, Kubernetes, Mesosphere and Cloud Foundry. ◦ CSI is currently in the early draft stage, and seeking feedback from the community.” ◦ https://github.com/moby/moby/issues/31923
15. Limit the scope to where there is agreement • No log management in containerd (yet) ◦ Output streams of containers can be handled as required ◦ Platform can arrange logging how it wishes ◦ https://github.com/docker/containerd/issues/603 discusses changes ◦ Possibly adding timestamps, formatting in the shim • No build in containerd ◦ Use other tools for building containers ◦ Very different concerns from runtime
16. Ok what is in containerd then?
17. Containerd Services github.com/containerd/containerd/api/services • Content • Rootfs • Images • Execution • Shim Each of these are GRPC APIs
18. Design
19. Containerd Architecture
20. Docker Graph Driver
21. Docker Storage Architecture
22. Containerd Storage Architecture
23. containerd: Content Content is a content addressed store service Content { rpc Info(InfoRequest) returns (InfoResponse); rpc Delete(DeleteContentRequest) returns (google.protobuf.Empty); rpc Read(ReadRequest) returns (stream ReadResponse); rpc Status(StatusRequest) returns (stream StatusResponse); rpc Write(stream WriteRequest) returns (stream WriteResponse); } Content is identified via a digest, i.e. content hash. Status gives the status of an in progress write transaction. Content Digest
24. containerd: Rootfs service RootFS { rpc Unpack(UnpackRequest) returns (UnpackResponse); rpc Prepare(PrepareRequest) returns (MountResponse); rpc Mounts(MountsRequest) returns (MountResponse); } • Unpack a downloaded image • Prepare the root filesystem from the set of layers • Mounts returns a list of mounts to make, does not execute them
25. containerd layers • containerd has three built in ways of layering images: ◦ overlay ◦ btrfs ◦ vfs ❖ These correspond to overlay and snapshotting drivers, which are the two models. The aim is to make sure the API provides support for both types, not to be comprehensive. ❖ Also a plain driver that does not use layers. ❖ Plugins will provide additional mechanisms, eg ZFS
26. containerd: Data Flow Content Rootfs
27. containerd: Execution service ContainerService { rpc Create(CreateRequest) returns (CreateResponse); rpc Start(StartRequest) returns (google.protobuf.Empty); rpc Delete(DeleteRequest) returns (DeleteResponse); rpc Info(InfoRequest) returns (containerd.v1.types.Container); rpc List(ListRequest) returns (ListResponse); rpc Events(EventsRequest) returns (stream containerd.v1.types.Event); } Fairly simple API for container management.
28. containerd: Shim The shim is a process that handles IO for a container. service Shim { rpc Create(CreateRequest) returns (CreateResponse); rpc Start(StartRequest) returns (google.protobuf.Empty); rpc Delete(DeleteRequest) returns (DeleteResponse); rpc Exec(ExecRequest) returns (ExecResponse); rpc Pty(PtyRequest) returns (google.protobuf.Empty); rpc Events(EventsRequest) returns (stream containerd.v1.types.Event); rpc State(StateRequest) returns (StateResponse); rpc Pause(PauseRequest) returns (google.protobuf.Empty); rpc Resume(ResumeRequest) returns (google.protobuf.Empty); rpc Exit(ExitRequest) returns (google.protobuf.Empty); }
29. containerd: Command Line Interface The command line is not the API • There are some commands for testing e.g. ( dist rootfs, snapshot) ◦ However their CLIs are unstable and may be incomplete ◦ They can be useful for understanding what is going on, and writing tests ◦ Helpful in trying out low level operations, eg applying layers.
30. containerd: Command Line Interface • dist - everything for images • ctr - everything for containers • shim - directly interact with containers ( bypass containerd) Containerd end to end $ dist pull docker.io/library/redis:alpine $ ctr run --id redis -t docker.io/library/redis:alpine docker run
31. containerd • Easy to use • Simple design • Consistent GRPC interfaces • Clean design, fixes complexities from Docker • Smaller component with narrower focus • Easier to understand • Long term interface stability • Supports OCI • Portable Extensible via plugin • runtimes • snapshotters
32. Containerd and Kubernetes
33. containerd: View from Tim Hockin at Google
34. containerd and Kubernetes • Currently Docker is the default and best supported runtime • Containerd is being written to replace the relevant code in Docker • The CRI acts as an API for runtimes in Kubernetes • Work on integration in https://github.com/cri-containerd/kubernetes • Kubernetes PR https://github.com/kubernetes/kubernetes/pull/43655 • Containerd 1.0 milestone support in at least one runtime • Likely 1.0 will be shipped with at least Docker and Kubernetes support • Working with Kubernetes is an essential part of roadmap
35. Interested in contributing?
36. Get involved Project hosted on github • https://github.com/containerd/containerd Weekly development report : • https://github.com/containerd/containerd/tree/master/reports Follow on Twitter • @containerd Try in docker $ docker run --privileged -d dmcgowan/containerd Testsuite Integration | API’s Snapshot plugins
37. Thanks! Credits: - @justincormack https://www.slideshare.net/Docker/containerd-the-universal-container-runtime - https://blog.docker.com/2017/02/containerd-summit-recap-slides-videos-meeting-notes/ *Old containerd logo