►
From YouTube: Kata Containers + Cloud-Hypervisor: Virtualization for Cloud Native - Samuel Ortiz, Intel
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Kata Containers + Cloud-Hypervisor: Virtualization for Cloud Native - Samuel Ortiz, Intel
At KubeCon NA 2017, the speakers introduced the Kata Containers project to the public for the first time. After two years of development and community collaboration, we have made containers running in virtualized sandboxes a commodity. On the other hand, virtualization has become more lightweight and container-friendly. At the beginning of 2020, Kata project is kicking off the 2.0 dev-cycle, and the idea behind it is “virtualization for Cloud Native”. The new open-source cloud-hypervisor will be a cornerstone for the goal -- not only by helping Cloud-Native infrastructures run better with hardware-virtualized isolation but also by pushing the virtualization tech forward: - Share resources across sandboxes but keep the security boundary clear. - Provision resources to sandboxes on-demand and promptly. - The collaboration between host user-space tool, VMM, and the guest kernel.
https://sched.co/Zej5
A
A
You
can
tell
your
cri
runtime,
which
container
runtime
you
want
to
use
you
can
you
can
tell
it
to
use,
run
c
or
you
can
tell
it
to
use
catacontinus
and
catacontainers
as
a
runtime.
Instead
of
creating
a
process
running
on
the
host
or
a
few
processes
running
on
hosts
that
make
the
pod
cata
containers
will
use
hardware
virtualization
as
a
container
isolation
layer.
A
You
had
complexity
compared
to
to
the
run
c
setup.
Now
you
have
more
components
that
are
running
with
cata
containers.
You
have
you
have
a
virtual
machine.
You
have
a
few
components
running
inside
the
virtual
machine.
You
have
an
additional
protocol
between
the
cada
runtime
and
the
cata
agent
inside
the
virtual
machine
to
communicate
through.
A
A
Okay,
so
what
we
did
with
cada
containers
2.0
is
improving
and
working
on.
Many
of
the
components
that
are
specific
to
cata
contains
one
of
them,
as
I
mentioned,
is
the
cata
agent.
This
is
an
agent
running
on
the
virtual
machine
that
manages
the
pod
and
the
the
pod
workloads
in
the
virtual
machine
and
it
communicates
through
a
specific
protocol,
typically
through
a
vertical
v-stock,
socket
that
communicates
back
to
the
to
the
cat
at
runtime
and
the
guy
agent.
A
Is
that
it
was
consuming
about
10
megabytes
of
memory,
so
each
and
every
pot
that
you
launch
includes
a
cata
agent
and
that
cat
agent
was
consuming
10
megabytes
of
physical
memory
from
the
host.
So
that's,
that's.
That's
quite
a
bit
of
overhead
that
you
induce
with
with
with
your
agent,
so
we
did
two
things
we
re-implemented
cata
in
rust
from
go.
A
The
cata
agents
are
in
rust
from
go
and
we
also
switch
from
a
grpc
to
ttr
pc
and
when
combining
those
two
together,
we
significantly
reduced
the
memory
overhead
that
the
ketta
agent
added
to
the
to
the
cata
containers
project
from
roughly
10
megabytes
to
something
between
one
and
two
megabytes.
So
with
that
new
implementation
of
the
agent
you
save
about
eighty
percent
of
the
of
the
agent
memory
functions,
so
that's
that's
significant
improvement.
A
We
also
simplify
the
the
protocol
between
the
the
agent
and
the
anticli
runtime
to
make
it
easier
to
maintain
and
also
easier
to
understand,
easier
to
extend
as
well.
If
we
ever
need
to,
we
took
a
lesson
from
from
kata1.x
and
understood
what
is
really
needed
as
a
protocol
between
the
the
host
and
the
cata
agent,
and
we
kind
of
work
on
that
and
make
it
simpler.
A
You
need
to
have
a
dmm
that
supports
a
bunch
of
specific
order,
virtualization
feature
to
support
the
entire
cri
specs.
Otherwise,
you
kind
of
you
won't
be
able
to
support
all
of
it.
So
we
work
on
this.
We
work
on
a
new
vmm
called
cloud
upvisor,
which
runs
on
top
of
kvm
and
which
is
based
on
the
upstream
rossvmn
project
and
cloud
hypervisor
is
implementing
the
full
cri
specification.
A
A
But
the
difference
between
cloud
advisor
and
one
of
the
main
difference
between
cloudwiser
and
qmu
is
the
the
language
that
is
that
it
is
implemented
in
cloud.
Hypervisor
is
implemented
in
rust,
whereas
a
qmu
is
implemented
in
ce
rust.
Being
arguably
one
of
the
safest
system,
programming
languages
out
there
and
last
but
not
least,
cloud
provisor
is
pretty
fast.
So
the
the
boot
latency
are
quite
reduced
with
or
minimized
with
the
cloud
advisor
and
the
memory
footprint,
which
is
typically
under
10
megabytes
per
per
vmm,
with
with
cloud
visor.
A
A
So
what
we
added
is
a
catamonitor
component,
and
here
it
may
not
be
strictly
in
that
diagram,
but
there's
one
catamonitor
component
per
node
and
that
kind
of
monitor
daemon,
basically
monitors
the
entire
set
of
containers
running
on
your
node,
and
that's
that
cata
monitor
implementation,
integrates
seamlessly
with
premises.
As
I
said,
and
it
provides
a
very
interesting
set
of
metrics
from
the
hypervisor
itself.
A
So,
from
the
whole
virtualization
layer
from
the
agent
we
get
metrics
from
the
agent
as
well
and
from
the
virtual
machine
from
the
guests
running
inside
the
virtual
machine
as
well.
Another
interesting
features
that
we
added
as
part
of
the
of
the
canon
containers
project
is
a
pod
overhead
which
allows
us
to
specify
through
the
runtime.
A
Okay,
another
very
interesting
aspect
of
what
we're
what
another
interesting
feature
that
is
going
to
be
landing
in
canada.
Containers
to
zero,
eventually,
is
how
we
fetch
the
container
images
so
typically,
today,
the
way
container
images
are
handled
through
containers
is
that
you
pull
the
container
images
from
the
host
and
you
expose
that
container
image
into
the
virtual
machine
because
you
need
to
run
the
pod
inside
the
virtual
machine.
So
obviously
your
virtual
machine
needs
to
have
access
to
this
to
this
container
image.
A
One
of
the
latest
vertical
specific
specification
edition
could
be
the
legacy
9p
protocol,
or
it
could
be
something
like
virtual
block,
but
basically
your
host
is
fetching.
The
image
is
managing
the
images,
and
then
you
expose
that
image
of
those
images
into
the
virtual
machine
and
what
we
do
with
what
we
are
planning
to
do
with
the
catalog
containers
to
the
zero
is
to
have
an
optional
way
to
optionally,
be
able
to
fetch
the
container
images
from
inside
the
virtual
machine.
A
So
that
sounds.
That
sounds
quite
like
a
pretty
big
change
and
it
it
is
one.
But
the
idea
behind
all
this
behind
pulling
images
from
the
code
is
to
basically
extend
the
catacontainer
threat
model.
We
want
to
extend
it
to
the
point
where,
as
a
tenant,
you
no
longer
have
to
trust
your
csp.
You
no
longer
have
to
trust
your
host.
A
You
can
basically
say
I'm
running
my
workload
inside
a
virtual
machine
and
when
you
combine
this
with
technologies,
like
total
memory,
encryption
that
are
available
to
to
virtual
machines
on
many
architectures,
you
can
basically
ensure
that
your
host
no
longer
sees
what
your
container
is
running.
No
longer
see
what
your
the
the
memory
that
your
container
is
consuming
and
now,
if
you
can
also
pull
the
images
directly
from
the
virtual
machine,
you
can
guarantee
that
your
you're
that
you
host,
that
your
csp
is
no
longer
seeing
what
your
container
is
actually
running.
A
So
we
want
to
extend
the
thread
model
of
catacontainers
to
where
it
is
today
to
the
point
where
it
can
also
protect
the
container
workloads
from
the
csp
itself,
which
is
quite
a
an
interesting
and
also
interesting
from
business
perspective
and
from
a
technology
perspective
as
well.
Interesting
features.
A
It
I
wouldn't
say
by
default,
because
this
is
this
is
already
partly
the
case
with
containers1.x,
but
in
some
cases
with
with
catacontainers1.x,
you
may
end
up
with
this
specific
architecture.
So
when
you
launch
a
catalog
container,
the
catalog
container
runtime
launches
the
vm
yeah,
the
link
between
the
the
the
virtual
machine
and
the
serial
runtime
is
done
through
a
set
of
components,
a
container
d
shim
or
a
container
runtime,
shame
and
the
cata
container
shim,
and
you
basically
have
a
pair
of
shims
for
each
and
every
process.
A
A
What
we
did
is
is
work
with
the
cri
runtime
maintainers,
the
container
d1
and
the
cryo1
to
move
to
a
much
simpler
architecture
and
a
more
much
more
scalable
architecture.
We
work
on
a
runtime
scheme.
Api
called
runtimescheme
api
v2
that
allows
us
to
have
one
long-standing
daemon
for
catalog
containers.
The
kalashin
v2
and
basically
having
it,
allows
us
to
have
one
running
daemon
for
a
pod,
so
one
single
one
single
single
demon
per
pod
instead
of
n
per
containers
inside
the
pot.
A
A
This
is
the
set
of
categories
2.0
and
also
combined
with
with
cloud
advisor
as
a
vmm,
we're
planning
to
move
forward
the
the
virtualization
support
in
the
cloud
native
ecosystem
and
make
it
even
more
seamless,
much
lighter
and
much
more
transparent
than
it
is
today.
Thanks
a
lot
for
your
attention
and
I'm
not
ready
to
take
any
further.
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
A
Is
this
a
problem
for
the
trust
model,
especially
in
some
of
the
future
future
model
where
the
csp
is
untrusted
infrastructure?
Con?
Oh
another
question!
Sorry,
this
is
jumping
up.
Oh,
I
know
sorry,
I'm
gonna
take
that
one.
First!
Okay,
let
me
repeat
the
question
other
infrastructure
container
inside
a
pod
which
end
up
inside
the
vm
boundary,
for
example.
Sidecars.
A
Is
this
a
problem
for
the
truss
model,
especially
in
some
of
the
future
modes
confidential
computing?
Where
the
csp
is
untrusted?
I
guess
this
could
be.
This
could
be
an
issue
especially
for
things
like
confidential
computing.
Definitely
when
the
csp
is
entrusted,
you
probably
don't
want
to
run
sometime
something
from
the
csp
inside
the
the
catacontainer
security
boundary.
A
A
This
is
really
a
problem
for
the
for
the
future
for
well,
not
future
one,
because
it
it
can
be
an
optional
one,
but
for
the
quote-unquote
confidential
computing
trust
model,
it
is
gonna,
be
it
is
going
to
be
a
problem
and
you
you
really
want
to
move
that
those
infrastructure
container
outside
of
the
of
the
vm
boundary.
I
guess
there's
going
to
be
some
limitation
there.
Obviously
you
won't
be
able
to
let
your
csp
see
anything
and
everything
that
you
do
and
you
you
you
may
be.
A
You
may
be
losing
some
of
the
metrics,
for
example,
on
what's
happening
inside
a
virtual
machine.
Actually,
you
may
be
losing
quite
a
bit
of
them,
but
I
guess
this
is.
This
is
kind
of
the
there's
always
a
price
that
you
pay
for
security,
and
I
I
guess
this
could
be
a
this.
This
could
be
seen
as
as
one
of
them
another.
A
A
A
A
Another
question
I
think
I
only
have
a
few
minutes
left
is
scala
2.0,
already
available
or
still
in
development.
2.0
is
available.
It's
both
it's
it's
stealing
development.
So
there's
a
I
can.
I
can
put
a
link
there.
I
will
I'll
put
a
link
in
the
answer
box,
but
really
quickly
to
to
answer
this.
Catalog
2.0
is
a
work
in
progress.
A
The
the
stable
and
production
ready
version
of
cat
is
still
one.x,
but
2.0
is
where
most
is
where
the
the
the
continuous
community
is
trying
to
shift
its
efforts,
its
development
efforts.
So
it's
it's
going.
It's
making
a
very
good
progress,
and
it's
already
usable
I
would
say
I
we
can
certainly
not
claim
that
it's
that
it's
production
ready,
but
this
is
something
you
can
go
and
and
build
it
yourself.
There's
there
are
packages
for
it.
A
A
Cloud
advisor
and
firecrackers
share
a
lot
of
a
lot
of
code.
They're
they're,
both
consuming
an
upstream
project
called
ras
vmm
raspbian
is
basically
a
set
of
virtualization
crates
that
firecracker
and
cloud
advisor
are
using
and
the
so
they're
sharing
quite
a
bit
of
code,
they're
they're,
basically
aiming
at
a
different
use
cases.
A
I
think
firecracker
is
simpler
and
smaller
it.
The
the
simplicity
and
the
simplicity
comes
with
restrictions,
the
things
that
you
cannot
do
with
firecracker
for
not
because
their
technical
reason
for
not
do
for
not
implementing
that
in
firecracker,
but
it's
it's
basically
because
the
firecracker
community
doesn't
see
a
reason
why
implementing
those
features
like,
for
example,
device,
passthrough
or
host
file
system
sharing,
and
that
that
creates
limitation
on
on
what
kind
of
kubernetes
workloads
you
can
support.
A
So
if
you
have
to
do
a
few
work
around
supports
as
much
as
many
as
many
workloads
as
you
would
with
cloudvisor
cloud
advisor
does
supports
a
device
passthrough.
It
does
support,
hosts,
hosts
file
system
sharing
and
basically
it
supports
the
entire
cri
spec.
So
there
are
the
use
cases
for
for
both.
If
you
want
something
very
slim
and
simple,
you
probably
want
to
look
at
firecracker,
but
you
need
to
know
what
kind
of
restrictions
you're
going
to
have
to
to
support
what
kind
of
what
type
of
vm
image
is
used.
A
What
hypervisor
is
used,
so
the
hypervisor
there
are
two
hypervisors
today
that
are
used,
acorn
and
kvm,
and
acorn
is
an
hypervisor
on
its
own.
Kvm
is
the.
I
would
say
most
widely
used
linux
hypervisor
and
on
top
of
kvm,
then
you
cata
container
supports
vmm
like
cloud
advisor
firecracker
qmu.
They
all
run
on
top
of
kvm.
A
So
basically,
the
two
underlying
hypervisor
are
kvm
and
acorn,
and
on
top
of
kvm
you
can
select
what
kind
of
emm
you
want
to
use
depending
on
the
again
the
kind
of
workload
you
want
to.
You
want
to
use
with
kubernetes,
qmu
and
cloud
visor
supports
the
entire
ci
spec,
and
things
like
firecracker
comes
with
some
some
limitation
on
what
kind
of
part
of
the
spec
they
support.
A
Isn't
vm
a
higher
cost
to
pay
for
the
trust
boundary?
Well,
it
depends
on.
It
depends
on
what
you
want
to
do.
So
the
question
is:
isn't
avert?
Are
our
virtual
machine
a
higher
cost
to
pay
for
the
trust
boundary
virtual
machine
people
think
about
virtual
machine
as
something
very
expensive
and
and
very
costly?
A
I
think
with
gala
containers
we're
showing
that
virtually
the
virtual
machine
overhead
is
definitely
not
as
high
and
and
large
as
people
think
we
boot
a
a
a
containers
with
qmu
or
fi
quarker
or
cloud
visor
in
typically
less
than
one
second,
in
the
in
the
worst
case,
the
the
memory
overhead
is,
it
can
be
very
small
depending
on
the
workloads.
So
I
I
think
the
there
is
a
cost.
A
I'm
not
I'm
not
saying
there
isn't
a
cost,
but
if
you're
looking
for
having
this
additional
isolation
layer
based
on
hardware
and
using
other
virtualization,
I
think
this
is
the
kind
of
cost
that's
that
you're
willing
to
pay.
So
what
we're
seeing
is
that
yeah
that
that
would
be
my
last
question
and
we're
running
out
of
time.
But
what
we're
seeing
is
that
people
running
in
production
containers
they
they
run
cata
containers
for
very
specific
security
reasons
they
want
to.
A
They
want
to
run
multitask,
kubernetes
multi
hardware
to
tendency,
and
they
see
cata
containers
as
a
very
good
way
to
implement
this
answering
another
question
here.
But
yes,
it's!
If
you're
looking
at
this
kind
of
this
kind
of
use
cases
where
you
you
want
to
have
this
additional
layer
of
security.
This
is
typically
the
kind
of
willing
to
pay.