►
Description
Containerd: The Universal Container Runtime [I] - Justin Cormack, Docker
Containerd is a new community project designed to provide a common runtime for every project that uses containers: Kubernetes, Docker, Amazon ECS, Azure Container Engine and many more, with contributors coming from Docker, Google, Red Hat, Microsoft, Amazon, IBM, Alibaba and many more companies in the container space. It extends the collaboration on standards around the Open Container Initiative by implementing these standards, and is run by an independent foundation. This project will be a central point of collaboration between the diverse container community and an integration point for vendors, much like the Linux kernel project is.
Although containerd was designed to be a "boring infrastructure" component that just sits there and works for a huge range of use cases, it is a pretty exciting development for those of us involved in containers. This talk covers the state of the project now, the roadmap, how it fits into broader tools such as Docker and Kubernetes, how it will affect users, and the future roadmap. It is an open project which is seeking a wide range of input, so the talk covers how to get involved and contribute.
About Justin Cormack
Justin Cormack is an engineer at Docker and a maintainer of the Docker engine.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
My
name
is
Justin
Cormac
I
work
at
docker
and
I'm
here
to
talk
about
container
D,
the
newest
CN
CF
project.
Well,
one
of
the
two
newest
ciencia
projects
we're
incredibly
excited
about
joining
the
CN
CF.
When,
when
I
submitted
this
talk,
it
was,
it
was
still
a
hope
and
possibility,
rather
than
the
reality.
It
is
today,
which
is
really
great,
and
we're
really
excited
to
be
working
in
this
community,
and
this
is
a
you
know.
A
A
A
A
It's
the
infrastructure
that
does
the
kind
of
low-level
bits
of
managing
container
execution,
making
sure
your
containers
continue
running
connecting
to
them,
letting
you
pull
images
that
you
want
to
run
and
giving
you
plumbing,
and
so
it's
kind
of
that
group
of
things
that
just
locally
runs
containers.
It's
not
a
distributed
component.
It's
a
single
host
component.
A
It
does
clustering,
it's
a
it's
a
commercial
product,
so
it's
not
container
D
is
really
just
the
component
that
you
need
to
do
the
low-level
bits
without
any
without
any
of
that
without
a
user
interface.
Really
we'll
we'll
talk
about
the
RPC
a
bit
more
without
clustering
without
any
of
those
things.
So
it's
a
it's
a
tool
for
building
and
bigger
systems
like
darker,
like
kubernetes,
in
terms
of
the
the
ecosystem.
A
The
aim
is
that
it
continually
should
be
used
by
everyone
on
every
system
on
Windows
on
Linux,
and
it
should
support
every
high
level
container
platform
that
sits
above
that
Cloud
Foundry,
kubernetes,
stockist,
warm
and
AWS,
and
and
a
container
services
and
so
on,
and
so
and
the
Microsoft
container
services
and
so
on.
So
it's
a
component
for
people
are
building
platforms
like
kubernetes
and
people
who
are
building
platforms
like
AWS
and
people
who
are
building
platforms
like
ibm's
bluemix.
A
The
requirement
for
our
1.0
is
that
it
supports
at
least
one
runtime
in
practice.
That
means
it
supports
at
least
doctrine
kubernetes
and
it's
basically
working
ideally
shipped,
and
so
that
integration
work
is
incredibly
important
and
the
people
the
people
working
on
it
I'd
made
something
yesterday
and
it's
really
really
cool
work
and
it's
really
important.
Where
I
can
it's
really
valuable
work
for
us
and
you
know
I'm
it's
it's
really
important
that
we
integrate
into
the
communities
community
and
and
provide
what
kubernetes
needs
and
Tim
Hakan
was
at
the
container
d
summit.
A
That
was
about
a
month
ago,
and
this
was
one
of
his
slides
where
he
said,
explain
why
it
matters
and
why
containers
is
important
for
kubernetes.
It
provides
just
what
kubernetes
needs
without
all
the
other
bits
of
the
docker
platform
that
are
basically
useless
for
communities,
because
goodness
has
its
own
view.
On
that
it's
designed
to
be
embedded.
It's
not
designed
to
be
a
standalone
system,
it
doesn't
have
type
dependencies.
A
So
it
really
helps
that
we
did.
There
was
a
previous
not
point
to
branch,
so
we
could
take
some
so
bits
of
it.
Working
in
particular
the
the
runtime
code
was
already
working,
because
that
was
the
bit
that
was
already
being
used
by
Daka.
So
we
have
something
it
wasn't
from
nothing
the
image
code,
the
image
handling
code,
is
pretty
much
all
new.
A
So
there's
been
a
lot
of
work
on
that
and
it's
coming
along
really
well,
so
that
evolution
is
definitely
helping
us,
but
it's
a
super
aggressive
deadline
and
we
need
the
community
to
help
ship
that,
but
it's
you
know,
and
we
need
people
to
you
know
start
integrating
it
into
Cuban.
It
is
now
which
is
happening,
which
is
great,
so
it
would
be
a
kind
of
it'll,
be
streamlined
and
small
and
focused
to
get
to
one
point
a
that
quickly
with
extensions
fire
plugins
rather
than
jamming
of
loads
of
code
into
the
repo.
A
We
hope
we're
hoping
to
use
the
new
go
plug-in
infrastructure.
Maybe
that
won't
work
but
it'll
still
be
pluggable
and
build
a
bore
but
inextensible
once
we
ship,
1.0
it'll,
be
supported
for
a
year
as
a
stable
product
that
people
can
use
in
their
platform
without
worrying,
about
API,
breakage
or
anything,
and
then
it
can
move
on
to
2.0,
which
can
do
very
different.
Things
doesn't
have
to
be
so.
We
don't
have
to
have
such
an
aggressive
timetable
for
shipping.
A
It
will
it'll
be
there
and
running
with
have
learnings
from
experience,
and
we
can
say
we're
want
to
change.
Api
is
or
change
architecture
and
so
there'll
be
hell,
obscenities
for
exciting
new
directions
for
their
project
to
take
and
evolve
it
in
new
ways,
and
the
community
can
lead
that
wherever
it
wherever
people
want
for
their
runtimes
and
based
on
the
experience
of
using
it
in
production.
So
limiting
scope
is
important
in
order
to
get
this
thing
out
so
and
make
it
not
a
giant
project.
A
That's
unapproachable,
so
we
left
a
load
of
stuff
out
I'll
talk
about
these
things
in
a
minute,
but
there's
no
networking,
no
volumes,
no
logging
and
they
build
at
the
moment,
which
is
all
kind
of
a
lot
of
the
stuff
that
people
kind
of
expect.
So
I'll
talk
about
a
lot
a
bit
about
why
this
isn't
the
networking.
A
What
should
we
do
about
networking
and
there
was
a
good
discussion
and
the
answer
was:
let's
not
do
anything
about
networking
it
in
container
D,
let's
not
be
opinionated,
let's
basically
provide
some
methods,
so
you
can
join
a
network
existing
network
namespace.
You
can
use
a
CI
hooks,
which
is
how
run
C's
worked
or
but
probably
the
cleanest
model.
A
Container
D
has
this
nice
separation
between
creating
a
container
and
running
a
container
there,
not
one
operation.
So
between
those
two
things
you
can
set
up.
Networking
enter
the
name
and
the
network
namespace
of
the
process
and
do
what
you
want
so
there's
kind
of,
but
any
of
these
methods,
work
and
they've,
been
used
by
other
project
kind
of
everyone
seems
really
happy
that
they
don't
have
to.
A
They
can
just
do
what
they
want
with
networking,
keep
networking
how
it
works
now
in
their
platform
and
contained
he's
not
going
to
get
in
the
way
volume
management
pretty
much
the
same
thing,
any
there's,
even
less
standardization
I
just
wanted
to
point
out
that
there
is
now
a
new
storage
interface.
Standardization
proposal,
that's
in
kind
of
early
days,
and
if
you
want
to
get
involved
because
you
care
about
storage,
do
look
it
up,
but
again
container
D
doesn't
really
care.
A
A
A
There
are
different,
but
there
are
different
use
cases
that
have
to
be
allowed
for
so
it
has
to
not
get
in
the
way
of
people
who
are
using
container
outputs
as
binary
streams
which
dockets
it
does.
Sometimes,
if
you
using
docker,
is
their
unix
pipeline
or
something
like
that.
So
not
everything
is
log
structured,
it's
kind
of
so
there's
there's
nothing.
It
doesn't
do
much
yet
with
logging,
but
there's
still
an
open
issue
and
if
you're
interested
in
that,
please
participate
and
contribute
code
and
and
think
about
it
and
look
at
the
issue.
A
A
The
assumption
right
now
with
container
D,
is
you
build
your
images
in
some
other
system
like
docker
or
any
other
set
of
tooling
you
like,
and
then
you
run
them
in
container
D
will
run
them.
It
has
the
internals
to
handle
some
sort
of
build
tool,
but
it
doesn't
have
any
opinion
about
what
a
build
tool
should
be.
It's
just
snap
that
you
can
snapshot
containers
that
exist.
A
A
The
best
way
to
understand
container
D
is
to
understand.
Is
it's
a
Geo
PC
interface
and
the
best
way
to
to
look
at
the
project
if
you're
first
starting
is
to
get
it
to
the
API
directory,
which
is
conveniently
right
at
the
top
of
the
github
repo?
And
you
look
a
github
and
look
through
and
look
at
the
G
RPC
API?
It's
because
they
are
really
how
container
D
works
is
built.
There's
a
few
little
bit,
there's
a
few
bits
missing
from
them,
but
I'm
going
to
cover
the
the
high-level
parts
which
are
there.
A
There
are
some
bits
around
the
metadata
that
don't
have
interfaces
yet,
but
we'll
do
soon
as
so,
but
pretty
much
you,
you
can
start
at
the
top
level
of
the
api's
and
look
through
and
really
understand
the
project,
I'm
going
to
kind
of
run
through
a
little
bit.
What
these
are
there's
a
this
is.
This
is
kind
of
the
docker
storage
architecture,
which
is
kind
of
complicated
and
everyone
hates
container
these
really
much
simpler.
A
It
has
a
store
for
content,
it
has
snapshotting,
so
the
disk
is
the
on.
The
left
is
the
image
tool
and
cutter
is
the
container
runtime
tool.
So
these
are
the
kind
of
the
notionally
the
two
halves
of
it
of
container
d.
They
share
a
metadata
store,
which
is
names
and
tags
about
things,
and
it's
a
really
simple
structure.
It
makes
for
a
surface
I'll.
Tell
you
about
that,
a
bit
more
in
a
minute,
so
G,
obviously
API
number
one
is
content,
which
is
a
Content
store.
A
You
take
things
in
that
are
basically
docker
images
or
other
OCI
images
which
are
basically
which
a
content
addressed
stores
so
basically
they're
a
load
of
a
big
blob
of
stuff
with
a
hash
written
in
simple
terms.
They
actually
are
often
file
system
layers,
but
in
conceptually
for
them
the
contents
to
a
point
of
view.
It's
just
it's
a
blob
and
you
want
to
address
it
by
content.
A
The
interface
is
fairly
straightforward,
read,
read
and
write:
there's
a
slightly
more
complicated
thing
with
right.
So
you
can
you
have
a
stream,
an
updating
stream
while
you're
writing
the
content,
so
you
can,
if
you're
fetching
something
for
remotely
and
writing
takes
quite
some
time.
You
can
see
what
which
bits
you've
filled
in
so
far
of
the
thing
makes
restart
and
anything
like
that.
You
need
to
do
if
the
network
connection
goes
down
and
you
want
to
finish
committing
your
own
content
blob
when
you
get
it
out,
it's
much
more
straightforward.
A
If
you
finished
yet
G
RPC
service
number
two
route
FS,
which
is
basically
about
taking
a
bunch
of
layers
that
you've
got
from
the
content,
store
and
unpacking
them
and
taking
their
bits
of
the
image
and
and
building
something
that
you
could
later
actually
run
a
container
from
it's
very
much
a
do-it-yourself
interface
mount
the
mounts
call
doesn't
mount
everything
for
you.
It
just
tells
you
what
you
need
to
do
to
mount
it,
so
you
can
do
useful
things
like
privilege,
separation
and
things
like
that.
A
A
A
They're
meant
to
be
extended
by
plugins,
but
they
cover
the
two
well,
the
three
basic
styles
of
doing
of
doing
layering,
which
is
which
has
been
successful
in
docker,
and
we
kind
of
learned
to
laugh
but
with
much
nicer
api's,
because
the
api's
are
really
clean
and
straightforward
and
understandable,
whereas
if
you've
ever
looked
at
the
graph
driver
code
in
docker
in
runner,
what
you've
probably
run
away
screaming.
But
this
does
understand
a
Bullen
and
nice.
A
Then
there's
execution
g-o-p
see
service
number
three.
This
is
quite
relatively
straightforward
on
a
creator
containers
as
I
said,
crate
and
starter
split,
so
you
there's
the
two
stages,
delete
list
and
then
get
events
from
them
really
quite
straightforward.
It
kind
of
obvious
interface
to
and
to
running
containers,
and
then
there
finally
there's
a
shame
which
is
a
kind
of
which
is
the
shims,
a
small
process.
That's
attached
to
every
container
that
sits
there
and
handles
its
I/o.
A
One
of
the
purposes
of
the
shim
is
to
mean
that
you
can
completely
restart
container
D.
If
you
want
to,
for
example,
upgrade
it
while
your
containers
are
still
running
and
the
shims
can
then
be
reattached
and
all
the
Oh
containers
keep
running.
So
you,
if
you
want
in
in
theory
you
your
upgrade
process
for
container
D,
may
be
that
you
actually
upgrade
container
D
without
ever
stopping
your
containers.
There's
a
few
other
use
cases
of
the
shim
as
well
kind
of
where
some
of
the
log
handling
happens.
A
Things
like
that,
but
that
has
a
slightly
more
complicated
control
plane.
It's
also
a
replaceable
component.
If
you
want
it's
a
standalone
binary.
So
if
you
want
to
make
a
custom
shim
that
follows
this
interface,
you
can
also
do
that.
I
think
that
the
VM
where
people
are
running
containers
are
sorry
running
virtual
machines
as
containers
or
doing
a
custom
trim
parts
because
they're
using
a
very
different
back-end
and
there's
options
of
customization
around
that
so
Jo
PC
is
really
really
important
and
totally
everything's
built
around
the
GRP
interfaces.
A
The
command
there's
a
command
line,
but
it's
not
the
API.
It's
just
there
for
running
tests
playing
with
and
particularly
and
while
it's
been
developed,
it's
been
quite
changeable,
to
say
the
least.
The
options
in
the
command
line
of
them
often
change
completely
every
week
and
it's
been
kind
of
confusing
for
people
it'll,
probably
stabilize
a
bit
more
soon,
but
it's
it's
useful
just
for
playing
with,
because
you
can
do
quite
low-level
things
with
the
command
line.
A
I'll
show
you
some
of
the
examples,
but
it's
not
the
way
that
we
expect
anyone
to
interact
with
this
project
in
the
long
term.
It'll
be
we
expect
the
G
RPC
interfaces
are
the
API
G
RPC
is
how
it's
built
and
how
it
works.
So,
as
I
said
that
there
are
two
commands
distant
cutter,
so
dis
lets,
you
do
everything
with
images
and
resurfaces.
A
A
No-
and
you
is,
as
I
said,
it's
not
an
end
user
API,
but
it
does
correspond
to
the
ER
PC
API
is
that
there
are
to
a
large
extent,
which
is
quite
quite
cool,
and
then
kurta
is
everything
about
containers
and
shims,
slightly
simpler
and
more
straightforward,
you
can
do
run,
delete
list
and
get
gatling
profiling
for
information
out
and
stuff
like
that
which
is
kind
of
cool
as
well
as
of
last
week.
These
commands
actually
work
before
that
it
was.
A
A
As
well
as
the
GRP
c.a.p
eyes,
which
are
really
important,
there's
also
the
Prometheus
API
arrived
final
last
week
in
this
first
film,
which
is
really
nice,
the
GOP
capr.
So
the
prometheus
end
point
is
actually
really
really
cool
because
it
gives
you
every
piece
of
information.
There
is
about
the
container
every
container
that
container
D
is
running
and
I've.
A
Given
you
a
little
teeny-weeny
snot,
the
subset
of
it
here
with
bits
of
things
like
the
cgroups
matrix
for
a
container,
so
you
can
see
how
many
CPU
nanoseconds
that
container
has
used
on
each
different
CPU
core
I
mean
we're
talking,
absolutely
all
the
detail
about
what's
running,
and
this
is
really
really
nice
and
it's
really
detailed.
There's
all
the
information
is
there,
and
so
you
can
really
really
understand.
What's
going
on
in
your
system.
A
A
It's
much
cooler
than
that
promethease
endpoint
in
dr
at
the
moment
which,
because
it's
got
so
much
more
detail
in
it
and
it's
M
I'm
really
looking
forward
to
using
this
myself
and
that's
so
that's
the
that's
the
second
interface,
it's
not
G,
RPC
is
prometheus,
and-
and
so
you
know
that
those
those
two
api's
are
really
really
complementary
and
important
windows
at
the
moment.
The
cage
not
in
there
for
Windows,
but
it's
been
worked
on.
A
We
will
have
full
parity
with
Windows
containers
in
container
D
and
they
will
just
work
just
like
Leona's
containers
do,
which
will
be
really
good,
because
when
the
support
for
docker
was
done,
it
was
kind
of
as
we
were
migrating
to
the
OCI
process
and
Windows
is
a
it's
windows
on
the
handle
completely
differently
in
docker,
and
it's
a
bit
messy.
This
is
to
be
really
nice
and
clean.
A
Container
D
will
just
be
compiled
on
Windows
and
run
Windows
containers
through
Windows
ACI
standard
compliant
runtime,
and
that's
going
to
be
great
other
platforms
as
well
through
particularly
there's
loads
of
people.
Finally,
getting
their
code
for
running
containers
as
VMs,
going
that
into
our
clear
containers,
the
people
doing
run
via
the
hyper-v
people,
VMware
and
I-
think
that's
really
cool.
A
If
you
need
virtual
machine
isolation
for
your
containers
that
will
be
supported
out
of
the
box
as
well,
just
by
plugging
in
a
new
OC
I
layer,
and
there
are
loads
and
loads
of
people
working
on
that
which,
within
container
D
and
using
identity
for
that
which
I,
think's
really
cool,
because
it's
been
promised
for
so
long
and
been
really
hacky
and
difficult,
and
it's
going
to
just
become
another
runtime.
You
can
just
use
which
I
think's
great.
A
So
overall,
the
aim
is
it's
easy
to
use
and
simple
if
you're,
if
you
particularly
if
you
love
gr,
PC
interfaces,
which
I
hope
all
of
you
do
here,
it's
a
nice
clean
design,
fixes
a
lot
of
complexities
from
darker
I.
Think
everyone's
had
really
enjoyed
working
on
it
as
a
kind
of
new
platform
where
we
can
get
away
from
a
kind
of
legacy
code
that
we
had
for
ages
that
everyone's
always
wanted
to
fix.
But
it's
difficult
to
do
so.
A
The
narrow!
The
narrow
focus
means
that
the
people
working
on
it
are
really
just
working
on
these
areas,
which
is
really
nice,
so
that
they've,
you
know
you
have
the
people
who
spend
their
like
whole
life,
thinking
about
image,
images
and
layering
such
as
Derek
who's
here
somewhere,
and
they
they
really
want
to
make
it
the
best
system
based
on
all
the
stuff
they've
learned
in
the
past
and
all
the
so
I
think.
That's
really
great.
There's
long
term
interface,
stability
with
the
GR
PC
interfaces.
A
We
know
the
one-year
releases,
so
people
don't
have
to
complain
about
breakage
every
few
months
or
anything
like
that
portability.
The
codebase
is
much
easier
to
understand
than
docker.
It's
really
am
because
it's
again
because
of
the
focus
so
I
think
that
that
will
help
contributors.
I
do
think
that
you
know,
starting
by
looking
in
the
API
folder
and
reading
through
the
G
RPC
api's
I've.
A
Given
you
the
top
level
summary
of
each
but
there's
more
detail
of
this,
if
them
in
each
of
those
files
that
that
just
gives
you
at
that
understanding
in
in
a
really
straightforward
way
and
I
think
G,
G
RPC
is
really
great.
From
that
point
of
view,
you
can
obviously
then
there's
a
bunch
of
libraries
that
you
can
use
as
well
and
things
like
that.
But
it's
it's
a
really
nice
straightforward
structure
and
nothing
easy
to
to
get
involved
with.
Please
do
get
involved,
it's
a
community
project.
A
We
want
more
people
involved,
it's
currently
at
docker
container
D,
but
it's
going
to
be
moving
soon,
I
think,
since
the
donation
there's
new
Twitter
account.
If
you
want
all
the
container
dnews,
we
set
up
a
little
docker
container
with
a
little
that
you
can
try.
If
you
run
it
and
then
it
exec
into
it,
you
can
run
dist
and
cursor
and
see
what's
going
on
there.
It
just
got
that
set
up
now.
Now
it's
running
end-to-end,
it's
kind
of
it's
quite
cool
I
can
show
you
in
a
minute,
but
so
you
can.
A
You
can
try
it
out.
Obviously,
when
you're
doing
real
development
at
the
moment,
it's
easiest
to
do
on
a
Linux
box,
probably
but
soon
there'll
be
Windows
and
support
as
well.
Things
like
that
and
but
but
yeah
give
it
try
it
out.
Take
a
look,
look
at
the
repo
read
the
api's
and
and
participate
and
join
in
every
week.
There's
a
development
report
saying
what's
happened.
This
has
been
incredibly
useful.
I
found
to
find
out
what's
changed
every
week,
because
they've
been
a
lot
of
changes,
hopefully
it'll
it'll.
A
This
quarter
will
be
more
stabilization
and
a
few
little
bits
being
pushed
in
that
are
missing,
like
the
metadata
G
RPC,
a
POS,
but
the
weekly
reports
of
checked
into
the
repo
on
Friday
afternoons.
Usually
so
it's
good
to
read
them
over
the
weekend
see
what
happened
where
we're
going,
get
a
feel
for
what's
happening.
A
There's
a
container
do
summit
after
docker
corn
in
Austin
on
the
20th
of
April.
It's
not
part
of
docker
car,
it's
after
dr.
Connor.
You
don't
have
to
be
attending
dr.
Connor.
If
you
want
to
come,
if
you
want
to
invite
it's
just
get
in
touch
with
me
or
anyone
else.
The
doctor
who's
here
or
fell
his
IBM
him
own
trainer.
Who
can
give
you
a
it
can
point
you
at
the
right
people
we've
got
a
whole
the
whole
morning
on
container
day.
All
the
maintainers
will
be.
A
A
Daniel
is
well
okay,
so
yeah
do
they'll
with
all
will
all
be
around.
So
please
ask
questions,
and
you
know
talk
to
people
and
ask
ask
all
the
questions.
You
can
ask
questions
now.
There's
a
lot
bit
of
time
left
I'm
here
I'm
around
all
day,
though,
but
yet
so
happens
to
take
questions
now
for
the
time
we've
got
left
as
well.
A
A
Well,
there's
a
few
issues:
one
is
they're
very
new
and
so
no
one's
quite
sure
how
it
is
one
is
their
only
split
on
Linux
so
that
we
can't
use
them
for
Windows
and
there's
some
non
clarity
about
the
ABI,
because
go-going
doesn't
define
an
ABI.
So
it's
not
clear
if
you
can
actually
usefully
separately,
compile
your
code
and
it
still
expect
it
to
work.