►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Introduction to containerd - Phil Estes, IBM & Derek McGowan, Docker
Join containerd maintainers and learn how containerd is an improvement to one of the most fundamental parts of the container ecosystem. They will discuss the latest updates to the containerd project as well as how it is being used by Kubernetes and other container systems. Come dive into what containerd is, how it is different from other runtimes, and how it is built. The agenda includes an introduction to the containerd project, the architecture of containerd, and upcoming features in containerd 1.4.
https://sched.co/ZewU
A
Hello,
I'm
derek
mcgowan,
I'm
a
maintainer
on
the
container
d
project,
I'm
joined
today
by
phil
estes
from
ibm,
who
is
also
a
maintainer
of
container
d.
We
are
going
to
give
you
an
introduction
to
container
d
today.
Most
of
you
have
already
heard
of
container
d,
but
today
we
will
focus
on
the
decisions
that
you
might
make
as
a
container
to
user
or
a
potential
contributor.
A
Firstly,
phil
will
go
through
what
container
d
is
where
it
came
from
and
what
problems
it
is
solving.
Then
he
will
go
into
why
you
might
be
using
containity
today
or
want
to
use
it
in
the
future.
After
that,
I
will
discuss
how
to
contribute
to
continuity.
We
will
go
through
the
high
level
architecture
of
container
d
and
discuss
the
different
parts
which
you
may
want
to
contribute
to.
Lastly,
we'll
discuss:
what's
coming
up
in
container
d,
all
right,
let
me
hand
it
over
to
phil
thanks.
B
For
that
intro,
derek
and
hi
everyone,
it's
obviously
it
would
be
a
lot
more
fun
to
be
together
at
kubecon,
like
we
have
for
the
past
few
years.
Like
many
of
you,
it's
one
of
my
favorite
conferences,
where
I
see
tons
of
friends
and
colleagues
across
the
container
world,
but
we're
going
to
do
the
best
we
can
and
hopefully
give
you
some
details
on
container
d
that
are
valuable
to
you
and
your
current
role
and
hopefully
in
the
future.
We'll
see
you
again
at
a
conference
in
the
future.
B
You're
using
all
these
resources
need
have
some
metadata
they've
got
dependencies,
they
have
name
spaces
and
other
ways
to
to
administratively
separate
them,
and
so
container
d
again
handles
these.
For
you
and
when
derek
comes
back,
you'll
see
this
in
an
architectural
diagram
that
hopefully
helps
you
see
how
it
all
fits
together.
B
B
So
far,
the
only
major
change
we've
made-
and
it's
been
several
years
now-
is
to
bring
in
the
cri
implementation.
So
kubernetes
has
this
container
runtime
interface.
There
was
an
implementation
started
separately
that
used
container
d.
We've
brought
that
within
the
project,
and
it's
been
that
way
for
several
years.
B
A
couple
quick
highlights:
you
may
have
heard
about
them
already
at
past
conferences,
but
we're
the
fifth
project
to
graduate
with
within
the
cncf.
There
are
others
who
have
graduated
more
recently,
it's
been
over
a
year
now,
since
we
graduated
in
the
past
year,
we've
grown
in
contributors
and
more
companies,
and
so
we
now
have
over
250
unique
contributors
to
the
project.
B
We
support
linux
and
windows.
Our
windows
support
has
grown,
and
we
also
support
multiple
architectures
and
we've
added
more
recently
governed
sub
projects
like
a
rust
lang.
Implementation
of
the
ttrpc
protocol
container
encryption,
lazy
image,
pull
support
as
an
external
snapshotter,
and
so
again
a
lot
of
things
have
happened
in
the
last
year
or
two
with
container
d.
So,
if
you
aren't
up
to
speed,
there's
also
a
great
project
journey
report
that
was
put
out
early
this
year,
you
can
find
that
on
the
cncf
website
or
just
by
searching
for
container
d
project
journey.
B
So
hopefully,
that
gives
us
kind
of
a
level
set
of
what
is
container
d,
what
are
kind
of
the
main
components
of
it
and
what's
been
happening
in
the
last
year.
So,
let's
move
on
from
there,
we
talked
about
what
continuity
is
now,
let's
talk
a
little
bit
about
where
container
d
came
from,
it
was
originally
built
up
alongside
docker.
It
wasn't
forked
or
inherited
from
the
docker
code
base.
B
I
mentioned
this
already,
but
the
cri
was
originally
this
out
of
process
plug-in,
and
so
that
was
kind
of
the
last
piece
that
came
into
container
d.
So
again,
this
growth
over
years
from
the
supervisor
to
this
full
run
time
and
then
adding
in
the
cri
to
be
a
runtime
for
kubernetes
that
happened
over
a
number
of
years.
Within
that
time
frame,
it
was
donated
to
the
cncf
a
lot
of
times.
B
So,
of
course,
the
million
dollar
question
is
great.
Should
I
use
container
d,
of
course,
you're
asking
the
maintainers
of
the
project
who
have
spent
the
last
four
years
building
and
of
course
the
answer
is
yes,
but
you're,
probably
looking
for
a
more
nuanced
answer
of
well,
why
would
I
use
container
d?
So
here's
a
few
aspects
before
we
dig
even
further
coming
at
it
from
different
perspectives,
for
example,
are
you
using
kubernetes
container
d?
B
What
about
for
development
both
docker
and
build
kit?
That
would
be
our
recommended
tools
for
a
developer
facing
a
workflow,
but
those
are
using
container
d
already
today,
so
maybe
you're
using
docker
or
build
kit,
and
therefore
you're
already
using
container
d
today,
you're
interested
in
edge
container
d
is
the
most
memory
efficient
and
stable
runtime
look
at
rancher's
k3s
and
they
chose
container
d
again.
For
that
reason,
for
this
minimize
kubernetes
functions
as
a
service.
B
If
that's
an
area,
you're
interested
in
again
container
d's
performance
and
efficiency
have
caused
it
to
be
selected
by
the
open
fads
for
the
fasd
project,
ibm
cloud
functions
uses
container
d
as
the
runtime
under
the
covers
as
well.
So
these
are.
These
are
aspects
you
know,
maybe
you're
using
container
d
already,
because
you're
using
a
popular
cloud
provider's
kubernetes
offering.
B
But
these
are
all
the
kind
of
aspects
that
we
see
where
people
are
using
container
d
and
it's
important
to
think
about
this
in
terms
of
stability,
we
initially
in
2016
and
2017,
talked
about
container
d
being
this
core
stable
run
time,
but
stability
means
different
things
to
different
people.
There's
process
stability.
So
again,
if
you're,
if
you're
running
a
demon
like
kubernetes
or
docker
or
some
other
demon,
you
want
process
stability
and
that
that
that
demon
process
doesn't
crash
on
you,
corrupt
your
data,
you
don't
lose
containers,
that's
one
aspect
of
stability.
B
B
B
It
is
the
lion's
share
of
container
runtime
use
in
the
industry
today.
So
I
talked
about
this
a
few
minutes
ago,
but
effectively
because
of
all
these
use
cases.
Because
of
all
these
implementations,
if
you're
running
containers,
you
maybe
already
are
using
container
d
in
some
way,
are
you
using
docker,
then
yes,
you're
using
container
d?
B
So
all
the
cloud
providers
manage
service
offerings,
use
container
d,
and
so
you
probably
may
already
be
using
container
d
today,
if
you
have
a
use
case
that
hasn't
been
represented
here,
we'd
love
to
hear
from
you
and
hear
how
you're
using
container
d,
but
at
this
point
be
a
great
time
to
transition
back
to
derek,
to
talk
about
not
just
using
container
d
but
contributing
to
it
so
pass
it
back
to
you
derek.
Thank
you.
A
All
right,
let's
discuss
how
to
get
started,
contributing
to
continuity.
Most
of
you
are
already
using
container
d
in
some
form,
we're
still
happy
if
your
only
contribution
to
container
d
is
attending
this
session
and
learning
more
about
container
d.
We
hope
you
never
encounter
issues
while
using
container
d,
but
we
all
know
that's
inevitable
with
any
software,
please
contribute
by
filing
those
issues
on
github,
we
also
recently
opened
up
github
discussions
for
container
d.
This
operates
in
place
of
a
developer
mailing
list
and
is
a
good
place
to
ask
and
answer
questions.
A
All
maintainers
are
also
available
on
slack
for
guidance.
Even
if
you
are
just
following
issues,
it
is
good
to
understand
the
architecture
of
container
d.
It
will
not
only
help
you
diagnose
problems,
but
also
help
you
understand
what
components
may
be
affected
by
your
issue.
If
you
want
to
contribute
code,
knowing
the
high
level
architecture
will
help,
you
understand
where
to
contribute.
It
may
also
help
you
align
your
particular
interests
with
different
parts
of
continuity.
A
If
you
are
integrating
with
kubernetes,
the
cri
plug-in
is
a
good
place
to
contribute.
If
you
like,
lower
level
system
development
runtimes
are
a
good
place
to
start,
if
you'd
just
like
to
hack
around
with
container
technologies
or
have
a
new
feature,
you
want
to
try
out.
The
container
d
client
provides
good
flexibility,
for
that,
usually
contributing
to
the
client
is
the
best
place
to
start.
That
is
where
you
can
get
started
pretty
quickly.
A
As
a
user
of
container
d,
the
client
is
the
first
place
you
will
interact
with
if
you
are
building
a
system
on
top
of
container
d.
The
client
is
what
you
will
be
working
with.
You
can
see
in
the
diagram
that
some
core
functionality
that
is
often
associated
with
container
runtimes
is
implemented
here
in
the
client.
A
An
example
of
this
is
container
management
which
handles
creation
of
the
oci
specification
preparing
the
container
snapshots
as
well
as
starting
individual
container
tasks.
Image
pulling
is
also
completely
implemented
inside
the
client.
Because
of
this
approach,
clients
are
mostly
limited
to
using
our
go
library,
even
though
python
java
or
another
language
could
talk
to
the
container
d.
Api
using
grpc
basic
functionality
would
need
to
be
re-implemented
to
use
the
full
runtime.
A
The
cri
interface
is
probably
much
easier
to
work
with
if
you
are
not
implementing
your
project
in
go.
One
of
the
first
things
you'll
come
across
in
the
client
is
the
options
pattern
we
realize
not.
Everyone
is
a
fan
of
this
pattern
and
we
always
appreciate
feedback
and
pull
requests
to
make
the
client
better.
Any
software
can
get
complex
really
quickly.
Sometimes,
adding
simplicity
in
one
part
can
lead
to
complexity.
In
another
part,
with
container
d,
we
chose
to
keep
the
core
as
simple
as
possible
by
defining
clean,
simple
interfaces
inside
the
core.
A
That
meant
the
client
had
to
have
more
functionality
and
configurability
in
the
container
decor.
There
may
just
be
generic
variatic
options
on
a
core
type,
but
in
the
client
you
will
see
these
width
options
used
on
these
types
to
implement
a
feature
you
will
commonly
see
this
used,
for
example,
for
labeling
or
filtering
on
the
different
types.
We
were
also
hoping.
This
would
allow
clients
to
include
their
own
opinions
rather
than
be
forced
to
work
around
opinions
in
the
container
daemon.
A
A
We
want
data
and
operations
flowing
through
the
core
and
everything
else,
wrapping
those
types
or
using
data
that
is
tracked
by
the
core.
The
core
has
the
main
implementation
of
these
interfaces,
and
these
interfaces
are
extended
and
used
all
the
way
to
the
client.
The
design
is
such
that
all
data
flows
through
the
core,
so
that
plugins
and
other
components
don't
need
to
store
data.
This
is
important
because
we
have
implemented
garbage
collection
inside
the
core
metadata
store.
A
A
A
A
The
high
level
feature
of
remote
snapshotters
is
not
something
that
the
core
knows
anything
about,
but
one
functionality
we
did
add
to
the
core
was
the
ability
for
the
snapshotters
themselves
to
report
that
they
already
know
about
a
snapshot
as
it
is
flowing
through
the
core.
So
when
you
go
to
create
a
new
snapshot,
you
can
pass
information
that
says
this
is
the
target
snapshot
that
I'm
trying
to
create
and
it
will
pass
that
to
the
backend.
A
The
backend
now
can
actually
communicate
back
up
to
the
core
to
let
it
know
that
it
already
has
that
snapshot
that
allows
the
client
to
know
the
snapshot
is
already
available
as
a
remote
snapshot
when
it
sees
the
core
report,
the
snapshot
as
already
existing.
Meanwhile,
the
core
has
no
knowledge
of
what
a
remote
snapshot
is.
It
is
really
important
for
us
to
keep
the
core
of
container
d
unopinionated
to
make
sure
we
don't
get
feature
creep
showing
up
in
the
container
d
daemon.
A
A
The
runtime
in
the
daemon
is
responsible
for
starting
up
new
runtime
shims.
It
will
pass
through
the
oci
specification
and
all
the
commands
to
the
shim.
The
runtime
shims
are
the
boxes
on
the
right
side.
These
shims
are
what
actually
own
the
container
processes.
The
containers
are
parented
directly
to
the
shim.
The
container
d
daemon
will
talk
to
the
shims
using
the
lightweight
grpc
protocol
called
ttrpc.
A
A
There
are
many
different
runtime
shim
implementations,
the
run
c
implementation
is
the
most
common.
There
is
run
hcs
for
running
on
windows,
there's
also
a
few
sandbox
shims,
such
as
for
firecracker
or
kata
containers.
Since
the
shims
only
implement
this
rpc
interface,
anyone
can
implement
their
own
shim
to
be
used
by
container
d.
Pretty
easily
container
d
just
needs
to
know
about
the
shim
binary
in
order
to
use
it
to
run.
Containers
plugins
can
call
into
the
core
of
container
d
and
the
core
can
call
out
to
different
back-ends.
The
back-ends
themselves
are
also
pluggable.
A
For
example,
all
snapshotters
are
implemented
as
plug-ins
each
plug-in
can
define
their
own
configuration,
which
gets
included
with
containerd's
global
configuration
object.
If
you
have
a
grpc
service,
it
can
be
added
as
a
plugin
and
call
into
the
core
services
directly
cri
is
shown
in
the
diagram
as
a
plugin.
It
is
just
registered
as
a
grpc
service
plugin.
Even
though
cri
is
very
important
and
big
enough
to
have
its
own
core,
we
don't
include
it
as
part
of
container
diese
core.
A
This
is
because
cri
consumes
the
core
services,
but
today
it
is
implemented
completely
outside
the
core
code
base
in
continuity.
1.5,
we
are
looking
into
bringing
the
cri
code
base
into
the
main
container
d
repository.
This
will
allow
us
to
merge
some
of
the
core
components
of
cri,
such
as
pod
sandboxes,
with
the
core
components
of
container
d.
This
may
lead
to
new
types
and
interfaces
inside
the
core
related
to
sandboxes.
A
In
fact,
there
is
already
a
proposal
to
add
a
sandbox
api
to
container
d
and
1.5,
including
your
own.
Snapshotter
plugin
is
pretty
easy.
You
can
compile
in
the
snapshotter
and
register
it
as
a
plugin,
just
like
every
other
built-in
snapshotter
or
you
can
implement
your
snapshotter
as
a
proxy
plugin.
A
proxy
plugin
allows
a
snapshotter
to
just
implement
container
d's
snapshot
or
grpc
api
and
configure
container
d
to
talk
to
your
plugin
over
a
unix
socket.
A
The
proxy
plugin
approach
is
great
for
experimenting
with
plugins
without
having
to
compile
container
d
or
ship
your
own
binaries,
to
include
your
plugin
in
the
client.
There
are
many
options
for
customization.
By
default,
the
container
d
client
will
use
the
proxy
services
which
communicate
with
the
continuity
daemon
through
the
grpc
api.
A
However,
a
client
can
be
instantiated
with
any
custom
implementation
of
a
service
even
allowing
clients
to
operate
completely
without
a
daemon.
You
can
also
add
your
own
resolvers
resolvers
are
what
are
used
to
push
and
pull
images
to
container
d.
The
default
implementation
communicates
with
a
docker
registry
using
the
standard,
oci
distribution
api.
However,
you
can
implement
your
own
very
easily
if
you
have
a
different
or
faster
way
to
distribute
images.
A
Okay,
going
back
to
the
whole
continuity
diagram,
you
can
see
how
operations
flow
from
the
client
on
the
left
all
the
way
to
the
runtime
and
back
ends
on
the
right.
The
components
on
the
left
tend
to
be
more
stateless.
The
components
on
the
right
have
more
state,
even
though
our
garbage
collector
is
in
the
middle.
It
tracks
resources
used
by
all
the
ends,
but
it
operates
completely
invisible
to
the
client.
A
Our
end
goal
is
to
track
any
resource
which
may
be
used
by
container
d
to
guarantee
the
long
term
stability
of
the
runtime
continuity
1.4
has
recently
been
released
and
you
can
start
using
it
today.
It
includes
support
for
c-groups
v2,
improved
se.
Linux
support
support
for
remote
snapshotters
and
support
for
cri
on
windows.
If
you
want
to
hear
more
about
remote,
snapshotters
attend
the
deep
dive
session
for
container
d.
A
A
This
will
not
only
allow
for
better
integration
with
virtual
machine
sandboxes,
but
also
allow
us
to
clean
up
the
way.
Pods
are
managed
by
container
d
there's
also
work
going
on
to
improve
the
way
system.
Resources
are
managed
by
the
runtime.
This
relates
to
improving
interactions
with
resources
and
tying
them
into
the
container
lifecycle.
More
cleanly
feel
free
to
join
the
discussions
today
for
container
d
1.6,
there
are
discussions
about
a
new
node
resource
interface,
which
operates
in
the
container
lifecycle
similar
to
cni.
A
There's
also
discussions
about
the
possibility
of
introducing
a
new
version
of
the
cri
api.
So
if
this
is
something
that
interests
you
come
join
the
conversation
all
right,
that's
all
we
have
for
you
today.
Thank
you
for
joining.
I
also
like
to
give
a
shout
out
to
sue
mcgowan
for
helping
film
and
edit
this
session
bye.
Bye
now.