►
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
Let's Try All the CRI Runtimes: Part 2: Answering the Why Question! - Phil Estes, IBM
In Barcelona, we raced through seven different container runtime setups from Docker to cri-o to containerd--including interesting projects like AWS's Firecracker, Kata containers and gVisor. For each we demonstrated how to allow Kubernetes to use each one of them using either RuntimeClass or standard kubelet CRI configuration parameters and then gave a quick highlight of their feature set, maturity, and usage in the ecosystem. While we successfully demo'd each runtime, we didn't have time to assess each of them with regards to the "why?" question: why would an operator or user choose one of these runtimes? In this "Part 2" talk we will take the time to walk back through each runtime, cover updates to the project since May, look at performance and security characteristics, and answer the why question for each one!
https://sched.co/Uaag
B
Right,
thank
you
very
much
so
yeah
with
that
introduction,
I
guess.
First,
you
know
it's
again
with
the
runtimes
talk
yeah,
so
that
I
kind
of
a
one-trick
pony
I
talk
about
run
times,
because
that's
what
I've
been
working
on
for
about
the
last
five
years
started,
contributing
to
docker
in
2015,
2014,
late,
2014
and
obviously
moved
to
container
D
and
maintainer
there.
So
it's
an
area
of
interest
to
me
and
obviously,
with
kubernetes
and
the
adoption
of
the
CRI,
it
seems
to
be
an
interesting
topic.
People
seem
to
to
be
interested
to
understand.
B
You
know
why
do
these
things
exist?
What
are
the
options?
Why
are
there
options
so
in
Barcelona,
I
gave
this
talk
and
my
goal
was
wouldn't
be
really
cool
to
like
demo,
all
of
them
and
that
just
meant,
like
I
raced
through
like
switching
screens
and
trying
to
get
different
clusters
running
and
it
was
sort
of
like
okay
wow.
So
you
ran
a
bunch
of
containers
and
different
runtimes.
Why
didn't
you
tell
me
like?
What's
good
and
bad,
or
you
know
why
do
these
things
exist?
B
So
I
submitted
this
part
to
talk
where
I
won't
do
a
single
demo.
So
hopefully
that's
not
going
to
be
too
boring,
but
instead
I'll
talk
about
a
little
bit.
Try
and
answer
some
of
those
questions
that
people
asked
at
the
end
of
the
talk
in
Barcelona
and
we'll
see
if
we
can
fit
it
in
because
again
it's
it's
a
lot
of
information.
Here's
a
couple
slides
that
again,
if
you
weren't
in
Barcelona
the
background
was
OCI.
B
The
open
container
initiative
has
brought
us
to
the
place
where
we
have
a
standardized
idea
of
what
a
container
is
from
a
runtime
image
and
now
even
distribution
standpoint
such
that
we
can
have
multiple
registries.
We
can
have
multiple
runtimes
and
we
can
all
agree
what
that
means
on
and
have
interoperability
if
you
add
to
that
the
CRI.
So
kubernetes
has
the
container
runtime
interface.
As
you
can
see,
it's
not
really
a
new
thing
anymore.
B
This
blog
post
from
2016
you
know,
shows
we're
just
now
coming
up
on
three
years
since
the
CRI
came
into
kubernetes
1.5
and
in
kubernetes
container
years,
that's
like
ages
ago.
Hopefully
none
of
you
are
so
running.
Kubernetes
1.5,
if
you
are
there's
a
few
Seavey's,
you
probably
want
to
know
about,
but
again
with
OSI,
I
and
CRI.
We
now
have
this
sort
of
open
playing
field
where,
if
you
implement
the
CRI
and
you
follow
those
the
high
specs,
you
can
be
a
runtime
underneath
kubernetes,
and
so
we
looked
at
this
picture.
B
I've
fixed
it
in
a
few
places
that
I
kept
getting
complaints
that
I
wasn't
showing
all
the
realities
so
below
docker.
You
obviously
still
have
container
D
and
run
C.
So
if
you
say
I'm
running
docker,
you're
also
running
container
D
you're
also
running
run
C
again
we
talked
about
CRI
container
D,
which
drives
container
and
then
run
si
creo.
And
then
we
didn't
talk
as
much
in
Barcelona
about
the
Shem
API
underneath
container
D.
B
But
that's
what
exposes
the
ability
to
have
some
of
these
other
Isolators
like
katha,
firecracker,
G,
visor
and
then
singularity
I,
think
I
mentioned
briefly
in
Barcelona
and
again
we'll
mention
it
briefly
here
and
the
way
if
I.
If
you
were
setting
up
your
own
cluster
and
you
know
doing
Kelcey
Hightower's
kubernetes
the
hard
way
at
some
point.
You'd
come
up
to
this
couplet
you
know,
contain
a
runtime
and
and
runtime
endpoint.
This
is
the
place
where
you
could
say:
here's
my
CRI
I'm
using
docker
I'm
using
container
D,
yummies
and
cRIO.
B
These
other
Isolators
and
again
I
showed
this
in
Barcelona
can
use
runtime
class.
So
again,
we'll
talk
about
that
briefly
or
annotations
as
a
way
to
say:
hey,
Kubla
I
want
you
to
actually
tell
the
CRI
that
this
is
the
runtime
I
want
to
use
and
I
want
to
use
firecracker
as
the
isolator,
so
that's
kind
of
where
we
are.
B
This
report
came
out,
I
think,
just
last
week
or
two
weeks
ago,
from
cystic
and
I,
you
know
I
I,
don't
put
this
up
to
prove
a
point
that
hey
you
know,
docker
one
or
container
d1
or
creo
is,
is
only
4%.
It's
it's
the
fact
that
reality
is
even
with
multiple
choices.
Docker
has
been
kind
of
the
default
for
for
many
years
and
continues
to
be
the
lion's
share
of
usage
in
kubernetes
clusters
for
runtimes.
We
don't
have
a
prior
report.
I,
don't
think
Cystic
had
this
kind
of
data
in
the
prior
report.
B
So
it's
hard
to
say
who's
growing
and
who's
who's
diminishing,
but
obviously,
in
the
years
future
we
can
kind
of
look
at
the
trends,
but
really
again.
The
the
the
interesting
fact
here
is
that
that
docker
is
still
running
the
lion's
share
of
clusters
out
there.
Obviously
container
D
has
been
sort
of
production-ready
for
just
a
year
or
two,
and
so
we're
seeing
growth
there
and
then
creo
also
being
used
in
OpenShift
and
and
if
you
read
the
report,
they
expect
that
number
to
grow
as
OpenShift
installations
switch
from
docker
to
creo.
B
For
example,
an
open
shift
for
and
rail
8
that'll
be
the
default
the
default.
So
let's
walk
through
kind
of
these
three
main
choices.
When
again
before
we
talk
about
sandboxes
and
special
Isolators.
Let's
just
look
at
these
three
main
runtimes,
so
you
know,
there's
not
a
whole
lot
to
say
here.
If
you've
been
around
this
community,
you
know
what
docker
is
it's
the
runtime
that
kind
of
started
this
whole
thing.
B
B
Maybe
some
of
you
use
that,
but
docker
again
has
been
kind
of
the
default
and
the
de
facto
standard
docker
itself
is
is
multiple
things,
and
obviously
many
of
you
have
probably
heard
the
news
in
the
last
week
or
two
that
the
enterprise
part
of
this
suite,
if
you
want
to
think
of
it
as
that
has
been
sold
to
moranto.
So
obviously
the
future
will
tell
kind
of
where
that
path
goes
in
the
future.
But
docker
seee
remains
with
docker
based
on
the
mobi
project.
B
So
you've
got
the
you
know
the
Claudia
daemon
build
container
D
run
C
notary.
Some
of
these
are
CMC,
F,
contributed
projects
and
an
enterprise
added
a
bunch
of
things
around
that,
including
a
kubernetes
distribution.
In
addition
to
swarm,
and
then
docker
desktop,
you
know
gave
you
this
in
recent
year
as
a
single
node
kind
of
kubernetes
setup,
as
well
as
swarm
on
Mac
and
Windows.
So
again,
why?
Why
would
you
use
docker?
Obviously
many
tools
and
deployers
are
still
defaulting
to
docker.
B
It
does
have
some
value
in
in
a
cluster
where
you
kind
of
have
a
mixed
use
of
your
nodes,
where
you
expect
other
tools
are
expecting
either
the
docker
API
socket
or
expecting
docker
commands
to
just
work.
You
shouldn't
be
relying
on
this,
but
you
know
again
in
cluster,
build
has
been
relying
on
the
API
socket.
B
There
are
solutions
to
this,
which
is
why
I'm
saying
you
really
shouldn't
be
relying
on
this
in
2019
with
projects
like
Tecton
and
others,
but
again
there's
there
was
a
simplification
here
that
many
people
relied
on
and
made
it
simple.
If
docker
is
your
it,
your
runtime
underneath
kubernetes,
that
means
you
can
also
use
the
docker
api
people
were
mounting
it
as
a
volume
mount
inside
a
container.
You
get
easy
access
to
docker
commands,
which
also
means
you
give
easy
access
to
hackers.
B
To
then
do
anything
they
want
on
your
node,
which
is
the
reason
you
shouldn't.
Do
that
but
again
say
we're
a
docker
enterprise
customer,
obviously
docker
as
a
choice
for
your
cluster
gave
you
support
from
docker
now
mer
Antos
and
gave
you
no
fur
for
a
subset
of
users
who
wanted
this
idea.
I
can
choose
swarm
or
I
can
choose
kubernetes.
You've
got
that
so
again,
there's
challenges
here,
but
you
know,
let's
just
be
real.
The
docker
engine
is
a
time-tested
production
deployed.
B
Runtime,
that's
been,
you
know
when
you
see
huge
numbers
being
shown
on
the
the
keynote
stage.
Most
likely,
the
docker
engine
is
involved
in
those
massive
clusters
that
are
doing
very
interesting
things,
container
D
container
d.
Many
of
you
probably
are
aware-
and
you
heard
from
the
intro-
you
know
just
to
admit-
I-
have
a
bias.
I've
been
part
of
the
container
D
project.
Since
it
was
created,
it
was
donated
to
the
CN
CF
in
early
2017
by
docker
and
effectively.
B
You
know
I
do
not
have
time
to
walk
you
through
this
beautiful
architecture
picture
that
derek
has
put
together,
which
the
teaser
is
tomorrow,
we're
having
our
mini
summit
for
container
D
here
at
coop
con
and
we'll
walk
through
this
architecture.
Go
through.
You
know
these
components
but
effectively
there's
a
set
of
ways
to
drive
container
D,
most
likely
through
an
API
through
the
CRI,
if
you're
using
it
underneath
kubernetes
that
drives
a
set
of
distinctive
services
like
content,
image
store,
namespaces,
etc.
B
B
So
I
won't
read
everything
on
this
chart.
Adoption
I
think
has
been
interesting.
We
use
it
an
IBM
cloud
for
our
managed
kubernetes
offering
google
has
ax
as
an
option
in
GAE.
So
if
you're
creating
a
new
cluster
creating
node
pools,
you
can
select
the
container
D
image
and
use
container
D
as
your
image
as
your
engine.
Although
I
believe,
if
you
don't
make
a
choice,
you
end
up
still
with
docker
Alibaba
public
cloud
is
also
using
container
D.
They
have
a
project
called
pouch
which
also
heavily
uses
container,
D
and
I.
B
Think
the
value
of
that
architecture
that
we
didn't
get
to
talk
about
is
we've
gotten
feedback
that
it
has
a
very
clean,
API
and
extends
extension
points.
There
was
a
great
talk
from
some
of
the
AWS
firecracker
folks
yesterday
on
some
of
the
ways
that
they've
used
those
extension
points,
but
that's
led
to
a
lot
of
different
uses
and
and
extensions.
B
Some
of
them
are
listed
here,
k3s
from
Rancher
from
Darren
Shepherd
uses
container
D,
the
new
Azure
teleport
feature
uses
the
container
D
snapshot
or
there's
a
great
blog
post
on
that.
So
again,
the
extensibility
and
and
to
extend
container
D
has
been
I.
Think
one
of
the
the
big
values
of
why
people
have
chosen
container
D,
both
with
container
D
and
creo,
because
the
engine
is
simpler
and
smaller.
You
end
up
with
lower
memory.
Cpu
footprint
and
we've
had
a
big
focus
on
stability
and
performance
in
container
D.
B
The
other
things
we've
done
in
container
D
I
think
have
been
valuable
and
a
reason
why
some
people
are
choosing
it.
We
have
clear
sort
of
support
terms
for
our
releases,
so
we're
back
porting
fixes.
We
have
very
clear
release
structures
how
things
get
back
ported
when
they're
back
ported
there's
also
a
significant
sort
of
by
default,
hardening
and
testing
that
happens
just
by
nature
of
every
docker
installation
also
uses
container
D.
B
So
again,
the
azure
teleport
google
has
a
project
called
c
RFS
and
we're
working
with
cern
on
their
c
VMFS
to
allow
you
to
basically
pre
populate
layers
across
a
cluster
and
then,
instead
of
pulling
from
a
registry
automatically
using
those.
So
again,
these
are.
These
are
values
that
are
in
container
D
because
of
the
design
and
because
of
the
way
the
API
was
put
together
for
extensibility.
B
So
let's
talk
about
creo,
you've
already
missed
it,
but
there
was
an
intro
to
creo
yesterday
from
runo
and
one
of
his
colleagues.
This
was
the
chart
when
we,
you
can
already
get
the
slides
from
from
sked,
but
obviously
there'll
be
a
video
available
as
well
of
the
intro
talk
again,
I.
Think
the
the
main
point
about
Krios
architecture
is
that
there's
a
couple
libraries
you
can
go,
look
at
them
on
github,
so
containers,
slash
image
and
container
slash
storage.
B
These
are
implementations
of
the
storage
back-end,
so
think
of
that,
like
container
these
snapshot
and
container
slash
image
being
that
representation
of
an
OCI
image
and
the
API
around
that
and
so
cRIO
is
built
over
run,
see
with
these
two
kind
of
standardized
libraries
and
a
set
of
services
that
obviously
work
with
kubernetes
and
the
CRI
to
give
you
a
purely
kind
of
OCI
based
engine,
hence
the
name
cRIO
so
directly
supporting
the
OCI
specs.
That
was
one
of
their
design
points,
starting
at
these
two
shared
libraries,
which
again
containers
image
and
container
storage.
B
Given
they
kind
of
standardize
around
this,
their
tools
build
a
scope.
Eo
pod
man
can
actually
utilize
the
same
store
as
creo
as
a
kubernetes
runtime,
and
so
therefore,
you
get
sort
of
these
suite
of
tools
that
all
work
together
and
and
have
sort
of
the
same
on
disk
representation
of
these
pieces,
obviously
used
in
Red
Hat's
OpenShift
sousei
also
has
their
containers
of
service
using
creo.
B
B
The
next
part
is,
is
really
you
know
once
once.
You've
obviously
made
a
choice
about
a
general
kind
of
Linux
container
runtime
there's
this
whole
aspect
that
that
you've
probably
heard
about
where
people
are
saying.
Well,
you
know
what
about
multi-tenancy
use
cases,
serverless
use
cases
and
I
want
more
isolation
than
just
Linux,
C
groups
and
namespaces,
and
so
in
kubernetes
112
runtime
class
was
introduced.
There
had
been.
Maybe
you
know
there
was
the
untrusted
flag
for
for
a
pods
back
and
earlier
kubernetes
releases.
B
This
kind
of
replaced
that
to
say
I
can
now
register
runtimes
in
my
cluster
and
then
in
a
pods
back.
I
can
I
can
specify
that
this
pod
should
use
this
runtime
class
and
the
CRI
implementing
runtime
should
be
able
to
map
that
to
an
actual
shim
or
binary
that
it
wants
to
run
and
so
I
demoed
that
in
in
Barcelona,
using
firecrackers,
Jim
and
cat
Ashim
and
G
visor
so
again,
just
to
kind
of
set
the
stage
Annabel
just
tweeted
this
out,
I
think
over
the
weekend
or
I
guess
it
was
on
day
zero.
B
The
cloud
native
security
day,
I
wasn't
here
yet,
but
Ian
coldwater
said
if
you're
not
doing
container
isolations,
it's
important
to
know
what
can
happen
if
someone
compromises
that
container
and
then
Annabelle
kind
of
addenda,
with
no
time
like
the
present
to
go,
look
at
G,
visor
and
kind
of
container.
So
again,
there's
there's
significant
increased
interest
in
these
additional
Isolators
and
sandboxes
again.
I'm
no
expert
here
there
are
experts
here
at
the
conference,
but
it
was
an
area
of
interest
to
me.
B
So
I
did
a
little
bit
of
reading
and
research
and
wrote
this
in
fuck-you
article
that
got
published
a
few
months
ago.
Just
talking
about
this
kind
of
new
marriage
of
hypervisors
and
containers,
and
so
out
of
that
you
know,
I
drew
this
picture
to
kind
of
help.
Think
through
and
I
have
a
feeling
in
the
back
of
this
room.
B
Some
of
that
may
not
be
so
readable,
but
it's
part
of
the
article
that
you
can
easily
find
an
info
queue
to
help
think
through
why
someone
would
care
about
adding
this
extra
layer
of
isolation,
and
so,
if
you
think
about
sort
of
standardized
containers,
there
are
a
set
of
tools
that
you
can
use
to
kind
of
significantly
reduce
that
attack
surface
of
your
container.
You
can
you
automatically
get
an
app
armor
profile
with
docker,
but
you
could
create
your
own
and
do
more
restrictions.
B
You
get
a
set
comm
profile
with
the
docker
run
time
and
with
container
D,
but
you
could
restrict
it
further.
You
can
in
fact
some
people
are
starting
to
create
some
interesting
tools
to
help
create
SATCOM
profiles
based
on
running
your
application
and
and
trapping
syscalls
there's
Linux
capabilities
that
are
already
reduced,
some
just
by
nature
of
using
a
container
runtime,
but
you
can
reduce
that
further.
You
can
do
that
in
kubernetes
and
a
pod
step
pod
spec.
By
dropping
further
capabilities.
B
You
can
do
that
with
the
docker
client
or
the
other
runtimes,
and
then
obviously
there's
namespaces
and
C
groups,
so
you
can
reduce
you
can
restrict
CPU
utilization.
You
can
strict
memory
use,
so
these
are
kind
of
the
knobs
that
we've
had
for
just
pure
Linux
containers,
but
we're
still
running
on
that
host
kernel
and
there's
still
this
syscall
interface,
that
even
if
we
restrict
it
to
some
degree,
it's
still
exposed
even
from
within
a
container
and
as
the
in
cold
water
said.
B
You
know,
we
don't
know
what
future
escapes
CVS
etcetera
may
exist
in
that
space,
and
so
we're
left
potentially
with
exploits
that
that
even
can
get
out
of
these
layers
of
our
sort
of
defense
and
depth
strategy.
So
by
adding
in
this
case
you
know
on
the
right
side,
I'm
showing
like
a
V,
then
now
you
have
a
kernel
that
firecracker
is
inserted
or
cata
containers
as
inserted.
The
now
this
is
called
boundary,
for
your
container
is
only
for
your
container.
B
What
and
why
for
each
of
these,
this
is
a
picture
that
Eric
Ernst
provided
just
recently
I
think
Eric's
here
somewhere
and
and
can
tell
you
all
about
counter
containers
that
I
can't
tell
you
about.
But
again,
their
architecture
is
again
using
a
shim
underneath
container
D
that
can
drive
the
qmu
based
hypervisor.
They
also
have
support
for
fire
cracker
as
a
back-end
as
well.
B
The
background
of
the
project,
some
of
you
may
or
may
not
know,
Intel
clear
containers
of
hyper
SH
where
the
predecessors
they've
now
joined
forces
together
under
the
cat,
a
name
I
already
mentioned.
They
have
cue
as
a
default,
but
also
added
support
for
firecracker
last
fall.
They
can
work
with
dr.
creo
and
container
D
and
support
kind
of
a
general-purpose
kubernetes
use
case.
B
They
have
great,
you
know,
Doc's
getting
started
that
can
help
you
try
that
out
and
governance
there
under
the
OpenStack
foundation
and
have
multi
architecture
support
very
interestingly
by
two-by-twos
cloud,
released
an
interesting
white
paper
that
has
tons
of
details
about
their
use
of
cata.
That
is
a
great
read,
and
this
is
a
medium
post
that
has
links
to
the
white
paper
and
also
gives
you
some
of
the
contacts
for
that.
So
again,
why
would
you
choose
cata?
B
If
you
have
this
desire
for
additional
isolation
than
just
the
pure
Linux
container
primitives,
you
prefer
hypervisor
of
a
hypervisor
based
versus
like
the
G
Weiser
model,
which
we'll
talk
about
in
a
second.
If
you
need
broad
multi
architecture,
support
kind
of
has
that
and
there's
fewer
restrictions
out
of
the
box
than
the
way
fire
cracker
is
set
up,
because
fire
cracker
has
a
narrower
focus
again.
Aws
created
it
more
focused
on
the
lambda
use
case
versus
katas,
more
general-purpose
use
case,
alright.
So
moving
along.
Let's
talk
about
fire
cracker.
B
B
They
have
created
a
snapshot,
ER
implementation
that
they
contributed
to
container
D,
dev
mapper
so
using
the
device
mapper
for
storage,
and
so
that
can
be
used
by
both
fire
crackers
shim,
as
well
as
cata,
also
as
a
way
to
use
the
new
device,
mapper
snapshot
or
within
container
D.
So
again,
one
of
the
attractions
of
firecracker
is
the
idea
that
the
vmm
was
written
in
rust,
originating
from
a
google
project.
B
It
does
have
a
very
narrow
focus
around
the
lamda
use
case,
so
there
are
certain
restrictions
that
they
accepted
for
firecracker
because
it
fits
their
model.
You
can
use
it
standalone
or
they
have
written
a
shim
for
container
D
and,
as
I,
also
have
this
idea
of
a
jailer,
adding
C
group
and
set
com
restrictions
on
their
vmm,
which
runs
on
top
of
that.
B
Interestingly,
since
Barcelona
there
have
been
a
few
projects
that
have
wrapped
firecracker
with
some
additional
capability,
so
we've
works
has
ignite
and
then
more
recently
the
fire
cube
project,
and
so
this
is
again
kind
of
this.
Marriage
of
I
want
container
like
youth
use
model,
but
I
want
hypervisors
of
vm's
in
the
background,
and
so
those
are
two
interesting
projects
to
go.
Look
at
if
you're
interested.
So
why
would
you
choose
firecracker
if
that
narrow
use
case
and
that
use
model
fits
what
you're
looking
for?
And
you
don't
need
the
general
purpose
container
use
case.
B
So,
for
example,
volume
mounts,
don't
work
and
the
way
firecracker
is
set
up
today,
maybe
you're
attracted
to
the
security
promises
of
the
rough
space.
Vmm
or
maybe
you
know
this
ignite
and
fire
cube.
These
projects
are
of
interest
to
you
all
right,
so
G
Weiser,
so
Ian
gave
a
talk
over
the
weekend
at
cloud
native
rejects,
and
so
he
shared
this
diagram
with
me.
I
also
have
a
link
to
his
entire
talk
about
running
an
untrusted
code
in
kubernetes,
so
the
architecture
of
G
Weiser
is
different
because
we're
not
talking
about
hyper-v
lightly.
B
Hypervisor
isolation
at
this
point
they
have
sentry,
which
is
basically
a
a
set
of
Linux
system,
calls
implemented
in
userspace
written
and
go
it's
joined
by
another
architecture.
Piece
called
gopher
which
handles
the
file
system,
access
and
so
Google
is
using
gee,
visor
and
Google
cloud
run.
There's
a
lot
of
great
information
online
about
how
they're
using
gee
visor
for
that.
For
again
this
increased
isolation
and
security
boundary
you
can
use
it
as
a
run
sirrah
plate
replacement,
so
they
have
a
run
SC.
B
They
also
have
a
shim
implementation
again
that
I
used
to
demonstrate
running
G
visor,
underneath
container
D
in
Barcelona
sentry
doesn't
implement
every
system
call
out
there
and
it
also
by
default,
intercepts
sis
calls
via
P
trace,
which
has
some
performance
impact,
although
they
are,
they
have
an
experimental,
KVM
based
method
as
well.
That
gains
some
of
that
back.
B
Again,
the
interest
the
draw
here
for
G
visor-
maybe
the
the
hypervisor
model-
isn't
necessarily
of
interest
to
you,
but
this
idea
that
that
your
system
calls
from
your
container
aren't
going
through
your
host
kernel
but
going
against
G
visors
implementations,
again
you're
going
to
have
to
accept
that
there's
some
limited
functionality
there.
They
did
put
out
a
blog
post
several
months
ago,
just
showing
some
of
the
additions
they
made
in
the
in
the
first
year
of
G
visor.
B
So
again,
this
is
an
obvious
alternative
to
the
hypervisor
model
and
has
less
management
so
again,
you're
not
going
to
have
a
custom
kernel
being
inserted
and
booted,
and
you
don't
have
some
of
the
agents
involved
in
the
other
model,
so
two
final
pieces
in
the
last
few
minutes,
I
talked
briefly
about
nabla.
This
is
a
open
source
project.
The
IBM
Research
created
it's
based
around
Yoona
kernels
on
top
of
a
very
highly
restricted
set
count
profile,
so
they
again
the
eunuch
er.
B
No,
that
is
booted
running
your
container
has
very
limited
access
to
the
host
kernel.
The
big
limitation
is
that
nabla
forces
you
to
rebuild
a
lot
of
your
container
images
against
a
special
set
of
basis
that
the
nabla
team
created
they'd
love
to
remove
that
limitation.
But
for
now
that
makes
it
very
hard
to
to
really
have
adoption,
because
you
can't
just
point
to
an
image
on
docker
hub
and
expect
it
to
work
with
nabla
and
then
singularity
I
mentioned
because
in
the
last
year
they
did
implement
both
OC
I
support
and
implemented.
B
A
CRI
I
think
it
would
have
been
awesome
if
they
had
made
just
a
shim
using
the
shim
API
for
container
D.
Would
it
kept
them
from
having
to
implement
the
whole
CRI?
But
if
you
haven't
heard
of
singularity
it's
an
HPC
focused
runtime
focused
on
the
academic
research
community,
not
demon
based.
So
again,
if
you
know
anything
about
HPC
clusters,
it
works
a
lot
better
with
some
of
the
workload
orchestrators
they
already
have
in
that
world
and
they
also
have
their
an
image
format
called
SIF
and
again
there
again,
if
you're
in
that
space.
B
You've
probably
heard
of
them,
if
not
you,
you
probably
haven't
so
in
summary,
the
creation
of
OCI,
the
fact
that
we
now
all
agree
on
what
an
images
on
the
runtime
spec
on
distribution.
We
have
this
comment
under
underpinning
that
allows
for
people
to
innovate
in
the
space,
but
yet
we
all
have
interoperability,
we're
not
using
a
different
registry
for
COD
on
a
different
registry
for
firecracker
or
different
register
for
creo.
So
that's
the
goodness
we
have
today.
B
Cri
then
allows
kubernetes
the
plug
ability
for
container
runtimes
and
really
you
know,
we
continue
to
see
options
growing
in
the
space
lots
of
innovation
around
this,
the
sandbox
idea
with
G
Weiser,
cata,
firecracker
and
others,
and
really
it's
up
to
you.
You
know
I
I
can't
tell
you
that
you
absolutely
should
use
docker
or
container
to
York
Rio
or
you
should
enable
cata.
You
know,
based
on
your
threat
model,
your
use
case,
what
you're
building
you
know.
C
Hey
guys
going
to
quick
ones,
it
seems
like
the
term.
Runtime
is
a
little
overloaded,
docker
container
dear
uncie.
Do
you
have
a
way
of
D,
conflicting
those
and
then
the
other
one
is
just
with
container
D
and
Dockers
and
say
both
use
container
D,
maybe
I
mean
you
said
it,
but
maybe
I
missed
it.
Why
would
I
use
one
versus
the
other
yeah.
B
So
so
I'm
horrible
and
did
mystifying
the
idea
of
Renta
I
mean
I.
There's
some
blog
posts
out
there
that
tried
to
say
we
should
call
one
thing:
an
engine
and
one
thing:
a
runtime
I've
been
very
nonspecific
I.
Think
the
term
we're
gonna
use
tomorrow
in
the
container
D
summit
is
like
low-level
runtime
and
sort
of
high-level
runtime
I,
don't
know
if
that
helps
at
all.
B
To
your
your
second
point,
what
you're
missing
with
container
D
container
D
is
really
made
for
embedding
in
a
system
like
kubernetes,
so
all
the
developer
workflow
around
docker
build.
You
know,
docker
push
some
of
these
exist
in
our
kind
of
CTR
tool,
but
CTR
is
not
meant
to
be
kind
of
a
full-featured
developer
environment.
So
that's
really
where
docker
comes
into
play,
you
know
and
again
all
the
suite
of
things
around
that
weather,
urine,
dachshund,
compose
or
or
other
pieces
of
that
ecosystem.
B
B
B
Yeah
I
I
think
from
my
understanding.
The
existence
of
containers,
image,
container
storage
lid
pot
is
so
there's
not
duplicated
code
across
both
the
developer
tools,
as
well
as
the
runtime
cRIO
I.
Don't
know
if
that
is
that
clear,
yep
all
right
well,
I
will
I'm
willing
to
hang
out
here
for
a
little
bit
but
I
think
we're
over
time.
So
thanks
very
much
for
coming.