►
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
Intro: Virtual Kubelet - Ria Bhatia, Microsoft & Ben Corrie, VMware
The intro to virtual kubelet session will go through the architectural design and the history of the virtual kubelet project. The session will feature use cases, demos and current ways of using virtual kubelet in your own kubernetes clusters to scale into burst capacity, or manage other kinds of resources like IoT Edge deployments.
To learn more: https://sched.co/I1Xj
A
My
name
is
Rhea
I'm,
a
program
manager
at
Microsoft
and
I've
been
with
this
project
since
the
beginning.
We
actually
release
it
about
a
year
ago
and
we'll
go
into
some
history.
So
if
you
went
on
our
on
the
web
site-
and
you
saw
that
Sudan
Way
was
speaking
with
me-
that's
actually
another
PM
on
my
team,
who
hasn't
done
much
yet
with
virtual
couplet,
but
probably
well
in
the
future,
but
really-
and
we
have
been
here-
who's
been
working
with
me
on
with
virtual
couplets
since
the
beginning,
so
I'm
gonna.
B
B
What
are
people
doing
with
it,
and
then
Ria's
gonna
focus
more
on
the
kind
of
the
use
cases
kind
of
deep
dive
into
how
customers
are
making
virtual
cubelet
work
for
them.
It's
interesting
to
note,
I
think
it
was
this
time.
Last
year,
the
virtual
cool
it
was
announced
that
Cube,
Conn
and
I
got
very
excited
by
it.
Oh,
we
need
to
plug
this.
In
don't
mean
that
would
help
all
right,
yeah
101
of
presenting
a
thing.
B
Okay,
there
we
go
so
I
want
to
talk
briefly
about
like
why
why
I
was
excited
about
it,
so
I've
been
working
for
years
on
a
product
in
VMware
called
vSphere,
integrated
containers,
and
we
came
up
with
this
idea
of
a
virtual
container
host.
The
virtual
container
host
is
kind
of
different
to
a
actual
container
host.
This
is
back
in
the
docker
days
when
all
we
thought
about
was
a
single
host
in
that
it's
not
a
VM.
It's
not
like
this
static
thing
that
you
deploy
containers
into
it's
just
an
abstract
concept.
B
It's
like
this
resource
limit
into
which
you
can
deploy
any
number
of
containers,
but
if
you
don't
deploy
any
containers,
you
don't
consume
any
resource,
and
so
we
came
up
with
this
idea
of
a
virtual
container
host
and
the
way
that
it
worked
is
there
was
just
a
simple
API
endpoint
that
would
run
in
a
vSphere
cluster
and
do
I
have
a
pointer
here,
no
I,
don't
think.
Oh
there
we
go
yeah
little
API
endpoint.
B
That
would
run
in
a
vSphere
cluster,
and
this
was
what
you
would
connect
to
with
the
daughter,
client
and
the
virtual
container
host
was
just
this
abstract
resource
limit.
And
when
you
want
to
deploy
container,
the
vSphere
scheduler
would
take
over
and
would
figure
out
which
host
to
put
your
container
on
and
then,
if
it
wanted
to
life
migrate,
those
containers
around
it
could
do
that
completely
transparently
to
the
client.
B
The
client
just
sees
a
host
a
single
thing,
but
actually
behind
the
scenes,
as
many
hosts
and
there's
all
sorts
of
other
interesting
and
useful
things
happening,
and
this
is
a
very
useful
parallel
for
the
way
that
virtual
kulit
is
designed
to
work.
So
this
is
just
scraped
from
the
virtual
couplet
readme
in
the
get
in
the
github
repo
I
highly
recommend
going
and
kind
of
looking
at
some
of
the
information
in
there
because
there's
a
there's
some
good
data
in
there.
B
The
idea
of
virtual
couplet,
though,
is
very
similar
to
this
idea
of
the
virtual
container
host
that
I
just
referred
to
in
that
it
allows
us
to
think
about
resource,
contain
a
resource
pod
resource
in
the
abstract.
A
virtual
Kubler
is
not
a
literal
VM,
it's
not
a
literal
computer
that
runs
containers.
It
is
a
cuddler
to
this
concept
of
an
abstract
resource
constraint,
into
which
pods
and
containers
can
be
deployed
in
some
place.
B
So
virtual
Kubler
in
theory
gives
you
a
lot
of
flexibility
in
how
you
not
only
manifest
your
containers,
but
also
the
the
resource
that
you
containers
use
and
indeed,
as
well,
like
we've
seen
in
HCI
the
way
that
you
pay
for
your
containers.
So
let's
delve
into
this
a
little
bit
more
depth.
So
kubernetes
fundamentally
is
a
node
based
scheduling
system.
That's
what
it
is
and
that's
what
it
does
it
needs
nodes.
It
will
always
need
nodes,
because
the
node
is
the
fundamental
building
block
of
a
cluster.
B
But
this
is
how
we've
come
to
think
of
a
node
and-
and
just
because
this
is
how
a
node
is
today
doesn't
mean
that
we
can't
be
a
little
bit
more
flexible
in
terms
of
how
we
think
about
it,
to
get
business,
to
get
business
value
out
of
kubernetes,
so
I'm
gonna
dive
a
little
deeper.
This
was
some
a
diagram
that
we
did
when
we
were
looking
at
Kubler
kind
of
early
on
in
the
and
the
virtual
cubelet
project.
B
We
wanted
to
say
to
ourselves:
okay,
well,
what
functionally
does
Kubla
do
like
what
is
Kubler
and
we
kind
of
actually
went
through
all
the
code
and
the
net
result
of
all
of
that
was
this
one
slide,
which
very
succinctly
explains
what
Kubla
is
and
what
it
does.
Kubler
fundamentally
is
a
node
agent.
It's
job
is
to
it
has
two
fundamental
jobs.
B
One
is
to
manage
your
configure
the
note
and
make
sure
that
it's
you
know
it's
it's
ever
all
the
resources
in
the
node
are
being
correctly
apportioned
to
pods
and
containers
and
images
and
ephemeral
storage,
and
all
these
other
things.
The
second
job
that
it
has
is
pilot
and
container
lifecycle
management.
So
the
things
like
you
know,
starting
containers,
init
containers,
liveness
redness
checks.
All
these
all
these
are
the
things
now.
The
way
that
couplet
works
is
it
has
two
paths
to
control
paths.
B
One
is
the
asynchronous
path
which
you
see
on
the
left
here,
which
is
a
polling
based
mechanism,
and
it's
actually
interesting,
because
if
you
go
to
Kubler
and
look
for
an
api,
there
isn't
like
a
big
API
in
Kubla,
there's
not
like
a
start
pod
API
in
cubelet,
for
example.
It
doesn't
do
it
quite
that
way.
It
has
this
polling
side
of
the
fence
which
handles
all
the
things
like
you
know.
B
Basically,
the
lifecycle
of
any
kubernetes
object
and
turns
that
into
things
like
creating
and
mounting
volume,
while
mounting
volumes,
you
know,
secrets
configuring
the
host
for
DNS.
You
know
updating
a
pod
starting
a
pod,
stopping
the
pod.
All
these
things
are
handled
by
that
asynchronous
side
on
the
left.
On
the
right
hand,
side
we
have
the
synchronous
path,
which
is
all
of
the
interaction
that
you
might
have
with
the
Container
via
coupe
cuddle.
B
So
if
you
want
to
get
a
shell,
for
example,
into
a
container
or
run
a
process
in
it
or
get
logs
from
it,
that's
a
synchronous
path
that
goes
through
this.
This
this
channel
on
the
right
hand,
side,
and
you
can
see
some
of
the
high
level
function-
that
kulit
handles
down
there
in
the
bottom
right
now.
Kubla
also
has
its
own
internal
control
loops
to
things
like
garbage
collection,
making
sure
that
pods
are
evicted
if
it
starts
getting
low
and
resources,
as
I
mentioned
the
liveness
and
readiness
probes.
B
So
this
is
kind
of
from
a
very
high-level
perspective.
What
Kubler
is
and
what
it
does
so
approaching
this
from
the
perspective
of
virtual
kulit,
you
kind
of
have
to
ask
yourself:
well,
okay,
if
we're
creating
this,
this
virtual
note
that
kubernetes
master
is
going
to
interact
with
if
it's
going,
to
look
and
feel
and
smell
and
behave
just
like
a
regular
node.
B
So,
let's
talk
in
a
little
bit
more
depth
in
about
virtual
Kubla
and
and
what
the
point
is
now
I
want
to
just
stress.
The
point
of
virtual
cubelet
is
not
to
replace
regular
Kubler,
it's
not
as
a
it's,
not
designed
to
be
a
ground-up,
Ryoka,
texture
or
ground-up
refactoring
of
Kubla.
It's
not
that
at
all.
It's
it's
a
kubernetes
client
that
aims
to
represent
a
different
kind
of
resource
than
just
a
regular
kubernetes
node.
B
So
we
talked
earlier
that
a
virtual
couplet.
The
whole
point
of
it
is
that
it
allows
us
to
be
a
little
bit
more
flexible
about
how
we
think
about
nodes
and
pods.
So
it
allows
us
to
think
about
them
more
in
the
abstract
than
in
the
literal
way
we
think
about
them
in
a
vanilla,
kubernetes,
node,
so
nodes,
rather
than
being
this
thing
with
a
couplet
in
it,
this
operating
system
running
a
couplet
with
container
D
or
whatever
else
is
in
there.
It's
just
a
bounded
amount
of
resource
that
can
run.
B
That
is
the
definition
of
a
virtual
couplet
note,
quote-unquote,
and
a
pod,
of
course,
is
a
set
of
containers
that
are
running
within
a
sandbox,
but
the
way
that
the
sandbox
is
is
manifested
can
be
something
that's
quite
flexible
because
virtual
cube,
it's
not
opinionated
about
that.
So
when
you
get
into
those
specifics
about
what
a
container
is,
what
upon
is
how
you
do
garbage
collection?
How
you
do
image
management
all
these
other
things,
all
that
is
encapsulated
inside
of
a
thing
called
a
provider
which
which
which,
which
is
a
pluggable
interface
in
virtual
cubelet.
B
Something
like
10:
is
it
10
providers
in
the
bunch
of
12?
Ok,
there's
quite
a
few
providers
in
the
virtual
cube
that
github
repo
now
there's
one
for
Fargate,
there's
one
for
a
CI.
This
there's
a
bunch
of
them
in
there
and
it's
interesting
to
note
that.
Actually,
you
know
if
we
go
back
to
this.
This
previous
slide,
like
the
things
that
you
really
need
here,
that
are
common
to
every
single
provider,
is
mostly
the
stuff
in
this
box.
B
On
the
left-hand
side,
the
polling
mechanism,
the
event
handling
and
the
stuff,
on
the
right
hand,
side
that
handles
that
the
synchronous,
interaction
with
containers
that
stuff
that
every
single
provider
is
going
to
need.
So
that's
the
stuff,
that's
in
the
core,
that's
in
the
base,
but
the
base
is
actually
quite
small.
The
common
code
is
is
a
relatively
small
and
simple
code
base,
and
much
of
the
complexity
is
intentionally
left
up
to
the
provider
to
deal
with,
and
the
interface
is
exactly
what
you
would
expect
it
to
be.
B
B
So
this
whole
question
of
why
virtual
Kubler
I
think
is
a
really
really
important
question
that
Andrea
is
going
to
delve
into
that
and
a
lot
more
when
she
looks
at
use
cases
but
I
think
it's
a
really
important
question,
partly
as
it
as
I
mentioned,
because
you
know
it's
important
that
it's
not
seen
as
some
that
is
necessarily
there
to
replace
existing
couplet.
Maybe
it
could
be
named
a
little
bit
differently,
but
it
seemed
an
appropriate
name
at
the
time.
I'm
sure,
ultimately,
is
there
to
give
us
flexibility
of
abstraction.
B
It
allows
us
more
potentially
more
granularity
in
terms
of
the
way
we're
deploying
things.
Let
me
give
an
example,
so,
speaking
to
Alex
Alex
this
morning,
he
was
the
crater
open
fires
and
he
was
saying:
well:
wouldn't
it
be
really
cool
if
we
had
like
these
little
IOT
nodes
and
and
in
each
one
was
a
little
container
engine,
we
could
just
deploy,
containers
or
positive
these
IOT
nodes,
and
then
it's
going
to
be
this
edge
controller
that
just
kind
of
controls
all
the
IOT
nodes.
B
Well,
wouldn't
it
be
cool
if
we
could
add
that
edge
controller
to
a
kubernetes
cluster
and
get
kubernetes
to
deploy
containers
to
all
these
little
IRT
notes,
I
was
like
yeah
that
would
be
cool.
That
is
exactly
the
kind
of
use
case
that
virtual
cupola
addresses
right.
It's
a
non-standard
node
idea
in
that
the
edge
controller
is
not
a
typical
kubernetes
node,
but
the
edge
controller
can
handle
the
scheduling
it
can
handle.
B
You
know
how
containers
go
to
which
IOT
device
and
routing
and
networking
and
various
other
things,
but
you
can
take
a
step
back
from
that
and
then
abstract
it
out
and
say
regardless
of
how
this
is
all
manifesting.
We're
still
thinking
about
this
as
a
node
and
we're
still
thinking
about
pods
and
containers.
B
So
here's
just
four
bullet
point
use
cases
that
I'm
going
to
sort
of
cover
from
out
from
a
high
level
perspective
before
before
we
hand
over
to
real.
The
hybrid
use
case
is
one
that
Microsoft
have
been
demoing
a
lot
with
the
a
CI
connector
that
we
have
a
hybrid
use
case
is
very
simply:
I
have
an
existing
kubernetes
cluster
and
maybe
on
Prem.
It
may
be
in
a
KS.
It
may
be.
B
He
knows
where
it
is,
and
I
want
to
have
the
ability
to
deploy
pods
to
something
that
either
I
can
burst
into
or
that
I'm
paying
like
for
the
pod
and
not
for
the
node
right,
because
a
CI,
obviously
the
ability
to
pay
for
containers
that
are
running
and
pay
for
pods
that
are
running
the
moment.
You
shut
them
down,
you're,
not
paying
for
them
anymore,
which
is
a
very,
very
flexible
way
to
pay
for
things.
Well.
This
one
node
can
represent
that
portal
in
turn
into
a
CI
and
theoretically
infinite
resource
right.
B
So
it
allows
your
one
cluster
to
have
this
kind
of
special
magic
portal.
That
sounds
like
a
children's
book.
Doesn't
it
right
one
for
containers
and
pods
to
go
into
into
a
CI
and
be
deployed
there?
So
that's
the
hybrid
use
case,
an
interesting
other
use
case
that
I
haven't
actually
seen
yet,
but
I
think
would
be
would
be
worth
experimenting
with,
is
one
in
which
you
put
a
virtual
Kubla
in
each
availability
zone.
B
So
you
might
have
a
cloud,
and
you
know
you
have
you
know
virtual
Kubla,
that
represents
positive
Loyd
and
one
availability
zone
and-
and
you
may
have
any
number
of
availability
zones
and
then
you
add
those
to
a
single
kubernetes
cluster
that
can
then
deploy
pods
across
availability
zones.
Well,
that's
kind
of
cool,
because
you
then
keep
this
notion
of
affinity
and
anti
affinity.
B
So
you
can
make
sure
that
your
your
replica
set
is
deployed
across
availability
zones
without
but
with
just
a
single
cluster
single
scheduler,
so
that'll
be
kind
of
a
cool
idea
and
I
mention
the
IOT
use
case.
And
then
you
know
at
any
any
use
case
really
where
you
have
a
node
that
really
doesn't
conform
to
the
way
that
kulit
expects
things
to
be
virtual.
Cubelet
could
be
a
solution
for
you,
so
I
have
a
minute
from
handing
over
to
RIA
I.
Don't
want
to
skip
over
this
because
compatibility
challenges
is
such
an
important
question.
B
It's
one
that
a
lot
of
people
immediately
want
to
ask
questions
about
so
I've
laid
out.
What
I
think
are
the
most
significant
compatibility
challenge
is
a
virtual
couplet,
and
the
first
point
to
make
here
is
that
that,
when
pods
are
deployed
to
a
special
node
of
virtual
Kubla
node,
you
have
to
want
that
to
happen.
It's
not
something!
That's
just
going
to
happen
automatically.
You
have
to
specifically
say:
ok,
this
node
is
special
I'm,
giving
it
this
taint
and
and
I
want
particular
pods
to
be
deployed
to
that
node.
B
So
that's
how
how
you
might
use
it
now.
In
some
of
these
use
cases,
a
virtual
couplet
could
represent
multiple
fault
domains,
in
which
case
the
whole
notion
of
affinity
and
anti
affinity
becomes
a
difficult
one
to
wrestle
with,
because
it's
just
a
single
node
right,
so
it
in
the
case
where
we
have
multiple
nodes
in
multiple
availability
zones.
Again,
you
know
you
sort
of
you
can
think
about
those
as
fault
domains,
and
you
can
get
that
capability
back,
but
it
doesn't
always
map
one-to-one
as
cleanly
as
a
regular
node
would
in
a
kubernetes
cluster.
B
If
that
makes
sense
to
people
now,
of
course,
privileged
containers.
Can't
you
can't
guarantee
that
they're
going
to
get
access
to
an
ABI
and
get
access
to
the
resources
of
a
node,
because
there
is
maybe
there
may
be-
is
no
node
right.
There,
probably
is
a
note
somewhere,
but
you
know,
you're
privileged
container
is
not
necessarily
going
to
get
you
access
to
that
node.
B
Another
one
is
that
when
you
deploy
pods
in
a
node,
there's
quite
a
bit
of
configuration
that
they
inherit
from
that
node
either,
because
the
node
has
a
volume,
like
maybe
secrets,
are
going
to
be
written
to
a
volume
and
you
update
the
secret
and
automatically
because
the
volume
is
bi
and
mounted
into
a
container.
The
container
gets
to
see
that
updated
secret
right.
It's
inheriting
that
state
from
the
node
in
virtual
Kubla.
B
Again,
you
can't
guarantee
that,
because
there
may
be
no
node
or
the
node
may
be
distributed,
so
a
notion
of
actually
being
able
to
push
things
to
pods
rather
than
pods.
Inheriting
a
configures
is
something
that's
been
built
into
virtual
cubelet
and,
of
course,
the
provider
itself
has
to
either
either
implement
a
lot
of
function
to
deal
with
all
of
these
things
like
image
management
volume
management
either
you
know
the
either
you
going
to
rely
on
it
on
a
COO,
but
another
kubernetes,
cluster
somewhere
or
you're
gonna
have
something
else.
B
That
does
that
for
you,
but
that's!
These
are.
These
are
the
high
level
compatibility
challenges
that
that
we
confront,
with
with
virtual
equivalent
I
think
that
is
yeah.
That's
the
last
of
my
slides,
so
I'm
gonna
head
over
to
rear.
Thank
you
and
we're
gonna
have
time
for
questions
at
the
end,
so
yeah.
A
Time
for
questions,
okay,
so
I'm
gonna
take
the
perspective
of
first
of
all
a
provider
but
then
also
a
customer.
So
with
an
azure
we
we
decided
that
we
needed
virtual
couplet
for
a
couple
of
reasons
and
I
actually
want
to
skip
forward
to
this
flight
and
then
go
backwards
because
I
want
to
go
through
the
history
first,
so
it
was
about
a
year
ago
when
we
came
together
and
we
had
this
project
called
a
CI
connector.
It
was
something
that
Brendan
had
just
come
up
with.
A
He
believes
that
pods
and
nodes
were
too
tightly
bound
in
kubernetes,
but
instead
of
trying
to
go
in
and
change
kubernetes,
we
decided
to
work
around
that
problem
and
create
the
Asya
connector.
So
it
was
actually
just
a
bunch
of
typescript
if
you
want
that
old
code.
For
some
reason
let
me
know,
but
it
only
worked
for
ACI.
It
only
worked
for
Asher
and
ACI
is
as
your
container
instances
so
on
the
fly.
We
can
spin
out
just
custom
containers
to
customers
on
demand,
so
it's
filled
per
second,
you
can
choose
the
amount
of
CPU.
A
You
want
the
amount
of
memory,
but
you
don't
have
to
manage
it.
So
there's
no
note
underneath
you
don't
have
to
deal
with
any
of
that.
You
just
give
it
an
image:
the
amount
of
resources
you
want
and
you're
good
to
go
and
you
can
get
a
public
I'd
be
IP.
You
can
get
a
private
IP,
it's
really
whatever
you
want.
So
that's
why
the
ACI
connector
was
born
because
we
started
to
think
about
what,
if
you
could
burst
from
kubernetes
to
this
unbounded
resource
taste
CI.
So
it's
a
completely
different
service.
A
It
doesn't
lie
in
your
cluster.
You
don't
manage
any
of
those
resources,
but
if
you
need
it,
it's
there
for
you.
So
that's
when
it
was
born,
and
then
we
built
virtual
couplet
because
we
realized
that
this
was
a
problem
and
this
was
something
that
other
providers
could
build
into.
So
that's
why
we
made
a
pluggable.
We
made
the
virtual
kulit
project
and
we
were
really
stood
as
a
community
project
this
time
last
year.
So
it's
been
a
year
and
I'm
really
excited
that.
Literally
a
couple
weeks
ago
we
were
I.
A
Guess
now
we're
in
the
CNC
F,
so
it's
really
great,
because
we've
been
working
for
a
really
long
time
on
this,
it's
been
kind
of
a
struggle
to
figure
out
where
the
right
home
was.
We
tried
to
go
into
kubernetes
and
we're
like.
Maybe
this
is
in
the
right
place,
we
can
live
without
kubernetes.
We
have
no
dependencies
on
the
couplet,
it's
just
an
abstraction
above
it,
so
some
challenges
of
creating
a
provider
as
Ben
talked
about
before
a
lot
of
those
decisions
are
on
the
provider
to
create.
A
So
within
a
CI
within
that
Azure
provider,
we
have
to
go
back
and
figure
out
how
networking
worked.
How
do
we
spin
up
a
coop
proxy?
So
we
actually
do
it
as
a
side
container
that
customers
don't
see.
So
you
don't
see
any
of
that
complexity.
We
just
say
what
subnet
do
you
want?
What
v-net
do
you
want
and
we
give
that
to
you?
You
don't
have
to
configure
anything
and
then
service
creation
was
also
difficult.
How
can
you
get
a
bunch
of
these
pods
to
be
backed
by
one
service?
A
Also,
what
should
a
max
node
resource
be
this?
This
is
something
that
I
thought
about
a
lot
I
mean
we
have
it
exposed
in
kubernetes,
but
it's
not
important
to
you
as
a
customer,
but
it
does
become
important
if
you're,
to
realize
that
your
service
is
running
out
of
resources.
So
ACI
itself
will
tell
you
hey.
We
don't
have
enough
resources
for
you
to
spin
out,
but
how
do
we
expose
that
in
kubernetes?
That's
something
we're
still
working
on
what
version
is
virtual
couplet?
A
This
is
something
we've
we
just
talked
about
in
our
last
meeting
is:
do
we
go
by
the
kubernetes
version?
Do
we
start
to
track
on
virtual
couplet
with
kubernetes
versions
that
doesn't
make
sense
really
because
we're
not
dependent
on
the
couplet?
So
we
don't
actually
care
about
what
kubernetes
version
you're
running,
but
we
do
have
a
version
of
virtual
couplet,
which
has
different
features
and
different
capabilities,
so
we
do
want
to
expose
it.
A
So
maybe
we
rewrite
the
couplet
version,
which
is
something
you
might
see
an
azure
in
the
future
and
then
how
do
we
enable
customers
who
want
to
monitor
their
pod?
So
a
lot
of
the
time
the
monitoring
comes
out
as
a
daemon
set,
it's
kind
of
difficult
because
all
of
your
logs
and
your
monitoring
data
is
held
in
the
seller
service
and
not
on
your
nodes
that
are
in
your
cluster.
So
we
basically
have
to
keep
create
those
pipelines
for
you
to
be
able
to
expose
all
that
monitoring
data.
A
So
as
a
customer,
these
are
kind
of
the
things
that
you'll
start
to
see
the
decisions
that
I
think
of
when
we're
looking
into
the
a
CI
provider
so
yeah.
So
some
use
cases
I'm
when
that
ban
also
went
through
was
the
IOT
edge
use
case.
We
do
have
an
IOT
edge
provider
and
basically,
you
can
represent
a
node
as
a
device
or
multiple
devices
and
anytime
you
spin
out
a
pod
to
it.
You
can
update
the
deployment
and
maybe
change
the
color
of
a
light.
For
example,
that's
kind
of
an
interesting
use
case.
A
You
can
also
represent
maybe
meters
or
icy
edge
devices
around
the
world
or
whatever
you
need
to
read
and
just
use
kubernetes.
This
is
a
common
API
to
deploy
things
to
it
and
then
the
virtual
node
architecture
and
I
cast.
This
is
something
that
we
use
deeply
in
Azure.
It's
a
use
case
that
we
talk
about
all
the
time,
but
basically
you
have
your
normal
kubernetes
cluster.
You
have
your
normal
nodes
in
your
cluster
and
then
you
have
this
thing
called
a
virtual
node.
A
So
it
looks
like
a
node
but
there's
no
resources
that
are
backed
by
it.
It's
literally
just
a
string
in
when
you
say
cuoco
to
get
nodes.
It's
just
a
string
and
it
kind
of
looks
like
a
node
to
you
anytime.
You
spin
out
a
pod
to
that.
Node
you're,
actually
spinning
it
out
in
teh,
CI
and
a
CI
has
a
lot
of
different
configurations,
so
you
can
have
Linux
or
Windows.
You
can
have
different
regions
and
then
virtual
couplet
has
a
lot
of
different
providers.
A
So
if
you
start
to
think
of
that,
you
can
have
kubernetes
as
your
common
control
plane,
but
you
can
start
to
spin
out
to
different
clouds.
If
you
want
it's
not
a
use
case,
we
support,
but
you
could.
You
can
have
a
virtual
kulit
that
that's
fun
out
to
different
regions
within
the
same
cluster
and
manage
it
from
one
place.
You
could
even
have
a
virtual
couplet
representing
a
completely
different
cluster
like
service
fabric
or
something
else.
These
are
all
things
that
have
been
enabled
by
virtual
couplet.
A
Maybe
there
are
things
that
you
want
to
experiment
with
or
try
out.
They
might
not
be
customer
or
enterprise
level
use
cases,
but
I
think
that's,
okay,
I
think
a
lot
of
these
use
cases
will
start
to
spring
up
but
yeah.
So
we
use
a
CI
as
something
in
Azure
in
a
chaos
and
we
basically
use
it
as
this
unbounded
resources
resource
where
you
don't
have
to
manage
the
notes
and
that's
really
important
for
customers.
They
can
also
scale
out
on
demand.
A
A
But
how
do
you
do
that?
So?
The
first
way
you
do,
that
is
by
adding
a
Toleration
to
your
virtual
notes
back,
so
this
allows
you
to
be
scheduled
out
to
virtual
couplet
and
if
you
didn't
have
this
you
wouldn't
be
allowed
to,
because
we
have
a
taint
on
the
note
itself.
So
you
just
have
to
keep
this
in
mind.
You
can
also
add
a
mutating
webhook
in
to
your
cluster
and
basically
anytime,
you
spin
out
a
pod
in
that
namespace
and
then
provided
namespace.
A
You
can
get
this
added
to
your
prospect,
so
you
don't
have
to
think
about
it,
which
is
nice.
So
the
key
right
here
is
Asscher,
but
you
can
have
any
provider
in
there
and
then
you
can
add
affinities
to
burst
out
from
a
CI
take
ass,
so
I'm,
and
this
can
be
used
also
in
any
kind
of
cluster.
But
if
you
have
this
node
affinity,
basically,
what
we're
saying
is
prefer
the
nodes
in
the
cluster
fill
those
out
and
then
burst
out
to
a
CI.
A
So
you
want
to
actually
fill
out
the
nodes
that
are
in
your
cluster
before
you
burst
out,
because
it's
just
gonna
save
you
money.
If
you
already
have
those
nodes,
but
you
want
to
have
that
extra
burst
capabilities,
if
you
need
it
so
one
example
is
a
Black
Friday
example,
and
we
also
have
like
a
demo
that
you
guys
can
try
out
as
your
samples
repo.
A
But
basically,
if
you
have
a
lot
of
load
coming
in
and
you
haven't
pre
provisioned
your
notes
for
a
couple
good
reasons-
one
you
don't
want
to
spend
a
lot
of
money,
maybe
you're
not
really
sure
when
the
loads
gonna
come
in.
Maybe
it's
gonna
be
midnight.
Maybe
it's
gonna
be
3
a.m.
but
the
biggest
thing.
Is
you
don't
want
to
provision
all
those
nodes
and
have
to
manage
them?
A
So
you
could
have
virtual
couplet
installed
in
your
cluster
or
virtual
node
and
then
automatically
you
can
be
scaled
out
into
a
CI
without
thinking
about
it.
So
with
this
node
affinity,
you
can
do
that
all
right,
so
now
I'm
going
to
show
you
how
it
works,
so
that
was
kind
of
like
the
use
cases
and
the
higher-level
ways
that
you
can
use
virtual
couplet
as
a
customer.
But
what
do
you
actually
see
when
you
look
at
your
cluster?
A
A
My
command
lines
on
the
bottom
and
I'm
gonna,
coop
cuttle
get
knows
it's
the
first
thing
you
do
when
you
get
a
cluster,
so
I'm
gonna
do
that
and
once
this
comes
back
to
me,
the
Wi-Fi
is
unbelievably
slow
here
and
I've
been
trying
this
all
morning.
But
it's
the
easiest
demo.
You
can
do
so.
We're
gonna
wait
for
like
three
minutes.
While
we
wait.
Does
anyone
have
a
question?
A
C
B
A
B
Even
listening,
so
you
have
it
well,
you
have
an
on-prem
cluster
actually
or
you
may
have
a
cluster
in
aks
because
actually
Microsoft
have
a
solution
for
this.
If
your
cluster
is
in
aks
and
your
virtual
node
is
in
a
CI,
they
have
this
really
cool
networking
feature
where
they
can
talk
to
each
other
and
they
get
IP
addresses
in
in
in
in
an
appropriate
subnet,
so
that
they
can
all
see
each
other
and
talk
to
each
other
with
the
on-prem
solution.
B
A
A
Do
they
connect
to
each
other
you're,
actually
paying
a
j''r?
So
the
way
we
have
it
is
you
can
in
solver
to
a
couplet
on
to
an
on-prem
cluster?
The
virtual
note
that
we
have
in
Azure
you'll
have
to
do
it
manually
and
you'll
have
to
in
your
pod,
spec,
say:
hey
I'm
part
of
azure.
This
is
my
subscription.
This
is
my
service
principle.
These
are
all
the
details
and
that's
how
we
know
we're
a
lot
to
spin
out
to
Azure.
So
that's
what
you
have
to
do.
It's
the
same
technics,
a
mode.
A
A
Do
you
have
in
yeah
as
long
as
you
have
internet,
you
would
be
good?
Is
it
yeah
so
the
way
that
you
would
do
it?
You
would
need
to
have
public
eye
piece
in
it,
but
we
don't
have
a
solution
with
v
nets,
yet
we
need
to
get
veena
appearing,
for
example,
or
other
ways
to
connect
to
your
on-prem
v
net
so
that
technically
wouldn't
work
with
the
networking
but
talk
to
me
after
we
can
talk
about
like
what
we
need
to
do
to
enable
that
anything
else.
It's.
A
I
came
up
it's
great
okay,
so
that's
my
cluster,
that's
what
a
virtual
node
looks
like,
and
this
is
what
my
a
cask
cluster
looks
like
and
I
actually
just
went
to
the
portal
I
said:
create
a
virtual
node
enabled
it.
You
can
also
use
a
home
chart.
You
can
use
this
thing
called
a
CI
connector,
but
it's
really
whatever
you
want
to
do.
It
shows
up
like
that
and
now
I'm
going
to
go
ahead
and
create
a
pod.
A
A
It
can
change
it
reports
like
three
terabytes
today
yeah,
so
it's
like
three
terabytes,
it's
some
ridiculous
amount
of
like
we
just
have
a
huge
number
for
it.
We
are
thinking
of.
We
could
change
it
to
what
the
limits
are.
Nací,
so
you
say
itself
has
limits
for
per
customer
today.
It's
a
hundred
container
instances
do
they
come
up
already
exist,
oh
well,
we
can
just
go.
A
Okay,
so
he's
asking
about,
we
still
have
a
node
in
our
cluster.
What
is
the
benefit
since
we
saw
the
node
with
virtual
Kubla
in
this
scenario,
because
you're
still
paying
for
that
node?
That's
completely
true!
Your
benefit
is
really
you
being
able
to
burst
out
quickly
without
having
to
scale
up
nodes,
because
that
can
be
difficult.
The
other
thing
is,
we
are
working
towards
a
solution
where
you
wouldn't
have
nodes
in
your
cluster
at
all,
which
would
be
really
cool.
A
So
now
you
can
have
actually
a
cluster
with
just
virtual
couplets
or
virtual
nodes,
and
you
can
spin
out
TCI
or
have
nothing
running
if
you
don't
want
to
have
anything
running.
So
that's
something
that
we're
working
on
with
a
net
cast.
It's
back,
okay!
So
it's
running
so
this
is
actually
on
a
CI,
but
what
I'm
gonna
do
is
Oh
wide,
so
you
can
see
what's
happening,
it's
in
a
private
v
net.
We
have
all
of
that
working
if
you're
within
an
azure
networking.
Oh
it's
that
show
just
work.
A
D
A
Yeah
so
today,
I'm
and
I'm
sneaking
from
a
provider
perspective.
This
would
be
the
same
for
a
fare
gate
or
anything
else.
We
do
not
cache
images
in
virtual
couplet
or
anything
like
that.
So
it's
really
up
to
the
provider
to
allow
that
avail
like
the
ability
we
don't
have
any
NaCI.
We
do
cache
common
like
sub
images
or
base
images,
so
we
do
do
that.
But
that
is
a
common
question
that
we
get.
Can
we
catch
our
entire
image
and
we're
like?
How
would
we
do
that?
A
B
From
it
just
to
clarify
on
that
point
from
an
a
CI
standpoint,
my
understanding
I'm,
not
an
expert
in
this
and
maybe
Brian
or
someone
can
correct
me.
My
understanding
is
it's
backed
by
kubernetes
in
the
backend
right.
So
ultimately,
when
you
deploy
container
it's
going
to
end
up
on
own
node
somewhere,
that
node
will
have
a
cached
image
on
it,
but
there's
no
guarantee
any
anytime.
You
deploy
it's
going
to
end
up
on
the
same
node,
and
that's
that
that's
the
challenge
that
you
have
because
the
moment
there's
no
primitive
in
kubernetes.
B
It
says
make
this
can
make
this
image
available
everywhere,
because
I
don't
want
any
any
latency
I
mean
you
could
deploy
a
replica
set
or
a
daemon
set
at
your
demon
set
would
be
the
appropriate
way
to
make
sure
that
image
gets
cached
everywhere.
But
again
you
were
limited
with
this,
because
the
daemon
set
doesn't
work
with
this.
With
this
with
subtraction.
That's
a
good
observation.
C
B
Currently,
no
I
mean
I
think
that
the
nice
thing
about
the
virtual
node
is
that
you
could
create
an
asynchronous
relationship
between
you
know,
because
in
a
regular
node
couplet
and
the
things
that
controls
is
all
synchronous
with
virtual
Kubla,
because
you're
not
tied
to
that
paradigm,
you
could
you
know
you
could
make
it
so
that
you
were
queuing
things
up
inside
the
virtual
node.
When
you
made
the
connection,
you
could
get
status
back
and
you
could
launch
new
things.
I
mean.
Maybe
that
would
be
the
right
way
to
do
that.
That's.
A
B
B
It's
actually
the
API
server
interface
that
matters,
because
you
know,
as
you
saw
in
that
second
slide,
most
of
what
Kubler
does
it
does
through
polling
behavior
and
the
only
interface
quote-unquote
external
interface
that
it
has
is
the
synchronous
interface
for
exact
and
attach
and
and
logs
and
that's
relatively
stable.
So
it's
actually
more
a
question
of
you
know.
As
things
get
added
to
the
API
server,
you
know
how
stable
is
the
API
server,
API
and-
and
you
know,
kubernetes-
is
doing
a
great
job
of
keeping
that
stable.
C
D
D
D
A
I
will
not
work,
so
you
cannot
do
doctor
and
doctor
with
a
CI.
We
have
tried
the
ACR
team.
The
azure
container
registry
team
has
come
to
us
multiple
times
asking
and
multiple
times.
We
said
no,
it's
just
not
what
we're
gonna
add
is
functionality
and
a
CI.
But
if
you
were
to
build
your
own
provider,
you
could
do
it.
D
B
Mean
one
observation
I
make
about
that
is
you
know
the
virtual
container
hose
concept
I
talked
about
earlier,
a
very
popular
use
case,
for
that
was
to
connect
into
a
CI
CD
pipeline,
because
anything
that
you
do,
that
is
transactional
right.
The
runs
for
period
of
time
takes
input,
gives
you
output
and
you
may
have
bursty
periods,
and
you
may
have
completely
quiet
periods.
You
don't
want
to
be
reserving
resource
for
that
and
paying
for
resource
for
that
right.
Exactly
exactly
so,
I
think
I
think
there
are
good
solutions
to
this.