►
From YouTube: Webinar: Intro to Virtual Kubelet 1.0
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
Virtual Kubelet is a sandboxed project within the CNCF and we've been working hard to release VK 1.0. In this webinar we will go through the new updates in the latest Virtual Kubelet release and talk about the architecture of Virtual Kubelet in general. We will talk about our eco-system of providers and the values they offer customers and lastly we will go through our future outlook for the project.
A
Have
started
I
like
to
thank
everyone,
who's
joining
us
today.
Welcome
to
today's
cmcm
webinar,
it's
gonna
be
on
the
intro
to
virtual
cubelet,
one
dotto
I'm
Karen
I'm,
a
CNC
f,
ambassador
and
community
manager
at
Microsoft
and
I'll,
be
moderating.
Today's
webinar
we'd
like
to
welcome
our
presenter
today,
Riya
Bhatia
virtual
Hublot,
maintainer
and
program
manager
at
Microsoft,
just
a
few
housekeeping
items
to
go
over
before
we
get
started
during
the
webinar.
You
will
not
be
able
to
talk
as
an
attendee
there's
a
Q&A
box
at
the
bottom
of
your
screen.
A
B
Thanks
Karen
and
I'm
really
excited
to
be
here
and
talk
about
virtual
kulit,
one
dot
o
and
the
incharge
virtual
cubed,
so
I
hope
a
lot
of
you
don't
know
it
virtual
cool.
It
is
because
we're
gonna
start
from
the
beginning
and
level
up
all
the
way
towards
use
cases
that
a
lot
of
our
partners
are
working
on.
So,
let's
get
started
and
the
introduction
to
me
a
little
bit
more
in
depth.
Yeah
I'm,
a
program
manager
at
Azure,
compute
and
CRO
maintain
regret.
B
Roll
couplet
and
I
basically
work
on
kind
of
up-and-coming
projects
that
Austin
Azure
working
on,
but
then
also
us
as
a
community
are
starting
to
work
on.
So
it's
an
exciting
space
and
I
was
really
plugged
into
the
surrealist
kind
of
space
in
the
past
year
and
a
half.
So
it's
been
fun
all
right.
Let's
see,
okay,
so
I'm
excited
to
say
that
Virgil
kuben
is
part
of
the
CN
CF
as
sandbox
project.
This
probably
happened
eight
months
ago.
B
It
was
a
long
time
ago,
but
we
are
really
happy
to
have
the
support
of
the
CN
CF
and
excited
to
hopefully
level
up
to
incubating.
In
the
next
couple
of
months,
so
we're
gathering
case
studies
right
now
and
we're
starting
to
start
that
process.
Okay,
virgil,
cubed
itself.
So
what
is
it
we've,
basically
masked
what
an
actual
note
is
in
kubernetes
with
this
thing
called
virtual
coolant.
B
So
we've
Mesa
Kaleem
aid,
all
those
registrations
with
this
virtual
couplet.
So
you
can
connect
up
your
own
api's
to
kubernetes
api.
So
it's
just
an
interface.
Excuse
me,
my
allergies,
but
it's
just
an
interface
into
kubernetes.
So
if
you
start
to
think
about
these
cases,
what,
if
you
wanted
to
connect
this
virtual
cupola
into
I,
don't
know?
Maybe
your
card?
You
could
actually
do
that
as
long
as
you
understand
what
it
means
to
create
a
pod
delete
a
pod
and
possibly
update
a
pod
in
the
future.
B
You
could
technically
allow
kubernetes
to
create
a
pod
in
virtual
kulit
and
possibly
start
your
car.
So
that's
kind
of
a
level
of
abstraction
we're
talking
about.
We've
just
felt
this
interface
and
we've
open
sourced
it
for
anyone
and
everyone
to
go
and
build
their
own
providers
for
how
they
want
to
extend
kubernetes,
so
it
really
creates
kubernetes
is
a
common
control
plane
for
really
any
kind
of
workload.
B
So
the
only
thing
kind
of
by
finding
all
this
together
is
the
kubernetes
api.
Okay,
a
little
bit
more
in
depth.
Sorry,
this
is
super
wordy,
but
you
can
just
listen
to
me.
Read
the
slide
either
one
I
mean
so
virgil
Kubik
creates
the
concept
of
pods
and
notes
in
the
abstract.
So
if
they're
not
actually
housed
in
your
cluster
and
when
you
go
and
create
a
pod,
you'll
see
the
pods
in
your
cluster
you'll
see
those
extra
virtual
coolant
nodes
in
your
cluster,
but
they
might
actually
not
be
physically
in
your
cluster.
B
They
could
be
if
someone
decided
to
create,
create
that
that's
actually
just
the
couplet
but
in
reality,
they're
running
somewhere
else,
whether
it's
in
a
car
at
a
different
data
center
in
a
different
cloud,
possibly
on
a
satellite
in
the
outer
space.
So
it
could
really
be
anywhere
I
mean
today
when
we
think
about
notes.
It
is
a
bounded
resource,
so
you
have
to
have
some
sort
of
memory,
capacity
to
it
or
compute
capacity,
something
about.
B
Of
course,
virtual
couplet
actually
allows
you
to
have
an
infinite
pool
of
capacity,
because
we
don't
found
you
so
our
project
itself.
We
allow
you,
as
a
provider,
someone
that
wants
to
connect
your
own
api's
to
kubernetes
just
to
choose
that
boundary.
So
if
you
are
a
cloud
provider
for
example,
you
could
choose
the
boundary
of
what
your
data
center
is.
B
So
that's
just
something
to
think
about.
Instead
of
the
pod
sharing
a
bunch
of
pods
sharing
resources
on
a
node,
so
you
have
the
specifics
of
how
all
of
these
capacity
things
and
networking
things
and
it's
like
configure,
apps
and
secrets
they're
all
described
by
the
actual
provider
itself,
the
common
code
in
VK.
Our
interface
is
actually
really
small
and
simple
as
a
p.m.
B
I'm
able
to
go
in
and
understand
what
our
interface
is
and
what
exactly
we're
doing
all
the
time,
because
of
course
like
I'm,
not
in
code
every
day,
but
it's
also
easy
for
our
providers
to
go
in
and
plugg
understand
what
they
need
to
do
to
plug
into
our
interface.
So,
really,
if
you
can
just
create
a
pod,
delete
a
pod,
you
have
mechanisms
for
config,
config,
Maps,
possibly
or
secrets
you
can
be
a
provider
with
ritual
code,
but
in
BK
itself
can
actually
be
the
point
as
a
pod,
so
I
mean.
B
B
This
is
a
repo.
This
was
a
screenshot
taken
a
long
time
ago.
We
have
about
a
thousand
more
stars
now
fun
popularity
contest,
but
we've
done
a
lot
of
work
in
this
repo,
so
we
actually
have
a
community
repo.
Now,
on
that,
we
just
spent
out
for
the
wind
auto
release.
We
have
milestones
if
you
go
into
issues
and
click
on
milestones.
We
are
working
towards
a
couple
milestones,
we're
finishing
a
couple
issues
that
we
had
for
the
window
release.
We
want
to
make
sure
it's
perfect,
but
basically
like
this
is
your
home.
B
If
you
want
to
create
a
provider,
you
would
click
in
providers
and
then,
when
you
click
into
that
and
I
can
show
you
the
repo
at
the
end,
you'll
see
a
list
of
all
the
providers
that
are
currently
supported,
supporting
virtual
cubelet
and
you
can
also
get
into
the
readme
and
figure
out
how
to
deploy
these
providers.
So
that's
really
useful.
B
A
lot
of
them
are
just
home,
charts
that
you
go
into
play,
but
you
do
have
to
usually
have
some
like
customer
configuration
to
be
to
be
able
to
be
allowed
to
spin
out
to
maybe
a
different
cloud
or
something
like
that.
So
that's
something
to
keep
in
mind,
but
providers
is
that
folder
that
you
want
to
go
and
look
into
okay,
so
our
provider
definition
I'm
kind
of
the
same
things
that
I've
been
saying.
B
You
need
to
able
to
provide
the
backend
plumbing
necessary
to
provide
the
life
cycle
of
a
pot
through
kubernetes
and
supporting
what
it
means
to
be
a
resource
in
kubernetes.
So
kubernetes
needs
to
look
at
virtually,
wouldn't
understand
that
they
can
spin
out
workloads
to
virtual
kool-aid,
and
we
do
that
in
a
couple
different
ways.
One
is
that
we
use
taste
and
toleration
x',
so
we
basically
have
painted
the
node
and
it's
basically
a
lock
on
the
node.
B
So
every
workload
has
to
have
a
toleration
to
be
able
to
tolerate
that
node
and
be
able
to
be
spun
out
to
that
node.
We
and
azure
have
explicitly
done
it.
Providers
can
do
it
differently,
whether
they
decide
to
taint
the
nodes
or
not.
Just
because
it's
a
different
billing
model,
we
don't
want
people
to
accidentally
get
spun
out
into
virtual
kulit,
because
there
are
some
limitations.
For
example,
a
limitation
would
be.
You
can't
do
daemon
sets,
you
don't
have
access
to
the
actual
node
host
itself.
B
So
a
lot
of
some
of
the
container
container
monitoring
solutions
won't
work
because
they
actually
go
into
the
host
itself
into
heaps
err
and
they
gather
the
node
metrics,
where
in
virtual
culet,
you
can't
exactly
do
that.
There
are
some
workarounds
that
we've
worked
on
to
work
around
it,
but
that's
kind
of
the
context.
It
is
a
little
bit
different
from
a
node,
because
we
aren't
exactly
a
node.
You
need
to
conform
to
the
current,
a
PRI
specified
by
virtual
cubelet,
and
then
you
can't
have
direct
access
to
the
kubernetes
api.
B
B
We've
all
created
a
way
to
spin
up
containers
on
the
fly,
whether
you
have
to
provision
a
cluster
first
to
get
those
containers
and
get
that
interface,
and
they
say
you
don't
have
to
you
just
get
containers
so
we're
thinking
about
how
do
you
get
all
of
the
functionality
that
you
had
a
kubernetes
but
abstract
away?
The
notes,
because
we
didn't
want
to
build
in
another
dispute
system,
we
didn't
want
to
build
it,
how
to
auto
scale
or
how
to
do
load,
balancing
or
sort
of
discovery,
or
anything
like
that.
B
Kubernetes
already
does
that
for
you,
so
to
just
abstract
away
more
infrastructure.
We
just
decided
to
connect
the
two
in
the
way
we
did.
It
was
by
kind
of
hacking,
the
couplet
itself,
and
it
turned
out
to
be
pretty
easy
to
write
and
from
there
we
kind
of
realized
that
this
might
be
something
that
other
people
wanted
to
do.
B
So
we
made
it
pluggable
and
open,
and
that's
when
we
just
stripped
out
everything
that
was
a
sure
we
made
an
interface
we
partnered
with
hyper
SH,
we
partnered
with
Amazon
and
VMware
and
a
bunch
of
other
companies
who
were
also
thinking
around
the
same
things
like
what
is
new
marilla
super
Nettie's,
and
what
does
it
mean
to
have
a
pods
as
a
service
or
a
containers
as
a
service?
So
us
together
brought
it
prior
to
the
market.
B
We
released
first,
oh
cool
it
at
coop,
con
2018,
I,
think
in
Austin,
and
it
was
awesome
to
see
the
community
engagement
and
to
see
everyone
really
excited.
And
from
there
we
decided
to
start
community
meetings
every
week
or
every
other
week
we
have
a
sock
channel
in
virtual
couplet
and
our
jobs
as
core
maintainer
Zoar,
really
to
make
sure
the
process
is
as
easy
as
possible
on
board
any
providers.
So
we
don't
care
who
you
are.
B
We
will
help
you
onboard
and
not
only
that
we'll
also
help
the
users
of
your
guys's
providers
make
sure
they
have
solutions,
because
we
get
a
lot
of
issues
from
providers
there's
something's
broken
and
so
where
I
was
trying
to
keep
track
of,
like
the
health
of
the
project
overall
and
all
of
our
providers
I'm
here
a
couple
tweets,
so
something
you
might
know
Jesse.
She
also
was
one
of
our
first
contributors.
She
actually
helped
build
the
interface
with
Eric
say
we're
in
which
is
pretty
awesome.
B
Brendan,
of
course,
has
always
been
there
for
for
this
project,
and
then
Amazon
was
pretty
excited
about
virtual
couplet.
They
used,
they
connected
far
gate
to
VK
and
then
a
couple
of
our
customers,
so
web
chat,
for
example,
was
really
excited
to
see
a
CI
happen
and
a
CI
plus
virtual
people
would
happen,
and
a
lot
of
people
were
just
kind
of
looking
at
the
space
and
thinking
about
what
they
could
do
and
it's
I
was
really
exciting
to
talk
to
people
about
their
different
use.
B
Cases
because,
like
we've,
heard
everything
from
like
I
want
to
create
a
provider
to
spin
out
to
Domino's,
for
example,
or
I
want
to
create
a
provider
to
spin
out
to
a
satellite
like
close
to
the
moon.
So
even
if
you
aren't
a
cloud
provider
per
se,
you
can
use
virtual
Kubla
to
kind
of
have
this
common
and
easy
control
plane
that
that
is
kubernetes
that
we
all
know,
and
it's
kind
of
easier
for
operators
to
understand
how
to
spit
out
two
different
kind
of
workload.
Types
now
all
right.
B
So
this
is
what
the
couplet
does
today
here
are.
The
asynchronous
is
you're
gonna
kind
of
control,
loops
that
we
have
and
the
things
that
we're
pulling
for
inside
the
coop
inside
the
Kulin
itself.
So
we're
always
getting
notes,
ATS
and
pod
size,
the
container
logs
and
things
like
that,
and
then
you
also
have
to
create,
update
and
delete
your
pods
volumes
and
secrets.
So
this
is
kind
of
what
our
MVP
strove
to
be.
B
We
wanted
to
be
able
to
create
pods
and
secrets
and
do
dns
routing
I
think
the
only
thing
we
have
it
specifically
nailed,
and
this
is
actually
volume
changes,
but
everything
else
we
have,
which
is
pretty
exciting,
so
we
have
exec-
or
at
least
we
have
it
in
a
PR.
We
have
container
logs,
we
pull
for
for
these
logs
and
stats
and
things.
So
that's
pretty
exciting
that
we're
almost
at
like
what
we
said
we
would
do
about
a
year
ago
and
some
things
just
don't
make
sense.
B
So,
for
example,
volumes
it's
very
provider
specific,
so
we
haven't
really
gotten
a
provider,
that's
ready
to
mount
volumes
close
to
their
containers.
That
way,
we
do
volumes
and
in
our
own
clods
like
a
jar
files
and
things
like
that,
but
we
don't
have
like
this
support
or
PVC
support,
for
example,
because
that
just
doesn't
make
sense
yet,
okay,
so
challenges
in
creating
provider.
B
Private
networking
is
hard
because
you
now
have
to
replicate
what
it
means
to
be
to
proxy
per
container,
so
I
know
Alibaba
and
us
have
done
it
I
think,
for
you
might
have
done
it
too.
So
we
basically
now
deploy
a
sidecar
per
container
and
since
broken
hair,
spinning
up
through
virtual
kulit
to
be
able
to
get
service
discovery
basically
and
be
able
to
create
services.
That's
how
we
tacked
it
so,
instead
of
one
coop
Roxie
per
node
per
couplet,
we're
doing
it
per
pod.
So
what
should
a
max
node
resourced,
be?
B
This
is
something
that
we've
thought
of
so
many
times
and
how
do
we
expose
it?
Is
it
important
to
a
customer?
Some
customers
want
to
spin
out
to
100k
containers
right,
but
each
container
itself
has
its
own
resource
and
then
the
node
resource
like
does
it?
Should
it
match
the
amount
of
containers
that
you
need
or
should
it
match,
then,
when
I
compute,
the
hiding
datacenter
or
should
watch
like
they
might
I
compute
that
that
customer
has
is
allowed
to
spit
out
two
for
that
subscription?
B
So
that's
a
lot
and
that's
why
this
is
a
complicated
question
and
we've
continued
to
make
it
open-ended
for
our
providers
on
what
version
is
VK,
so
we
also
have
to
so.
Whenever
you
create
a
node
in
kubernetes,
you
get
a
virgin
tag
with
it.
So
when
you
get
nodes,
you'll
see
the
curates
version
of
your
nodes.
B
Plus
we
add
our
own
VK
tag,
sometimes
so
usually
like
the
most
important
thing
is
we
add
our
own
VK
x,
so
you
can
see
the
actual
virtualui
bridging
running
and
that's
the
most
important
thing,
and
then
how
do
we
enable
custom
respond
into
their
pods
because
the
only
way
we've
really
hacked
through
this
is
we
have
to
aggregate
the
container
metrics
from
every
container
itself.
We
can
aggravate
it
through
a
node.
So
that's
something
to
keep
in
mind.
B
So
that
we've
gone
through
challenges,
these
are
all
the
things
that
you
can
spit
out
to,
so
you
can
spit
out
to
hoshi
corapi,
and
so
that's
a
like
nomads,
they're,
no
bad
provider,
faregates
at
dominoes
to
DCOs
to
IOT
edge
and
Roger
Roger
container
instances.
Dodger
people
have
made
providers
for
almost
everything.
I
know
vSphere
and
like
Vick
also
has
a
provider
and
things
like
that
so
and
sometimes
yeah,
you
just
need
to
run
a
container.
So
that
was
the
premise
of
what
a
lot
of
us.
B
Why
a
lot
of
us
decided
to
create
Perez
for
chocolate?
We
just
wanted
to
create
containers
in
kubernetes
and
not
have
to
manage
infrastructure
no
to
infrastructure
anywhere.
We
didn't
want
to
have
a
node
go
down
and
then
all
of
the
workloads
on
that
node
go
down.
At
the
same
time,
we
just
wanted
to
deal
with
the
container
runtime.
B
So
here's
a
diagram
of
what
we
did
in
a
very
similar
to
some
of
the
other
use
cases
you're
about
to
see
so
vm's.
This
is
your
cluster.
Vm
is
a
control
plane.
You
have
something
called
a
virtual
node
that
will
spin
out
unlimited
compute
to
Azure,
and
if
you
use
this
you'll
realize
that
it
adds
her.
We've
actually
have
limits
for
you
for
your
subscription
for
each
data
center.
B
So
that
makes
it
difficult
because
when
you
look
at
virtual
kulit
you're,
like
oh
I,
have
I,
don't
know
three
terabytes
of
memory
that
I
can
use,
but
when
you
go
and
actually
use
it,
we're
like
300
cores
or
something
ridiculous.
When
you
go
ahead,
actually
use
it.
You're
gonna
get
on
and
if
you
try
and
spin
out
that
much
you're
gonna
get
hit
by
limits
and
Azure
and
you're
gonna
have
to
go
through
your
computer
logs
to
realize
why
that's
happening.
So
that's
one
example
of
why
this
is
kind
of
still
difficult
for
people.
B
B
So
if
you
have
a
bunch
of
nodes
and
you
need
to
I'll
just
go
quickly
so
if
you're,
a
gaming
company-
and
you
have
all-
your
games-
are
online
and
you're
trying
to
now
spit-up
compute,
because
you've
just
got
a
seven
person
load,
and
maybe
you
weren't
expecting
it
that's
when
you
can
use
like
the
HPA
and
kubernetes
and
jason
toleration,
x'
and
node
affinities
to
basically
be
able
to
on-demand
spin
at
a
so.
You
don't
have
to
think
about
auto
scaling.
B
Your
notes,
you
just
spin
out
into
this
unlimited
compute
unlimited,
but
then,
after
the
fact,
when
you're
working,
so
just
when
it's
kind
of
done
when
there's
no
more
requests
coming
in,
for
example,
you
can
burst
on
custom
requests
like
requests
per.
Second,
all
these
instances
will
spin
down
and
you
won't
have
nodes
running
when
you
don't
need
them
to
be
ready,
so
the
cost
model
is
kind
of
nice
because
you
just
pay
for
what
you
use.
B
B
So
when
you
spin
out
like
containers
in
BK
you'll
go
into
the
Nomad
portal
and
you'll
see
all
these
nomads
tasks
actually
come
through,
which
is
pretty
cool
and
there's
a
really
awesome
demo
that
Mishra
did
so
I
would
encourage
you
guys
to
check
out
that
talk
and
then
all
Ãbamos
cloud
use
cases
for
BK
are
also
really
cool.
They're
doing
the
same
thing
that
we
did
with
ACI.
So
they
have
this
thing
called
elastic
container
instances
in
their
cloud
and
they're.
Basically,
their
pods
are
can
have
side
containers.
B
So
as
a
cloud
provider
they're
using
the
Kay
to
scale
their
own
distributed
systems
and
to
also
have
teams
have
their
own
clusters,
so
they
don't
give
each
team
a
cluster
and
they're
in
their
cloud.
They
have
to
be
really
efficient
for
the
workloads
that
they
run.
I
mean
if
you
look
at
their
stats,
it's
insane.
B
They
blow
Amazon
out
of
the
water
for
like
their
most
busy
days
of
when
they're
selling
like
their
stuff
online
on
their
on
their
market,
but
basically
they
give
one
virtual
couplet
per
per
team
and
from
there
that
team
has
full
rein
over
what
they
deploy
and
what
they
don't.
But
they,
when
they
only
get
charged
for
stuff
that
they're
running,
for
example.
So
everyone
is
basically
distributed
across
an
entire
cluster,
and
that
means
they're
really
efficient
internally
because
they're
all
in
one
cluster.
B
Other
places
like
we
see
a
lot
of
people
just
doing
one
cluster
per
per
team,
basically,
when
you're,
developing,
which
kind
of
sucks,
when
you
think
about
the
cost
efficiency
of
that,
because
if
you
don't
have
workloads
running
all
the
time,
you're
wasting
those
resources
when
another
team
could
be
using
those
resources.
This
compute
resources.
B
So,
in
this
case,
this
is
actually
probably
one
of
the
most
efficient
designs
that
I've
seen
so
far,
all
right
for
a
little
video
of
an
example
of
how
you
could
use
virtual
couplet
if
you're,
a
customer,
I'm
gonna
not
use
this
voice
and
just
voice
over
it.
So
this
is
an
example
of
a
web,
app
I'm
running
it
on
a
kubernetes
cluster.
B
So
the
way
that
it's
doing
it
is
by
collecting
custom
metrics
in
their
cluster
using
Prometheus
we're
basically
collecting
requests
per
second
and
we've
spun
out
a
bunch
of
load
to
this,
just
like
test
load
to
see
how
we're
scaling
up
so
over.
Here
is
requests
per
second
for
the
entire
cluster
itself,
so
this
entire
cluster
is
getting.
It
started
at
zero
and
then
it's
kind
of
ping
pong
you
back
and
forth
to
almost
like
about
500
requests
per
second
and
then,
if
you
look
over
here,
we're
calculating
the
requests
per
second
per
pod.
B
So
once
we
get
to
100
we're
actually
spinning
out
another
pod.
So
this
is
what
the
horizontal
pilots
go
and
kubernetes
is
doing
for
us.
It's
scaling
out
these
pods
our
response
time.
It
went
up,
so
you
don't
want
your
response
had
to
go
up
and
that's
the
latency
it
takes
for
customers
to
checkout.
So
response
time
went
up,
but
as
soon
as
we
started,
auto
scaling
it
actually
pivoted
down
and
the
interesting
part
is.
B
We
only
have
two
pods
running
in
our
cluster
that
are
working
pods
that
are
working
through
all
this
load
and
we
spun
out
19.
It
actually
gets
up
to
about
34
and
it
record
all
of
it,
but
we
spun
out
a
bunch
of
pods
to
go
so
they
all
can
go
and
help
with
the
act
of
just
taking
down
a
load
and
when
they're
done
they're
gonna
spin
back
down.
So
once
these
requests
per
second
per
pod
get
below
a
certain
number
they're
gonna,
slowly
spin
back
down,
which
is
kind
of
nice.
B
So
that's
that
guy!
So
one
of
my
last
slides
just
joined
us.
We
have
a
virtual
couplet
website
thankful
thanks
to
sans
EF
this,
our
github
leo
sock,
channel
and
kubernetes
so
reach
out
to
us.
If
you
want
to
be
a
part
of
the
community
and
thank
you
and
I
think
now
we
can
take
a
bunch
of
questions
we
yeah.
We
have
plenty
of
time
for
that.
So
good.
A
B
B
Pk
itself
like,
if
you
ask
you
about
like
if
it's
in
a
cluster
I,
would
assume
it's
that
if
you're
actually
like
creating
VK,
it
resides
usually
on
a
node.
So
usually
what
we
do
is
there's
one
node
writing
in
the
cluster
and
there's
the
virtual
couplet
pod
is
running
the
cluster,
but
it's
also
kind
of
faking
out
our
node
interface
thinking
out
like
kubernetes
itself,
and
it's
giving
you
like
this
fake
node.
B
When
you
do
cuoco
get
nodes,
you'll
see
the
virtual
cool
it
node,
but
when
you
do
coup
could
all
get
pods
and
all
namespaces.
For
example,
you'll
see
a
virtual
Kubla
pod,
so
it
actually
just
is
running
as
a
pod
in
your
cluster,
like
any
other
workload,
the
code
itself
is
a
process
within
the
container,
so
we're
running
a
process.
It's
all
in
go
in
a
container
itself,
and
if
you
want
to
check
out
the
code
for
every
provider,
it's
all
in
the
virtual
Googler
repo
and
the
ways
to
spit
out
these
pods
individually.
B
B
B
B
Virtual
kulit
as
the
project:
yes
because
we
have
something
called
an
OS
type
which
you
can
toggle.
So
if
you
want
to
put
Windows
or
Linux
doesn't
matter
the
thing
the
real
question
is:
does
it
have
support
for
the
providers
and
that's
a
different?
You
can
asked
every
provider
you
can
Solly
Baba
that
you
can
now
say.
I
was
on
that
you
can
sauce
that
I.
Don't
a
sure
we
have
it.
We
have
support
for
what
is
Linux,
but
from
a
provider
perspective.
It's
actually
really
easy
to
just
toggle.
B
That
on
and
off
the
hard
part
is
understanding
how
you
distribute
that
in
the
backend.
So
as
a
pod
provider,
you
need
to
understand
those
calls
coming
in
and
be
able
to
spit
out
a
Windows
container
in
your
clusters
in
for
the
customer.
Basically,
so
yes,
technically
yes,
bridge
will
cool,
but
itself
does
cool.
A
B
B
For
this
thing,
so
when
you're
in
the
right
region,
you'll
see
something
called
virtual
nodes
and
probably
the
node
pool
section,
you
just
click
that
like
checkmark
it
and
then
go
to
the
networking
page
and
you'll,
see
that
we're
delegating
a
subnet
for
you
specifically
for
a
CI
and
then
a
subnet
for
your
kubernetes
cluster.
So
we
have
two
different
subnets
and
every
container
it
says
that
comes
up
gets
its
own
private
IP.
B
So
it
is
private
networking
you
can
do
service
discovery,
you
can
do
load
balancing,
they
will
look
and
feel
like
a
curious
cluster
and
all
in
it
all
out.
Hopefully
so
yeah
just
go
and
toggle
the
virtual
nodes,
saying
you
oughta,
try
like
ease
us
or
blast
us
or
something
or
south-central.
Those
will
have
it.
North
Northern
Europe
might
have
a
Western
Europe
yeah
should
be
online.
The
region's
cool.
B
Yet
no
so
we're
still
specifically
talking
about
actually
so
I'll
continue
on
that
we
do
not
have
support
for
zero
nodes.
Yet
there
are
a
couple
other
things
that
are
higher
priority
for
Roger
and
and
we're
still
reading
ritual
cupola.
On
that
notes,
you
still
need
one
at
least
one
under
your
cluster,
a
tubular
to
read
her
chocolates
and
not
yet,
but
the
best
thing
you
can
do
is
just
do
a
one
node
cluster
that
would
be
as
expensive
as
doing
a
three
node
cluster,
for
example,.
A
B
I
could
see
a
road
that,
specifically
for
the
library
I,
would
definitely
go
in
a
thunderstruck
channel.
I
can
give
you
my
best
guess
we're
basically
trying
to
make
VK
as
efficient
as
possible
and
as
easy
as
possible
to
read
and
develop
it
and
I
know
for
a
long
long
time.
We
wanted
to
make
we've
been
wanting
to
make
a
library.
So
if
you
wanted
very
specific
reasons,
I
would
definitely
reach
out
to
like
Brian
Goff.
Is
this
like
channel
another
core
mutator
for
for
why
exactly?
B
But
the
road
map
for
VK
so
we're
actually
working
with
a
couple
new
maintainable
people
in
the
community
that
are
working
BK?
Actually
one
of
them's
Netflix.
They
found
a
lot
of
cool,
different,
bugs
and
kind
of
efficiency,
things
that
they
want
to
start
doing
so,
I
mean
our
goal
is
to
be
able
to
spit
out
to
like,
for
example,
hundred
pay
containers
in
a
couple
of
minutes,
for
example,
so
that's
kind
of
the
level
of
efficiency
and
quickness
we're
trying
to
get
to
so
whatever
throttling
things
that
we
have
in
BK.
B
Whatever
limits
us
we're,
gonna
be
working
through
that
I
know.
A
lot
of
one
of
the
things
is
that
we
are
currently
registering
everything
as
a
queue
and
we're
deleting
things
as
a
queue.
So
we
can't
do
really
anything
concurrently.
Yet
we
can
spin
out,
like
ten
containers
at
a
time,
for
example,
but
we're
not.
We
can
only
really
do
one
thing
at
a
time,
so
we're
trying
to
make
that
more
dynamic
and
trying
to
make
that
more
efficient.
So
virtually
we
can
do
multiple
things.
Another
thing
is
Virgil.
Couplet
apparently
will
also
freak
out.
B
If
you
have
a
virtual
couplet,
if
you
have
a
name,
if
you
used
to
have
the
same
name
of
a
container
in
your
cluster
and
then
now
virtual
couplet
is
seeing
that
same
name
again,
there's
some
weird
behavior
that
happened
so
we're
kind
of
finding
all
the
weird
edge
cases
we're
trying
to
make
it
more
efficient.
It's
nothing
like
big
feature
sets
because
we're
barely
compliant
to
what
we
think
users
need
it's
more
like
now
we're
trying
to
tackle
the
problem
of
scale
and
that's
really
what
we're
working
towards.
B
B
A
provider
is
someone
that
wants
to
use
virtual
couplet
and
wants
to
use
her
interface
and
has
their
own.
They
want
their
own
customers
to
be
able
to
spit
out
from
kubernetes
to
their
service.
So
if
I
was
I
would
have
have
a
different
example,
so
yeah
I
mean
as
a
cloud
provider.
A
lot
of
us
are
trying
to
figure
out
how
conveniences
spit
out
from
kubernetes,
but
another
example
is
RIT
edge.
B
So
if
I
want
to
have
people
use
kubernetes
as
the
carbon
control
plane,
because
the
way
that
people
use
IT
edge
right
now
is
kind
of
fragmented
and
they
could
kind
of
maybe
spit
out
things
in
multiple
different
ways.
But
everyone
already
knows
kubernetes.
So
why
don't
I
just
allow
my
IAT
edge
devices
to
look
like
nodes
in
kubernetes?
So
whenever
you
deploy
a
pod
or
workload
to
it,
it'll
update
the
actual
IOT
edge
configuration
for
example.
So
someone
did
a
little
workshop
and
a
little
demo
on
this.
B
They
connected
virtual
keys,
went
to
and
I
should've
I
click
the
light
bulb
and
then
any
time
they
updated
their
pod
configuration.
It
would
change
a
different
color,
so
they
kind
of
rare
that
all
through
kubernetes
and
another
wouldn't
have
to
understand
how
to
connect
up
their
device.
The
kubernetes
had
already
be
done
as
a
provider.
They
could
just
use
the
providers
code,
but
then
they
can
now
use
kubernetes
to
update
the
providers,
their
iot
edge
devices,
for
example,
so
a
provider
yeah,
and
they
also
said
they
want
providers
in
virtual
people.
B
Specifically,
they
want
to
be
housed
by
us
because
we
kind
of
give
them
the
support
and
the
life
cycles
and
that
you
will
automatically
give
them
all
the
changes,
the
interface
and
things
like
that,
if
I
so
choose
like
within
our
project.
So
it's
really
good
for
people
that
have
a
service
and
they
want
their
own
customers
to
be
able
to
use
a
service
through
kubernetes.
That's
the
premise
of
it.
B
Pelagic
and
what
yeah
so
you're,
basically
talking,
you
want,
like
the
containers
to
be
able
to
talk
to
each
other
I'm
guessing.
Is
that
the
premise
like
you
want
to
have
a
back-end
container
and
then
a
front-end,
and
you
want
them
to
be
able
to
communicate
and
scale
up
and
scale
down
depending
on
load
on
the?
The
answer
is:
yes,
all
you
need
for
that.
It's
like
the
service
discovery
and
maybe
possibly
like
private
networking.
B
If
you
wanted
to
be
private
from
your
cloud
provider
that
they
would
deliver
that
for
you,
but
essentially
yes,
we've
given
the
virtual
people,
an
interface
all
of
all
the
things
that
needs
to
be
able
to
run
real
apps.
So
the
example
that
I
showed
in
the
video
I
had
worker
nodes
and
I
also
had
my
logics,
like
my
back-end
logic
in
the
cluster,
but
then
I
had
my
worker
networker
pods
in
a
CI.
B
There
are
some
things
that
you
might
not
be
able
to
do
in
a
CI,
but
like
you
can
also
talk
from
the
pods
in
your
cluster
to
your
pods
in
a
CI.
So
if
there
is
a
limitation
like
daemon
sets
or
needing
like
your
hosts
need
to
get
back
into
your
hosts,
you
can
run
some
of
the
containers
on
the
nodes
themselves
and
then
run
like
your
worker,
pods
and
scale
up
put
what
you
need
to
scale
on
a
CL.
That's
usually
how
we've,
how
we've
kind
of
done
that
if
we
found
a
limitation.
A
B
Technically,
yes,
Sara,
we
would
not
block
you
from
that.
That's
really
interesting
that
it's
not
something
I've
ever
ever
thought
of
so
yeah
I
mean
all
you
need
to
do
is
reconfigure
your
own.
You
would
have
to
create
your
own
provider
for
that.
You
could
honestly
probably
copy
Amazon's
code
and
whatever
else
you
want
from
for
storage
into
there
and
create
your
own
mechanisms
back
in
well,
the
thing
is
about.
Storage
is
like
a
lot
of
the
clouds
like
I.
B
Don't
know
if
you
use
add
your
files
like,
for
example,
with
a
with
a
compute
resource
somewhere
else.
That
would
be
the
question:
like:
is
the
storage
in
your
cloud
compatible
with
the
compute
in
another
cloud
as
long
as
they
are,
or
in
theory
should
be?
Yes,
but
that's
something
really
interesting.
I
would
try
that
out
and
let
us
know
what
happens
I
don't
know
exactly
because
yeah
it
actually
should
just
work
cuz
if
it's
not
coupled
with
the
compute,
it's
just
for
anyway,
so
yeah,
yes,
Oh.
A
B
We've
also
made
that
more
efficient
one
dot
out,
but
we're
trying
to
get
closer
to
a
model
where,
like
in
VK,
you
basically
don't
have
to
like,
find
those
differences.
You
can
just
understand
that
you
are
yourself
the
kind
of
the
knowledge
of
the
information
you
are
like.
You
are
holding
the
same
kinds
of
positive
as
the
couplet
would
how
we
do
that
is
kind
of
a
question,
but
if
it
does
go
offline
it
should
all
your
workload
should
stay
there.
There
might
be
some
edge
cases
where
things
get
lost.
We've
had
this.
B
This
was
a
long
time
ago
with,
but
we
would
have
these
ghost
resources
kind
of
spin
up,
so
you
delete
a
pod,
but
it
would
look
like
it
was
there.
So
if
that
happens,
to
just
like
put
up
an
issue
that
should
be
long
gone,
but
a
lot
of
these
things
also
can
be
up
to
this,
like
the
provider
is
some
things
might
be
wrong
or
the
writer
using
itself
an
offer
to
cool
it.
So
it's
definitely
like
an
interesting
partnership
that
we
have
to
have
between.
B
A
B
So
the
demo
that
I
had
was
running
multiple
single
containers.
In
my,
if
you
look
at
the
pot
itself,
it
actually
every
single
pod
that
was
sort
of
an
AC
I
had
a
KU
proxy
sidecar
already
and
a
monitoring
sidecar.
So
we
were
spinning
those
out
as
our
like.
We
do
that
as
a
service
already
for
you,
because
so
you
don't
have
to
see
it,
you
don't
see.
What's
in
your
actual,
you
don't
see.