►
From YouTube: containerd Intro – Stephen Day, Docker (Any Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
containerd Intro – Stephen Day, Docker (Any Skill Level)
Containerd is the core container runtime originally used in Docker to execute containers and distribute images. It was designed from the ground up to support the OCI image and runtime specifications. The design of containerd is carefully crafted to fit the use cases of modern container orchestrators like Kubernetes and Swarm. In this talk, we'll provide an introduction to containerd and how you can get started with leveraging it in your infrastructure.
About Stephen
Stephen Day is a software engineer at Docker. His many contributions to Docker ecosystem projects include SwarmKit and the version 2 specification for the Docker Registry HTTP API, and evolving the available models for container image distribution. He currently works on containerd and as a maintainer of the OCI Image Specification.
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
A
So
the
project
was
started
in
April,
April
2016
and
was
released
with
docker
111
and
so
basically
provide
provided
like
a
supervisor
or
management
of
osci
Runcie
processes.
We
wanted
to
expand
the
project
as
of
December
2010
and
with
that
we
started
the
like
container
d,
1.0
work
stream
and
which
was
finalized
or
released
in
December
of
2017,
and
then
we've
recently
had
a
release
in
December
or
sorry,
and
just
just
a
week
ago,
at
the
end
of
April,
which
includes
CRI,
support
and
I'll
talk
a
little
bit
about
that.
A
A
So
why
did
we
do
this?
Why
why
another
container
runtime?
So
the
the
the
main
issue
was
the
docker
in
roughly
in
2016
that
the
docker
engine
was
really
becoming
a
monolith
and
we
wanted
to
spin
things
out
of
there.
So
we
could
make
different
components
useful
without
having
to
stand
up
the
entire
docker
engine.
We
also
wanted
to
have
other
use.
Cases
such
as
like
the
kubernetes
CRI
build
kit,
which
is
another
project
that
does
build
as
well
as
other
stuff.
A
A
So
our
technical
goals
were
to
ensure
that
we
had
a
really
clean,
G,
RPC
based
API
in
client
library.
We
wanted
full
OC
I
support
so
that,
like
it
kind
of
felt,
OC
I
native
works
really
good
with
SDI
primitives
and
they
don't
feel
tacked
on.
We
also
folk
wanted
to
focus
on
stability
and
performance
with
like
a
really
well-defined
core
and
kind
of
a
void
feature
creep
over
time
and
part
of
that
was
designing
it
for
like
decoupled
systems.
A
So
we
wanted
the
image
the
file
system,
the
runtime,
to
be
available
for
plug
ability
and
reuse.
So
I.
Another
way
of
putting
that
is
container
D
is
very
ala
carte,
so
you
can
choose,
you
can
use
the
whole
thing
or
you
can
choose
which
parts,
depending
on
your
problem
space
or
what
systems
you're
integrating
with.
We
also
wanted
to
have
be
agile
with
actual
runtimes.
So
in
container
to
you,
we
don't
actually
touch
osc
I
configs.
A
We
just
pass
them
through,
which
actually
means
you
don't
have
to
do
an
OC
I
configure
on
your
runtime.
You
can
do
other
kinds
of
runtimes
that
take
different
configurations.
So,
for
example,
like
Windows
doesn't
have
an
OC.
I
configure
has
its
own
kind
of
configuration,
but
it
also
allows
us
to
do
things
like
adding
support
for
cata
containers
took
no
no
changes
in
lines
of
code,
we
just
added
it
and
it
worked
because
it
was
run.
A
C
compatible
and
I've
already
said
that
part
we
do
use
Prometheus
for
metrics
I'll
mention
that,
so
we
have
to
try
to
use
other
CN
CF
projects
inside
of
container
D,
where
it
makes
sense
so
again.
Well,
OC
I
is
not
CN
CF,
but
it's
very
closely
related,
but
G
RPC
for
API
and
Prometheus.
For
metrics,
so
the
kinds
of
use
cases
that
container
D
fits
into
is
so
I.
A
This
big
umbrella
of
container
API
implementations
we
can
put
like
docker
mobi
under
their
kubernetes
CRI
Alibaba
pouch
has
been
cropping
up
lately,
that's
kind
of
an
interesting
project
and
then
also
like
swarm
kit
and
other
stuff
and
then
the
other.
The
other
two
big
use
cases
we're
looking
at
there's
more
use
cases
that
I've
left
off
of
here
that
you
know
people
can
try
out
but
building
images.
So
this
is
this
is
what
build
kit?
A
Does
it
leverages
container,
D
heavily
and
the
models
and
architecture
within
container
D
and
then,
as
well
as
container
us
I
was
trying
to
generalize?
Basically
what
Linux
kit
is
doing
so
Linux
kid
actually
runs
its
internal
services
as
containers,
and
this
has
been
a
long
ask
of
docker
it
was
it
was
it
was.
A
It
was
kind
of
a
problem
with
docker,
because
you
would
start
up
docker
and
try
and
run
system
services
and
actually
implement
that
you'd
have
to
have
two
Dockers,
but
with
with
the
architecture
and
container
D,
you
only
need
one
container
D
and
it
can
run
all
of
these
different
things
on
the
host
and
then
there's
also
like
IBM
cloud
is
an
example
of
a
cloud
provider
that
uses
container
D.
So
there's
a
lot
lots
of
different
use
cases.
A
It
fits
into
a
lot
of
spaces
because
of
its
flexibility,
so
a
little
bit
about
the
architecture,
so
there's
kind
of
a
three
layer
architecture
at
the
top.
We
have
like
what
you
interact
with
being
a
G
RPC
and
the
metrics
API,
and
then
in
the
middle.
We
have
a
suite
of
services
that
are
loosely
coupled
and
some
of
them
interact
depending
on
what's
needed,
but
we
can
roughly
divide
them
into
3
parts.
There's
storage,
which
is
images
and
snapshot,
file
systems
and
diffs
for
building
images.
A
Then
there's
a
metadata
portion
which
declares
containers
and
images
and
how
they
relate
to
other
parts
of
the
system
and
then
there's
a
tasks.
Api
and
the
tasks
API
is
the
actual
runtime
of
the
actual
runtime
manipulation.
So
and
all
of
this
sits
on
top
of
the
operating
system
and
then
interacts
with
the
runtimes
and
then
across
all
of
the
services.
A
We
have
an
event
service,
so
container
D
can
actually
you
can
consume
events,
and
then
you
can
actually
generate
events
back
in
new
container
D,
so
that,
like,
if
you
have
another
component,
that's
kind
of
outside
of
container
D,
it
can
generate
its
own
events
and
you
can
consume
those
within
another
component
that
you've
integrated
with
so
continuty
is,
what's
called
a
client
heavy
architecture,
meaning
that
well
stepping
back.
We
really
wanted
to
avoid
having
abstractions
that
prevented
people
from
doing
what
they
want.
A
A
Well,
let's
go
down
a
level
and
say
you
can
interact
with
what's
necessary
in
container
D
and
container
deep
only
provides
what's
necessary,
but
then
the
client
can
actually
integrate
with
the
operating
system
to
provide
functionality,
and
so
we've
worked
very
hard
to
build
a
solid
client
library
to
make
this
a
reality.
But
it
means
that
you
can
so
rather
than
building
plugins
everywhere
to
add
functionality.
You
can
build
your
own
code
and
do
everything
you
want
and
then
interact
with
the
container
D
abstractions.
A
A
If
you
really
want
to
understand
container
D
deeply
and
then
also
the
go
dock
is
great,
and
so
this
go
dock
link
takes
you
directly
to
the
client
and
that'll,
be
how
to
implement
containers
with
that
and
in
these
examples,
we'll
all
use
interfaces
that
are
defined
in
the
go
dock.
So
a
little
bit
about
kind
of
how
these
services
fit
together.
Like
a
it,
looks
like
just
a
bunch
of
services,
what
do
they
do?
Looks
really
complicated
and,
and
so
I
think
pulling
an
image
is
a
great
example.
It's
a
really
complicated
thing.
A
It's
it's
magic
and
docker,
and
recreating
that
magic
and
defining
the
different
parts
of
it
is
very,
very
important
to
a
good
container
system.
So
the
way
I
like
to
think
of
it
is
this
data
flow
diagram
on
the
bottom.
We
have
the
services
and
then
the
colored
boxes
are
the
like
client
heavy
implementation,
and
then
we
have
our
goal
at
the
end,
which
is
mounts
and
mounts
are
just
things
you
pass
the
container
to
make
up
the
root
filesystem,
so
to
run
a
container.
A
Your
goal
is
to
get
a
root
filesystem,
and
so
you
say
when
you
say,
pull
you're
going
to
start
doing
three
things
or
sorry,
two
things
your
first
operation
is
going
to
be
to
fetch
the
image
data
from
the
from
a
remote
register
it
with
the
content
store,
which
is
where
we
store
securely
store,
all
of
the
image
metadata
or
sorry.
All
of
the
image
like
layer
files
manifests
manifest
lists,
etc,
and
then
we
register
that
with
the
image
store.
A
So
that's
just
a
link
back
to
that
and
then
we
also
do
an
unpack
process,
and
so
what
that'll
do
is
take
the
contents,
such
as
a
layer
and
then
it'll
apply
it
to
a
model.
We
call
snapshots
and
snapshots
what
they
do
is
provide
something
similar
to
what's
in
graph
drivers
and-
and
this
gives
you,
the
the
ability
to
have
a
kind
of
a
revision
container
file
system
and
I'll
talk
a
little
bit
about
that
later.
A
All
you
have
is
a
metadata
store
that
contains
references
into
the
snapshot
ER
and
into
the
content
store,
and
what,
in
based
on
that
pull
flow,
you
can
actually
pull
your
image
config,
which
becomes
a
no
CI
config,
and
then
your
route
FS,
which
is
a
set
of
mounts.
So
here's
an
example
of
investigating
the
root
filesystem.
We
can
do
CTR
snapshot
LS
and
that
will
tell
us
what
snapshots
are
and
what
container
file
systems
are
there,
and
we
can
see
the
relationships
if
anybody
remembers
docker
tree
the
command
that
was
removed.
A
Here
we
see
an
overview
of
The
Container
Service,
which
is
a
metadata
service
and
the
task
service,
which
is
our
like
run
time
controller.
And
what
actually
happens
is
you
give
it
a
run
time
config
into
the
containers
service
and
then,
when
you
start
up
at
a
container
using
the
task
service,
you
use
the
mounts
that
are
consumed
from
the
snapshot
and
then
you
pass.
Then
you
convert
all
of
that
down
to
the
runtime
config
and
then
you
can
run
these
various
things
and
that
this
this
is
this
loosely.
A
What
it
looks
like
on
the
backend
and
just
to
give
you
a
kind
of
an
idea
of
how
that
how
the
relationships
might
work
the
same.
We
do
way
we
do
pull
here's,
how
we
do
is
start
on
a
can
or
a
run
rather
on
a
container,
so
we
start
out
and
we
initialize
so
we'll
grab
the
images
and
snapshots
we'll
build
a
new
container
file
system
into
the
snapshot
store,
which
will
fork
off
of
an
existing
image
snapshot,
and
then
we
set
it
up.
So
we
build
this
container.
A
We
build
an
OC,
I
config
from
that
and
then
and
we
get
mounts
and
then
we
actually
start
the
container
and
then
out
the
out
the
arrow.
On
the
other
end,
we
have
running
containers,
hopefully
all
right,
so
I'm
gonna
actually
leave
the
demo
to
the
end,
because
these
are
rather
short,
but
what
I
want
I
do
want
to
show
you.
A
couple
of
I've
talked
a
lot
about
code
in
the
client,
heavy
architecture
and
I
just
want
to
show
you
how
simple
pulling
an
image
running
containers
is,
and
you
know
it's
it.
A
Doesn't
you
know
it
like
with
docker?
You
drive
like
an
API.
Where
is
this
like
I
can
go
into
this
code
and
I
can
modify
how
everything
happens.
I
can
change
everything.
I,
could
you
know
I
could
send
out
a
tweet
every
time,
I
pull
an
image
or
something
like
that.
Somebody
should
do
that
it'd
be
annoying
but
cool.
A
A
So
running
a
container
is
very
similar,
like
it
continues
to
build
on
this
accommodator
api.
So
you
use
the
same
client
that
you
declared
before
you
can
here.
We
specify
that
we're
going
to
use
a
particular
image
which
was
defined
off
the
screen,
and
then
we
can
grab
this
specification
directly
from
the
image
config.
So
that's
actually
so
I
can
actually
define
my
own
OCI
generations
like
I.
Don't
have
to
use
an
image,
I
can
define
my
own
OCI
generation
process
or
I
can
like
modify
it
with
my
own
SEC
profiles
or
whatever
you
want.
A
So
you
can
build
new,
Combinator's
and
and
really
customize
what's
happening
and
we
delete
the
container
when
we
exit
the
function
and
then
so
once
we
have
a
container,
the
container
is
like
a
metadata
object
and
we
can
use
it
to
generate
tasks,
and
so
you
call
container
dot
new
tasks
and
that's
your
actual
runtime
handle
one
interesting
point
that
we
did
with
container
D.
Is
we
split
out
the
concept
of
the
metadata
object
and
the
actual
runtime
objects
due
to
performance,
and
the
reason
for
this
is
in
docker
container?
A
The
container
object
is
a
super
object,
meaning
it
ended
up
having
lots
of
locks
so
anytime.
You
want
to
modify
it.
You
have
to
grab
all
those
locks
and
you
have
to
deal
with
the
runtime
State
anytime.
You
want
to
like
start
a
container,
stop
a
container
you're
grabbing
all
these
locks,
and
we
avoid
this
in
container
D
as
much
as
possible.
So
the
next
step
is
you
wait
on
the
task
and
that
just
calls
a
wait
API,
and
that
gives
you
back
a
channel
and
then
you
can
wait
on
that
channel
later.
A
I
think
we
have
an
example
following
this
and
then
you
can
call
task
dot
start.
So
this
is
this
very
similar
to
when
you
like,
create
a
container
and
docker,
and
then
you
start
a
container
in
docker
and
you
can
do
anything
in
between
there
and
and
really
hook
into
anything.
So
here
here
we
just
like
the
last
example.
We
have.
A
A
Another
thing
about
this
Combinator
API
is
that
you
can
do
things
like
you
can
define
your
own
functions
that
you
can
do
on
top
of
a
spec.
So
there's
an
example
of
a
accommodator
that
you
can
pass
into
creating
a
new
container
that
will
generate
an
H
top
config
and
you
can
so
you
can
exec
in
and
just
run
H
table
with
with
a
TTY
and
there's
all
sorts
of
cool
things
you
can
do.
You
can
do
it.
You
can
define
networking
accommodators
like
this.
A
So
so
here's
an
example
of
with
host
namespace,
but
we
can.
We
can
do
this
in
CRE
I
believe
there's
places
where
we
used
similar
Combinator's
to
actually
hook
into
CNI,
so
a
little
bit
about
the
project,
since
this
is
an
intro.
So
we
have
a
very
well-defined
release
process
and
we
don't
just
say:
oh,
we
use
semver
and
then
argue
about
it
layer
we
actually
outlined
exactly
which
parts
of
semver
are
done.
We
define
which
components
are
covered
by
the
semantic
versioning.
A
We
also
define
the
lifecycle
of
the
releases,
and
you
can
read
all
about
that
here
in
detail,
but
I'll
just
give
you
a
quick
overview.
So
this
is
one
component
which
is
called
our
support
horizon
and
it
defines
how
long
we
have
branches.
So
each
branch
has
a
state
end-of-life,
which
is
old
branches.
We
no
longer
back
port
fixes
to
those
we
have
active
branches,
which
is
includes
1.0
and
1.1,
which
will
be.
We
have
this
fancy.
A
You
can
parse
that
and
figure
that
out,
but
basically
we're
saying:
okay
well,
we'll
support
it
till
the
end
of
kubernetes
or
the
release
of
1.2
or
April
23rd,
2019
and
we'll
take,
whichever
is
the
maximum
of
those,
so
that
you're
not
left
in
a
state
where
one
point
you're
still
running
one
point
one,
but
there's
a
security
problem,
and
it's
still
in
use
by
kubernetes
or
or
what
have
you
so
in
this.
This
release
process
is
defined
in
that
release
documents.
A
A
Purposefully
so
there
could
be
changes
that
are
accidentally
happening,
but
we
do
consider
it
stable.
The
metrics
API
is
considered
stable
and
we've
actually
versioned
it
for
Prometheus.
So
if
we
do
want
to
change
it,
we
can
add
a
v2
metrics
or
v3
metrics.
Hopefully
that
won't
happen.
The
other
components
right
now
are
considered
unstable,
just
because
they're
changing
or
integrating
with
a
bunch
of
systems,
and
we
want
to
be
able
to
make
changes
so
that
that
things
work
well.
A
So
the
client
API
is
unstable,
although
it's
relatively
stable,
so
don't
be
afraid
to
use
it.
The
CRA,
the
CR
IG
RPC
API,
is
considered
unstable
because
it's
still
in
alpha
and
I'm,
not
sure
when
that
comes
out
of
when
that
comes
out
of
alpha
yet
and
then
the
command
line
tool,
the
CTR
CTR
tool
is
also
considered
unstable
and
right
now
it's
out
of
scope.
I
know
people
have
more
interest
in
that.
So,
if
you
do,
let
us
know,
but
it
you
know,
don't
deeply
integrate
scripts.
A
If
you're
going
to
do
production
work
with
container
D
I
highly
recommend.
Writing
your
own
go
code
or
building
your
own
client
CRC.
Our
CRI
tool
is
an
example
of
that
and
it
works
great
in
because
of
the
way
you're
because
you
really
want
integrate
with
a
target
system
rather
than
these
low-level
things
like
container
D
is
really
like
a
container
runtime
building
system
so
that
that
really
impacts
how
we
do
that,
so
the
so.
A
The
latest
release
was
done
with
the
April
26th
I
want
to
say
is
that
right
and
so
there's
two
big
things:
I
mean
that
there's
a
whole
big
list,
I
suggest
you
go
read
these
release,
notes
it's
a
really
cool
release.
It's
really
cool
to
see
that
see
the
project
taking
shape
and
and
but
the
biggest
thing
is
we
merged
in
ceará
kubernetes
CRI
support.
A
So
you
can
run
container
d
with
kubernetes
out
of
the
box,
and
then
we
also
there
was
a
lot
of
requests
for
snapshot
or
plugins,
but
we
actually
found
that
there's
really
only
three
that
were
really
popular,
and
so
we
just
added
those
rather
than
adding
a
complex
plug-in
system
that
might
break
and
that's
ZFS,
au
FS
and
a
native
snapshot
ER,
and
then
there's
lots
of
other
great
things
in
this
release
and
I
definitely
go
to
this
link
and
and
read
it.
They
were.
A
It's
it's
really
really
really
good,
especially
if
your
go
developer,
it
should
be
pretty
pretty
straightforward
to
get
started
and
then
porting
testing
tested
on
your
architecture
of
choice.
Let
us
know
if
there's
problems
with
that,
we
do
want
better
multi
arc
support
and
that
that
should
be
coming
down
the
pipe.
We
also
do
heavy
upstream
testing
with
kubernetes
test
grid,
and
you
can
check
out
the
status
of
that
in
cig,
node
container
D.
A
So
a
couple
of
new
talks:
I
talked
a
lot
about
snapshots
and
it's
a
complex
topic
and
it
involves
file
systems
and
other
fun
stuff
I'm
doing
a
talk
on
it
in
an
hour
and
I'll
go
over
all
the
cool
stuff.
You
can
do
with
snapshot
at
file
systems
and
then
also
we'll
do
a
deep
dive
into
container
D
and
I'll
use.
A
This
same
slide
set,
but
I'm
gonna
like
push
everything
on
the
side
and
just
like
do
mostly
demo
and
kind
of
show
you
like:
okay,
here's
CRI
tool,
here's
how
the
pods
look
and
or
actually
first
we'll
convert
over
from
docker
to
container
D
and
then
we'll
look
at
the
pods
and
we'll
play
with
them
and
it
will
pull
apart.
All
the
pods
look
at
the
metadata
storage
and
then
actually
we
can
get
down
to
the
run.
So
you
can
fig
so
that'll,
be
a
fun
talk
and
hopefully
it'll
be
more
interactive.
A
A
A
A
We
had
to
implement
a
like
a
strict
subset
of
what's
between
them
so
like,
for
instance,
our
runtime
model
isn't
is
definitely
like
platform
agnostic,
but
if
you,
your
snapshot
are
not
going
to
be
that
that
way,
so
you
need
to
be
able
to
interact
with
the
file
system
and
really
be
it's
like
like
it
has
to
be
local
to
the
host.
So
it's
not
a
remote
API,
so
it's
a
little
different
from
like
say
docker,
pouch,
sure
or
any
of
those
other
projects
like
that.
A
A
So
oh
yeah
yeah,
so
it
will
come
with
with
things
that
are
so
so
the
question
was:
will
it
come
with
components
that
are
suitable
for
the
various
platforms?
And
the
answer
is
yes,
what
I'm
saying
it's
not
platform
agnostic
like
docker,
for
example,
like
you
mostly
interact
with
the
API,
whereas
with
container
D,
we
say
well,
you're
gonna
be
local
to
the
host
and
you
can
interact
with
the
API
as
well
as
the
host
operating
system.
That
is
that
clarify!
Okay.
Are
there
any
other
questions
all
right?
A
So
let's
do
some
demos,
okay,
so
so
running
a
container
is
pretty
simple.
I
have
an
image
here
and
I
mean
CTR.
Is
you
know
it's
kind
of
like
docker?
You
know
as
much
as
it
can
be.
This
is
a
whole
bunch
of
specific
OCI
stuff,
like
we
have
our
we
have
on
the
the
far
left.
We
have
our
image
name
and
we
have
the
type
of
the
image.
And
then
we
have
you
know
information
about
what
platforms
I'll
run
on
and
we
actually
have
the
total
size
so
and
then
we
can.
A
We
can
just
take
that
this
is
good
old
Redis
Redis
is
the
Redis
runs
everything
works
right,
so
we
can
take
that
and
so
in
container
D
we
use
fully
qualified
image
names,
so
there's
no
kind
of
short
image
names,
and
this
keeps
things
from
being
unambiguous
in
a
lot
of
cases.
So,
but
your
container
runtime
could
implement
your
own
kind
of
image.
Parsing,
the
the
actual
image
naming
format
is
very,
very
simple,
so
just
you
know
running
here,
really
simple
oops.
A
So
there's
there's
a
there's
running
race
and
you
can
see
it's
it's
running
a
few
things
about
this,
so
so
that
so
remember
that
that
starting
a
container
kind
of
data
flow
diagram.
We
did
before.
That's
that's
what
happened
and
I
can
actually
show
you
the
byproducts
of
that.
So
we
can.
We
can
do
a
CT,
our
containers
LS,
and
we
can
see.
Oh
there's
my
test,
one
that
didn't
work
because
I
didn't
have
access
to
create
the
FIFO,
and
then
we
have
our
test
o2.
A
We
can
also
see
we
can
also
take
a
peek
at
the
tasks
that
are
associated
with
that
I
think
they've,
all
exited,
so
they're
not
going
to
show
up,
and
then
we
can
actually
look
at
the
snapshots
that
were
created
as
a
byproduct
of
that.
So
I
can
do
a
snapshot,
LS
and
Wow.
What's
going
on
there,
we
have
more
hashes,
we
can
see.
I
was
playing
around
with
Boo
and
far
bar
and
foo
here
and
then
you
can
see
the
relationships
so
across
the
top
we
can
see.
A
We
have
committed
snapshots
and
these
two
active
snapshots
are
actually
those
are
the
running
container
file
systems.
We
can
actually
take
this
and
we
can.
We
can
look
at
the
relationship
here
and
we
can
see
that
you
know
everything's
descended
from
that
one
Redis
image
and
this
hash
is
slightly
different
than
what
was
up
in
the
images
LS
for
implementation
details,
but
I.
A
A
So
it
I
swear,
kubernetes
is
actually
running
I.
Think
CRI
scuttle
should
work.
So
the
problem
is
the
wife
wet
each
time
you
go
on
the
Wi-Fi,
you
lose
the
IP
address
and
I
need
to
figure
that
out
for
I'll,
have
it
figured
out
by
Friday,
hopefully
but
here's,
but
you
can
see
all
of
the
pods
running
and
I
got
I
got
nginx
deployments,
some
HelloWorld
stuff
and
then
calico
and
a
bunch
of
other
stuff
and
well
I
mean
now
you're
wondering,
though
okay
well,
you
said
it's
running
in
container
D.
Where
are
the
containers?
A
So
they
do.
You
know.
Oh
those
were
just
my
test.
Containers
actually
container
D
is
namespace,
so
all
of
these
containers
are
completely
hidden
from
from
from
the
default
namespace.
So
here's
the
actual
container
D
containers
that
are
implementing
the
pods
inside
of
cry
cuddle.
So
alright
I
think
we're
about
out
of
time
any
questions
on
the
demo
No
all
right.