►
From YouTube: Crossplane: Compose Infrastructure and Services Into... Viktor Farcic & Aaron Eaton & Muvaffak Onuş
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Crossplane：将基础设施和服务组成定制平台应用程序接口 | Crossplane: Compose Infrastructure and Services Into Custom Platform APIs - Viktor Farcic & Aaron Eaton & Muvaffak Onuş, Upbound
在此次讨论中，我们将介绍 Crossplane 项目，描述整体愿景，并深入探讨一些具体的架构和实践范例。Crossplane 最近被批准为 CNCF 的孵化项目，生产应用者的社区也在持续发展。我们将学习如何使用 Crossplane 的通用控制面来配置和管理您的所有基础设施，以及如何建立您自己的定制平台和抽象，为您的开发人员提供自助服务。我们还将了解更多关于该项目和社区的部分最新进展，以及即将发布的项目进展规划。Crossplane 是一种社区驱动型项目，因此与项目维护人员进行合作、分享您的观点以及运用案例来影响规划方向的机会非常多！
In this session, we will introduce the Crossplane project and describe the overall vision as well as deep dive into some specific architecture and practical examples. Crossplane has recently been approved as a CNCF incubating project and the community of production adopters continues to grow. We will learn about how to provision and manage all of your infrastructure using Crossplane's universal control plane and how to build your own custom platform and abstractions that enable self-service for your developers. We'll also learn more about some of the recent advancements in the project and community, as well as the upcoming roadmap for where the project continues to progress. Crossplane is a community driven project, so there will be plenty of opportunities to collaborate with the project maintainers and share your perspective and use cases to influence the roadmap direction!
A
Today
we
are
going
to
explore
the
concepts
and
an
implementation
behind
a
universal
control
plan,
a
control
plane
for
everything,
infrastructure
services
applications,
but
before
we
do
that,
let
me
do
a
quick
introduction.
My
name
is
victor.
I
am
a
developer
advocate
at
top
bound.
We
are
a
company
behind
the
cncf
project
crossplane,
which
is
the
implementation
of
a
universal
control
plan.
I
am
accompanied
by
two
of
my
colleagues
and
I
will
let
them
introduce
themselves.
My.
B
A
Traditionally,
we
tend
to
manage
infrastructure
and
services
by
defining
the
desired
state
and
then
letting
some
command
line
interfaces
converge
the
actual
state
into
that
desired
state
by
communicating
with
the
api
of
a
provider
of
choice
that
could
be
aws,
azure,
google
cloud,
alibaba
or
any
other
cloud
provider.
What
is
special
about
those
apis
is
that
there
is
always
a
control
plane
behind
them.
A
control
plane
is
making
sure
that
resources
are
created,
updated
deleted,
that
they
are
scheduled,
that
they
have
allocated
resources
and
so
on
and
so
forth.
A
However,
there
are
a
couple
of
problems
with
the
tools
that
we
are
using
today.
They
do
not
have
an
api
and
they
do
not
have
a
control
plane
and
managing
infrastructure
and
services
without
an
api,
and
without
the
control
plane
is
painful
and
we
already
experienced
the
benefits
of
having
those
tools
through
deployment
of
our
applications
in
a
kubernetes
cluster
kubernetes
api
allows
us
to
communicate
with
kubernetes
control
plane
and
tell
it.
What
is
the
desired
state
that
we
want
when
dealing
in
applications,
especially
those
running
in
kubernetes?
A
We
moved
away
from
the
imperative
way
of
managing
them.
We
are
not
saying
anymore,
install
this,
create
that
update
this
delete,
that
and
so
on
and
so
forth.
We
are
always
defining
the
desired
state
and
letting
the
scheduler
the
control
plane
figure
out
what
should
be
done.
The
benefits
of
kubernetes
api
and
control
plane
are
obvious
and
that's
why
most
of
us
are
moving
or
already
moved
our
workloads
to
kubernetes.
A
But
that
is
not
enough.
We
need
something
more
universal.
We
need
a
universal
api
and
a
universal
control
plane
that
will
allow
us
to
manage
not
only
applications
in
a
kubernetes
cluster,
but
everything
services,
infrastructure,
applications
or
any
other
type
of
resources
allocated
to
one
or
many
clouds.
A
Most
of
us
are
moving
towards
multi-cloud
type
of
systems,
and
we
need
a
universal
api
and
a
universal
control
plane
that
will
manage
everything
and
the
solution
cannot
be
proprietary,
it
needs
to
be
open
source
and
all
major
vendors
need
to
contribute
to
it,
and
we
already
have
such
a
solution.
It
is
called
crossplane.
A
So
today
we
are
going
to
explore
crossplane
and
see
some
of
the
benefits.
There
is
not
enough
time
to
see
all
the
benefits,
but
we
are
going
to
see
some
of
the
benefits
that
crossplan
gives
us,
especially
when
compared
with
some
other
tools
that
we
might
be
using
to
manage
our
infrastructure
services
and
applications.
Let's.
B
Take
a
look
at
what
crossplane
is
and
how
crossplane
can
use
compositions
to
empower
your
development
teams
to
self-provision
custom
resources
while
maintaining
your
platform,
team's
control
and
visibility
on
what
is
being
deployed
and
managed.
Crossplane
is
an
open
source.
Kubernetes
add-on
focuses
on
two
main
feature
areas:
custom
platform
abstractions,
which
we
call
apis
and
crossplane
resource
model,
otherwise
known
as
the
xrm
custom
platform.
B
Abstractions
enable
infrastructure
owners
to
declaratively
build
an
opinionated
platform
for
developers,
while
the
crossplane
resource
model
provides
a
universal
api
for
managing
those
resources
consistently
in
every
environment,
crossplane
was
launched
in
december
of
2018
by
the
creators
of
rook,
which
is
a
cncf
graduated
project.
As
it
says
here
we
were
accepted
into
sandbox
in
june
2020.
Our
first
major,
stable,
milestone,
was
released
in
december
of
2020
and
in
september
of
2021.
We
moved
to
incubation
status
in
the
cncf.
B
Crossplane
manages
granular
resources
for
both
cloud
and
on-prem
infrastructure,
as
represented
as
crds
controllers,
which
we
call
providers
are
written
to
plug
into
crossplane,
with
these
crds
and
interface,
with
any
api
driven
system
to
enable
you
to
provision
infrastructure
or
any
api
driven
resource
through
the
kubernetes
control
plane.
What
this
means
is
that,
as
a
platform
operator,
you
would
create
an
rds
resource
submitted
to
the
api
server.
It
would
then
be
watched
by
the
rds
controller,
which
would
submit
commands
to
the
aws
api
to
provision
rds
instances.
We
call
these
providers
in
the
crossplane
world.
B
There
are
already
several
providers
available
from
major
clouds
and
more
are
being
developed
by
the
community
every
day
to
get
a
look
at
what
we
already
have
covered.
You
can
head
over
to
doc.crds.dev,
which
will
give
you
a
complete
breakdown
of
any
publicly
available
cross,
plane
provider.
Here
we're
looking
at
crossplane
provider
aws,
you
can
investigate
what
resources
we
cover.
What
sections
of
the
api
and
what
attributes
of
that
resource
we
expose
to
reach
alpha
status
and
a
provider
resources
only
need
to
be
able
to
be
created
and
destroyed.
B
Complete
coverage
of
every
field
ability
to
detect
out-of-sync
changes.
All
of
that
is
a
beta
feature.
If
something
has
been
promoted
to
beta
api
level
within
a
provider,
it
is
fully
functional
and
it
should
detect
any
change
to
a
configuration
of
a
currently
running
resource
and
bring
that
resource
in
line
with
whatever
you've
specified
in
the
kubernetes
api
crossplane
allows
you
to
build
your
own
platform
api
through
the
use
of
compositions.
What
this
means
is,
you
can
take
all
of
those
granular
resources.
B
We
were
just
talking
about
from
any
cloud
and
any
vendor
even
mixing
and
matching
and
assemble
them
into
your
own,
composed
resource
definition.
These
will
be
exposed
in
your
kubernetes
control
plane
and
can
be
leveraged
as
claims
by
your
development
teams.
Your
kubernetes
clusters
may
not
look
like
everybody
else's
kubernetes
cluster.
Your
organization
may
have
different
security
or
access
requirements.
You
may
have
certain
performance
goals
which
require
tweaks
to
the
configuration
that
are
non-standard.
B
You
may
have
unique
solutions
in
how
your
app
is
architected
that
require
you
to
provision
your
infrastructure
in
ways
that
are
not
the
same
as
everybody
else.
You
may
be
just
be
running.
Multiple
clouds,
you
may
have
gke
clusters,
which
are
using
ec2
nodes.
All
of
this
is
the
reason
we
created
compositions.
You
can
compose
your
definition
of
what
is
a
kubernetes
cluster.
What
is
a
storage
bucket?
What
is
a
database
and
make
it
available
for
your
development
teams
to
access?
B
You
can
compose
these
and
offer
them
as
a
single
cluster
resource,
limiting
the
configuration
values
to
only
those
that
a
developer
would
need
to
change
to
suit
their
purposes.
Everything
else
within
the
composition
would
stay
within
the
control
of
the
platform
team.
This
allows
you
to
hide
infrastructure
complexity
and
also
allows
you
to
add
policy
guard
rails
around
the
infrastructure
that
your
teams
need
to
launch.
All
of
this
is
happening
within
the
kubernetes
api.
B
This
means
any
tool
that
you
currently
use
in-house
to
talk
to
your
kubernetes
clusters
can
continue
to
be
used
when
talking
to
these
custom
resources
that
you
have
created.
This
is
not
code.
Crossplane
resource
model
allows
you
to
handle
all
of
this
in
configuration
and
definition.
You
do
not
have
to
write
your
own
custom
code
in
order
to
manage
these
custom
resources.
Crossplane
uses
the
crossplane
resource
model
in
order
to
give
you
a
consistent
api
across
all
of
your
resources.
B
So
the
same
api
that
allows
you
to
declare
a
deployment
or
a
replica
set
or
a
service
or
a
pod
is
also
going
to
allow
you
to
provision
a
kubernetes
cluster.
You
get
to
decide
whether
that
kubernetes
cluster
goes
into
an
already
existing
network
or
has
its
own.
You
get
to
decide
when
you
provision
a
bucket.
If
it
already
comes
with
an
iam
role
or
service
account
for
access
to
it,
you
get
to
decide
what
security
configuration
goes
into
it,
and
all
of
that
can
be
built
in.
B
You
can
call
for
a
claim
for
an
instance
of
one
of
these
resources
through
the
same
kubernetes
api
that
you're
using
to
deploy
your
services
and
your
workloads.
We
are
extending
the
kubernetes
resource
model
in
an
opinionated
way
to
provide
this
universal
experience.
This
means
that
if
you
have
a
package
that
you
want
to
run
that,
if
you
are
using
some
kind
of
standardized
resources,
some
publicly
available
configuration
package
on
the
crossplane
tool,
it's
going
to
behave
exactly
the
same
way
as
your
custom
packages.
Every
object
in
the
kubernetes
resource
manager
has
a
consistent
behavior.
B
We've
enabled
you
to
do
cross-resource
references,
standardize,
spec
and
status,
we've
enabled
connection
secrets
and
credentials.
We
allow
you
to
set
the
external
name
of
your
resources
and
we
have
life
cycle
policies
for
managing
them
through
their
different
phases
of
deployment
and
tear
down
our
composition.
Engine
also
has
another
unique
feature
in
which
you
can
publish
several
compositions,
which
respond
to
the
same
custom
resource
type.
You
can
use
labels
to
select
these
compositions
when
you
create
your
claim.
B
This
means
that
if
you
are
in
an
organization
where
your
developers
are
concerned
with
whether
their
clusters
are
running
in
a
specific
cloud
or
a
specific
environment,
you
may
have
use
cases
where
you
need
to
test
how
your
code
behaves
when
it's
inside
of
aws
versus
when
it's
inside
gcp
versus
when
it's
inside
azure.
You
can
do
all
of
this
through
the
same
resource
by
changing
the
label
of
the
composition
that
it's
going
to
leverage.
So
when
we
say
you
can
mix
and
match,
you
can
have
compositions
that
work
across
all
clouds.
B
You
can
have
compositions
that
deploy
resources
in
multiple
clouds
simultaneously
and
allows
them
to
interact,
or
you
can
construct
cloud
specific
compositions,
depending
on
your
use
case.
So
the
same
cluster
resource
that
you
declare
can
have
an
aws
variant
and
a
gcp
variant
and,
as
you
can
see,
launching
a
kubernetes
cluster
on
eks
requires
a
different
set
of
support
mechanisms
than
launching
a
kubernetes
cluster
on
gke.
Some
of
these
abstractions
are
name
only
a
network
and
vpc
are
roughly
analogous,
but
some
node
pools
and
node
groups
are
roughly
analogous,
but
some
of
them
are.
B
And,
at
the
same
time,
while
you're
launching
an
eks
cluster
or
a
gke
cluster
and
all
of
the
associated
infrastructure
needed
to
drive
them,
you
can
include
helm,
charts
that
are
standardized
across
both
you
have
certain
cluster
operators,
policy
agents
enforcement
tools
that
you
need
to
run
on
every
cluster.
You
can
include
those
in
your
composition
as
well
before.
A
A
I
want
to
be
able
to
manage
infrastructure
and
to
manage
services
and
to
manage
applications,
and
I
need
a
single
api
through
which
I
can
do
all
that,
through
which
I
can
declare
the
desired
state
that
I
want
through
which
I
can
query
the
actual
state
and
so
on
and
so
forth,
and
behind
that
api
there
must
be
a
control
plane,
a
control
plane
capable
of
figuring
out
what
to
do
with
all
those
resources.
What
should
go
where
how
something
should
be
done
where
something
should
be
done
and
so
on
and
so
forth.
A
A
So
we
want
operators
or
series
and
security
experts
and
so
on
and
so
forth,
to
be
able
to
implement
best
practices
and
implementations
of
all
the
resources
that
we
need
but
expose
those
to
everybody
else
to
developers
in
a
way
that
is
easy
to
manage,
easy
to
consume
and
easy
to
define.
This
is
about
being
able
to
shift
left.
A
It
is
about
collaboration
between
different
type
of
experts,
all
with
the
goal
of
enabling
people
on
the
left,
developers,
testers
and
so
on,
and
so
forth,
to
manage
everything
and
to
have
full
freedom
without
being
constrained
with
things
that
do
not
matter
to
them.
So,
let's
jump
into
a
demo
and
see
crossplane
in
action.
We
always
want
to
start
with
the
desired
state.
We
want
to
define
what
should
be
the
state
of
some
resources
and
those
resources
could
be
anything
it
could
be
a
cluster.
A
It
could
be
networking,
it
could
be
a
database,
it
could
be
applications
or
more
often
than
not,
it
should
be
a
combination
of
all
those.
Let's
start
with
a
simple
example:
let's
say
that
we
want
to
have
a
cluster
and
let
it
be
in
google
cloud.
Maybe
it
could
be
gk
cluster,
for
example.
A
definition
could
be
something
like
this
examples:
google,
gk,
no
xrd
and
remember.
This
is
a
very
simple
example.
I
will
show
you
more
complex
examples
soon.
A
So
here
we
have
a
cluster
and
that
cluster
has
some
parameters
like
hey,
it
should
run
in
usc
and
it
should
be
the
latest
version,
and
then
we
have
a
node
pool
that
should
be
attached
to
that
cluster
and
that
node
pool
also
has
some
parameters
like
hey
location
should
be
this
one
and
the
reference
to
the
cluster
is
this
function,
so
it
should
be
attached
to
this
cluster.
This
is
the
number
of
nodes
I
want
to
have
initially,
and
there
are
some
other
parameters
here:
they're
not
really
important
for
this
story.
A
What
does
matter
is
that
this
gives
me
a
declarative
way
to
define
my
resources.
I
could
do
something
similar
with
terraform,
pollumi,
ansible
and
so
on
and
so
forth.
Soon
you
will
see
the
things
that
you
cannot
do
with
those
tools
for
now.
What
makes
this
special
is
that
this
is
a
kubernetes
api.
These
are
not
definitions
in
some
proprietary
format.
A
Google,
I
forgot,
what
is
it
gk,
no
xrd
dot,
yaml
right,
we
can
apply
those
resources
in
a
kubernetes
cluster
that
already
has
cross
plane
up
and
running
in
the
same
way
as
we
would
manage
any
other
resources
in
a
kubernetes
cluster.
The
major
difference
in
this
case
is
that
crossplane
extends
the
reach
of
kubernetes
api
instead
of
managing
only
our
applications.
A
We
are
managing
things
not
only
inside
the
kubernetes
cluster,
but
also
outside,
and
in
this
case
outside
means.
Google
cloud
resources,
so
I'm
going
to
apply
this
and
voila
come
on,
go
go
there.
We
are,
we
got
two
kubernetes
resources
created
and
from
now
on,
cross
plane
will
take
this
as
the
desired
state
and
make
sure
that
the
actual
state
is
converged
into
that
desired
state.
A
It
will
make
sure
that
the
cluster
and
the
node
pool
is
not
only
created
in
google
cloud,
but
the
state
is
maintained
forever,
or
at
least
until
I
change
my
opinion
and
change
the
desired
state.
So
crossplan
is
doing
automated
drift
detection
and
reconciliation,
and
I
will
show
you
an
example
of
that
in
a
second.
For
now,
what
I
want
to
focus
on
is
the
api.
A
I
should
be
able
to
query
the
kubernetes
api
to
find
out
the
status
of
those
resources
and
I
can
say
something
like
hey:
get:
clusters
of
type
container
dot,
gcp
dot,
cross,
plane,
dot,
io,
and
I
can
see
I
should
be
able
to
see
in
a
second.
Yes,
there
is
a
cluster
and
right
now
that
cluster
is
being
provisioned.
Crossman
is
communicating
with
google
cloud.
It
is
telling
its
api
what
to
do
and
right
now
google
is
provisioning,
it
is
creating
the
cluster,
but
I
can
go
further.
A
I
can
do
things
that
other
tools
cannot
do
because
other
tools
in
that
area,
like
infrastructure
is
called,
do
not
have
an
api,
so
I
can
do
things
hey
give
me
the
status
of
all
gcp
resources
and
I
can
see
what's
going
on
with
all
the
resources
related
with
gcp
with
google
cloud.
There
is
a
cluster
that
is
being
provisioned
right
now
and
there
is
a
node
pool.
That
is
not
even
synchronized.
A
If
I
would
need
to
see
the
details
of
a
resource,
I
can
do
something
like
I
would
do
for
normal
kubernetes
applications.
I
can
say:
hey:
let's
describe
clusters,
container
dot,
gcp,
dot,
cross,
plane,
dot,
io
and
the
resource
I
want
to
describe
is
called
atm
gk
no
xrd,
and
now
I
can
see
all
the
details
about
that
specific
resource
in
this
case
of
a
kubernetes
cluster
of
gka
cluster,
including
the
events
that
are
happening
right
now.
Now
this
will
take
a
couple
of
more
minutes.
A
I
do
not
want
you
to
wait
until
google
cloud
creates
all
the
resources,
so
I
will
fast
forward
a
few
minutes
and
then
we
can
explore
drift
detection
and
reconciliation.
We
can
see
here
that
the
cluster
was
created
in
google
cloud
and
if
I
go
to
that
cluster,
I
can
see
that
it
is
fully
operational.
Everything
is
great
and
so
on
and
so
forth.
A
But
let
me
do
something
that
will
show
how
drift
detection
works
and
that
will
be
yet
another
thing
that
infrastructure
is
called
tools
cannot
do
simply
because
they
are
not
controlled
planes
they're,
not
monitoring
the
actual
state
and
trying
to
find
the
drifts.
So
I
will
go
to
nodes,
for
example,
and
I
will
simulate
that
something
terrible
happened
to
my
node
pool
by
deleting
that
node
pool
I'm
simulating
that
the
data
center
went
down
or
something
terrible
happened
with
the
node
pool
and
so
on
and
so
forth.
A
Now,
if
I
go
back
to
the
terminal
and
do
cube
cattle
get
node
pools,
I
should
see
that
from
the
corresponding
perspective,
it
is
still
running.
That's
because
the
node
pool
was
not
yet
fully
shut
down
and,
let's
see
what's
going
on,
node
pools
and
we
can
see
that
the
state
is
stopping
cross
plane
detected
that
the
node
pool
is
being
shut
down.
So
it
is
fully
aware
at
any
given
moment
what
is
the
actual
state
of
the
resources?
A
The
point
here
is
that
crossplane
is
making
sure
that
the
state
is
always
maintained
and
I
do
not
need
to
worry
about
it.
So,
instead
of
me
freaking
out
and
saying
hey,
I
do
not
know
what's
going
to
happen
better,
not
be
recreated
or
not,
and
so
on
and
so
forth.
I
will
just
go
and
get
myself
a
coffee
and
come
back
10
minutes
later,
because
hey
I'm
calm,
I
know
that
crossplane
is
going
to
figure
out
what
to
do
so.
A
Let's
see,
what's
going
on
cube
cuddle,
get
node
pools
and
it's
provisioning
cross
plane
with
its
drive
detection.
Reconciliation
figured
out
that
the
desired
state
and
the
actual
state
are
not
in
sync
that
there
is
a
drift
between
the
two
and
as
soon
as
it
could.
It
started,
creating
a
new
note
pool
so
that
the
state
is
maintained.
But
now
you
might
be
saying,
hey,
that's
a
simple
example:
I
want
something
more
complicated.
So
let's
do
that.
A
Let's
go
into
more
complex
example
and
see
how
we
can
manage
more
resources
at
once
and
how
we
can
enable
everybody
developers
testers
whomever
to
manage
infrastructure
services
and
applications
and
everything
else
in
an
easy
way
without
going
crazy.
So
if
you
want
to
enable
others,
we
have
three
options.
We
can
encourage
them
to
open
jira
tickets
so
that
other
people
can
create
infrastructure
and
services
and
deploy
applications
and
do
whatever
needs
to
be
done.
But
that's
not
the
goal
we
want
to
enable
others.
A
We
don't
want
others
to
depend
on
us,
so
opening
issues
and
tickets
and
requesting
hey
do
this
for
me
and
do
that,
for
me
is
not
an
option.
The
second
option
would
be
for
everybody
to
stop
what
they're
doing
and
dedicate
couple
of
years
of
figuring
out
all
the
details
about
how
aws
works
or
alibaba
or
whatever
we
are
using.
A
That's
not
a
good
idea
for
obvious
reasons,
so
we
need
to
think
of
a
different
solution
and
that
different
solution
is
to
create
services
that
others
can
consume
and
those
services
should
be
made
to
fulfill
the
needs
of
our
users
and
those
users,
as
I
said
before,
could
be
developers
could
be.
Testers
could
be
whomever
so
I'm
about
to
create
a
completely
new
custom
resource
definition
or
to
be
more
precise,
cross,
plane,
resource
definition
or
what
we
call
xrd.
That
will
generate
a
new
interface
and
it
could
look
something
like
this
cross
plane.
A
Config
definition
k
test.
So
this
is
an
open
api
here
we
are
open
api,
schema
that
says
hey.
Whenever
somebody
wants
to
manage
a
cluster,
there
should
be
some
properties,
and
those
properties
would
be
in
this
example.
In
this
scenario,
version
and
note
size
and
minimum
number
of
nodes
and
whether
they
would
like
to
manage
their
resources
through
githubs
and
if
they
do
what
should
be
the
repository
for
the
manifests
and
then
we
need
the
implementations
of
this
schema
and
one
possible
implementation
for
aws
could
be
cross
plane,
config,
composition,
eks.
A
So
this
is
an
implementation.
This
contains
all
the
details
that
are
required
to
run
a
cluster
successfully
in
aws
and,
as
you
can
see,
there
are
many
things
here,
because
what
we
do
is
complex.
We
need
to
do
a
lot
of
things.
Let
me
scroll
to
the
top.
If
I
ever
get
to
the
top
to
show
you
what
I
need.
If
I
want
to
run
a
cluster
in
aws,
where
is
the
top?
Where
is
the
top?
Oh,
my
god.
This
is
really
really
complex.
A
Here
we
are
so
I'm
creating
a
composition
which
will
be
an
implementation
of
the
schema
that
I
showed
you
before
and
that
one
will
create
a
cluster
and
then
it
will
create
a
node
group
and
after
that
it
will
create
an
iam
role
and
after
that
it
will
create
another
role.
Actually
it's
not
before
or
after
that,
crossplan
will
figure
out.
What
is
the
order
of
all
those
things?
A
I
will
install
argo
cd
in
that
cluster.
Actually,
I
will
not
install
anything.
Crossplane
will
make
sure
that
those
resources
are
up
and
running,
and
then
I
will
configure
kubernetes
provider
which
will
create
a
namespace
called
production
and
it
will
create
an
argo
cd
project
and
then
it
will
create
an
argo,
cd
application
and
so
on
and
so
forth.
The
details
are
not
important
right
now.
A
What
does
matter
is
that
I,
as
an
sre
or
operator
or
cs
admin,
can
define
what
infrastructure
and
services
and
so
on
and
so
forth
are
and
what
is
required
to
run
something
well,
but
this
will
be
hidden
from
everybody
else.
This
is
an
implementation
detail
because
remember
I'm
creating
a
completely
new
service
custom
made
for
my
organization,
so
others,
consumers
of
this
service
could
do
something
like
this.
Could
they
find
something
like
examples,
aws
cks.yaml
and
say:
hey.
I
want
to
create
a
cluster
claim.
A
Cluster
claim
is
the
name
that
I
gave
to
the
definition
that
I
showed
you
before
and
I
will
define
some
labels
and
say
hey.
I
would
like
to
have
a
cluster
in
aws
and
that
cluster
should
be
ks.
I,
as
a
user,
could
change
those
labels.
I
would
say
no.
I
would
like
alibaba,
for
example,
or
azure
or
google
cloud.
A
That's
an
implementation
detail,
it's
the
job
of
somebody
else
to
define
the
implementation
of
this
interface
of
this
cluster
claim
and
my
job
as
a
user
is
to
say
what
I
want
and
to
define
a
couple
of
parameters
like
hey
I
care
about
node
size.
I
would
like
my
nodes
to
be
small.
I
do
not
know
what
small
is.
I
assume
that
whomever
created
the
implementation
for
aws
in
this
case
knows
what
small
is
and
I
would
like
to
have
a
minimum
of
three
nodes.
So
I
is
a
developer.
A
As
a
user
can
write
this
example
and
just
say:
hey
cubecattle
namespace.
I
want
to
do
it
in
my
own
namespace,
a
team,
and
I
would
like
to
apply
something
defined
in
a
file
that
is
located
in
examples,
aws,
cks,
dot,
yaml
and
there
I
go.
I
created
that
single
resource
or
I'm
about
to
there
we
go.
I
created
a
single
resource
cluster
claim.
That
is
easy
way
for
me
to
define
what
I
want,
even
though,
behind
that
single
resource
there
are
many-
and
I
will
show
you
what
those
are.
A
A
C
Most
exciting
things
for
me
is
tetherjet
and
the
blast
provider
coverage
that
it
will
get
us
teleget
is
a
project
called
code
generation
project
that
will
let
anyone
to
generate
a
crossplane
provider
using
a
telephone
provider.
You
can
essentially
take
one
telephone
provider
and
produce
code
controller
code
and
every
nci
design
everything
using
terajet
with
that
project,
we're
going
to
have
like
thousands
of
crds
available
for
you
to
use,
and
now,
like
you
know,
we
have
aws
and
azure,
but
you
can
use
any
telephone
provider
you
would
like
for
that
purpose.
C
C
This
will
allow
us
to,
like
you,
know,
scale
the
number
of
composite
and
claim
resources
to
or
drop
like
a
ten
thousands
right
now
we're
able
to
scale
the
two
thousand
or
three
thousand.
I
think
users
are
reporting,
but
with
these
improvements
will
get
even
higher
with
less
resource
usage,
and
the
next
thing
is
pluggable
secret
stores.
C
So
there
have
been
lots
of
users
asking
for
a
way
to
not
use
kubernetes
secrets
for
various
reasons,
and
one
of
the
other
tools
that
were
that
was
requested
was
using
vault
as
the
store
for
credentials
of
the
cloud
resources
that
crosstalk
provisions,
so
that
will
come
with
with
pluggable
secret
server.
You
can
just
choose
secret
source,
you
would
like,
and
crosby
will
publish
secrets
to
only
to
those
resources
and
the
other
thing
is
custom
compositions.
C
That
can,
like
you
know,
render
anything
you
would
like
with
the
programming
language
that
you
choose
and
after
that
we
have
some,
like
you
know,
ux
improvements
like
composition,
validations
right
now
you
would,
you
would
have
the
templates
in
your
compositions,
but
they
would
get
validated
only
after
you
create
a
composite
resource
or
a
claim.
So
with
the
composite
composition,
validations
we
will
be
able
to
validate
them
before
they
make
it
to
the
api
server
and
observe.
C
Only
resources
is
another
feature
that
is
requested
by
the
community,
which
will
allow
us,
which
will
allow
users
to
make
a
managed
resource.
Only
observable
meaning
we
cross
plane
will
not
issue
an
update
or
deletion
or
anything
for
that
matter,
and
that
is
most
useful
in
cases.
For
example,
you
have
a
vpc
and
you
would
like
to
use
the
same
vpc
in
different
cross,
plane
environments,
so
having
it
reconciled
in
different
crossfit
environments
would
might
result
in
a
racing
condition.
C
However,
this
does
not
scale
to
all
all
use
cases.
In
some
cases,
the
source
custom
resource
does
not
know
about
the
target
references
resource.
In
those
cases
we
need
to
have
a
generic
way
to
tell
controller
that
hey,
go.
Take
that
value
convert
it
in
that
way,
and
only
you
know,
put
it
in
this
field
of
that
of
this
source
custom
resource.
A
This
was
a
very
quick
overview.
I
did
not
have
time
to
go
into
all
the
details,
because
I
think
that
the
session
should
be
25
or
30
minutes
or
something
like
that.
But
if
you
would
like
to
know
more,
just
come
to
the
slack
channel.
Ask
your
questions.
You
can
contact
me
directly
or
contact
the
community
as
a
whole
and
we
will
do
our
best
to
help
you
out
and
give
you
more
information
more
detail
about
crossplane,
because
trust
me.
I
only
scratch
the
surface.