►
From YouTube: Running VM Workloads Side by Side with Container Workloads - Sebastian Scheele, Loodse
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Running VM Workloads Side by Side with Container Workloads - Sebastian Scheele, Loodse
On Kubernetes clusters, cloud native workloads and (legacy) VM workloads can run side by side. KubeVirt is a project to bring declarative, Kubernetes-style APIs to VM creation, configuration, and management. In this talk, I will demonstrate how you can use the KubeVirt to set up and manage VM inside of a Kubernetes cluster. I will be describing how KubeVirt leverages CPU virtualization to implement a stronger security architecture for Kubernetes. When combining both approaches, we can run a wider range of workloads, from container cloud-native applications to lift-and-shift applications with KubeVirt.
To learn more: https://sched.co/GrYS
A
B
C
B
Were
stuff
all
right,
so
I'm
going
to
just
kind
of
give
an
overview
of
the
cube
root
project
and
what
we're
doing
here
so
kubernetes
kubernetes
is
a
container
platform
and
Cubert
is
a
virtualization
extension
for
Cooper
neighs
that
allows
us
to
run
virtual
machine
workload
side
by
side,
with
container
workloads
and
from
a
really
high
level.
What
I'm
talking
about
here
is
giving
Cabernets
the
same
kind
of
ability
to
do
the
use
cases
you
might
use
something
like
an
open
stack
for
we
get
that
feedback,
maybe
backed
off
a
little
all
right
all
right.
B
So
that
kind
of
begs
the
question
to
me:
why?
Why
would
we
do
this?
We
already
have
on-premise
solutions
like
OpenStack
and
overt,
and
we
have
the
public
cloud.
We
know
how
to
manage
virtual
machines
there
in
a
Dib
s
and
GC
and
we've
had
things
like
vmware,
so
we
solved
this
problem
with
vm
management
hundred
times
in
a
hundred
different
ways.
Why
are
we
doing
it
yet
again
with
Qbert?
B
So
a
couple
of
reasons?
First,
one
infrastructure
convergence.
So
if
you
have
legacy
virtual
machines
right
now,
maybe
their
name
and
legacy
virtual
machines,
maybe
you
have
to
develop
some
of
your
applications
and
virtual
machines,
but
you
also
want
to
do
development
in
containers
as
well.
Your
system
probably
looks
like
this.
You're
gonna
have
two
stacks
one
from
your
virtual
machine
management.
Maybe
that's
running
OpenStack,
for
example,
and
a
separate
one
for
your
container
workload
management
and
that's
going
to
be
kubernetes.
So
with
two
stacks.
B
That
means
you're
having
to
do
to
duplicate
everything
so
you're
duplicating
your
logging
and
metrics
you're
monitoring.
You
have
two
schedulers
you're
gonna
have
two
networks:
two
storage
providers.
All
of
this
and
that
operational
complexity
comes
at
a
cost.
The
more
complex
the
operation
is
more
costly
just
to
operate
so
Qbert
we're
converging
these
stacks.
Now
you
can
run
virtual
machines
and
container
workloads
using
kubernetes
and
we're
reusing
all
the
things
kubernetes
gives
us.
So
the
same
logging
same
metrics,
monitoring
the
same
scheduler,
the
same
storage
network
they're
using
for
containers.
B
You
can
now
use
for
virtual
machines,
we're
even
extending
this
to
things
like
our
back,
so
you
create
a
roll
that
gives
a
user
the
ability
to
schedule
a
pod.
You
can
also
give
the
user
permissions
to
create
virtual
machines,
so
we're
tying
in
to
all
the
things
that
Cooper
nase
gives
us
today.
So
infrastructure
convergence,
one
stack
second
reason
for
couvert
workflow
convergence,
so
back
in
I
think
was
like
twenty
fourteen
or
something
when
I
first
heard
about
kubernetes
I
didn't
quite
get
it.
B
I
was
working
on
another
cluster
manager,
actually
at
the
time
and
I
saw
Cabernets
this
just
another
way.
They
did
the
same
thing
that
all
the
other
things
did,
and
there
was
a
few
things.
I
was
missing
there
and
one
key
part
I
was
missing
with
the
power
of
this
declarative
API.
So
in
kubernetes
you
declare
the
state
you
want
and
kubernetes
converges
on
that
state.
So,
for
example,
if
you
have
a
deployment-
and
you
say
you
want
Tim
replicas
of
that
deployment-
then
kubernetes
converges
on
that.
It's
going
to
give
you
ten
pods.
B
If
a
node
goes
down,
that's
running
one
of
those
pods
Coover
reconvergence
on
that
state,
and
it's
going
to
spin
up
that
tenth
pod
somewhere
else
for
you
we're
allowing
virtual
machines
to
be
managed
using
the
same
declarative
pattern.
In
addition
to
that,
we're
using
all
the
same
tooling
that
you
already
use
for
container
workloads
to
manage
virtual
machines.
B
B
You
manage
your
virtual
machines
on
the
right
hand,
side
you
can
see
an
example
of
us
posting
a
virtual
machine
manifest
to
the
cluster
and
just
kind
of
looking
a
whole
manifest
there,
but
you
can
see
it
looks
fewer
Nettie's
like
it
looks
really
familiar.
You're
gonna
have
a
metadata
section:
you're
gonna
have
a
spec
and
a
status.
The
kind
is
a
virtual
machine
instance.
That's
our
API
that
we're
registering
is
a
custom
resource
definition.
B
So
one
last
thing
before
I:
do
a
demo
I
want
to
talk
about
the
simplicity
of
our
install
process,
Cubert
it
just
drops
into
any
existing
kubernetes
cluster.
It's
that
simple.
You
don't
have
to
do
any
sort
of
node
level
configuration
there's,
no
changing
of
runtimes
or
anything
like
that.
It's
just
going
to
work!
So
it's
as
simple
as
going
to
our
github
page.
You
can
find
our
releases.
You
can
take
one
of
those
manifests
and
their
releases
and
you
can
just
post
it
to
your
cluster,
so
cube.
B
Ctl
creates
that
chef
and
I
have
a
URL
there
and
that's
one
of
our
release
manifests
that's
going
to
pull
in
all
of
our
api's
custom
resource
definitions.
All
of
our
components
that
involve
the
virtual
machine
launch
flow.
It's
going
to
install
that
for
you
and
you
didn't
have
to
think
about
any
of
that.
At
that
point
you
can
just
start
using
our
API
start
posting
virtual
machine
specs
and
virtual
machines
come
up.
It's
it's
that
easy.
The
reason
it's!
B
That
simple
is
a
key
architecture
decision
that
we
made
early
on,
and
that
was
so
we're
going
to
run
virtual
machines
inside
of
pods.
So
that's
how
we
reuse
the
scheduler
reuse,
everything
that
kubernetes
gives
us
we're
just
running
a
virtual
machine
process
inside
of
a
pot.
So
when
we
post
a
virtual
machine
instance
back,
that's
our
manifest!
That's
our
API
to
the
cluster.
B
We
have
a
controller
behind
the
scenes
that
observes
the
creation
of
that
object
and
in
response
to
that
is
during
a
pod
for
that
virtual
machine
instance
process
to
live
in.
So
if,
in
your
virtual
machine
instance
manifest,
you
said,
you
want
a
fork
or
machine
with
ten
gigabytes
of
memory
and
persistent
volume
claimed
with
a
virtual
machine
disk
on
it.
Then,
when
our
controller
generates
the
pod
for
that
virtual
machine
to
live
in,
it's
going
to
have
all
those
resources
assigned
to
it.
B
When
the
pod
starts
up,
there's
a
component
inside
the
pod
that
manages
mapping
all
of
those
resources
that
have
been
attached
to
the
pod,
to
the
virtual
machine
process
that
we're
starting
inside
of
the
pod.
So
the
end
result
here
is:
we
kind
of
have
a
virtual
machine
process
in
the
pod
that
kind
of
assumes
the
role
of
the
pod
and
they
kind
of
drive
that
home
with
our
default
networking.
B
If
you
ping,
the
pods
IP
address
you're,
actually
getting
a
response
from
the
virtual
machine
guest.
So
it's
where
actually
the
guest
owns
that
network
address
the
device
that
C&I
created
for
it
all
right,
so
I'm
going
to
do
a
quick
demo,
real,
quick.
This
demo,
it's
been
recorded.
So,
if
you're
interested
in
looking
at
it
again
take
a
picture
of
that
you
can
play
it
back
for
yourself
inspect
what
I
did
and-
and
you
can
even
try
it
out
for
yourself.
B
B
All
right
so
start
with.
We
have
two
notes,
because
you
get
that
two
notes:
do
a
migration
I'm
going
to
show
the
virtual
machine
instance
manifest
real,
quick,
show
you
what's
going
on
there.
This
is
a
full,
manifest
I.
Guess
it
cut
off
a
little
bit,
the
top,
that's
okay
in
the
spec.
The
only
thing
that's
worth
pointing
out
here
is
the
type
of
disc
that
we've
defined.
Here.
It's
a
cool
feature.
We
have
that
lets.
B
B
All
right,
so
that's
the
virtual
machine
instance
pod.
That's
where
the
virtual
machine
process
lives.
We
now
look
at
the
VMI
object.
We
can
see
a
few
things
we
see
in
the
event
section
here.
We
can
track
the
state
of
the
virtual
machine
instance
as
it
started,
so
we
see
that
it
was
successfully
created.
That
means
the
POW
was
generated,
and
now
the
virtual
machine
process
inside
that
pod
has
started
so
for
fun.
I'm,
going
to
log
into
the
console,
we
have
a
convenience
tool
called
verts
ETL
and
that
lets
you
do
some
extended
functionality.
B
You
don't
need
it
to
manage
your
virtual
machines,
but
it
does
allow
you
to
log
into
the
console,
which
is
nice
so
now
I'm
inside
the
virtual
machine
and
when
I
do
here
is
I'm
launching
a
simple
process
here.
That's
it's
just
a
loop,
echoing
some
output.
So
what
I
want
to
do
now
is
I
want
to
migrate,
that
virtual
machine
to
another
node
and
a
well
lock
back
into
the
console
after
I've
migrated
and
show
you
that
that
counter
is
still
ticking.
It
represents
a
process
running
inside
the
virtual
machine.
B
We
know
that
it
wasn't
interrupted
so
to
migrate,
a
virtual
machine.
We
have
a
migration
object
that
needs
to
be
posted
to
the
cluster.
That
declares
that
you
want
this
virtual
machine
to
move
from
one
to
another.
So
if
you
look
at
the
migrations
back,
it's
really
simple.
This
one's
really
simple,
all
I
said
is
the
virtual
machine
named
then
once
migrate
is
fee
mi
gradable
and
we're
just
telling
it
by
posting.
This
object
that
we
want
it
to
move
somewhere
other
than
where
it
is
now
so
we'll
post
this
manifest
to
the
cluster.
B
Jobs
been
created,
we
look
at
the
pods
here.
We
see
that
another
pod
has
been
chariot
on
a
different
node
and
that's
the
target
for
this,
and
we
do
it
described
on
our
VM
I
again,
we'll
see
lots
more
events,
so
we're
tracking
the
migration
we
can
see
when
the
target
was
prepared.
This
happened
really
fast
because
the
it's
a
really
small
virtual
machine,
then
running.
A
So
from
Lutzer
we
built
Cuba
Matic,
which
is
a
platform
to
run
kubernetes
cluster
anywhere,
so
we
can
run
on
cloud
provider
on-premise
and
what
we
saw
quite
often
our
secret,
often
especially
if
you
are
in
the
on
from
environment
customer,
has
this
huge
bi-metal
machines,
but
you
want
to
have
not
like
10
5
500
gigabyte
machine
in
one
cluster,
because
then
you
have
10
5
terabyte
of
memory
in
the
cluster,
and
this
is
not
working.
Your
developer
wants
to
have
a
small
class,
a
development
classes.
A
A
So
it
was
more
or
less
similar
ideas
and
we
were
saying
cool,
let's
see
how
where
this
is
going
and
potentially
we
can
integrate
this
for
some
use
cases
to
streamline
and
to
make
the
API
at
our
customers
and
say
usability
much
more
easier,
so
that
we
really
have
the
possibility
to
run
everything
with
Cuban
ideas,
so
only
tool.
What
you
need
is
Q
control
and
you
don't
need
different
tooling
to
manages
one
managing
all
and
the
other
big
side
effect
of
this
is
I.
A
Think
it's
unrealistically
in
the
next
year's
to
get
everything
inside
of
a
container.
You
still
have
like
virtualization
workloads,
but
then
you
have
like
David
mentioned
the
unified
platform.
You
can
run
your
queue,
bonitas
cluster,
you
run
can
run
you
can
antennas
inside
and
you
can
also
side
by
side.
Your
VM
workloads,
so
we
are
quite
actively
in
the
cluster
API
I'm,
not
sure
who
is
familiar
with
the
cluster
API.
A
Okay,
only
a
few
I
will
give
you
a
rough
overview.
So
the
idea
of
the
cluster
API,
it's
a
zigg
of
Q
Benitez
to
create
a
declarative
API
to
spinning
up
Q,
bonitas
cluster,
and
one
part
of
this
is
the
Machine
API
and
I
will
show
you
how
we
integrated
cube
word
into
the
machine
API.
So
the
main
concept
of
the
machine
API
is
to
make
really
machines
natively
available
inside
of
cuban
eaters,
so
that
you
can
do
Cube
control,
create
machines
or
even
like
queue
control.
A
A
machine
did
create
machine
deployment
and
cuban
eaters
will
manage
and
generate
all
of
your
machines,
and
this
cube
control
create
machines
should
run
everywhere.
The
same
it
doesn't
matter.
If
you
are
in
the
cloud
on
AWS
on
google
or
if
you
are
on
firm
on
with
cube
vert
or
VMware,
or
even
when
you're
using
tools
like
mass,
you
have
an
API
for
your
bi-metal
machines.
You
could
also
do
this
integration
with
super
metal
machines
directly.
So
the
main
component
here
is
a
machine.
A
A
So
when
you
create
a
new
machine,
the
machine
controller
will
detects
us
and
then
yeah
we
will
do
the
necessary
stuff
and
then,
at
the
end,
create
a
VM
in
this
case
on
Qbert
or
like
on
your
cloud
provider
and
afterwards,
when
you
delete
the
machine
also
deletes
a
VM
a
again,
and
how
did
we
implement
this?
So
our
machine
controller
is
open
source.
A
It's
when
you
check
on
the
cluster
API
repository,
you
find
a
link
to
it
or
you
can
find
it
also
at
the
end
of
our
presentation,
there's
a
link
to
it,
and
mainly
it
has
six
methods
we
might.
We
must
implement
the
two
main
methods
are
create
and
delete,
so
we
must
create
a
custom
resource
definition
for
cube,
vert
and
then
Qbert
is
picking
it
up
and
we
must
delete
it
and
some
other
smaller
functions
to
do
this.
A
And
this
is
what
I
want
to
show
you
now
so
in
the
backend
I
spin
up
the
master
with
our
to
Cuba
Matic,
so
the
master,
some
we're
running
and
then
I'm
running
this
machine
controller,
and
now
this
is
checking
all
the
time
if
there
any
changes
and
then
execute
this
changes
and
on
the
one
side,
I
have
my
user.
We
call
it
user
cluster,
where,
as
a
developer,
want
to
deploy
some
workload
on
it.
A
A
I
created
already
a
machine
deployment,
so
we
have
a
machine
deployment
with
two
replicas
and
this
is
then
mapped
to
a
machine
set
in
the
provider.
You
see
already
is
Qbert
so
similar
like
poor
deployment
and
pots
in
Cuban
eaters.
We
now
have
a
machine
set
so
that
we
can
also
do
rolling
upgrades
of
the
machine
and
then
based
on
the
Machine
set.
We
generate
the
machines
and
then
what
we
technically
do
is
like
we
play
see.
A
Custom
resource
comes
custom
resources
for
the
cube,
light
controller
for
the
Qbert
controller
and
the
Qbert
controller
is
picking
this
up
and
spinning
up
the
machine.
So
when
we're
looking
here,
that's
now
the
biometric
last
EAC
cube
word
is
running
with
the
API
and
they
control
us
and
you
see
also
two
instances
launched
for
worker
notes.
So
when
we
now
do
Cube
get
notes,
you
know
this
is
a
master,
but
we
have
two
worker
nodes
running
here
and
what
we
also
can
now
add.
C
A
Potentially
we
see
it
students,
it
looks
yeah
you
see
here,
it's
processing
the
entries
which
is
created
and
now
when
we
check
on
the
biometric
roster,
we
have
four
virtual
machines
running.
It
now
takes
a
little
bit
time
to
start
this
up
and
that's
a
are
ready
to
join.
It
takes
now
for
five
minutes
so
that
they're
ready
to
join.
But
then
all
of
this
is
running
and
see,
developers
can
use
the
small
cluster
for
the
development
purposes
and
we
could
easily
easily
do.
A
A
You
see
the
amount
of
memory
CPU
so,
and
you
see
the
couplet
version
so
when
we
now
want
to
run
an
upgrade
our
cluster,
we
only
would
change
the
couplet
version
and
then
the
machine
deployment
up
deployment
will
generate
a
new
machine
set
and
will
generate
new
machines,
and
so
the
old
VMs
will
be
terminated
and
cubed.
Q
Bert
will
create
new
new
machines.
Out
of
this.
A
A
You
can
run
it
this
on
a
miniature
cluster
and
connect
this
with
your
bare
metal
cluster,
and
now
we
really
have
the
possibility
to
manage
a
lot
of
smaller
clusters
on
top
of
such
big
PerR
metal
machines
and
can
provide
developers
like
one
or
two
nodes
cube
anita's
cluster,
instead
of
trying
only
multi-tenancy
with
namespaces.
So
now
one
developer
can
run
already
on
one
on
11.
The
next
developer,
who
wants
to
use
already
one
or
12
or
13,
can
can
already
deploy
this,
and
they
can
indeed
individually
decide.
A
Ok,
when
it's
the
best
time
to
upgrade
and
as
an
operation
from
operation
perspective,
I
only
need
true
control
and
perhaps
third
control,
but
even
this
so
like
when
I'm,
currently
working
with
like
cloud
provider,
I
barely
use
their
CLI.
Because
with
this,
you
can
already
use
queue,
control
to
manage
everything,
because
when
VM
dies,
you
don't
care,
it's
automatically
restarting
a
new
one,
so
I'm
not
really
looking
into
what's
happening
in
the
VM
as
long
as
C
VMs
contain
a
runtime
installed
and
the
couplet
is
running
on
top
of
it.
A
It's
joining
and
that's
the
only
thing
as
a
developer
perspective,
I'm
interested
in
to
it
so
and
also
in
most
cases
from
the
operational
side
so
really
having
one
to
to
manage
all
of
this.
Also
in
your
per
metal
environment
and
like
we
already
discussed,
was
far
beyond
like
potentially,
if
you
want
to
run
CI
it's
on
cloud
providers
and
you
want
to
use
bigger
machines.
This
could
be
also
possibility
running
nested
on
cloud
provider
by
using
like
peckers
running
on
their
infrastructure.
A
So
then
you
can
easily
deploy
this
on
the
infrastructure,
with
cube
hood
and
having
VMs
and
then
additional.
You
really
have
this
benefit.
If
you
need
a
dedicated
VM,
you
can
spin
it
up
side-by-side
and
they're
on
the
same
network.
They
can
talk
to
each
other.
You
don't
must
think
about.
Okay.
How
do
I
now
get
my
traffic
from
outside
of
my
kubernetes
cluster
inside
my
cubans
cluster?
They
could
work
on
the
same
network,
same
storage
and
all
this
kind
of
stuff.
A
A
It's
it's
a
POC,
it's
not
polished
yet
our
our
setup,
so
you
must
do
make
deploy,
but
in
general
it's
working,
you
can
use
mini
Clube
mini
cube,
or
they
are
also
some
terror
from
suspending
up
cube,
anita's
cluster,
and
you
can
connect
this
with
a
bi-metal
cluster,
and
then
you
easily
can
try
this
out
play
around.
If
you
want
to
have
feedback,
create
a
PR
or
contact
us,
we
also
have
a
booth
there.
If
you
want
to
talk
about.
This
was
really
interesting
about
feedback.
A
B
Test
test:
okay,
Hubert's,
very
new,
it's
something
that's
being
actively
developed
from
you
know
last
year,
up
until
now,
so
it's
we're
just
getting
to
the
part
where
we're
starting
to
see
people
actually
adopting
it.
We've
seen
and
I
think
most
of
the
interests
that
we've
seen
is
people
that
have
traditional
workloads,
they're
wearing
a
virtual
machines
that
want
to
converge
on
top
of
cooper
neighs
because
they
want
the
ability
to
have
into
that
operational
simplicity.
That
was
talking
about.
As
far
as
specifics
go
I,
don't
have
any
examples.
I
can
share
right
now.
C
B
There's,
not
a
lot
of
overhead,
so
you
have
the
kubernetes
components
that
are
running
on
site
on
top
of
the
bare
metal
and
we're
launching
virtual
machines
inside
the
container
environment,
and
so
you
have
things
like
cgroups
they're
involved
there
and
just
any
sort
of
it's
going
to
depend
on
how
you've
figure
cluster.
So
the
perform
is
going
to
depend
on
how
fast
your
containerized
environment
is.
B
So
what
kind
of
c-
and
I
plug
in
your
using
and
things
like
that,
but
from
a
cpu
performance
perspective,
we're
reusing
what
kubernetes
gives
us
so
Cooper
neighs
has
more
time
I
like
overcommit,
and
things
like
that.
Some
of
the
things
people
think
about
with
virtual
machines,
we're
reusing
the
same
quality
of
service
that
qu
Bernays
provides
us.
If
you
have
request
limits
and
things
like
that,
and
we
are
able
to
do
like
CPU
pinning,
because
kubernetes
provides
us
cpu
pinning
so
we're
trying
to
leverage
all
the
things.
Kubernetes
gets
us
for
performance,
yeah.
C
B
B
E
E
All
right,
yes,
so
basically
cube,
verges,
uses
all
the
native
kubernetes
facilities,
so
any
storage
that's
available
to
the
cluster,
whether
it
be
host
path
or
local
storage
or
statically
provisioned
persistent
volumes,
dynamic,
provisioning,
CSI.
Any
of
the
the
mechanisms
that
are
available
today
would
be
compatible
with
this.
So.
B
A
B
Sure
so
the
question
is:
is
keeper
compatible
with
service
messages
such
as
sto?
We
have
lots
of
different
networking
options
and
we
have
a
specific
networking
option
that
plays
nicely
was
sto
and
that's
one
of
our
use
cases
that
we
are
definitely
interested
in.
So
yes,
we
do
play
nice
with
this.
Do.
C
B
The
question
is
how
to
dynamically
provision
virtual
machines,
there's
lots
of
ways
of
doing
that
cloud
in
it.
Like
you
mentioned,
we
we
support
that
directly,
and
so
you
can
actually
define
your
cloud
in
its
script.
Inline
in
the
virtual
machine
instance
manifest,
and
you
can
also
we
support
I-
believe
writing
your
cloud
in
it
into
a
grenade
secret.
So
if
you
have
like
a
huge
script,
I
can
get
like
a
megabyte.
Orthis,
don't
recommend
that,
but
you
can
you
can
write
like
a
megabyte
worth
of
cloud
Anette
data
there.
Yes,.
A
B
Container
runtime
it's
equivalent
and
have
it
where
we
launch
virtual
machines
from
like
a
centralized
levert
on
the
host.
We
considered
that,
but
that
that
removes
some
of
the
simplicity
that
I
was
talking
about
where
we
just
reuse
everything
that's
already
given
us,
we
play
nicely
with
all
container
runtimes
and
that
would
prevent
us
from
being
a
drop-in
solution,
which
is
what
we're
really
going
for.