►
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
Introduction to CRI-O - Mrunal Patel, Red Hat, Inc. & Peter Hunt, Red Hat, Inc.
You have a lot of complicated things to think about as a developer and Kubernetes admin. Your container runtime shouldn't be one of them. CRI-O is there to be your "no-worry" CRI option. Running distributed applications, even with kubernetes, is a challenging task, and ultimately a developer’s focus should be on providing value to their end-users. CRI-O is a container runtime designed to be secure and reliable and is developed exclusively for Kubernetes so that you can focus on what matters more. Join Mrunal Patel and Peter Hunt as they walk through the architecture and design of CRI-O and show you how to deploy and run with kubernetes, so you can choose it as your runtime, and promptly forget about it.
https://sched.co/Uai5
A
I'm
a
mean
I've
also
worked
for
a
Red
Hat
software
engineer,
I've
maintained,
cryo
and
also
pod
man
and
some
other
related
container
technologies,
and
today
we're
here
to
talk
to
you
about
cryo.
So
if
that's
not
what
you
want
to
listen
to,
you
should
probably
leave
so
here
we
are
cryo,
all
the
runtime
a
container
needs.
So
this
is
an
introduction
talk.
So
let's
do
an
introduction.
A
What
is
cryo,
what
do
we
mean
by
craft?
So
cryo
is
a
two-part
acronym,
so
the
first
part
of
it
CRI
sense
for
the
container
of
runtime
interface.
The
container
runtime
interface
is
the
way
that
the
cubelet
asks
a
runtime
to
create
containers,
pull
images
create
pods
and
alike
in
so
for
a
bit
of
a
history
lesson.
In
the
beginning,
there
was
just
docker
and
the
qubit
directly
talked
to
the
docker
socket
asking
it
to
create
containers,
for
it
then
came
along
rocket
and
the
entire.
A
The
rocket
is
another
core
OS
runtime
that
worked
with
kubernetes
and
the
way
that
they
implemented
it
in
the
cubelet
was
they
said.
If
we're
using
rocket
then
execute
the
rocket
method,
otherwise
execute
the
docker
method
and
then
came
along
some
other
VM
based
technologies,
and
then
the
qubit
maintains
our
like
whoa
wait:
okay,
let's
slow
down,
so
they
created
the
CRI.
They
contain
a
runtime
interface
and
basically,
what
it
does
is
it's
the
it
asked
container
runtime
to
fulfill
all
of
the
needs
that
the
qubit
has
for
a
container
runtime.
A
So
it
is
a
the
CRI
defines
how
implementations
asked
for
cube
will
ask
them
to
create
a
container
or
create
a
pod
or
pull
an
image
exact
into
a
container.
All
of
these
various
things
so
cryo
is
an
implementation
of
the
container
runtime
interface.
What
kind
of
implementation
and
see
I
compliant
one?
So
that's
what
the
O
stands
for
is
OCI,
so
the
OCI
is:
is
a
standards
board
that
and
a
set
of
projects
that
standardizes
the
way
that
containers
are
run
container
image
formats
and
the
like?
A
So
the
OCI
was
a
good
way
to
kind
of
make
a
basis
for
container
technologies
that
other
container
managers
and
runtimes
build
on
top
of
so
cryo
supports
all
kinds
of
content
OC.
I
compliant
container
images,
including
the
legacy
docker
one
supports
any
container
registry
and
protocols
that
the
OCI
defines
for
between
runtimes
and
registries,
and
it
supports
all
OCI
container
runtimes.
So
we
have
run
see
we
have
cata
and
we
run
integration
tests
against
both
of
those
there's.
A
c1
that
c
run
that
someone
in
Red
Hat
is
developing.
A
We
got
G
visor,
all
of
them,
cryo
will
run
with
and
you
can
specialize
your
container
needs
there.
So
that's
an
introduction.
The
question
then
follows:
why
would
I
use
cryo?
What
kind
of
value
proposition
does
cryo
give?
So
the
number
one
thing
that
we
like
to
say
that
is
great
about
cryo
is
it's
only
for
kubernetes,
so
other
container
runtimes
have
a
lot
of
different
masters
that
they
have
to
serve.
They
have
their.
You
know
there
are
clients
that
want
to
build
containers.
A
There
are
clients
that
want
to
push
containers
to
container
registries,
but
the
cubelet
doesn't
need
to
do
any
of
those
things,
and
thus
neither
does
cryo
so
cryo
is
only
built
for
kubernetes.
Cryo
is
kubernetes
only
lover,
as
we
like
to
say,
or
the
other
way
around.
Kubernetes
does
cryos
only
lover
and,
as
such,
we
can
do
things
like
run
the
entire
kubernetes
end-to-end
conformance
suite
against
cryo
for
every
PR
merged,
so
we're
guaranteed
to
be
conformant
with
the
way
that
kubernetes
expects
a
runtime
to
act.
A
We
also
have
run
against
the
CRI
tests
and
also
our
own
integration
tests.
So
we
run
like
a
ton
of
tests,
it's
crazy
and
it
takes
a
long
before
anything
gets
merged.
There's
also
us
being.
We
version
ourselves
in
lockstep
with
communities
which
simplifies
a
developer's
choice
or
an
admin
story
to
use
cryo
with
other
runtimes.
Your
questions
sometimes
becomes
what
version
of
X
runtime
works
with
kubernetes
one
dot
X,
and
you
never
have
to
ask
that
question
with
cryo.
It's
always
going
to
be
kubernetes
116
works
with
cryo,
116
and
so
on.
A
So
that
makes
it
easier,
and
basically
the
intention
with
cryo
primarily
is
to
make
contain
running
containers
in
production,
boring
and
secure,
and
we'll
talk
a
little
bit
more
about
secure
in
a
little
bit.
But
the
boring
aspect
is
all
of
because
cryo
only
works
with
kubernetes.
You
can
expect
cryo
to
run
precisely
with
the
way
that
the
CRI
expects
in
a
reliable
manner,
and
you
can
choose
to
use
cryo,
deploy
it
and
forget
about
it.
We
kind
of
like
to
liken
using
cryo
in
production,
as
choosing
XFS
for
the
file
system
on
your
node.
A
A
Another
reason
why
to
use
cryo
so
cryo
is
built
off
of
the
standard
components
it's
OCI
compliant,
which
allows
us
to
use
some
different
tools
that
we
work
with
to
be
so
it's
compatible.
So
we
have
our
container
storage
library
that
manages
so
when
you
just
create
a
container,
you
have
to
slap
it
down
on
disk
and
a
copy
on
write
style
so
that
you
know
you
have
your
lower-end
merged
stairs
to
be
shared
among
all
these
different
containers
and
upper
doors.
A
Where
you
write
to
container
storage
manages
that
on
the
filesystem,
you
don't
need
a
daemon
to
do
that.
Containers
image
is
used
for
pulling
images
from
registries
and
is
able
to
you
know,
pull
from
any
sort
of
container
registry
and
a
lot
of
different
formats
and
the
like.
We
had
supporting
mirroring
between
registries
and
all
of
this
we
use
CNI.
You
know
de
facto
standard
for
container
networking
now
for
all
of
our
networking.
So
we
don't
reinvent
the
wheel
with
this.
You
know.
A
Cni
is
definitely
you
know,
dominated
this
space,
so
any
C&I
plugin
that
you
want
to
use.
You
can
plop
right
into
cryo
and
it
just
works
and
we
support
any
OCI
runtime,
so
any
container
runtime
that
you
want
to
use.
If,
for
instance,
we
do
we
test
against
cotta,
so
you
can
run
your
cotta
VMs
or
your
cotta
containers
inside
of
a
VM
with
cryo,
and
it
just
works
as
expected.
A
A
So
here's
Dan
Walsh
he's
been
going
on
he's
he's
currently
occupying
the
booth
where,
where
we've
left
from
which
we've
left-
but
he
has
for
a
couple
of
years,
been
on
a
tirade
against
big
fat
container,
Damon's
ones
that
take
over
the
entirety
of
the
container
space
and
do
everything
under
the
Sun
for
a
container.
You
don't
need
that.
You
know
you
don't
need
a
container
Damon
to
be
able
to
write
on
to
a
filesystem
in
a
certain
manner
or
to
pull
a
tarball
and
then
put
it
on
to
a
disk.
A
You
know
using
HTTP,
so
cryo
is
only
for
the
CRI
and
it's
as
little
of
a
daemon
as
possible
for
the
CRI,
so
it
uses
it
and
an
example
of
that
is
for
all
of
our
so,
for
instance,
for
cryo.
All
of
the
containers
that
run
under
it
are
actually
only
managed
by
cryo
they're,
not
child
processes
of
the
cryo
Damon.
So
that
allows
us
to
do
things
like
restart
the
day.
Men
with
containers
running
and
those
containers
aren't
disturbed
because
cryo
is
not
their
parent.
A
There
there's
a
monitor
process
that
cry
all
this
talks
to
and
we'll
talk
about
that
when
we
get
into
architecture,
but
cryo
is
not,
is
not
a
monolith
Damon,
it's
just
about
it's
just
exactly
what
the
cubelet
needs
and
nothing
more
and
finally,
we
are
security
focused.
So
another
thing
that
Dan
Walsh
has
you
know
always
pushed
is:
can
security
and
you
know
really
push
container
security?
Who
here
has
SELinux
enabled
whoo?
That's
awesome,
I'm,
not
actually
sure
I
do
sorry
Dan,
so
we
so
cryo
has
been
designed
to
be
secured
by
default.
A
A
Like
we're
gonna
block
you
there
because
selinux
standpoint,
that's
a
process
breaking
out
of
its
you
know:
desired
needs
we
ship
by
default,
pretty
low
PIDs
limits
so
that
you
know
1024,
so
that
and
it's
a
lot
you
can
adjust
the
page
limit
and
crowd
directly
to
prevent
fork
bomb
attacks.
For
instance,
we
ship
with
fewer
as
few
capability
linux
capabilities
as
possible.
A
Other
container
runtimes,
for
instance,
give
make
node
and
net
raw
because
they
have
to
fulfill
every
single
use
case
that
exists
under
the
Sun
for
running
and
playing
with
containers,
but
cryo
doesn't
need
to
run
with
or
play
with
containers
it's
only
for
using
them
in
production,
so
it
needs.
It
has
a
lot
fewer
capabilities
that
it
needs
and
finally
know
that,
actually
that's
it
when
it's
it's
by
being
a
minimal
daemon
and
only
fulfilling
the
CRI.
It
also
has
a
lower
attack
surface
as
such.
A
A
A
There's
the
image
service,
which
is
responsible
for
pulling
and
listing
images
and
deleting
them
not
pushing
because
coober
that
doesn't
need
to
do
that
and
that's
all
managed
through
containers
image
and
then
there's
the
much
more
exciting
part
of
it,
the
runtime
service,
which
actually
gets
into
the
nitty-gritty
of
how
to
use
containers.
So
it's
you
know,
run
this
pod
and
create
this
container
and
exact
into
this
container.
Oh,
this
is
so.
The
runtime
service
manages
this
to
create
a
container.
A
One
inside
of
the
pin,
namespace
and
Reap
daemon
read
the
processes
that,
like,
if
a
container
dies,
we
don't
want
that
to
be
a
zombie
process.
Each
container
inside
of
a
pod
has
con
mon
instance
and
conmen
is
the
mad
secret
sauce
to
allow
cryo
to
be
a
minimal
daemon.
Con
Mon
is
a
monitoring
process
that
actually
is
responsible
for
listening
to
the
container,
so
come
on
is
responsible
for
keeping
the
standard
in
open.
A
Listening
on
to
the
container
actually
like
hanging
out
with
the
container,
the
cryo
is
able
to
disappear
for
a
second
be
restarted,
change
the
configuration
variable
whatever
and
come
back
up,
and
then
you
know
check
the
state
of
all
the
con
runs
and
that
you
know
keeps
cry
out
nice
and
slim.
We
like
that.
So
now,
first
demos
I'll
pass
it
off
to
man
all.
B
B
This
is
the
script
I
used
and
the
most
important
part
here
is
you're
setting
the
container
runtime
end
point
to
point
to
the
cryo
socket,
so
that
makes
the
cubelet
top
two
cryo
instead
of
docker
or
any
other
default
setup.
Now
we
can
examine
and
see.
If
the
node
is
up,
it
says
it's
ready,
so
we're
good
to
go.
So,
let's
start
off
with
a
simple
nginx
pod.
First.
B
We
can
reach
it
now,
let's
see
if
we
can
get
logs
back
from
that
container,
so
we
will
see
a
get
for
what
we
did.
Let's
try
a
couple
more
and
then
you
can
see
that
the
it's
registering
two
more
and
get
yes
so
so
that
covers
like
starting
a
simple
pod,
just
like
you
would,
but
with
cube.
Ctl
next
example
is
exacting
into
your
pod,
so
exec
is
useful
for
like
getting
into
the
namespaces
of
the
pod
and
examining
it.
B
B
And
it's
up
and
running
so
we're
gonna
attach
to
it,
and
now
we
are
in
inside
that
container,
which
is
running
so
Peter
talked
about
how
cryo
ships
with
fewer
capabilities
out
of
the
box.
So
let's
take
a
look
at
what
capabilities
are
enabled
inside
this
container.
So
take
a
look
here
and
then
see:
let's
try
the
notice
that
we
don't
have
MK
nod
or
is
the
natural.
So
let's
try
pinging
the
other
container
and
see
if
it
actually
works,
so
it
works.
So
how
did
that
work
without
capmetro?
B
B
So
we
talked
about
ASA
Linux,
so
is
anyone
here
familiar
with
the
syntax,
how
it
works?
Okay,
so
SELinux
is
basically
assigning
process
labels
and
then
assigning
labels
to
files,
and
then
there
are
rules
saying
which
label
can
access
which
files,
so
by
default
cryo
will
give
a
unique
acid
Onix
process
label
to
each
container.
That
is
started
inside
a
pod.
So
all
the
all
the
containers
in
the
pod
need
to
talk
to
me
to
be
able
to
talk
to
each
other,
so
they
get
the
same
label,
but
every
pod
has
a
different
security
label.
B
This
container
has
this
context,
and
this
is
the
only
container,
slash
pod
that
has
this
context
and
its
root
filesystem
in
run.
C
is
also
labeled
with
this
content,
so
it
can
only
access
the
files
created
for
this
container.
It
can't
access
anything
else
now
to
simulate
a
breakout.
What
I
have
done
here
is,
for
example,
say
you
re
running
some
process
its
root
and
it
was
able
to
break
outside
of
the
container
because
of
a
zero-day
issue.
B
B
B
B
What's
happening
so
so
cry
CDL,
so
cry
CTL
is
a
is
a
as
a
debugging
tool
that
can
talk
directly
to
cry
out
to
get
information
back
from
port
acting
docker
PS
4G
equivalent,
so
there's
a
cry:
CTL
PS
and
now
we
have
a
web
container.
So
let's
try
to
get
more
information
about
it.
So
we
we
saw
that
how
we
are
using
the
system.
B
D
has
a
C
group
manager
and
the
advantages
is
you
can
do
system
control,
status,
cryo
and
then
specify
the
ID
that
you
see
here
and
then
you
get
a
nice
view
of
what's
running
inside
your
container
and
then
we
also
said
that
Kahneman
is
actually
the
parent
process
of
all
the
processes
running
inside
any
container
of
okra.
So
how
do
we
get
a
view
of
that
simple?
So
do
cryo
convo
knife
in
this,
and
then
you
get
a
view
of
Kannan.
Now,
let's
dig
deeper.
B
B
And
I
think
that
covers
the
basic
operations
of
what
you
can
do
with
cryo.
So
what
we
were
demonstrated
is
like
you
can
do
anything
that
is
expected
of
a
container
runtime
using
cryo,
and
you
have
tools
like
systemctl
and
crisis
ATL
to
be
able
to
debug
and
dig
deeper.
If
you
need
to
understand
more
so
now,
we'll
open
it
up
to
questions.
If
you
want
to
see
anything
or
if
you
have
any
questions,
both
cry
out
we'll
just.
A
So
cryo
is
it
implements
the
Container
runtime
interface
cryo
calls
into
container
runtimes.
Technically
you
could
more
call
it
a
container
manager,
but
sometimes
container
on
time
and
container
manager
is
interchangeable
because
you
know
the
it's
not
you
know
not.
Many
people
use
the
term
container
manager,
so
it's
container
runtime
is
kind
of
all-encompassing,
but
so.
B
At
the
lowest
level
like
run,
C
implements
the
code
which
is
calling
into
the
system
calls
for
spawning
a
container
process
like
setting
up
the
C
groups
on
sharing
the
namespaces
and
so
on,
but
cryo
is
doing
more.
It's
also
managing
your
images
and
it's
basically
satisfying
the
requirements
of
the
cubelet.
It's
like
a
think
of
it
as
a
Orchestrator
like
a
container
Orchestrator
alga,
no,
no
level
runtime.
It's.
D
This
is
in
continuation
to
some
of
my
questions
that
I
asked
offline
as
well,
so
just
wanted
to
understand
more
on
the
differences
between
how
cry
was
used
was
his
continuity,
because
if
I
were
to
use
continuity
instead
of
cryo
I
would
use
a
continuity
shame
and
then
it
would
talk
to
continuity,
and
then
it
would
do
so.
I'm
thinking
of
cryo,
as
here
a
better
replacement
to
using
continuity
in
that
fashion.
So
would
be
glad
if
you
could
elaborate.
B
More
on
this,
like
so
technically
container
D
and
cry
like
operate
in
the
same
space
and
the
container
D
will
also
need
a
CRI
implementation,
which
is
what
you
are
referring
to
as
a
swim,
but
CIO
being
Cuban.
Itis
focus
doesn't
have
the
traditional
layer,
we
are
just
implementing
the
CRI
directly
and
because
we
don't
care
about
any
other
clients,
so
that
hop
is
reduced
and
out
of
the
box
like
support
for
a
ceramics
and
other
features
is
better
and
one
more
thing
I
would
call
out
is
like
our
container
monitor.
B
Kanban
is
written
in
C
to
be
efficient,
and
also
since
we
are
like
the
way,
OCI
runtimes
work,
you
always
need
a
container
monitor
process
and
when
you're
running,
say
100
pods,
you're
talking
about
200
containers
and
200
instances.
The
advantage
of
writing
it
and
see.
Is
you
can
dynamically
link
to
the
library?
So
your
memory
per
process,
overhead
for
the
Kanban
process
is
very
low.
Even
when
you
have
a
lot
of
containers
and
ports
running
thanks.
D
E
F
B
I
think
we
also
like
a
dread,
had
a
run
docker
in
production,
and
we
learnt
lessons
there
with
issues
that
we
saw
at
the
customer's
listen
and
design
cryo
from
the
beginning
to
address
those
problems
like,
for
example,
crys
very
cuban
at
is
focus
right,
so
one
operation
that
the
cubelet
does
frequently
is
missed
everything.
This
is
the
containers
again
and
again,
so
we
wanted
to
make
sure
that
that
operation
is
very
fast.
So
we
do
a
lot
of
caching
in
that
layer.
B
So
we
don't
have
to
call
to
get
the
runtime
state
unless
absolutely
needed,
and
then
we
get
the
state
asynchronously
using
iota
v
and
con
one
writes
the
exit
file.
So
we
kind
of
learn
lessons
from
running
da
current
production
and
design
cryo
to
do
better
than
then
docker,
like
our
plug
numbers
are
better
than
dr.
Alec,
since
we've
now
run
cryo
in
production
that
Red
Hat
in
for
X.
B
So
we
be
used
run,
see
right
now,
but
we
are
looking
into
running
cotta
in
production
as
well,
and
the
use
cases
we
think
cata
would
work
very
well
is
where
you
want
strong
isolation
between
clients
like
if
you
try
to
do
multi-tenancy
or
if
you're,
trying
to
do
privileged
operations
like
you
want
to
do,
builds
inside
your
pods,
then
you
would
want
to
give
more
capelet
capabilities
to
your
pods
and
having
that
VM
isolation
makes
sense
for
such
use.
Cases.
A
A
G
H
B
So
I
think
like
for
debugging
such
cases,
you
would
probably
do
a
development
more
debugging.
Rather
than
trying
to
do
it,
it
will
be
easier
to
say
use
like
pod
man
locally
and
debug.
That
issue
where
you
have
more
control
over
the
logs
and
I
think
we
are
also
looking
into
adding
an
S
trace
base
plugin,
so
that
can
help
with
debugging
like
crashing
containers,
I'm.
H
B
B
The
plague
numbers
are
way
better,
so
I
don't
have
numbers
of
the
top,
but
I
think
we
can
work
to
share
them
with
the
top
of
on
Steam
and
what
I
would
like
to
mention
one
more
thing.
So
we
are
working
on
a
feature
for
117
where
we
get
rid
of
the
pause
container
entirely.
There's
like
no
pause
unless
you're
sharing
a
big
namespace,
so
that
will
further
reduce
the
memory
overhead
per
pod
in
cryo.
I
B
So
right
now
the
status
is
that
pod
man
and
cryo
are
integrated
at
the
container
storage
level.
So
if
you
pull
an
image
with
pod
man,
cryo
can
see
the
image,
but
we
haven't
integrated
at
the
runtime
level
and
like
that
is
one
of
our
top
priorities
to
get
both
of
those
integrated.
So
I
expect
that
within
the
next
few
months,
you'll
see
progress
over
in
that
area
where
pod
men
can
see
crab
containers.
So
you
can
potentially
use
pod
men
to
exact
and
debug
container
by
cryo.
F
B
A
J
A
Where
we
actually
in
where
we
are,
we
have
since
about
114,
we
are
now
at
the
point
where
a
rollover
of
the
cryo
binary
can
do
an
N
minus
1
work
with
the
cryo
config.
You
would
need
to
then
replace
the
crowd
config,
because
we
don't
guarantee
and
-2,
but
right
now
we
we
do
test
that
for
production.
We
do
have
that
sure.
B
Sasha,
who
is
also
cryo
maintainer,
has
been
recently
adding
features
where
we
can
make
changes
to
some
cryo
configuration,
and
you
can
send
a
signal
to
cryo
and
will
pick
up
those
changes.
So
the
goal
is
to
support
that
for
as
many
configuration
settings
as
possible
and
another
another
thing
that
we
are
working
for
is
like
baking,
the
defaults
into
the
crowd.
So
basically
a
crowd
con
should
be
totally
commented
out
and
it
should
have
great
defaults,
and
you
should
have
a
very
good
reason
to
try
and
change
something.
B
J
F
B
So
so
that
shouldn't
technically
be
required.
So,
but
in
now
I'm
going
to
do
Blake
open
shift
land
in
openshift
land.
It
made
sense
for
us
to
wipe
out
the
node
completely,
because
when
we
the
way
we
do
upgrades,
we
are
always
pulling
new
images.
So
all
the
old
images
weren't
needed
anymore
so
that
service
I
think
should
be
optional
if
it
isn't,
but
that
that's
why
it
was
created
for
basically
just
remove
all
the
images,
because
we
know
for
sure
that
when
you're
gonna
upgrade
a
node
we're
going
to
repol
all
the
images
so.