►
From YouTube: CRI-O: The Runtime Control Room - Sascha Grunert, SUSE, Peter Hunt, Urvashi Mohnani, Mrunal Patel
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
CRI-O: The Runtime Control Room - Sascha Grunert, SUSE, Peter Hunt, Urvashi Mohnani, Mrunal Patel, Red Hat
There are many ways to customize the underlying container runtime in Kubernetes. Where Kubernetes API offers many knobs for tuning your workloads, using CRI-O gives you access to even more. CRI-O is a container runtime that provides an incubation space for new runtime features in a secure way. It exposes lower-level features with container annotations, runtime classes, and configuration variables, giving admins control over how and when these features are available, and paving a path for their eventual stabalization and wider adoption in Kubernetes. Join the CRI-O maintainers Peter Hunt, Sascha Grunert, Urvashi Mohnani and Mrunal Patel as they give an introduction of CRI-O and walk through the features and knobs CRI-O exposes.
https://sched.co/ekGC
D
Hi
everyone,
I'm
renault
patel,
I'm
also
a
software
engineer
at
red
hat
and
I'm
a
crime
maintainer
welcome
everyone.
So
what
is
cryo
cryo
is
a
container
runtime
that
implements
the
kubernetes
container
runtime
interface,
using
open
container
initiative,
images
and
runtimes.
It
means
that
cryo
supports,
pulling
oci,
compatible
images
and
running
them
with
oci
compatible
runtimes
such
as
run
c
or
c
run.
The
projects
that
make
up
cryo,
such
as
containers,
image,
storage,
podman
and
run
c
are
continually
pushing
the
envelope
of
container
technology
and
linux
as
they
keep
integrating
new
features.
D
A
All
right,
I
would
like
to
talk
to
you
about
the
basic
configurations
of
cryo,
so
most
people
will
look
at
etc.
Cryo
cryo.com,
which
is
the
main
configuration
file,
and
it's
written
in
tomlin,
so
every
configurable
part
of
cryo
can
be
set
there.
Everything
we
can
adjust
also
via
the
command
line.
Interface,
can
be
done
in
this
configuration
file.
So,
for
example,
we
can
specify
the
storage
driver
and
the
storage
route
we
can
also
set,
which
underlying
oci
run
time
should
be
chosen.
A
So
how
does
this
work
so?
Cryo
supports
dynamic
configuration
which
works
that
we
just
have
to
send
a
sick,
hang
up
to
the
server
and
then
the
server
will
reload
the
options,
so
this
works
for
features
like
the
default,
app
armor
profile
or
the
second
profile,
and
it
also
works
for
the
lock
level
and
the
lock
level
filter.
A
So
those
configuration
files
are
in
alphabetically
order
processed,
so
it
makes
them
easy
to
use
if
you
prefix
them
with
a
number,
for
example,
and
they
also
work
with
the
dynamic
configuration
reload
feature
and
those
drop-in
configurations
have
a
higher
priority
than
the
etc
cryocryo.conf,
which
gives
administrators
the
possibility
to
deploy
a
default.
Configuration
and
users
can
override
those
configurations
by
just
having
their
drop-in
configurations.
A
And
now
I
would
like
to
demo
that
to
you
so
what
we
can
see
here.
I
will
now
start
cryo
with
a
configuration
file
in
my
local
directory
and
I
will
unset
the
configuration
directory
because
I
on
my
local
machine
I
already
have
etc
cryo
cryo.conf.d
available
and
to
not
have
any
effect
on
my
demonstration.
I
will
just
put
it
to
an
empty
string.
A
A
We
are
probably
more
or
less
bound
to
warnings
or
info
messages
which
are
related
to
the
cni
network,
so
to
change
that
we
can
go
into
our
cryo
configuration
and
go
to
the
lock
level
and
set
it
to
debug.
Then
we
save
it
and
my
demo.
I
will
now
restart
cryo,
and
here
we
can
see
that
we
are
now
in
debugging
mode
and
if
we
now
run
any
rpc
request,
then
we
can
see
that
everyone,
every
request,
is
locked
so
and
those
log
files
can
be
pretty
huge
in.
D
A
Because
the
verbosity
is
now
really
really
high
and
to
have
a
better
debugging
possibility,
we
added
something
like
a
lock
level
filter.
So,
for
example,
we
now
can
go
into
our
cryo
configuration
and
change
the
log
level.
This
is
a
regular
expression.
It
works,
for
example,
we
can
change
it
as
case
insert
insensitive,
regular
expression
and
go
for
request,
and
now,
let's
just
we
don't
have
to
restart
cryo
at
all,
we
can
just
reload
cryo.
We
are
sending
zig
hang
up
like
this.
A
Cryo
also
gives
us
the
indicator
that
we
reloaded
the
configuration,
so
it
reloads
the
configuration
it
updates
the
configuration
file
and
we
can
also
see
okay.
The
log
filter
is
now
set
to
request,
and
if
we
now
run
cryctl,
then
we
can
see
that
we
only
really
lock
the
requests,
and
this
way
administrators
can,
for
example,
really
good
filter
on
those
log
messages.
A
What
do
we?
What
can
we
do
for
the
drop-in
configuration
files?
We
can
also
start
cryo
by
changing
the
configuration
file
directory
to
my
local
directory
and
then
cryo.com.d,
and
if
we
do
that,
then
we
can
see
that
in
this
directory,
for
example,
is
a
log
file,
a
log
modification
file
which
resets
the
log
filter.
A
So
in
the
configuration
file
we
change
the
log
level
filter
to
log
only
the
requests
and
in
this
overwrite
file
we
just
unzip
it
again
and
if
we
now
run
crycto,
then
we
can
see
that
we
get
all
data,
not
only
the
requests.
We
also
get
the
responses.
For
example,
here
we
have
the
list
image
response,
which
lists
all
the
images
available
on
my
local
machine
and
that's
it
for
my
little
demo
and
now
I
would
like
to
hand
over
back
to
rashi.
B
So
cryo
uses
the
container
storage
library
to
manage
copy
and
write
file
systems
for
containers
and
the
containers
image
library
for
pulling
images
from
container
registries.
These
libraries
are
also
shared
across
our
other
container
tools
like
bond
build
up
and
scorpio,
so
having
a
shared
backend
means
that
we
can
also
share
configuration
files.
So,
to
give
an
example,
let's
say
I
want
to
block
image
pools
from
a
specific
registry.
B
So,
instead
of
having
to
configure
this
for
each
container
tool
that
I
use,
I
can
just
put
it
in
a
shared
file
that
all
the
container
tools
can
access.
So
we
have
three
shared
files
like
this.
The
first
one
is
the
registries.conf
file,
which
is
used
to
configure
anything
related
to
your
registries,
so
users
can
go
there
to
configure
the
insecure
registries
block
registries,
their
list
of
unqualified
search
registries
as
well
as
mirror
setup.
B
The
second
file
is
the
policy.json
file.
This
file
holds
policy
requirements
for
a
container
image,
specifically
around,
where
you're
pulling
the
image
from
so
you
can
have
policy
requirements
for
various
transports,
including
trusted
keys
and
input
signatures.
The
third
file
is
the
storage.com
file.
This
is
used
for
configuring
options
for
your
container
storage,
so
stuff
as
stuff,
like
your
driver,
your
rundown,
your
graph
route,
etc,
and
now
now
we'll
talk
about
container
the
networking
configuration.
D
So
cryo
uses
cni
for
configuring
networking
for
kubernetes
parts.
Cni
is
widely
adopted
as
a
networking
solution
in
kubernetes,
so
cni
configuration
mainly
consists
of
two
settings.
One
is
the
part
to
the
directory
in
which
the
configuration
is
stored
and
the
second
is
where
the
plug-in
binaries
are
stored.
So
you
can
see
in
the
example
on
the
slide,
we
have
a
network
door
and
a
plug-in
doors
option
for
both
of
these
settings.
In
addition,
we
also
support
setting
a
default
network.
D
If
you
intend
to
do
so,
and
then
cry
also
supports
bootstrapping
networking
through
daemon
sets,
so
you
can
have
a
daemon
set
that
copies
over
the
configuration
and
the
binaries
to
these
directories
and
cryo
will
pick
up
the
configuration.
So
any
parts
that
start
up
after
that
configuration
will
pick
up
the
cns
settings.
C
In
addition
to
all
of
these
options
that
you
know
in
the
crowd,
trial
also
has
the
ability
to
edit
the
runtime
classes
and
handlers.
So
in
kubernetes
you
know,
differing
workloads
have
differing
needs
of
performance
and
security,
and
their
users
need
a
way
to
toggle
between
different
runtimes.
So
in
so
kubernetes
has
this.
Has
this
feature
runtime
classes,
which
is
slated
to
be
ga
and
1.20,
which
asks
the
cri
implementation
to
use
a
different,
runtime
or
users
can
also
make
it
use
runtimes
differently?
C
C
So
in
the
bottom
left
here
you
can
see
that
this
is
a
basic
runtime
class
example
and
the
runtime
class
name
is
correspond
with
one
of
the
runtimes
in
the
run
times
table.
So
perhaps
the
runtime
class
name
would
be
run
c
high
performance
and
then
a
pod
would
and
then
so
and
we'll
go
into
a
little
bit
more
in
detail
on
the
right.
We
have
an
example
of
a
couple
of
different
ways
that
you
can
configure
cryo
to
have
different
runtimes
and
we'll
go
into
a
bit
more
in
detail.
C
C
In
addition
to
all
of
the
ways
that
you
can
create
your
crowd,
there's
also
the
pod
annotations,
which
is
a
pretty
generic
feature
generally
known
in
kubernetes,
but
I'm
just
going
to
real
quick
over
it.
It's
you
know
a
generic
key
value
map
in
the
pod
metadata
and
it
allows
for
passing
through
of
unstructured
data
varying
levels
of
the
stack.
C
What
this
allows
us
to
do
is
cryo
has
some
specific
annotations,
userness
mode,
annotation
and
synthesize
annotation,
and
these
annotations
allow
admins
to
our
users
to
request
differing
configurations
of
the
runtime
and
then
cryo
can
use
those
annotations
to
to
configure
the
runtime
as
long
as
that
user
is
allowed
to
do
that
and
we'll
go
into
a
username
mode.
Annotation
example
a
little
bit,
but
first
in
summary,
admins
have
the
ability
to
configure
cryo
in
a
varying
number
of
ways:
storage,
image,
networking
all
of
these
varying
options.
C
B
So
this
is
helpful
in
workloads
where
the
expanse
of
context
switching
cannot
be
tolerated.
So
the
user,
the
admin
of
the
user,
gets
the
privilege
to
disable
cpu
load,
balancing
and
certain
cpus.
So
I
have
a
quick
demo
on
how
this
is
done.
Okay,
so
in
this
demo
here
I
have
an
openshift
cluster.
So
the
first
thing
that
I
did
with
my
cluster
was:
I
created
a
machine.
Config
object
that
drops
in
a
config
file
at
cryo.com.d
called
99
onetimes.config.com.
B
So
in
this
config
file,
I
am
configuring
my
runtime
class,
my
high
performance
runtime
class,
so
that
was
just
the
base64
content,
so
we
can
go
on
the
node
now
to
see
what
the
file
actually
looks
like
under
the
crowd
of
confident
folder,
and
we
can
see
here
that
I
have
created
a
runtime
called
high
performance
here.
This
is
important
because
we
will
be
creating
a
one-time
class
using
oc
and
cryo
needs
to
know
that
there
is
a
high
performance
runtime
that
exists,
so
it
knows
to
run
the
pre-start
and
free
stock
books.
B
So,
since
we're
already
on
the
node,
we
can
check
the
value
of
the
flags
for
the
various
cpus
that
I
have
on
this
node.
This
is
important
to
keep
in
mind
what
the
value
here
is.
So
four,
seven,
eight
three
and
four
six
five:
five,
because
once
we
disable
load
balancing
on
the
cpu,
the
value
will
drop
by
one.
B
So
if
you
can
see
in
the
cube.com
file
here,
let
me
scroll
down
right
here.
I
don't
even
see
my
cursor,
but
it
was
set
to
static.
So
now.
The
next
thing
is,
I
created
a
runtime
class,
a
high
performance,
runtime
class.
The
handler
name
was
high
performance
and
I
called
it
hyperf
test.
This
is
just
a
quick
description
of
what
the
runtime
class
looks
like.
B
So
now
we
are
ready
to
create
our
pod,
where
we
would
like
to
disable
cpu
load
balancing.
So
here
for
the
part
I
have
the
set,
the
cpu
load,
balancing,
cryo
io
annotation
to
true.
I
have
set
the
runtime
class
name
to
the
hypertest
runtime
class
that
I
created,
and
I
have
requested
two
cpus
under
my
resources.
B
B
And
here
we
can
see
that
the
values
dropped
down
by
one.
It
is
four
seven,
eight,
two
and
four
six
five.
Four
now
for
both
cpu
one
and
cpu
three,
we
can
just
take
a
look
at
cpu
2,
for
example,
just
see
what
the
to
double
check
the
values
that
that
one
is
still
enabled-
and
we
didn't
accidentally
disable
that
so,
as
you
can
see,
the
values
are
greater
than
the
disabled
one.
B
So
let's
quickly
delete
the
pod
here
and
we'll
go
back
on
the
node
and
check
the
same
flag
value
again
so
yep
and
then
we're
going
to
catch
that
value
for
cpu
one
and
three
and
yep.
As
you
can
see,
it
went
back
up
as
those
load
balancing
on
these
two
cpus
are
enabled
again
and
that's
all
I
have
for
my
demo.
A
All
right,
let's
talk
a
bit
about
security
related
configurations,
so
usually
the
container
runtime
interface
defines
the
main
behavior.
How
a
container
runtime,
which
implements
the
kubernetes
api
should
behave.
But
this
behavior
is
probably
not
always
the
most
secure
one.
So,
for
example,
if
we
specify
a
second
profile
and
put
it
and
put
it
into
an
empty
string,
then
this
will
be
considered
as
unconfined,
and
this
applies
to
basically
all
workloads
in
the
cluster
who
do
not
use
the
runtime
default
second
profile
or
a
localhost
profile.
A
So
turning
this
option
on
will
by
default,
use
the
runtime
default
second
profile,
which
ships
with
cryo
to
all
workloads
who
do
not
really
specify
something
like
unconfined
or
localhost
profile,
and
I
prepared
a
demo
for
you
to
show
it
to
you.
So,
first
of
all,
let's
have
a
look
at
this
new
configuration
option.
So
it's
part
of
cryo.conf
and
we
can
just
have
a
look
into
the
description
of
the
option
and
by
default
it
it's
set
to
false.
A
So
if
we
now
run
cryo
and
for
our
demonstration
purposes,
we
will
unset
the
configuration
directory
and
then
create
a
kubernetes
workload,
and
then
we
can
see
that
zaccom
is
not
enabled
on
this
workload,
so
we
can
just
verify
it
by
using
proxy
status
and
second
points
to
zero.
So
it's
not
enabled
at
all.
A
If
we
now
run
cryo
with
that
configuration
directory
and
create
a
new
kubernetes
workload,
then
we
can
verify
now
in
the
same
way
that
seccomp
is
enabled
for
that
workload,
and
this
is
a
great
enhancement
to
default
security
and
is
a
good
example
of
strong
security
defaults.
From
my
perspective,
that's
it
for
my
demo.
C
Thanks
sasha,
so
next
we're
going
to
talk
a
little
bit
about
username
spaces
in
kubernetes
and
cryo.
So
real,
quick,
I'm
just
going
to
do
a
quick
overview
of
your
name
spaces
for
people
who
aren't
aware
you
can
think
of
of
users
and
groups
as
people
and
the
available
range
of
ids.
All
of
them
on
the
host
is
like
a
house.
The
username
space
is
people
living
not
in
the
full
house,
but
in
a
little
dollhouse
within
the
house,
as
in
a
subset
of
the
range
of
ids,
without
going
too
far
into
it.
C
C
The
happy
news
is
that
much
like
a
pig's
limit,
which
was
an
option
that
cryo
introduced
way
at
the
beginning
of
cryo
to
prevent
fork
bombs
from
dosing
a
system
and
that
wasn't
supported
in
kubernetes
until
119,
I
believe
or
118
somewhere
around
then
cryo
has
added
support
for
username
spaces
before
upstream
cube
has
solidified
on
the
implementation,
and
this
allows
admins
to
play
around
with
username
spaces
and
use
it,
but
we
make
sure
to
implement
it
in
a
way.
That's
secure.
C
So
I'm
going
to
do
a
quick
demo
on
that
all
right,
so
so
we're
going
to
start
off
by
just
creating
a
vanilla,
kubernetes
cluster
running
cryo
in
it,
and
while
this
bootstraps
I'm
going
to
show
a
little
bit
more
about
what
we're
going
to
be
working
with
so
we're
going
to
start
off
with
our
this
is
our
runtime
class
for
the
user,
ns
so
notice.
We
have
the
name
run
to
userness
and
our.
D
C
Annotations
is
io,
grenades,
cryogenic
mode.
So
that
means
that
this
username
space
is
allowed
to
interpret
the
I
o
kubernetes
cryo
userness
mode
to
configure
username
space
for
a
newly
created
pod
moving
forward
a
little
bit,
then
we're
going
to
look
at
our
three
queries:
objects
that
we're
going
to
create.
So
first
we're
going
to
create
a
runtime
class
and
that's
going
to
use
the
handler
to
run
to
userness
it's
going
to
be
called
run,
userness
class
and
any
pod
that
wants
to
be
able
to
have
the
userness
mode
interpreted
needs
to
use
that
class.
C
C
Then
we're
going
to
create
also
a
not
username
pod.
This
one
is
going
to
attempt
to
get
the
annotation
auto,
but
it's
actually
not
going
to
work
because
cryo,
because
it
isn't
configured
with
the
correct
runtime
class
name,
so
cryo
will
refuse
to
interpret
the
annotation
so
it'll
just
be
given
the
default
username
space.
This
allows
the
admins
to
have
finer
green
control.
It's
going
to
sleep
for
two
days
and
that'll.
Allow
us
to
differentiate
the
two
in
a
ps3.
C
This
is
the
beginning
of
the
uid
range
and
that's
the
end
of
the
your
day
range
all
right,
the
beginning
of
uid
range
with
respect
to
the
containers
username
space-
and
this
is
the
beginning
of
the
uid
range
from
the
respect
of
the
host
username
space.
So
the
container
thinks
that
it's
running
in
uid0,
but
actually
it's
running
in
uid,
20,
000
and
that
allows,
and
then
there
are
65
k
allocated
ids,
which
should
be
enough
for
our
two
pid
pods.
C
C
So
if
it
happens
to
break
out
goodness
for
good,
then
it
won't
really
be
able
to
do
anything
that
from
its
elevated
capabilities
from
within
the
username
space,
and
here
just
to
demonstrate
that
it's
gated
on
the
runtime
class
we're
going
to
show
the
not
userness
pod.
So
here
we
see
from
the
perspective
of
the
username
space
it's
running
as
root
or
it's
uid
map,
because
it's
root
and
from
the
host
begins
with
root,
and
this
is
just
all
of
the
available
uids.
So
basically
what's
happening.
C
Is
this
pod
is
running
in
the
host
username
space,
so
if
it
is
specified
to
run
as
a
if,
if
the
pid
one
in
the
container
is
running
as
root,
then
it's
actual
root
on
the
host
and
any
privileges
it
has
is:
are
the
privileges
from
the
perspective
of
the
house
and
notice.
How?
Even
though
we
attempted
to
give
the
annotation
to
the
pod,
it
didn't
work,
it
wasn't
given
the
annotation
or
it
was
the
annotation
wasn't
interpreted
so
the
username
space
wasn't
created
and
that
meant
an
admin
stopped.
B
Oh,
thank
you
for
that.
Awesome
demo,
peter
so
cryo
currently
is
an
incubating
project
in
the
cncf.
The
most
recent
version
of
cryo
is
119
and
we
continue
to
walk
in
lockstep
with
the
kubernetes
version.
Cryo
is
stable
and
it
is
the
container
runtime
that
is
being
used
by
susicaps
and
openshift4x
clusters
and
production.
B
We
are
also
moving
some
of
cryo
components
over
to
rust
to
improve
performance,
and
we
see
cryo
graduating
in
the
near
future.
If
you
want
to
find
out
more
about
cryo
here
are
some
resources
for
you.
We
are
available
on
slack
and
irc,
and
we
have
this
awesome.md
dock
on
our
repo,
which
has
links
to
past
talks,
as
well
as
any
articles
and
resources
around
cryo,
and
we
also
have
a
pretty
cool
coloring
book
that
talks
about
the
different
container
tools
and
how
they
work
together.