►
Description
Join us for Kubernetes Forums Seoul, Sydney, 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
Growth and Design Patterns in the Extensions Ecosystem - Eric Tune, Google
How big is the Kubernetes Extensions ecosystem today and how quickly has it grown? How many CNCF projects does it touch? Data gathered from Github over 2 years by the speaker provides detailed answers. Based on experience as a Kubernetes contributor and API reviewer, and from analyzing hundreds of extensions, the speaker has identified recurring Design Patterns, like: Provisioner, Composition, Enforcer, Claim, and Class. End users will learn to recognize the patterns, and API authors will learn when to apply them. The talk will be accessible to a general audience. However, experts on Kubernetes Extensions will still find ideas and data not presented anywhere before. Illustrative examples will be used from various CNCF projects, such as Vitess, Jaeger, OpenEBS, and Rook.
https://sched.co/UaYw
A
So
I'm
gonna
talk
today
about
the
kubernetes
resource
model
and
its
ecosystem.
This
was
an
immediate
track,
but
I
kinda
wanted
this
feel
when
do
a
lot
of
audiences,
I'm,
not
sure
where
people
are
at
how
many
people
have
heard
of
a
CRD
have
some
idea
what
it
is?
Okay,
like
everybody,
so
I'll
go
fast
over
that
power.
Who's
heard
the
term
krm
COO
Bernays
resource
model,
some
of
you
less
okay,
so
that
won't
bore
you
so
kubernetes
api
is.
A
Is
the
term
I
like
to
use
to
refer
to
like
the
ones
that
come
with
kubernetes
they're
document
on
Q&A
at
I/o
there
in
the
kubernetes
release,
they're
about
containers,
they're
things
like
pod
and
service,
a
distinction
from
that
as
the
COO
Rene's
resource
model?
It's
not
an
API.
It's
a
pattern
for
API
is
to
follow.
A
It
doesn't
mean
that
API
has
to
have
any
do
with
containers
if
it
has
a
bunch
of
attributes.
The
pattern
which
I'll
talk
about
in
a
second
so
an
example
of
an
attribute
of
the
KRM
pattern
is
that
the
body
of
a
post
is
also
a
file
format
that
you
use
to
store
things
on
the
client
side
and
all
this
some
others
in
a
second,
so
I
use
a
term
model
and
framework
and
patterns.
So
let
me
explain
what
those
mean
to
me.
A
model
is
something
that
a
bunch
of
api's
have
in
common.
A
It
could
mean
the
wire
format
or
headers
that
are
required
or
other
things.
Rest
is
an
API
model
that
most
people
have
heard
of
I.
Don't
say
that
kubernetes
perfectly
follows
the
rest
model
like
it
doesn't
use,
links
for
everything
or
link
relations
framework
is
a
term
I
mean
to
use
like
libraries
or
tools
or
like
meta,
api's
or
API
services.
Idl's
to
help
you
create
things
that
follow
the
model
is
not
necessarily
required,
but
it
help
them
helps
a
lot.
A
If
you're
going
to
use
a
REST
API,
you
might
use
flask
as
a
library
to
help
you
fork.
A
api's
I
like
to
use
cube
builder,
could
be
other
uses,
see
RDS,
you
don't
have
to
use
CRTs,
but
you
should
and
then
finally,
a
pattern
is
something
that
tends
to
emerge
is
a
good
way
to
do
things.
It's
not
something
that
every
API
uses
within
the
model,
but
it's
that
a
lot
of
API
is
in
the
model
use
it.
A
So
if
you
search
for
rest
patterns
on
Google
you're
going
to
find
a
lot
of
hits,
if
you
search
for
G
RPC
patterns,
the
RPC
is
another
model
and
you're
gonna
get
an
official
G
RPC
guide
with
like
a
list
of
like
20
patterns.
It's
really
good
by
the
way
I
will
post
the
most
updated
slides
that
you
know
later
today.
So
don't
feel
you
how
to
photograph
everything
but
to
feel
free
to.
If
you
want
to.
If
you
search
for
krm
or
kubernetes
api
patterns,
you
basically
will
get
almost
no
useful
hits.
A
So
that's
something
I'd
like
to
solve
for
us
as
a
community,
and
only
this
talk
is
like
a
beginning,
and
we
can
have
a
conversation
about
whether
these
patterns
make
sense
and
document
them
and
collect
more
so
like
what
are
some
common
attributes
for
care.
Api's
mostly,
you
know
this,
but
I'm
gonna
recapitulate
this
for
people
that
maybe
are
are
new
to
this.
They
all
share
one
at
least
one
CLI.
They
can
interact
with
them,
coop
CTL.
They
all
have
metadata
like
labels
and
annotations.
A
They
all
share
one
state
storage,
which
means
the
API
implementation
is
stateless
and
somebody
else
gets
to
worry
about
the
backup
they
all
share
a
common
authentication
authorization,
audit
logging
model.
They
share
a
consistency
model
for
better
or
for
worse
of
you
all,
don't
like
eventual
consistency,
but
at
least
the
consistent
it's
consistently
expecting.
It
sets
expectations.
They
all
share
that
least
dynamic
clients.
In
some
languages
they
have
schema
reflection
that
can
help
ID
ease
help.
A
A
So
one
thing,
I
noticed
as
I
was
looking
at
sort
of
all
the
chemi
api's
out
there
is
that
CS
CF
uses
them
a
lot
identified,
18
projects
that
are
somewhere
in
CNCs
support,
folio
and
I,
highlighted
those
in
a
solid
line
circle
and
all
those
use
km
in
their
core
project
and
then
there's
another
six
that
they
don't
actually
use
Karen
in
the
core
project.
But
there's
like
a
well
supported,
you
know,
operator
or
some
other
third-party
project.
A
That's
supporting
that
with
km
prometheus
I
would
say
is
a
great
example
is
a
chorus
prometheus
operator.
People
I
know
that
run
huge
for
me,
these
installations
that
have
deep
experience
and
definitely
recommend
you
use
that
and
they
use
it
for
themselves
in
production.
So
overall,
there's
like
136
types,
just
among
CN
CF
projects,
so
you
can
see
how
kerim
has
just
sort
of
without
anyone
intending
it
as
bringing
a
level
of
consistency
to
this
whole
portfolio.
A
In
fact,
you
could
say
that
I'd
say
half
of
the
projects
in
the
portfolio
share
this
API
model
I
want
to.
As
an
aside,
I
want
to
say
that,
like
I
mentioned,
G
RPC
is
a
different
model
and
GRP
see
is
a
CNCs
project
and
I
viewed
G
RPC
as
complementary
to
krm
G
RPC
is
flexible.
It's
great
for
imperative
programming.
It's
great
for
high
bandwidth,
this
high
efficiency-
it
doesn't
have
quite
as
many
opinions
I
think.
Kerim
is
great
for
declaring
infrastructure
it.
A
Unlike
GRDC,
it
models
the
reconciliation,
loop,
sort
of
as
part
of
its
model,
as
opposed
to
not
making
any
assumptions
about
that.
So
I
hear
some
other
projects
and
you
weren't
aware
of
how
broad
the
ecosystem
is.
These
are
all
things
that
have
more
than
500
stars
on
github
that
use
krm.
It's
certainly
not
an
exhaustive
list.
What
I
wanted
to
bring
out
is
like
there's
a
lot
of
things
here
that
are
not
about
containers
and
within
each
category.
There's
like
lots
of
good
options.
These
are
just
a
sampling
for
some
of
these.
A
So
I've
been
working
on
kubernetes
project
since
nearly
the
beginning,
as
Paul
suggested
and
I
see
him
really
rapid
growth.
The
project
overall
and
I've
seen
the
api's
as
well
grow
really
rapidly.
At
the
beginning
of
the
project,
I
wrote
some
api's
that
are
in
the
core
and
then
I
moved
to
doing
API
reviews
I,
don't
do
that
anymore,
I.
It's
like
there's
too
many
to
review
Jordan.
A
Thank
you
very
much
for
for
staying
on
those
I
moved
on
to
trying
to
help
teams
within
my
company
build
km,
API
sort
of
consulting,
and
even
that
has
like
stopped
scaling
and
all
units
I
think
in
scale
is
documentation
and
frameworks
and
and
I
recently,
I
did
something
which
I've
done
a
few
times
in
my
career,
which
I
think
is
good
and
has
helped
me.
A
lot
is
I.
A
Take
off
my
engineer,
hat
where
you're
trying
to
sort
of
say
how
things
and
I
put
on
my
Naturals
hat,
which
is
more,
let's
just
look
at
all
the
things
that
exist
out
in
nature,
a
natural.
So
if
you
don't
know
like
a
scientist
who
collects
and
classifies
things,
maybe
seashells,
so
let
me
describe
my
time
as
a
naturalist
in
the
kubernetes
or
km
ecosystem.
So
this
was
like
several
centuries
ago.
You
were
a
naturalist.
There
was
no
place.
A
You
could
go
that
had
a
collection
of
all
the
shells,
so
you
would
have
to
go,
find
a
beach
and
walk
along
and
pick
up.
Everything
looks
like
a
shell
and
you
might
count
them.
Then
you
might
throw
away
some
rocks,
you
might
try
to
sort
them
and
guess
what
species
they
are
and
look
for
patterns
across
species,
and
that's
basically,
what
I
set
aside
some
time
to
do
so,
there's
not
a
list
of
all
the
KPIs,
but
there's
a
lot
of
stuff
on
github.
A
If
you
just
look
at
the
PMO
files,
you
pretty
much
get
a
picture
of
like
90%
of
all
the
things
that
are
in
the
Karem
ecosystem,
so
I'm
going
to
focus
on
that
for
today,
it's
nice
because
I
can
parse
it
and
understand
the
you
know:
structure
within
there,
so
I
downloaded
all
of
them
put
them
in
a
database
kind
of
clean.
The
data
got
rid
of
duplicated
files
right.
A
Some
people
have
copied
stuff,
github
tries
to
get
rid
of
Forks,
but
you
still
end
up
with
a
lot
of
duplicates
conveniently
unlike
an
actual
list
like
the
things
are
labeled
with
their
genus
and
species
right.
They
have
an
API
group
name,
which
is
a
unique
domain
and
a
kind
or
which
I
call
it
type
name.
A
So
I
do
this
in
October
it
took
a
while
to
get
this
data
because
github
like
doesn't
want
you
just
search
everything
and
they
have
all
this
DDoS
protections,
but
I
ended
up
with
like
27,000
EML
files,
and
then
you
sort
of
those
have
like
different
documents
in
so
you
break.
Those
I
began
a
bunch
of
objects,
and
this
the
end
it
was
67,000.
Cr
DS
there's
some
duplication
there.
You
went
all
that
down
figure
out
this
stuff.
A
So
there's
some
there's
some
noise
in
this
method,
but
you
also
some
big
spikes.
Those
are
real.
That
was
one
project
called
cube
form
over
on
the
right.
They
entered,
they
created
a
repo
and
it
has
like
more
than
a
thousand
types
in
it,
so
that
kind
of
figure
it's
not
fair
to
like
count.
Those
guys
is
one
thing
and
really
what's
more
interesting,
is
how
many
independent
groups
are
building
things.
A
So
I
decided
just
to
focus
on
API
groups
for
this
graph,
and
you
can
still
see
this
really
steady
trend
of
new
API
groups
showing
up
on
github.
So
if
you
extrapolate
and
say
well,
we
got
past
the
exponential
phase
and
it's
just
linear.
For
the
last
year,
I
still
extrapolate,
a
thousand
new
API
groups
will
be
created
in
the
next
year.
So
that's
great
more
things
for
us
to
you
know
configure
along
with
our
kubernetes
clusters,
but
it's
also
a
chance
to
influence
the
next
group
of
people
that
build
an
API.
A
So
how
can
we
provide
good
advice
and
support
and
tooling
to
those
folks,
so
I'm?
Clearly
one
way
we're
keeping
API
is
consistent,
so
far
is
through
frameworks
through
C
RDS
through
things
like
controller
runtime.
So
definitely
we
should
look
back
and
say
like
what
frameworks
are
people
actually
using
in
the
wild?
What
do
we
build
and
do
they
like
it
and
I'm?
Not
sure
I
can
tell
you
why
they
like
the
things
they
didn't
like,
but
but
I'll
tell
you
the
numbers
of
what
got
used
like
I'll
say
it.
A
A
I,
don't
recommend
you
do
that,
but
you
can
around
early
2017
the
community
was
trying
to
decide
like
we
had
invested
heavily
in
aggregation
and,
in
extension,
API
servers,
and
they
thought
this
was
the
most
flexible
way
to
build
new
api's
and
I
kind
of
said.
Wait
a
second,
that's
really
hard!
Isn't
it
better
if
more
people
come
to
the
ecosystem,
even
if
they
don't
build
api's
that
are
quite
as
full
featured
as
we
want
them
to
be?
A
Let's
focus
on
T
PRS,
which
became
CR,
DS
and
so
I
think
that
at
least
I
was
part
of
the
conversation
that
shifted
the
community
effort.
There
I
think
it
was
the
right
call,
because
looking
back
as
a
hundred
times
more
see
RDS
and
there
are
extension,
API
servers
that
basically
grew
not
at
all
over
the
last
two
years
and
CR
DS
have
just
gone
gone
vertical,
so.
A
A
lot
of
things
are
optional
for
CRTs,
at
least
in
v1
beta
one
validation
is
optional,
it's
sort
of
required
in
v1.
But
let's
talk
about
what
you
can
you
know
use
in
in
your
clusters
today,
I'm
I
should
mention.
Cr
DS
went
v
1
in
116.
If
you
didn't
hear
that
so
that's
kind
of
a
good
chance
to
reflect
back
on
them,
but
60%
of
all
the
CR
days
at
github
use
some
validation.
A
A
Additional
printer
columns
is
kind
of
one
of
my
favorite
things.
It
means
that
just
means
that
when
you
coop
CTL
get
some
type
name
that
you
get
columns
other
than
like
the
creation
time
in
the
name
which
is
kind
of
boring,
but
you
get
columns
that
were
picked
by
the
author
I
highly
recommend
that,
by
the
way,
if
you're,
building
a
CRT
status,
sub
resource
I'm
really
happy
that
people
are
following
the
status
pattern.
I
think
it's
not
used
enough
in
the
core,
but
people
are
adopting
it
well
for
CR,
DS
and
Conditions.
A
That's
an
area
I
think
we
could
work
to
sort
of
tell
people
like
whether
they
should
use
those
how
to
use
them
or
not
scale
sub
resource
surprised
me
like
no
one
basically
uses
scale,
and
it
seems
like
it's
just
as
easy
to
use
a
status,
but
only
1%
of
the
CRTs
I
could
find
define
scale
and
so
I
think.
Maybe
that's
because
not
everything
needs
to
be
scaled
or
if
it
needs
to
be
scaled.
A
A
So
I'm
gonna
talk
about
two
different
patterns:
the
first
one
that
I'd
like
to
promote
the
idea
of
is
a
controller
pattern.
This
is
less
about
like
what
the
schema
is.
This
is
about
what
does
the
controller
do,
and
so
the
first
bifurcation
I
make
is
between
controllers
that
create
some
kind
of
resource
and
controllers
that
don't
create
resources,
but
maybe
they
make
something
to
resources.
A
One
branch
is
where
they
act
on
requests.
I
call
that
a
enforcer,
that's
kind
of
a
shorter
way
to
say
like
mutating
or
validating
admission
webhook,
which
I
think
is
kind
of
a
mouthful.
The
other
option
is
where
they
act
continue.
Those
like
grab
synchronously
the
request
when
you
try
to
make
something
or
mute
or
to
update
it,
but
they
don't
do
anything
if
it's
the
things
just
they're
in
steady
state.
If
you
want
to
act
on
something
in
steady
state,
I
call
that
a
governor
pattern
and
it's
actually
quite
different
to
implement.
A
A
A
lot
of
people
that
are
like
hey
I
just
want
to
make
like
a
GCS
or
an
s3
bucket
and
define
that
next
to
my
application,
I've
seen
a
lot
of
people
try
to
do
that,
and
so,
if
you're
doing
that,
if
you
use
UCP
I'd
recommend
you
check
out
google
config
connector,
it
does
that
for
you
and
so
in
the
simplest
possible
version.
You
just
make
this
really
succinct.
A
Object,
doesn't
even
need
a
spec,
because
everything's
default
able
the
reconcile
is
going
to
go
off
and
make
a
cloud
provider
bucket
for
you
and
it's
gonna
set
some
status,
which
I
don't
show
there.
If
you
want
to
get
down
into
all
the
details,
like
you
know,
koror's
or
whatever,
for
like
serving
from
a
web
bucket
and
who
pays
there
are
fields
for
that.
But
it's
it's
simple
to
start
with.
So
if
you're
interested
in
provisioners
a
bunch
of
examples,
I
mentioned
conveyed,
connector
cross
plane,
dot
IO
is
pretty
cool
project.
A
It
takes
an
abstract
angle,
where
it's
like
trying
to
hide
this
sort
of
the
differentiators
of
each
cloud
and
view
each
view
every
cloud
as
being
having
a
least
common
denominator
of
resources,
with
a
focus
on
portability.
Kubb
form
is
saying:
let's
just
take
the
terraform
providers,
which
have
pretty
much
all
the
options
for
each
cloud
provider.
A
So
there's
not
symmetry
o'clock
across
similar
resources
from
cloud
providers
until
very
recently,
I
would
have
said
check
out
AWS
service
operator,
fusing
AWS,
but
unfortunately
that
seems
to
be
archived
and
I'm
hoping
they'll
they'll
revive
it,
because
I
think
it's
it's
useful,
so
composite
pattern.
So
this
is
very
familiar
deployments.
A
Stateful
set
are
very
common,
CN
CF
examples
are
Jagger
and
V
tests
there's
a
controlling
resource,
which
is
the
one
that's
defined
in
your
CR
D,
the
controller
watches
the
controlling
resource,
and
then
it
makes
one
or
more
camera
sources
that
are
the
controlled
or
or
lower
resources.
Some
people
like
to
say
parent
child
I
find
that
gets
like
a
little
bit
too
far
into
the
analogies.
A
There's
some
support
for
doing
that
in
frameworks
like
controller
runtime,
but
I
think
we
need
to
make
that
more
consistent
and
more
ubiquitous
some
advanced
concerns,
or
how
do
you
deal
with
like
attaching
and
detaching
resources
to
move
them
between
controllers
I?
Think
a
really
important
one
is
like
how
much
reconfigurability
or
changing
the
defaults.
A
In
fact,
you
can
go
like
I
can't
even
fit
in
the
whole
page
like
you,
can
override
node
affinity
and
and
stuff,
but
doesn't
use
a
pod
template,
but
as
it
stands
of
her
resources
and
so
I,
don't
know
that
we
have
a
consistent
thing,
a
consistent
pattern.
Yet,
for
templates
in
our
ecosystem,
which
is
why
I
didn't
add
them,
I
should
use
a
pod
template,
or
should
you
just
put
in
the
things
that
you
want
people
to
override
I'm
hoping
we
can
at
least
solidify
some
advice
to
people
on
that?
A
So
third
pattern,
I
call
enforcer.
This
is
gonna,
allow
or
deny,
and
maybe
edit
creation,
update
requests.
So,
unlike
the
previous
two
patterns,
the
controlling
resource
is
not
one
to
one
or
one
to
several
with
the
resources
that
get
created,
because
nothing
created
it's
more
like
the
controlling
resources,
just
configuration
at
the
cluster
or
namespace
level
for
this
policy
engine,
and
so
you
try
to
create
something.
And
then
maybe
you
get
to
creator
you
don't
so.
A
A
lot
of
this
is
like
sidecar
injection
or
security
policies,
pod
security
policy-
if
you
need
a
general
way
to
do
this,
I
would
definitely
recommend
you
to
check
out
the
gatekeeper
project.
I
link
that
at
the
bottom,
it's
part
of
OPA,
which
I
guess
is
part
of
CN
CF
I,
think
how
about
I'm
gonna
speak
their
fourth,
one
is
governor
pattern,
so
this
is
where
you're
continuously
updating
a
resource,
but
you
didn't
create
it
and
you
don't
own
it
and
you
can
detach
the
governor
or
add
it
to
a
resource.
A
I'm,
not
sure
why
this
is
covering
up,
but
it's
supposed
to
say,
horizontal
plot,
autoscaler,
a
vertical
part,
autoscaler
and
then
a
project
called
ke
da
could
not
try
to
pronounce
that
this
is
what
I
could
find.
The
least
examples
of,
but
I
wanted
to
include
it
for
a
completeness.
Okay.
So
let
me
talk
about
a
totally
different
set
of
patterns.
I
call
this
I
don't
have
a
great
name
for
this,
but
kind
pair
patterns.
A
A
Why
would
you
use
this
you'd
use
this?
If
you
want
the
administrator
to
be
able
to
create
like
defaults
or
limited
selection
for
users,
or
you
just
don't
want
to
repeat
yourself,
and
you
want
to
give
different
missions
for
the
X
resource
so
that
each
team-
sorry
I,
didn't
scribe
that
right,
if
you
want
to
make
cluster
objects
only
writable
by
the
administrator,
but
you
want
each
team
to
also
have
some
additional
set
of
objects
in
their
namespace.
You'd
use
this
pattern.
A
So
here's
some
examples-
I
found
like
around
40
of
these
as
I,
was
just
like.
Looking
for
the
pattern
of
X
and
cluster
X
within
the
same
API
group,
next
one
is
I
call
X
and
X
claim.
So
an
exclaim
is
something
that
a
user
creates
to
represent.
They
won
or
equal
to,
like
request.
A
resource,
and
then
it
gets
fulfilled
with
some
X
resource,
and
so
this
is
splitting
them,
so
they
can
have
different
lifetimes.
Maybe
you
want
the
X
thing
to
be
recycled.
A
You
want
to
have
different
permissions,
for
who
could
manage
each
one
I
think
is
a
useful
pattern.
It
worked
well
for
Peavey's
and
PVCs,
which
use
that
pattern
and
I
found
fairly
small
number
of
examples.
Actually,
one
that
was
sort
of
used
in
quite
a
few
places
is
this
object
bucket
claim
it
actually
doesn't
claim
object,
buckets.
It
can
claim
different
types
of
things
that
implement
buckets
on
different
platforms.
So
there's
some
variation.
A
Does
that
I
do
that
right,
yeah
for
some
type
X,
and
then
the
X
objects
might
copy
those
from
the
next
class
when
it's
created-
and
this
again
is
about
separation
of
privilege.
It's
also
about
like
these
are
not
even
have
to
think
about
it.
So
I'll
be
able
to
create,
like
site-specific
our
cluster
specific
defaults,
the
developers
don't
have
to
think
about
there's
sort
of
two
ways
this
plays
out.
I've
seen
it
used
like
with
the
enforcer
pattern
where
the
X
class
values
get
copied
into
the
X
as
like
site-specific
defaults.
A
A
So
I
saw
a
decent
number
of
these.
It's
used
quite
a
what
quite
a
bit
when
the
core
or
I
guess
three
places
in
the
core
API
crossplane
dot,
IO
uses
Wadud
recommend
you
check
that
out.
If
you're
interested
in
a
agnostic
cloud,
storage,
solution,
I
haven't
used
myself,
but
it's
interesting
from
an
API
standpoint.
Okay,
so
I
covered,
like
adoption,
growing
frameworks
patterns
models
how
those
fit
together
some
patterns,
I've,
seen
and
there's
quite
a
few
more
for
us
to
discover.
I
kinda
want
to
reflect
now
on.
A
So
I
talked
about
this
is
just
a
slight
that
top
half
of
this
is
just
that
slide
from
before,
where
I
showed.
How
often
I
saw
people
using
these
patterns
that
are
supported
by
the
framework
or
I
guess
features
of
the
framework,
and
the
bottom
thing
is
these
three
paired
patterns
I
just
talked
about
which
are
not
supported
by
any
framework
anywhere.
You
just
have
to
sort
of
know
about
them
and
I
saw.
A
So
let
me
try
to
sum
up
again:
Karam
api's
are
not
limited
to
containers
or
kubernetes.
You
can
use
them
without
using
kubernetes.
If
you
want,
you
can
create
a
cluster
and
not
have
any
nodes
in
it.
Not
have
any
pause
in
it
because
it
was
growing
really
rapidly.
There's
like
2,000
API
is
they'll,
be
another
thousand
next
year
and
I
find
a
consistency
across
those
really
valuable
unless
people
reuse
their
understanding
and
reuse
tooling,
framework
adoption
is
happening
much
faster
than
pattern.
A
A
B
A
C
B
B
There's
more
to
the
pattern
than
just
an
object
reference
all
right.
It's
a
specific
kind
of
relationship
and
the
way
you
implement
the
relationship
alright.
So
if
you
look,
for
example,
in
a
relationship
between
PVC
and
PV,
there's
a
kind
of
a
pattern
in
the
code
and
there's
same
kind
of
pattern
in
weight
uses
as
finalized
or
the
object
reference
and
then,
what's
wrapped
around
all
right,
same
kind
of
pattern
again
between
pod
and
the
PVC
okay,
so
that
that's
the
kind
of
thing
I'm
talking
about.
C
Yeah
hi,
so,
while
you're
going
through
all
those
different
controller
patterns,
I
found
myself
thinking
of
some
of
my
controllers,
we've
written
and
thinking
we've
kind
of
implemented,
all
all
of
those
in
one
controller
here
so,
and
maybe
that's
not
the
best
idea.
So
is
this
sort
of
more?
Do
you
mean
this
sort
of
as
I
serve
a
starting
point,
or
is
there
anything
more
sort
of
guideline
II
or
prescriptive?
You
you
can
say
when
you
find
yourself,
maybe
implementing
too
many
of
these
or
yeah.
If
that
makes
sense,.
A
A
Think,
for
example,
certain
manager
uses
like
I
think
all
these
patterns
as
well,
but
I
think
it
is
useful
to
least
have
names
for
the
parts
of
the
controller
that
do
it.
I
also
have
found
implementing
control
loops
that
it's
definitely
even
if
you
don't
expose
it
to
your
users,
I
think
it's
less
error-prone
to
try
to
implement
separate
control
loops
for
each
of
these
patterns
because
they
really
have
different
concerns.
I
think
we
probably
need
to
categorize
like
libraries
as
supporting
different
ones
of
these
patterns.
A
You
can
link
in
more
than
one
library
and
I.
Actually,
I
think
you
don't
want
to
try
to
shove
if
you
can
help
it
all
these
patterns
into
like
one
custom
resource,
so
I
think
it's
useful,
at
least
from
a
debug
ability,
understand
ability
if
you're
going
to
build
something.
That's
like
gonna
provision
cloud
resources
for
a
bunch
of
different
clouds.
A
You
could
sort
of
use
the
cloud
provider
plug-in
model
where
it's
sort
of
invisible,
what
the
relationship
is
between
the
top
level
CRD
and
then
the
created
cloud
resources,
and
you
can't
see
them
but
I,
actually
like
it
better.
When
you
have
an
intermediate
step
where
the
top-level
resource
then
creates
like
a
provisioner
style
resource
and
the
provisioner
then
goes
and
makes
the
cloud
resource
that
would
allow
cloud
providers
or
people
were
experts
in
each
system,
each
type
of
pattern
to
to
leverage
each
other's
work
and
I.
Think
it's
a
good
separation.
It
concerns.
D
Okay,
so
when
I
think
of
resources
in
kubernetes,
I,
think
of
them
as
describing
the
desired
state
and
controllers
as
what
reconciles
the
actual
state
to
be
aligned
with
the
desired
state,
but
I've
seen
other
instances
where
people
will
create
actions
with
resources
like,
for
instance,
an
ad-hoc
backup
of
a
database
and
in
the
how
the
controller
do
that.
So,
do
you
have
any
opinions
on
whether
that's
appropriate
or
not
yeah.
A
I
mean
I
I,
considered
putting
in
a
slide
on
that
which
I
call
like
the
job
like
pattern
and
I
think
it's
definitely
useful
to
have
a
pattern
for
resources
that
reach
a
terminal
state,
because
a
lot
of
times
you
want
to
know
like
is
this
done.
I
think
the
contract
there
should
be
like
if
you
offer
a
status
that
says
that
you're
completed
or
succeeded
or
failed
like
you,
should
never
be
able
to
leave
that
state
again.
A
That
way,
because
it'd
be
weird
if
he
said
that
my
job's
done
and
then
you
like
we're
like
okay,
great
I'm,
doing
the
next
thing
and
the
job
saying
just
kidding
I'm
not
done,
especially
with
eventual
consistency.
We're
like
you
sort
of
you
know
you
might
have
to
wait
a
long
time
to
get
the
message
that
it's
done
hopefully
not
like.
You,
definitely
don't
want
the
messages
crossing
in
them
in
the
night,
so
you
need
to
use
monotonically
increasing
signals
in
an
eventually
consistent
system
to
sort
of
help.
A
A
A
If
you
look
at
coop
flow
job
like
there's,
you
know
or
spark
job
there's
different
roles
and
so
I'm
interested
in
seeing
how
we
could
formalize
that
to
make
it
general
enough
to
be
usable
but
I,
don't
I,
don't
yet
have
an
opinion
on
like
where
the
trade-offs
are
for
that.
It's
a
good
area
to
look
at
thanks
everyone
for
coming
and
for
making
the
check
over
to
this
hotel.