►
From YouTube: KubeVirt Intro – Using KubeVirt to Run VMs at Scale - Fabian Deutsch & Marcus Sorensen
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.
KubeVirt Intro – Using KubeVirt to Run VMs at Scale - Fabian Deutsch, Red Hat & Marcus Sorensen, Apple
This session will provide an intro into the KubeVirt project, which enables Kubernetes to run virtual machine workloads alongside containers. This provides a unified development platform where developers can build, modify, and deploy applications made up of both application containers as well as virtual machines in a common, shared environment. In the session, you will learn more about why KubeVirt exists, how people are using it today, and how the project actually works from an architectural perspective. You will also see a short demo of the project in action! Finally, you will hear about future plans for developing KubeVirt’s capabilities that are emerging from the community.
https://sched.co/ZevE
A
A
A
Kubernetes
has
seen
a
tremendous
growth
right
and
we've
seen
so
many
companies
and
people
organizations
being
interested
in
kubernetes
for
a
reason
right.
It's
bringing
spring
value
right,
they're,
new,
workflows,
new
concepts,
new
patterns
right.
I
think
that
declarative
approach,
new
networking,
plugins
new,
alerting
monitoring
tools,
auditing
tools,
tracing
tools,
there's
so
much
around
kubernetes.
You
see
it
at
every
real
kubecon.
A
On
this
slide,
you
actually
see
this
wave
on
the
right
hand,
side
the
reddish
area
right,
which
is
the
search
volume
for
docker,
and
we
sometimes-
or
we
often
actively
pursue
down
this
path.
We
personally
or
our
organization
or
developers
rise,
and
we
do
it
do
it
for
a
reason.
As
I
said
right,
the
newly
established
cloud
native
patterns
and
workflows
and
technologies
actually
many
of
them
finding
new
home
in
the
cncf
they
they
allow
us
to
do
our
work.
A
A
A
Guy,
I
still
tell
myself
as
an
infrastructure
guy
come
from
that
area
right,
I
think
we
have
to,
or
we
have
to
enable
our
developers
to
leverage
this
family
of
tools
right.
We
need
to
allow
them
to
play
with
them
to
learn
them,
to
adopt
them
to
to
write
new
applications
to
solve
new
problems
more
efficiently
than
they
did
it
before,
and
this
infrastructure
guide
just
to
get
back
is
I
think
it's
our
responsibility.
A
A
However,
as
an
infrastructure
guy,
on
the
other
hand
or
as
an
organization
right,
we
see
that
everything
we've
built
and
maintained
before
just
does
not
go
away
right.
A
lot
of
the
legacy
we
piled
up
in
the
last
decade
will
remain.
We
need
to
continue
to
operate
it
on
this
diagram
right
on
the
left
inside
the
blue
added.
A
Chart
no
data
points
are
showing
the
third
volume
around
virtual
machines
right
and
we
see
a
tip
on
the
left
for
vm
center
tip
on
the
right
for
for
containers
and
quotes
because
it
was
darker,
but
we
see
the
trend
right,
but
the
blue
is
actually
highlighting
how
much
we've
built
how
much
interest
there
was
right
and
we
need
to
maintain
that
we
find
we
need
to
find
a
solution.
What
we
do
with
this
as
an
infrastructure
guy
right.
A
Sometimes
we
can
rewrite
the
application
inside
the
vm
to
work
cloud
native
and
to
run
in
kubernetes,
but
sometimes
that's
not
possible
and
feasible,
for
example
from
financial
standpoint,
and
that's
where
kubert
comes
in
cuba
is
a
cloud
native
computing
foundation,
sandbox
project.
We
actually
entered
the
sandbox
last
year
and
it's
marrying
virtual
machines
and
kubernetes
right.
It's
you.
It's
a
kubernetes
add-on
right.
It's
an
operator
it's
using
crds
to
extend
the
kubernetes
api
and
it's
mapping
its
workloads
to
pods.
A
You
effectively
only
need
a
single
yammer
line
in
order
to
install
it.
So
how
does
it
look
technically?
We've
got
cubectl
at
the
top
left,
which
you
can
use
to
to
interact
with
with
cuber.
Right
has
a
lot
of
components,
and
the
essence
is
that
we
extend
the
api
and
we
run
pods
for
you,
which
act
as
vms,
and
I
would
like
to
steer
your
focus
to
two
important
areas
that
actually
show
the
important
bits
of
kubernetes
on
the
left-hand
side.
You
see
that
circle,
which
is
circling
out
the
word
controller.
A
This
makes
kuber
declarative.
Just
like
kubernetes
is
right,
so
you
have
yamls,
you
define
the
desired
system
state
or
the
desired
vmc
in
this
case,
and
the
controller
and
other
controllers
will
make
sure
to
get
that
system
into
that
stale
or
fail
right.
So
it
feels
like
kubernetes.
The
way
how
you
interact
with
the
system
is
just
like
kubernetes
on
the
right-hand
side,
the
other.
The
second
important
aspect
is
that
to
cube
it's
a
pod
and
that's
fine
right,
we
did
not
want
to
teach
kubernetes
yet
another
entity.
A
Instead,
we
wanted
to
say
parts
remain
the
atomic
compute
unit,
and
that's
why
vms
are
ultimately
running
inside
of
pods.
This
actually
enables
a
few
things,
because
first,
the
orchestrator
can
be
kept
simple.
It
doesn't
need
to
know
two
kinds
and
tools
that
know
how
to
monitor
ports.
For
example,
they
implicitly
monitor
vms.
A
Cube
ctl
will
thus
be
the
tool
of
choice
to
rule
them
all
right.
So
I
I
was
already
saying
we're
extending
the
api
and
you
can
simply
use
cube
cd
and
edit
cube.
Cdl
patch
cube
cdl,
create
to
to
work
with
vms,
actually
live
migrations
which
I'll
get
to
in
a
second
are
handled
the
very
same
way
with
cube
cdl.
A
There's
a
companion
tool
called
vert
ctl,
which
provides
a
little
bit
more
convenience
like
there's
certain
things
which
are
not
relevant
for
containers
like
graphical
desktops
and
thus
they're
not
present
in
cube
cdl
word
ctl
allows
you
to
directly
connect
to
the
graphical
desktop,
but
it's
really
the
exception.
Bird
ddl
can
be
installed
as
a
plugin
to
cube
cdl,
for
example,
using
crew.
A
So
what
can
you
manage?
We've
got
the
basics
right
start,
stop
pause,
resume,
live
migration
might
sound
odd,
but
because,
as
I
mentioned
before,
pots
are
like
you
know,
vms
are
running
inside
parts.
Consider
the
part
to
be
to
the
context
and
then
the
live
migration
is
nothing
else.
Then
then,
moving
a
pro
or
the
vm
from
one
context
to
the
new,
where
the
context
is
the
part
pods.
However,
it
cannot
be
life
migrated
just
to
clarify
that
point.
A
We
support
multi-network
and
actually
srv
network
card
using
motors,
so
we're
not
inventing
something
new
here
we
just
tied
into
the
de
facto
networking
standard,
which
multis
is
one
implementation
of
we
support,
block
and
also
file
system
storage
using
persistent
volume.
So
the
same
mechanism
and
we've
got
pending
prs,
maybe
by
now,
therefore,
by
the
time
of
this
session,
and
that
pr
is
actually
merged
or
not.
The
important
point
here
is
it's
mapping
to
the
underlying
infrastructure
of
kubernetes,
again
so
volume
snapshots.
A
Why
is
that
important?
Because
the
thing
to
highlight
here
is
that
the
resources
are
not
managed
by
kubernetes.
Kubrick
is
exclusively
consuming
resources
from
kubernetes
right
sorry,
the
resources
are
exclusively
consumed
from
kubernetes.
Kubert
is
not
doing
any
management
here,
and
that
has
a
few
benefits
we'll
see
in
a
few
slides.
A
One
benefit
is
that
you
develop
on
and
only
use
one
platform
right,
so
developers
which
want
to
work
with
either
vms
or
containers.
They
just
have
to
know
that
one
platform
right
there
are
ides
like
j
which
can
run
on
kubernetes,
and
you
can
just
use
that
ede
ide
to
to
really
work
with
both
entities.
A
This
enables
developer
self-service
right
and
it's
actually
simplifying
and
unifying
the
access
to
resources
in
general
right
with
pods.
You
already
have
the
abstractions
like
dynamic
provisioning
right,
which
are
providing
dynamic
access
based
on
the
quota.
You
have
to
storage
or
network
is
transparently
there
and,
as
cuber
is
tying
to
the
same
models,
the
same
workflows
or
self-service
limitations
or
opportunities
applied
to
cuber
as
well.
A
One
interesting
part
or
use
case
that
has
emerged
relevant
for
developers
is
actually
coupon
cube.
Right,
kubert
is
providing
you
vms
on
bare
metal,
kubernetes
clusters,
and
once
you
have
those
vms
and
you
have
network
and
you
have
storage,
then
you
can
actually
easily
bring
up
a
kubernetes
cluster
running
on
kubernetes
actually
can
bring
up
multiple
kubernetes
clusters
running
on
a
single
shared
kubernetes
cluster
as
the
infrastructure
below
there
are
a
couple
of
community
projects
which
are
focusing
on
this
specific
use
case,
and
that
actually
is
the
segway.
For
this
slide.
A
You
only
have
to
operate
one
platform
and
even
in
the
previous
case,
right
that
there
might
be
multiple
instances
of
the
same
platform
right.
You
have
tenant
clusters
using
kubernetes
and
the
under
kubernetes
cluster
to
host
them.
It
still
means
that
you've
got
one
system,
you
need
to
know
and
one
system
you
need
to
know
inside
out
right
and
that's
relevant,
because
there
are
different
parties
in
your
company
and
they
need
to
speak
to
each
other
about
in
this
system
right,
resolving
problems.
The
developer
can
speak
to
to
the
it
department
to
understand.
A
Why
is
my
storage
provisioning
not
working
right
and
there's
only
one
system
to
worry
about
not
multiple
important
here
is
also
to
note
that
that
with
kubert
we're
actually
setting
we're
setting
the
stage
for
where
we
want
to
go
right,
we
with
kubert,
you
have
the
opportunity
to
say
this
is
the
ideal
architecture
I
want
to
pursue
in
future
right.
I
would
have
kubernetes
at
the
heart
and
extend
it
to
support
my
legacy
workloads
as
long
as
I
need
them
now.
A
Let's
get
to
the
heart
of
this
session
and
to
scale
just
a
few
words,
because
before
I
head
over
to
marcus,
so
cubert
in
general
is
adopting
patterns
from
cube
rights,
adopting
controllers
and
watchers
to
efficiently
work
with
or
scale
out
too
many
entities
on
the
node
level.
It's
actually
using,
as
I
said
before,
network
storage
and
other
node
level
features
from
kubernetes
and
not
inventing
their
own.
So
in
both
cases
on
the
cluster
level,
because
we
adopt
the
same
patterns
as
kubernetes,
we
do
not.
We.
A
There
are
also
no
limits
from
the
kubernetes
keyboard
perspective
in
the
scale
of
how
these
resources
can
be
consumed
on
the
load
level
or
in
other
words
there
should
be
no
kubert
specific
limits
on
the
node
or
cluster
level,
because
we
inherit
most
of
the
stuff
from
kubernetes
anyway.
So
kubernetes
is
setting
the
scale
elements.
A
B
B
I
was
lucky
enough
to
be
able
to
travel
across
the
globe
and
help
set
up
new
semiconductor
facilities
and
the
data
centers
that
serve
them
from
there
I
transitioned
to
public
web
hosting.
I
worked
at
bluehost
and
endurance
international
and
there
I
learned
a
lot
about
internet
traffic
networking
technologies.
B
B
I'm
going
to
start
today
by
talking
about
the
things
that
actually
attracted
me
to
cube
vert
in
the
first
place.
What
what
was
it
that
interested
me
and
got
me
thinking?
The
cuber
was
worthwhile
to
participate
in
then
I'll
talk
about
some
of
the
challenges
that
I
ran
into
and
which
ultimately
led
to
contributions
and
changes
to
cubeverd
itself.
B
B
B
B
B
Kubernetes
cluster,
but
there
are
some
issues
that
I
ran
into
when
I
was
trying
to
use
it.
The
first
thing
that
comes
to
mind
is
the
evert
operator
deployment
model.
The
vert
operator
makes
it
easy
to
deploy
cube
vert
into
a
cluster,
the
keyboard
components.
There
are
a
lot
of
components
that
are
complex,
configuration
wise
and
to
maintain
upgradeability
and
make
it
easy
for
people
to
deploy.
We
have
this
operator.
B
The
problem
I
ran
into
was
that
you
know.
Inevitably
I
found
some
small
tweaks
and
things
that
would
need
to
be
done
to
the
various
keyboard
deployments
that
I
really
couldn't
do,
because
it
was
gated
by
this
vert
operator
and,
like
fabian
alluded
to.
If
you
find
that
you
have
to
scale
the
resources
for
your
individual
deployments,
maybe
you
have
different
priority
classes
or
things
you
need
to
change
about
the
way
that
the
individual
components
are
deployed.
B
B
So.
One
of
the
solutions
that
I
found
to
this
was
that
I
can
you
can
actually
run
vert
operator
in
a
mode
where
it
will
dump
its
install
strategy
to
a
config
map,
and
when
you
do
that,
you
can
see
everything
that
vert
operator
was
going
to
do
and
you
have
all
the
ammo
and
you
can
tweak
and
then
deploy
that
manually.
How
you
see
fit-
and
I
think,
there's
room
to
improve
this
in
the
community
going
forward
and
I
hope
to
be
able
to
work
on
that.
B
B
So
because
of
this,
I
thought
it
would
be
good
to
add
a
configuration
that
allowed
the
customer
to
maintain
their
inserts
and
the
idea
being
that
the
vert
operator
is
usually
creating
these
certificates
and
rotating
them.
By
using
the
secrets
and
config
maps
attached
to
all
of
the
cube
vert
components,
it
should
be
possible
for
a
user
to
write
a
controller
they
can
reach
out
to
the
ca
of
their
choosing
and
populate.
B
I
also
found
an
undocumented
requirement
for
net
raw
cuber
was
assuming
that
net
raw
was
a
default
capability
of
all
of
the
pods
and
all
the
containers
in
in
kubernetes.
And
so,
if
you
run
into
a
situation
where
your
cluster
has
disabled
net
raw
as
a
default
capability,
then
you
would
run
into
problems
running
kubert.
B
And
finally,
I
ran
into
a
compatibility
problem
with
cube,
vert
and
container
d
now
normally
cube,
vert
is
compatible
with
cryo
and
it's
mostly
tested
against
cryo
and
theoretically.
It
should
work
with
any
container
runtime,
but
we
found
that
when
running
it
with
container
d,
there
was
a
problem
in
parsing
the
c
groups.
It
was
assuming
that
there
weren't
any
colons.
I
think
it
was
in
the
actual
seeger
path
when
it
was
trying
to
figure
out
where
some
of
the
container
components
were,
and
so
that
was
patched
and
now
cube.
B
B
B
B
So
when
jenkins
sees
that
my
kickstart
files
have
changed,
it
goes
and
spins
up
an
agent
as
a
pod
with
dev
kvm,
and
then
some
scripting
will
run
vert
install
and
it
will
go
through,
create
the
template.
You'll
end
up
with
a
qcad2
file
and
then,
as
the
last
step
in
the
jenkins
pipeline,
it
can
push
that
off
to
an
artifact
repository,
and
so
you
get
the
ci
cd
pipeline
of
vm
template
generation
all
running
kubernetes,
and
so
I
found
that
so
far
to
be
super
useful
and
a
great
way
to
automate
vm
template
generation.
B
This
is
super
helpful
if,
in
cases
where
you
don't
have
minicube
that
can
handle
virtualization
or
you
want
to
create
a
consistent
repeatable
process
or
even
for
like
ci
cd
type
use
cases.
If
you
need
a
kubernetes
cluster,
not
just
for
keyboard
development
but
for
any
sort
of
kubernetes
development,
this
would
be
a
good
way
to
automatically
get
a
kubernetes
cluster
that
you
can
play
with
using
kubernetes
itself.
B
So
the
idea
was
that
I
created
a
vm
template
that
using
cloud
init
I
can
actually
trigger
cube
adm
to
install
kubernetes
inside
of
the
virtual
machine,
and
so
you
deploy
this
vm
template.
You
use
kubert
to
deploy
the
vm
in
your
cluster
and
then
you
can
target
it
and
you
can
do
all
of
your
development
on
it
so
specifically
for
cube
vert
development.
B
Another
thing
that
I
found
really
interesting
is
that
I
can
actually
deploy
hypervisors
with
kubernetes
using
kubert
vms,
and
so,
as
I
mentioned,
I've
been
involved
in
virtual
machine
orchestration
platforms
for
a
number
of
years
and
in
order
to
develop
on
those
platforms,
you
need
environments
that
can
be
spun
up
easily
and
can
be
thrown
away
and
rehashed
and
restarted,
and
so
kubernetes
with
cube.
Vert
allows
me
to
do
this.
The
the
general
pattern
is
that
you
would
create
your
control,
plane
and
or
all
of
your
satellite
services
as
pods.
B
In
my
case,
I
set
up
the
cloud
stack
management
server
as
a
pod,
and
I
fronted
that
with
the
service
and
ingress,
and
then
you
can
deploy
your
hypervisors
as
virtual
machines
and
again
this
is
where
the
nested
kvm
really
comes
in
handy.
You
can
run
virtual
machines
inside
of
those
virtual
hypervisors
that
you
deploy
and
I've
done
all
sorts
of
interesting
experiments.
With
these
I've
even
run.
You
know
vxlan
tunnels
over
the
pod
networking
and
done
some
more
advanced
networking
tests
and,
and
things
like
that
with
hypervisors.
B
You
know,
as
far
as
other
use
cases
that
I
could
imagine
people
would
want
to
do.
You
know
there
could
be
situations
where
people
require
different
operating
systems.
You
know
they
can't
necessarily
run
inside
the
linux
kernel
and
they
may
have
a
an
appliance
that
is
provided
by
a
vendor
and
it's
something
they
can
run
in
a
container.
B
B
So
I
just
wanted
to
finish
off
by
talking
about
some
tips
that
things
that
I've
learned
that
I
found
useful
as
far
as
operating
cube,
vert
and
using
kubevert,
and
hopefully
you'll
find
some
of
them
useful
too.
The
first
one
is
regarding
cube
vert
test
suites.
So
if
you
look
at
the
cube
verb
code
base,
there
are
actually
tests
functional
tests
that
are
in
the
code
base
that
you
can
actually
target
to
a
specific
cluster.
B
You
can
run
it
in
a
cluster
and
you
can
actually
set
it
up
as
a
cron
job
inside
the
cluster,
and
that
would
give
you
like
a
continuous
feed
as
to
whether
or
not
whether
or
not
kubert
is
working
at
any
given
moment
and
give
you
statistics
on.
You
know
how
well
it's
working
there's,
also
a
prometheus
endpoint
in
most
of
the
kubert
services
that
you
can
monitor.
B
Another
thing
to
consider
is
to
be
aware
of
quotas
in
ip
use,
with
the
vert
handler,
because
vert
handler
is
a
demon
set
and
because
it
doesn't
use
host
networking
every
single
node
is
another
ip
address
that
you
may
use
up
in
your
cluster.
So
if
you
have
very
large
clusters
and
you're
deploying
vert
handler
to
every
single
node,
there
may
be
a
significant
number
of
ip
addresses
used
up
in
your
cluster
and
also
you
have
to
scale
your
quota.
B
If
you
have
resource
quotas
for
kubevert,
you
have
to
make
sure
you
scale
your
resource
quotas
to
match
the
size
of
your
cluster
so
that
you
can
deploy
all
of
the
vert
handlers
that
you
need
to
and
the
last
one
I
think
I
mentioned
several
times
that
the
actual
device
plug-in
the
kvm
device
plug-in
that
is
provided
by
vert
handler
can
be
used
by
itself.
You
can
use
it
to
create
vm
templates,
like
I've
shown
or
you
can
use
it
for
any
other
purpose.
B
That
might
require
you
to
spin
up
a
virtual
machine
manually,
and
I
think
that's
all
I
had
as
far
as
tips.
You
know
there's
so
many
things
about
qvert
that
I
could
add
here.
It
has
so
many
different
features.
You
know,
there's
gpu,
support
and
network
virtual
functions
and
different
types
of
volumes
and
multiple
networks.
B
There
are
different
tweaks.
You
can
do
to
the
virtual
hardware
and
there's
even
more
coming,
so
I
think
that
speaks
to
the
diversity
of
the
use
cases
and
the
teams
and
groups
that
are
finding
cube,
vert
interesting
out
there
and
along
those
lines.
I
just
want
to
thank
the
community,
for
you,
know,
being
open
and
providing
feedback
and
answering
questions
and
just
being
super
helpful
and
welcoming
in
general.