►
From YouTube: Use the Cluster API to Deploy Clusters On-Prem and in Public Clouds - Loc Nguyen & Kris Nova
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
Use the Cluster API to Deploy Clusters On-Prem and in Public Clouds - Loc Nguyen, VMware & Kris Nova, Heptio
Deploying and managing kubernetes clusters has a reputation filled with stress and headaches. On top of this, there are dozens of tools, APIs and services available to use but they don’t all interoperate. Some tools work best with on prem while others works best with a specific public cloud. The Cluster API is a new project bringing in members from many of these well-known tools and members from both public clouds and on-prem infrastructure software providers. The goal is to create a common declarative, kubernetes-style API, tools, and best practices that can be used to create day-zero solutions for deploying kubernetes to multiple platforms. Come learn about the goals of this project and see a demo of it in use in both on-prem and in a public cloud.
To Learn More: https://sched.co/GrWT
A
A
A
So
yeah
we're
gonna
get
started
as
folks
kind
of
finish
coming
in.
We
got
it
quite
a
bit
of
time
at
the
end
of
our
presentation
for
QA.
A
lot
of
folks
have
had
questions
about
what
we're
gonna
be
talking
about
tonight.
So,
if
you
have
questions,
don't
be
shy
and
feel
free
to
to
come
up
here
if
you're
interested
in
seeing
more
and
learning
more
so
yeah
hi,
I'm,
I'm,
Chris
Nova
I
work
for
VMware
now,
which
is
exciting.
B
A
C
A
C
A
Who
here
has
not
used
it
but
wants
to
start
using
it
or
as
excited
about
it?
Nice,
okay?
So
so,
just
to
tell
folks
who
are
in
the
front
row,
most
people
put
their
hand
up
for
the
second
one.
Most
people
are
interested
in
learning
more
so
we're
gonna
start
off
today
and
we're
going
to
learn
a
little
bit
about
the
cluster
API
today
and
we'll
talk
a
little
bit
more
about
the
history
of
how
we
got
here,
but
this
is
sort
of
what
is
the
state
of
the
cluster
API
project
today,
yeah.
B
So
this
is
not
going
to
be
a
deep
dive.
There's
gonna
be
another
session
later
on
this
week
and
anyway,
let's
go
ahead
and
get
started
so
the
cluster
API
today.
So
what
is
cluster
API?
The
cluster
API
is
a
framework
that
is
designed
to
handle
day
one
and
day
two
operation
day.
One
operation,
meaning
deployment
and
installation
and
day
two
is
managing
upgrade
scaling
and
the
cluster
API
was
designed
to
be
a
standard
for
to
make
the
ecosystem
less
fragmented
and
I
just
want
to
point
out
that
we're
still
experimenting.
B
A
Awesome
so
the
cluster
API,
it's
a
project
that
came
together
that
attempts
to
solve
what
it,
what
it
looks
like
and
what
it
feels
like
to
bring
up
a
kubernetes
cluster.
A
lot
of
folks
kept
tio,
not
part
of
VMware
digitalocean
AWS
Google
Cloud.
We've
had
folks
from
azure
contributors
from
other
open
source
projects
like
terraform.
A
lot
of
folks
who
are
notable
in
the
community
have
come
together
and
said.
We
are
tired
of
this
fragmented
experience
for
bringing
up
a
kubernetes
cluster.
We
all
represent
clusters
in
a
different
way.
B
A
To
make
a
kubernetes
pun,
here's
the
declared
state
of
the
cluster
API
I
wrote
a
blog
on
this,
which,
if
you
took
a
picture
of
the
appendix
like
I
told
you
to
you,
can
find
a
link
to
the
blog
page,
but
this
project
have
started
in
2017.
The
original
origins
of
the
project
sort
of
came
up
all
around
the
world.
At
the
same
time,
we
talked
about
this
in
cops
when
I
was
first
working
in
kubernetes
cops.
We
talked
about
this
in
Cuba
corn,
a
project
I
made
to
bring
up
kubernetes
clusters.
A
The
folks
in
the
cube
admin
department
have
been
talking
about
this.
We
even
had
folks
from
companies
overseas
like
load,
C
and
then
ultimately,
I
sat
down
with
some
of
my
friends
at
Google
and
we
sat
down
and
said:
ok,
we're
tired
of
having
different
api's
we're
tired
of
having
a
fragmented
experience.
Let's
come
together
and
let's
actually
formalize
this
and
make
this
a
kubernetes
official
project,
so
some
of
the
original
goals
of
the
project
that
we
hope
to
solve
again.
A
These
come
from
lessons
learned
from
tools
like
cops
in
Cuba
coin,
as
we
wanted
automatic
transactions
for
the
cluster
management
operations,
and
that's
a
really
fancy
way
of
saying.
If
something
breaks
we
want
to
like
guarantee
that
it's
going
to
break
in
a
clean
way.
We
don't
want
to
have
halfway
deployed
clusters
anymore.
We
don't
want
to
bring
up
a
virtual
machine
that
isn't
configured
properly
or
is
missing
security
authentication.
We
want
to
make
sure
that
it
either
works
into
its
entirety
or
it
fails
in
its
entirety.
A
We
have
cluster
automation,
which,
again
this
is
just
plugging
things
into
the
cluster
API.
If
we
do
things
in
a
declarative
way,
we're
able
to
build
on
that-
and
we
write
other
tooling
that
can
simply
scale
and
change
our
clusters
from
underneath
us
resilient
infrastructure.
So
we
see
this
all
over
kubernetes.
If
you
ride
a
controller,
you
write
an
operator,
something
changes
accidentally.
Those
operators
go
back
and
try
to
fix
it,
they're
continually
working
towards
this
desired
state,
and
we
can
now
get
that
with
infrastructure
which
we
haven't
seen
before.
A
We
want
to
improve
user
experience.
This
is
going
to
be
who
here
an
operator,
sits
down
at
the
command
line
and
actually
manages
the
kubernetes
cluster.
Okay,
so
you're
the
people
we're
talking
to.
We
want
this
to
be
as
intuitive
and
it's
graceful
for
you
as
possible,
and
we
just
want
you
to
feel
like
you
have
everything
you
need
right
there
at
your
fingertips.
Last
but
not
least,
cluster
upgrades
who
here
enjoys
upgrading
kubernetes
okay,
so
like
maybe
what
like?
What
do
you
think
lock
like
10
people
yeah?
So
we
want
to?
A
We
want
to
solve
that.
We
want
to
start
standardizing
how
an
upgrade
is
going
to
work
and,
last
but
not
least,
we
wanted
to
create
a
community.
We
had
a
lot
of
small
communities
that
we're
all
sort
of
fighting
each
other
and
we
hope
to
bring
people
together
today
to
work
on
this.
Last
but
not
least,
we
have
one
last
additional
goal,
which
is
cross
infrastructure
deployment.
This
was
the
original
promise
of
kubernetes.
In
the
first
place
to
be
cloud
agnostic,
we
want
to
bring
that
infrastructure.
So
that's
the
cluster
API
in
a
nutshell,.
B
Ok,
cluster
API
basics.
First
topic
is
a
cluster
CTO,
so
this
is
a
bootstrap
CLI
that
was
built
by
the
project
and
it's
it
was
designed
to
bootstrap
cluster
API
and
right
now,
a
we.
Every
provider
implements
their
own
version
of
cluster
API
I
mean
cluster,
your
CTO,
because
it
requires
some
logic
from
each
provider.
Implementation.
B
So
we
have
a
couple
of
CR
DS
objects
in
cluster
API,
representing
things
that
cluster
machine
machine
set
and
machine
deployment,
machine
set
and
machine
deployment
are
kind
of
analogous
to
replica
sets
and
deployments
and
then,
like
Chris,
said
earlier
about
the
reconciliation.
That's
how
the
declarative
action
occur
because
of
the
controller,
reconciliation,
loop
and
yeah.
That's
it.
A
So
yeah,
so
how
this
all
kind
of
fits
together
to
like
look
at
the
iPad
high-level
picture
here,
here's
a
basic
diagram
that
that
has
a
lot
of
small
squares
on
it,
but
basically
there's
three
main
components
here
that
you
need
to
concern
yourself
with
the
first
one
is
the
cluster
controller?
The
second
one
is
the
providers
cluster
actuator
in
this
last
but
not
least,
little
square
over
here
is
very
unique.
Specific
information-
that's
unique
to
a
provider,
in
this
case
we're
using
vSphere,
because
we
both
work
for
view
and
Larry
now
so
so.
A
Cluster
cuddle
is
the
command
line
tool.
It's
modeled,
just
like
you,
Bechdel
and
all
the
other
kubernetes
CTL
control.
Whatever
tools
you
want
to
use
and
then
basically
it
goes
and
it
creates
a
CR
D,
and
then
we
deploy
these
controllers
and
these
controllers
reconcile
the
CR
G.
It's
the
same
operator
model
we've
heard
from
our
keynotes
this
morning
when
we
learned
from
SED
also
by
the
way
congrats
to
SED
for
making
it
to
the
CNC
F
today,
but
the
cluster
controller
is
special
because
for
the
first
time
we're
actually
reconciling
infrastructure.
A
So
in
this
example,
let's
sort
of
go
from
left
to
right,
we
define
a
cluster
spec,
so
this
represents
a
kubernetes
cluster,
who
can
think
of
an
example
directive
that
we
might
want
to
define
here,
API
port.
Perhaps
what
port
do
we
want
the
API
server
to
listen
on
what
version
of
kubernetes
do
we
want
to
run
the
control
plane?
So
these
are
all
things
that
you
would
go
into
fine
here,
and
most
of
these
are
gonna
map
to
cube
admin.
A
Furthermore,
we
go
down
a
layer
into
this
other
thing
called
the
provider
spec,
and
this
is
going
to
be
the
unique
implementation
for
all
of
the
different
cloud
providers
behind
the
scenes.
In
this
example,
we
actually
are
going
to
be
using
the
vSphere
provider,
which
is
similar
to
how
a
cloud
provider
works
for
the
rest
of
kubernetes.
And
last
but
not
least,
we
have
this
really
wonderful
status
that
we
haven't
seen
yet
in
kubernetes
management.
A
If
you
go
and
you
create
a
cluster
with
cops
or
with
Kiba
corn,
you
kind
of
just
have
a
cluster,
but
what's
the
status
of
our
cluster,
how
do
we
query
that?
How
do
we
build
tests
again
it
against
it?
How
do
we
gain
observability
into
our
cluster?
These
are
all
problems
that
have
yet
to
be
solved.
Now
we
finally
have
a
status
because
we're
actually
having
a
controller
that
goes
and
runs
against
the
state
of
the
world.
So,
as
we
drill
down
into
the
provider
specific
bits,
this
is
the
square
in
the
middle.
A
You
can
notice
that
we
are
going
to
start
defining
things
that
are
important
to
these
here,
so
these
could
be
things
that
would
define
like
the
size
of
the
virtual
machine.
Perhaps
we
could
put
some
network
level
configuration
in
here
the
size
of
our
disks
attached
to
our
virtual
machines,
and
these
would
translate
one-to-one
two
things
that
are
important
to
my
specific
cloud
provider.
The
beauty
of
this
is
now
doesn't
matter
what
cloud
provider
am
using.
A
One
of
the
reasons
we
chose
to
have
provider
specific
bits
is
because
we
learned
the
hard
way
after
trying
to
do
this
in
cops
and
try
and
do
this
in
cuba
corn
that
actually
trying
to
find
an
abstraction
that
works
against
all
providers
was
never
gonna
happen.
So
we
decided
to
keep
the
top-level
directives
as
simple
as
possible
and
put
as
much
into
cloud
specific
provider
information
as
we
could.
Okay.
B
Moving
on
this
is
a
first,
let's
define
a
couple
of
terms
so
that
when
we
just
talk
a
little
bit
further,
you
guys
understand
so
the
first
term.
We
wanted
to
define
his
target
cluster.
So
this
is
the
cluster
that
you
actually
want
to
create.
Then
the
next
term
is
bootstrap
in
management
cluster.
We're
going
to
talk
about
the
difference
between
the
bootstrapping
management
cluster
later,
but
this
is
the
cluster
that
you're
going
to
use
to
deploy
cluster
API
to
then
create
the
target
cluster
okay,
cluster
CTO.
We
already
talked
about,
and
provider
implementation.
A
These
are
the
official
terms
that
we
picked
out
in
a
cig
after
many
sig
calls
of
argued
what
you
should
be
you,
so
I'm
gonna
try
to
be
on
my
best
behavior
and
use
them
as
correctly
as
I
can
okay.
So
let's
talk
about
these
two
usage
modes,
so
these
are
the
the
two
possible
types
or
two
possible
flavors
of
creating
a
kubernetes
cluster
with
a
cluster
API
that
you
may
or
may
not
see.
A
A
lot
of
the
cloud
providers
are
still
in
an
experimentation
mode,
as
Locke
mentioned
earlier,
and
one
of
these
is
usually
going
to
be
the
path
in
which
they
choose
to
go
down
as
they
look
at
how
they
want
to
start
creating
and
managing
one
or
more
clusters
moving
forward.
So
the
first
one
I'm
going
to
talk
about
is
the
self-service
usage
mode.
So
this
is
a
kubernetes
cluster.
That's
going
to
be
acting
back
on
to
itself,
so
this
is
the
original
design.
A
When
we
originally
started
talking
about
the
project,
was
this
idea
of
kubernetes
managing
itself?
The
problem
here,
though,
is
if
you've
read
my
book,
the
cloud
native
infrastructure.
You
know
that
we've
defined
this
really
hard
problem
to
solve
called
the
bootstrap
problem.
We
saw
this
in
writing
C
compilers,
for
the
first
time
when
the
compilers
had
to
compile
themselves.
We
know
how
the
same
problem
in
kubernetes.
How
do
you
create
a
kubernetes
cluster
from
thin
air?
That's
going
to
ultimately
manage
itself
so
coming
up
with
clever
ways
to
solve.
A
That
is
what
the
cig
who's
been
working
on
over
the
past
couple
of
months.
Furthermore,
there's
a
problem
because
there's
a
source
of
truths
concern
here.
If
you
define
what
the
cluster
should
look
like
in
the
cluster
itself,
and
something
goes
wrong
with
the
cluster.
Who
knows
what
the
cluster
is
supposed
to
look
like,
so
there's
a
bit
of
a
concern
there
we
solved
with
some
cops
by
putting
the
definition
of
our
cluster
in
a
completely
independent
system.
We
store
it
in
s3
and
that's
how
we
separated
our
concerns
along
the
way.
Okay,.
B
So
the
the
second
usage
model
is
the
management
cluster
I.
Think
everybody
here
who
has
worked
in
enterprise
understand
this
concept.
So
this
is
a
separation
of
concerns.
We
divide
up
the
roles
into
the
cluster
administrator
and
in
the
cluster
creator,
and
for
this
we
need
to
deploy
first
deploy
a
secondary
management
cluster
and
we're
going
to
talk
about
that
a
little
bit
more.
When
we
talk
about
the
vSphere
provider,
it
is
a
little
bit
more
complex,
but
it
also
provides
a
lot
of
flexibility
that
we're
going
to
talk
about
by
the
way.
B
A
So,
let's
go
into
self-service
a
little
bit
more
and
learn
about
some
strengths
and
weaknesses
to
this
approach
and
talk
a
little
bit
more
about
the
broader
design
here.
So
this
is
when
kubernetes
manages
itself,
it
can
either
manage
itself
via
the
bootstrap
problem
or
by
a
bootstrap
cluster.
So
a
bootstrap
cluster
is
a
temporary
ephemeral
cluster
that
is
used
to
create
other
kubernetes
clusters.
I
used
the
word
ephemeral
there,
specifically
because
this
is
not
designed
to
be
a
cluster
that
lasts
very
long.
A
It
just
serves
as
sort
of
our
springboard
into
building
other
clusters
later,
and
we
can
see
a
concrete
example
of
this.
When
we
look
at
the
AWS
provider
which
we're
going
to
talk
about
in
a
minute,
so
some
traits
of
a
self-service
cluster
that
is
built
using
the
cluster
API
is
it
has
to
solve
the
original
cluster
problem.
So
at
some
point
we
have
to
say
we
need
some
cluster
created,
somehow
whether
that's
using
a
tool
like
kubernetes,
a
docker
or
mini
cube,
or
maybe
a
managed
service
similar.
A
We
do
need
an
initial
cluster
to
start
the
process
on,
and
in
this
case
we
we
use
mini
cube
by
default.
Furthermore,
it's
centralized
storage
of
cluster
declaration.
This
is
what
I
talked
about
earlier,
where
the
actual
representation
of
the
cluster
is
itself
is
stored
inside
of
the
cluster.
So
one
of
the
great
strengths
of
this
is
extremely
simple.
You
can
understand
it
pretty
easily
I
have
some
CRTs.
They
represent
a
cluster
I,
have
a
controller
that
manages
creating
and
mutating
that
cluster
over
time
moving
forward.
A
So
one
of
the
big
weaknesses
is
its
decentralized
nature
and
makes
a
central
accounting
of
the
clusters
harder
and
it
may
not
be
allowed
in
some
enterprises.
So,
as
we
started
talking
to
more
corporate
implementations
of
the
cluster
API,
we
actually
learned
that
defining
secrets
is
as
fairly
important
and
how
we're
gonna
start
managing
those
is
going
to
be
a
concern.
We
need
to
start
looking
at
a
little
more
in
depth.
A
Ok,
so
here's
a
lovely
diagram
of
a
self-service
cluster,
so,
let's
start
at
the
top
the
cluster
CTL
or
cluster
cuddle
command-line
tool.
This
is
this
is
the
same
command-line
tool
you
would
use,
regardless
of
what
cloud
you're
running
in
and
you
would
use
cluster
cuddle
to
first
create
a
bootstrap
cluster.
So
in
this
example,
we
see
that
you
could
use
fusion
or
VirtualBox,
and
this
would
actually
be
what
is
running
mini
cube,
and
this
would
be
running
locally.
If
I
was
running
this
in
my
macbook
here,
I
would
run
a
cluster
cuddle
create
command.
A
It
would
then
spin
up
a
mini,
cube
virtual
machine,
and
that
would
serve
as
our
bootstrap
cluster
once
that
cluster
is
up
and
running.
We
would
define
the
see
IDs,
we
would
install
some
controllers,
and
those
controllers
would
then,
and
now
we're
moving
across
the
bottom
of
the
screen
would
actually
go
and
bring
up
at
the
target
cluster,
and
that
cluster
is
what
we
would
actually
plan
on
keeping
online
and
what
we
would
ultimately
do.
A
So
in
this
example,
this
is
a
little
more
vague,
but
we
wanted
to
speak
to
the
power
of
the
cluster
API.
The
community
and
the
broader
tickets
come
together
and
written
tools
and
common
libraries
to
make
this
easier
for
you
and
implementer
to
go
and
write,
but
the
the
shape
of
the
API,
the
API
service
itself
is
where
the
real
value
is
here.
So
in
this
intentionally
ambiguous
diagram,
we
wanted
to
point
out
that
you
don't
necessarily
have
to
use
cluster
cuddle.
A
You
don't
necessarily
have
to
use
the
tools
in
the
libraries
that
the
kubernetes
community
is
working
on,
but
the
API
shape
still
remains
the
same
and
speaking
that
API
shape
is
going
to
be
important.
As
we
start
looking
at
standardizing
what
a
kubernetes
cluster
looks
like
moving
forward.
So
in
this
example,
we
could
have
one
or
more
ambiguous
tools
that
would
handle
creating
a
cluster,
define
some
C
RDS
and
then
reconciling
those
C
RDS
and
managing
one
or
more
clusters
moving
forward.
B
That
the
the
that
the
working
group
has
started
investigating
and
it
solves
the
bootstrap
problem
by
first
installing
an
initial
cluster
and
the
traits
are
that
it
has
two
primary
roles:
administrator
who
installs
the
initial
cluster
and
in
the
cluster
creator
who
who
creates
cluster
for
maybe
their
department
or
something
or
a
business
unit,
and
it
also
has
a
central
storage
for
all
the
cluster
declaration.
Now.
The
strength
of
this
is
that
it
centralizes
the
accounting
of
cluster
resources
used
by
by
the
clusters
and
users.
Don't
need
extra
software
like
fusion
or
mini
queue.
B
B
It's
a
lot
simpler
in
that
there's
less
boxes,
but
so
you
you,
you
first
have
a
management
cluster
that
you
deploy
somehow
and
in
this
diagram
notice
that
there's
two
types
of
target
clusters
here-
and
this
is
a
this-
is
important.
So
the
the
the
one
on
the
left
has
a
target
cluster,
that's
very
similar
to
the
self-service
cluster
in
that
we
can
deploy
the
cluster
API
onto
it.
B
Why
do
we
want
to
do
that?
Because
we
want
that
cluster
to
be
self-managed
to
be?
If
you
want
to
modify
the
cluster,
you
can
tell
it
to
modify
and
it
will
reconcile
itself
or
and
in
the
target
cluster
on
the
right
is
a
skinnier
cluster
where
it
doesn't
have
the
cluster
API,
but
it
doesn't.
You
can't
do
self
edits
on
the
cluster
and
we're
not
sure
which
way
we're
in
going
yet.
If
this,
maybe
we
always
support
both
well.
B
A
B
Okay,
so
let's
talk
about
the
vSphere
provider,
so
the
vSphere
provider
supports
both
the
self
service
and
the
management
cluster
model.
The
the
admin
workflow
is
this.
So
any
of
you
guys
who
are
very
familiar
with
vSphere,
knows
about
OVA
and
it's
very
common
deployment
model.
You
first
deploy
an
OVA
and
the
OVA
creates
the
management
cluster.
B
So
why
a
management
cluster?
Well,
this
is
a
model
that
I
think
a
lot
of
our
customers,
a
lot
of
our
customers,
our
administrators,
are
in
DevOps,
and
this
is
a
model
that's
very
familiar
to
them.
They
want
to
be
able
to
see
all
the
resources
being
used
on
vSphere,
and
this
provides
that
for
them
and
also
the
OVA
is
a
very
common
deployment
model.
A
A
The
frustration
and
the
the
weird
API
behavior
that
we
detected
as
we
began
to
look
at
not
only
creating
the
cluster
in
Amazon,
but
actually
running
in
that
cluster
over
time.
Scaling
that
cluster
up
and
down
and
upgrading
that
cluster
as
well
so
cig
AWS,
one
of
the
kubernetes
SIG's
I'm
co-chair
of
and
said,
cluster
lifecycle
join
forces
to
create
the
AWS
cluster
API
provider
implementation.
And
this
is
a
very
fancy
way
of
saying.
A
We
took
the
cluster
cuddle
tool
and
the
cluster
API
shape
and
we
wrote
an
Amazon
specific
implementation,
but
you
can
actually
go
and
run
today.
I
did
a
demo
on
this
a
few
weeks
ago
and
I'll
be
doing
another
demo
on
it
later
today.
If
folks
want
to
see
it,
and
we
might
be
able
to
look
at
something
at
the
end
of
the
talk
here
if
we
have
enough
time,
but
ultimately
this
uses
a
bootstrap
cluster,
it
uses
mini
cube
today
and
it
goes
in
and
defines
I
think
we're
using
crts.
A
Now
we
were
using
an
aggregated
API
server
before,
but
I
think
we
finally
switched
over
to
CR
DS
again
with
long
history
there
to
define
a
cluster
in
Amazon,
and
here
we
would
define
things
like
EPC
information,
security
group
information,
the
type
of
ec2
instances.
We
want
to
use
the
version
of
kubernetes,
we
want
to
use,
etc.
A
We
get
a
lot
of
the
resiliency
concerns
that
you
see
in
the
rest
of
kubernetes,
and
this
would
actually
go
and
create
a
kubernetes
cluster
in
amazon,
and
then
we
would
be
able
to
take
those
same
improvement
on
these
cluster
definitions
and
change
them,
and
the
reconciler
would
reconcile
them
over
time.
So
on
the
right
side
of
the
page,
here
we
can
sort
of
see
a
little
bit
of
the
flow.
We
would
first
create
a
bootstrap
cluster
in
mini
cube.
It
would
handle
all
this
TLS
secret
generation
and
it
needs
to.
A
It
would
then
go
and
create
a
second
cluster
in
Amazon
against
the
Amazon
API.
As
long
as
you
had
an
Amazon
I
am
set
up
beforehand.
That
allowed
you
to
create
all
the
resources
needed
and
then
there
would
be
a
controller
manager
that
wraps
up
a
number
of
different
controllers.
That
then,
would
go
and
actually
handle
creating
every
specific
piece
of
infrastructure
behind
the
scenes
to
bring
in
Amazon
cluster
to
life
and
that's
how
the
AWS
provider
works
so
right
now
we're
using
a
very
simple
self
service
usage
mode.
A
B
And
and
I
think
we-
we
talked
about
this
earlier
in
the
presentation
that
eventually
we
want
all
the
providers
to
be
able
to
work
together.
So
I
could
see
one
day
for
for
vSphere
users
we
can
shift
an
ova
as
all
the
providers,
so
you
can
deploy
to
be
sphere.
You
can
deploy
to
AWS.
You
can
avoid
to
Google
cloud
and
that's
the
hope.
Okay,.
A
Cool,
so
at
this
point
we're
gonna
do
a
open
QA.
A
lot
of
folks
have
come
up
to
me
at
the
conference.
I
think
some
folks
have
come
up
to
you
as
well.
If
anybody
has
any
questions
where
we
can
answer
them
now,
I
noticed
we
have
some
folks
from
the
sig
here
as
well,
and
we
were
happy
to
answer
any
questions
along
the
way
or
clarify
anything.
If
anybody
has
any
thing
yes,
I'll
see,
I'll
say
it
back
to.
A
A
B
A
D
A
A
A
It
was
I
look
at
the
history
of
the
project
before
we
moved
the
new
repository.
There
was
a
terraform
provider
once
upon
a
time,
so
there
might
be
some
work
there
that
we
could
look
at
as
well.
How
much
time
do
we
have
left?
We
have
seven
minutes
so
we'll
try
to
keep
them
quick.
Let's
start
here,
I
think
I
saw
your
hand
up
first.
A
This
is
the
best
question.
Okay,
so
can
you
use
this
to
stand
up
a
cluster
on
bare
metal,
so
I
think
there's
two
answers
there
and
that
depends
on
how
you
define
bare
metal.
So
the
first
one
is
true,
bare
metal,
which
is
like
a
machine
that
you
plug
into
the
wall
with
an
rj45
running
an
operating
system
and
then
there's
VMware,
which
is
the
vSphere
provider.
So
the
original
goal
of
the
project
was
to
be
inclusive.
To
bare
metal.
A
E
E
A
So
the
question
was:
how
far
does
it
go?
Do
we
can
we
do
a
che?
Does
it
do
monitoring?
What's
the
scope
effectively
of
the
cluster
API,
the
cluster
API
manages
cluster
infrastructure
only
bringing
up
the
layer
software
that
we
humans
call
kubernetes
and
managing
that
over
timing
stops
there
one
two
three
and
then
I
think
we'll
be
out
of
time.
A
A
Okay,
so
the
question
is:
how
do
we
deal
with
dependencies
like
docker,
Annette
CV,
when
we're
managing
upgrading
our
cluster,
as
we
mentioned,
we're
still
in
experimentation
mode,
we're
still
developing
a
lot
of
these
strategies.
We
actually
talked
at
the
contributor
summit
about
the
upgrade
strategy
for
the
project
and
what
we
want
to
do
there.
So
we're
still
figuring
that
up
question.
Let's
do
the
back
and
then
you
and
here
in
the
front.
A
C
A
See
I
see
so
the
question
here
is
effectively:
are
we
doing
I
forget,
there's
a
name
for
it,
but
it's
where
you
would
run
the
kubernetes
control
plane
as
a
deployment
or
set
of
deployments
on
the
management
cluster.
So
this
is
where
you
get
into
like
a
hybrid
model
of
like
how
do
you
bridge
the
gap
between
this
new
cluster
that
is
just
nodes
only
and
you're
running
a
control
plane
on
another
kubernetes
cluster
there's
a
bilateral
communication
there.
So,
however,
we
can
solve
that
I
mean
we've
thought
about
it.
I
think
it's
possible.
A
A
Sure
I
think
that's
a
possibility.
I
think
that's
one
of
the
big
reasons
why
we
wanted
to
start
defining
this
as
a
CR
D
and
using
operators
in
the
first
place
so
that
we
could
start
making
this
much
more
portable
anyway.
The
question
was:
why
don't
we
have
any
examples
like
this
already
and
I?
Just
think
it's
we're
not
there.
Yet
any.
B
You
know
you
saw
the
self
service
in
the
the
management
cluster
model
and
we
want
to
hear
your
opinions
and
we
have
a
bunch
of
questions
and
we'd
like
to
hear
your
opinions
on
on
a
lot
of
this,
because
we're
experimenting
right
now
and
we
would
love
to
you
know
if
we're
going
in
the
right
direction.
Absolutely.
A
At
the
end
of
the
survey,
there's
also
an
optional
spot,
where
you
can
write
your
email
address
if
you
would
like
for
us
to
follow
up,
and
we
can
have
any
other
discussions
moving
forward.
So
if
you
want
to
talk
more
with
folks
that
have
to
our
folks
at
VMware
feel
free
to
hit
that
survey,
and
we
will
go
from
there.
Okay,.
B
I
just
wanted
to
say
one
listing:
yeah
I'm.
Sorry,
we
didn't
have
time
for
demo
today.
The
demo
would
have
taken
a
lot
of
time,
but
later
next
week
we're
gonna
have
videos
of
the
demo
of
the
vSphere
provider
with
the
management
cluster
in
the
OVA
deployment
up
on
our
repo.
So
next
week
after
coop
con
look
for
that
thanks.