►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Intro: containerd - Mike Brown, IBM & Derek McGowan, Docker
Join containerd maintainers to learn about the design, project goals and history of containerd. We will cover the tools used for interacting with containerd, such as ctr and crictl. We’ll also show you how to monitor pods and containers using Prometheus and go over containerd’s plugin model to show how containerd was built to support new custom extensions. You’ll learn about Kubernetes’ Container Runtime Interface (CRI) and how to configure containerd’s CRI plugin to enable using containerd as the container runtime for Kubernetes. By the end you will understand how to get started using containerd as a developer, contributor, or system administrator for a wide variety of use cases.
To Learn More: https://sched.co/GrcW
A
All
right,
I
think
we're
ready
to
go.
I've
got
3:40,
so
we're
gonna
get
started,
hopefully
you're
here
to
hear
something
about
container
D.
This
is
the
maintainer
z--
track.
So
in
this
room,
all
those
CNC
have
projects
get
a
chance
to
do
an
intro
and
then
a
deep
dive.
There's
only
two
names
up
here
and
actually
it
might
be
a
bait-and-switch.
If
you're.
Looking
at
your
schedule,
you
thought
you'd
see
Derek
McGowan
from
docker
up
here,
Derek's
here
on
the
front
row
he
will
be.
He
and
I
will
do
the
deep
dive
tomorrow
afternoon.
A
A
A
So
let's
get
started
a
little
bit
of
history
who
came
here
and
has
never
heard
of
container
D.
Alright,
just
a
very
few
hands,
so
container
D
started
life
in
2016,
just
after
the
OC
I
had
been
formed
in
2015
run.
C
was
this
default
implementation
and
so
container
D
was
created
within
the
docker
community,
specifically
Michael
Crosby,
one
of
our
maintainer
'he's.
Creating
container
d
is
the
simple
kind
of
runtime
manager
over
run
C
processes.
A
So
in
docker
1.11
you
now
had
container
D
running
and
you
can
actually
restart
the
docker
engine
and
he
would
have
your
containers
didn't
have
to
stop
container
D
would
manage
those
processes
that
were
being
executed
through
OC
eyes,
run
C.
So
that
was
the
fair
start
again
in
that
same
year.
Kubernetes
trying
to
both
handle
docker
as
a
runtime,
but
also
rocket,
which
was
available
at
the
time
created
this
abstraction
called
the
CRI
that
contained
a
runtime
interface,
so
that
happened
in
later
in
2016
it
was
really
late,
2016
and
then
early
2017.
A
The
container
D
was
promised
to
be
contributed.
It
was
given
to
the
CN
CF,
officially
in
March
of
2017,
and
it
was
really
this
goal
of
not
just
being
this
run:
seed
manager
for
the
docker
engine,
but
to
be
a
complete
sort
of
core
container
runtime
that
supported
the
OCI
image
format.
They
used
those
here
runtime
and
that
would
implement
the
CRI,
so
it
was
useful
for
kubernetes
as
well,
and
at
that
time
we
also
added
a
plug-in
architecture
that
we'll
talk
about
a
little
bit
more
so
fast-forward
to
late.
A
A
At
that
time
we
also
stabilized
the
API
and
again
in
the
same
kind
of
timeframe,
the
CRI
implementation
had
an
alpha
release,
and
so
that's
where
we
were
last
coop
con
North
America
since
then
early
this
earlier
this
year.
We
did
a
1.1
release,
CRI
continued
to
progress
and
had
a
beta
release,
but
more
importantly,
we
talked
to
the
CRI
plugin
team.
That
was
folks
at
Google
folks
at
IBM.
Mike
Brown.
Here
was
part
of
that.
We
said
why?
A
Don't
we
just
have
a
single
project,
the
the
CRI
plugin
can
come
into
the
container
d
github
project.
We
can
work
on
it
together
and
integrate
those
projects.
So
container
d11
was
the
culmination
of
that
work.
In
that
release.
You
actually
had
the
CRI
plug-in
within
container
D
and
we'll
talk
again
about
how
that
looks:
architectural
e.
As
the
years
progressed,
we
did
a
1.2
release
just
a
few
months
ago
we
stabilized
the
Shem
API.
So
now
you
have
other
runtimes
other
than
just
run
C.
A
So
if
you've
heard
of
G
Weiser
kind
of
containers,
maybe
you
recently
heard
about
AWS
is
firecracker
project
they're
all
able
to
use
this
runtime
plug
ability
within
container
DS
so
that
you
can
use
container
D
from
a
higher
layer
but
drive
different
runtimes
underneath
and
so
again
a
lot
of
the
work
went
into
1.2
as
well
as
I.
Don't
think
we
listed
here,
but
the
Microsoft
folks
got
a
lot
of
the
windows.
A
You
know
docker,
which
again
many
of
you,
if
you're
using
kubernetes,
you
continue
to
use
the
docker
engine
as
the
runtime
underneath
your
kubernetes
cluster,
but
over
time
the
entire
docker
project
and
the
engine
that
scope
is
increased
and
it
docker
does
way
more
things
than
maybe
you
need
underneath
or
kubernetes
cluster
and
again,
you
know
certain
use
cases.
Certain
models
wanted
a
a
runtime
that
had
smaller
footprint
or
or
even
replace
certain
capabilities,
the
docker
provided
in-house.
A
You
know
less
opinionated
than
the
full
docker
engine
more
extensible
so
that
they
could
use
it
within
their
cloud
environment.
So
today,
IBM
cloud
and
gke
both
have
the
option
to
use
container
D
and
obviously,
as
as
that's
tested
and
stabilizes,
you
can
expect
that'll
be
the
default
at
some
point
in
the
near
future.
A
As
I
said
in
March
of
2017,
container
D
was
contributed
to
the
CN
CF
and
so
again
the
the
parentage
of
the
project.
That's
obviously
been
important
for
certain
folks
who
didn't
want
to
see
a
single
vendor
point
of
control
around
the
common
runtime
they
wanted
to
use
and
then,
like
I've
said,
you
know,
OCI
image
back
runtime,
spec
compliance.
A
A
There
were
a
set
of
design
principles
that,
as
we
came
to
to
expand
container
D
from
that
initial
manager
of
run,
C
to
a
more
complete
container,
runtime
extensibility,
having
loosely
coupled
components
that
could
be
used
separately
or
together
and
we'll
see
how
that
how
that
works,
having
stable
API
is.
We
have
a
very
clear
support
policy
on
the
canoe
within
the
container
D
project.
You
can
clearly
see
you
know,
there's
no
breaking
API
changes
between
point
releases.
All
that's
very
clearly
stated
with
clear
end
dates
for
support
and
then
unup,
enya
nated.
A
So
the
fact
that
that
there
are
definitely
defaults
within
container
D
but
they're
all
they're
all
possibly
can
be
overwritten
and
each
plug-in
gets
to
define
their
own
configuration.
And
then
we
have
a
go
client
library
that
allows
you
to
basically
bring
all
these
disparate
components
together
in
sort
of
a
common
way
which
you
can
use
that
or
you
can
write
directly
to
the
services.
A
So
that's
kind
of
where
we
started
in
this
gives
you
not
too
busy
of
a
picture
but
kind
of
a
complete
picture
of
that
architecture
and
I'm
going
to
walk
through
just
in
the
next
five
minutes.
A
few
of
the
highlights,
but
again
I
want
to
reiterate
that
that
tomorrow,
we'll
have
more
time
to
kind
of
dig
down
into
these
components.
A
So,
unlike
the
docker
engine,
where
push
and
pull
are
something
that
you
you
ask
the
engine
to
do
on
your
behalf,
push
and
pull
are
implemented
here
within
the
go
client
library
you
do
within
this
library
that
have
access
to
those
those
low-level
resources
like
snapshots
and
really.
The
main
goal,
of
course,
is
to
get
a
container
running,
and
that
means
that
the
main
job
of
the
library
is
to
put
together
that
OCR
configuration
with
your
specific.
You
know
if
you're
calling
it
the
API,
you
know
what
programmer
are
we
going
to
run?
A
How
are
we
setting
up
the
namespaces
all
the
knobs
and
switches
that
the
OCI
config
gives
you
and
so
again
we're
we're
passing
that
through
to
run
see?
We
don't
have
an
intermediate
representation,
so
that
means,
if
new
features
come
about
and
run
see,
then
we
don't
have
to
modify
container
D
to
handle
those
new
capabilities.
You
can
simply
pass
through
an
entire
OSI
ice
pack.
If
you'd
like
again.
B
A
If
you
were
running
and
go
or
you
didn't
want
to
interact
with
the
client
library,
all
of
the
services
in
container
D
are
available
over
G
RPC
interfaces
and
it
mirrors
those
those
internal
interfaces
of
each
of
the
components.
So
things
like
snapshots,
which,
if
you
know
the
docker
engine,
if
you
know
what
graph
drivers
are,
you
know
the
back
ends
of
overlay
or
a
OFS
in
container
D.
We
call
those
snapchatters.
A
So
again,
the
high
level
components
snapshots
content,
which
is
the
blobs
like
from
an
image
the
manifest
the
layers
and
then
containers
themselves
and
tasks
which
are
the
obviously
the
pins,
the
actual
process
running
with
within
a
container
and
then
a
an
entire
event
structure
around
that.
So
you
know
start
containers
top
container
eventing
metrics
are
exposed
to
Prometheus.
A
So
obviously,
kubernetes
defines
the
CRI
API
for
a
specific
level.
Obviously
the
CRI
has
been
changing
over
time,
so
the
CRI
plug-in
supports
a
specific
version,
CRI
API,
and
then
it
simply
uses
that
go
client
library
that
I
talked
about
to
calling
the
container
D
and
do
those
opera
raishin.
So
your
workload
gets
scheduled
to
a
node.
The
Kubla
wants
to
start
a
pod
that
calls
into
the
CRI
API,
which
will
then
call
in
a
container
d
to
actually
start
containers
and
Michael
will
show
that
in
more
detail.
A
A
C
A
So
again,
a
lot
of
our
recent
work
has
been
focused
around
this
extensibility.
You
can
do
interesting
things
like
have
your
in
resolve
our
interface.
So
if
you
have
a
custom
po
flow
with
a
registry
again
because
you're
in
this
code,
client
library
context,
you
have
direct
access
to
the
rest
of
the
container
d
interfaces,
Mike's
going
to
talk
about
CRI.
But
again
the
plug-in
model
is
very,
very
flexible
in
that
you
can
self
register
and
plug
in
to
do
whatever
you
wanted
to
do
and
even
have
custom
G,
RPC
services.
A
That
way
so
again,
I
think
at
this
point
a
lot
of
people
are
finding
container
d2
to
have
all
those
core
features
that
you'd
like
in
a
runtime
but
also
be
extremely
flexible.
So,
based
on
that,
you
know,
here's
a
here's,
a
few
use
cases
where
we
see
people
using
container
D.
Today,
obviously
we
talked
about
kubernetes
and
docker
I
mentioned
alibaba's
Pausch
container,
which
is
actually
an
open
source
project.
You
can
go
look
at
on
github.
A
They
are
using
container
D
I
just
mentioned
AWS
firecracker,
who
implemented
their
own
snapshot
or
snapshot
or
and
runtime
shim
for
their
firecracker
vmm
project.
There's
a
couple:
I
Oh
T
use
cases
ballina
and
Elliott
using
container
D
in
the
IOT
space
I
mentioned
the
garden
runtime
underneath
cloud
foundry
using
container
D
again
cata
another
VM
based
isolation,
runtime
a
couple
other
projects,
Linux
kit
from
docker,
the
mobi
project,
uses
container
D
to
run
its
services.
A
A
A
So
again,
in
the
last
year,
we've
seen
a
lot
of
interesting
uptake
in
interest
in
container
D
a
lot
of
use
cases
and
so
we're
happy
with
the
feedback
we've
got
and,
of
course,
if
anyone
has
further
use
cases
where
you're
finding
some
aspect
of
container
D
doesn't
work
in
your
use
case.
We'd
love
to
hear
about
it,
but
this
is
kind
of
an
easy
transition
point
to
Mike
to
talk
a
little
more
about
the
CRI
and
how
that's
implemented.
B
How's
everybody
doing
after
lunch,
retired,
pretty
good
yeah,
so
I'm,
like
Brown
I've,
been
with
IBM
for
a
long
time,
I
left
and
came
back
again
to
work
on
open
source.
My
os/2
programmer
das
programmer.
You
know
pretty
much
done
everything
from
telecom
servers
to
session
management
and
set
operating
systems,
so
they
said
Mike,
it
won't
work
on
docker
I
said
yeah.
That
sounds
like
fun.
C
B
I've
been
working
on
open
source
projects
for
a
while,
then
they
about
a
year
and
a
half
ago,
two
years
ago
they
said
about
container
D.
We
need
a
shim
to
hook
up
between
cubelet
and
container
D.
If
you
know
today,
there's
a
dr.
shim,
that's
using
the
CRI
interface,
that's
how
you
get
containers
today
by
default.
Well
now,
if
you
want,
you
can
change
the
the
defaults
to
use
container
D
as
long
as
it's
installed
and
running,
and
it
works
pretty
good.
We
we
test,
everything
gets
tested
for.
B
Docker
is
well
on
container
T
on
every
PR
that
we
push
we're
done
millions
of
tests
and
it
actually
runs
with
less
flakes.
We
think
then,
no
offense,
then
docker,
that
does
it
seems
you're
pretty
clean.
Okay
and
it
runs
a
little
runs
a
little
faster.
It's
a
little
smaller
and
I.
Think
that's
one
of
the
points
to
why
we
we
did
container
DB's
container
the
the
kubernetes
guys
they
were
a
little
disappointed
with
every
time
docker
came
out.
There
wasn't
a
lot
of
talk
about.
How
would
how
it
was
gonna
affect
kubernetes.
Okay.
B
So
when,
when
the
CRI
interface
came
out,
it
was
okay,
we're
gonna
have
a
very
official
API
and
if
you
implement
these
services
correctly
we'll
test
for
it
container
speech
slipped
in
that
slot.
Okay,
so
you
see
this
little
boxer
called
cubelet.
It
is
you
met
Phil
mentioned
earlier.
We
have
a
gr,
PC
API
it
go.
B
We
have
a
daemon
that
runs
that
receives
the
requests
we
have
registered
to
through
the
GRP,
see
that
we're
gonna
service,
the
CRA
API,
and
we
typically
only
talk
to
couplet
unless
you're
you're
using
one
of
the
tools
like
cry,
CTL
cry
see,
tell
will
be
another
customer
of
this
GRP
capi
christ.
You
can
create
a
pod
with
it
or
just
inspect,
usually
just
inspect,
because
if
you
create
a
pod
with
some
other
tool
besides
couplet,
then
it's
not
gonna
tell
the
rest
of
the
cluster.
B
What's
what's
going
on,
so
that's
sort
of
an
interesting
point
see
as
you're,
showing
here
every
time
we
on
the
right.
Every
time
we
create
a
pod.
We
we
create
a
a
place
place
where
we
put
the
resources
and,
and
that's
going
to
be
in
a
namespace,
but
so
pod.
It's
a
its
own
right
is
is
really
just
a
logical
concept.
B
For
the
plot
we
use
shown,
we
see
an
eye
to
do
all
of
our
networking
after
we
create
the
pod,
we'll
go
ahead
and
created
a
namespace
for
it,
a
network
name
size
and
we'll
use
the
CI
plugins
to
execute
your
whatever.
However,
you've
configured
it
be
a
flannel
or
or
whatever
weave
they're
all
supported,
as
shown
we're
using
run
C
as
our
default
runtime.
But
there's
a
new
way
to
configure
per
pod,
be
the
ability
to
to
switch
runtime
suit,
caddy
containers
or
some
other
runtime.
B
B
We
can
I've
got
a
PRI
just
pushed
last
weekend,
we're
if
you
do
an
inspect
on
the
pod,
you'll
actually
get
the
cni
results.
If
there
is
some
kind
of
error
in
your
configuration
of
CN
I,
will
we're
gonna
be
showing
you
that
result
as
well
and-
and
we
show
the
where
the
config
password
felt
like
I
saw
so
what
another
thing
you're
gonna
get
from
container
D
is
a
little
little
more
help
in
the
debug
area.
You
know
is
my
networking
that
kind
of
stuff
we're
gonna,
try
to
work
with
those
guys
and.
B
B
So
you
can
also
help
help
on
that
tool.
If
you
want
cry
see
tell
it's
the
other
side
of
CRI
for
for
debugging
and
analyzing,
what
CRI
employee
container
runtime
integrations
have
built.
We
actually
have
test
cases
that
are
written
in
the
chrysotile
repo
whole
bunch
of
cry
tests.
So
it's
sort
of
interesting.
If
you
want
to
look
at
if
you
want
help
on
debugging
over
writing
test
cases,
it's
a
little
easier
to
write
the
test.
Cases
that
go
here
and
in
Christ's
ETL
than
it
is
to
do
the
end,
end
tests
and
kubernetes.
B
C
B
So
we
was
asking
earlier.
How
do
you?
How
do
you
configure
Kubb
ATM
to
use?
Well
there's
some
some
parameters
over
here
in
see
it's
at
City
default.
Sorry,
that's
a
default
couplet!
You
can
configure
your
extra-large.
Basically
just
tell
couplet
that
you're
gonna
want
to
run
a
remote
runtime,
whatever
kind
of
timeout
you
want
and
where
the
sock
is-
and
this
is
the
default
sock
that
we
use
for
communicating
over
to
your
PC
okay.
B
So,
as
you
can
see
with
on
coop
cuddle,
we
have
one
pod,
not
sure
why
it's
curly
riding
in
Gen
X.
It
runs
pretty
quick,
but
for
the
demo,
purses
I
just
want
to
make
sure
he's
already
up
and
running
so
so
this
is
the
coop
CTL
command
for
take
a
look
at
what
pod
we
currently
have
running.
Let's
go
look
a
little
bit
deeper
I'm
using
cry.
Ctl.
B
C
C
B
B
Mentioned
before
that,
we
we
create
a
pause
container
and-
and
this
is
going
to
show
the
details
for
that
as
well.
If
you're
familiar
with
OCI
specification,
we
we
support
lucy
ice
pack,
both
the
runtime
and
the
in
respect,
and-
and
this
is
a
runtime
spec
for
a
pause
container,
alright,
showing
the
command
arguments.
Ooh,
man,
caps,
you
can
see
what
security
permissions
the
deep
these
are.
The
default
security
permissions,
the
docker
uses
the
same
use,
the
same
default
security
permissions
and
container
D
and
stalker
does
you'll
find
it.
B
We
try
to
use
all
of
the
doctor
defaults
so
that
when
Shearer
pots
go
from
running
on
docker
they're
running
on
a
container
date
just
work.
Okay,
you
can
modify
the
defaults
if
you
want
to
be
more
secure,
ELISA
cure,
as
well
as
you
can
in
docker,
and
we're
showing
the
the
mounts
that
we
set.
These
mounts
are
in
the
OCI
spec
format,
not
in
the
Kuban
Hades
format.
B
C
B
C
A
B
It's
hard
to
remember
the
different
command
syntax.
It's
close,
you
can
guess
the
different
committee.
We
tried
to
use
the
same
commands
between
cry,
CTL
and
and
docker.
So
if
I'd,
if
I
wanted
to
do
a
PS
all
like
doctor,
does
that
also
works
here?
If
I
just
want
to
listen
containers,
so
yeah
I'm,
just
trying
to
give
you
a
feel
for
the
you
know
the
tools,
the
tool
side
and
but
they're
there
and
they're
pretty
easy,
and
we
take
issues
and
PRS
to
extend
an
answer.
We
make
them
better.
Okay,.
B
C
B
B
Or
commands
this
is
the
command
I
mentioned
earlier
that
chips
with
container
D,
they
like
to
say
it's
an
unsupported
command
with
what
it
really
means
is
that
it
works,
but
we
don't
want
this
to
be
a
docker
replacement.
Api,
you
know
command
line
tool,
all
right
not
meant
to
be,
and
they
the
commands
might
change
the
syntax.
Might
change.
B
I
can
tell
you
a
couple
that
moved
in
moved
and
we
don't
worry
about
they're
moving
it
much
because
we're
not
expecting
anybody
write
scripts
to
use
when
they're
using
these
okay,
if
you
want
to,
if
you
want
to
use
scripts
and
things
like
that,
you
know
you
use
the
docker
tools
or
some
other
higher-level
to
like
code.
You
know
kubernetes,
where
they
support
their
eight
guys.
I
mentioned
docker
and
just
for
a
second,
it
lets
suit.
So
we
got
going
over
here.
B
Well,
it's
using
its
using
the
same
container
d.
So
three
weeks
ago,
I
installed
an
update
on
inventor
and
it
automatically
updated
the
container
d
that
was
on
my
computer
so
in
what
that
really
meant
was
container
doctor
is
using
the
same
version
of
container
D.
That
I
was
using
in
development
and
it
everything
just
works.
B
So
we've
got
this
concept
of
namespaces
container
name
chases,
it's
not
the
same
as
a
kubernetes
namespace
or
Linux
namespaces,
but
you
can
actually
have
a
one
tool
using
container
D
like
docker
and
it's
gonna
have
its
own
set
of
containers
and
and
they're
separate
isolated
from
the
kubernetes
containers
that
are
in
pods.
Okay.
So
if
I
were
to
do
a
CTR
namespaces
one
of
the
commands
seats,
you're.
B
B
A
All
right
so
I
think
we're
pretty
sure
we're
out
of
time.
I
think
we
had
a
4:15
we're
minute
over,
but
if
anyone
has
questions
or
other
there's
a
whole
group
of
container
D
folks
up
here,
happy
to
talk
or
even
step
outside,
but
thanks
a
lot
I,
don't
think
we
have
time
for
open
questions,
but
we'll
be
happy
to
answer
some
things.