Michael Crosby
Author Archives: Michael Crosby
- Home → Author's archive:
Michael Crosby
containerd Graduates Within the CNCF
We are happy to announce that as of today, containerd, an industry-standard runtime for building container solutions, graduates within the CNCF. The successful graduation demonstrates containerd has achieved the maturity, stability and community acceptance required for broad ecosystem adoption. containerd has already been deployed in tens of millions of production systems today, making it the most widely adopted runtime and an essential upstream component of the Docker platform. containerd was donated to the CNCF as a top-level project because of its strong alignment with Kubernetes, gRPC and Prometheus and is the fifth project to make it to this tier. Built to address the needs of modern container platforms like Docker Enterprise and orchestration systems like Kubernetes, containerd ensures users have a consistent dev to ops experience.
From Docker’s initial announcement that it was spinning out its core runtime to its donation to the CNCF in March 2017, the containerd project has experienced significant growth and progress over the last two years. The primary goal of Docker’s donation was to foster further innovation in the container ecosystem by providing a core container runtime that could be leveraged by container system vendors and orchestration projects such as Kubernetes, Swarm, Continue reading
Interview with Michael Crosby, the OCI Technical Oversight Board Chairman
Last month the Linux Foundation announced the 2018 Open Container Initiative (OCI) election results of the Technical Oversight Board (TOB). Members of the TOB then voted to elect our very own Michael Crosby as the new Chairman. The result of the election should not come as a surprise to anyone in the community given Michael’s extensive contributions to the container ecosystem.
Back in February 2014, Michael led the development of libcontainer, a Go library that was developed to access the kernel’s container APIs directly, without any other dependencies. If you look at this first commit of libcontainer, you’ll see that the JSONspec is very similar to the latest version of the 1.0 runtime specification.
In the interview below, we take a closer look at Michael’s contributions to OCI, his vision for the future and how this benefits all Docker users.
Why are you excited about your new role as chairman of OCI’s TOB ?
I think that it is important to be part of the TOB to ensure that the specifications that have been created are generally useful and not specific to any one use case. I also feel it is important to ensure that the specifications are stable so that Continue reading
A tour of containerd 1.0
We have done a few talks in the past on different features of containerd, how it was designed, and some of the problems that we have fixed along the way. Containerd is used by Docker, Kubernetes CRI, and a few other projects but this is a post for people who may not know what containerd actually does within these platforms. I would like to do more posts on the feature set and design of containerd in the future but for now, we will start with the basics.
I think the container ecosystem can be confusing at times. Especially with the terminology that we use. Whats this? A runtime. And this? A runtime… containerd (pronounced “container-dee”) as the name implies, not contain nerd as some would like to troll me with, is a container daemon. It was originally built as an integration point for OCI runtimes like runc but over the past six months it has added a lot of functionality to bring it up to par with the needs of modern container platforms like Docker and orchestration systems like Kubernetes.
So what do you actually get using containerd? You get push and pull functionality as well as image Continue reading
Kubernetes 1.8 release integrates with containerd 1.0 Beta
Intent of containerd effort
When containerd was first developed it had two goals. The first was to solve the upgrade problem with running containers and provide a codebase where OCI runtimes, like runc, could be integrated into Docker. However, as needs change in the container space and after speaking with various members of the community at the beginning of this year, we decided to expand the scope of containerd and make it a fully functional container daemon with storage, image distribution and runtime.
containerd fully supports the OCI Runtime and Image specifications that are part of the recently released 1.0 specifications. Additionally, it was important to build a stable runtime for users and platform builders. We wanted containerd to be fully functional; but also, it needed to retain a small core codebase so that it is easy to maintain and support in the long run with an LTS release receiving backported patches on a stable API.
To demonstrate the progress made on the project, Stephen Day presented the current status of containerd 1.0 alpha at the Moby Summit in LA two weeks ago,:
Check out the getting started with containerd guide to get your feet wet with containerd if you want to integrate Continue reading
What is containerd ?
We have done a few talks in the past on different features of containerd, how it was designed, and some of the problems that we have fixed along the way. Containerd is used by Docker, Kubernetes CRI, and a few other projects but this is a post for people who may not know what containerd actually does within these platforms. I would like to do more posts on the featureset and design of containerd in the future but for now, we will start with the basics.
I think the container ecosystem can be confusing at times. Especially with the terminology that we use. Whats this? A runtime. And this? A runtime… containerd as the name implies, not contain nerd as some would like to troll me with, is a container daemon. It was originally built as an integration point for OCI runtimes like runc but over the past six months it has added a lot of functionality to bring it up to par with the needs of modern container platforms like Docker and Kubernetes.
Since there is no such thing as Linux containers in the kernelspace, containers are various kernel features tied together, when you are building a large Continue reading
containerd summit recap: slides, videos and meeting notes
Last week, we hosted a containerd summit for contributors and maintainers. Containerd is a core container runtime with an emphasis on simplicity, robustness and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, snapshot storage for container filesystems and a few other things to make the management of containers robust.
We started off by getting everyone up to speed on the project, roadmap and goals before diving down into specific issues and design of containerd. We had a couple breakout sessions where we discussed blocking issues and feature requests by various members of the community. You can see a summary of the breakout sessions in last week’s development report in the containerd repository and the various presentations below:
Deep Dive into containerd by Michael Crosby, Stephen Day, Derek McGowan and Mickael Laventure (Docker)
Driving containerd operations with gRPC by Phil Estes (IBM)
containerd and CRI by Tim Hockin (Google)
We ended the day with discussions around governance and extension model. Watch this video recording to learn more about why and how core contributors are thinking about integrating containerd with other Continue reading
CPU Management in Docker 1.13
Resource management for containers is a huge requirement for production users. Being able to run multiple containers on a single host and ensure that one container does not starve the others in terms of cpu, memory, io, or networking in an efficient way is why I like working with containers. However, cpu management for containers is still not as straightforward as what I would like. There are many different options when it comes to dealing with restricting the cpu usage for a container. With things like memory, its is very easy for people to think that , --memory 512m gives the container up to 512mb. With CPU, it’s hard for people to understand a container’s limit with the current options.
In Docker 1.13 we added a --cpus flag, which is the best tech for limiting cpu usage of a container with a sane UX that the majority of users can understand. Let’s take a look at a couple of the options in 1.12 to show why this is necessary.
There are various ways to set a cpu limit for a container. Cpu shares, cpuset, cfs quota and period are the three most common ways. We can just go Continue reading