►
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
How Standards, Specifications and Runtimes Make for Better Containers – Chris Aniszczyk, The Linux Foundation/CNCF, Jeffrey Borek, IBM, Rithu Leena John, CoreOS/Red Hat, & Patrick Chanezon, Docker
With the rapid growth of containers over the past few years — including container-based solutions from almost all major IT vendors, cloud providers & emerging start-ups — the industry needs a set of common, open standards & specifications. As the container market — which is poised to reach $2.7 billion by 2020 — flourishes, the fear of lock-in is real. Chris Aniszczyk, Jeffrey Borek, Patrick Chanezon, & Rithu Leena John plan to dive into how standards impact the ecosystem at large; container runtimes like containerd & rkt; how specifications ensure interoperability & neutrality + much more. Attendees will learn about developing/deploying containers and/or learning the benefits of standardization in container environments. They can also expect to hear how contributions to OCI bridge the industry closer to standardized container distribution via runtime and image format specifications.
To learn more: https://sched.co/GrZE
A
So
thanks
everyone
for
coming
to
a
talk
on
OCI,
which
essentially
is
all
about
container
standards
and
bringing
the
container
community
together.
Today
we
have
four
speakers.
My
name
is
Chris
Hannah
Zach
I
have
the
fun
job
of
helping
kind
of
run,
the
wonderful
back
off
the
stuff
of
the
open
container
initiative,
also
with
CN
CF
and
some
other
Linux
Foundation
things
and.
B
C
B
B
So
we're
gonna
cover
this
agenda.
We're
gonna
go
through
this
very
formally,
as
you
can
tell,
by
the
way
we've
set
the
stage
for
today.
So
I'm
gonna
encourage
questions.
If
you
have
some
things
you
want
to
shout
out,
I,
don't
think
it's
going
to
throw
anyone
off,
but
we're
gonna
go
through
a
lot
of
material,
pretty
quickly
and
I
hope,
you'll
find
it
all
entertaining.
B
So
how
many
think
containers
are
brand
new
good
they've
been
around
for
a
long
time.
Our
friends
at
Google
have
been
leveraging
the
heck
out
of
the
containers
for
over
a
decade
and,
as
you
can
see
from
the
slide
up
there,
a
lot
of
people
over
the
span
of
the
last
18
plus
years
have
been
doing
a
lot
to
advance
the
ball,
and
this
is
not
even
exhaustive
right.
So
if
I've
left
something
off
or
neglected,
someone,
please
forgive
me,
but
these
are
some
of
the
highlights.
B
B
B
So
what
needed
to
happen
here
is
that
I
think
a
lot
of
people
that
had
been
in
the
industry
really
appreciated
the
value
that
Salomon
and
the
team
at
docker
had
brought
to
containers
and
terming
in
terms
of
making
them
much
more
easily
easy
to
consume
and
for
the
average
developers
sysadmin
to
begin
to
leverage.
But
it
was
so
fundamental
and
yet
so
revolutionary
and
such
an
you
know
a
solid
incremental
advancement
that
you
know.
B
Many
of
us
thought
this
really
needed
to
be
something
that
was
shared
under
open
governance
and,
as
I
mentioned
earlier,
I
collaborated
with
docker
and
some
early
rising
around
got
the
topic
of
governance
and
ultimately
that
led
to
the
formation
of
the
OCI,
and
that
was
announced
on
at
the
docker
conference
on
stage
by
Solomon
back
in
20:15.
So
just
an
amazing
gathering
of
industry
leaders
to
come
and
work
on
this,
but
it
wasn't
just
docker
a
shout
out
to
Alex
and
Brendon
and
the
team
at
core
OS.
B
You
know
is
this
something
I
need
to
decide
at
this
level
of
the
technology,
and
so
as
part
of
this
OCI
process,
both
technology
from
rocket,
as
well
as
from
docker,
contributed
to
this
specification
process
and
ultimately,
Runcie
became
the
code
base.
That
was
also
contributed
to
essentially
found
the
OCI
in
the
early
days.
And
again
it
wasn't
just
these
two
companies,
lots
of
other
companies
and
players
were
involved.
It
was
a
very
interesting
time
in
the
evolution
of
the
whole
container
phenomenon.
B
Here's
a
quick
slide
that
just
shows
you
know
some
of
the
other
players.
I've
referenced.
You
know
proud
to
been
a
small
part
as
IBM
whenever
I
mentioned
IBM
an
open
source,
I'd
like
to
say
I,
stand
on
the
shoulders
of
giants,
because
in
the
early
days
of
open
source
back
in
the
hole,
Apache
Linux
eclipse
phase,
you
know,
IBM
did
some
very
fundamental
positive
things
to
help
nurture
an
open
ecosystem.
B
So
it
was
nice
to
be
a
small
part
of
this
activity
associated
with
the
development
of
open
containers
and
then,
lastly,
just
as
a
quick
slide,
you
can
see
just
how
important
docker
was
to
this
effort,
as
well
as
the
efforts
of
Red
Hat.
Another
company,
I
like
as
well
as
some
of
the
other
players
associated
with
this.
B
C
So
let's
Tec
take
a
step
back
and
go
through
the
timeline
of
what
happened
before
OCI
was
launched
in
about
I,
want
to
say,
November
of
2014
the
docker
image
format
circa
was
introduced.
It
was
more
of
a
fluid
format
which
continuously
kept
evolving,
and
it
was
fine
at
that
time
because
there
was
so
much
change
going
on
around,
but
there
was
no
way
to
sign
it.
There
was
no
content
adjustability.
C
So
then
we
at
Corollas,
who
were
also
very
heavily
invested
in
the
open
standards.
Space
came
up
with
ab
c--,
which
was
application.
Contino,
which
was
a
specification
and
rocket,
was
built
around
that.
So
we
had
a
container
engine
for
it.
It
was
also
quite
widely
adopted
and
then
in
April
of
2015
docker
came
out
with
version
2.2,
which
was
also
circa,
and
they
fixed
a
lot
of
the
issues
with
problem
1.
This
time
you
could
sign,
it
reliably
was
optional.
C
You
could
turn
it
on
and
off
if
you
wanted,
and
that
was
content
addressability
and
all
of
this
finally
culminated
in
June
of
2015
and
OCI
was
launched.
So
the
idea
behind
that
was,
we
came
together
as
a
big
wide
community
and
decided
that
we
needed
to
get
some
standards
in
place
so
that
we
can
help
everybody.
C
This
slide
kind
of
shows
us
as
a
better
timeline
of
OC
I
was
launched
in
June
of
2015.
It
was
initially
launched
with
the
with
just
the
runtime
specification
later
on
in
April.
2016
is
when
the
image
format
specification
project
was
launched
and
from
then
on.
We've
had
lots
of
successful
revisions
and
versions
that
a
lot
of
adopters
have
been
involved
in,
and
this
is
not
an
exhaustive
list.
This
is
all
of
the
OCI
adopters.
We've
seen
a
lot
of
success
from
all
of
these
big
players.
C
So
next
I
would
like
to
go
off
on
a
little
bit
of
a
tangent
and
kind
of
talk
to
you
about
the
examples
of
how
containers
are
actually
adopted
in
the
industry.
Nowadays,
I've
been
lucky
enough
to
join
lyft
three
weeks
ago
and
I've
been
trying
to
understand
how
their
container
architecture
works
and,
just
to
give
you
a
little
bit
of
a
background.
Lyft
runs
more
than
300
micro
services
across
40,000
ec2
instances.
So
you
can
just
imagine
when
you
want
to
move
all
of
this
from
a
well-orchestrated
system
into
kubernetes.
C
It's
not
going
to
be
easy.
If
there's
one
thing,
we've
learned
over
the
past
few
days
at
coop,
con
migration
for
enterprises
to
kubernetes
is
not
easy,
but
we're
actively
working
on
it.
We
use
the
envoy
service
mesh
for
all
of
our
network
needs
and
some
of
us,
some
of
our
production
services,
do
run
on
it.
Now
most
of
our
machine
learning
services
do
run
on
it
and
we've
seen
success
and
we're
working
very
very
quickly
to
get
the
rest
of
it
action
so
I
think
when
I
take
a
step
back
and
look
at
it.
B
D
D
So
if
you
want
to
learn
more
about
continuity
and
understand
the
architecture,
you
can
dig
into
these
and
try
to
find
the
videos
for
them,
but
essentially
continuity
over
time,
grew
into
just
a
demon
to
control
run,
see
that
with
just
the
that
would
just
generate
the
image
and
then
the
OCI,
bundled
for
it
into
getting
the
images
laying
them
on
the
filesystem
and
then
doing
the
distribution
as
well
and
as
container
D
grew.
We
actually
grew
the
set
of
all
CI
specifications.
D
So
in
docker,
container
D
has
been
the
container
runtime
in
darker
since
1.11
in
2016,
and
that
has
brought
a
lot
of
a
lot
of
advantages
to
darker
engine.
Another
example
of
runtime
we
talked
about
that
is
a
creo,
that's
made
by
Red
Hat.
One
of
the
interesting
aspect
of
the
dynamics
in
the
industry
right
now
is
that,
with
all
the
consolidation
that
happen
in
the
industry
in
the
past
few
years,
basically
soon
at
IBM,
there
will
be
three
runtimes
continuity,
creo
and
racket.
D
D
The
fact
that
at
least
they're
running
both
docker
and
creo
to
me
speak
speaks
a
lot
about
the
value
of
having
a
standard
specification
and
then
lots
of
different
implementation
that
can
compete
on
different,
different
trade-offs
because
in
engineering,
it's
all
about
trade-offs
and
and
having
different
engines
that
solve
for
specific
use
cases
better
allows
you
to
explore
the
space
with
different
trade-offs
and
I'll.
Tell
you
about
a
few
examples
of
that.
One
of
them
is
pouch
made
by
Alibaba.
D
So
that's
another
container
engine,
that's
using
continuity
inside
an
R
and
C
and
like
like
docker,
they
have
the
ability
to
plug
different
runtimes
like
cat
eye
containers
or
run
a
taxi,
and
one
thing
I
found
interesting
on
the
Alibaba
psy.d
that
they
had.
They
had
a
very
specific
use
case
where
they
needed
to
migrate
legacy,
applications
that
run
with
system
G,
so
to
have
containers
that
have
system
D
in
them
and
a
bunch
of
stuff,
and
so
they
extended
the
spec
a
little
bit
to
create
what
they
call
rich
containers,
or
something
like
that.
D
So
I
wonder
whether
maybe
they
will
submit
that
to
a
CI
for
Standardization
or
whether
it's
just
a
particular
use
case.
But
what
I
really
liked
in
the
way
they
implemented?
It
is
that
they
stuck
to
the
OCI
spec,
and
then
they
use
the
hooks
that
we
have
in
the
spec.
We
made
it
extensible
to
be
able
to
add
behavior
to
that,
and
then
another
example
I
talked
to
you
about
that.
Before
is
one
of
the
trade-offs.
D
That's
really
interesting
is
in
in
terms
of
speed
of
starting
your
container,
it's
very
fast
to
start
it
on
Linux.
You
just
need
to
set
up
some
namespaces
and
C
groups,
but
then
you
have
less
isolation
that
you
would
have
with
VMs,
and
so
the
Cata
team
created
the
cat
a
container
runtime.
You
can
replace
run
C
by
the
cat.
A
container
runtime
and
they
are
implementing
the
OCI
spec,
and
it
gives
you
VM
level.
Isolation
and
I
wanted
to
conclude
on
an
even
more
recent
use
case.
D
So
this
one,
this
one
is
literally
I
heard
about
that
two
days
ago.
So
I
want
to
see
direct
stock,
we're
about
continuity
and
at
the
end
of
the
talk
we
gathered
with
people
from
Microsoft,
Amazon,
Google,
docker
and
Cruz
Steven
was
there,
and
so
we
all-
we
just
all-
went
to
the
Amazon
office
next
door
and
they
showed
us
a
prototype
that
they
built
that's
on
github.
You
can
find
it.
D
That's
called
firecracker
container
D
where
they
implemented
a
runtime
based
on
the
firecracker
vm
that
they
created
that
that's
targeted
to
a
very
specific
use
case
and
with
a
very
specific
set
of
trade-offs
that
they
wanted
to
implement
they're
where
they
want
a
very
fast
boot
time
for
high
turn.
So
it's
really
for
the
type
of
things
that
you
would
have
in
server
less
kind
of
workloads
and
they
wanted
to
implement
that
in
container
D
so
that
it
could
just
plug
directly
in
kubernetes
and
you
could
have
pods.
D
So
your
part
is
a
VM
and
then
they
can
start
containers
inside
what
I
found
super
interesting.
There
is
that
they
really
followed
as
much
as
the
OCI
spec
as
they
could
leveraging
all
the
code,
that's
already
in
container
D
and
in
run
C
for
that
and
just
adapting
the
shim
so
that,
for
example,
when
they,
when
they
spin
up
a
VM,
the
continuity
which
is
pulling
the
images
needs
to
make
them
available
inside
of
the
VM,
and
so
they
created
a
new
snapshot
over
there.
D
That
makes
it
available
that
makes
these
snapshots
available
inside
of
the
VM
as
block
device,
and
then
they
have
a
V
sock
inside
of
the
VM
that
the
agent
is
using
to
communicate
with
continuity
and
to
pass
all
the
FIFO
for
the
tty
and
things
like
that.
So
that's
a
very
promising
proof
of
concept.
You
can
try
it
out.
D
We
could
standardize
Microsoft,
darker
and
many
others
release
the
spec
last
week
at
dhaka
con
that's
called
cloud
native
application,
bundles
the
goal
that
that
spec
is
to
be
able
to
bundle
applications
that
are
based
on
on
containers
infrastructure
as
a
service
managed
cloud
services
as
well
as
server
less
functions
into
a
single
OCI
image,
and
so
they
leverage
the
OCI
standard
to
the
maximum.
A
darker.
D
We
implemented
that
in
our
docker
app
experimental
tool
and
one
of
the
discussions
we
had
yesterday
in
the
OCI
face-to-face
meeting,
the
people
from
Microsoft
came
there
to
talk
with
the
OCI
maintainer
is
about
what
should
we
do
with
that
spec?
Should
it
live
in
OCI?
What
do
we
do
for
distributions
of
these
and
all
that,
so
that
that
may
be
a
very
interesting
angle
for
the
future,
so
I'll
leave
it
at
that
for
the
examples
and
Chris,
do
you
want
to
talk
about
the
current
state
just.
A
Kind
of
close
things
up
and
maybe
ask
the
audience
if
there's
any
questions
so
yeah
I
mean
the
OCI
is
just
a
kind
of
very
simple,
open
source
project
with
a
variety
of
different
projects.
There
we
have
spec
projects,
tools,
projects
and
a
couple
of
utility
projects.
You
could
just
go
to
github.com
such
open
containers
and
check
them
out.
You
know
most
people
ask
you
know
what
is
what
is
OCI
going
to
do
in
the
future.
You
know:
are
you
kind
of
done
yet?
What
else
is
there?
At
a
standardized?
I
mean
the
goal.
A
Kind
of
for
the
organization
is
to
keep
things
stable.
You
know
people
appreciate
the
stability
that
OCI
has
brought
to
the
industry
around
containers.
There's
a
couple
things
around
distributions.
Spec
was
created
as
a
project,
but
it
hasn't
shipped
as
a
100
yet
so
that
will
be
happening
next
year,
as
Patrick
mentioned,
we
had
the
C
NAB
team
at
a
little
OC
I
face-to-face
yesterday,
discussing
whether
C
NAB
makes
sense
for
OC
I
or
you
know,
potentially
maybe
it
goes
in
CN
CF,
but
we're
having
these
discussions.
A
Kind
of
you
know
find
a
proper
home
for
that
project,
and
you
know
just
like
any
wonderful
open
source
organization.
We
have
our
elections
and
all
this
kind
of
type
of
back
office
stuff
that
yet
that
you
have
to
do
to
kind
of
keep
things
going
so
I'll
be
running
those
next
year.
Other
than
that,
like
you
know,
standards,
work
and
specification.
Work
is
generally
not
the
most
exciting
thing
in
the
world,
but
it's
super
critical
to
kind
of
get.
A
You
know
whether
you're
comfortable
with
Chrome
Firefox
or
you
know,
whatever
boutique
things
and
we
kind
of
want
to
see
the
same
thing
happen
with
containers
in
a
future
where
you
don't
really
care
about
the
you
know,
specifications
or
specs
you're,
just
happy
things,
things
work,
so
that's
about
it,
I
think.
If
you
want
to
get
involved
with
the
community,
it's
just
like
any
other
person
computer,
they
host
meetings,
they
have
repos
mailing
lists
and
so
on.
A
So
please
get
involved
at
this
you're
interested
in
this
type
of
work
or,
if
you're,
actually
using
a
CI
in
some
strange
ways.
You
know
like
Patrick,
you
know
demoed
the
kind
of
or
showed
off
the
firecracker
work
that
the
AWS
folks
we're
working
on
that's
kind
of
brand
new.
So
a
lot
of
people
are
doing
interesting
things
and
please
share
them
with
us.
We
definitely
want
to
kind
of
document
and
learn
about
them,
but
other
than
that.
Thank
you
for
listening
and
we'll
open
it
up
to
any
questions.
If
folks
have
them.