►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Off
we
go,
I
want
to
thank
everyone
for
joining
us.
Welcome
to
today's
cncf
live
webinar,
how
we
manage
thousands
of
clusters
with
minimal
efforts
using
gardner,
I'm
libby
schultz
and
I'll
be
moderating
today's
webinar.
I
want
to
introduce
our
speakers
today,
smarth
a
software
engineer
and
hardik
a
software
developer,
both
at
sap
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
speak
as
an
attendee.
A
A
In
addition,
please
join
our
cncf
public
slack
channel
hashtag
cncf
cncf-online-programs
to
continue
the
conversation
later
and
address
any
questions
you
had
we
didn't
get
to.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
any
questions
that
would
be
in
violation
of
that
code
of
conduct
and
please
be
respectful
to
all
of
your
fellow
participants
and
presenters.
B
So
thanks
a
lot,
everyone
first
of
all
joining
and
let
me
first
of
all
introduce
myself
so
I'm
hardik,
I'm
a
software
developer
developer
on
gardener
on
metal.
Previously
I
was
working
on
gardner,
mainly
the
machine
management
and
auto
scaling
of
corner,
and
otherwise
I
am
also
once
in
a
while
active
in
the
cluster
api
community
and
the
auto
scaling
community
in
general.
C
B
Okay,
so
let's
get
started
first
of
all,
the
first
thing:
first,
what's
the
motivation,
so
the
webinar
is
actually,
of
course,
about
card
and
a
brief
about
it.
So
it's
basically
an
open
source
initiative
by
sap.
It's
basically
a
fully
managed
control
plane
as
a
service
that
offers
homogeneous
clusters
potentially
on
any
cloud
provider
and
is
fully
customizable
and
scalable,
and
we
have
been
thousands
of
clusters
for
real
since
recently,
and
this
webinar
is
about
giving
a
glimpse
around
what
and
why
and
how,
and
we
will
basically
be
doing
something
interesting.
C
Yes,
so
managing
thousands
of
kubernetes
clusters
at
scale
is
not
a
cakewalk,
and
over
these
three
to
four
years,
gardener
has
evolved
to
be
so
robust
and
scalable
that
we
have
actually
made
managing
thousands
of
clusters
a
cakewalk,
so
gardener
primarily
runs
everywhere.
It
runs
on
our
own
infrastructure,
it
also
runs
on
other
cloud
providers
and
the
experience
that
it
gives
with
respect
to
the
versions
or
the
features
offered,
is
pretty
homogeneous,
even
though
the
support
is
for
various
cloud
and
even
our
own
infrastructure.
B
Yes,
and
to
communicate
the
idea
a
bit
more
effectively,
this
is
what
we
are
going
to
do.
So
we
are
going
to
host
a
hypothetical,
highly
consumable
once
in
a
minute.
Instead
of
an
application,
it's
going.
We
are
going
to
call
it
the
botanist
waste
on
a
platform
which
would
really
need
something,
as
droppost
is
called.
C
So
we
will
be
assuming
kind
of
our
roles
and
we
will
do
the
role
play
where
hardik
will
be
the
founder
of
this
application.
He
spoke
about
the
botanist
quest,
which
is
hypothetical,
and
I
will
be
the
product
manager
for
this
modernist
quest,
and
this
webinar
is
basically
going
to
be.
You
know
a
set
of
arguments
and
brainstorming
between
us
to
design
this
gardener
from
scratch
and
convince
you
that
such
a
robust
platform
is
practically
possible
to
exist
for
applications
like
botanist
quest
and
or
for
also
other
critical
applications
of
yours.
B
So
this
is
what
I
have
I
have.
I
have
got
one
very
nice
kubernetes
cluster
with
three
dedicated
control,
plane
machines
and
it's
basically
serving
a
bunch
of
beta
users,
and
I
have
got
a
really
good
feedback
already
for
the
application
and
we
are
going
to
launch
the
jungle
release
very
soon
and
then
our
initial
set
of
or
the
target
new
users
would
be
around
500
or
so.
B
So
on
essay
we
have
a
beta
app
and
that's
hosted
on
one
cluster
and
the
plan
is
that
we
simply
scale
this
cluster
to
file.
So
we
would
have
basically
five
clusters
with
dedicated
control,
plane
machines
and
all
of
them
would
basically
be
hosting.
The
pattern
is
quest
in
high
india
hybrid
model.
They
would
also
be
running
on
different
cloud
providers
and
yeah.
That's
the
situation
at
the
moment.
C
That
is
good,
but
five
dedicated
clusters
might
not
be
enough
scaling
because,
as
per
my
research,
botanist
quest
is
having
a
lot
of
traction
in
the
market,
and
I
see
something
similar
to
pokemon.
Go
might
potentially
happen
with
botanist
quest
too.
That
is,
you
might
have
planned
for
an
expected
influx
of
a
5x
in
the
worst
case,
but
your
traffic
might
hit
250x,
which
happened
with
the
pokemon,
go
right,
so
you
might
have
to
have
the
scaling
done
massively
and
across
geographical
locations.
C
You
said
about
multi-cloud,
so
are
you
planning
to
take
the
managed
clusters
across
different
cloud
providers
because,
if
you
are
doing
so,
probably
there
won't
be
a
homogeneous
experience
when
it
comes
to
managing
the
clusters
and
also
the
transparency
of
the
control
plane.
I
doubt
if
we
would
get
that
and
also
I
want
you
to
employ
our
own
infrastructure
that
we
have
at
different
locations.
B
Yeah
yeah,
I
get
it,
I
get
it
so.
Basically,
I
my
team
is
then
going
to
replicate
the
installation.
We
would
have
30
kubernetes
clusters,
we'll
use
this
awesome,
foo
bar
tool
that
we
have
been
using.
It
will
be
multi
cloud,
yes,
and
all
of
them
will
also
have
three
dedicated
control
plane
machines
again,
so
it
will
be
super
reliable
and
I
think
it
should
work
like
a
charm.
C
Yeah
that
does
look
good,
but
30
clusters
with
three
dedicated
control
plane
nodes
for
each
cluster
doesn't
really
is
as
cool
as
it
appears
to
be.
You
know
why.
The
first
reason
is
that
the
control
plane
nodes
are
never
fully
utilized,
they
are
always
under
utilized.
So
let's
say
for
30
clusters,
you
will
end
up
having
90
control
plane
nodes,
and
these
will
only
incur
your
cost
faster
than
your
team
scaling
up
your
clusters
and
not
just
that.
Have
you
even
considered
about
the
operational
complexities
that
your
team
might
face?
C
What
if
some
cluster
goes
into
volume,
mount
issues?
Some
cluster
has
an
api
unreachable
issue
and
some
other
cluster
has
some
other
issue,
and
if
these
things
start
happening
simultaneously,
then
the
team
will
go
heavier
and
more
than
that,
how
have
you
planned
to
manage
the
tracking
of
these
clusters
for
their
config
files
and
cloud
credentials,
etc?
C
B
Yeah,
those
are
actually
good
points
and,
let's
take
a
first
look,
I
would
say
the
kubernetes
or
let's,
let's,
let's
ponder
upon
what
we
already
know
so.
First
of
all,
we
know
that
the
dedicated
control
plane
machines
are
usually
underutilized
in
most
of
the
setups.
As
you
see
second
point
that
is
very
well
known.
Also,
the
beauty
of
the
kubernetes
is
that
the
both
the
control
plane
and
the
workload
are
somehow
decoupled.
So
they
can.
B
They
don't
really
necessarily
has
to
run
always
together
and
the
third
and
the
more
important
point
is
basically
the
control
plane
components
themselves
are
actually
a
full-fledged
workload.
Applications
they
are,
they
can
be
probably
be
treated
as
the
workload
themselves.
Okay.
So
what
can
we
actually
infer
from
this
information
and
maybe
innovate
to
address
your
concerns?
B
C
B
Yes,
it
is
the
chip
section
and,
and
so
in
order
to
improve
the
resource
utilization
of
the
controller
plane
nodes.
I
think
we
will
spawn
one
kubernetes
cluster
manually
and
then
we'll
call
it
a
management
cluster,
and
then
we
do.
We
basically
use
that
management
cluster
to
host
the
control
plane
of
other
clusters.
So
for
the
visualization,
this
is.
What
is
what
you
see
on
the
screen
is
is
what
I
would
like
to
propose.
B
C
B
Yeah
sure
so,
let's
take
a
let's
double
down
and
let's
take
a
bit
closer
look
so
essentially
the
control
plane
of
each
let's
call
them.
Child
cluster
would
basically
have
their
own
dedicated
name
species.
So
that's
first
level
of
isolation.
Of
course
we
don't
want
them
to
mess
up
with
each
other,
so
we
can
also
isolate
them
using
the
network
policies.
So
that
would
be
the
baseline
idea
and
then
another
thing
which
I
would
really
want
to
consider
is
that
we
really
use
kubernetes
here
and
not
invent
the
pre-inventor
bill.
B
So
I
would
use
deployments
and
stateful
sets
and
such
battle
tested
inbuilt
controllers
to
deploy
the
api
server.
Lcd,
cube,
scheduler
and
and
components
like
that,
and
this.
This
essentially
should
actually
reduce
the
blast
radius
by
effectively
having
to
manage
only
one
management
cluster
against
30
clusters,
as
it
was
in
the
previous
case.
C
Oh,
that's.
That
appears
to
be
pretty
efficient,
but
but
I
think
it
only
addresses
the
cost
issue
right,
where
the
excessive
under
utilized
control
plane
machines
were
rather
migrated
as
workload
onto
one
single
management
cluster
as
workload.
But
when
it
comes
to
life
cycle
of
these
control
planes
and
the
life
cycle
of
the
underlying
machines,
I
think
we
are
back
to
square
one.
B
B
Let's,
let's
do
it
this
way,
so
we
have
our
control
plane
parts
and
then
we
we
basically
represent
them
using
the
cluster
crd.
This
cluster
crd
would
have
all
the
knobs
and
necessary
configuration
options
that
decides
the
whole
life
cycle
of
a
given
cluster
and
in
a
similar
way.
This
will
help
me
trigger
the
cluster
of
creations.
B
So
we
can
also
introduce
a
crd
for
machines
and
then
it
could
look
like
a
machine
deployment,
machine
set
and
machines
in
a
similar
way.
There
are
deployment
replica
set
and
parts
so
the
way
a
deployment
controller
somehow
always
ensures
that
a
certain
number
of
replicas
of
the
pod
are
always
running,
and
it
does
a
very
fine-grained
rolling
updates
of
the
pod.
B
We
could
also
implement
the
similar
similar
functionalities
for
the
machines,
so
we
have
machine
deployment
which
would
basically
help
us
do
the
right
kind
of
rolling
updates
and
so
on,
and
and
yes
with
this
kind
of
abstraction,
if
you
call
it
the
machine
api,
we
get
seamless,
auto
scaling
as
well,
because
with
such
abstracted,
dedicated
crts,
then
the
higher
level
functionalities
or
the
higher
level
automations
becomes
really
easy.
So
just
imagine
cluster
autoscaler,
making
use
of
this
and
we
get
free,
auto
scaling
for
all
cloud
providers,
even
parameters
and
so
on.
C
B
Yeah
so,
and-
and
here
is
also
detailed
visualization,
so
so
essentially,
we
would
also
have
the
cluster
controller
manager.
Of
course,
we
would
have
a
controller
which
would
take
care
of
both
kinds
of
crts,
and
this
controller
would
be
running
in
the
management,
controller
management
cluster
and
upon
creation
of
the
cluster
crd.
The
control
plane
of
the
child
cluster
should
be
deployed
first
by
the
controller
and
then
in
turn.
The
same
controller
also
deploys
the
machine
crds.
C
B
B
Okay,
you
might
be
surprised,
but
I
already
already
prepared
it.
I
think
I'm
just
too
fast.
So,
let's
look
at
the
demo.
We
have
three
terminals
here:
two
management
clusters
and
one
to
my
load
cluster.
I
wanna
quickly
see
the
shoot,
so
I'm
gonna
I'm
going
to
call
it
a
shoot
because
it's
my
cluster,
it's
my
bottomless
twist.
So
for
the
key
one
shoot
cluster,
which
is
called
bqtemocncf,
I
have.
C
B
Particular
shoot
cluster
and
I
would
expect
that
this
name
space
hosts
all
of
the
control
plane,
components
that
are
necessary
got
it.
Let's
take
a
look
into
it
and
we
already
see
that
here
I
have
on
top
of
the
essential
control
plane
components
like
api
server,
scheduler
controller
manager.
I
also
have
few
other
controllers.
I
have
introduced
something
also
for
the
machine
api,
a
separate
controller
which
we
call
machine,
controller
manager
and
then
also
auto
scaler
as
a
separate
controller.
B
So
here
it's
a
glimpse
where
we
see
that
in
the
spec
section
we
can
already
see
there
are
multiple
sections.
Hibernation
is
one
of
my
favorite,
it
saves
so
much
cost
for
us.
We
can
also
kind
of
configure
all
kind
of
cooperative
related
stuff,
fully
transparently
via
the
spec,
and
here
we
go
and
we
see
the
worker
section.
The
worker
section
is
basically
what
we
just
discussed
so
based
on
the
information
that
I
gave
here
I
tell
minimum
is
high.
Three
maximum
is
five.
B
I
give
a
very
fine
grained
information
like
max
unavailable
and
max
search,
which
should
be
respected
during
rolling
update,
and
then
this
controller
basically
fetches
this
information
and
prepares
the
right
kind
of
machine
deployments.
Let's
take
a
look
at
what
we
have
in
terms
of
machine
deployment,
machine
set
and
machines.
C
B
B
Here
we
see
again
for
the
consistency
through
replicas.
This
allows
us
to
the
rolling
update.
It's
also
allows
us
to
do
the
recreate
strategy
in
case
of
rolling
update.
It
would
really
delete
the
machines
one
by
one.
The
way
the
deployment
controller
does,
and
we
have
a
reference
to
the
machine
class
and
the
node
template
to
sync
to
sync:
the
labels
and
other
metadata
back
to
the
node
object
back
and
forth.
Node
object
and
the
machine
objects,
because
essentially
the
machines
are
really
dynamic.
B
And
yeah
what
we
could
do
more,
I
think
we
could
quickly
change
because
I
claimed
it
should
take
care
of
the
life
cycle.
Let
me
actually
make
make
a
very
small
change
in
the
shoot.
So
before
that
I
would,
I
would
watch
the
machine
deployments
and
I
would
also
watch
the
nodes
of
my
workload
cluster.
So
three
nodes
designate
the
three
machine
objects
that
are
there
in
my
management
cluster.
B
B
With
with
a
minimal
change-
and
this
is
actually
the
power
of
the
declarative
approach
with
once
I
make
this
change,
my
controller,
which
is
running
in
the
backend,
is
going
to
reconcile
this
particular
chain
form
or
it's
going
to
update
during
the
reconciliation.
It's
going
to
update
the
machine
deployments,
machine
sets,
and
so
on
that
there
is
a
change
in
the
worker
section
where
the
promotions
previously
running
were
x
large.
B
Now
they
should
be
running
on
2x
large,
but
the
the
catch
or
the
magic
is
that
it
should
not
be
done
abruptly
because
we
actually
don't
want
to
handle
only
infrastructure
here.
We
also
want
to
take
care
of
the
pods
running
on
them.
So
because
I
said
makes
unavailable
was
zero
and
max
search
was
one.
It
created
a
new
machine
and
it
will
actually
wait
for
the
new
machine
to
join
until
then.
B
Yes,
that's
true,
and
the
internal
node
object
is
basically
the
virtual
machine
or
the
real
machine,
and
also
one
thing
is
that
this
this?
What
we
are,
what
we
see
here
is
infrastructure
related
stuff,
but
if
you
would
have
a
pod
running
on
one
of
the
machine
and
if
that
part
says
I
have
xyz
pod
sls
that
this
particular
machine
I
am
running
on
should
not
be
deleted.
B
Unless
there
is
another
replica
or
there
are
enough
replicas,
then
this
controller
is
smart
enough
or
I
would
say
this
controller
uses
the
drain
feature
in
such
a
way
that
such
pod,
slas
and
disruption
widgets,
are
also
very
properly
taken
care
of
and
achieve
with
a
bit
of
a
fast
forwarding
in
between.
We
already
have
all
the
three
brand
new
nodes
available
placed
one
by
one.
C
It
this
this
already
looks
good
to
me,
so
it
is
honoring
the
infrastructure
sls
as
well
as
it
is
also
honoring,
the
slas
for
the
applications
that
are
running
as
spots
within
that
infrastructure,
and
this
looks
pretty
good
to
me
to
see
the
infras
being
handled
as
custom
resource
objects
in
a
particular
atp.
This
this
is
really
nice.
C
Okay,
this
is
all
good,
but
I
see
that
all
the
control
planes
of
these
shoot
that
you
call,
because
you
are
botanist
quest
all
these
shoot
clusters.
Control
plane
are
sort
of
hosted
on
a
single
management
cluster
as
workload,
but
the
shoots
are
distributed
across
regions.
So
I
see
a
potential
issue
of
cross
region
latency
here
alongside
this.
C
If
I'm
having
one
management
cluster,
let's
say,
and
this
guy
is
hosting
several
control
planes
of
several
shoot.
It
should
hit
an
upper
limit
correct
that,
after
certain
number
of
clusters,
whole
control
planes
hosted
there.
Maybe
it
cannot
accommodate
more
so
you
might
want
to
scale
the
management
cluster
right.
So
can
you
just
explain
me
how
you're
handling
these
two
aspects.
B
Those
are
again
good
points
and,
honestly,
I
see
a
very
straightforward
solution
to
this
so
see
we
have
one
management
cluster
and
if,
if
the
latency
is
the
problem,
then
we
could
simply
replicate
this
management
cluster
to
the
regions
and
that
should
basically
solve
the
problem.
Although
it
looks
that
we
are
having
instead
of
one
management
cluster,
we
are
having
more
management
clusters,
but
all
of
them
would
basically
be
auto
scaled.
B
C
C
Good,
so
this
idea
is
nice,
so
probably
the
cross
latence
cross
region-
latency,
is
kind
of
handled
here,
but
with
time
you
see
with
increasing
workloads
with
increasing
number
of
shoot,
the
density
of
shoot
will
increase
and
we
might
have
to
scale
the
management
clusters
also
in
a
pretty
large
number.
So
how
do
you
plan
to
manage
these
management
clusters
so.
B
Okay,
yeah,
that's
also
a
valid
argument
and
you
already
got
me
through
entangled
into
it.
I
would
say
I
feel
we
are.
I
don't
want
to
pack.
I
don't
want
to
fall
back
to
the
square
one.
So
let's
take
a
look
at
it
again
from
what
we
have
discussed
so
far.
So
what
we
had
you
know
phase
one.
We
had
a
plenty
of
clusters
with
a
dedicated
control
plane
in
one
location,
and
then
we
saw
the
problem
that
we
have
a
lot
of
resource
being
underutilized.
B
So
we
decided
that
we
move
a
few
clusters,
few
of
the
clusters
different
locations
in
different
regions,
and
this
worked
pretty
well
but
again,
this
this
situation
has
its
own
set
of
problems.
That
again
we
have
plenty
of
control
planes
running
at
plenty
of
locations.
So
we
then
say:
let's
go
to
the
phase
two
and
introduce
a
management
cluster.
B
B
Latency
is
again
a
bit
of
a
trouble,
so
we
replicate
the
management
clusters
to
the
geographic
vicinity,
so
we
moved
all
of
the
clusters
to
their
different
regions.
This
worked
well,
but
again
we
fell
into
the
same
problem
that
we
have.
We
could
have
actually
possibly
plenty
of
management
clusters.
So
the
way
we
had
to
manage
plenty
of
shoot
clusters.
We
now
also
have
to
manage
plenty
of
management
clusters.
To
be
honest,
what
looking
at
the
perception-
and
you
can
looking
at
the
recursive
approach-
I
would
go
bold
and
introduce
another
cluster.
B
B
So
essentially
now
I
have
a
management
cluster
crd,
which
takes
care
of
my
management
clusters,
and
then
I
also
have
to
shoot
crds
and
machine
crds,
so
the
machine
crs
can
also
be
used
for
the
management
clusters
in
general
with
because
it's
completely
recursive
and
our
cluster
controller
manager
runs
at
the
top
label.
At
the
super
management
cluster.
C
Okay,
okay,
I
think
this
proposal
is
also
pretty
good.
So
if
I
understand
this
correctly,
then
the
cluster
crd
and
the
machine
crd
that
we
were
speaking
about
in
the
before
slide,
so
that
cluster
crd
will
now
be
a
part
of
or
it
will
be
applied
or
created
in
the
super
management
cluster,
because
the
cluster
controller
manager
is
also
running
there
and
even
these
super
management
clusters.
Even
these
management
clusters
will
be
represent
as
management
cluster
crd
in
our
super
management.
Cluster,
correct.
C
Yep,
I
think
this
looks
like
a
sophisticated
design.
That
kind
of
convinces
me
that
we
can
now
manage
thousands
of
clusters
so
to
actually
answer
this
question.
Can
we
now
already
manage
thousands
of
clusters?
Probably
we
want
to
look
at
the
flow
of
adding
one
new
cluster
to
this
ecosystem
and
see
if
there
are
any
unknown
unknowns
right.
B
Then
we
are
manually
assigning
this
cluster
to
one
of
the
management
clusters.
Okay,
that
sounds
fuzzy.
Then
the
third
step
is
basically
the
cluster
controller
manager
reconciles
this
cluster
object
and
then
it
creates
the
control
plane
and
in
the
dedicated
name,
space,
that's
good
and
at
the
end,
the
cluster
controller
manager,
of
course
takes
care
of
the
rest
of
the
lifecycle
of
this
control
plane
in
maintaining
it.
B
B
Yes,
I
would
actually
think
that,
let's
take
a
step
back
and
let's,
let's
look
at
the
kubernetes,
what
kubernetes
does
with
the
pods?
So
essentially
we
have
a
cube
api
server.
Yes,
and
then
we
have
scheduler
controller
manager,
so
scheduler's
job
is
actually,
although
it's
it's
really
important,
it's
job
in
sense
is
to
assign
a
node,
so
it
would
just
update
the
node
name
field
on
the
pod
and
that's
job.
Q.
Controller
manager,
of
course,
takes
care
of
certain
other
life
cycle
aspects.
B
B
We
have
a
cluster
aggregation,
server
or,
let's
say
a
standard
server
which
which
is
going
to
host
our
cluster
crts
or
some
securities.
We
already
have
the
first
cluster
controller
manager,
which
and
this
controller
manager
is
creating
control
planes.
Okay,
that's
something
that
could
be
improved.
On
the
other
hand,
I
also
see
that
we
have,
we
already
have
the
control
planes
running
on
the
management
cluster.
So
what's
actually
missing
here.
B
B
Then
we
have
a
corner,
scheduler
gardener,
controller
manager,
which
does
the
same
as
what
we
just
discussed
and
then
the
gardener
garden
elite,
which
is
sense
of
high
scale
and
then
on
each
of
the
seed
cluster.
We
have
one
gardener,
cuddling
hosted,
which
is
responsible
for
managing
the
control
planes
which
are
going
to
run
on
those
particular
seed
clusters.
So
if
you
look
at
the
mapping,
then
this
gardner
scheduler
becomes
a
chip.
B
Currently,
it
is,
of
course,
the
cube
plate
and
the
control
should
control
plane
is
the
part
wow
this.
This
looks
fascinating
and
you
know
what
just
just
to
add.
So
this
is
the
core
of
the
cotton
design
it
maps
to
the
design
pattern
of
kubernetes.
As
we
see
so,
we
can
really
actually
reuse
the
skills
in
effect,
in
effect,
a
cubeception
model
of
turtles.
B
All
the
way
down,
along
with
the
requirement
of
delivering
a
fully
managed
kubernetes
as
a
service
step
by
step,
actually
lead
us
to
this
architecture.
Now,
initially,
our
requirements
are
for
running
the
bottom:
squeeze
application
on
kubernetes
motivated
the
whole
platform,
but
now
it
seems
this
platform
is
not
only.
C
That
is
good.
That
is
good.
So
what
we
started
for
ourselves
looks
like
it
has
become
a
novel
for
all
other
potential
users
too.
This
is
this
is
good
so
going
forward.
I
really
like
the
the
design
already,
but
you
know
we
don't
want
to
miss
one
important
aspect,
because
now
we
are
making
it
available
for
majority
of
the
customers
that
might
find
potential
usage
for
this.
C
So
with
increasing
adoption,
we
might
want
to
support
even
more
cloud
providers,
and
this
may
force
us
to
switch
to
different
operating
systems
and
to
different
network
plugins
and
to
different
other
aspects
of
the
cluster
management.
So
with
ever
evolving
cloud
native
ecosystem,
our
systems
also
have
to
be
completely
extensible.
C
B
Support,
that's
really
a
great
point
and
I
can't
agree
more
with
you.
I
would
say
the
extensibility
should
be
at
the
very,
very
core
of
any
good
design
and
gardner
supports
a
very
neat
and
kubernetes
native
extension
model.
So
each
extension
point
is
essentially
a
provider
specific
controller
very
similar
to
how
extensivity
is
designed
for
cloud
controller
manager,
for
example
in
kubernetes,
and
a
very
simple
example
would
be
actually
for
the
cloud
providers
themselves.
B
Where
you
can
see
that
corner
gardner
would
basically
declare
a
neat
coolant
interface
for
a
provider,
and
then
the
provider
would
have
to
implement
that
particular
interface.
The
interface
content
would
be
a
bare
minimum
functions
which
would
be
needed
for
a
gardener
to
support
or
which
would
be
needed
for
a
full,
refrigerated
kubernetes
to
run
on
a
particular
provider.
One
of
the
one
of
the
simple
example
would
be
the
gardener
extension
provider
aws,
which
is
targeted
for
aws,
and
this,
of
course,
this
report.
B
This
approach
recursively
builds
on
kubernetes
support
for
various
other
providers
as
well.
So
this
was
that
that's
theory,
but
let's
actually
look
at
a
beautiful
outcome
of
of
of
a
well-defined
extension
model
or,
I
would
say,
the
power
of
well-defined
extension
models.
So
we
just
this
is
basically
a
one,
a
simple
single
gardener
installation,
where
there
are
large
number
of
clusters
being
managed
on
different
cloud
providers.
Basically,
gardener
is
the
support
management
cluster.
B
C
B
Okay,
so
let
me
show
you
the
demo
of
what
I
just
talked
about.
What
we
see
on
the
screen
is
a
garter
dashboard
to
have
a
better
user
experience.
Of
course,
everything
can
also
be
done
from
the
terminal
on
what
we
see
is
basically
cluster
secret
members,
some
utilities,
and
then
we
already
saw
a
demo
of
the
pq
demo
cncf
cluster,
where
there
are
few
fields,
different
sections
that
can
be
configured
in
a
given
q1
cluster,
and
you
have
you-
have
a
chance
to
directly
fall
into
the
terminal
from
there.
B
So
what
you
just
saw
in
the
overview
of
course,
everything
there.
The
essence
of
them
is
basically
also
in
the
dml
file
here.
So
you
basically
change
the
cml
files
or
you
you
can
declare
everything
in
the
ml
files
as
well,
and
let's
actually
try
to
create
a
new
cluster
and
see
how
the
flow
looks
like.
So
I'm
going
to
create
a.
C
B
On
aws,
I'm
going
to
call
it
bottomist
here
the
version
is
1.20.
I
can
set
different
purposes,
let's
call
it
evaluation
purpose,
I'm
going
to
use
standard
aws
secret
for
that,
just
access,
key
and
so
on
for
the
worker
pools.
I
would
basically
use
m5.large.
I
can
choose
other
worker
sizes,
let's
use
m5.large,
I
could
use
carbon
linux
operating
system.
Docker
I
would
keep
min
and
max
is
one
and
two
maintenance,
so
I
would
keep
it
as
it
is.
B
So
only
in
this
maintenance
window
the
cluster
would
be
rolled
out
and
not
in
any
random
time,
and
then,
of
course,
my
personal
favorite
is
hibernation.
Where
that
I
would
say
every
day
at
5
pm,
my
cluster
should
be
hibernated,
because
this
is
just
evaluation
clusters.
I
would
actually
save
a
lot
of
cost
by
bringing
down
all
the
machine
and
control
planes
every
day
at
5
pm,
of
course,
same
can
be
done
with
the
yml's
and
let's
not
wait
long
and
go
ahead,
create
a
cluster.
B
What
I
also
see
is
a
tracker,
basically,
it
says,
create
processing.
So
the
tracker
keeps
me
up
to
date
in
terms
of
what's
what's
going
to
what's
happening
right
now
with
some
of
the
detailed
messages,
and
it
says
it's
deploying
the
external
domain
and
let's
now
look
at
the
back
end.
So
at
the
gardner
api
server,
I
would
expect
to
see
another
shoot
cluster
which
we
just
created
by
the
dashboard.
I
already
see
a
bottomist
as
a
new
shoot
cluster,
and
now
it
says
the
creation
is
processing.
B
B
Yeah,
I
see
a
message
which
clearly
states
that
it
has
been
scheduled
to
the
seat,
which
is
aws.
It
has
a
difference.
It
can
also
be
plugged
with
different
kinds
of
scheduling
strategies.
If
you
want
the
way
we
do
with
cube,
scheduler
and
perfect,
let's,
if
it's
assigned
to
the
aws,
then
this
is
the
carton
lid
which
is
running
on
the
aws
seed
cluster
or
the
aws
management
cluster,
and
here
I
would
expect
this.
Cotton
lid
should
have
at
least
started
doing.
B
Something
at
least
it
should
have
fetched
the
definition
and
start
to
create
the
control
plane
parts,
and
I
already
see
that
there
are
there
are
demo
pro
bottom
is
less
bottom
is
which
basically
refers
to
our
cluster,
and
it
has
already
started
processing
that
cluster.
I
think
it's
doing
something
in
the
background
we'll
get
to
know
that
the
next
next
terminal,
then
I
can
also
take
a
quick
look
at
the
gardner
controller
manager
now,
so
we
have
from
the
diagram.
B
Okay,
so
I
see
that
it's
already
api
server
and
lcd,
I
think
more
parts
are
coming.
We
also
have
a
nice
logging
and
monitoring
setup
with
loki
and
on
the
other
hand,
I
would
also
be
later
on
be
interested
in
looking
at
the
workload
cluster,
but
essentially,
if
we,
if
you
try
to
recall
what
we
just
learned
in
the
diagram
so
from
the
api
server,
it
has
reached
to
the
cotton
scheduler
from
scheduler
to
carton
leaked
from
carbon
lead
to
in
parallel
to
corner
controller
manager
and
now
on
the
management
cluster.
B
We
see
something
happening
and
the
dashboard
says
it
shows
clearly
that
the
creation
is
ongoing.
I
think
it
should
take
place
in
the
infrastructure
for
five
to
seven
minutes,
or
so
I
would
suggest
let
let's
take
a
look
at
another
key.
Other
key
features.
Summers.
Meanwhile,
while
the
cluster
is
being
created.
B
Good,
so,
to
add,
to
the
whole
thing,
what
we
saw
was
the
day,
one
in
general,
so
creating
a
cluster
even
creating
thousands
of
clusters
still
is
okay,
but
what
really
happens,
and
what's
really
more
fascinating,
is
what
what's
gonna
happen
on
day,
two
or
day
three
and
so
on.
So
we
are,
we
are
going
to
have,
or
we
already
have,
the
customers
or
the
people
who
would
generally
create
lots
of
lots
of
workloads
on
their
cluster
and
in
such
cases
we
don't
want
our
api
server
to
die.
B
We
don't
want
our
other
control
plane,
components
to
be
exhausted.
So
what
what's
there
to
save
us
is
basically
the
horizontal
vertical
part
autoscaler.
So
what
it
does
is
really
fascinating.
It
auto
scales,
the
pods
control
print
parts,
both
vertically
and
horizontally,
as
situation
demands,
and
then
we
have
fcd
backup
and
restore.
So
this
is
this
is
our
savior
for
the
disaster
and
recovery,
where
this
sidecar
container
basically
keeps
on
taking
the
snapshots
of
the
lcd.
B
Let's
say
every
one
over:
this
is
perfectly
configurable,
so
it
takes
full
snapshot
every
one
over
and
then
it
takes
delta
snapshots
every
few
seconds
and
then
at
any
point
in
time.
If
things
go
south,
it
would
basically
restore
the
entire
cluster
using
the
snapshot
taken
previously,
and
it
would
give
us
kind
of
a
point
in
time,
recovery
of
loss
of
only
a
few
seconds
of
the
data.
The
next
next
one
is
also
my
favorite,
where
gardner
goes
one
step
beyond
and
it
actually
does
the
automatic
seed
provisioning.
B
Now
we,
if
you
look
at
the
design,
we
saw
that
we
assumed
that
there
are
always
x
number
of
management
clusters
available.
But
what
if
we
have
a
certain
increase
in
the
cluster
number
of
clusters
and
someone
just
creates
1000
more
clusters,
and
then
we
don't
have
enough
capacity
in
the
existing
management
clusters.
So
gardner
also
offers
such
features
where
the
new
cluster
is
automatically
new
management.
Cluster
is
automatically
added
and
it
actually.
B
I
would
say,
because
this
cluster,
our
scalar,
basically
always
scales
our
super
management,
cluster
management,
cluster
and
the
actual
shoot
clusters,
and
it
works
in
a
cloud
agnostic
fashion,
as
as
we
discussed
that,
because
it
supports
the
machine
api,
which
is
gardner's
machine
api.
If
it's
it
basically
only
has
a
common
denominator
requirement
that,
if
a
private,
if
a
cloud
provider
has
a
create
machine
and
delete
machine
api
is
implemented
which
is
like
a
bad
bitimum,
then
the
auto
scaler
would
be
able
to
do
its
job
of
auto
scaling.
C
C
Wow
that
was
really
good,
and
so
we
I
already
see
that
we
have
a
set
of
adopters
who
are
running
gardener
and
managing
thousands
of
clusters
at
ease.
So
obviously
at
sap
we
use
gardener
internally
for
development
purposes
and
also
for
production
workloads,
and
it
is
utilized
by
software
developers
and
all
the
line
of
businesses
across
the
globe.
Gardiner
creates
hibernates
scales,
deletes
hundreds
of
clusters
on
a
daily
basis.
C
Gardener
is
operated
by
a
central
platform
team
and
its
premier
usage
within
sap
leads
to
synergies
on
total
cost
of
development
and
reduced
cost
of
operations
in
multi-cloud
environment
gardener
is
also
in
use
by
other
cloud
providers
such
as
fits
who
have
extended
gardener
into
their
metal
stack
and
stack.
I
t
t
systems.
C
23
technologies
applies,
gardner's
multi-provider
feature
for
its
gaia
x,
a
federated
european
sovereign
cloud
initiative,
ping
cap,
the
makers
of
ti
kv
and
tidb
run
their
commercial
database
as
service
offering
on
top
of
gardener
landscapes
and
many
of
the
same
reasons
apply.
Running
critical
applications
and
critical
systems
off
record
requires
you
to
have
complete
access
on
your
control
plane,
and
each
component
of
gardener
is
completely
independently.
C
As
a
user,
you
just
need
to
annotate
or
apply
a
custom
resource
in
your
cluster
to
consume
these
value
added,
but
managed
services
so
think
about
it.
Gardener
has
the
minimum
architecture
that
is
needed
to
provide
all
types
of
related
services.
Thank
you,
stu,
linker
d
or
think
cross
plane
in
a
managed
way.
So
for
us
and
our
community
gardener
is
more
than
just
a
kubernetes
cluster
as
a
service.
B
Hey
and
yeah,
of
course,
towards
the
end
bullseye
question
or
a
million
dollar
equation.
What's
the
relation
with
the
cluster
api,
we
know
what's
clustering,
api,
it's
it's
it's
a
great
community
project
which
has
a
very
similar
purpose
and
we
are
often
asked
about
it.
So,
in
general,
with
the
latest
cluster
api
specification,
it
is
possible
to
delegate
the
specifics
of
cluster
management
to
a
separate
controller,
plane
provider.
B
So
it's
the
extension
model
of
the
cluster
api,
so
there
is
already
a
battery
included,
which
is
cube,
adm
control,
plane
provider
and
that
works
pretty
cool
with
the
dedicated
control
plane
machines,
but
then,
with
the
whole
concept
of
control,
plane,
controllers
being
an
extension.
What
is
the
possibility
or
what
we
are
planning
to
do-
is
basically
to
have
another
control,
plane
provider
provider
which
is
going
to
be
the
gardener
control
control,
plane
provider.
B
B
A
B
B
Through
tucker,
I
can
probably
answer
that
question,
so
his
question
is
that
doesn't
replication
of
management
clusters
across
regions
again
increase
the
cost
factor
just
certainly,
and
I
think
in
the
flow
we
answered
that
already
so
increasing
having
more
management
clusters
has
basically
two
effects.
One
is
the
complexity
of
manage
managing
more
clusters,
one
and
the
other
one
is
the
costs.
The
first
one
is,
of
course
targeted
by
the
super
management
cluster
and
the
second
one
is
targeted
by
having
a
very
well
defined,
auto
scaling
of
the
management
clusters
themselves.