►
From YouTube: CNCF Research End-User Group Meeting: Crossplane
Description
In this session, Nic Cope from Crossplane shows us various patterns and approaches to how we can utilize Crossplane in our organizations.
The User Research user group meets regularly to discuss and advance Research Computing using cloud native technologies.
If you'd like to learn more about the CNCF End User community or join as a member, you can find more information at: https://www.cncf.io/enduser
B
A
D
A
E
D
F
D
D
A
A
A
E
G
A
A
G
A
D
D
A
Yeah,
so
I
was
about
to
add
like
we,
we
do,
we
we've
been
using
crossplane,
but
only
for
integrating
with
public
clouds,
and
we've
tried
the
providers
for
pretty
much
all
the
major
public
cloud
providers
and
we
use
it
actually
to
deploy
kubernetes
clusters.
So
we
manage
the
clusters
at
different
clouds
from
within
an
on-premises
kubernetes
cluster
and
we
just
orchestrate
the
remote
ones
using
corsplain
and
it's
easy.
A
D
D
D
Think
of
think
of
cross
playing
as
an
interface
to
your
platform,
so
your
platform
could
be
a
lot
of
things
to
a
lot
of
different
people,
which
can
mean
both.
What
is
your
platform
for?
Is
it,
for?
Is
it
a
platform
for
application
developers
to
quickly
ship,
apps,
sort
of
a
paths
or
internal
paths,
type
of
system?
Is
it
a
machine
learning
platform?
Is
it
sort
of
a
mini
internal
cloud
platform,
and
it
can
also
mean
what
is
it?
What
is
it
made
of?
What
is
it
powered
by?
F
D
F
D
D
So
this
is
an
example
of
basically
what
you
saw
on
the
previous
slide,
so
in
this
previous
slide
you're,
seeing
an
example
of
yaml-
and
you
know-
I
don't
everyone-
everyone
disses
yaml
in
that's
kind
of
cool
thing
to
do
these
days,
but
you
can
just
think
of
it
as
a
rest,
api
really
behind
the
scenes.
What
it's
doing
is
taking
this
yama
document
confirming
you
know,
transforming.
F
D
D
So
again,
remember
that
the
claim
would
be
the
postgres
instance
in
the
previous
slide,
the
managed
resources
would
be
rds
database,
subnet
group
in
this
example.
So
some
of
the
new
things
that
you
see
introduced
here
are
more
sort
of
platform,
team
or
platform.
Curator
concerns
you
have
the
composite
resource
definition
or
xrd,
and
you
have
the
composition.
D
These
are
these
all
sort
of
configure
what
your
platform
can
do,
so
composite
resource
definition
teaches
cross
plane
that
a
particular
type
of
composite
resource
now
exists
in
this
case
the
exposed
crystal
instance.
It
also
teaches
it
that
a
new
type
of
claim
exists
because
those
two
objects
are
tightly
coupled.
The
two
types
are
go
hand
in
hand.
D
Cosplay
then
needs
to
know
what
to
do
if
someone
creates
one
of
those
claims.
So
if
someone
says
hey
I'd
like
a
postgres
instance,
it
has
to
know.
Oh.
That
means
I
should
go,
create
an
rds
instance
or
I
should
you
know,
create
a
dv
subnet
group,
or
maybe
it
should
be.
You
know
using
a
different
cloud.
It
should
be
using
a
cloud
sql
instance
in
google
or
you
know
again.
Maybe
you
should
be
using
some
sort
of
on-prem
system
with
an
api
just
a
bit
of
a
database.
D
D
You
can
see
here
that
the
only
field
that
we
have
on
the
postgres
instance
here
is
storage.
You
should
know
the
fact
that
storage
is
actually
20
gigs
over
here.
I
realized
that
after
I
took
the
screenshot
pretend
that
they
pretend
that
they're,
both
100
gigs,
but
all
these
other
fields
have
to
come
from
somewhere
and
if
they're
not
sort
of
specified
here
in
the
postgres
instance
that
you
know
has
to
be
a
different
resource
and
you
can
almost
think
of
the
postgres
instances.
D
Configuration
fields
then
being
overlaid
on
top
of
the
rds
instance.
So
that's
all
done
with
a
composition,
and
one
of
the
interesting
things
is
that
there
is
a
one
too
many
composite
resource
type
to
composition,
relationship.
So
that
or
another
way
of
saying
that
is
for
any
particular
type
of
composite
resource.
D
D
Please,
and
by
specifying
labels-
and
they
will
get,
they
will
get
the
right
one
and,
as
you
can
see,
I
think
this
dotted
line
in
the
middle
sort
of
shows
that
everything
above
the
line
is
what
we
think
of
as
a
consumer
concern
an
app
team
concern.
Everything
below
the
line
is
more
of
the
person,
who's
sort
of
configuring,
the
platform,
probably
the
platform
team.
D
D
D
D
D
We
use
a
package
format
called
x
package,
which
is
just
a
simple
oci
based
packaging
format,
and
today
the
things
that
you
can
extend,
crossplane
with
are
providers
and
configurations
providers,
teach
cross-plane
about
managed
resources,
so
that
teaches
cosplaying
about
these
managed
resources
down
the
bottom,
which
again
are
things
like
rds
db,
subnet
group
cloud,
sql
instances
providers
tend
to
be
focused
or
packaged.
You
know
based
on
a
product
or
a
cloud,
so
we
have
an
aws
provider.
D
D
We
have
a
domino's
pizza
provider
that
can
go
and
one
of
our
product
managers
that
are
bound
made
to
to
order
pizza.
Is
it
something
that
you
always
have
to
do
if
you're
making
a
making
an
infrastructure
tool?
Apparently
and
then
so?
That's
providers?
We
also
have
configurations
configurations,
extend
cross
plane
with
support
for
new
composite
resources,
so
that
is
composite
resources
and
claims
configurations
will
actually
typically
drop
in
composite
resource
definitions,
xrd.
E
A
D
F
D
Them
up
as
a
configuration
can
be
a
handy
thing
to
do,
to
just
distribute
them
out
to
everything
you
can
version
that
configurations
can
have
dependencies
on
providers.
So
you
can
say
this
configuration
needs
the
aws
provider
and
the
google
provider
and
crossplane
will
automatically
install
all
of
that.
So
it's
kind
of
just
a
convenience
thing
for
distributing
cross-plane
configuration
some
of
the
stuff
that
we
have
in
the
works
that
we
think
of
as
cosplaying
extensions.
That
will
likely
be
packaged
up
as
well,
soon
secret
stores.
D
So
that
is
a
way
to
teach
crossblade.
When
I
create
something
like
the
postgres
instance.
In
the
previous
example,
I
might
need
to
push
connection
details
somewhere.
I
might
need
to
say
this
is
the
this
is
the
address
that
it's
running
at
this
is
a
username,
and
this
is
a
password
we've
always
supported
kubernetes,
just
writing
that
to
a
secret.
We
now
have
alpha
support
for
pushing
to
fault
as
well,
and
we're
working
on
a
sort
of
plug-in
based
model,
so
you'll
be
able
to
teach
crossplane
about
more
secret
stores.
D
D
D
B
D
Also
web
hooks
we're
adding
plugable
web
book
support
to
this,
some
of
those
web
books
is
probably
gonna
be
built
in.
So
this
should
be
things
like
validation
of
core
crossplane
types,
but
we're
hoping
to
allow
you
to
also,
you
know,
add
your
own
bespoke
web
hook
so
that
you
can
sort
of
add
your
own
sort
of
validation,
admission
control,
web
books
for
your
composite
resources,
for
example.
D
D
D
Validations
relates
to
the
web
hooks
also
looking
into
just
improving
our
support
for
argo
city,
a
lot
of
people
use
cross
playing
with
argo
cd
and
there's
a
few
bugs
at
the
moment
that
make
that
a
less
than
optimal
experience,
so
we're
gonna
work
with
the
argo
cd
folks
on
that
and
another
thing
that's
in
quite
demand.
Quite
a
lot
of
demand
is
observe
only
resources
as
we
call
them,
which
is
the
idea
that
maybe
you
want
some
stuff
to
be
represented
in
cross
plane.
D
D
D
In
all
of
our
examples
here,
we
we
tend
to
talk
about
crossplane
as
being
used
for
infrastructure
constructs
like
postgres
instances.
In
this
case,
we're
increasingly
seeing
folks
use
crossblade
for-
and
we
just
haven't,
got
a
lot
of
demos
of
this
at
the
moment.
But
people
ask
us:
you
know
what
what
app
model
should
I
use
with
crossplane?
What
should
you
know?
D
Should
I
use
cosplaying
together
with
coupe
vel
or
something
like
that
or
some
some
other
sort
of
simplified
application
model,
especially
if
I'm,
if,
if
I'm
installing
crossplane
as
a
add-on
to
kubernetes,
rather
than
as
a
standalone
control
plan,
and
you
know
being
based
on
kubernetes,
it
is
compatible
with
with
sort
of
any
of
those
things.
And
then
you
know
if
you,
if
you
like
one
of
those
app
models,
you
are
more
than
welcome
to
to
use
it
with
crossplane.
D
So
it
should
work
really
well,
but
we
also
think
crossplane
is
a
way
to
build
your
own
app
model.
I
was
at
an
open
source
symposium
run
by
some
amazon
folks,
the
other
week,
and
some
of
the
people
on
stage
were
talking
about
how
it's
it's.
Similarly,
to
the
fact
that
it's
really
tough
for
anyone
to
design
the
one
true
postgres
api
that
just
works
for
every
company
every
organization-
you
know
every
lab-
it's
tough
to
do
that.
D
For
you
know
the
one
true
application
model
as
well,
and
the
nice
thing
about
crossplanes
sort
of
composite
resource
system
is
that
it
is
pretty
open-ended.
You
could
use
this
to
define
a
composite
resource
that
represented
an
app
that
went
and
used
our
plugins
for
our
providers
for
helm
or
kubernetes
or
ec2
instances,
etc
to
go
and
actually
speed
up,
workloads
somewhere
and
potentially
also
spin
up
the
databases
and
cues
and
all
the
things
that
that
needs
behind
the
scenes.
D
A
C
D
D
F
D
But
we
have
a
steering
committee
that
is
open
to
people
who
are
not
bound
employees.
We
have
maintainers
who
are
not
about
employees
et
cetera,
et
cetera,
whereas
terraform
is
open
source,
but
it
is
is
not
open
governance,
it
is
a
hashicorp
driven
project,
but
putting
aside,
you
know
how
their
communities
run.
F
D
Much
more
like
sort
of
kubernetes
and
all
the
great
cncf
projects
that
she
called,
but
technologically
I
would
say
hashicorp
is
an
iac
tool
right.
So
it's
a
command
line
tool
that
is
one
shot.
Crossplane
gets
installed
onto
a
kubernetes
control
plane,
typically
we're
increasingly
promoting
a
model
where
you
could
actually
just
go
and
install
like
a
really
a
really
small
kubernetes
control
plate
that
doesn't
actually
run
your
controllers
and
doesn't
run
all
of
your
storage
and
your
controls.
D
It
doesn't
run
your
pods
that
is
just
sort
of
standalone
as
a
place
to
run
cross-plane
separately
from
maybe
all
of
your
app
clusters
that
you
run
sort
of
kubernetes
apps
on,
but
you
can
also
install
cosplay
just
as
an
add-on
to
a
kubernetes
cluster.
So
the
point
here
is
that
you
know
if
you
think
about
all
the
benefits
that
you
get
from
kubernetes.
Like
you,
declaratively,
say:
hey,
this
pod
should
be
running
and
if
the
pod
stops
running
kubernetes,
try
really
hard
to
get
it
running
again.
D
D
Another
thing
is
that
just
slight
design
differences-
and
this
is
a
this-
is
a
sort
of
a
trade-offs
thing.
Terraform
very
thoroughly
creates
a
graph
of
all
of
your
resources.
It
computes
everything
and
that
could
end
up
with
some
challenges
where,
if,
if
you
just
sort
of
model
all
of
your
infrastructure,
as
one
terraform
configuration,
you
might
want
to
say,
hey
terraform,
please
go
update
this
database
for
me,
but
then
someone's
changed,
your
buckets
out
of
out
of
you
know,
banned
as
well
and
terraforms.
D
I
just
have
to
fix
everything,
so
I'm
going
to
change
the
buckets
and
I'm
going
to
change
your
databases
as
well.
That
happens
less
with
cosplay,
just
because
you
really
can't
change
things
out
of
out
of
band
with
chris
playing,
because
it's
going
to
immediately
notice
and
change
them
back,
but
we
also
designed
crossplane
in
a
somewhat
lazy,
more
kubernetes-like
fashion,
where
it's
it's
all
very
decoupled
and
asynchronous
from
each
other.
So
there's
you
know
if
you
want
to
go
change
database,
there's
like
no
forced
relationship
on
on
on.
D
D
You
know
kubernetes
controller
projects
is,
it
varies,
notably
the
google
one
is
not
open
source
at
all
and
so
most
of
the
cloud
provider
ones
I
get
not
really
community
driven
are
owned
by
their
vendor.
So
you've
really
gotta
go
sort
of
work
with
work
with
the
cloud
providers
to
get
features
added
or
bug
fixes
et
cetera,
et
cetera,
but
they
all
are
single
vendor.
They
focus
only
on
their
cloud.
D
That
falls
outside
of
a
cloud
provider.
You
can't
have
to
go
find
some
other
sort
of
controller
or
operator
there.
You
could.
Let's
say
you
are
in
all
of
the
big
three
clouds
and
a
few
other
things
you
could
install
all
of
those
operators.
All
of
those
controller
sets
and
then
install
operators
for
all
these
other
things.
But
then
you
have
a
somewhat
disjoint
set
of
tools
that
all
are
like
kind
of
the
same
they're
all
in
the
kubernetes
ecosystem,
but
there's
subtle
differences
between
them
across
plane.
D
We
have
what
we
think
of
as
the
xrm
the
crossplane
resource
model,
which
says
anything
that
our
provider
drops
in
should
write
connection
details
in
a
standard
way
should
have
a
standard
sort
of
overall
shape
of
its
api,
for
how
the
spec
and
status
is
laid
out.
Things
like
that
should
have
standard
status
conditions
so
that
you
can
tell
when
they're
healthy
when
they're
not
healthy,
have
standard
annotations
for
importing
existing
resources.
Things
like
that.
D
So
with
crossblade,
you
get
the
kind
of
benefit
that
no
matter
what
back
end
api
you're
on
things
will
work.
Similarly,
like
all
the
apis
will
seem
familiar
to
you
and
then
again,
the
real
benefit,
I
think
with
crossplane
is
that
it
has
this
abstraction
layer
on
top
of
it.
If
you
go
install
amazon
controllers
for
kubernetes
you're,
really
just
taking
the
aws.
F
D
On
top
of
that,
as
I
showed
in
one
of
my
earlier
slides
that
sort
of
gives
you
wraps
at
all
in
your
opinions,
so
if
you're
developers
yeah,
I
worked
it.
I
worked
at
spotify
for
a
long
time,
and
one
of
the
projects
I
worked
on
was
before
spotify
was
in
the
cloud,
was
their
machine
provisioning
system
and
when
we
moved
to
the
cloud,
one
thing
that
was
conscious
of
in
the
early
days
was
that
developers
already
had
a
mental
model
from
our
previous
system
that
we'd
built
of
what
machines
were.
D
They
didn't
think
in
like
amazon
terms,
they
thought
in
spotify
terms
of
like
machine
sizes
and
features,
and
things
like
that.
So
you
know
in
that
example.
Something
like
crossplane
would
help
a
lot,
because
you
could
just
move
to
the
cloud
and
just
keep
the
same
abstraction
sort
of
thing
as
like
a
as
a
layer,
and
this
is
something
we
see.
Anyone
who
thinks
of
themselves
as
a
platform
team
and
many
people
think
of
themselves
as
sre
is
doing
at
the
moment.
D
They're
they're
really
trying
to
build
sort
of
a
layer
between
the
people
that
they
support
their
customers
and
the
sort
of
huge
amount
of
infrastructure
that
they
run
so
that
they
can
kind
of
present
it
in
a
slightly
more
user-friendly
and
controlled
way.
And
that's
that's
really.
What
crossplay
does
that
things
like
ack?
In
my
opinion,
don't
do
we
do
love
ack,
though
we
work
with
their
team
and
we
actually
share
a
co-generation
pipeline
with
them.
D
D
G
Taylor,
thank
you
yeah.
I
I
had
one
question.
You
kind
of
had
done
this
already
in
in
terms
of
like
setting
up
that
mini
cluster,
and
you
know
using
installing
control
plane
there
and
then
using
that
to
manage
some
of
your
other
concepts
and
and
constructs
have
you
seen
any
other
patterns
that
have
developed
in
using
crossplane
in
this
way,
like
git
ops,
you
know
you've
seen
like
app
of
apps
and
all
these
other
ways
in
which
to
manage
things.
D
So
let's
say
they,
you
know:
they've
got
20
clusters
around
the
world
for
whatever
reasons,
or
they
might
give
a
cluster
to
each
sort
of
department
or
team,
or
something
like
that
for
for
running
apps
on
and
they
might
want
those
clusters
to
have
rocd
installed.
Have
you
know
maybe
prometheus
installed
and
a
few
other.
D
D
D
D
D
D
G
G
I
know
I
know
I
know
the
industry
always
loves
an
us
first
them
story,
but
I've
I've
been
able
to
use,
tear
form
with
cross
plane
and
then
kind
of
like
use
terraform
to
get
up
to
the
bounds
of
instant
instantiation
and
then
use
cross,
plane
and
flux
and
argo
and
all
those
things
like
to
handle
those
downstream
things
too,
so
really
interesting
to
see
how
everybody's,
using
the
different
tools
within
the
space
and
yeah.
I
appreciate
it
nick.
Thank
you.
That's
fantastic.
D
Yeah
yeah,
that
was,
I
yeah.
I
haven't
used
a
terraform
in
a
little
while
just
you
know,
for
obvious
reasons,
because
I
you
know,
have
my
new
tool
of
choice,
but
I
contributed
to
terraform
before
I
ever
worked
across
play
and
I
really
loved
the
project
and
it's
it's.
It
is
pretty
funny
because
I
you
could
totally
have
a
cross-play
provider
for
terraform
and
then
you
could
have
you
know:
cross-play
calling
terraform,
calling
cosplay
and
calling
terraform
and
make
yourself
a
nice
endless
loop
or
something.
F
A
That
and
we
actually
do
that
using
argo,
so
we
basically
have
argo
re
argo,
cd
resources
that
are
cross-plain
clusters
using
the
gcp
provider
or
or
aws
or
whatever
you
mentioned.
There's
work
on
going
to
integrate
argo
cd
with
crossplane
a
bit
better.
What
is
that
exactly?
Because
one
thing
we
had
issues
with
is,
for
example,
if
we
deploy
those
clusters
using
argo
cd,
you
can't
really
register
those
clusters
to
then
deploy
additional
resources.
A
In
the
same
argo
city
instance,
it's
not
trivial
because,
like
argo,
cd
has
some
logic
on
how
to
manage
multi-cluster
deployments
from
a
single
instance
and
if
you're
deploying
the
clusters
themselves
using
crossplane
as
inside
the
same
argo
cd
instance,
it's
kind
of
a
loop
and
we
have
a
kind
of
hacky
way
of
registering
those.
Is
this
the
kind
of
thing
that
is
being
worked
on.
D
D
Use
a
ton
I
we
have
a.
We
have
an
issue
on
on
cosplay
slash
cross
playing,
which
is
titled
something
along.
The
lines
of
crossland
should
play
nice
with
argo
cd,
and
that
is
sort
of
our
parent
issue
for
some
of
the
little
bugs
that
we've
we've
noticed.
So
some
of
the
things
that
I
can
say
are
missing
at
the
moment.
D
If
I
understand
correctly,
is
that
argo
cd
does
not
have
a
concept
of
readiness
for
most
crossplane
resources,
and
this
I
think
I
actually
just
pinged
one
of
the
folks
from
acuity.
The
other
day
of
one
of
the
argo
project
leads
to
start
talking
about
this.
I've
been
meaning
to
reach
out
to
them
for
a
while
to
swap
notes,
because
my
understanding
is
that
that
might
be
best
fixed
in
argo
city.
D
Have
literally
hundreds
or
thousands
of
managed
resources,
that's
a
lot
of
configuration
to
add
to
argo
cd
and
then,
on
top
of
that,
if
people
are
just
defining
their
own
arbitrary
types,
they
probably
can't
reconfigure
aggro
cd
for
all
of
those.
So
I
was
considering
asking
the
argo
city
folks
how
they
feel
about
adopting
the
key
status,
emergent
spec,
which
really
just
says
amongst
a
few
other
things,
if
you
have
a
status
condition,
called
ready.
D
That
nothing
else
consider
that
to
be
the
thing
being
ready.
I
think
another
thing
was
that
there
is
some
label
copying
that
we
automatically
do
between
cross-plate
claims
and
cross-plane
composite
resources
that
confuses
aggro
cd,
because
argo
cd
will
manage
a
claim
and
it
will
add
a
label
to
that
claim
to
say
hey.
I
I
managed
my
ocd
and
we'll
just
copy
that
over
the
composite
resource
and
then
aggro
city's
like
I'm
managing
this
composite
resource,
but
I
didn't
create
it.
So
I
guess
I
gotta
delete
it
or
whatever.
So
so.
D
Some
of
these
things,
I
think,
need
to
be
fixed.
You
know
the
first
example
there
I
think
needs
to
be
fixed
in
argan
city.
The
second
example
probably
needs
to
be
fixed
in
cross
planes,
so
step.
One
is
going
to
be
just
talking
to
the
argo
city,
folks
about
the
issues
we're
seeing
and
getting
their
opinion
on
all
these
things,
to
figure
out
where
we
fixed
them
and
how.
A
D
F
D
Sort
of
thing:
either
there
are
some
rbac
issues
and
whatnot,
but
but
you
know
a
lot
of
you
know
folks,
who
are
much
more
sort
of
opinionated
and
experienced
for
security
than
me.
I'm
sure
will
violently
disagree,
and
you
know
different
different
orgs
are
gonna
have
different
policies.
Some
people
are
going
to
be
well,
you
can
only
put
it
involved.
Other
people
say
you
can
only
put
it
in
aws's.
I
think
it
was
called
key
manager
or
something
like
that,
so
our
approach
in
crossplane
is
to.
D
D
We
just
we
effectively
refactored
the
api
a
little
bit
to
be
a
little
bit
more
generic.
Previously
it
was.
The
api
was
was
very
specific
to
kubernetes
secrets
so
that
that
api
still
exists
because
it's
part
of
the
v1
api,
so
we're
not
going
to
get
rid
of
it,
but
we've
sort
of
added
a
new
field
as
an
alpha
field
that
that
sort
of
speaks
a
little
bit
more
generically
about
publishing
connection
details
that
can
has
a
a
new
type:
that's
similar
to
provider
config.
D
If
you've
used
provider
config
before
we
now
have
a
store
config
for
for
where
to
store
secrets,
and
that
can
be
told
there's
two
in
tree
baked
in
ones.
At
the
moment.
One
is
for
kubernetes
ones
for
fault.
The
kubernetes
one
can
now
publish
secrets
to
a
different
cluster
which
is
convenient
if
you,
if
you
have
that
kind
of
central
control
plane
and
you
use
that
for.
F
D
So
so
it's
there
for
the
time
being-
and
I
know
one
of
the
other
cosplay
maintainers
hassan-
is
actually
prototyping
sort
of
a
plug-in
based
approach
for
secrets
at
the
moment
that
would
open
up
all
those
other
ones
but
as
to
you
know
which
one
you
should
use
or
how
you
should
do
it
all
that
kind
of
stuff.
It's
kind
of.
I
can't
really
tell
you
that
that's
that's
up
to
your
org
to.
A
D
It's
interesting
actually,
because
I
my
background
is
you
know
10
or
15
years
in
platform
and
sre
right,
but
then
for
the
last
three
years
I've
been
building
this
cosplay
tooling,
and
I
don't
run
across
playing
a
lot
myself
to
go.
Do
anything
so
when
it
comes
to
learning
the
best
well,
you
know
I
run
it
to
develop
crossplay,
but
I'm
not.
F
D
The
infrastructure
anymore,
so
when
it
comes
to
what
are
the
best
practices
when
using
crossplane,
we
really
look
to
what
is
the
community
doing.
So
you
know
when
I
described
that
pattern
of
you
know
using
a
central
control
plane
like
that's
what
we
saw
people
doing.
You
know
I
have
co-workers
and
up
bound
to
use
cross-platforms
infrastructure.
So
I
look
to
them
to
tell
me
what
the
best
practices
are
and
the
secret
store
support
only
shipped
in
like
the
most
recent
version
of
crossplane.
D
B
Hi,
nick
thanks
for
the
talk,
I'm
having
troubles
getting
my
head
around
how
the
rest
api
is
constructed.
I
mean
in
my
mind,
they're
they're,
something
that's
normally
hand
built
and
crafted,
and
you
have
to
define
the
different
endpoints
and
what
what
methods
they
accept.
So,
in
your
example
postgres
there
how?
How
does
the
api
postgres
get
constructed?
Is
it
a
matter
of
the
difference
between
provided
annotations
and
what's
missing
or.
D
It
that's
a
good
question
and
to
answer
I'll,
ask
another
question:
are
you
familiar
with
crds
or
custom
resource
definitions
in
kubernetes
at
all
a
little
bit?
Yeah?
Okay?
So
we
we
basically
extend
those
or
use
those
as
a
framework
and
so
crds
when
you
install
the
cid
in
the
kubernetes
api,
it
kind
of
tells
kubernetes
hey.
D
I
have
this
new
type
that
I
would
like
you
to
expose
as
part
of
your
rest,
api
and
here's
kind
of
the
the
open
api
schema
for
it
and
then
the
kubernetes
api
server
is
very
clever
and
is
capable
of
basically
adding
all
those
restaurants
and
methods,
and
things
like
that
in
order
to
accept
requests
for
that.
But
then
the
ati
service
really
just
kind
of
a
document
store.
So
if
you
I
create
one
of
those
things,
the
api
server
is
really
just
gonna.
D
Go
all
right,
cool
I'll,
put
that
in
ncd
now
and
it's
there
and
not
do
anything
else
so
cross
playing.
Okay,
what
we
call
an
xrd,
which
is
a
just
a
sl
like
a
super
set
of
a
cid.
Almost
slightly
more
opinionated
takes
away.
Some
of
the
the
cds,
in
my
opinion,
were
sort
of
really
designed
for
a
software
engineer
to
go
right
like
it
was
designed
for
someone
who's
like
building
software
on
top
of
kubernetes.
D
That
knows,
oh
okay,
I
should
create
these
routes
and
accept
documents
and
accept
rest
requests,
basically
with
a
certain
shape,
and
then
crossplay
also
knows
about
those
and
sort
of
through
the
composition
type
you
can
think
of
the
composition
type
as
kind
of
like
a
help
chart
basically
like
the
helm,
templates
and
helm
chart
or
like,
like
the
the
the
hcl
in
a
terraform
module
sort
of
thing.
It's
kind
of
the
thing
that
says:
watch
it.
What
should
cosplay
do
when
that
rest
api
is
called
and,
interestingly,
what
cosplay
typically
does
is
like.