►
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).
rkt Intro – Alban Crequy & Iago López Galeiras, Kinvolk (Any Skill Level)
rkt is a modern container runtime, built for security, efficiency, and composability. Learn what rkt has to offer and how you can use it for running your containers.
About Iago
Iago brought his relaxed Spanish demeanor to Berlin a few years back. Sincenthen, he’s been diving and swimming around the internals of various Linuxnflavors; Android, embedded and Cloud. Container technologies are his currentnfocus; specifically on the rkt project where he’s a core contributor andnmaintainer. Although he once got distracted by functional programming, hisndaily tasks see him working mainly in Go and C.
About Alban
Originally from France, Alban currently lives in Berlin where he is a CTO & co-founder at Kinvolk, a software engineering team focused on building foundational Linux technologies for the cloud. He is a contributor to rkt, a container runtime for Linux, Weave Scope, a container visualization & monitoring tool, and is actively working on BPF-related projects. Before falling into containers, Alban worked on various projects core to modern Linux; kernel IPC and storage, dbus performance and security, etc. His current technical interests revolve around networking, security, systemd and containers at the lower-levels of the system. Alban previously gave talks at several conferences including FOSDEM, Linux Plumbers, IO Visor Summit, Kubecon and LinuxCons/OSSummit.
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
these
rugged
introduction,
first
of
all,
I'm
kind
of
surprised
to
see
so
many
people,
that's
good,
so
how
many
people
have
seen
or
watched
a
talk
by
me
about
rocket
nobody,
that's
good,
because
if
you
were,
you
were
gonna,
you
know
hear
the
same
things:
okay,
so
yeah!
First
of
all,
something
about
us,
so
I'm
Yago
and
he's
hi.
B
A
Yeah,
so
we
live
in
Berlin.
We
are
two
of
the
cofounders
of
well
two
out
of
three
of
the
cofounders
of
kinfolk
and
we
did
a
lot
of
work
on
rocket
with
Korres
and
on
rocket
lit
after
that
and
yeah
we're
currently
maintainer
of
record
and
the
rocket
lit.
These
are
our
github
pages
and
our
Twitter.
If
you
want
to
follow
us,
although
we
don't
really
treat
much,
but
we
retreat
sometimes
so.
The
plan
for
for
today
is
first
I
would
like
to
explain
what
is
rocket.
A
B
A
In
a
yeah
yeah
for
the
next
months,
I
guess
so
yeah.
This
is
a
catchphrase
for
rocket.
It's
a
modern,
secure,
composable
container
runtime.
So
to
explain
this
a
bit
with
modern.
We.
We
say
that
we
try
to
take
advantage
of
the
latest
technologies
wherever
possible,
so
things
like
in
the
Linux
kernel
in
a
user
name
spaces
or
SATCOM
or
yeah
the
no
new
privilege
flag,
yeah,
those
those
things
that
yeah
UNIX
kernel
made
available
for
us
and
their
new
yeah.
A
We
say
that
it's
secure,
as
in
we
try
to
be
secure
by
default,
so
all
the
security
options
are
enabled
by
default,
so
yeah.
Sometimes
that
means
that
your
apps,
not
gonna,
work
and
you'll
have
to
debug
a
bit
why
it's
not
working,
but
we
think
it's
important
that
we
make
things
as
secure
as
possible
by
default
and
by
composable
we
mean
that
we
try
to
interact
with
the
rest
of
the
system
in
a
yeah
in
a
good
way.
A
So
we
don't
really
try
to
reinvent
the
wheel
and
if
something
is
implemented
in
another
part
of
the
system,
we
just
use
that
yeah.
So,
for
example,
we
have
a
very
good
integration
with
system
D
because
yeah
we
it's
there
and
it
does
things
that
work
and
yeah.
We
don't
need
to
reinvent
what
it
already
does
so
yeah.
Ultimately,
raka
is
an
implementation
of
the
ab
c--
spec,
so
yeah
before
the
LCI
spec
there
was
the
ab
c--
spec
and
back
in
the
day
the
docker
image
format
wasn't
really
specified.
A
It
was
specified
in
the
code
and
I
was
not
really
ideal.
So
yeah
there
was
this
f4
from
Korres
to
put
up
put
out
there,
a
spec
called
up
C
and
actually
define
the
things
that
that
it
that
and
a
container
image
and
a
container
should
be,
and
even
though
now
it's
kind
of
in
a
not
deprecated
but
not
actively
developed.
We
think
it
served
as
a
first
step
to
towards
standardization
and
yeah.
So
now
that
the
OCS
back
is
there
that's
what
you
should
be
doing,
but
rocket
still
implements
the
app
suspect.
A
The
parts
of
the
spectral
implements
is
the
image
format
and
execution
environment
so
yeah
just
a
quick
word,
an
app
see
yeah
as
I
said
it's
a
spec.
It
has
some
associated
tooling,
so
we
have
things
well.
We
have
this
pack
itself
and
we
have
some
code
there
that
implementation
of
the
spec
can
use
for
image,
discovery
and
other
stuff.
A
A
So
the
app
suspect
is
four
things:
basically,
an
image
format,
which
is
the
a
CI
and
yeah
an
image,
is
just
a
table
with
some
manifest
data
attached.
So
the
ACI
is
just
that
terrible
with
the
root
of
s
and
some
manifest.
That
explains
what
binary
should
be
executed.
How
isolated
should
be
the
the
container
and
things
like
that?
A
A
cool
part
of
the
ab
c--
spec
is
image
discovery
part.
So,
instead
of
having
a
centralized
registry,
where
you
just
get
your
images
from
what
it
does,
is
it
uses
dns
as
a
discovery
mechanism.
So
if
you
imagine
your
organization
example
and
you
have
an
app
called
app
one,
so
example.com
slash
up
one-
is
your
URL
for
the
for
the
image.
So
what
the
app
suspect
will
do
is
go
to
that
web
page
and
download
some
metadata
there.
That
will
tell
the
runtime
where
the
actual
artifact
of
the
image
is.
A
So
this
is
a
decentralized
way
of
getting
images
instead
of
dealing
with
a
centralized
registry.
Yes,
it
spec
also
define
spots
which
is
yeah
I,
guess
you
know
parts
because
you're
in
a
cube
con.
So
yes,
how
you
group
applications
together
and
and
run
them
together,
and
it
also
defines
the
executor
so
the
runtime,
which
is
what's
the
environment
of
the
app
what
one
environment
the
app
should
find
when
it's
running
in
a
container
yeah
so
rocket.
It's
just
a
simple
CLI
to
there's
no
demon
involved.
You
just
run
rocket
and
it
just
runs
there.
A
Whatever
you
under
the
process,
that
was
that
spawned
rocket,
it's
just
a
simple
mandating
golang
and
it's
only
supporting
Linux.
So
we
didn't
want
to
support
other
operating
systems
like
open,
BSD
or
Windows
for
Mac.
It's
self-contained.
So
it
only
requires
yeah
minimal,
set
of
libraries
like
you
see,
and
a
couple
more
that
should
be
installing
on
every
Linux
and
it's
init
system
and
District
Gnostic.
So
it
should
work
everywhere.
Even
though
we
optimize
for
system.
A
A
So
you
see
there's
the
word
stages
here,
so
the
state
zero,
which
is
a
rocket
binary
and
that
deals
with
just
discovering
the
where
the
image
is
fetching
the
images
the
image
managing
it
like
you
can
list
images,
remove
what
you
expect
from
from
yeah
a
container
runtime.
It
also
sets
up
the
pod
file
systems
and
yeah,
so
it
renders
the
pod
to
the
file
system,
so
you
can
actually
start
a
container
from
there.
Yeah
then
there's
stage
one
which
is
the
actual
exit
environment
for
pots,
and
this
is
what
we
call
yeah
a
pot.
A
That's
where
the
isolation
is
so
in
stage
one
you
can
yeah
the
the
actual
container
will
start.
It
also
manages
the
lifecycle
of
the
processes
inside
the
container,
so,
for
example,
yeah.
Sometimes
you
want
that
if
a
process
dies,
the
container
dies-
or
maybe
you
want
it
to
restart
it,
so
that
is
handled
by
stage
one.
It
also
applies
the
resource
constraints.
So
if
you
want
to
limit
the
amount
of
memory
that
container
is
taking
or
the
CPU
yeah
that's
stage
one
role,
nice
stage,
two
is
just
the
actual
application.
A
So
whatever
you
run
nginx
or
yeah
any
application.
So
one
cool
thing
about
stage
one
is
that
it's
swappable,
so
the
default
implementation
uses
Linux,
namespaces
and
secrets
for
isolation.
So
that's
yeah
what
you
call
a
Linux
container
and
it's
based
on
system
the
N
spawn
and
run
system
the
inside
to
supervise
those
processes,
as
I
mentioned
before,
but
there's
also
different
implementations.
There's
a
KVM
implementation.
So,
instead
of
using
Linux
containers,
it
uses
virtualization,
so
hardware
virtualization.
A
A
So
this
was
very
cool
because
it
the
the
rocket
the
design
of
rocket
made
easy
to
just
swap
system
nyan
spawned
with
qmo
binary
and
things
just
work,
and
you
can
take
advantage
of
the
rocket
distribution,
image,
distribution
mechanisms
and
all
that
and
signing,
and
then
this
fly,
which
is
yeah
just
something
so
dia
that
you
take
advantage
of
the
image
distribution
mechanism.
As
I
mentioned,
it's
just
a
chroot
there's,
no
security,
there's
no
security
guarantees
involved.
A
Yes,
so,
for
example,
flies
what
used
if
you
run
Korres
container
Linux
it's
what
used
to
run
the
cubelet
via
the
cubelet,
wrapper
script
and
also
I,
think
at
CD,
and
then
there's
others,
there's
some
experimental
ones,
yeah.
You
can
search
for
them,
so
yeah
what
happened
in
rocket
recently,
so
we
implemented
sharing
the
house
IPC
namespace.
This
was
not
possible
before
because
system
the
and
spawned
wasn't
allowing
that.
So
we
implemented
this
for
a
client
that
wanted
to
have
some
HPC
high-performance
computing
tasks
running
and
they
share.
They
heavily
use,
share
memory
so
yeah.
A
We
did
that
to
allow
that
and
also
so.
The
rocket
lit
is
the
rocket
implementation
of
a
kubernetes
CRI,
so
contain
your
runtime
interface
so
yeah.
In
order
to
make
that
work,
we
need
to
fix
a
lot
of
stuff
in
rocket
because
the
design
of
rocket
and
the
CRI
weren't
really
matching.
So
we
had
to
redesign
rocket
a
bit
to
allow
sandbox
to
be
created
and
then
containers
been
added
on
top,
instead
of
just
creating
an
immutable
part
which,
with
what
it
was
a
sign
for,
we
also
switched
the
fall.
A
Kvm
flavored
milk
AVM
to
chemo
I
mentioned
that
and
we
fix
a
lot
of
bugs
another
recent
development
with
it
was
documentation.
So,
yes,
documentation
is
important
and
things
were
documented,
but
not
as
deep
as
they
could
be.
So
we
actually
have
to
thank
the
CN
CF
for
this,
because
this
work
was
funded
by
them
and,
as
you
can
see,
we
had
a
lot
of
issues
about
documentation.
We
have
31
PRS,
well,
actually,
yeah
I,
don't
think
it's
their
issues
OPRS,
but
yeah
a
lot
of
stuff
yeah.
So
what
is
missing
in
rocket?
A
First,
one
of
the
most
urgent
things.
I
guess
is
updating
the
CNI
version,
because
rocket
is
using
0.3
and
that's
pretty
old
and
on
Oh
in
in
0.6
there's
some
new
features
that
users
want,
but
yeah
we
haven't
gotten
around
to
it
yet
because
some
vendor
issues
and
some
yeah
a
lot
of
changes
on
the
CNI.
A
Another
thing
that's
missing
is
to
implement
the
rocket
LED
support.
We
did
some
new
features
that
are
guarded
by
some
environment
variables
there.
Those
are
the
rocket
experiment,
environment,
variables
yeah.
So
we
think
that
those
work
fine.
Maybe
it
can
be
improve
a
bit.
So
we
should
remove
those
environment
variables,
so
it
just
works
out
of
the
box.
A
Those
features
are
needed
and
then
KC
from
Korres
started
experimenting
using
run
C
to
run
the
stage
two
and
the
reason
for
this
is
so
we
were
taking
the
parameters
for
rocket
and
translating
those
two
fields
in
a
system
a
unit
and
sometimes
the
parameters
needed
are
done
really
much
so
yeah
using
run.
C
will
avoid
that
and
make
things
work
better,
but
yeah,
it's
just
an
experimental
state.
So
it
doesn't
really
work
at
the
moment
and
then
rocket
supports
the
LCI
image
spec,
but
only
through
converting
docker
images
to
the
ACI.
A
That's
used
internally
in
rocket.
So
there
was
some
interest
in
doing
some
native
OCI
support,
but
I
don't
think
work
has
started
yet
there
and
then
of
course,
always
general
bug
fixing
so
I'm
gonna
do
a
small
demo
now
and
then
I
will
try
to
answer
questions.
Maybe
you
have
questions
about
the
future
of
rocket
or
things
like
that,
so
I
will
try
to
answer
those
as
yeah,
whereas
I
can.
So.
A
Okay,
you
can
see
that
I
guess
a
little
bit
bigger
okay,
so
this
demo
is
kind
of
a
mix
of
things.
So
we
have
a
cluster
kubernetes
cluster
running
the
rocket
lid,
and
this
is
running
in
the
in
containers.
So
on
my
machine,
I
have
a
tool
called
cubes
bond
that
we
have
kinfolk
developed
and
this
tool
can
start
multi
node
clusters
on
your
machine.
So
it's
thinking
think
of
it
like
mini
cube,
but
for
multi
node
clusters
and
using
containers
instead
of
VMs.
A
So
I
have
three
of
those
machines,
so
I
have
a
master
in
two
workers
and
yeah.
Actually
it's
also
running
flat
berliners,
which
is
a
fork
of
maintainer
Linux
that
we
had
kinfolk
did
because
since
the
acquisition
by
by
Red
Hat
yeah,
so
we
there's
not
gonna,
be
commercial
support
for
container
Linux,
so
we're
trying
to
take
over
there.
So
it's
basically
just
like
container
Linux,
but
with
the
names
changed
and
we
try
to
be
as
close
as
option
as
possible
as
long
as
option
exists.
A
A
A
A
Yeah,
so
these
are
all
the
parts
that
are
running
and
yeah.
It's
it's
just
a
simple
demo
to
show
that
rocket.
Lit
works,
fine
as
a
runtime
for
kubernetes.
We
have
some
problems
with
Cuban
Ares
110
that
was
recently
released,
but
this
is
one
nine
and
it
worked
fine
and
yeah.
We
should
fix
those
problems
soon
and
I
just
have
an
engine
X
spot.
Just
a
typical
example
and
I
also
have
a
an
engine
X
service,
that
is
a
node
port
service,
so
yeah
I
can
show
that
it
works.
So
the
port
exposed.
A
A
Yeah,
it's
just
welcome
to
nginx
Hey,
so
yeah.
That
was
the
demo
unless
you
want
to
show
and
what
you
want
to
see
something
specific
yeah.
So
at
the
moment,
rocket
is
receiving
yeah,
not
much
not
many
contributions,
because
Korres
only
supports
it
as
far
as
they
need
for
their
container
Linux
needs.
So
we
do
some
basic
maintenance,
like
maybe
the
reviews
on
PRS
and
doing
some
small
releases,
and
then
we
add
kinfolk.
A
We
don't
have
we
currently
don't
have
you
know
financiación
to
to
carry
on
development
full-time,
so
yeah,
it's
CNCs
project,
so
it
should
be.
We
I
guess
we
were
hoping
that
the
community
will
pick
it
up
and
use
it,
but
yeah
I
think
this
is
it
hasn't
happened
yet.
So
that's
what
the
only
thing
I
can
say
about
the
future
of
rocket.
A
We
we
like
it
a
lot,
but
we
don't
really
have
the
time
spend
on
developing
it
full-time
and
if
you
like
to
pick
it
up
or
if
you
want
to
use
it
and
maybe
make
it
gain
more
traction,
please
feel
free
yeah.
Otherwise
it
will
stay
there.
I
guess
I
think
some
people
still
use
it
and
we
sometimes
receive
stories
from
people
that
use
it,
but
either
it
works
fine
for
them
or
yeah.
They
don't
need
any
new
features
so
yeah,
and
with
that,
maybe
you
have
any
questions
or
comments.
A
A
So
this
is
a
question
about
the
advantages
of
using
a
rocket
against
docker
or
other
runtimes.
So
yeah,
we
think
rocket
is
pretty
focused
on
just
being
a
just
just
doing
the
containers
and
that's
it
so
in
docker
that
you
have
a
lot
of
things
in
the
ROC
docker
demon-like,
the
docker
diamond
itself,
fetches
images
and
it
keeps
running
there
and
then,
if
it
crashes,
maybe
your
containers
crash
too,
and
it
also
does
yeah.
B
A
Does
a
lot
of
things
so
rocket
is
pretty
focused
it
it's
just
a
process
that
does
maybe
very
much
fetching
and
then
runs
and
then
stays
out
of
the
way.
So
that's
one
advantage
from
our
point
of
view.
Then
we
also
like
this
stage,
one
swaps
of
ability
so
that
it's
easy
to
experiment
with
new
runtimes.
So
I,
don't
know.
A
If
you
heard
about
this,
this
new
runtime
runtime
by
Google-
that's
that's
a
sandbox,
runtime,
yeah
I
think
it
will
be
pretty
easy
to
just
do
a
stage
one
with
that,
one
with
that
thing
and
and
yeah.
So
it's
a
good
way
to
experiment
with
new
concepts
and
I'm.
Also
a
bit
yeah.
Well,
maybe
not
disappointed,
but
yeah
I,
don't
like
that
in
the
OCI
image.
Spec,
the
distribution
spec,
an
idea
like
the
image
distribution
for
AC
is
was
considered,
wasn't
consider
because
I
think
a
distributed
image.
A
Distribution,
yeah
a
distributed
approach
to
image
distribution
was
very
interesting
and
they
just
follow
darker
with
the
central
registry
idea.
So
that's
kind
of
a
shame,
yeah,
so
I
I
in
summarizing
I.
Think
if
you
just
need
to
run
containers-
and
you
don't
need
anything
fancy
around
it,
you
can
use
rocket.
A
A
A
So,
if
you're
interested
in
knowing
how
containers
work
like
in
a
more
deep
ways,
you
can
come
to
the
rocket
deep
dive,
we
will
be
talking
about
sea
groups
as
they
notify
and
yeah
a
lot
of
cool
stuff
with
diagrams,
and
it
will
be
more
like
a
discussion
session
where,
if
you're
interested
in
the
topic,
you
can
talk
about
anything.
We
can
try
to
explain
how
this
works
yeah.
So,
if
you're
interesting
that
please
come.