container Kunal Kushwaha (@kunalkushwaha) The universal container runtime 

Container Runtime 

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 

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. 

Result…. 

No content

Container A simple and dumb container runtime 

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 

“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.” 

Containerd’s role in ecosystem 

“containerd is an evolution, not a rewrite” 

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

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 

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 

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 

Ok what is in containerd then? 

Containerd Services github.com/containerd/containerd/api/services ● Content ● Rootfs ● Images ● Execution ● Shim Each of these are GRPC APIs 

Design 

Containerd Architecture 

Docker Graph Driver 

Docker Storage Architecture 

Containerd Storage Architecture 

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 

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 

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 

containerd: Data Flow Content Rootfs 

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. 

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); } 

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. 

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 

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 

Containerd and Kubernetes 

containerd: View from Tim Hockin at Google 

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 

Interested in contributing? 

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 

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