►
From YouTube: CNCF SIG-Runtime: The Cloud Native Runtimes Outlook - Ricardo Aravena & Renaud Gaubert
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.
CNCF SIG-Runtime: The Cloud Native Runtimes Outlook - Ricardo Aravena, Rakuten & Renaud Gaubert, Nvidia
This talk will discuss the purpose of the CNCF SIG-Runtime, together with how we identify projects for CNCF admission and where we see the future of runtimes in the cloud native ecosystem. The session will cover: - Overview of the SIG-Runtime, how to join, and how to help. - Overview of related projects in the CNCF and the projects that have presented in our meetings. - Existing Workgroups in the SIG and how to get involved. - Future trends for cloud native technologies in the SIG scope such as containers, VMs, WebAssembly and MLOPs.
A
So
our
charter,
so
the
cncf
runtime,
is
there
to
help
enable
the
adoption
of
the
execution
of
all
the
different
types
of
workload,
types
that
you
can
run
in
cloud
native
environments,
so
that
could
be
latency
sensitive.
It
could
be
batch
type
of
workloads
and
any
any
type
of
specialized
workload.
We
also
have
three
toc
liaisons
cncfdoc.
A
A
We
also
support
different
community
members
and
different
projects
navigate
the
cncf
ecosystem.
Sometimes
it
can
be
a
little
bit
daunting
with
all
the
different
projects.
We
help
the
existing
projects
through
the
process
in
the
cncf
to
go
through
the
different
stages
of
sandbox,
incubation
and
graduation.
A
All
of
this,
in
the
hope
that
getting
more
contributors
and
and
getting
more
involvement
from
their
community,
so
in
the
scope
of
the
sig,
we
we
have
many
different
projects
in
different
areas.
So
here
are
some
of
the
logos
or
some
of
the
projects
that
have
presented.
Some
of
them
have
actually
applied
for
different
stages
in
the
cncf.
Some
of
them
are
in
graduated
state,
for
example,
container
d
and
cryo
are
in
kubernetes.
A
This
is
the
the
main
project
that
started
the
cncf,
there's
more
projects
at
the
edge
like
cube,
edge
or
open
yurt
and
other
projects
that
allow
you
to
run
web
assembly
on
your
system.
So
a
lot
of
different
areas,
so
more
details
about
the
scope
here
so
in
different
areas.
So
we
have
the
general
workload
orchestration
with
kubernetes
and
volcano
and
metalcube.io.
A
You
also
have
specific
runtimes,
like
the
webassembly
runtimes,
the
container
image
registries,
the
runtime
shims
like
container
id
and
cryo
another
scope
and,
in
the
sake,
is
the
special
purpose
operating
systems.
Some
example
of
that
is
flag
cars
operating
system
just
meant
for
running
containers.
A
And
finally,
we
also
take
care
of
work
groups
so
so
onto
the
fall
under
the
six
right.
Now
we
only
have
one
work
group
work
group,
but
we
are
hoping
to
get
some
more
in
the
future.
So
renault
we'll
talk
about
the
container
orchestrated
device
work
group
that
we
currently
have
so
in
the
runtime
scope.
A
So
another
project
that
got
involved
in
our
sick
and
had
the
presentation
is
sscm,
and
this
is
a
webassembly
runtime,
so
web
assembly
or
the
community
created
this
standard
called
wazi
that
allows
you
to
run
web
assembly
on
a
system,
as
initially
webassembly
was
intended
more
for
the
browser.
But
with
this
standard
you
can
run
it
as
a
executable
as
a
as
a
runtime.
A
Crosslist
is
another
project
that
presented,
and
this
is
also
in
the
web
assembly
space
and
they
allow
you
to
run
webassembly
on
top
of
kubernetes,
so
you
can
create
your
webassembly
module,
compile
it
that
way.
Your
wasm
file
and
you
can
push
it
over
to
a
container
registry,
and
and
with
this
project
like
when
you
have
all
the
components
installed
under
your
kubernetes
cluster,
you
can
actually
instantiate
a
pod
with
webassembly
modules
such
as
like
a
regular
workload.
Just
like
you
would
run
a
container.
A
We
have
harbor,
but
some
of
the
differences
with
this
project
is
that
they
aim
to
be
more
of
a
lighter
weight
image
registry
that
can
be
run
all
the
time
on
top
of
kubernetes
and
maybe
possibly
in
the
future,
allowing
users
to
distribute
this
container
images
across
all
your
nodes
of
your
kubernetes
clusters
in
in
in
a
faster
way,
maybe
possibly
using
some
protocol
like
a
pgp
type
of
mechanism,
and
this
project
is
also
written
in
rust.
It's
part
of
the
reason
why
they
are
aiming
to
be
lighter
weight
and
faster.
A
So
rootless
community
also
presented
and
got
involved
in
r6.
So
this
is
a
mechanism
that
allows
you
to
use
this
username
space
facility
in
the
linux
kernel,
where
you
can
run
a
container
type
of
mechanisms
as
root
inside
a
root
namespace,
but
on
the
host
you
will
be
a
different
user,
so
hence
you're
calling
it
or
they're
calling
it
ruthless
containers.
Because
you
know
on
the
host
you,
you
might
be
user
1000,
but
inside
that
username
space
you
might
be
rude
and
then
as
root
you
can
actually
instantiate
different
containers
in.
A
A
So,
essentially,
you
can
define
your
operating
system
in
what
they
call
an
init
file
like
a
v
init
file,
and
you
can
tell
exactly
what
to
do
inside
the
vm
and
no
need
to
have
daemons
like
ssh
demon,
shell
or
login.
So
something
very
lightweight
and-
and
the
idea
here
is
that
it's
more
protected
and
it's
also
lighter
weight
so
that
it
becomes
more
efficient
and
faster,
so
very
interesting
project
and
we'll
see
more
of
this
project
in
the
future
as
well.
A
A
A
B
B
What
that
means
is
that
you,
as
a
user
or
as
a
cluster
admin,
we
are
trying
to
make
your
experience
seamless.
We
don't
want
you
to
switch
into
your
nodes
to
install
custom,
run
times,
custom
drivers
or
even
kind
of
tinker
with
your
distributions
and
travels
being
vendors
users
and
cluster
administrators
and
clusters
that
have
these
devices.
B
We
are
familiar
with
the
problems
and
we've
laid
out
a
roadmap
to
try
to
to
show
what
are
the
main
issues
that
we've
been
facing.
The
first
one
really
is
at
the
runtime
level.
It's
about
exposing
the
device
to
container.
It's
actually
a
really
hard
problem,
because
the
space
is
actually
very
fragmented.
B
B
While
podman
has
a
concept
of
hooks
and
nomad
has
its
own
concept,
if
you
look
at
the
different
runtimes
out
there,
it's
actually
pretty
much
the
same.
Everyone
has
implemented
their
own
mechanism
and
all
these
differences
across
the
space
makes
it
very
difficult
for
vendors
to
provide
a
uniform
experience
and
actually
the
same
set
of
features
across
the
different
projects,
meaning
that
some
projects
have
actually
different
features
than
others,
but
that
makes
the
super
burden
actually
pretty
high.
B
Finally,
when
you
are
at
a
cluster
level,
when
your
application
actually
needs
to
use
multiple
nodes,
whether
you
are
in
small
or
big
large
scale,
deep
learning
application
or
you
are
a
super
computer.
You
typically
need
to
make
sure
that
your
nodes
are
actually
kind
of
close
to
each
other
so
that
when
they
start,
when
your
applications
start
talking
to
each
other
and
talk
and
talking
through
the
network
to
each
other
you're,
not
incurring
a
really
heavy
penalty.
B
And
so
one
of
the
one
of
the
solutions
or
one
of
the
kind
of
projects
that
I'm
going
to
talk
to
you
about
today,
is
focused
on
the
runtime.
It's
called
cdi
the
container
device
interface
and
it's
a
unified
plug-in
architecture
for
red
dots.
Three
things
you
need
to
know
about
it.
It's
based
on
the
cni
model,
the
container
networking
interface.
B
It
describes
the
devices
that
are
available
in
the
machine
and
describes
the
operations
the
runtimes
performed
here.
On
the
slide,
you
can
see
a
very
simple
example
where
a
vendor
has
created
a
json
file
at
ccdi
vendor.json
that
describes
that
there
is
a
device
that
is
vendor.com
flash
device
on
the
node.
It
has
a
device
type,
sorry
on
the
node.
It
has
a
single
device
on
the
node.
That's
called
my
device,
where
the
only
operation
that
a
runtime
must
perform
is
to
mount
the
def
card.
One
and
dev
card
render
one
into
the
container.
B
This
is
the
space
of
a
vendor,
as
a
user
you'll
be
actually
more
interacting
with
your
container
in
time.
It's
actually
not
that
different
from
a
normal
experience.
You
just
invoke
your
runtime
with
the
flag
dash
dash
device.
My
device
or
vendor.com
device
equals
my
device,
and
you
just
invoke
your
image
and
your
command
from
a
kubernetes
perspective.
B
We've
actually
kind
of
created
this
proof
of
concept.
That
shows
what
we're
intending
to
do.
It's
based
on
the
same
model
as
volumes
that
you
can
see
in
kubernetes
and
the
general
idea
is
that
when
you
as
a
cluster
administrator
provision,
machines
that
have
physical
devices
on
them,
you're
also
going
to
tell
kubernetes
that
you
have
a
what
we
call
device
class.
B
B
B
We've
also
created
a
roadmap
for
cgi
by
the
time
you
see
this
presentation,
we'll
probably
be
in
public
availability
with
a
first
feature
in
pond
man
or
a
first
implementation
being
available.
In
pun,
we've
been
working
with
different
runtimes,
for
example,
continuity,
pod
man
in
different
groups,
for
example
the
hpc
advisory
council,
on
how
this
solution,
how
the
specification
should
look
like
we've
been
showing
some
pucks.
B
B
We
are
also
working
towards
having
the
first
version
available.
The
set
of
things
that
we
have
defined
are
having
support
at
least
two
major
run
times.
It
seems
to
be
given
a
podman
and
container
d
that
are
going
to
be
supporting
cdi
having
a
better
level
in
kubernetes
and
making
sure
that
we
are
working
to
have
at
least
three
different
plugins
from
there
we'll
be
tagging
a
version
of
v1.o,
so
that
users
understand
that
their
plugins
will
actually
be
supported
over
time
and
we
can
actually
lay
out
the
groundwork
for
an
ecosystem
to
build.
B
If
you
want
to
contribute,
if
you
have
ids
we'd
love
to
hear
from,
you
feel
free
to
drop
into
our
tuesday's
bi-weekly
meetings
and
if
you're
working
with
our
specifications
with
our
projects,
let
us
know
either
by
dropping
a
meeting
or
even
sending
an
email
to
sick,
runtime,
we'd
love
to
hear
from
you
and
that's
it.
For
the
sick,
runtime
presentation,
you
can
read
a
lot
more
on
what
we're
doing
for
instagram
time
or
cod
on
the
cncfio
mailing
list.