►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
containerd: Project Update and Deep Dive - Derek McGowan, Apple
Join containerd maintainers for an introduction and deep dive into the latest updates on containerd. With many exciting features currently in development, the upcoming release of container promises to deliver many new capabilities while retaining the stability containerd is known for amongst users. The deprecation of dockershim in Kubernetes has brought many new users to containerd along with greater need for documentation and tooling. We will cover how to get started and configure containerd for Kubernetes users. Additionally, nerdctl has filled a crucial usability gap for operators and developers coming to containerd. We will discuss how to make use of this important new containerd sub-project.
A
All
right,
oh
welcome
everybody.
I
realized
we're
in
like
the
first
slot
here,
which
is
it's
kind
of
interesting,
so
yeah,
it's
good.
I'm
excited
to
get
started
so,
as
I
said,
yeah
phil's
not
going
to
be
here
today
he's
in
valencia,
but
he
can't
be
here
today.
Unfortunately,
he
might
be
on
the
on
the
virtual
platform
somewhere,
so
hi
phil.
A
A
So
I'm
going
to
start
off
with
kind
of
where
container
d
has
been
in
the
last
year,
we've
we've
seen
kind
of
tremendous
growth
in
the
project.
A
lot
of
that
is
going
to
be
seen
from
kubernetes
1.24
we've.
We
finally
saw
the
the
deprecation
and
removal
of
the
docker
shim,
which
has
brought
a
lot
of
people.
Thank
you
is
that
dims
right
there
yeah
yeah
a
lot
of
yeah.
You
can
thank
dims
for
that.
A
He's
worked
hard
on
that,
but
that
is
that's
really
driven
a
lot
of
people
to
container
d
and
luckily
like
what
we've
seen
is,
even
though
the
number
of
users
has
gone
way
up,
the
project
itself
hasn't
seen
a
lot
of
issues.
People
seem
to
have
had
a
pretty
good
experience,
moving
to
container
d.
So
if
you
already
I'm
sure,
you're
you're
thinking
about
it
as
it's
well,
you
have
to
at
some
point
really
and
then
as
well
as
is
nerd
cuddle.
A
So
I
don't
know
how
many
of
you
are
using
nerd
gotta
today,
it's
it's
a
pretty
new
tool
developed
by
originally
by
aki
hero,
we're
seeing
a
lot
of
uptick
in
that
in
usage.
It's
driving
a
lot
of
users
to
container
d,
and
it's
really
it's
it's
a
pretty
amazing
project.
You
should
you
should
check
it
out
if
you
haven't
already.
We've
also
have
some
new
maintainers
that
have
joined
since
last.
A
It's
understandable
that
contributing
to
a
case
like
container
d,
is
kind
of
hard
to
get
started,
but
you
know
each
of
you
are
going
through
your
own
journey,
whether
it's
just
switching
to
container
d
from
from
docker
or
you're,
switching
or
you're,
just
starting
fresh
when
you
get
frustrated
or
you
hit
those
little
snags
like
like
it's
good
to
to
come
to
the
maintainers
and
and
help
us
fix
that,
because
so
that
we
can
fix
that
for
others
in
the
future.
So
I
put
this
up
here.
A
This
is
this
is
one
of
the
common
questions
to
get
asked
is
about
earring
for
container
d?
How
do
you
configure
it
and
stuff?
So
you
can
go
into
our
in
our
docs
and
look
at
it.
We
don't
have
this
information.
I
I
think
our
website's
not
really
updated
very
well,
but
when
in
doubt
go
to
our
source
code,
there's
a
docs
directory
that
has
quite
a
bit
of
information
where
you
can
find
that
find
those.
A
We
have
this
extended
support
time
period
that
we're
probably
going
to
extend
quite
a
bit
for
1.6,
so
we
don't
have
long
term
releases,
but
the
way
we
tend
to
to
end
of
life,
things
is
when
the
community
is
ready.
So
that's
that's
another
area
where,
if
you're
a
user-
and
you
see
something
you're
like
that-
can't
happen-
you
know
come
to
maintainers
and
we'll
listen
to
you
about
that
and
1.7
is,
is
on
the
horizon.
A
I
think
it's
like
four
three
or
four
at
a
time,
so
we
tend
to
support
our
our
releases
tend
to
live
a
little
longer
than
that,
so
1.5
is
going
to
be
supported
for
pretty
much
every
version
of
kubernetes
out
there.
Today,
1.6
we've
tested
with
one
two
three
and
later
and
all
the
new
ones
are
going
to
be
on
1.6
for
a
while.
So
so
I'm
going
to
talk
a
little
bit
about
where
we're
going
with
container
d
1.7.
A
One
of
the
major
uses
of
container
d
over
the
past
few
years
has
actually
been
focusing
more
on
the
environments
and
yeah
containers
vms,
whatever,
like
you're
used
like
they're,
using
container
d
to
manage
those,
and
so
we're
trying
to
improve
our
interfaces
around
how
those
are
managed,
because
vms
and
containers
they're
not
exactly
the
same.
They
have
some
different
requirements
or
different
abilities
that
you
can
do
and
you
want
to
be
able
to
leverage
from
different
parts
of
the
stack
and
then
some
of
these
other
components.
A
Most
of
these
are
actually
they'll
go
along
a
common
theme,
but
so
the
image
transfer
service
is
our
way
of
improving
the
way
we
do
pull
and
push
and
container
d.
So
right
now
we
have
kind
of
a
fat
client
approach
where
we're
doing
everything,
but
we
want
to
actually
have
a
nice
service
that
we
can
develop
against.
A
A
So
this
is
what
the
architecture
of
container
d
ends
up.
Looking
like
it's
an
eye
chart
don't
try
to
memorize
it
I'm
going
to
go
through
the
different
parts,
I'll
highlight
kind
of
some
of
those
things
that
I
mentioned:
that's
new
in
one
seven.
So
we
have
these
new
transfer
service
apis.
We
have
new
new
stuff
for
sandboxes.
A
We
have
some
new
stuff
in
our
api
layer
that
we're
working
on,
but
everything
else
is
stable
and
stays
the
same,
we're
trying
to
add
stuff
in
a
very
backward
compatible
way.
So
I
mentioned
the
continuity
client.
It's
kind
of
fat
today,
like
there's,
there's
a
lot
of
functionality
that
lives
in
inside
our
client.
A
A
The
way
we
have
developed
it
is,
we
have
a
bunch
of
service
apis
and
the
client
uses
those
same
service
apis,
and
then
we
have
a
server
proxy.
It's
actually
going
to
go
over
grpc
to
container
d,
then
in
the
actual
daemon
we
kind
of
broke
it
out
into
the
four
different
parts
we
have
the
api.
The
api
is
going
to
be
grpc
today,
but
we're
also
looking
into
supporting
ttr
pc
more
more
at
this
layer.
A
A
A
A
It
can
go
ahead
and
delete
all
the
resources
without
you
having
to
to
try
to
track
those
yourself
as
the
client.
So
the
back
end
is
where
we're
going
to
have
the
solid
implementations
of
stuff.
Like
the
snapshotters,
we
have
like
the
overlay
snapchatter,
that's
actually
going
to
handle
the
on
this
storage
of
our
snapshots.
A
We
have
our
content,
store
our
content
stores,
actually
what
stores
all
the
blobs
and
stuff
that
we
get
from
the
registry
sort
of
artifact
that
you
create
along
the
way.
So
if
you're
like
build
kit,
you're
building
something
you
might
store
something
in
the
content,
store
and
push
it
up
to
a
registry,
then
we
have
our
runtime
back
ends.
These
are
what
manage
all
the
actual
container
processes,
the
sandboxes
and
all
the
tasks
that
are
running
and
we
focus
a
lot
on
plugability
and
standardy.
A
A
Okay,
okay,
hello,
hello,
can
you
hear
me?
Okay,
all
right,
we're
back,
so
any
of
the
boxes
here
everything
is
designed
around
having
using
our
plugin
interface,
so
cri
itself
is
actually
written
as
a
plugin
that
uses
every
other
plugin
in
container
d,
we
have
metrics
something
that
plugged
in.
I
also
have
a
few
spots
here
where
we
have
snapshotters
content
stores
that
can
be
plugged
in
so
you'll
see
this
quite
a
bit.
There's
other
implementation
of
snapchatters,
so
a
common
one,
that's
become
very
popular.
A
A
We
have
some
some
plugins
like
around
the
runtime
which
can
actually
restart
your
containers
for
you
and
our
shim
layer
is
what
actually
manages
the
container
process
so
think
of
the
shim
as
what's
going
to
parent
your
container,
and
it's
going
to
it's
kind
of
like
it's
babysitting
it.
It's
it's.
It's
it's
working
on
behalf
of
container
d,
to
watch
the
container
track,
exits
and
status
and
handle
everything
handle
all
that
uses
a
ttrpc
api
for
container
d
to
actually
communicate
to
the
shim.
A
A
A
The
first
thing
that's
going
to
happen
is
the
client
is
going
to
actually
set
up
the
snapshot.
That's
used
for
the
container,
so
this
is
going
to
have
the
the
actual
root
file
system.
It's
going
to
set
up
the
root
file
system.
The
container
is
going
to
use
I'm
going
to
go
to
the
container
service,
we're
going
to
create
that
container,
and
now
we're
going
to
go
to
the
task
service,
we're
actually
going
to
run
a
task
in
standard
d.
A
A
A
So
the
transfer
service
is
one
of
the
new
things.
That's
been
worked
on,
so
it's
it's
a
it's
another,
stateless
service.
It's
what's
actually
handling
doing
a
poll
operation,
but
previously
the
poll
operation
was
done.
Client
side,
the
transfer
service
is
actually
adding
a
service
into
container
d.
While
why
this
is
significant,
is
you
can
see?
For
example,
the
the
cri
plug-in
has
its
own
instance
or
own
implementation
of
doing
image.
Poll
nerd
cut
will
use
the
client,
so
we
have
multiple
implementations
of
this.
It's
it's
really.
A
A
We
have
common
libraries
for
actually
doing
the
image
distribution
part
of
it,
so
everything
that's
related
to
transfer
the
actual
transfer
implementations
and
the
resolvers
authentication
stuff
like
that.
So
with
the
transfer
service,
the
process
is
going
to
look
a
little
different.
The
client
is
going
to
make
a
request
to
the
container
d
api.
It's
going
to
say:
hey
transfer
from
this
registry
to
local
storage.
A
The
transfer
service
is
going
to
talk
to
the
registry
registers
used
to
say,
hey,
you
need
to
authorize
we're
building
a
way
in,
and
this
is
kind
of
the
complicated
way
we
haven't
added
it
before
we're
getting
a
way
in
for
service
to
go
back
to
the
hey.
I
I
need
credentials
and
the
client
can
actually
send
those
credentials
back
up
to
the
transfer
service,
and
that's
that's
really
important
to
us
was
we're
very
strict
about.
We
do
not
store
credentials
in
container
d
like
our
metadata
store
will
not
store
credentials.
A
A
A
So,
for
example,
when
you
do
sandbox
creation
today,
this
box
here
that
says
pod
sandbox,
it's
it's
the
same
size
as
everything
else,
but
it's
actually
much
bigger.
It
does
a
lot
of
stuff
in
there
for
managing
these
sandboxes.
Obviously,
it's
like
all
the
logic
around
a
pod
is
pretty
large
and
managing
creating
the
the
sandbox
and
the
containers
for
it
and
there's
there's
a
lot
involved
in
that
in
that
process.
A
So
we're
trying
to
add
these
new
interfaces
to
make
it
easier,
not
just
to
create
the
sandbox
and
create
new
interfaces,
but
actually
this
will
give
us
an
option
to
do
stuff
from
the
client
and
as
well
as
from
from
other
plugins.
So
I
talked
about
working
on
a
cri,
v2
plugin.
You
can
think
of
a
cri
v2
plugin
as
a
simpler
implementation
that
can
leverage
these
these
services
and
there's
different
parts
of
the
stack.
A
A
This
will
give
us
some
ability,
for
example,
to
move
the
pause
logic
down
into
the
shim
it's
being
worked
on,
and
then
I
mentioned
before
kind
of
this
ttrpc
work
and
proxy.
So
one
of
the
one
of
the
things
that
we're
working
on
right
now
as
well
to
enable
this
is
by
defining
these
new
services
and
these
new
service
apis
we're
actually
able
to
move
logic
into
the
shim
when
that's
needed.
A
A
So,
if
you
think
of
how
I
demonstrated
the
poll
earlier
we're
going
to
have
a
poll,
that's
going
to
go
to
the
container
d
api,
which
is
going
to
go
to
our
local
service
implementation
with
the
proxy
implementation,
you
can
think
of
it
as
the
container
container
d.
Api
is
actually
going
to
forward
that
request
directly
into
the
shim
api
and
the
shim
can
handle
whatever
it
needs
to
to
implement
that
interface
and
return
it
back
to
the
client.
A
So
from
the
client's
perspective,
it
doesn't
have
to
do
stuff
like
go
around
container
d,
to
talk
to
shims
or
try
to
understand
too
much
about
like
what
what
implements
different
parts
we
can
handle
that
kind
of
transparently
to
the
client.
So
they
don't
have
to.
They
don't
have
to
see
that
all
right,
I'm
gonna,
go
back
to
the
overview
slide
and
that's
all.
That's
all
that
I
have
today
it's
a
reminder
of
when
the
talks
are
the
other
container
detox
that
I
recommend
there's
also
a
I
mentioned
confidential
computing.