►
Description
CNI, CRI, and OCI - Oh My! [I] - Elsie Phillips & Paul Burt, CoreOS
If you work with containers, it’s easy to get lost in the emerging standards and foundations. You might have questions like:
What is OCI? What happened to appc? Do I need to do anything to take advantage? Don’t we already have container runtimes? So, why do we need CRI? Similarly, what’s the use of CNI with all of the container networking solutions already out there?
Our aim is to answer all of these questions, and showcase places you can find (and use!) each of them. We’ll discuss how these specs affect you when using Kubernetes or other container orchestrated projects. Kubernetes will serve as a handy vehicle for some short, live demos. We’ll explore how each standard is improving our lives today, and what kinds of innovation they open up for the future.
About Paul Burt
Paul Burt is a Community Manager at CoreOS. He’s upvoting your /r/kubernetes threads and answering your #coreos questions on freeNode. Paul has a knack for and demystifying infrastructure, and making gnarly, complex topics approachable. He enjoys home brewing beer, reading independent comics, and yelling at his computer when it doesn’t do what he wants.
About Elsie Phillips
Elsie herds the CoreOS Community and Co-Leads the Kubernetes Contributor Experience SIG. She's a northwest native who got her start in open source working at the Oregon State University Open Source Lab. In her free time she throws wild one woman dance parties and makes a mean vegan chocolate chip cookie.
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
Welcome
to
the
talk
on
container
standards,
we're
gonna
talk
about
CNI,
CRI
and
OCIO.
My
the
slides
for
this
deck
are
available
at
this
URL
here,
so
snap
a
photo
of
it.
If
you
don't
have
your
phone
out
right
now,
we'll
be
showing
that
URL
and
a
couple
slides
again
just
so
you
can
capture
it.
There'll
be
a
lot
of
references
to
external
content
that
does
more
of
a
deep
dive
into
each
of
these
standards.
So
should
be
handy
for
that
context.
A
I've
also
linked
to
it
on
the
schedule
for
the
cube
con
talk,
and
so
we
did
it
out,
so
you
can
get
it
in
other
avenues
as
well
cool,
so,
first
off
who
are
we?
How
do
we
have
any
authority
to
talk
about
these
things?
Well,
we
work
at
core
OS,
where
a
lot
of
these
standards
got
a
lot
of
attention,
so
I'm
Paul
Bert.
This
is
my
associate
LC
Phillips
and
we
work
on
the
community
side
of
things
for
core
OS.
So
we're
answering
technical
questions.
A
Matching
you
with
our
technical
people.
If
you're
coming
in
the
door,
answering
questions
on
kubernetes
stack,
overflow,
IRC.
That
sort
of
thing
so
you've
probably
seen
us
floating
around,
and
this
talk
is
explicitly
about
standards
and
containers,
so
we're
gonna
try
and
cover
both
of
those
angles,
and
you
know
Before
we
jump
into
it.
We
should
kind
of
get
on
the
same
page,
I
think
about
both
of
those
things,
so
we're
gonna
do
kind
of
a
brief
dive.
So
we're
all
talking
the
same
language
here
when
we
talk
about
standards.
A
So
what
is
a
standard,
something
those
ISO
folks
make
was
the
short
answer.
The
long
answer
is
that
ISO
is
actually
somewhat
poetic
when
it
comes
to
standards,
the
name
of
the
ISO
organization.
Actually,
doesn't
it's
not
an
acronym?
It
doesn't
stand
for
anything
because
they
realized
that
being
in
the
international
standards
organization
in
English
versus
the
IO
n
in
French
I'm,
not
even
gonna,
try
and
butcher.
The
French
was
somewhat
weird,
so
they
chose
a
Greek
word
ISO,
which
means
equality
as
they're
kind
of
stand-in.
A
So
it
means
the
same
thing
in
any
language
and
that
kind
of
gets
to
the
heart
of
what
we're
shooting.
For
when
we
go
for
a
standard,
we
want
everybody
to
speak
in
the
same
language,
so
we
can
look
at
a
standard.
We
know
which
is
JavaScript
on
you
might
think
like.
Why
would
you
use
JavaScript
and
that's
a
good
question,
but
bear
with
me
so
if
we
go
back
to
the
dark
days
of
the
web
like
1996
or
so,
this
was
the
state
of
the
art.
A
This
was
Yahoo
around
Christmas
time
and
when
we
wanted
to
develop
webpages,
we
were
developing
in
jscript,
JavaScript
ActionScript
and
a
new
thing
called
dhtml,
dynamic
HTML,
which
means
for
any
web
application
that
we're
developing
we're
developing
in
four
different
languages
potentially,
but
all
four
of
those
languages
are
really
doing
the
same
thing,
so
that's
kind
of
a
pain
in
the
butt
and
that's
where
JavaScript
came
from
it
came
from
that
world.
So
you
may
hate
j/s
now,
but
you
know
you
could
hate
it
a
lot
more
than
you
currently
do.
A
If
you
had
to
write
the
same
JavaScript,
five
or
six
different
times
for
every
browser
that
you're
supporting.
So
that
is
a
lot
of
the
history
and
the
context
supporting
a
lot
of
these
standards
is.
There
are
a
lot
of
different
flavors
of
containers
floating
around
a
lot
more
than
a
lot
more
existed
way
before
docker
and
doctor
really
popularized
it
and
did
a
great
job
of
disseminating
it
to
the
masses.
A
So
we
want
to
support
that
whole
ecosystem
and
allow
that
ecosystem
to
grow
and
thrive,
so
that
that
is
what
the
standard
does,
and
you
know
with
javascript
in
particular,
while
not
everyone
is
the
biggest
fan
of
it.
I
think
a
lot
of
people
are
fans
of
things
like
JSON
a
JWT.
There
are
a
lot
of
follow-on
standards
that
have
been
built
on
top
of
java
scripts
that
have
thrived
and
really
made
a
big
difference
in
our
lives.
So
one
example
of
this
in
the
container
space
they
may
not
be
aware
of
is
frac
T.
A
Its
goal
is,
to
kind
of
you
know,
allow
virtual
machines
to
plug
in
as
a
runtime,
potentially
there's
another
one
announced
during
this
conference
called
cotta
containers
I
believe
also
incredibly
cool
same
sort
of
mindset.
So
these
are
the
things
that
we
want
to
support
without
bending
over
backwards,
Andrey
architecting
everything
you
know
from
the
start.
A
Cool,
so
what's
the
container,
so
this
will
go
pretty
quickly.
I
just
want
to
make
sure
we're
on
the
same
page
when
we
say
container,
because
it
does
mean
a
lot
of
things
to
a
lot
of
different
people
and
essentially
a
container
is
just
a
tar
file.
It's
a
bundle
of
files.
So
if
you're,
not
a
Linux
user,
it's
more
akin
to
like
a
zip
file,
so
we've
all
messed
with
those
in
the
old
heyday
of
mp3s.
A
That
sort
of
thing
bundling
stuff
up
and
win
rare
and
sharing
it
with
our
friends
that
sort
of
stuff.
That
is
what
we're
working
at
when
we're
working
with
a
container
but
we're
specifically
working
with
tar
files.
Plus
these
kind
of
low-level
Linux
system
calls
they
either
restrict
to
the
usage
of
the
the
tar
file.
A
What
resources
can
access
or
it
isolates
it
in
a
nice
way
that
allows
the
tar
file
to
play
nicely
with
other
stuff
on
the
system,
so
I'm
using
node
4.0
and
my
production
system
is
using
the
latest
version
of
nodejs
I.
Don't
have
to
worry
about
any
headaches
that
come
from
me
deploying
my
app
to
that
environment.
Those
two
versions
of
node
never
talk
to
each
other,
which
is
quite
nice,
so
containers
are
Linux.
A
Magic
is
the
way
I
like
to
sum
up
all
those
things
and
if
you're
curious
about
more
the
technical
details
behind
those
Linux
system
calls
and
just
what
a
container
is.
There's
a
blog
post
by
colleague
of
mine
from
core
OS
containers
from
scratch
and
Brian.
Redbeard
also
has
a
great
talk
on
building
minimal
containers
from
scratch,
which
really
gets
you
into
the
meat
of
what
a
container
is.
A
Cool,
so
why
containers?
Why
do
we
all
use
containers?
Well,
we
use
it
because
he'll
is
other
people's
development
environments.
So
this
is
this
I
think
is
my
favorite
reason
for
containers
they're
a
lot
for
them,
but
the
isolation
I
think
is
one
of
the
biggest
reasons
we're
in
this
world.
So
that's
a
theme
that
will
pop
up
in
a
lot
of
these
standards
that
we
talk
about.
A
Cool
so
we're
onto
the
meat.
Now
what
is
CNI
the
container
network
interface,
so
the
container
network
interface
is
a
project
that
was
started
by
core
OS
way
back
when
it's,
you
know
rapidly
approaching
version
1.0
now
and
if
we
want
to
know
what
the
goal
of
the
project
really
is
well
just
to
zoom
in
on
the
readme
page
on
github
here
on,
says:
CNI
concerns
itself
only
with
network
connectivity
of
containers
and
removing
allocated
resource
when
the
container
is
deleted.
A
So,
in
a
nutshell,
what
this
is
saying
is
CNI
is
an
API
that
basically
has
two
calls.
It
has
an
ad
and
a
delete,
and
that's
it.
It's
very
simple:
there's
actually
a
third
call
for
version,
but
you're,
probably
not
gonna,
call
that
too
often
and
the
context
that
CNI
emerge
from
was
docker
was
dominant
and
there
wasn't
any
real
standard
other
than
just
do
it.
A
The
docker
way
so
see
and
I
eventually
pressured
the
other
side
enough
that
CNM
emerged
and,
if
you're
looking
for
like
a
good
kind
of
evaluation
of
what
these
two
standards
are,
how
CNI
differs
from
CNM
I
think
the
new
stack
has
a
really
great
piece
on
this
which
dives
into
it.
But
the
choice
quote
for
you
all
today
is
that
both
of
them
are
really
they
try
to
accomplish
the
same
thing.
A
Their
driver
based
plug-in
based
they're
great
for
creating
and
managing
network
stacks
for
containers,
but
the
real
wart
on
CNM
is
that
it's
designed
to
only
support
docker
and
that's
not
great,
especially
if
your
kubernetes
user,
like
we
said
before
we
want
you,
know
multiple
products
to
be
able
to
thrive.
The
same
way.
The
web
supports
multiple
browsers,
so
this
was
echoed
on
the
kubernetes
blog.
A
You
know
in
this
post
from
January
2016
and
they
say
that
kubernetes
is
system
that
supports
multiple
containers,
runtime
of
witchdoctors,
just
one
and
eventually
CNI,
one
so
see
and
I
has
been
adopted
by
the
CN
CF.
As
you
know,
its
tenth
project
in
the
organization
that
happens
sometime
this
year
and
how's
it
work.
What
does
it
do
so?
We
mentioned
those
two
calls
the
add
and
delete.
Those
are
the
two
really
important
ones.
So,
a
quick
visual
of
just
what
a
CNI
plugin
is
at
its
base.
It's
really
just
an
executable.
A
That
does
something
and
it
responds
to
those
two
calls.
So
what
happens
when
a
container
fires
up
the
runtime
has
to
create
a
network
namespace
first
and
then,
after
that
network
namespace
is
created.
The
runtime
reads:
a
JSON
config
for
the
network,
information
that
it
wants
to
stuff
in
there
and
I
config
I
will
contain
a
name
of
an
executable
that
it
wants
to
run
maybe
many
executables
and
it
will
execute
a
plug-in
with
that
name.
Calling
the
add
command.
A
That
plug-in
then
has
the
responsibility
of
reading
from
that
same
JSON
type
file,
it'll
read
it
from
standard
in
can
I
do
its
magic,
whatever.
That
is
that's.
That
means
usually
setting
something
up
in
the
network
namespace
internally
in
the
container
and
then
connecting
that
to
the
outside
world
as
well
doing
whatever
it
needs
on
the
host
system.
A
If
there's
an
error,
then
the
runtime
will
just
tell
the
plug-in
to
delete
the
operation
right
there.
So
it'll
safely
remove
what
it
was
trying
to
do,
but
otherwise,
if
everything
ran
normally,
when
the
container
reaches
the
end
of
its
life
cycle,
it'll
call
the
delete
operation.
Then
so
part
of
the
spec
is
for
every
ad
that
you're
doing
there's
a
corresponding
delete
to
remove
the
work
and
that's
it.
A
It
may
seem
like
I'm
oversimplifying
things,
but
it
really
is
that
simple,
you
can
check
the
CNI
github
page
and
the
spec
I
think
is
highly
readable.
I
am
NOT
a
developer
by
trade.
I
am
sort
of
I
play
a
developer
on
TV
sort
of
thing,
so
I
I
found
it
highly
readable
and
highly
approachable.
Someone
who
messes
around
with
today
day
to
day,
have
my
own
toy
kubernetes
cluster,
but
I'm
not
like
hardcore
in
the
guts
of
kubernetes
maintenance,
and
this
is
an
example
of
what
a
configuration
file
would
look
like
for
the
bridge.
A
A
What's
happened
in
the
CNI
space,
that's
benefiting
us!
Well,
we
got
ipv6
support
this
year.
Plug-In
chaining
is
a
thing
plug-in.
Chaining
basically
just
says
if
I
am
calling
a
plug-in
and
it
adds
successfully,
maybe
I
want
to
pass
the
successful
results
from
that
plug-in
to
the
next
plug-in
down
the
line.
Maybe
something
relies
on
that
action?
That's
happening.
So
that's
a
nice
gimme
and
then
we
also
got
port
forwarding.
But
really
the
big
thing
for
CNI
is
CNI
is
everywhere
it's
kind
of
hard
not
to
use
CNI.
A
At
this
point,
like
there's
a
flag,
you
can
disable
on
your
cubelet
when
you're
running
kubernetes,
but
really,
if
you're,
using
any
kind
of
networking
plug-in
these
days,
you're,
probably
using
CNI,
there's
a
good
chance.
So
it's
it's
really
taken
off
and
it's
rapidly
approaching
1.0,
but
there's
always
room
for
improvement
beyond
1.0.
So
if
you
want
to
get
your
foot
in
the
door
before
1.0,
they're
always
looking
for
contributors
and
vice
versa,
if
you
have
grand
ideas
for
how
to
improve
things,
I
know
they'd
love
to
hear
him.
A
Alright,
this
is
the
kubernetes
one,
the
CRI
it's
Hana,
runtime
interface
and
just
out
of
curiosity.
How
many
folks
here
have
like
worked
directly
on
c
and
I
CRI
or
OC
I?
Oh
wow,
alright,
so
I'm
like
given
a
book
report
on
The
Hobbit
to
junior
art
open
here.
So
please
correct
me.
If
anything
I
say
up
here,
it
ends
up
being
wrong
or
if
you
have
any
flavor
to
add
yeah
so
CRI,
it's
was
talked
about
in
depth.
A
You
know
the
verbs
or
adjectives
like
volatile
are
not
generally
good
in
software,
especially
when
it's
a
volatile
interface,
it
usually
means
things
are
tightly
coupled
so
CRI
emerged
as
the
solution
to
that
volatility.
It
allowed
us
to
fix
that
problem
so
that
multiple
standards
would
be
easy
to
support.
In
the
future,
and
what
does
that
look
like?
A
Well,
it
looks
like
an
adapter,
so
really
what
what
CRI
is
is
its
added
a
wrapper
as
an
adapter
around
the
cubelet
as
based
on
gr,
PC
and
protobuf,
and
a
lot
of
other
technical
fancy
things,
but
it
allows
us
to
plug
in
these
various
different
container
standards
in
an
easy,
repeatable
way,
which
is
very
nice.
So
it's
defining
that
that
interface
and
a
consistent
way.
A
A
You
know
1.8
most
recent
release
that
most
of
us
are
hopefully
on.
We
had
the
CI
tools
come
out,
so
you
there's
a
tool
called
crack
cuddle,
very
cool,
very
easy
to
play
with
I,
encourage
you
all
to
give
it
a
shot
and
in
the
upcoming
release,
we're
getting
stats
is
a
big
thing
coming
out
of
CRI,
so
we're
getting
a
lot
of
compatibility
on
the
stat
side.
That
may
be
something
that
works
just
for
docker,
but
we're
getting
it
for
all
of
the
container
interfaces
going
forward,
which
is
super
cool.
A
It's
super
cool
and
like
a
mom
and
dad
got
me
socks
for
Christmas
kind
of
way,
like
it's
cool,
if
you're
in
adults,
and
that's
your
thing
or
that's
your
space,
but
it's
not
exciting
as
like
a
toy
you
can
play
with.
So
how
can
you
mess
around
and
get
excited
about
CRI
today?
Well,
cryo
is
a
great
way
to
do
that,
so
cryo
is
sort
of
a
minimal
implementation
of
a
container
run
time.
It's
based
on
run
C
and
a
lot
of
other
stuff
can
I
glued
together
to
build
that
runtime.
A
A
They
have
a
great
tutorial
for
literally
you
just
run
the
script,
to
set
up
a
local
kubernetes
cluster
and
then
points
to
cryo
as
your
runtime
a
choice
so
the
real
goal,
the
gift
that
cry
CRI
has
given
to
us
is
we
don't
need
an
entirely
different
ecosystem
of
software
for
every
different
container
format,
and
thank
goodness
for
that.
So
the
idea
is
like
if
we're
using
something
like
Prometheus
for
monitoring
logging
or
sorry,
it's
monitoring.
B
So
when
we're
talking
about
the
CRI,
we
talked
about
the
value
of
having
an
adapter
for
various
plugs,
in
this
case
the
plugs
being
a
metaphor
for
various
container
runtimes.
Well,
the
OCI
is
a
set
of
standards
for
each
of
those
plugs.
They
might
not
all
be
a
different
shape,
but
we
still
might
want
the
packaging
or
the
cabling,
for
instance,
to
be
standard,
and
this
is
the
OCI.
We
want
to
standardize
both
sides
of
the
equation.
B
B
B
The
docker
image
format
at
this
time
was
not
static.
There
wasn't
a
formal
specification.
It
was
only
implicitly
defined
through
Dockers
implementation,
which
isn't
a
problem
if
all
you're
using
is
docker,
but
if
you
wanted
to
integrate
with
other
systems.
Good
luck,
there
were
no
guarantees
that
your
integrations
would
work.
There
are
also
some
technical
gaps
in
the
format
like
a
lack
of
content,
addressable
images
or
image
signing
and
the
fact
that
image
distribution
couldn't
be
delegated.
B
So
we're
going
to
fast
forward
a
little
bit
to
December
2014
exactly
three
years
ago,
corta
West
at
this
time
announced
a
new
project
a
container
standard
and
that
container
standard
was
called
app,
see.
The
motivation
behind
this
project
was
a
combination
of
the
use
cases
that
we
just
talked
about.
B
B
So
we're
going
to
jump
forward
a
couple
of
months
to
April
2015
and
the
docker
image
format
had
progressed.
Arguably,
the
most
important
addition
was
a
first
pass
at
writing
a
formal
specification.
There
were
things
missing
from
it,
but
it
was
a
great
first
step.
We
were
also
pleased
to
see
that
there
were
some
work
done
on
some
of
the
other
things
that
we'd
cared
about.
B
B
B
So
in
short,
the
OSI
I
set
out
to
define
what
a
container
is,
so
everyone
can
implement
and
build
tooling
for
it
and
also
to
pull
in
the
best
ideas
from
around
the
community.
So
a
lot
of
people
have
bought
into
this
idea.
This
is
we're
the
current
list
of
members
of
the
OCI
stands
and
you
can
see
some
pretty
big
names
there.
B
B
The
runtime
specification
outlines
how
to
run
a
file
system
bundle
that
is
unpacked
on
disk
at
a
high
level
and
OCI
implementation
would
download
an
OCI
image,
then
unpack
that
image
onto
a
OCI
runtime
file
system
bundle.
At
this
point,
the
OSI
OCI
runtime
bundle
would
be
run
by
an
OCI
runtime.
That's
a
tongue
twister.
B
Because
we're
running
a
little
short
on
time,
we're
gonna
skip
through
that
slide.
So
if
you're
curious
about
the
nitty
gritty
details
of
an
O
CI
image,
let's
talk
by
john
jonathan
bull
is
really
excellent
and
it
clocks
in
just
under
10
minutes
the
gist
that
you
want
to
walk
away
with.
Is
that
the
image
is
a
linux
tar
ball
and
some
metadata.
B
So
moving
on
to
talk
about
the
image
or
the
runtime
spec
briefly,
so,
as
we
mentioned
earlier,
this
is
basically
the
on
disk
layout
of
a
container
just
before
it
executes
the
runtime
spec
defines
various
life
cycle,
verbs
of
what
it
means
to
start,
create
and
kill
a
container.
It
also
has
platform
agnostic.
B
A
All
right
cool,
so
OCI
is
the
first
of
these
standards
to
hit
1.0
and
that's
all
for
the
better
for
us,
because
it's
sort
of
the
nucleus
of
a
lot
of
these
standards,
it
standardizes
the
image
format,
as
Elsie
said,
which
is
super
important
to
having
all
this
stuff
operate
together
nicely
you
know.
So
those
are
the
standards.
Well,
not
quite
there's
a
bit
more
and
I
guess
in
terms
of
OCI,
you
would
potentially
see
OCI
today
in
image
registries.
A
It
would
be
the
container
standard
that
you
would
download
when
you
pull
from
docker
hub
or
Quay
dot,
IO
or
Google
trusted
registry,
whatever
it
is.
Unfortunately,
the
industry
hasn't
quite
shifted
to
that.
Yet,
but
that's
where
things
are
headed
and
in
the
meantime,
we've
had
some
space
to
look
at
other
standards.
So
you
know
there
is
a
lot
more
to
be
done
in
the
standards
space
and
one
that
we
weren't
able
to
touch
on
today
is
the
containers
storage
interface.
So
if
you
are
in
the
storage,
world
are
passionate
about
storage.
A
That
is
a
young
standard
that
is
being
worked
on
currently,
and
your
feedback
would
be
invaluable
when
it
comes
to
improving
that
so
sort
of
wrapping.
This
up
standards
allow
this
whole
ecosystem
to
grow
and
thrive,
and
as
that
ecosystem
grows,
the
standards
will
need
to
evolve
to
meet
the
ecosystems
needs,
that's
all
the
better
for
us,
because
we
get
more
options
as
users.
That's
sort
of
the
dream
when
you're
making
a
standard
is
to
provide
accessibility
and
optionality
for
the
people
who
are
using
your
software
and
that's
something
worth
being
passionate
about.
A
A
I
know
that
core
OS
is
also
very
grateful
for
that
that
move
towards
openness
is
behind
a
lot
of
the
work
that
we
do
so
we
just
announced
a
project
called
open
cloud
services,
somewhat
separate
from
standards,
so
I'll
just
direct
you
to
the
core
OS
blog,
if
you're
interested
in
reading
more
about
that
and
yeah.
Thank
you.
A
I
think
the
question
is
our
images
built
by
the
latest
docker
version.
Oci.
Is
that
right
there
OCI
compatible
and
there's
a
tool
that
you'll
see
Jonathan
bull
use?
If
you
check
out
his
talk,
that
I'll
see
referenced
it's
and
it's
linked
in
these
slides
that
you
can
inspect
it
and
transform
it
easily
into
OCI
using
a
tool
called
scope
EO.