►
From YouTube: Kubernetes Scalability: Federation & Cluster API - Katie Gamanji, Condé Nast International
Description
Join us for Kubernetes Forums 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
Kubernetes Scalability: Federation & Cluster API - Katie Gamanji, Condé Nast International
In the past years, Kubernetes has been the nucleus of container orchestration frameworks. With the growing number of microservices in a cluster, scalability is one of the core pillars for a fault-tolerant application. Additionally, from a technological landscape standpoint, the cloud platform teams are highly focused on delivering scalable, reliable and highly available platforms. Scalability on the Kubernetes clusters can be approached on the application level and cluster level. While the application level scaling techniques (e.g. HPA and VPA) are widely used, Federation v2 and Cluster API are emerging tools that still prove their worth in a production setup.
A
My
name
is
Katie
Comanche
and
I'm
a
club,
but
from
engineer
for
Conde
Nast
around
one
year
and
a
half
ago,
I
joined
Conde
Nast
to
contribute
to
a
project
that
aims
to
create
a
centralized
globally
distributed
platform
at
Husky
Benitez
edit
Center
base.
Today,
however,
I'm
going
to
talk
about
community
scalability,
more
specifically
Federation
and
cluster
API,
and
how
we
integrate
and
prototype
this
tools
within
our
platform,
I'd
like
to
start
today
by
giving
you
an
overview
of
what
containers
does
and
delivers
as
a
product
as
well
as
our
infrastructure
and
our
ecosystem.
A
So
without
any
further
ado,
I
would
like
to
introduce
kinda
NASA
to
you
when
Dennis
has
set
the
benchmark
for
print
and
digital
publishing
for
more
than
110
years.
We
operate
brands
that
are
fashion
or
luxury
oriented,
and
you
might
be
familiar
with
some
of
the
brands
like
vogue,
GQ,
Wired,
Vanity,
Fair,
ATM
anymore.
These
are
just
a
few
of
the
brands
we
have
in
our
portfolio.
Currently
we
have
38
brands
and
we
distribute
them
in
26
languages,
so
quietly
inclusive
range.
We
have
out
there
with
headquarters
in
London
in
New
York.
A
We
operate
in
12
countries
and
have
86
websites.
Overall,
they
generate
more
than
330
million
unique
users
every
single
month,
and
so
far
we
distribute
37,000
articles
to
our
users
every
single
minute.
So
it's
quite
a
considerable
customer
base.
We
have
out
there
now
I've
mentioned
that
we
operate
in
12
markets.
However,
if
you
look
at
the
areas
you
can
see
that
they
quite
you're
graphically
dispersed.
Historically,
all
of
these
regions
had
quite
an
individualized
tech
stack
with
very
little
shared
components
in
between
them.
A
This
includes
the
systems
deliver
the
live
traffic,
as
well
as
the
systems
to
write
and
deliver
the
content.
Never
inconsistency,
which
is
actually
quite
big
for
us,
was
the
visual
in
design.
Has
it
made
difficult
us
to
provide
a
unified
experience
for
all
our
customers,
a
search?
We
kicked
off
a
centralized
digital
transformation
project
that
aims
to
create
a
centralized
platform,
and
we
globally
distributed
across
five
different
regions,
making
a
total
of
nine
clusters.
We
have
free
clusters
in
Europe,
one
in
Tokyo
and
one
in
Mexico.
A
We
have
two
dedicated
clusters
for
China
alone
and
we
have
two
more
clusters
in
Dublin
to
host
our
internal
tools.
However,
if
you
look
at
the
map,
we
can
see
that
we
don't
have
a
replica
of
our
checks
like
in
Russia.
This
is
because
the
current
strategy
is
to
deliver
the
content
from
our
European
servers
while
having
a
CDN
which
is
Russian
oriented.
This
will
ensure
our
service
availability
in
Russia,
while
investing
minimal
engineering
effort.
A
Our
pod
room
is
life
since
October
last
year,
when
it
first
launched
Gigi
France.
Since
then
we
migrated
two-thirds
of
our
Intendant
estate
and
so
far
we
serve
more
than
two
hundred
and
fifty
million
page
views
from
our
back-end
systems.
So
again,
quite
a
considerable
amount
of
requests
to
become
only
accumulated
over
time.
A
Now.
This
is
pretty
much
a
very
quick
overview
of
our
platform
and
I
mentioned
that
we
have
nine
different
clusters.
The
way
we
distribute
our
applications
or
actually
deploy
applications
to
these
clusters
is
to
have
pipelines
with
very
similar
stages,
to
run
in
every
single
region.
Now
it's
not
necessarily
inefficient.
However,
if
you'd
like
to
have
a
change
for
your
pipeline,
you
have
to
do
it
in
every
single
region
as
well,
which
is
quite
tedious
to
maintain,
and
we
started
to
think.
A
Is
there
a
way
to
have
a
more
centralized
mechanism
to
deploy
our
applications
and
assemble
the
cross
federation
between
now?
What
Federation
is
aids,
a
mechanism
to
manage
application
and
services
in
multiple
clusters?
One
point
I
would
like
to
take
across
Federation
is
not
about
cluster
management
Federation.
It's
about
application
management
and
I'm.
Gonna.
Repeat
this
over
and
over
again
today,
I
think
when
you're
talking
about
Federation,
we
talked
about
signal
multi
cluster,
which
is
in
v2
and
requires
a
IQ.
Bridgette
is
one
third
team
to
run.
A
Viju
means
that
there
was
a
v1
at
some
point.
What
actually
tried
to
do
in
v1
was
to
wire
the
code
for
Federation
within
the
Copernicus
codebase.
This
was
very
efficient
because,
most
of
the
time
they
had
to
keep
up
with
all
the
releases
and
the
changes
in
the
code
base,
so
they
changed
the
purge
completely
in
Vichy
they
using
the
building
block
principle,
which
makes
the
best
use
of
customer
source
definition
and
another
project
I'm
going
to
talk
about
today
from
the
cig.
Multi
cluster
is
cluster
registry.
A
Now
cluster
registry
is
very
tightly
coupled
to
Federation
and
it
is
a
tool
that
has
all
the
information
and
associated
metadata
to
connect
to
the
clusters
I'm
going
to
talk
about
this
later
on
as
well.
So
let's
look
at
how
Federation
works.
Supposedly
you
have
already
a
motion
of
clusters,
different
regions,
potentially
different
infrastructures
provider.
A
The
way
Federation
works
is
going
to
have
a
host
cluster
and
every
other
cluster
is
going
to
be
perceived
as
a
member
cluster
on
the
host
cluster,
we
require
the
cluster
registry
installed,
as
well
as
the
Federated
ap
is
the
cluster
registry.
A
summation
is
going
to
have
all
the
information
required
to
connect
to
the
member
clusters
and
the
Federated
API
actually
needs
to
run
a
lock
on
the
control
plane
to
make
sure
we
have
all
the
controllers
to
reconciliate
the
federated
resources.
A
In
a
nutshell,
the
host
cluster
is
going
to
be
the
control
plane
and
it's
gonna
push
configuration
to
the
member
clusters.
I
would
like
to
focus
slightly
bit
more
on
the
manifest
of
Federation.
Now
there
are
two
more
bits
of
information.
We
require
the
cluster
placement
and
the
configuration
of
writes
with
a
class
two
placement.
We
say
where
we
want
our
application
to
run
and
the
configuration
overrides
we
can
tailor
every
single
application
to
the
cluster.
Let's
look
a
bit
more
in
details
for
them.
A
A
We
have
an
option
for
cluster
selector
as
well,
which
makes
the
best
use
of
the
labeling
system
in
Cuba
90s,
which
is
actually
quite
powerful.
The
cluster
selector
would
say
we
want
to
run
this
application
on
a
cluster
resources
on
a
class
to
research
that
matches
this
label.
So
in
this
particular
case,
we
have
a
label
region,
use,
u
central
1,
which
means
we
want
to
an
allocation
in
Europe
only.
It
is
worth
to
mention
that
cluster
and
gloucester
selector
can
be
specified
both
for
them.
A
At
the
same
time,
however,
cluster
is
going
to
have
precedence
of
a
cluster
selector,
just
to
find
the
table
to
keep
in
mind
in
terms
of
the
configuration
overrides,
we'll
be
able
to
patch
add
or
remove
any
configurations,
one
for
an
application.
In
this
particular
case,
we
say
where
we
want
up
the
change
to
happen
and
to
which
resource
so
I
say
in
cluster.
One
do
overwrite
the
amount
of
replicas
to
five.
This
is
going
to
make
a
bit
more
sense
when
you
look
at
the
entire
manifest
for
a
federated
deployment.
A
So
this
is
how
federated
deployment
looks
like
in
this
back
section.
It's
similar
to
deployment
so
I
completely
committed
that
no
change.
Is
there,
however,
going
to
have
the
two
points
of
information?
We've
talked
about
the
placement
and
the
overrides.
So
what
we
say
here
is
we
want
an
engine,
X
deployment,
and
you
want
this
deployment
to
run
in
cluster
2
and
cluster
1
and
1
and
overwrite
of
on
the
Mount
of
replicas
to
7,
and
this
is
going
to
be
in
cluster
to
the
end.
Result
is
going
to
be
we're.
A
A
Can
everyone
see,
hopefully
so
what
I
actually
have
here?
I
already
have
two
federated
clusters:
cluster
1
and
cluster
2,
and
they
are
in
a
ready
state
which
means
I
can
propagate
configuration
to
them.
So
in
today's
demo,
what
I'm
actually
going
to
show
you
is,
how
can
they
figure
it
a
namespace,
and
how
can
I
deploy
a
federated
deployment
with
different
configuration?
First
of
all,
let
me
see
where
I
am.
A
A
Now,
if
I
do
a
cube
CTL
in
my
cluster,
one
I'll
be
able
to
say
test
namespace,
which
is
pretty
much
the
basic
one
and
I
would
like
to
federated
if
I
issue
the
same
command
in
cluster,
two
I
will
have
not
test
namespace
to
do
that.
I'm
gonna
do
play
my
federated
namespace
resource,
so
I'm
gonna
do
a
cube.
Ctl
apply,
F,
federated
namespace
now
once
has
been
created
in
cluster
2
I
should
be
able
to
see
a
new
namespace
which
has
been
federated
now.
A
The
commands
I'm
issuing
is
from
class
2
1
class
2
1
is
my
control
plane.
Now,
let's
look
at
something
a
bit
more
complex.
Let's
look
at
a
federated
deployment,
so
a
manifest
file
for
that
is
gonna.
Look
something
like
this,
it
can
see,
can
seem
quite
verbose,
but
what
we
actually
do
here
is
we
deploy
an
engine
X
deployment
and
we
want
free
replicas
for
it.
A
What
I
would
like
to
draw
your
attention
towards
is
the
placement,
so
we
say
again
in
cluster
1,
&
2
and
in
the
override
so
actually
have
a
few
more
details.
We
want
to
tailor
so
we
say
in
cluster
2
how
five
replicas,
instead
of
free,
do
run
a
diff
nginx
image
so
is
going
to
be
117
instead
of
the
latest
Angelique's
image
and
we
add
an
annotation
as
well.
So
let's
actually
deploy
that
to
TTL
apply
my
federated
deployment
so.
A
What
I'm
gonna
do
I'm
gonna
get
all
my
deploys
in
the
test.
New
space
in
cluster
I
have
five
replicas
in
class.
One
I
have
free
replicas
great.
Now,
let's
look
at
the
image
tag
as
well.
So
if
I
get
a
llamo
output
of
vase
and
I
grab
the
image
in
cluster,
one
I
see
I
have
just
the
latest
nginx
image
and
if
I
shoot
the
same
command
in
class
here,
I'll
be
able
to
see
that
I
run
a
117
instead.
So
this
is
how
we
tailor
it,
but
we
added
actually
an
annotation.
A
So
let's
look
at
the
annotation
as
well,
so
in
question,
one
I'm
gonna,
look
at
all
the
annotations
and
I'm
gonna
grab
a
few
lines
after
what
I
have
is
just
an
automatic,
well,
a
default
annotation
added
to
the
deployment,
which
is
the
revision
and
if
I
issue
the
same
command
in
cluster
two
I'll
be
able
to
see
that
I
have
an
annotation
which
is
fubar,
which
we
actually
added
ourselves.
So
this
is
like
a
very
quick
demonstration
of
how
Federation
works.
A
But
more
importantly,
how
can
you
tailor
your
application
to
the
cluster
if
need
be
before
I
move
forward?
I
would
like
to
leave
you
with
a
few
takeaways
about
Federation.
Now
Federation
is
about
resource
management.
It
is
not
about
cluster
management.
It
is
quite
an
important
thing
to
keep
in
mind
with
Federation,
actually
have
a
new
feature,
which
is
the
namespace
of
scope,
control
plane
in
the
actual
demo.
A
It's
a
great
feature
to
use
any
production
if
you'd
like
tests,
Federation
conditional
scalability,
it's
quite
tricky,
but
it's
worth
to
mention
here
is
that
the
source
of
truth
for
a
deployment
it's
going
to
be
within
the
federated
deployment,
not
within
the
cluster,
so
want
to
create
a
new
deployment
with
amount
of
replicas,
and
we
have
an
HP
object
that
value
of
the,
for
example,
if
you
scale
out
the
application
for
the
HP
object,
that
value
is
not
going
to
be
retained.
However,
Federation
allows
you
to
do
that
through
like
so.
A
It
is
possible,
but
you
have
to
be
mindful
of
that,
and
another
important
thing
about
Federation
is
the
higher-level
behavior.
Now
this
is
something
which
is
quite
a
powerful
feature
that
comes
across
the
multitude
of
clusters.
It
comes
with
a
very
sophisticated
scheduling
mechanism
which
can
comply
with
requests
such
as
I
want
to
run
1,000
replicas
of
my
application
at
all
time.
Now,
if
a
cluster
goes
down,
the
scheduling
will
be
able
to
identify
that
we
don't
have
enough
replicas
and
it
will
schedule
them
on
the
available
clusters.
A
This
is
a
great
mechanism
for
failover,
as
well
as
you'd
like
to
migrate.
Applications
between
the
clusters
and
another
high-level
behavior,
which
is
quite
important
for
Federation,
is
the
ingress
and
DNS.
When
you'll
try
to
access
the
application,
it
will
actually
return
you
all
the
endpoints
available
from
all
the
clusters.
A
Now
we
have
been
talking
about,
we
have
been
talking
about
application
management
of
multiple
clusters
at
cleanliness.
We
started
to
think
how
can
we
create
clusters
more
efficiently
because
we
have
quite
a
few
of
them
and
we
actually
going
to
extend
our
platform
even
more,
and
we
need
a
more
efficient
way
to
create
our
clusters,
but,
more
importantly,
to
be
cloud.
Agnostic
and
I'm
gonna
explain
why
now
Qube
anita's
underpins
the
entire
infrastructure,
conde
nast.
That
means
that
it's
gonna
be
the
core
component
of
our
platform.
A
We
are
a
Korres
house,
meaning
that
we
using
tectonic
installer
for
our
cluster
deployment
and
using
HCT
for
the
storage
of
our
cluster
data
using
tectonic
allows
us
to
plug
in
into
different
cloud
providers
while
consuming
the
computer
network
networking
resources.
As
such,
we
deploy
100%
open
source
communities
in
a
multi
master,
multi
node
fashion.
A
Now,
I
would
like
to
focus
on
China
and
Russia
I'm
from
this
a
country
salon.
We
have
16
million
unique
users
every
single
month
and
they
represent
20%
of
our
entire
digital
leadership.
However,
deploying
infrastructure
to
countries
like
Russia
and
China
can
be
quite
challenging
from
an
infrastructure
standpoint.
When
we
kicked
off
the
project
for
a
global
transformation,
we
did
not
have
a
clear
vision
of
one
cloud
provider,
there's
going
to
be
used
for
all
platforms
and
all
as
such,
this
enforces
our
decision
to
go
for
self-hosted
kubernetes
solution.
A
This
means
that
we're
gonna
manage
our
own
clusters
and
with
not
gonna
outsource
days
to
a
third
party,
and
another
thing
I'd
like
to
draw
your
attention
towards
are
the
capabilities,
bootstrap
tools
we
have
plenty
of
them
available.
At
the
moment
we
have
cube
ADM
cubes
break
ups
tectonic.
Would
you
actually
use
in-house?
However,
if
you
look
at
every
single
tool,
they
will
support
a
specific
cloud
provider.
They
will
not
support
all
of
them.
A
So
if
you're
looking
down
to
a
tool,
then
you
look
down
to
a
specific
amount
of
infrastructure
providers
that
you
can
deploy
your
infrastructure
into
as
well.
In
our
case,
tectonic,
for
example,
is
no
longer
under
active
development.
Any
stock
shall
be
merged
with
open
shift
container
platform.
We
need
to
think
about
how
we're
going
to
deliver
our
cluster
in
the
future
in
a
different
way.
Hence
we
stumbled
across
cluster
API,
which
is
a
tool
that
provides
a
unified
set
of
API
to
manage
the
creation,
deletion
management
and
main
maintenance
of
the
cluster.
A
Now,
when
we
talk
about
cluster
API,
I
would
talk
about
sig
cluster
lifecycle,
which
has
its
first
initial
release
in
April
this
year,
so
it's
been
around
for
half
a
year,
not
too
long.
It's
currently
in
V,
1,
alpha,
2
and
very
soon,
very
soon
to
be
in
V
1,
alpha
3,
with
a
bunch
of
new
features.
Actually
now,
when
we
talk
about
cluster
API,
we
talked
about
this
common
interface
to
integrate
with
different
infrastructure
providers
by
having
minimal
changes
to
your
manifests.
A
So
currently
we
have
there's
a
bunch
of
cloud
providers
in
collaboration
of
cost
or
API
such
as
Google
cloud
AWS
vitae
cloud,
which
is
a
Chinese
provider.
So,
if
you'd
like
to
deploy
our
infrastructure
to
China,
we
do
that
with
minimal
changes
to
our
manifest.
We
have
a
bare-metal
digitalocean
and
many
more.
The
list
goes
on
now.
Let's
look
at
how
exactly
cluster
API
works.
Supposedly,
we
would
like
to
create
a
number
of
clusters
in
different
regions,
different
infrastructure
providers.
The
way
this
is
going
to
happen
will
require
a
management
cluster
for
testing
purposes.
A
You
can
use
kind,
which
is
an
easy
and
straightforward
way
to
create
a
coupon
using
a
docker
kind
of
cluster,
but
his
great
talk
shall
start
testing
with
cluster
API.
If
you'd
like
to
use
class
repair
in
production,
then
it's
recommended
to
use
a
production
running
cluster
as
well
to
have
a
more
failover
and
complex,
more
complex,
failover
strategy.
Now
there
is
a
dependency
dependency
will
require
on
the
management
cluster.
Those
are
the
controller
managers.
Let's
look
a
bit
more
into
them.
A
There
are
minimum
free
control
managers
you
require
for
your
cluster
API
process
to
be
working.
First
of
all,
you
require
the
cluster
API.
You
see
RDS.
These
are
going
to
be
the
cluster
machine
machine
set
and
machine
deployment.
There
are
four
of
them,
but
they'll
actually
ensure
this
higher
level
kind
of
layer
of
configuration
of
for
your
clusters.
Secondly,
will
require
a
bootstrap
provider.
Currently
we
have
cube
ADM
and
Talas
being
supported.
A
Now
this
particular
provider
is
going
to
ensure
that
an
instance
in
AWS,
which
you
see
P
or
n
out
of
a
cloud
provider,
is
going
to
be
added.
So
you
think
you
bring
this
cluster
as
a
node
so
and
if
quite
a
powerful
integration
over
there
and
lastly,
will
actually
require
the
infrastructure
provider.
This
is
going
to
be
responsible
to
interact
with
the
API
and
provision
actual
infrastructure,
such
as
instances
V,
pcs
subnets.
A
Whatever
it's
out
there
once
we
have
our
dependency
in
the
management
cluster,
we'll
be
able
to
provision
our
target
clusters
so
from
one
cluster
we'll
be
able
to
create
as
many
as
we'd
like
and
I
think
yeah.
Another
thing
I'd
like
to
focus-
and
this
is
gonna-
be
quite
important
during
the
demo,
which
is
gonna,
be
just
in
a
couple
of
minutes.
We
have
four
surges
I
mentioned
them.
Cluster
machine
machine
set
and
machine
deployment
with
glass
tier
we're
gonna.
A
Have
this
higher
level
configuration
available
for
for
provisioning
our
our
cluster,
so
we're
gonna
have,
for
example,
the
subnets
flower,
pods
or
services
machine
configuration
is
going
to
be
very
similar
to
an
instance
configuration
so
be
able
to
specify
the
version
of
kubernetes.
We
want
to
run
the
type
instance
for
different
infrastructure
provider,
ridging
I'm
roles
and
so
forth.
We're
gonna
look
a
bit
more
in
details.
A
Machine
set
is
going
to
be
very
similar,
it's
very
similar
to
replica
set,
meaning
that
we're
gonna
ensure
that
an
amount
of
machine
resources
are
going
to
be
up
and
running
at
all
time,
and
machine
deployment
is
very
similar
to
deployment.
Now
is
going
to
ensure
that
we
have
a
very
powerful
rolling
strategy
for
our
mission
resources.
Now,
let's
look
a
bit
more
in
details
of
how
cluster
ipi
works,
and
I
think
I
have
enough
time
as
well.
A
So
what
I
actually
have
here
I
would
like
to
draw
your
attention
to
the
first
three
pots.
These
are
my
controller
managers.
The
names
are
actually
shortened,
so
maybe
not
that
straightforward.
The
first
one
is
the
bootstrap
provider
which
I'm
using
cube
ADM.
The
second
one
is
the
AWS
provider
and
the
third
one
is
the
cluster
API
stereo
disk
controller
I
have
all
of
them
up
and
running.
Now.
What
am
I
going
to
do.
A
I've
already
provisioned
my
cluster
and
I'm
gonna.
Let's
look
at
how
the
cluster
configuration
is
going
to
look
like.
So
if
you
look
at
our
class,
the
configuration
for
AWS,
it's
very
straightforward,
I'm
going
to
have
a
cluster
resource
and
I
say
I
want
this
particular
subnet
for
our
pods
as
well.
Here
we
have
our
infrastructure
provider,
which
is
in
AWS,
and
here
we
specify
the
region
as
well
as
any
SSH
keys.
We
want
to
attach
to
our
instance.
A
This
is
going
to
be
a
bit
more
verbose,
but
this
is
going
to
be
how
we
actually
configure
our
instance.
So
what
I
actually
have
here?
I
have
a
machine
instance
and
I
just
say:
I
want
to
run
kubernetes
one
15.3,
and
these
are
two
references.
So
here
we're
going
to
have
the
bootstrap
provider
configuration
and
the
infrastructure
configuration.
A
These
are
just
references
because
they're
going
to
be
defined
later
on.
So
if
I
look
at
my
bootstrap
configuration,
it's
very
verbose,
but
I'm
gonna
enjoy
your
changes
to
this.
This
particular
thing.
What
we
have
here
is
cube
ADM
config,
and
we
actually
invoke
an
init
configuration
when
we
want
to
add
multiple
other
nodes,
we're
going
to
invoke
a
join
operation
from
cube,
ADM
and
the
in
the
infrastructure
provider.
We
say
that
we
want
our
instance
to
be
active
large.
A
We
want
to
have
an
iron
roll
attached
to
the
particular
instance
and
want
to
touch
a
specific
SSH
keep
here
now.
Let's
apply
this
particular
resource,
so
I'm
going
to
do,
keep
CTL
apply
our
control
plane.
Now,
if
I
take
your
CTL
get
clusters,
I
have
one
provisioned,
which
already
mentioned
that
I've
provisioned
with
the
previous
manifest.
If
I
do
a
cube,
CTL
get
machine
resources
which
we've
just
deployed.
We
actually
see
that
it's
pending.
A
So
ideally
at
some
point,
if
my
aw
session
console,
they
still
have
a
running
we'd
be
able
to
see
a
new
instance
appearing
over
here
at
some
point
it's
still
pending.
Well,
unfortunately,
I
don't
have
time
but
I'm
more
than
happy
to
go
in
more
details,
wave
a
full
demo
for
cluster
API
as
well.
You
can
visit
the
link
provided
here,
which
is
a
recorded
demo
of
how
to
provision
two
clusters,
one
in
docker
in
one
a
double
yes
in
less
than
ten
minutes,
I'm
gonna
move
forward.
Unfortunately,
the
time
is
quite
short.
A
Today,
I'm
gonna
leave
you
for
a
few
takeaways
about
cluster
API.
Now
clustering
PAC
has
been
around
for
half
a
year,
but
it's
been
so
successful
and
effective.
It
cause
accuses
the
building
block
principle.
It
makes
this
the
best
use
of
customer
service
definition
and
it
doesn't
actually
create
a
new
way
to
provision
clusters.
Another
feature
about
cluster
API,
which
makes
it
so
important
for
us.
A
It
is
the
fact
that
it's
cloud
agnostic
now
this
will
allow
to
have
this
common
interface
to
plug
into
different
infrastructure
providers,
while
having
minimal,
very
minimal
changes
to
your
manifest,
but
you'll
have
to
change.
Usually
is
just
your
infrastructure
reference,
so
from
AWS,
you're,
gonna
put
it
in
docker
or
JCP,
and
the
last
thing
about
cluster
API
is
still
experimental.
If
you
have
a
use
case
for
it,
please
use
it
and
please
feedback
to
the
community.
A
Now
is
the
time
to
actually
with
tailor
cluster
API
to
you
to
your
use
cases,
and
the
same
goes
with
Federation,
please,
the
feedback
to
the
community
I
have
written.
Actually,
this
is
going
to
be
a
very
quick
overview.
I
have
written
two
articles
about
Federation
and
cluster
API,
which
will
help
you
to
get
started.
Please
go
there,
there's
actual
practical
bids
that
would
help
you
to
get
started
with
it.