►
From YouTube: CNCF TAG-Runtime: Cloud Native Open... Alex Scammon, Zbynek Roubalik, Ricardo Aravena, Samuel Ortiz
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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 TAG-Runtime: Cloud Native Open Source Core Components - Alex Scammon, G-Research; Zbynek Roubalik, Red Hat; Ricardo Aravena, Rakuten; Samuel Ortiz, Apple
Learn about the CNCF open source projects that allow users to run cloud native workloads! This session will cover: 1) Overview of the TAG-Runtime, how to join, and how to get involved. 2) Update of working groups (new, existing, and potential) within the scope of the TAG . 3) How the TAG provides advise to the CNCF TOC. 4) Future trends for cloud native runtime technologies in the TAG scope such as containers, Virtual Machines, Edge/MLOps and WebAssembly.
A
A
A
So
we
work
closely
with
the
toc
I'm
one
of
the
co-chairs.
We
also
have
tech
leads
that
do
things
or
or
do
different
diligence
in
in
the
tech,
and
they
work
closely
together
with
the
toc
work
closely
with
the
the
community
and
we
meet
every
first
and
third
thursday
of
every
month
and
we're
happy
to
have
anybody
join
these
meetings.
A
So
the
scope
of
the
attack
contains
a
lot
of
different
projects,
so
there's
a
wide
variety
of
them.
You
have
the
run
times.
You
have
the
projects
that
allow
you
to
run
workloads
at
the
edge.
You
have
things
like
confidential
containers
that
allow
you
to
run
containers
in
a
secure
way.
You
have
things
like
cada
that
allows
you
to
run
auto
scaling
depending
on
different
types
of
metrics.
A
A
So
we've
also
had
some
presentations
since
the
last
kubecon,
so
the
tag
is
continually
expanding,
the
set
of
projects
and
the
scope-
and
you
know
the
engagement.
So
these
are
some
of
the
examples
of
different
projects
in
the
different
areas,
so
we're
expanding
on
cluster
management,
how
to
know
how
to
run
multiple
clusters
in
different
clouds
and
different
locations
on-prem
or
in
cloud
service
providers.
We
have
different
projects
also
to
help
users
run
kubernetes
at
the
edge
like
k0s.
B
Thank
you
appreciate
that
I'm
alex
from
g
research,
a
quantitative
research
firm
in
the
uk
and
I'll
talk
to
you
about
this
batch
system
initiative,
but
I
wanted
to
point
out
that
it's
friday
on
the
final
day
of
the
conference,
long
conference,
it's
just
before
lunch,
I
didn't
think
that
I
would
be
able
to
engage
enlighten
connect
with
you.
Just
if
I
had
bare
words
on
the
page,
so
instead
I'm
going
to
try
and
keep
it
interesting
with
some
animals.
B
B
We
came
to
the
tag
runtime
group
to
discuss
our
own
project
armada,
where
we
have
a
multi-cluster
approach
to
batch
scheduling
and
in
the
course
of
that
conversation
it
came
up.
The
runtime
group
had
been
chatting
with
a
bunch
of
other
batch
projects
and
we're
all
sort
of
saying
the
same
thing
and
that
maybe
we
should
have
a
separate
conversation
specifically
around
batch.
B
At
the
same
time,
there's
a
another
batch
initiative
that
I'll
mention
a
little
more
later
aldo
talked
about
it
yesterday,
which
is
a
kubernetes
batch
conversation
and
and
both
of
these
conversations
were
happening.
The
there's
a
kubernetes
batch
working
group,
but
it
felt
like
there
was
space
for
this
other
batch
conversation
where
people
who
are
creating
batch
projects
on
top
of
kubernetes
should
come
together
and
have
a
conversation.
So
that's
the
history
and
and
sort
of
what
this
is
and
I'm
wondering.
B
So
this
is
sloths,
and
this
is
a
bed
of
sloths.
This
batch
of
sloth
is
a
bed
of
sloths
the
kinds
of
projects
that
we're
talking
about
are.
I
mentioned
our
multi-cluster
approach
called
armada.
There's
volcano,
which
you
saw
on
a
couple
slides
earlier,
there's
mcad,
ibm,
there's
unicorn
and
cloudera.
There's
slurm
is
represented
in
the
in
the
conversation
as
well.
B
Scheduling
is
next
on
the
agenda
and
features
like
that
that
if
we
get
into
kubernetes
all
of
these
higher
level
projects
would
be
more
capable,
be
able
to
to
use
kubernetes
better,
whereas
in
this
cncf
batch
working
group
we're
talking
more
about
the
projects
that
have
been
built
on
top
of
kubernetes,
largely
because
we
couldn't
actually
do
batch
scheduling
effectively
with
the
the
features
that
kubernetes
has
had
up
until
now.
So
just
trying
to
make
that
distinction
just
a
little
bit
clearer,
but
please
come
to
both
come
to
all
we.
B
What
are
my
notes?
Oh
yes,
penguins.
They
are
a
waddle
of
penguins,
it's
fun.
Let's
see!
Do
I
have
with
this
one
there's
flamingos,
it's
a
flamboyance
of
flamingos
and
really
the
the
last
bit
is
to
to
just
join
us
in
conversation.
We've
got
a
a
schedule
of
every
other
week,
we're
having
a
meeting
about
the
cncf
working
group.
It's
on
mondays
at
7,
30
p.m.
It's
7
30
a.m,
pacific
time,
hopefully
that
lines
up
with
everyone.
B
There's
some
information
that
you
can
get
a
hold
of
us.
There's
a
slack
channel.
There's
this
zoom
room
every
two
weeks
we'll
be
there
chatting
about
stuff.
Please
feel
free
to
reach
out
to
us
directly,
either
me
or
klaus,
or
I
think
it's
alex,
but
wait
wait.
Any
of
us
three
can
direct
you
to
how
to
get
more
involved
in
the
conversation,
and
these
are
otters
and
otters
were
oh
what
what
are
otters
they
a
raft
of
otters.
Yes,
thank
you!
Thank
you.
B
C
So
I'm
going
to
transition
us
to
talking
about
the
iot
edge
space,
so
our
working
group
was
previously
part
of
the
kubernetes
space
and
now
we're
moving
to
the
runtime
tag
and
the
cncf
to
a
bigger
and
broader
scope,
since
there's
a
lot
happening
on
the
iot
and
edge
space.
So
to
start,
I'm
going
to
talk
about
some
of
the
cncf
sandbox
projects
in
this
area
and
then
I'll
talk
about
one
more
in
particular
and
then
tell
you
how
to
get
involved.
If
any
of
this
interests
you.
C
So
when
we
talk
about
the
cloud,
everything
is
homogeneous
there.
A
lot
of
the
servers
are
the
same
they're
in
a
static
environment.
But
when
you
move
to
the
edge
there's
a
variety
of
devices
with
different
compute
and
ranging
from
the
larger
compute,
we
have
those
servers
that
are
on-prem
on-prem
on
the
edge
and
more
and
more
people
are
wanting
the
same
level
of
orchestration
that
they
can
have
in
the
cloud
for
their
workloads
on
the
edge.
C
Also,
some
of
these
servers
have
less
compute,
so
they
themselves
are
more
constrained,
and
so
the
kubernetes
distro
that
you're
deploying
there
needs
to
take
up
less
resources.
So
another
project
that
handles
this
is
k3s.
They
kind
of
slim
down
kubernetes,
so
that
you
can
run
it
on
some
of
these
smaller
servers
that
are
processing
all
that
data
around
the
environment,
on
the
edge.
C
Also,
when
we
talk
about
the
edge
space
more
and
more
there's
a
discussion
of
web
assembly
on
the
server.
That's
because
when
you
make
your
applications,
webassembly
modules
instead
of
containers,
they're
smaller,
it's
a
binary,
that's
portable
across
different
os's
and
platforms,
and
it
has
quick
startup
time
and
better
security
or
just
as
good
of
security.
C
C
These
are
sensors
controllers
devices
that
just
have
enough
compute
to
do
exactly
what
they
need
to
do,
and
so
we
can't
put
any
extra
workloads
on
them.
So
the
question
becomes:
how
can
we
then
easily
get
data
from
these
devices
and
let
let
our
applications
running
on
our
servers
on
the
edge
leverage
that
and
one
cncf
sandbox
project
that
I
work
on
aims
to
solve
this
problem?
C
So
just
how,
in
your
pod
spec,
you
could
request
cpu
and
memory
ocry
enables
you,
then,
to
declaratively
request
an
iot
device,
so
an
ip
camera
usb
thermometer
a
robot
arm.
So
it's
extending
that
declarative
nature
of
kubernetes
to
these
iot
devices
and
it's
purely
kubernetes
native.
So
it
runs
on
any
kubernetes
distro
and
you
can
learn
more
about
it
and
the
documentation
there
too.
C
So
if
any
of
these
projects
interest,
you
please
come
join.
The
working
group,
like
I
said,
we're
transitioning
right
now
from
kubernetes
to
cncf,
so
we're
changing
all
of
our
locations,
of
where
our
slack
exists,
where
our
github
page
is
so
a
good
place
to
start
would
be
to
join
our
current
slack.
All
the
conversation
will
happen
there
and
we
do
have
bi-monthly
meetings
that
we're
continuing
to
have
during
this
transition
and
as
a
part
of
this,
we're
building
out
a
new
charter
to
kind
of
draft.
C
D
Hello,
everyone,
my
name
is
vignega,
I'm
from
redhead
I'm
working
on
k,
native
and
keta
projects,
so
I
will
speak
up
specifically
about
this
project
so
and
unfortunately
I
don't
have
any
animals
in
the
slide,
so
I
wouldn't
beat
you,
but
you
know,
so
what
is
kedar
like?
What
is
the
aim
of
this
project?
So
what
we
are
trying
to
do
is
basically
to
make
kubernetes
even
driven,
auto
scaling
very
simple,
very
user
friendly.
D
So
you
don't
have
to
configure
anything
almost
just
you
know
couple
of
lines
of
code
and
that's
all
with
that.
We
can
auto-scale
kubernetes
deployments
or
we
can
even
schedule
new
jobs
based
on
some
events
happening
in
in
external
service.
So
imagine
you
have
some
external
service
that
is
processing
some
messaging
some
messages
and
you
would
like
to
process
them.
So
sometimes
you
might
need
to
use
jobs
or
deployments
based
on
the
based
on
the
type
of
workload
that
you
would
like
to
prefer.
D
One
of
the
benefit
of
this
approach
is
that
we
are
able
to
scale
the
resources
down
to
zero,
so
you
can
save
resources
on
your
cluster
and
we
have
connectors
to
more
than
50
different
adapters,
different
external
services
that
you,
you
can
use
to
scale
them.
So
we
have
connectors
to
kafka,
prometheus,
ruby,
mq,
some
aw
services
etc.
D
So
to
give
you
like
the
very
specific
or
to
describe
the
idea
on
this
example,
so
this
is
very
simple
example:
application
that
consume
messages
from
some
external
systems.
So
in
this
case
it
is
a
kafka
consumer
application
that
consumes
messages
from
kafka
topic
and
okay.
We
we
have
this
application
deployed
on
our
cluster
and
we
would
like
to
auto
scale
this
application.
D
So
this
is
the
very
same
use
case
very
same
example,
but
we
are
using
cada
in
this
moment,
so
you
don't
have
to
change
anything
in
the
application.
Anything
in
the
in
the
kafka
broker
setup
you
just
you
just
set
up
cata
and
you
very
easily
can
define
that.
Okay,
let's
scale
this
deployment
based
on
the
metrics
from
this
kafka
broker,
and
it
should
it
should
do
the
job.
D
So
we
are
really
trying
to
make
it
very
simple
for
users,
and
this
is
about
the
project,
so
the
project
itself
started
as
a
collaboration
between
microsoft
and
red
hat
a
couple
years
ago,
then
we
transitioned
to
cncf,
and
we
are
incubating
an
incubation
phase
at
the
moment,
and
I
would
like
to
say
that
it
really
helped
the
project
a
lot
like
moving
to
cncf,
because
we
have
all
the
support
and
all
the
all
the
needs
that
we
need
to.
You
know
recover.
D
E
E
It
can
be
a
tdx
amd,
acv,
sgx
whatever,
but
really
the
idea
is
to
say
we
want
each
and
every
workload,
each
and
every
pod
to
get
its
own
dedicated
enclave
and
that
this
is.
This
is
very
different
from
what
a
lot
of
not
not
a
lot.
Many
csps
are
currently
offering,
which
is
confidential
computing
nodes,
so
they
give
you
a
node,
a
kubernetes
node
and
that's
running
inside
a
configuration
competing
vm.
E
E
It's
all
about
protection,
it's
not
about
making
workload
secure
it's
about
making
them
more
secure
than
what
you
currently
have
with
your
regular
kubernetes
security
setup
we're
protecting
workload
from
the
host.
That's
the
very
the
most
important
promise
from
confidential
computing.
So,
basically,
with
confidential
containers,
we
are
removing
the
host
from
tcb
you're
running
your
kubernetes
pod
in
your
communities,
cluster,
and
you
do
not
have
to
trust
the
the
csp
anymore.
You
basically
don't
have
to
trust
about
what
he's
providing
you
with
your
your
kernel,
your
workload,
your
pod,
your
container
images.
E
E
It
basically
provides
an
enclave
per
container,
so
you
can
run
a
pod
with
multiple
containers
and
typically
one
of
them
will
run
inside
an
sjnx
enclave,
because
this
is
this
is
not
as
it
doesn't
support.
Multiple
hardware
like
like
complete
containers,
the
only
sport
intel
hdx.
So
it's
a
different
different
approach.
It's
more
granular,
but
it's
it's
less
flexible
confidential.
E
That's
the
high
level
diagram
lots
of
buzzwords
a
lot
of
boxes.
I
want
to
make
sure
you
don't
understand
this,
so
you
go
come
back
to
me
and
ask
questions
so.
Basically,
and
really
I
mean
the
idea
here
I
mean
the
couple
ideas
that
I
want
you
to
take
back
is
again:
you
have
a
pod,
it's
running
inside
a
confidential
vm,
so
this
is
protected
by
confidential
computing
at
the
port
level,
and
this
is
a
virtual
machine.
E
E
The
big
difference
between
catacontainers
is
the
the
left,
the
right
hand
side
of
this,
of
this
diagram,
where
we
run
the
entire
attestation
and,
last
but
not
least,
the
containers
images
in
that
architecture
they're
living
in
the
guest.
So
the
host
never
sees
container
images
anymore,
kubernetes
itself
doesn't
touch,
pull
or
mount
or
sees
or
modifies
any
of
your
container
images
with
that
architecture.
Come
back
to
me,
if
you
want
more
details,
come
back.
E
Enclaver
is
the
second
one,
it's
again
slightly
different
and
you
can
see
that
you
have
multiple
runtime
for
for
multiple
many
of
your
containers,
so
you
can
have
a
run
container,
which
is
just
a
regular
container,
the
same
thing
that
you
would
run
on
any
kubernetes
pod,
and
then
you
have
something
different
there,
the
top
the
right-hand
side
at
the
top.
Where
you
see
that
one
of
your
container
one
your
application
is
running
inside
an
enclave,
and
this
is
really
an
sgx
enclave.
E
It
only
supports
intel
sgx.
So
this
is.
This
is
quite
different
from
the
conversation
containers,
but
it
leverages
computational
computing
to
protect
part
of
your
workload
with
kubernetes
join
us.
This
is
our
github.
Every
thursday
we
have
a
meeting
on
zoom
we're
a
cncf
sandbox
project,
so
we
have
our
own
slack
room
and
everything
we're
just
very
busy,
so
yeah
join
us
help
us
contribute
come
if
you
have
any
interest.
Thank
you.
F
G
B
E
B
E
B
H
B
Is
for
alex
and
sorry,
though,
for
which,
for
this
working
group,
the
the
batch
initiative
as
opposed
to
the
kubernetes
one
or
yes,
yes,
sort
of
I
mean
the
conversation
is
growing
as
we
speak,
so
it's
not
yet
very
well
defined,
but
in
general
I
imagine
that
we
will
be
keeping
up
to
date
on
what
all
of
the
various
projects
are
doing.
How
we're
reacting
to
the
the
changes
that
the
batch
kubernetes
group
are
implementing
in
kubernetes.
I
C
C
We
talked
about,
for
example,
secure
device
onboard
there's
discussions
of
how
do
we
onboard
and
provision
servers
at
the
edge
that
discussion
is
not
kubernetes
specific,
it's
specific
to
all
technology
that
we're
talking
about
on
the
edge,
and
so
it
really
was
an
opportunity
to
kind
of
expand
beyond
the
kubernetes
space.
As
we
talk
about
handling
these
both
constrained
iot
devices
and
larger
servers
that
are
running
on
the
edge.
J
G
E
Okay,
sorry,
but
if
you're,
if
and
that's
not
really
related
to
competition
computing
itself,
but
it's
more
related
to
other
virtualization,
if
you
receive,
if
your
workload
is
heavily,
I
o
bound.
This
is
probably
the
worst
case
scenario
for
running
anything,
not
only
containers
but
any
workload
inside
a
virtual
machine.
If
you're,
if
you
receive,
if
your
workload
is
io
bound-
and
you
do
you
do
you
do
not
do
a
direct
device
assignment.
E
Basically,
you
don't
have
direct
access
to
your
gpu
or
your
networking
card,
or
your
disk,
then
you're
going
to
do
a
lot
of
memory
and
vm
exits.
Basically,
and
it's
going
to
cost
you
a
lot,
but
that's
not
related
to
configuration
containers.
It's
more
related
to
hardware,
virtualization
itself,
composition
containers
adds
latency
in
terms
of
boot
time,
because
you
you,
you
do
have
to
do
the
remote
destination.
E
If
you
want
to
be
able
to
verify
what
you're
running,
that's
it,
it
highly
depends
on
the
kind
of
attestation
you're
running
and
it
potentially
adds
overhead
when
running
with
memory
encryption.
But
this
is
typically
according
to
silicon
vendors,
again
very,
very
minimal,
so
they
the
whole
memory.
Encryption
is
hardware
implemented
in
the
memory
controller,
so
the
overhead
is
is
very,
very
small,
typically
not
measurable
in
meaningful
way,
so
hope
it
answers
questions.
K
E
I
think
from
what
we
see
is
that
is
that
all
the
vendors
are
actually
kind
of
moving
away
from
this.
This
kind
of
implementation,
the
sgx
trust
zone,
kind
of
implementation,
where
you
have
this
application
boundaries
and
they're
going
into
the
suv,
tdx
and
arm
v9
is,
is,
is
really
providing
the
same.
E
The
same
architecture
basically
saying
we
are
going
to
extend
the
hardware
virtualization
isa,
the
instruction
set
to
support
computational
computing
through
memory,
encryption
measurement
and
attestation,
and
also
protecting
the
the
cpu
states,
your
caches,
your
registers.
So
this
is
basically
taking
the
current
hardware,
virtualization
implementation
and
extended
it
to
support
contextual
computing,
and
this
is
very,
very
different
from
sgx
from
trustzone
from
all
those
implementation,
and
this
is
where
the
industry
is
going.
If
you
look
at
arm
v9,
which
is
the
next
arm
design,
it's
not
instantiated
yet.