►
Description
Why Kubernetes is the essential foundation for any organization looking to leverage multiple different infrastructures across their application portfolio.
A
A
The
process
took
well
weeks
at
best,
but
often
months
in
the
blink
of
an
eye
the
world
changed.
Now
it
was
possible
to
get
access
to
a
computer,
fully
managed
by
someone
else.
By
making
an
api
call,
you
now
could
get
access
to
computing
resources
in
minutes
and
better.
Yet
you
could
get
rid
of
it
when
you
were
done
potentially
minutes
later
so
for
the
cost
of
a
few
cents,
you
could
run
an
experiment,
do
some
computation
and
then
walk
away.
A
A
These
systems
made
it
possible
to
manage
the
growing
complexity
of
new
infrastructure.
These
systems,
too,
were
largely
imperative,
but
they
made
it
possible
to
start
thinking
about
infrastructure
as
code
and
then
before
you
knew
it.
Other
clouds
sprung
up.
Google
cloud,
microsoft,
azure
ali
cloud,
digitalocean
oracle
cloud.
A
Each
of
these
clouds
brought
their
own
somewhat
unique
twist
on
how
to
do
cloud,
while
the
philosophy
was
the
same
computing
as
utility,
each
had
their
own
spin
on
it,
and
this
was
a
good
thing.
It
actually
led
to
a
burst
of
innovation
with
the
best
ideas
quickly
becoming
common
across
all
the
clouds.
A
Take
the
idea
of
building
a
scale-out
layer
of
compute,
like
a
fleet
of
homogeneous
front-end
servers
that
you
could
automatically
scale
up
and
down
based
on
demand
and
that
will
automatically
kept
healthy
amazon
calls
these
auto
scaling
groups.
Google
calls
this
concept
a
managed
instance
group
azure
calls
it
a
vm
skill
set.
A
While
all
these
three
things
accomplish
the
same
thing
they
go
about
it
in
somewhat
different
ways.
Consider,
for
example,
how
they
distribute
instances
across
failure,
domains
how
they
define
and
manage
health
checks,
or
even
a
detail
like
what
happens
when
you
delete
a
vm
that
happens
to
live
in
one
of
these
groups.
A
A
A
In
2014,
google
launched
kubernetes
an
open
source
project
that
turned
things
on
their
head
again.
Applications
no
longer
had
to
be
deeply
intertwined
with
the
infrastructure.
They
were
built
on
logical
constructs
that
were
layered
atop,
the
infrastructure,
so
that
you
could
have
a
proper
separation
of
concerns
and
it
had
another
awesome
trick:
declarative
infrastructure
as
code
which
was
actively
and
continuously
reconciled
against
the
actual
state.
So
you
didn't
have
to
manage
the
outcome
of
a
set
of
imperative
actions
yourself
and
deal
with
complex
recovery
from
transient
errors.
A
Going
back
to
the
layer
cake,
the
separation
of
concerns
kubernetes
not
only
introduced
a
better
operating
model.
It
now
made
it
legitimately
possible
to
think
about
multi-cloud
operations
where
applications
could
be
written
independently
from
the
underlying
cloud,
but
still
make
use
of
the
advanced
features
that
every
individual
cloud
provided.
A
For
example,
here's
how
you
specify
a
container
that
has
attached
storage
the
application
layer
is
clean
and
the
cloud
specific
stuff
is
cleanly
separated.
This
has
other
benefits
too.
Of
course,
even
if
you're,
using
a
single
infrastructure
provider,
you
could
easily
swap
out
the
storage
provider
from
ebs
to
say
nfs
by
changing
the
volume
definition,
but
your
application
didn't
need
to
know
about
that.
A
It
just
thinks
in
terms
of
the
volume
that
it
mounted
at
a
specific
path,
and
so
your
application
developers
can
also
remain
largely
blissfully
unaware
of
these
details,
and
all
of
this
has
spurred
another
wave
of
innovation
with
kubernetes
being
adopted
at
a
breathtaking
pace.
In
just
seven
years,
the
vast
majority
of
organizations
96
percent,
are
using
or
experimenting
with
it.
A
A
Treating
them
as
such
can
make
a
number
of
day
two
operations,
much
more
repeatable
and
predictable,
but
now
you're
back
in
imperative
land
trying
to
create
clusters
repeatedly
thinking.
Wouldn't
it
be
nice
if
I
could
just
tell
kubernetes,
I
wanted
a
new
cluster
and
it
did
it
for
me
just
like
it
does
with
containers
and
services
and
the
rest
turns
out
you
can
cluster
api
does
for
kubernetes
what
what
kubernetes
did
for
infrastructure.
A
It
was
launched
in
2018
by
the
kubernetes
sig
cluster
lifecycle.
It
has
a
declarative,
kubernetes
style
api
for
cluster
management,
and
it
has
an
explicit
goal
of
separating
the
environment,
specific
state
from
an
environment
agnostic
state
as
much
as
possible,
while
still
being
able
to
use
environment-specific
functionality.
A
It's
been
a
great
success
with
cloud
providers,
support
for
aws,
azure,
digitalocean,
gcp,
metal,
3,
vsphere
and
many
more
its
heart
cluster
api
lets.
You
use
a
management
cluster
to
create
and
perform
day
two
operations
on
the
clusters
where
you,
your
workloads,
run,
which
it
calls
unsurprisingly
workload
clusters
late
last
year,
cluster
api
also
added
support
for
two
new
alpha
capabilities
that
I
think
really
take
this
to
the
next
level.
A
Cluster
class
gives
you
the
tools
you
need
to
define
the
shape
of
your
cluster
once
and
reuse
it
many
times,
abstracting
away.
Much
of
the
complexity
by
letting
you
use
a
collection
of
cluster
and
machine
templates
to
define
the
shape
of
a
cluster
that
you
can
then
stamp
out
many
times
for
creating
clusters
that
have
a
similar
shape,
managed
topologies
are
how
you
take
a
cluster
class
definition
and
turn
it
into
a
cluster
which
not
only
lets
you
simplify
cluster
creation,
but
gives
you
a
way
to
have
a
single
control
point
for
the
entire
topology.