►
Description
Containers seem to be like virtualization, just better. Is it just a matter of time until all VMs will have vanished, and their workloads live their life in containers? Well - This depends on the problem you try to solve. This talk is about looking at why virtualization is still needed in a container world and where it is found. We’ll specifically look at virtualization related projects like ClearContainers, frakti, virtlet, and KubeVirt in the Kubernetes context, their use-cases, commonalities, and differences. After the talk an attendee should have gained overview over which projects exist in the Kubernetes world, and for what they can be used. This talk is for everybody who would like to secure their containers, or who would like to run classical VMs on Kubernetes.
A
Hello,
nice
to
see
all
of
you,
thank
you
that
you
found
the
way
to
DEFCON
to
see
that
here
in
Nice
preneur.
My
name
is
Fabio
I'm,
going
to
speak
about
virtualization
in
container
environment
or
in
a
containers.
World
I
reached
world
domination
about
myself
before
I
start
on
farming
doors.
I
work
louder:
oh
okay,
my
name
is
Fabian
Dortch
and
I
work
for
redhead,
not
here
in
Brno,
but
in
Germany
and
I
worked
used
to
work
on
virtualization.
A
Actually,
I
continue
to
do
so,
but
in
a
container
world
and
I
want
to
share
what
I've
seen
so
far
with
you,
and
you
might
be
interested
in
that
all
right.
So
in
order
to
understand
why
all
of
this
is
interesting,
you
know
putting
containers
into
a
virtualization
context
or
vice
versa.
Let's
take
a
look
at
how
they
relate
to
each
other.
A
So
let's
get
the
vault
virtual
machine
or
to
stage
and
on
the
other
side
we
we
invite,
can
the
container
to
the
stage
and
then
we'll
have
a
little
battle
to
see
how
they
compare
to
each
other.
What
why
do
I
want
to
do
that,
because
I
want
to
compare
the
two
technologies
or
the
two
concepts
to
then
see
why,
if
it
makes
sense
or
why
it
makes
sense
to
to
to
to
have
them
in
the
same
context
or
why
doesn't
make
sense
whenever
you've
got
a
question?
A
Please
lift
your
hand
and
interrupt
me
and
if
I
fade
off,
then
please
remind
me
to
speak
up
again.
So
we
start
off
with
I
structured
these
to
your
questions
in
roughly
in
the
in
the
in
the
lifecycle
of
a
container
or
a
VM.
So
usually
we
start
with
building
something
so
we're
building
a
VM
and
I
mean
vm's
have
been
around
for
like
I,
don't
know.
A
20
years,
roughly
I
mean
they've
been
around
since
the
60s,
but
I
think
in
our
context,
really
in
the
Linux
world,
like
20
years
or
so
or
50,
and
we've
got
a
rich
ecosystem.
Oh
well,
we've
got
several
ecosystems
which
don't
overlap
necessarily
which
you
can
use,
fill
VMs
they're.
All
different,
like
we've
got
I
mean
the
closest
family.
To
me
is
the
lippert
family,
with
version
stalwart
builder
and
all
these
tools
to
build
the
Evans,
and
how
does
that?
Look
in
the
container
side
well
in
containers
and
I
mean
that
is
very
charming.
A
Since
the
beginning,
there
was
like
one
tool
to
build
containers,
and
that
was
dr.,
build
with
docker
files,
you're
a
very
simple
format.
You
had
a
few
imperatives
of
directions
in
that
file
and
you
can
build
container
right
away.
So
we
did
not
have
this
fragmentation
of
tools
right
at
the
beginning.
Maybe
it
comes
up.
We
see
it
a
little
bit.
So
that's
really
convenient
and
I
mean
it's
like
granted.
Containers.
You
do
a
really
good
job
there
you
have
docker
file,
you
run
it.
It's
really
fast
to
build
it.
A
So
that's
really
a
good
experience
compared
to
what
we'd
need
to
do
with
the
ends
in
VMs.
Usually
I,
don't,
depending
on
what
you
want
to
do.
You
can
use
sysprep
for
windows
or
a
cloud
in
it.
Oh
well
cloud
in
its
runtime
thing,
you
can
use
anaconda
kick-starts
to
build
a
fedora
image
or
rail
image
or
debian
tools
or
Susy
tools.
All
of
them
have
tools
to
build
images
into
VMs
and
then
have
an
image
which
you
can
deploy
to
your
environment,
but
it's
much
more
effort
to
to
get
an
image.
A
So
alright
and
then
you've
got
the
image.
And
what
do
you
do
now
so
in
our
vm
world?
Well,
we
invented
a
lot
of
protocols
and
we
have
concepts
like
from
OpenStack.
We've
got
cinder,
for
example
or
clans
to
distribute
images
in
over
it.
We've
called
our
console
I'm,
an
overt
guy
I
used
to
work
an
overt,
and
we
have
our
concepts
to
distribute
images,
and
there
are
others.
If
we
look
at
vert
builder,
they
just
provide
them
as
compressed
images
on
and
on
and
on
a
web
server,
and
you
can
download
them.
A
So
we
have
the
image
format
defined,
but
the
the
whole
workflow
of
how
to
work
with
an
image
how
deliberate
how
to
ship
it.
That's
not
really
so
slick
so
I
wonder.
How
does
that
look?
For
you
can
the
container-
and
here
we
can
say
well,
it's
pretty
much
standardized
since
the
beginning,
like
there
was
doctor,
push
also
built
into
that
single
command,
and
the
protocol
I
mean
the
server
side
was
pretty
much
standardized.
The
way
how
you
push
it
wasn't
pretty
much
standardized.
So
it's
very
convenient.
A
You
run
docker
build
tea
with
your
tag
and
run
then
dr.
push
and
push
the
world
wide
web
on
docker
hub,
which
might
be
loaded
with
images
or
you
push
it
to
Kai,
Ora
or
not
the
registry.
But
the
essence
is
it's
really
slick
again.
You
know,
there's
a
single
workflow
of
how
to
push
it
to
different
places
and
from
there
you
can
consume
it,
I
mean
a
user
or
yourself.
A
You
can
then
just
name
the
registry
when
you
want
to
run
a
container
and
it's
there,
you
don't
have
to
you
know,
there's
all
this
diversity.
You
don't
have
to
know
a
lot,
because
it's
so
much
standardised,
that's
really
convenient
okay,
but
images
are
nothing
without
the
content.
So
what
can
we
run
in
an
image?
I
mean
you
ship
something,
and
then
you
need
to
see
what
kind
of
ship
I
mean
we're
shipping
an
empty
image.
It's
not
really
useful
because
it
cannot
even
launch
it.
A
So
what
can
we
put
into
images
in
the
virtualization
work?
We
can
be
proud.
We
can
put
a
lot
of
stuff
into
picture
into
VM
images.
We
use
it
for
a
lot.
We
use
it
to
test
operating
systems,
so
you
can
pull
while
Linux
operating
or
you
can
theoretically
pull-up
I
wonder.
Can
you
terrifically
put
everything
you
can
put
on
a
virtual
machine
into
on
a
physical
machine
into
VM?
Yes,
you
can
it's
like
you
know
it's
a
it's
a
one-to-one
mapping
of
your
disk
of
your
physical
Hardware.
A
A
So
and
containers
well,
you
know,
don't
necessarily
have
blocks
which
you
operate
on,
but
you
have
files
and
you
can
effectively
put
everything
into
them
as
well.
We're
we're
you
know
we're
friendly.
We
say
you
can
put
everything
in
there.
No,
we
know
that
you
know
you
can
say
from
Ubuntu
from
reticle
from
rail,
from
fedora
from
debian
from
from
gen,
actually
I
wonder
if
they're
a
base
image
for
Gen
2
in
yeah.
B
A
Very
cool
and
all
the
other
districts,
so
in
reality
you
know
you
can
package
a
lot
of
the
or
you
have
access
to
all
your
packages.
You
know
from
your
favorite
Linux
distribution
in
your
container
image.
That's
very
convenient,
so
I
think
here
it's
a
part.
We
can
put
pretty
much
the
same
stuff
into
VMs
as
we
can
put
into
containers.
A
So
now
we
ship
all
our
favorite
distribution
images
through
node
and
now
the
question:
if
we
launch
them,
you
know
the
cool
thing
about
virtualization
is
you
can
not
just
want
one
virtual
machine
on
a
node?
No,
you
can
run
arrange
at
them
like
I,
think
I'm,
getting
crazy
like
20
or
50
virtual
machines
on
a
single
host.
I
know
it
sounds
crazy,
but
it
really
is
reality
and
for
containers.
How
does
it
compare
there?
Well,
the
benefit
of
containers
and
that's
probably
due
to
how
they
implement
it.
A
A
So
the
list
is
getting
pretty
long
but
I'm
getting
to
the
end
so
fast.
It's
it's
always
important
to
be
fast.
We
want
to
boot
things
fast,
won't
build
things
fast
and
VMs
are
good.
We
did
a
lot
of
improvements
of
the
last
years
to
improve
performance.
You
know
there's
DP,
DK
or
all
the
vertical
stuff
we've
been
the
Linux
kernel.
We
have
guest
drivers
who
knows
in
order
to
improve
the
virtualization
in
order
to
get
a
get
in
and
out
from
Debian.
A
So
that
is
I
think
what
reservation
is
good,
but
reality
is
also
that
in
containers
you
don't
have
the
virtualization
isolation,
so
you
know
you
don't
need
to
optimize
anything
to
get
it
from
the
from
the
guest
to
the
host.
So
in
reality,
and
that's
more
overhead
in
the
thank
you
in
the
in
the
virtualization
world
because
need
to
initialize
the
BIOS
virtual
hardware.
A
So
it's
it's
lower
and
you
see
that
when
you
put
the
VM
yep
time
to
to
look
into
the
clouds
to
look
at
the
Sun
of
the
birds
outside
and
then
you
get
back
to
the
screen
to
to
to
do
something
in
containers,
it's
quicker.
It's
blazingly
fast,
so
they're
pretty
good
at
that
strong
isolation.
So
you
know
now
we
have
20
machines
or
containers
running
on
host,
so
how
they
eight
isolated.
A
A
You
know
every
container
is
self-contained
by
itself.
It
has
its
own
network
name,
space
eventually
mounting
space.
Definitely
so
there's
also
isolation.
Well,
it's
not
so
isolated,
but
still
branded,
because
on
title,
it's
isolated
in
the
end.
Containers
do
a
lot
of
stuff
right.
They
really
prompt
from
the
bidding
up
for
building
it
to
shipping
it
to
running
it.
It's
a
good
experience
and
I
mean
we
see
that
a
lot
of
people
have
picked
that
up
I
mean
kubernetes,
the
vibrant
community
all
focused,
and
you
know
improving
that
container
workflow.
That
is
building
and
I.
A
Think
on
that
base
that
this
whole
experience
is
so
slick
from
the
beginning,
and
you
know
it's
so
good
and
easy
to
grasp
the
concepts
of
how
to
you
know,
operate
and
build
them.
That's
really
helpful,
I
think
to
to
the
technique
itself,
but
also
to
the
ecosystem,
everything
that
builds
upon
it.
So
we
could
say
well
the
virtual
machine,
sorry,
but
that's
it
leave
the
stage
and
can
the
container
is
the
winner
of
our
a
small
contest
to
compare
you
know
between
the
features
and
requirements
we
have
running.
A
A
Isolation
is
important,
I
mean
you,
you
were
close
and
the
question
is:
if
you
also
trust
your
workers,
or
you
want
to
avoid
usually
in
a
production
environment
or
even
in
your
local
environment,
that
your
CI
job
is
not
destroying
your
Provost
or
your
CI
job
is
impacting.
Are
the
containers
on
your
hosts
and
containers
are
good
at
isolating
them,
but
it's
it's
just
isolation.
It's
not
the
strong
isolation
get
with
the
MS,
with
the
MTO
put
more
knobs
or
more
mechanics
to
force
the
isolation.
A
A
In
the
container
world
or
containers
interface
with
the
same
kernel,
so
they
effectively
process
it's
running
on
your
host
and
then
some
magic
apply
to
it
like
namespaces
and
see
groups
in
order
to
isolate
them,
but
they
all
interface
with
the
same
kernel,
and
that
can
be
an
issue
now.
It's
like
with
I,
don't
know
the
English
words
but
fragment
with
vertol
one
gust
if
the
hope
is
tainted
or
if
the
host
is
attackable,
then
all
the
other
tenants
on
that
host
or
affected
as
well.
A
So
if
the
kernel
is
of
gulnur
ability,
you
know
it's
it's
much
easier
for
process
in
one
container
to
leverage
that
and
eventually
attack
the
other
containers
and
because
the
whole
kernel
is
exposed.
The
attack
surface
is
quite
large.
In
VMs.
However,
it's
different
in
VMs,
every
VM
has
its
own
kernel
and
the
isolation
to
to
the
host
to
the
host
kernel
is
that
KTM
interface
and
please
correct
me
if
I'm
wrong.
A
So
that's
an
important
distinction.
So
you
know
every
VM
is
operating
with
its
own
kernel
and
that's
not
only
important
for
for
security
reasons,
but
also
because
every
VM
has
its
own
optimized
kernel,
I
mean
with
different
features,
might
need
or
might
not
need,
and
actually
for
different
versions
for
test
it's
important
to
have
different
versions
and
not
always
tested
same
okay.
So
what
I
want
to
get
to
is
isolations
our
concern
in
the
content
world,
we
actually
see
that
people
in
the
public
calc
are
running
containers
and
usually
in
a
public
cloud.
A
You
don't
want
that.
One
container
can
affect
the
other,
so
you
want
to
really
properly
isolate
and-
and
that
is
what
we
see.
Actually
that's
what
cata
containers-
and
this
is
the
first
project
name.
My
name
of
this
talk
is
actually
doing.
They
want
to
solve
this
problem.
They
want
to
bring
the
isolation
we
have
in
the
virtual
artist
world
to
contains
in
order
to
isolate
them
properly
and
secure
them.
A
Katakana
is
itself
is
a
kubernetes
runtime
who
of
you,
doesn't
know
kubernetes
or
openshift,
very
good.
We
save
a
few
minutes
and
if
the
kubernetes
runtime
kubernetes
sells.
Thank
you
all
that
stuff
all
right.
Kubernetes
has
a
few
runtimes
that
are
ways
to
run
a
container
and
Katta
is
one
of
them
and
it
uses
virtualization
techniques
around
them.
So
how
does
it
look?
Well
us
user?
For
you,
nothing
changes.
A
You
continue
to
work
with
pods,
so
who
of
you
has
not
created
or
defined
a
part
before
very
good,
so
you
can
continue
to
create
pods
using
what
spec.
As
you
know,
it
actually
there's.
One
thing
you
need
to
know,
but
we'll
get
to
that
in
a
minute
and
then
you're
done
and
you
can
use,
can
continue
to
use,
cube,
CTL
or
cube
Cal.
It's
not
sure
what
really
the
right
pronunciation
is,
but
you
can
use
it
to
manage
those
containers,
nothing
changes
for
you.
A
You
built
your
containers
the
same
way
if
I'm
not
mistaken,
so
what
happened?
So
what
does
change?
Well?
The
system
does
changes.
So
this
system
is
not
running
the
container
directly
on
the
node.
No,
it's
crafting
for
U
of
M
and
putting
the
whole
pot
inside
and
then
running
it
for
you,
so
it's
creating
a
VM
in
order
to
run
a
pot.
So
a
group
of
containers
on
that
note
so
by
running
the
pod
inside
the
VM
and
I'm
hope.
A
I,
don't
want
on
that
point
too
much,
but
because
it's
running
it
inside
the
VM
you
get
these
isolate.
That's
right,
virtualization
world!
That's
it
that's!
Really
it
there's
not
much
more
to
it.
So
how
does
it
look?
Oh,
so
that's
a
pot
definition,
it's
an
example
and
there's
just
that
is
the
important
nine.
So
this
annotation
is
telling
the
runtime.
If
you,
if
you
have
deployed
cutter,
it's
not
possible
at
the
moment.
A
It's
not
packaged
as
far
as
you
know,
but
if
you,
if
you
would
in
future,
then
you
can
put
that
annotation
or
to
your
part
in
order
to
tell
kata
to
run
your
pot
in
an
isolated
environment.
I
just
highlighted
that
part
as
well,
because
I
want
to
highlight
this
that
apart
it's
about
running
up
processes
here,
TFT
PhD
awesome.
So
we
picked
the
parts
we
want
from
the
virtualization
world
and
apply
them
to
containers
without
changing
anything.
This
solves
the
problem,
solves
the
problem
of
isolating
containers
and
thoughts.
A
All
right,
great,
that's
it
that
was
about
virtualization
in
the
current
world.
There's
nothing
else
to
say
well.
Is
that
really
everything?
No
not
necessarily
so
fact
is
that
this
deserted
thing,
this
usage
of
virtualization,
that
our
virtual
machines
we
mentioned
that
we've
built
them,
for
you
know
classical
virtual
machines
for
like
20
years.
So
what
does
that
mean?
Well,
you
know.
Imagine
all
these
little
tiny
rocks
in
this
large
Mountain
RBMS.
A
A
Okay,
they
go
so
we've
got
at
least
100
VMs
on
the
world
and
that's
sufficient
to
think
about.
What
can
we
do
about
them?
Because
so
what
I
want
to
illustrate
here?
Just
to
read
reiterate,
you
know,
we've
built
really
a
mountain
of
VMs.
Everybody
has
built
VMs,
we've
got
vendors
building
specialized
VMs
for
NFV,
and
if
he
is
always
a
good
example,
we
need
you
to
tor
mention
anything
really
good
and
we
build
VMs.
So
what
about
them?
A
Because
the
problem
is
even
if
containers
are
so
similar
to
VMs
VMs
cannot
be
run
as
containers
right
away.
That
might
be
true
for
some
workloads,
but
it's
often
not
true
for
very
workload,
and
sometimes
you
just
you,
don't
even
want
to
run
the
work
this
year.
You
happen
at
the
end
inside
a
hotel.
Did
you
other
differences
which
I
don't
want
to
go
into
now
like
assumptions?
A
Okay?
So
the
question
is:
what
can
we
do
about
those
VMs
we
have
created
of
last
20
years,
but
still
want
to
go
into
the
container
area,
and
that
is
what
cuber
comes
in.
That
is
the
second
project,
so
Qbert
is
actually
the
lift
and
shift
story
or
lift
and
shift,
which
is
a
migration
story.
This
is
a
horizontal
elevator,
so
it's
about
you
know,
lifting
the
elevator
up
and
then
shifting
to
the
left
and
right
just
another
comment
on
the
background
image.
A
So
the
lifting
and
shifting
its
taking
a
work
load
as
we
have
it
today
and
run
it
along
side
contains
because
you
can
we,
you
know
we
want
to
pick
you
or
all
the
others
of
where
they
are
with
DBMS
they
have.
Today.
We
want
to
allow
you
to.
You,
know,
move
it
into
containers,
but
it
said
it
might
not
always
be
possible
or
not
feasible,
because
it's
so
complicated.
So
from
the
Qbert
perspective
of
running
VMs.
What
does
change
so
for
you?
You
don't
create
a
pod.
You
rather
create
a
VM
and
you
yeah.
A
You
start
to
work
with
VMs
on
top
of
kubernetes
and
you
define
a
VM
using
a
VM
spec,
not
as
parts
back
anymore,
but
the
operation
of
that
VM
is
still
done
using
cube
color.
That
is
what
is
changing
for
you.
So
what
changes
on
the
system
side?
Well,
what
what
it
does?
What
cube
root
teaches
kubernetes
is
to
run
a
beam.
A
That's
it
that's
all
there
is
to
say
for
for
that.
So
how
does
it
look
and
that
is
effectively
a
new
kind
of
kubernetes
delivered
as
an
add-on
by
the
ways?
Isn't
a
dog
Vanity's,
it's
a
virtual
machine
type
and
I
highlighted
here.
You
know
early,
we
said,
was
the
process
of
a
pod.
Thank
you.
We
shortened
the
discussion
talk
a
little
bit
and
here
it's
about
really
running
a
disk,
so
we
just
specified
the
disk
to
launch
like
you
would
do
it
with
VMs.
A
So,
instead
of
specifying
the
process
and
containers,
you
specify
this
like
actually
do
today
in
OpenStack
mf4,
sir.
Okay,
that's
awesome
as
well.
It
gives
users
of
the
ends
a
perspective
of
how
to
run
their
BMS
and
future
as
well.
There
are
reasons
why
you
want
to
run
the
mail
alongside
each
other.
What
is
you
know?
Getting
pot
in
front
of
VMs
and
containers
running
closer
to
each
other
is
running
them
on
the
same
infrastructure
allows
them
to
cooperate
better.
A
You
know
it's
a
better
thing
for
the
operator,
because
if
you
run
them
on
the
same
infrastructure,
you
just
have
to
maintain
one.
You
don't
have
to
maintain
kubernetes
and
OpenStack
or
communities
on
OpenStack.
You
can
just
maintain
kubernetes
on
bare
metal
or
on
OpenStack
in
order
to
run
both
containers
and
games
all
right.
So
we
win
again
I
really
like
that
emoji.
So
that's
why
actually
it's
annoying,
because
that
emoji
is
is
in
color
when
you
put
into
the
Google
slides,
but
when
you
create
a
PDF,
it's
just
black
and
white.
So
really!
Never!
A
C
A
B
A
On
the
right
hand,
side
you've
got
OpenStack
and
overt,
which
are
classical
systems,
run
VMs
and
Cubert,
even
if
it
runs
on
communities,
is
pretty
much
on
that
side
because
it
allows
you
to
run
the
VMS,
as
you
would
run
them
on
OpenStack
or
over
and
there's
actually
one
component.
What
I
want
to
mention?
It
is
vertol
it
that
is,
you
know
it's
to
run
virtual
machines,
but
you
use
definition
to
rocket.
A
B
C
A
You
could
say
so:
I
actually
don't
know
if
missiles
or
a
diamond.
There
are
other
awkward
situations
beside
communities.
Oh
yes,
sorry.
The
question
was
for
this
statement
was
because
of
Cupid
and
cata
kubernetes
become
the
best
system
to
run
out
its
temperament
to
manage
KVM
based
work
at
the
best
kayvyun
manager
in
the
world.
A
That
was
added
by
no
candy
and
actually
I'm.
Not
aware
that
we
have
got
so
many
I
mean
I
mentioned,
but
can't
contain
is
like
there's
like
three
or
four
projects,
because
before
cat
emerged,
it
emerged
from
and
there
were
three
or
four
more
others
which
silently
and
maybe
moving
on
but
or
died,
but
I'm
not
aware
that
in
metals
or
other
orchestrators
there's
similar
work
at
home.
So
yes,
I
I
would
support
them.
A
The
question
was:
if
it's
really
just
a
matter
of
adding
one
annotation
to
part.
Yes,
it's
just
the
matter
of
deploying
the
right,
runtime,
making
sure
the
right
dependencies
are
deployed,
you
know
and
having
the
right
kernel
right.
Can
we
move
and
then
adding
the
pot
annotation
yeah,
then
that
is
all
you
have
to
do
from
a
user
perspective.
Yes,
there
are
stickers
to
win.
If
there
are
more
questions
are
great
and
you
get
one.
B
A
The
question
was:
what
is
mated
advantage
of
using
Qbert
compared
to
open
ship
for
open
stack,
open,
shipped
on
OpenStack?
Okay,
so
Qbert
cannot
give
you
so
cube
root
of
Base
the
rules
of
communities.
So
we
say
we
want
to
integrate
with
kubernetes
or
I'm
working
Hubert
by
the
way
so
did
I
did
I
say
that
human
or
based
kubernetes.
So
we
want
to
allow
you
exposing
upm
using
kubernetes
concepts
like
services-
oh
yeah,
it's
53!
A
Let
me
try
to
find
ten
thing
you
have
different
requirements
are
met
by
OpenStack
or
Cubert.
Openstack
is
surely
something
you
need
if
you
want
to
run
something
complex
on
large
scale
and
Cooper
is
something
which
is
surely
more
focused
on.
You
know
giving
you
the
guarantee
exposure
as
pods
or
containers.
You
know
it's
more
focused
on
integrating
it
with
pods
on
the
same
network,
whereas
I
mean
yeah,
but
in
the
end
they
can
run
the
same
VMs.