►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
ClusterAPI: A Guide to Get Started - Katie Gamanji, American Express
In the past years, Kubernetes has been the nucleus of container orchestration frameworks. With the growing number of microservices, managing clusters at scale has become an imperative requirement. Additionally, from a technological landscape standpoint, the cloud platform teams are highly focused on delivering scalable, reliable and highly available platforms. At Condé Nast, this constitutes in having a stable and coherent approach to deploy, manage and upgrade multiple Kubernetes clusters that are distributed globally. Also, it is imperative to keep the life-cycle management of the clusters consistent across all regions. Henceforth, this talk aims to present an overview of how Condé Nast prototypes tools, such as ClusterAPI, to ensure a sustainable cluster provisioning mechanism.
https://sched.co/Zenm
A
Hello:
everyone,
my
name,
is
katie
gamanchi
and
I'm
one
of
the
cloud
platform
engineers
for
american
express,
I
joined
american
express
around
six
months
ago
and
I'm
part
of
the
team
that
aims
to
transform
the
current
platform
by
embracing
the
cloud
native
principles
and
making
the
best
use
of
the
open
source
tools
as
well.
Quite
recently,
I've
been
elected
as
one
of
the
toc
the
technical
oversight
committee,
member
for
the
cncf,
alongside
10
other
champions
within
the
open
source
community
I'll,
be
responsible
to
steer
and
maintain
the
technical
vision
for
the
cncf
landscape.
Pretty
much.
A
Before
I
move
forward,
I
would
like
to
introduce
the
ecosystem
that
allow
cluster
api
to
be
developed.
Now,
if
you
look
six
years
ago,
the
container
orchestrated
framework
space
was
very
heavily
diversified.
We
had
tools
such
as
docuswear,
apache
messages,
queries,
fleet,
kubernetes
and
all
of
them
provided
a
viable
solution
to
run.
Containers
at
scale
over
in
the
last
year's
kubernetes
took
the
lead
in
defining
the
principles
of
how
to
run
these
containerized
workloads.
A
Nowadays,
kubernetes
is
known
for
its
portability
and
adaptability,
but,
more
importantly,
for
its
approach
towards
the
clarity
of
configuration
and
automation,
and
this
has
been
extremely
beneficial
for
kubernetes,
because
over
time
a
community
flourished
around
it.
Based
on
the
cncf
survey
in
2019,
more
than
50
percent
of
the
circuit
companies
are
using
kubernetes
in
production.
A
When
we
transition
towards
the
development
community,
more
than
2
000
engineers
are
actively
collaborating
towards
future
build
out
and
bug
fixing
and
when
you're,
looking
to
the
end
user
community,
more
than
23
000
attendees
were
registered
at
the
cubecons
around
the
world.
Now,
there's
going
to
be
kubecon
in
europe,
china
and
north
america-
and
this
has
been
extremely
beneficial
for
kubernetes,
because
over
time,
multiple
tools
were
built
around
it
to
extend
its
functionalities,
and
this
created
what
today,
we
know
as
the
cloud
native
landscape
which
resides
under
the
cncf
umbrella.
A
If
you
look
into
the
ecosystem,
as
mentioned,
there
are
plethora
of
tools
provisioning
this
capability,
some
of
the
most
widely
tools
are
such
as
cube,
atm
cube
spray,
cops
tectonic
and
many
more.
However,
if
you
look
into
every
single
tool,
it's
going
to
be
difficult
for
us
to
find
a
common
denominator.
A
A
Now
a
challenge
is
imposed
if
you'd
like
to
migrate
to
a
different
tool
altogether,
for
example,
tectonic,
which
I
introduced
earlier,
is
no
longer
under
active
development,
and
it
is
to
be
merged
with
openshift
container
platform.
That
means
that
moving
forward,
one
solution
is
to
work
the
project
and
maintain
it
in-house
or
you'll
have
to
choose
a
different
tool,
which
means
that
you'll
have
to
write
infrastructure's
code
from
scratch.
A
Usually
we
lose
this
shift
and
lift
and
shift
capabilities,
and
we
have
to
create
a
snowflake
infrastructure
in
these
regions.
However,
cluster
api
intercepts
all
of
these
challenges
and
provisions
a
set
of
declarative
apis
that
will
allow
the
cluster
creation,
configuration
and
management
and,
more
importantly,
it
will
integrate
with
different
cloud
providers.
A
A
A
A
A
A
The
second
component,
with
the
second
controller,
is
going
to
be
the
bootstrap
provider,
and
this
is
going
to
be
the
component
which
will
translate
the
yaml
configuration
into
cloudiness
script,
and
it
will
make
sure
to
attach
an
instance
from
any
cloud
provider
to
the
cluster
as
a
node.
Currently,
this
capability
is
provisioned
by
qpdm
intellis
and
the
last
set
of
controllers
will
require
are
going
to
be
the
infrastructure
providers,
and
this
is
the
particle
which
actually
interacts
with
the
apis
directly
and
provisions
the
infrastructure,
such
as
instances
subnets
iron
rolls
vpc
subnets
and
many
more.
A
I
deserve
to
mention
that,
if
you'd
like
to
create
a
cluster
in
multiple
cloud
providers,
you'll
require
a
controller
for
every
single
cloud
provider
as
well,
and
once
we
have
our
dependencies
we'll
be
able
to
provision
our
target
clusters,
and
these
are
going
to
be
the
clusters.
We
will
deliver
to
our
engineers
to
put
their
application
on,
and
these
are
going
to
be
the
clusters,
the
consumers
or
our
users
are
going
to
connect
to
interactive
file
application
now,
as
mentioned
previously,
cluster
api
introduces
five
new
resources,
cluster
control,
plane,
machine
machine
set
and
machine
deployment.
A
The
cluster
resource
is
going
to
be
taken
care
of
mostly
of
the
networking
components
of
our
cluster,
we'll
be
able
to
specify
settings
such
as
the
slider
for
our
services
and
pods
as
well.
Any
dns
suffix,
if
you
have
it,
the
control
plane,
is
a
new
resource
which
has
been
introduced
in
the
last
release.
So
the
third
release-
and
it
provides
a
declarative
way
to
manage
your
control
plane
or
the
set
of
masters
machine
configuration,
is
going
to
be
very
similar
to
node,
we'll
be
able
to
specify
the
version
of
kubernetes
would
like
to
run.
A
However,
we'll
be
able
to
attach
information
such
as
the
instance
type.
The
region
you'd
like
to
run
this
machine
name
if
you'd
like
to
attach
any
ssh
keys
and
so
forth,
machine
set
is
going
to
be
very
similar
to
replica
set.
It
will
make
sure
that
we
have
an
amount
of
machine
resources
up
and
running
at
all
time,
and
machine
deployment
is
very
similar
to
deployment.
It
actually
comes
with
a
very
powerful
rolling
out
strategy,
making
sure
that
we
can
reconcile
any
changes
to
our
machines.
A
It
is
worth
to
mention
that
the
machine
resource
is
immutable.
Now,
if
you
have
new
configuration,
the
instances
of
the
resources
with
the
old
configuration
are
going
to
be
taken
down
and
the
new
instance
with
the
new
configuration
is
going
to
be
brought
up.
There
is
no
patching.
There
is
only
immutability.
A
A
A
If
you'd
like
to
create
a
cluster
in
ews,
this
is
going
to
be
the
manifest
you're
going
to
be
requiring
here.
We
have
a
cluster
resource
in
beyond
alpha
free
endpoint
and
in
the
specs
section
we
just
choose
a
slash
16
subnet
for
our
pods
as
well.
We've,
as
mentioned
with
the
new
version,
we're
going
to
have
a
control,
plane
reference.
You
can
see
that,
towards
the
end
of
the
manifest,
however,
I'd
like
to
draw
your
attention
towards
the
infrastructure
reference,
because
this
is
the
configuration
which
will
interact
with
our
cloud
provider.
A
A
A
A
So
far,
we
just
created
our
cluster
resource
to
have
a
fully
working
target
cluster.
We
will
require
to
actually
have
our
control
plane,
which
is
already
associated
with
our
cluster,
so
with
the
control
plane,
we're
going
to
have
all
our
masters
already
managed
and
of
course
we
require
our
data
plane,
and
this
can
be
represented
by
a
machine
deployment
which
is
just
going
to
take
care
of
a
collection
of
machines.
We
will
define,
and
the
last
concept
I
would
like
to
introduce
is
how
can
we
use
cluster
api
with
the
github's
model?
A
Now
the
most
powerful
concept
cluster
api
actually
introduces
is
that
we
can
think
about
our
clusters
this
resource.
We
can
fully
translate
that
in
yaml
configuration
if
we
have
yaml
configuration,
that
means
that
we'll
be
able
to
have
it
stored
engaged,
so
we're
going
to
have
a
version,
a
control
around
the
versions
and
the
history
of
these
resources
and,
more
importantly,
we'll
be
able
to
introduce
a
layer
of
templating.
A
And
usually
this
is
provisioned
by
configuration
managers
such
as
helm
and
customize,
and
once
we
have
these
two
components,
such
as
gate
and
configuration
managers
by
default,
we'll
be
able
to
make
use
of
a
tool.
A
github
store,
we're
currently
provisioned
by
argo,
cd
or
reef,
actually
flux
provisioned
by
weaveworks.
A
A
So
this
is
the
clustering
by
github
suppose
tree
in
the
template,
I'll
be
able
to
have
all
my
customer
service
definitions.
I'm
gonna
have
my
cluster
resource,
which
we
actually
went
through
the
previously
in
the
slides.
So
again,
I'm
just
choosing
a
cider
for
my
pods,
I'm
having
a
reference
to
an
aws
clusters
and
so
forth,
but,
more
importantly,
as
you
might
notice,
this
is
already
a
helm
chart
and
I
have
already
templating
enabled
on
it.
A
As
such.
I
think
if
I
go
to
deployment
notes,
I
think
that's
going
to
be
a
better
example.
What
I
actually
have,
for
example,
you
can
see
that
I
can
template
the
version
of
kubernetes.
I
have-
and
this
is
a
very
specific
way
for
helm-
to
actually
consume
these
values
or,
for
example,
I
can
template
the
amount
of
replicas
or
the
amount
of
nodes
I'm
going
to
have
in
my
cluster
and
just
to
showcase
the
values
file.
A
A
So
now,
when
I'm
actually
going
back
to
my
argo
cd
view,
I'm
going
to
trigger
a
lookup,
so
it's
actually
going
to
look
into
the
repository.
It
will
see
that
we
have
a
new
value
for
our
work
nodes
amount
and
once
it's
try
to
actually
synchronize,
hopefully
soon
we'll
be
able
to
see
that
the
amount
of
replicas
of
the
machines
will
increase.
A
Cool,
yes,
as
you
can
see,
we
have
new
machines
actually
being
provisioned.
If
you
go
back
to
our
cluster,
we
see
that
three
new
machines
are
actually
to
be
provisioned
and
the
most
important
thing.
If
you're
looking
to
aws
as
well
console
we'll
be
able
to
see
that
we
have
3
new
machine
actually
being
initialized,
and
this
is
a
very
powerful
concept,
because
we
really
can
automate
the
entire
process
of
creating
a
cluster,
and
we
really
can
treat
our
clusters
as
cattle
rather
than
pets.
We
can
recreate
it
with
minimal
ease.
A
A
Another
important
feature
about
cluster
api
is
the
fact
that
it's
cloud
agnostic.
It
truly
provides
this
one
interface,
which
will
allow
us
to
integrate
with
different
cloud
providers
but,
more
importantly,
to
use
and
reuse
our
manifest
all
the
way
through
and
last
thing
I
would
like
to
mention
about
cluster
api
is
currently
under
extreme
active
development.
If
you
have
a
use
case
for
cluster
api,
please
give
it
a
try
and
feedback
to
the
community.
Now
is
the
perfect
time
to
customize
cluster
api
to
use
case.
A
If
you'd
like
to
know
or
to
find
more
technical
details
of
our
cluster
api,
I
did
collaborate
with
one
of
the
maintainers
for
cluster
api
to
provision
to
provide
actually
a
cncf
webinar.
So,
if
you'd
like
to
understand
cluster
api
from
a
maintenance
point
of
view,
please
visit
or
watch
the
webinar
over
there
as
well.
I
have
written
an
article
with
more
details
of
how
can
you
actually
start
playing
with
cluster
api
and
experiment
with
that?
A
A
A
A
So
a
couple
of
questions
which
actually
stood
out
where
the
question
about
when
cluster
api
is
going
to
be
beta
or
ga.
Now
there
are
some
currently
cluster
is
in
v1,
alpha
3
and
in
the
new
release,
they're
actually
trying
to
move
to
a
more
stable
version.
It's
actually
stable,
it's
just
in
production,
but
to
actually
gain
that
status.
I
think
it's
something
which
is
going
to
happen
in
the
next
next
release
of
the
next
couple
of
releases,
so
it's
definitely
on
their
radar.
A
Another
question
which
actually
was
an
underlying
thread
here,
so
the
question
is
related
to
things.
For
example,
we
already
have
cloud
providers
and
a
native
way
for
them
to
provision
kubernetes
clusters
such
as
gke
aks
eks.
What
is
the
benefit
of
cluster
api
instead
of
standard
infrastructure
as
code
framework?
Now?
This
is
pretty
much
a
more
kind
of
complex
answer.
Cluster
api
tackles
a
few
challenges.
A
If
you
don't
want
to
be
locked
into
a
specific
vendor,
then
you
might
consider
cluster
api
as
a
solution
for
you,
because,
if
you're
going
to
use,
for
example,
gk
or
eks,
if
you'd
like
to,
for
example,
for
cost
reasons,
you'd
like
to
transition
to
a
different
public
cloud,
that's
going
to
be
a
bit
more
difficult.
You'll
have
to
recreate
your
clusters
from
scratch
infrastructures
code
as
well
and
as
well.
You
will
not
be
able
to
migrate
your,
for
example,
gketer
for
two
and
I
don't
know
eks.
A
So
it's
gonna
be
quite
quite
a
different
approaches
to
do
that
with
cluster
api.
We
actually
have
this
consistent
amount
of
manifests
that
we'll
be
able
to
use
throughout,
and
this
is
pretty
much
one
of
the
it's
kind
of
highlight
of
why
it's
such
an
important
tool,
because
if
you
have
one
interface
to
plug
it
into
different
cloud
providers
and
you
can
reuse
the
manifests
as
well,
so
infrastructure
is
code
and
it's
something
you
can.
It
is
just
a
fundamental
and
you
can
build
on
top
of
it.
A
A
Another
question
which
was
actually
quite
interesting
is
since
we
have
a
special
relation
to
the
demo,
since
we
actually
have
our
declarative
approach
for
the
amount
of
replicas
we
have
in
the
cluster,
so
with
the
get-ups
model,
we'll
be
able
to
set
the
amount
of
workers
and
amount
of
masters.
How
does
that
interact
with
cluster
autoscaler
and
which,
which
actually
is
going
to
determine
the
machine
number
now?
This
is
something
which
is
still
worked
on
because,
currently
with
the
clustering
by
context,
we
do
not
have
that
automated
cluster
or
the
scalar.
A
So,
for
example,
if
you
want
to
use
that
with
aws,
you
have
to
integrate
with
aws
specifically
and
actually
provide
all
the
credentials
for
you
to
identify
how
many
numbers
of
how
many
replicas
of
your
machines
you
require.
Currently
this
is,
I
know
this
is
like
a
feature
they're
working
on,
but
currently
at
the
moment,
it's
something
which
is
done
manually
mainly
to
actually
set
your
amount
of
machines.
A
A
A
A
A
A
How
reliable
is
to
use
cluster
api
in
production
so
currently
they're
in
a
cluster
api
is
mainly
maintained
by
vmware
talking
to
the
maintainers.
They
already
have
teams
which
are
using
those
cluster
api
to
provision
production
clusters,
so
there
are
use
cases,
but
definitely
I
I
encourage
people
if
you
actually
have
a
use
case,
try
it
and
do
feedback,
because
we
really
require
that
insightful
information
of
how
different
teams
in
different
contexts
are
using
cluster
api
right.
A
How
does
management
cluster
relate
to
the
target
clusters,
so
this
is
like
a
quite
a
new
concept
introduced
by
cluster
api,
because
you
have
this
inception
model.
You
require
a
small
cluster,
just
like
this
incipient
cluster,
to
create
clusters
in
different
cloud
providers.
Whatever
you
want,
so
the
target
clusters
are
going
to
be
the
clusters
you're
going
to
be
provisioned
to
your
developers.
A
They
are
the
cluster
who's
going
to
hold
your
applications.
These
are
like
the
final
thing,
the
result
with
the
management
cluster.
That's
why
you
can,
at
least
in
my
example,
I
use
just
kind
cluster,
which
is
very
easy
to
your
provision.
You
just
have
kind
great
cluster.
You
have
it
already
in
your
local
machine.
You
just
need
that,
because
it
works
with
crds
it
was
it
works
with
kubernetes
manifest.
You
require
a
context
in
kubernetes
to
actually
deploy
all
these
resources.
A
A
Definitely
there
is,
if
I'm
not
mistaken,
there
is
already
a
integration
with
with
red
hat,
I'm
not
entirely
sure
if
it's
going
to
be
openshift,
because
openshift
is
a
very
similar
offering
such
as
gk
is
a
managed
clusters
managed
service
by
red
hat.
However,
I'm
not
sure
about
rancher,
there
might
be
some
initiatives
there,
but
definitely
there
is
as
long
as
there
is
an
api
endpoint
to
create
your
infrastructure
you'll
be
able
to
integrate
a
cluster
api.
A
A
A
A
I
think
there
was
a
question
in
regards
to
if
using
cluster
api,
does
it
mean
you
cannot
use,
skip
spray
anymore
or
tools
like
keep
spray?
That's
definitely
not
the
case.
I
think
these
tools-
and
this
is
why
it's
all
about
this
open
collaboration
and
open
source,
because
you
have
multiple
solutions
for
for
the
same
problem
so
with
a
cluster
api
you'll
be
able
again
if
you
would
like
to
provision
multiple
clusters
in
different
infrastructure
providers
having
reusable
manifest.
A
That's
going
to
be
the
case
if
you'd
like
to
use
cubespray,
for
example,
to
have
ansible
as
infrastructure
as
code
and
you
can
integrate
with
aws.
So
you
can
do
this
on
pure
metal
that
that
again,
is
is
right.
It's
more
about
like
the
different
problems
they
actually
solve.
One
is
just
a
simple
with
keeps
break
as
well.
We
integrate
with
only
a
couple
of
cloud
providers
while
clustering
is
more
expensive.
So
again,
it
really
depends
what
you're
trying
to
solve.
It
really
depends.
What
actually
is
the
end
result?
A
You
want
to
to
get
out
of
these
tools
and
how
do
you
want
to
describe
and
manage
your
infrastructure's
code
and
I've
actually
got
a
notification
that
I've
got
30
seconds
left.
So
I
think
this
is
going
to
be
my
last
question
to
be
answered,
but
again
I'm
going
to
be
available
on
social
media.
If
you
have
more
questions,
please
let
me
know,
please
do
to
read
the
article
medium
watch,
the
webinar
and
I'm
going
to
be
available
as
like,
as
mentioned
before.
So
thank
you
very
much
for
all
of
your
questions.