►
From YouTube: Clusters as Coppice — Paul Fremantle 2 1 2
Description
Although k8s clusters manage workloads dynamically, evidence shows that many clusters are still managed as "pets". In this talk Paul will examine how the k8s Cluster API lets us treat clusters more dynamically using GitOps. We will also explore a different analogy - Bonsai vs Coppice.
A
Well,
we'll
move
on
to
our
next
talk,
so
our
next
speaker
is
paul.
Fremantle
from
weave
works.
Paul
is
going
to
be
talking
about
clusters
as
coppis,
which
sounds
quite
interesting.
So
paul
is
joining
us
live,
but
we
will
do.
We
will
be
playing
his
talk
and
then
we'll
be
going
back
to
ask
him
some
questions.
B
B
I'm
not
a
huge
fan
of
this
analogy,
so
I
spent
a
bit
of
time
trying
to
come
up
with
a
better
analogy,
and
why
don't
I
like
it
well?
Firstly,
I
think
a
lot
of
farmers
do
treat
their
their
cattle
really
really.
Well,
I
mean
here's
one
that
is
obviously
groomed
and
looked
after
and
a
prize
winner
and
also
there's
large
parts
of
the
world
that
revere
cattle
or
or
are
vegan
and
so
forth,
and
so
I
just
don't
think
it's
a
very
good
analogy.
B
B
So
what's
this
got
to
do
with
kubernetes
clusters,
so
the
fact
is,
clusters
are
often
still
treated
as
pets.
You
know
the
work
clothes.
The
kubernetes
makes
it
really
clear
that
we
don't
treat
the
work
clothes
that
way
the
workloads
are
managed
through
declarative
pods.
You
can
kill
the
pods,
you
can
kill
servers,
but
the
fact
is.
B
The
overall
cluster
is
often
treated
as
a
pet
and
I've
seen
this
both
personally
in
working
with
people
and
and
helping
them
debug
things
and
going
in
and
fixing
clusters,
but
also
there's
a
lot
of
evidence
that,
for
example,
at
aws
lots
of
eks
clusters
on
very
old
versions
of
kubernetes,
which
is
a
kind
of
us
and
have
not
been
restarted
or
killed,
are
just
out
of
date.
So
that's
kind
of
a
sign
that
we're
not
doing
immutable
recycling
of
clusters.
B
So
how
are
we
going
to
do
that?
Well,
I
think
that
the
right
working
model
for
treating
things
as
coppice
is
githubs.
I'm
not
going
to
go
into
all
the
key
definitions.
The
five
key
attributes
that
the
get
ups
working
groups
come
up
with,
but
the
fundamental
fact
that
we
can
use
git
ops
the
the
way
I
see
it
is
a
kind
of
a
remote
control
for
coppist
workloads,
and
we
certainly
have
seen
this
so
so.
B
This
is
something
called
the
getups
maturity
model,
which
is
based
on
a
lot
of
working
with
a
lot
of
different
people,
doing
git
ops,
and
what
we've
seen
is
that
as
people
expand
their
get
ops
usage,
they
start
out
by
really
working
on
workloads
at
level.
One
they're
they're
they're
get
opting
their
applications,
but
then,
as
they
get
further,
they
start
to
get
up
to
the
infrastructure
and
the
clusters,
as
well
as
the
config
and
the
workloads.
B
So
how
do
we
do
this?
Well,
there's
a
key
technology
called
the
kubernetes
cluster
api,
also
known
as
capi
and
cappy
is
a
project
which
basically
enables
you
to
treat
kubernetes
clusters
like
any
other
kubernetes
workload
through
the
kubernetes
api,
using
the
ammo
to
define
it
and
using
kubecuttle
to
deploy
and
declare
it.
B
So
this
is
super
cool
technology
that
supports
multiple
ways
and
places
to
run
your
kubernetes
clusters,
so
it's
declarative
infrastructure
and
because
it
uses
the
kubernetes
api,
we
can
use
traditional,
get
ops
tools
built
for
kubernetes
to
do
the
reconciliation.
So
this
is
really
cool.
We
can
use
argo
cd
flux,
I'm
going
to
talk
about
a
project
called
read,
get
ops
that
builds
on
top
of
cncf
flux.
B
Sync,
it
up
to
a
git
repository,
add
some
yellow
into
that
get
repository
and
see
it
reconcile
and
create
a
leaf
cluster.
So
I've
already
got
a
kind
cluster
created,
and
now
I'm
going
to
install
capi
into
this
cluster
using
the
tool
cluster
cuttle,
which
is
part
of
the
cappy
project.
This
is
slightly
sped
up.
It
takes
a
little
longer
to
install
and
get
cert
manager
running,
for
example,
but
this
is
this,
is
you
know
just
for
demo
purposes?
I've
sped
up
this
recording
slightly.
B
Now,
I'm
going
to
install
we've
githubs
into
this
runtime.
This
is
basically
installing
flux.
So
if
you
know
flux,
you'll
see
the
customized
controller,
helm,
controller
and
so
forth
that
you
know,
and
now
I'm
going
to
go
and
clone
a
repository.
I've
created
now
this
repository
literally
has
nothing
in
it
apart
from
a
readme
file
at
this
point
in
time.
B
So
this
is
a
really
simple
repository
and
I'm
going
to
now
get
this
repository
to
sync
with
my
management
cluster,
so
using
wego
ipad.
That's
now
set
up
to
sync
and
I'm
now
going
to
pull
up
k9s
and
we're
going
to
look
at
what
clusters.
There
are.
First
I'll
show
you
what
pods
there
are.
You
can
see
various
cappy
and
and
we
go
pods
running
and
now
I'm
going
to
go
back
and
monitor
the
clusters.
B
Now
I'm
going
to
jump
to
the
other
half
of
the
shell
and
I'm
going
to
go
to
that
repository
and
create
a
new
branch
and
I'm
going
to
check
in
a
yaml
into
that
branch.
So
this
docker
cluster
yaml
basically
defines
a
local
cluster
using
docker,
I'm
going
to
create
my
branch
and
then
I'm
going
to
use
a
pull
request
and
a
merge
to
get
that
into
the
cluster.
B
So
I
commit
my
change
to
the
to
the
branch
I'm
going
to
use
the
github
cli
client
to
create
a
new
pr
submit
that
pr
and
now
I'm
going
to
merge
it
now,
of
course,
normally
there'd
be
a
review
process.
There'd
be
a
different
people.
Looking
at
this,
but
for
demo
purposes,
you
get
the
idea
so
as
soon
as
it's
merged
you'll
see
with
githubs
reconciles
that
definition
and
when
it
starts
to
create
a
cluster
and
actually
there
it's
provisioned
already.
B
B
One
of
the
other
exciting
aspects
of
weave
getups
is
that
we're
creating
a
a
user
interface
fret,
and
this
is
an
early
preview.
This
is
not
quite
released
yet
of
a
of
the
cappy
template
capability,
so
I'm
gonna
basically
deploy
a
template,
and
this
template
lets
me
tweak
different
aspects
like
the
control
plane,
which
version
of
kubernetes
how
many
replicas
to
have
for
the
worker
nodes.
B
B
You
can
see
that
that's
going
to
pop
up
a
cluster
definition
there
it's
still
not
created
because
we
haven't
merged
the
pr.
You
can
see.
There's
the
yaml
and
just
have
a
quick
look
at
that,
and
then
I'm
going
to
go
back
to
the
pull
request
and
do
the
merge,
and
I
can
then
delete
the
branch
and
go
back
to
the
cluster
definition
and
it's
going
to
take
a
little
time
to
reconcile.
I
have
sped
up
this
video
as
well
slightly
just
because
this
is
a
very
short
talk
and
you
can
see
there.
B
B
The
cluster
api
is
a
really
key
project.
If
you
haven't
looked
at
it
already,
I
recommend
you
do
it
gives
you
declarative
control
of
of
leaf
clusters
using
kubernetes
apis
very,
very
interesting.
We've
git
ops
is
an
open
source,
git
ops
tool.
That's
basically,
a
super
nice
wrapper
on
top
of
the
cncf
flux
project,
we're
building
a
nice
ui
around
it.
B
This
concept
of
putting
git
ups
and
cappy,
I
think,
creates
a
really
effective
operating
model
for
treating
clusters
as
coppice,
and
I
think
they'll
be
of
interest
and
finally,
that
getups
maturity
model.
I
just
talked
about
it
very
briefly,
but
if
you
want
more
information,
there's
a
white
paper
about
that
and
I
think
that's
a
really
good
way
of
tracking
how
how
your
organization
is
using,
get
ops
and
and
where
to
go
next,
and
I
will
leave
you
up
with
some
resources
and
hopefully
we
have
time
for
a
few
questions.
C
Good
morning,
sorry,
I
got
slightly
chucked
out
the
stream
there,
but
so
yeah.
That
was
great.
I
love
guitars,
it's
super
cool
and
I
think,
if
you
you
know,
that's
really
the
the
ultimate
expression
of
of
doing
cloud
native
right.
You
know
in
some
ways
I
I
you
know.
I
talk
a
lot
in
in
in
my
talks
about
how
fully
automated
pipelines
are
really
the
you
know
the
biggest
indicator
that
that
you
are
far
along
on
your
on
your
transformation
journey.
C
I
had
an
one
question
that
I
had
actually
about
cluster
api,
which
I
I
again
cluster
api
is
a
project
I
love,
I
know
quite
a
few
people
who
work
on
it.
It
all
becomes
very
inception
like
you
know,
you
start
to
think
of
that
in
your
head
right,
because
you
need
an
api
server
to
start
with
right.
What's
what's
the
kind
of
current
best
practice
on
that
sort
of
mini
seed
cluster
that
you
use
to
to
to
kick
things
off.
C
B
B
Well,
I
think
there's
lots
of
ones
and-
and
actually,
if
you
look
in
the
slack
chris,
contacted
me
and
pointed
me
at
a
linkedin
post,
where
he's
also
got
a
kind
of
vegan
alternative
to
pets
versus
cattle.
So
I
think
there's
a
few
people
here
who
who
find
that
maybe
that
we
do
need
a
slightly
better
analogy.
So
yeah
and
they're
saying
it's
the
best.
But
it's
certainly
nice
to
have
that
discussion.
C
Awesome,
I'm
just
just
flicking
through
through
slack
quickly
to
make
sure
that
we've
picked
up
any
questions.
We
do
have
a
couple
of
comments.
Very
nice
copics
makes
more
sense
from
bruno,
so
obviously
somebody
that
resonate,
that's
starting
to
resonate
bruno
is
also
asking,
so
you
move
the
controlling
to
inside
the
cluster
itself.
C
B
Yeah,
that's
right,
I
mean
so.
The
cluster
api
requires
a
kubernetes
cluster
as
a
management
cluster
that
can
then
manage
lots
of
other
clusters,
but
there
is
this
also
kind
of
pivot
model
where
that
can
become
self-managed
as
well.
So
so
you
can
manage
that,
but
you
do
always
need
one
extra
cluster
and-
and
you
know
I
guess
we're
probably
going
to
see
that
also
be
offered
as
a
service,
because
that's
a
clear
thing,
you
know,
there's
a
obvious.
B
You
know
hybrid
model
where
okay,
I'm
gonna,
run
my
clusters
in
whichever
cloud
I
want,
but
I
don't
want
the
bother
of
running
that
management
cluster
and
I
wouldn't
mind
someone
did
it
for
me.
So
so
you
know
I
expect,
as
as
cappy
develops
we'll
see,
people
offering
you
know,
cappy
management
cluster
as
a
service
is
a
kind
of
key
control
plane
and
we've
seen
similar
things.
You
know
we've
seen
other
sas
models
where
you
can
spin
up
clusters.
B
C
I
think
it
says
something
about
the
power
of
the
kubernetes
api
as
well,
that
you
know
the
api
model
is
is
started
to
spin
out
into
so
many
other
things,
including
you
know,
spawning
itself.
You
know
the
the
the
standardized
api
has
become
a
really
important
driver
in
massive
adoption
of
open
source.
In
that
way,.
B
Another
great
example
of
of
a
project
which
is
saying
you
know:
let's
use
the
kubernetes
api
as
a
standardized
api
for
everything,
including
itself,
but
also,
then
you
know:
rds
databases,
all
sorts
of
others,
other
infrastructure
and
that
you
know
that
obviously
takes
this
whole
clusters
as
copper's
idea
even
further.
Because
then
you
can
say:
okay,
I'm
going
to
manage
all
the
required
infrastructure
in
a
git
ops
way
using.
B
Git,
ops,
tooling,
that
talks
to
the
kubernetes
api,
so
yeah,
it's
it's.
I
mean
I've
been
a
api
fanatic
for
for
20
years.
I
started
a
company
up
that
does
api
management,
and-
and
you
know
this
is
the
power
of
standard
apis.
Isn't
it
it's
something?
We've
been
hunting
for
for
20
years
and
and
kubernetes
is
one
of
the
examples.
That's
really
taken
off
as
a
really
nice
standard
api.
C
Yeah-
and
I
mean
all
these
things-
can
then
leverage
all
that
work.
That's
already
gone
into
the
the
the
api
server.
The
controller
manages
all
of
those
kind
of
interesting,
reconciling
behavior,
that
that
is
often
where
the
hardest
work
actually
happens
to
make
all
that
work
in
the
background
and
it's
the
bit
that
no
one
ever
gets
to
see.
B
And
also
cool
things
like
you
know:
k9s
and
kubernetes
observability
projects
and
prometheus
and
grafana
and
cortex
and
and
flux
and
argo,
and
all
these
projects
that
work
around
the
kubernetes
api
suddenly
give
you
like
so
much
more
power.
So
you
know
just
the
fact
that
I
was
using
k9s
without
any
modifications
to
matt
to
to
look
at
see
what
clusters
were
running.
Super
nice
yeah.