►
From YouTube: Cluster API Provider AWS (CAPA) Update - Richard Case, Weaveworks & Sedef Savas, VMware
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Cluster API Provider AWS (CAPA) Update - Richard Case, Weaveworks & Sedef Savas, VMware
Cluster API Provider AWS (CAPA) is a SIG Cluster Lifecycle project, which is responsible for building the UX for deploying and upgrading Kubernetes clusters by also handling infrastructure provisioning in AWS. It can be utilized to build declarative, replicable, scalable Kubernetes clusters in AWS.
Learn about the new features in Cluster API (CAPI)/Cluster API Provider AWS (CAPA), the roadmap ahead, and how you can contribute to the project.
A
B
A
A
So
what's
cluster
api
and
what
does
it
do
for
us?
Kubernetes
lifecycle
management
is
complicated
with
day
one
and
day
two
operations
and
cluster
api
brings
kubernetes
style
declarative
apis.
To
simplify
this
management.
It
manages
kubernetes
clusters
again
by
kubernetes
clusters,
and
you
see
the
cluster
api
logo
on
the
right.
It
is
a
reference
to
tartus
all
the
way
down,
because
we
are
using
kubernetes
clusters
to
manage
kubernetes
in
general.
Cappy
brings
some
automation
to
the
management
of
the
clusters
in
terms
of
creation,
scaling,
repair,
upgrades
and
deletion.
A
If
you
do
not
find
your
provider
in
the
list,
you
can
always
build
your
own
provider,
there's
a
section
in
the
cluster
api
book
that
shows
the
contracts
for
adding
a
new
provider
and
I'm
gonna
no
next
slide.
Please
yeah
and
a
cappy
has
lots
of
cool
features.
If
you
want
to
know
more
in
detail,
there's
a
deep
dive
session
on
friday.
A
B
So
this
diagram
represents
that
the
high
level
architecture
of
how
cluster
api
works.
There
are
three
main
portions
to
it.
On
the
left
hand,
side
we
have
the
the
clusters
definition
as
yaml
in
the
middle
portion.
We
we
have
the
management
cluster
and,
on
the
right
hand,
side
we
have
the
resulting
clusters
that
are
created
or
the
tenant
clusters,
so
everything
starts
with
a
definition
of
a
cluster,
and
this
is
created
using
the
ammo.
B
So
essentially
you
have
to
start
with
that.
You
have
to
create
your
your
your
cluster
and
its
definition
as
yaml.
This
is
applied
then,
to
a
management
cluster.
So
this
is
a
core
concept
to
cluster
api.
You
have
to
have
a
management
cluster
where
you
apply
these
definitions
into
the
role
of
the
management
cluster,
then,
is
to
to
run
the
controllers
from
the
various
providers
and
from
cluster
api
as
well
and
provision
the
clusters.
The
tenant
clusters,
on
the
right
hand,
side.
So
essentially,
this
is
this
is
a
two-step
process.
B
So
you
can
see
within
the
management
cluster
you
can
see
the
color
coded
representations
of
the
various
controllers
for
the
different
providers
and
also
cluster
api
itself.
When
a
cluster
is
provisioned.
Essentially,
it
will
also
store
a
cube
config
for
that
cluster
within
the
management
cluster,
and
you
can
then
use
that
to
connect
to
to
the
newly
created
cluster.
B
B
It
provisions
the
infrastructure
in
an
opinionated
way,
so
you
don't
have
to
specify
every
every
aspect
of
the
infrastructure
you
can
just
let
the
provider
take
that
opinionated
view
on
what
infrastructure
it
should
create.
Obviously,
that
doesn't
fit
everyone's
needs,
so
you
can
bring
your
own
infrastructure,
so
you
can
provision
your
infrastructure
advice.
Some
other
means
like
terraform
or
cross
plane
and
and
plug
in
the
details
of
that
into
the
kappa
manifests
when
creating
clusters
with
with
kappa,
you
can
create
two
types
of
clusters.
B
If
you
look
towards
the
bottom
of
the
diagram,
you
see
representations
for
the
actual
worker
nodes
in
this
diagram.
We
have
machines
and
machine
force,
but
there
might
also
be
machine
deployments,
and
what
you
can
see
from
this
is
within
kappa.
The
resource
kinds
are
advised
machine,
aws,
machine
port
and
aws,
managed
machine
ball
and
you'll
see
for
managed
clusters
that
sits
across
all
of
this
is
a
bootstrap
type,
and
this
is
essentially
for
from
managed
clusters.
This
is
called
eks
config.
A
Yeah
and
now
I'm
gonna
mention
about
a
command
line
utility
called
cluster
aws
adm
that
we
publish
with
our
releases.
It
has
some
help.
Helper
functions
for
kpa,
for
example,
cluster
aws,
adm,
bootstrap
command,
manages
identity
and
access
management
objects
like
roles
policies,
and
these
are
used
by
clusters
and
kappa
controllers.
A
Also,
after
every
kubernetes
release,
we
build
and
publish
aws
images.
Amis
using
another
kubernetes
sub
project
called
image
builder,
and
these
mis
comes
with
packages.
That's
needed
to
the
node
by
default.
When
you
create
a
kubernetes
cluster
with
a
specific
version,
kappa
picks
the
right
image,
depending
on
the
version
from
from
an
aws
account
and
to
list
all
available
amis
for
specific
kubernetes
versions
and
os
distributions.
You
can
use
cluster
aws
adm
minus
command
as
a
side
note.
A
By
the
way
we
also
support
custom
mis,
created
by
users
on
the
kappa
manage
eks
site.
We
have
cluster
aws,
adm
eks
command
to
list
available
and
installed
addons
yeah.
So
let's
talk
about
some
new
features
of
kappa.
So
in
general
we
release
minor
releases
every
six
months
or
so,
and
a
petrol
is
almost
every
month.
We
are
currently
at
version
0.6
release,
which
was
released
last
september,
and
I'm
going
to
mention
about
some
new
features
in
0-6
release,
which
is
common
for
both
managed
and
unmanaged
clusters.
A
The
first
one
is
multi-tenancy,
previously
kappa
controller
used
to
use
same
set
of
credentials.
It
is
initialized
with
to
reconcile
all
all
all
the
workload
clusters
and
this
was
not
suitable
for
especially
large
organizations
where
they
would
prefer
to
run
their
management
cluster
in
a
management
aws
account
and
each
team
has
their
own
aws
accounts
to
run
their
workload
clusters.
A
Keppa
can
now
do
a
an
im
role,
assumption
at
runtime
on
a
per
cluster
basis
and
each
workload
cluster
can
pick
and
choose
a
different
principle
to
be
used
during
reconciliation
of
that
cluster,
and
you
see
the
crds
we
introduced
to
support
multi-tenancy,
different
kind
of
principles,
controller
principle,
role,
principle
and
static
principle.
Also,
we
have
a
new
controller
for
backward
compact
compatibility
for
the
existing
clusters,
because
we
need
to
create
a
controller
principle
to
make
the
previous
clusters
work.
Content
work
and
the
next
feature
is
aws
machine
pools.
A
So
we
added
this
feature
with
this
release
and
it
is
responsible
for
creating
and
managing
aws,
auto
scaling
groups
using
a
launch
template,
so
users
don't
have
to
manage
individual
meshes.
So
let's
continue
with
our
demo
all
right.
So
before
even
creating
our
management
cluster
with
capy
and
kappa
controllers,
we
need
to
create
some
im
resources
and
we
use
cluster
iws
adm.
For
this
we
create,
as
you
see
here,
a
cloud
formation
stack
with
all
the
necessary
roles.
A
A
This
role
will
be
used
to
bootstrap
our
management
cluster,
so
our
capital
controllers
will
use
this
raw.
You
see
this
management
role
has
the
necessary
permissions
to
manage
aws
resources
for
our
clusters,
like
ec2,
elb,
etc.
On
the
on
the
right
hand,
side:
do
you
see
the
workload
rod?
This
is
the
workload
aws
cluster.
A
A
A
A
A
So
these
are
the
oh.
These
are
all
the
kappa
and
cap
controllers
in
their
own
name
spaces.
You
see
here,
let's
check
out
our
cluster
objects.
We
have
a
cappy
cluster
that
referred
to
the
infrastructure
providers,
cluster
object,
which
is
aws
cluster
for
us
and
here
in
the
aws
cluster
object.
We
specify
inverse
structure,
specific
things
such
as
networking,
and
also
we
provide
a
principal
graph
here.
A
This.
This
principle
graph
will
be
used
to
create
infrastructure
resources
for
this
aws
cluster.
Let's
take
a
a
quick
look
at
the
resources
created
by
kappa
forever
plot
cluster.
So
here
you
see
a
vpc
created
for
the
demo
cluster
and
when
we
check
our
sumness,
we
kept
our
controller
created
a
public
and
private
subnet.
A
A
We
create
some
road
route
table
rules,
net
gateways,
security
groups
etc,
and
if
we
go
to
our
ec2
dashboard,
we
see
the
api
server
that
that
came
up
on
the
public
subnet,
with
let's
check
the
instance
with
our
single
control
plane
instance.
So
when
we
check
our
running
instances,
this
is
our
control,
plane,
workload,
control,
plane
instance.
A
We
also
have
security
groups
created
for
this
workload
cluster
here,
I'd
like
to
show
one
final
thing
in
our
yaml
file,
which
is
meshing
pools.
So
you
see
this
is
the
cluster
api
construct
formation
pools,
which
refers
to
aws
machine
pool,
and
here
aws
has
machine
pool,
has
details
about
how
we
want
to
create
our
launch
templates
for
auto
scaling
groups
if
we
go
back
to
our
console.
A
So
this
is
the
machine
pool
created
by
kappa
controller,
with
this
launch
template
with
the
specific
instance
type
we
provided
and
the
key
pair
name
etc,
and
when
we
check
again
our
easy
ec2
instances.
This
is
the
single
instance,
because
we
we
set
the
desired
instance
to
one
in
our
machine
pool
specifications.
A
This
finalizes,
our
demo
and
here
are
some
more
features
that
become
available
with
0.6
release.
First
one
is
we
added
support
for
using
spot
instances
incubate
in
its
clusters.
Support
instances
are
non-reliable
ecito
instance
types
that
that
are
cheaper
and
more
suitable
for
fault,
tolerant
workloads.
A
The
second
one
is:
we
started
watching
for
easy
to
instant
state
changes
using
event,
bridge
and
simple
q
services.
Previously,
when
there's
a
ec2
state
change,
kappa
was
not
detecting
it
until
the
next
reconcile,
which
could
take
up
to
10
minutes.
Now
when
a
change
is
detected,
it
triggers
a
aws
measure
reconcile
also
in
this
release.
We
added
support
for
dedicated
instances
which
are
basically
ec2
instances
that
run
on
hardwares
that
are
occupied
by
a
single
tenant.
A
B
So
there's
two
main
crds
that
you
need
to
create
a
cluster
eks
cluster.
First
one
is
aws,
managed
control
plane.
So
when
you
create
a
unmanaged
cluster,
you
you
have
a
aws
cluster
and
you
have
a
cube,
adm
control
plane
within
the
managed
side
of
the
provider.
You
only
have
the
aws
managed
control
plane.
It
acts
as
both
the
cluster
and
the
bootstrap
provider,
combined
into
one
for
the
work
of
those
within
the
eks
cluster.
We
support
three
types
of
worker
nodes,
essentially
machines
which
are
ec2
based
instances,
and
these
are
individual
machines.
B
So
you
individually
declare
the
machines
you
want
to
add
to
the
cluster
and,
from
a
declaration
point
of
view,
you
use
the
cappy
machine
kind
and
the
aws
machine
kind.
When
you're,
when
you're
declaring
these
so
def
has
already
mentioned
about
machine
pools.
Machine
pools
can
be
used
within
an
eks
cluster
and
these
again
are
essentially
ec2.
Auto
scaling
groups
from
a
eks
point
of
view.
B
You
have
to
use
the
the
machine
pool
cavity
declaration
and
also
the
aws
machine
form,
but
in
the
eks
side
we
also
have
another
variant
of
the
machine
force,
and
these
are
called
managed
machine
balls.
If
you,
if
you're
aware
of
a
vks
and
using
case
normally
these
get
represented
within
as
eks
node
groups.
Essentially
to
use
these,
you
need
to
use
again,
I
think
the
cappy
machine
pool,
but
then
there's
a
different
kind
from
a
capital
point
of
view,
and
that
is
at
the
aws
managed
machine
pool.
B
If
you
want
to
use
either
either
variant
of
the
of
the
machine
pool,
you
must
make
sure
that
you
enable
the
machine
call
feature
flag
and
you
can
use
all
three
of
these
within
an
eks
cluster,
so
you
can
mix
and
match
and
have
different
types
of
work
in
those
within
an
eks
cluster.
You
just
need
to
to
create
the
declarations
and
reference
the
the
managed
control
plane.
B
B
B
We
also
recently
added
support
for
eks
add-ons,
there's
only
one
animal
present,
which
is
the
vpc
cni,
but
this
enable
allows
you
to
declare
what
add-ons
you
want
within
a
cluster
and
then
also
upgrade
the
versions
of
those
add-ons
in
a
declarative
manner.
We've
also
added
support
for
file
gate
profiles.
B
Well,
this
is
in
0.65,
and
this
allows
you
essentially
to
attach
the
file
gate
profile
to
your
cluster
and
then
effectively
run
specific
pods
within
that
filegate
profile
at
the
bottom
of
this
screen,
you'll
see
that
they
how
you
install
the
the
capital
provider
into
your
management
cluster.
A
few
things
to
note.
We've
talked
about
feature
flags
quite
a
lot.
There
is
convention
about
how
you
can
enable
those
feature,
flags
via
environment
variables
and
in
the
bottom
of
the
screen.
You'll
see
some
examples
of
that.
B
So
what
is
the
actual?
What
does
the
album
look
like
from
a
managed
point
of
view
from
the
eks
cluster
point
of
view?
So
here's
two
examples
on
the
left-hand
side
in
the
box,
a
you
see
an
example
of
the
aws
managed
control
plane,
so
this
represents
the
cluster
and
the
bootstrap,
like
I
mentioned
before.
B
B
So
this
is
where
you
do
that
declarative
configuration
of
awsim
authenticator
on
the
right
hand,
side
you'll,
see
an
example
of
a
aws
management
machine
more
so
this
is
very
similar
to
what
sid
f
showed
in
the
demo,
but
this
is
just
for
for
the
managed
machine,
ball
side
of
things,
and
you
can
see
it's
very
simple.
You
know
we're
only
switching
to
two
properties
here,
the
min
and
the
max
size
of
that
of
that
machine,
full
size.
B
B
B
A
Yeah,
so
we
are
still
working
on
clarifying
the
features
that
will
be
in
for
v07
release.
We
will
continue
to
focus
on
improving
stability.
That's
for
sure,
but
these
are
some
of
the
features
that
are
coming
up.
We
for
the
unmanaged
site
we
plan
to
extend
our
spot
instances
apart
by
also
supporting
amazon,
easy
to
finish
and
scott
flix.
A
Also,
we
will
verify
you
using
a
gpu
is
easy,
to
instance,
type
as
workload
nodes.
So
for
that
we
will
probably
add
conformance
test
that
uses
mdigp
operator,
which
is
basically
responsible
for
installing
necessary
drivers
for
kubernetes
gpu
support
and,
finally,
we
will
add
ignitions
apart
and
start
supporting
ignition
format
for
our
bootstrap
data,
instead
of
only
using
a
cloud
in
it
to
run
our
bootstrap
script
during
instance,
initiation.
B
So,
on
the
managed
side,
we
we're
focusing
on
three
main
areas,
so
the
first
area
is
to
implement
the
oidc
provider
association.
So
this
feature
was
recently
introduced
into
eks,
so
we're
implementing
that
so
that
we
get
to
the
point
of
having
feature
parity
within
eks,
we're
looking
at
a
change
in
the
way
that
we
we
handle,
launch
templates
within
the
managed
side.
Currently
we
we
generate
a
default
launch
template,
but
we
don't
actually
allow
you
or
to
to
to
configure
all
of
the
options
within
a
launched
effect.
B
So
this
this
will
be
coming
along
from
an
api
point
of
view.
We
are
going
to
refactor
the
aws,
managed,
control,
plane
and
essentially
deprecate
the
aws
managed
cluster.
So
currently,
the
aliens
measure
control
plane
has
grown
organically
a
bit
in
all
honesty
and
we're
going
to
change
it
and
refactor
it.
So
there's
a
bit
more
structure
to
it.
So
it's
obvious
when
you
use
it,
you
know
what
options
you
should
be
using.
B
So
how
do
I
get
started
so,
first
and
foremost,
try,
cappy
and
copper
cappy
is
a
project,
creates
a
quick
start
guide
and
within
that
quickscop
guide
you
can
choose,
follow
through
and
choose
which
provider
you
want
to
use
and
to
get
you
from
the
point
of
creating
your
management
cluster
to
creating
your
first
tenant
cluster
once
you've
done
that
you
can
then
look
at
the
kappa
specific
book
that
we
publish.
This
has
various
topics
that
are
specific
to
capital.
That
will
be
useful,
like
different
scenarios,
how
to
contribute.
B
B
So
how
can
I
contribute
so
there's
a
number
of
ways
you
can
contribute?
It's
not
all
about
coding.
So
the
first
way
do
you
have
writing
skills,
so
every
project
needs
documentation.
You
know
the
quick
start
guides,
you
know,
architecture,
diagrams
and
so
on.
You
know
for
the
project
to
be
successful.
We
need
good
documentation.
So
if
you
have
those
skills,
you
know,
we've
really
welcomed
you
to
come
and
come
and
join
the
project.
B
Do
you
have
product
skills
you
know,
can
you
translate
actual
real-world
scenarios
into
requirements
and
issues
that
need
to
be
implemented
within
kappa?
So
how
do
you
help
with
with
prioritization
with
when
we're
planning
a
new
release?
These
skills
are
really
really
important
to
make
sure
that
we
deliver
on
what
users
want.