►
From YouTube: Tutorial: Building an Enterprise Infrastructure Control Plane on Kubernetes - Daniel Mangum
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Tutorial: Building an Enterprise Infrastructure Control Plane on Kubernetes - Daniel Mangum, Upbound & Steven Borrelli, Mastercard
Enterprise infrastructure is diverse, complex, and difficult to automate. What if you could standardize on a single infrastructure control plane using the Kubernetes API? In this tutorial we will cover how to build Kubernetes controllers to manage infrastructure across enterprise infrastructure providers using the crossplane-runtime library, taking examples from the work that Mastercard has done to build a cohesive service catalog based on Kubernetes CRDs. Attendees will walk away with a functioning controller and building blocks for developing their own enterprise control plane. Topics covered will include: - Modeling Resources like Virtual Machines and Databases as Kubernetes CRDs - Sharing reconciler logic across controllers - Translating imperative API calls into declaratively managed Kubernetes objects Attendees should have Git, Go, and Docker installed prior to this session.
https://sched.co/ekFT
A
Yeah
and
today
we're
going
to
be
talking
about
a
project
that
I
think
is
really
cool,
we're
going
to
be
talking
about
building
your
own
enterprise
control,
plane
and
basing
that
on
kubernetes,
and
we
hope
to
show
you
that
this
is
actually
really
powerful
and
really
easy
to
do
so.
Really,
that's
kind
of
our
goals
for
this
talk.
First,
we
want
to
talk
about.
A
This
is
really
one
of
the
fundamental
concepts
of
kubernetes,
but
we
really
want
to
talk
about
why
controllers
are
really
one
of
the
best
ways
to
manage
your
internal
infrastructure,
and
we
want
to
kind
of
show
just
how
easy
it
is
given
a
lot
of
the
tooling
libraries
around
kubernetes
right
now,
so
just
really
quick.
What
our
agenda
is
today.
This
is
an
85
minute
session.
A
I'm
going
to
do
a
few
minutes
of
an
introduction,
just
basically
talking
about
what
infrastructure
is
and
how
people
are
doing
it
today
and
then
we'll
really
get
into
a
lot
of
coding.
Where
we'll
be
talking
about
actually
developing
your
own
controller
and
during
that
we're
basically
going
to
walk
through
all
the
parts
of
doing
that.
A
That's
from
defining
your
custom
resource
definitions,
talking
to
the
remote
api
that
you
want
to
manage,
actually
how
you
get
into
the
guts
of
a
controller
and
do
credit
operations
and
then
finally,
we're
gonna
do
some
more
advanced
things
like
packaging,
your
controller
up,
so
you
could
deliver
it
to
clusters
and
then,
finally,
there's
some
really
cool
higher
level
abstractions.
We
could
do
where
you
could
take
other
people's
controllers
and
other
people's
kubernetes
objects
and
combine
them
to
make
more
complex
infrastructure.
A
So
first,
when
we
talk
about
infrastructure,
what
do
we
mean
if
you
look
at
now?
What
a
lot
of
companies
are
provisioning?
What's
in
the
scope
of
infrastructure
teams,
it's
usually
things
like
storage
and
virtual
machines
and
folks
will
be
asking
for
firewall
rules
and
networks
and
dns
records.
So
whenever
someone
wants,
you
know
an
application
team
wants
to
deploy
something
they're,
usually
asking
for
a
lot
of
these
things,
and
if
you
look
at
how
infrastructure
teams
they
used
to
do
these
manually
and
then
slowly
they've
been
getting
into
automation.
A
A
A
lot
of
these
tools
are
migrating
it
to
go,
and
what
folks
usually
do
is
build
like
custom
scripting
on
top
of
devops
tools
like
chef
ansible
is
very
popular
and
probably
one
of
the
most
popular
provisioning
tools
recently
has
been
something
called
terraform,
which
is
really
good
for
managing
remote
apis
and
then,
finally,
like
the
run
time
for
these
platforms
is
usually
a
ci
system.
So
what
happens?
Is
somebody
commits
something
into
git?
A
The
ci
system
sees
it
and
you
know,
fires
off
these
scripts,
so
this
infrastructure
that
you're
building
on
top
of
your
custom,
scripting
using
some
devops
tools,
is
usually
fired
off.
You
know
with
a
ci
pipeline,
so
you
know-
and
this
is
basically
what
it
looks
like
kind
of
logically
right
so
usually
what
happens
is
you'll
define
your
own
spec,
and
you
know
I've
been
on
demo
days
where
every
single
team
defines
their
own
specs,
so
we'll
have
five
different
spec
files
introduced
during
one
demo
day.
A
You
usually
have
some
code,
especially
systems
like
jenkins,
that
allow
you
to
do
things
like
groovy
code,
that
you'll
start
seeing
running
shell
scripts
in
here
doing
some
advanced
logic
and
then
finally,
it's
the
stuff.
You
want
to
do
right,
like
you're,
you
have
to
like
compare
you
have
to
connect
to
the
real
remote
api.
You
have
to
compare
what
you
have
to
that
and
you
have
to
do
something.
A
A
A
The
next
thing
is
a
lot
of
these
things
are
very
command
line
driven
and
it's
very
hard
to
expand
export
these
as
an
api
to
developers
right.
So
the
developer
experience
usually
involves
opening
up
a
ticket
or
committing
something
to
get,
and
then
finally,
tooling,
is
very
basic.
You
know
you
might
be
able
to
edit
the
files
in
json,
but
there's
not
a
lot
of
other
dev
tools
that
support
it.
A
The
ci
pipeline
is
usually
the
the
main
thing
running
this,
and
probably
the
most
important
thing
about
this
is
like
these
fire
off
on
changes
in
git,
not
in
changes
of
desired
state.
So
you
know
it
doesn't
care
whether
you're
adding
a
comment
or
whether
you're
making
large
changes
it's
still
going
to
fire
it
off
and
usually
what
happens
is
it
runs
only
once
so
once
you
deploy
this,
it
doesn't
go
back
and
check.
A
It
doesn't
check
if
anything
is
drifted
or
anything
like
that
and
then
finally,
there's
a
lot
of
you
know,
especially
with
homegrown
tooling,
there's
a
lot
of
issues
around
reconciliation
and
state
management
and
usually
operations
is
you
know,
besides
sending
out
an
email
to
someone
if
a
job
fails,
is
pretty
much
the
most
of
the
operational
support
that
a
lot
of
these
tools
have
so
that's
kind
of.
If
you
look
at
what
the
vast
majority
of
like
internal
tools
are
right
now,
it's
pretty
much
like
this.
A
So
what
we
want
to
talk
about
since
we're
in
kubernetes,
we
want
to
talk
about.
How
do
we
do
this
in
a
way
that
you
know
is
kubernetes
centric
and
that
you
know
takes
advantage
of
the
kubernetes
platform?
So
the
first
thing
is
that
we
talk
about
the
controller
approach
right.
What
if
we
could
take
all
those
things
that
we
want
to
provision
them
and
model
them
as
kubernetes
objects?
So
you
know
we'll
have
a
sql
database
kind.
A
A
We
could
have
this
in
our
files
and
we
don't
have
to
think
about
the
spec
file
anymore,
because
it's
handled
by
somebody
else,
then
what
we
could
do
is
we
could
put
kubernetes
there
and
then
you
know
a
lot
of
the
great
things
about
kubernetes.
It
has
an
api
that
supports
a
lot
of
different
tooling.
It
can
watch
for
events
for
you.
It
can
look
at
changes
and
things
like
that
and
notify
you
know
whatever
back
end.
You
want
so
that's
kind
of
a
powerful
pattern
and
then,
finally,
what
we
want
is.
B
A
For
each
one
of
these
things
that
we
want
to
manage,
we'll
probably
have
a
controller
running,
and
this
will
be
constantly
trying
to
reconcile
whatever
desired
state
you
put
into
the
system
talking
to
the
external
api,
so
things
like
observability,
failover,
there's
a
whole
bunch
of
features
you
get
in
a
kubernetes
controller
that
basically
spending
all
its
time
trying
to
get
to
the
state
that
you've
asked
for.
So
it's
a
very
powerful
pattern
in
that
way.
A
So
what
we're
going
to
talk
about
in
this
tutorial
today
is
basically
how
we
build
in
all
the
layers
of
this
controller.
So
at
the
very
bottom
level
you
know
we
have
kubernetes
itself,
which
will
run
our
controllers,
which
run
adapter
containers
and
it'll
handle
things
like
well-based
access
controls.
If
you
want
to
put
a
firewall
in
front
of
this
or
a
load
balancer.
The
next
thing
is,
if
you
haven't
worked
with
kubernetes
before,
like
done
any
programming,
there's
this
entire
thing
concept
of
machinery
right.
A
This
is
how
all
the
apis
are
composed
and
there's
a
lot
of
great
things
here,
but
probably
one
of
the
most
important
things
that's
emerged
recently
is
this
idea
of
custom
resource
definitions
or
crds
you're
going
to
hear
these
a
lot,
and
this
is
how
you
can
make
custom
objects,
look
like
native
kubernetes.
So
if
you
want
to
define
your
own
type
like
a
virtual
machine
type,
you
can
just
apply
it
to
kubernetes
and
it'll.
Look
like
anything
else.
A
On
top
of
that
is
this
library
called
controller
runtime,
which
is
recently
become
probably
one
of
the
main
libraries
that
almost
everyone
who
writes
kubernetes
controllers
at
least
uses
the
sum
part,
and
this
takes
care
of
things
like
what
happens.
If
someone
applies
a
change
to
one
of
the
kubernetes
objects,
it
watches
it
helps.
You
do
reconciliation
on
kubernetes,
so
it
makes
it
very
easy
to
have
these
controllers
that
respond
to
changes
when
your
customers,
you
know,
want
to
ask
for
something
different.
A
Your
infrastructure
will
automatically
get
notify,
whatever's
watching
it
and
then,
finally,
probably
one
of
the
most
interesting
things
about
this
talk
is
across
plain
run
time
itself
and
crossplay
makes
it
really
easy
to
manage
external
apis.
Most
of
the
other
kubernetes
things
make
it
easy
to
manage.
Kubernetes
objects,
but
crossplane
makes
it
really
easy
to
say,
find
any
api
out
there
and
then
do
these
operations
and
treat
it
like
a
kubernetes
managed
infrastructure.
A
So
this
is
really
one
of
the
most
exciting
things
that
makes
it
really
good
for
building
your
own
software,
because
really
the
benefit
of
this
approach
is
that,
basically,
you
only
have
to
focus
on
kind
of
the
logic
in
your
controller
and
you
get
extremely
full-featured
control
planes
just
by
building
on
the
rest
of
this
things
that
are
constantly
reconciling
things
that
are
validated
via
open
api
at
the
client
level.
So
this
is
a
very
powerful
platform
and
you
can
spend
a
lot
of
your
time
just
focusing
on
your
logic.
A
And
finally,
I
you
know
it
has
to
be
said
that
you
know
when
you
have
native
kubernetes
controllers
for
your
infrastructure.
Suddenly
you
could
use
all
kinds
of
great
tools.
I
use
customize
a
lot
personally.
The
amazon
cdk
is
really
interesting
too.
I'm
a
big
fan
of
argo
cd
for
deploying
things
to
any
cluster.
It
does
zips
valero
could
back
it
up,
there's
cross-plane
demos
using
open
policy
agent.
So
it's
a
lot
of
exciting
things.
A
B
If
we
go
over
to
our
documentation,
we
have
a
helpful
getting
started
guide
which
we're
going
to
run
through
shortly
right
here,
so
I'll
start
off
by
going
ahead
and
spinning
up
a
kind
cluster
if
you're
not
familiar
with
kind,
it's
a
great
way
to
run
a
local
kubernetes
cluster.
So
it's
actually
going
to
start
a
cluster
running
in
docker
for
us.
So,
while
that's
coming
up,
let's
go
ahead
and
take
a
look
at
what
crossplaying
kind
of
proposes.
It
will
do
for
you
all
right.
B
B
But
the
first
thing
we
want
to
do
is
as
a
kubernetes
add-on,
install
crossplane
into
our
kubernetes
cluster,
so
you'll
see
here
we
have
the
alpha
and
master
channels
alpha
just
being
the
latest
release,
which
is
0.13
as
of
this
recording.
So
we
can
go
ahead
and
create
a
namespace
and
I've
already
added
the
crossplane
alpha
repo
here.
So
it's
just
going
to
be
one
command
to
helm,
install
crossplane.
B
B
If
you'd
like
to
manage
those
permissions
yourself,
instead
of
having
this
automated
workflow
with
the
rbac
manager,
you're
welcome
to
just
deploy
the
crossplane
pod
and
let
that
handle
all
the
work
for
you
all
right.
So
now
we
have
all
of
these
pods
running,
and
if
we
look
at
our
crds
here,
we
still
haven't
installed
very
much
in
the
terms
of
new
api
types.
You'll
see
some
kind
of
meta,
crd
types
like
packaging
for
configurations
and
providers
which
we're
going
to
look
at
momentarily,
but
you
don't
see
any
external
cloud
infrastructure.
B
Yet
that's
because
crossplane
comes
out
of
the
box
without
supporting
any
individual
providers,
so
it
differs
from
other
solutions
in
that
regard,
that
may
be
proprietary
to
a
single
cloud
provider
or
something
like
that.
We
have
a
provider
model
which
is
what
we're
going
to
be
designing
today,
but
we
also
have
a
number
of
providers
for
common
cloud
infrastructure
that
cross-plane
as
a
community
maintains.
B
So
we
can
go
ahead
and
go
into
the
documentation
here
and
the
first
thing
we
do
after
installing
crossplane
and
checking
the
status
is
install
the
crossplane
cli.
This
is
a
cube,
control,
plugin,
so
you'll
just
be
able
to
do
cube,
control,
cross
plane
and
a
variety
of
commands,
and
this
makes
it
really
easy
to
add
new
functionality.
B
So
we've
just
extended
the
functionality
of
our
kubernetes
cluster,
quite
a
bit.
By
being
able
to
right,
alongside
our
deployments
and
other
native
kubernetes
types,
create
external
infrastructure,
which
we
can
then
use
to
manage
our
infrastructure
on
those
cloud
platforms
and
connect
that
to
our
cross
plane
instances,
and
once
we
have
provider
aws
installed,
we
can
see
what
crds
it
brought
with
it,
and
we
can
also
see
that
there
is
a
controller
running
for
provider.
B
Aws,
that's
going
to
be
reconciling
those
resources
all
right,
so
the
next
thing
we
want
to
do
is
to
be
able
to
actually
provision
resources
on
aws.
We
need
to
create
a
secret
with
our
account
information,
which
we
have
a
helpful
command
here,
to
use
the
aws
cli
to
do,
and
then
we're
going
to
create
a
provider
config
which
basically
informs
crossplane
how
to
reach
out
to
the
aws
provider,
and
here
we're
going
to
use
the
secret
credential
source
to
be
able
to
do
that.
B
So
I'll
just
run
these
commands
real
quick
and
we
can
make
sure
that
we
get
something
installed
all
right.
So
we
created
our
file
and
then
we're
going
to
create
a
generic
secret
from
it
in
our
kubernetes
cluster,
and
the
last
thing
we
want
to
do
is
go
ahead
and
use
this
provider
config,
and
we
have
this
helpful
command
here,
where
you
can
apply
it
from
a
remote
url.
B
I
would
normally
advise
you
to
check
the
contents
of
something
before
you
apply
it
against
your
cluster.
But
since
we
have
a
local
cluster
here-
and
I
put
this
link
here-
we'll
go
ahead
and
do
it
all
right.
So
we
have
our
default
provider
config
here,
and
the
next
step
is
to
actually
provision
some
resources.
So
let's
go
on
to
the
next
section
and
look
at
provision
infrastructure
and
you'll
see
what
we're
going
to
provision
is
an
rds
instance
on
aws
and
we're
going
to
tell
it
where
to
write
our
connection
secret.
B
So
that's
another
big
part
of
cross
plane
which
we're
going
to
see
later
on
we're
designing
our
own
provider.
Is
you
know,
credential
information,
so
you
can
connect
this
to
your
workload,
so
you
can
have
a
deployment
that
talks
to
the
database.
We're
going
to
show
a
simple
example
here,
so
we're
just
going
to
provision
the
database
and
see
what
happens.
B
All
right
we'll
run
this
command.
It
looks
like
our
rds
postgres
instance
was
created
and
we
have
a
couple
of
shortcuts
that
will
help
you
get
resources
more
quickly.
So
you
could
do
something
like
kgit
aws
here
to
list
all
of
your
aws
resources,
which
this
frequently
has
large
gaps
in
it.
So
let's
do
something
more
specific
and
just
get
an
rds
instance
all
right.
B
Yet
and
since
we
specified
that
the
connection
information
should
be
written
to
this
secret,
when
the
resource
actually
becomes
ready,
we
should
be
able
to
get
secrets-
and
in
this
case
in
the
cross,
plane
system
namespace
and
see
that
it's
there
and
we'll
see
here
that
we
don't
see
the
secret
at
this
point
or
actually
we
do
it's
already
present.
So
that
was
given
to
us
by
the
actual,
create
operation.
B
When
this
is
finished,
provisioning
we're
going
to
see
more
connection
information
in
there
and
you
can
look
up
the
documentation
to
actually
see
all
the
connection
information
then
rds
instance
publishes
to
its
secret
and
then
you
can
specify
via
environment
variables
or
something
of
that
nature,
how
to
get
the
secret
into
your
deployment.
So
your
application
can
talk
to
it.
B
But
you
can
also
do
things
like
packaging
up
your
infrastructure
abstractions,
which
is
another
layer
on
top
of
these
primitives,
which
are
these
cloud
provider
resources
that
we've
installed
into
the
cluster
at
the
end
of
our
tutorial,
I'm
going
to
circle
back
and
show
you
how
we
can
create
some
of
these
primitives
and
package
them
up
all
right
so
now
that
we've
gotten
a
look
at
how
crossplane
works
and
how
you
can
extend
its
functionality
with
providers.
Let's
look
at
take
a
look
at
one
of
the
providers
that
we're
going
to
work
on
today.
B
This
provider
github
we're
calling
it
kubecon
provider
github
here
and
to
kind
of
motivate
the
discussion
we're
going
to
have
and
the
work
that
we're
going
to
do
today
and
hopefully
inspire
you
to
go,
write
your
own
providers.
Let's
take
a
look
at
what
this
can
do.
So
if
you
take
a
look
at
the
crds
in
our
cluster,
you'll
see
that
we
have
our
provider
config
and
provider
config
usage,
which
are
kind
of
the
plumbing
which
we'll
talk
about
in
a
little
bit.
But
the
primary
thing
we're
going
to
work
on
today.
B
B
B
But
for
now
we
just
want
to
show
that
we
can
create
one
of
these,
so
I'll
go
ahead
and
apply
that
resource
and
you'll
see
over
here
that
we've
got
some
log
messages
coming
from
our
controller,
which
is
running
against
a
local
kind
cluster
here
and
the
important
thing
we
want
to
see
that
our
external
resource
is
up
to
date.
So,
essentially
that's
saying
is
we
went
and
first
we
created
the
resource,
and
then
we
checked
to
make
sure
that
it
matches
the
configuration
that
we
specified
since
we
just
created
it.
B
It's
likely
that
that
happens
on
the
first
reconcile,
but
this
controller
is
going
to
go
ahead
and
make
sure
that
this
stays
in
sync.
And
if
we
look
at
our
team,
we
can
say
that
we
have
a
synced
team
here
and
if
you
looked
at
the
status,
we
can
get
a
little
more
detail
here.
You
can
see
that
there's
some
information
about
when
it
was
last
reconciled
and
we
can
customize
this
to
give
more
information
if
we
want.
B
So
if
you
look
at
the
configuration
we
had,
we
named
it
was
crossplan
and
we
have
our
description
and
then
we've
also
seen
that
it's
a
secret
account
so
we'll
show
how
you
can
maybe
modify
that
in
the
future,
but
before
we
jump
into
that
too
much
we've
seen
how
these
resources
and
different
apis
get
added
to
a
cluster.
So
stephen,
I
wanted
you
to
give
us
a
little
bit
of
insight
onto
what
is
a
crd.
A
Yeah,
thank
you
dan
yeah.
So
this
is
one
of
the
really
interesting
things
about
this
pattern.
Is
that
you're
going
to
hear
this
term
a
lot
if
you
haven't
heard
it
before,
and
this
is
a
custom
resource
definition,
and
this
is
basically
taking
things
that
are
outside
of
kubernetes
and
making
them
look
like
kubernetes,
and
what
we're
going
to
show
you
right
now
is
actually
the
code
for
doing
that.
A
A
If
you
looked
at
the
example
that
dan
showed
before
we
had
the
name
of
the
organization,
the
description
and
the
privacy
settings
right,
so
when
you
create
a
crd,
what
the
way
it
works
with
ku
builder
is
that
it
looks
at
your
go
code
and
then
the
make
files
generate
the
crd,
the
yaml
for
that.
But
then
you
apply
to
your
cluster.
So
this
is
how
everything
gets
mapped,
and
this
is
how
you
create
your
own
custom
kubernetes
objects.
Then
you
could
apply
to
a
cluster
and
have
controllers
manage.
A
A
You
know
what
it
needs
to
do
in
terms
of
reconciliation,
so
those
are
kind
of
the
key
things
in
terms
of
what
you
store
in
terms
of
your
settings
and
the
value
and
there's
another
two
important
fields
that
you'll
see-
and
this
is
pretty
much
present
in
all
coupe
builder
type
controllers.
There's
a
spec
and
a
status,
so
the
spec
is
the
desired
state.
That's
what
you
provide
to
the
cluster
say.
A
This
is
what
I
want
things
to
look
like
and
that's
the
thing
that
the
user
provides,
and
then
the
status
is
the
thing
that
the
controller
comes
back
with.
It
goes
talks
to
a
remote
resource
and
it
comes
back
and
gives
to
the
state
to
it.
So
these
are
two
of
the
important
concepts
about
building
out
a
kubernetes
api
crd.
B
Absolutely,
and
and
one
of
the
things
that
stephen
pointed
out
there
is
that
we
have
the
parameters
and
observation
and
we
have
the
spec
and
status
you
can
think
of
it
as
the
parameters
in
observation
being
the
provider
specific
fields
and
they
kind
of
roll
up
into
the
spec.
So
we
have
our
parameters
for
the
provider
specific.
B
In
this
case,
it's
github
that's
rolling
up
into
our
spec
here
and
then
the
status
we're
going
to
have
the
at
provider
fields,
and
this
is
just
a
cross
playing
pattern
we
have
and
then
within
the
crossplane
ecosystem.
We
also
have
these
embedded
structs
that
we
put
put
in
our
spec
in
status
and
that
just
provides
some
uniform
fields
across
all
of
our
resource
types
and
they're
used
to
do
things
like
connect
to
the
external
provider
via
the
provider
config,
which
is
another
type
which
we
can
look
at
quickly
here.
B
B
It
tells
you
how
to
connect
to
the
external
provider,
so
it
has
some
credentials
method
in
it
and
once
again,
you're
seeing
we
have
this
embedded
struct
and
these
embedded
types.
These
different
things
that
we're
going
to
kind
of
have
abstractions
presented
for
us
are
from
cross
plane,
runtime,
which
we'll
take
a
look
at
in
a
minute,
but
the
provider
config
spec
is
going
to
include
usually
a
kubernetes
secret,
but
you
can
also
provide
different
authentication
methods
and
the
status
is
basically
just
going
to
show
you
that
it's
able
to
connect.
A
And
one
of
the
nice
things
about
the
provider
config
is
that
you
could
have
multiple
providers
right,
that
you
could
be
managing
multiple
back-ends,
even
if
they're
same
platform,
they
could
have
different
credentials,
so
you
could
use
the
same
resources
and
apply
it.
You
know
using
two
different
accounts.
If
you
want
some
kind
of
dr
or
something
like
that,
so
what
providers
do
is
abstract
out
the
connections
and
it
gives
you
a
lot
of
flexibility
to
separate
out
your
resources
from
the
backend
provider.
So
it's
a
very
nice
pattern
to
implement.
B
Absolutely,
and
in
some
of
the
other
providers,
where
they
actually
have
kubernetes
clusters
themselves
will
have
things
like
use,
iam
roles
for
authentication
and
that
sort
of
thing
which
can
be
really
useful
and
some
of
that
separation
of
concern.
That
steve
was
mentioning
in
github.
You
may
have
two
different
access
tokens
that
you
want
used
for
different
organizations
and
that
kind
of
separates
you
from
you
know
creating
something
in
the
wrong
organization
or
something
like
that.
B
We
actually
don't
have
a
reference
to
provider
config
and
that's
because
crossplan
also
provides
the
ability
to
if
you
create
a
provider
config
with
the
name
default,
that
provider
is
going
to
go
ahead
and
use
that
one
if
none
is
provided
so
there's
little
goodies
like
that,
that
are
kind
of
sprinkled
throughout
the
cross,
plain
runtime
ecosystem
that
make
things
a
little
bit
easier
for
you
all
right.
So
we've
gotten
a
good
look
at
these
different
api
types,
but
you
may
be
wondering
how
those
translate
into
actual
crds
existing
in
our
kubernetes
cluster.
B
So
a
crd
is
a
resource
in
itself.
It's
a
custom
resource
definition
and
there's
a
controller
running
in
kubernetes
that
watches
for
custom
resource
definitions
and
basically
you're
dynamically,
adding
new
api
types.
So
we
have
to
create
those
custom
resource
definitions
to
then
be
able
to
create
something.
Like
a
team,
we
have
those
custom
resource
definitions
in
this
crds
directory
in
our
provider.
Github
here
and
you'll
see
that
it's
generated
and
looks
like
probably
any
other
custom
resource
definition
that
you
would
see.
B
You'll
see
that
those
different
fields
in
the
go
struct
were
actually
used
to
create.
This
schema
here
that
we
have
which
allows
us
to
have
validation
when
we
create
instances
of
our
team
resource
and
we'll
look
a
little
bit
more
at
that
down
the
road.
But
stephen
did
you
want
to
talk
a
little
bit
about
what
some
of
these
different
annotations,
specifically
the
cube
builder
ones,
do
for
us
in
that
generation
process.
A
Yeah,
if
you
look
in
the
code
before-
and
this
is
a
feature
of
q
builder-
you
can
see
here
that
there's
there's
validation
fields
in
cue
builder,
there's
print
columns,
there's
objects,
so
basically
we're
building
upon
a
lot
of
the
cube
builder
project
here
and
what
it
does.
Is
you
give
these
annotations
here
and
this
instructs
when
you
build
out
your
crds
exactly
how
to
represent
them?
So
there's
lots
of
things.
As
we
said,
you
know
it
has.
A
Recent
versions
of
kubernetes
with
the
crds
are
imposing
open
api
validation
on
everything
which
suddenly
means
that
now
that
you
build
this
out,
suddenly
you
have
validation
not
only
at
the
server
level,
but
newer
versions
of
kubernetes
actually
have
the
client
doing
validation
now
too.
So,
basically,
all
that
work
is
going
to
be
handled
for
you
and
all
the
tooling
we
can
automatically
validate
from
these
crds.
So
that's
something
very
powerful
yeah
and
that's
basically
it.
A
B
B
So
it
just
gives
you
kind
of
a
boilerplate
to
get
started,
but
one
of
the
things
we
do
in
that
is.
We
provide
this
generation
code,
which
you'll
see
just
has
go
generate
statements
which
will,
basically,
you
know,
run
for
you
when
you
run
go
generate,
and
this
is
a
convenient
way
to
actually
pin
external
binaries,
that
you
need
to
run
generation
methods.
So
controller
gen
is
kind
of
the
cube
builder
flavored
generation.
That's
creating
these
deep
copy
methods
for
us,
as
well
as
generating
the
crds.
B
According
to
those
directives
that
we
were
just
pointing
out
there
and
you'll
see
that
we
provide
some
information
to
controller
gen
here,
to
tell
it
where
we'd
like
those
crds
to
go
angry
jet
is
our
cross
plane.
Flavor
of
that,
and
that
does
things
like
generate
our
manage.go
here,
our
pc.go,
which
are
basically
helper
methods
to
help
us
interact
with
these
different
classes
of
resource
commonly
called
duct
types
in
the
kubernetes
ecosystem.
B
So
once
we
have
these
api
types
defined
next
thing
to
do
is
to
define
how
we're
actually
going
to
talk
to
the
external
provider
so
frequently
there's
going
to
be
a
sdk
for
whatever
provider
you're
talking
to,
and
you
can
just
kind
of
look
at
the
go
types
there
and
how
to
authenticate
and
follow
that
pattern.
In
your
controllers
in
plane,
we
generally
like
to
separate
our
clients
and
controllers
into
two
separate
directories.
B
So
importantly,
we
saw
earlier-
and
I
believe
it's
still
running
over
here-
that
our
controller
basically
continuously
runs
and
outputs
some
information
and
what
it's
doing
is
watching
these
api
types
that
we've
defined,
and
so
we
have
a
single
entry
point,
as
you
generally
will
for
a
go
binary.
So,
let's
take
a
minute
to
look
at
what
we're
doing
here.
B
An
important
thing
to
realize
is
we're
heavily
relying
on
controller
runtime,
which
basically
gives
you
a
general
framework
for
running
a
bunch
of
controllers
together
in
what
they
call
a
manager,
so
some
different
options
that
you
can
supply
here
to
the
manager.
We're
just
saying
the
sync
period,
so
we're
not
configuring
it
too
much.
B
But
the
important
thing
to
note
here
is
that
we
have
the
controller
manager
and
then
we're
adding
our
apis
to
the
scheme
so
right
now
that
would
be
our
provider
config
and
our
team
resource
and
then
we're
doing
our
controller
setup
and
then
we're
starting
our
manager,
which
is
basically
going
to
run
all
these
controllers.
Anything
we
provide
in
the
setup
here
and
keep
those
running
and
watching
the
resources
and
they'll
it'll
be
notified
by
the
kubernetes
api
server.
When
events
happen
on
those
resources,
so
the
setup
method.
B
This
is
just
kind
of
a
wrapper
around
some
other
setup
methods
and
what
it's
doing
is
actually
setting
up
these
controllers
and
registering
them
with
the
manager.
So
we're
not
going
to
look
too
much
at
the
config
setup
today,
which
basically
just
watches
provider
configs
and
takes
some
actions
based
on
that,
essentially
confirming
that
they're
not
in
use
when
they're
cleaned
up,
because
if
you
lost
connection
while
you're
still
trying
to
reconcile
a
managed
resource
type
like
the
team,
that
would
obviously
be
a
bad
experience.
B
So
in
the
setup
method,
you'll
frequently
see
in
a
queue
builder
project
that
someone
has
defined
a
reconciler
and
they're,
basically
populating
it
with
whatever
fields
they
need
and
then
they're
doing
this
new
controller
managed
by
and
specifying
the
resource
they
want
to
watch
instead.
Here
we
have
a
call
to
this
manage.new
reconciler
method.
B
So
obviously,
when
a
resource
gets
created,
you
want
to
take
action
based
on
that
and
you
may
want
to
call
different
external
methods
based
on
the
status
of
your
or
really
the
specification
of
your
resource
in
your
kubernetes
cluster
and
then
manage
reconciler
takes
care
of
a
lot
of
that
for
you
so
steven.
I
know
you
have
a
lot
of
experience
with
writing.
Kubernetes
controllers,
we'll
look
especially
into
the
different
implementations
of
the
different
methods
that
are
part
of
the
manage
reconciler
that
we
define
in
cross
plane
runtime,
but
you
wanna.
A
Yeah,
actually,
one
of
the
things
that
really
attracted
me
to
cross
play
in
the
beginning
was
that,
if
you've
ever
written
a
controller
yourself
there's
a
lot
of
manual
things
you
have
to
do
in
terms
of
reconciliation,
logging,
creating
events,
you
know
having
written
a
lot
of
infrastructure
software,
you
kind
of
repeat
the
same
patterns
over
and
over
again,
and
actually,
as
we
walk
through
this,
we'll
find
out
that
there's
a
very
structured
way
that
crossplaying
does
it
that
layers
on
top
of
kubernetes
controllers.
That
makes
it
very
easy.
A
You
know
to
understand
the
logic.
So
I
think
that's
good,
and
the
most
important
thing
to
understand
is
that
this
controller
is
basically
a
piece
of
software.
That's
going
to
run
in
your
cluster
that
when
we
look
at
that
setup
it
basically
when
you
bring
it
up
it
registers
and
says
I
want
to
listen
to
anything
that
defines
a
team
right.
That's
what
the
setup
does
right
here.
A
You
know
that's
the
most
important
thing
because
when
you
first
look
at
this
there's
like
15
different
concepts
that
you
have
to
understand,
the
most
important
thing
to
understand
is
that
you
want
to
you
see
if
you
look
at
line
55
you're,
looking
and
you'll
see
this
group
version
kind
here.
This
is
pretty
common
in
kubernetes.
This
is
the
you
also
see
it
like
gvk
in
some
of
the
source
code,
and
this
is
basically
like
a
kind
would
be
the
team.
You
know
the
version
would
be.
A
You
know
the
group
would
be,
it
would
be.
A
combination
of
you
know,
hashtan,
you
know
github
io
and
the
version,
which
is
the
api
version.
Yeah,
so
you'll
see
this
a
lot.
Yeah
you'll
see
these
terms.
You'll
see
these
a
lot
in
kubernetes.
I
remember
the
first
time
I
did
like
when
I
was
playing
with
customize
that
it
kept
giving
me
gvk
errors,
and
I
had
no
idea
what
those
were
so
to
save
you
some
pain.
That's
this
is
what
it
comes
from
here,
yeah.
So
that's
basically
it.
A
This
is
the
core
of
this
setup.
There's
a
lot
of
things
that
have
to
be
called
here,
but
if
you
look
at
it,
it
says
we're
going
to
reconcile
teams
with
an
external
connector,
which
means
we're
gonna
connect
to
the
github
api,
and
then
you
say
with
logger
and
recorder,
and
these
are
nice
fields,
because
basically
this
sets
up
all
your
logging
and
events.
A
B
And
I
like
these
different
methods
that
we
have
here
these
with
methods
which
are
basically
saying
I'd
like
to
provide
this
kind
of
like
customized
option
for
this
thing.
But
if
we
actually
look
over
to
the
new
reconciler
code
here,
there's
a
lot
of
sane
defaults
that
we
provide
for
you,
one
of
those
being
things
like
defaulting
to
that
provider
config.
That
has
the
default
name
if
one
is
not
specified.
B
So
we
have
a
lot
of
different
hooks
to
customize
this
behavior
and
if
we
scroll
down
here
a
bit,
this
is
actually
the
the
reconciler
that
you'd
see
a
little
more
traditionally
in
a
q
builder
controller
or
something
like
that,
you'll
see.
We
have
some
default
fields
here,
things
like
setting
finalizer,
which
you
don't
have
to
worry
about
at
all
when
you're
writing
a
crossplane
controller,
because
we'll
take
care
of
that,
you
can
obviously
provide
your
own
api
finalizer
to
do
that.
B
Another
important
one
that
I
wanted
to
point
out
here
which
isn't
going
to
be
relevant
for
us
today,
because
there's
not
really
connection
information
for
a
github
team,
but
if
you're
provisioning,
a
database
or
kubernetes
cluster,
or
something
like
that.
There's
some
connection,
information
that
you
want
to
get
back
into
your
cluster,
so
you
can
reach
out
and
communicate
with
that
resource.
You've
provisioned!
B
So
we
have
a
default
api
secret
publisher,
which
is
going
to
publish
those
secrets
into
the
kubernetes
api.
And
then
you
know
you
can
run
a
deployment
that
consumes
that
either
through
an
environment
variable
or
by
getting
that
resource
directly
or
you
could
say,
I'd
like
to
provide
my
own
secret
publisher,
which
is
going
to
you
know,
send
these
secrets
to
vault
or
something
like
that.
B
A
Yeah
and
the
secret
propagation
is
really
a
great
feature
because
it's
very
underrated
like
when
you
deploy
a
new
system
and
you
get
some
credentials
back.
How
do
you
actually
get
that
back
to
the
user?
Who
requested
you
know
like
you,
give
them
a
database
and
they're
like
well
now
I'd
like
to
have
the
credentials
and
then
usually
somebody
has
to
go
log
in
somewhere
and
generate
them
or
hook
up.
You
know
some
external
systems.
So
it's
really
a
nice
feature
to
have.
B
A
And
this
is
yeah
and
an
important
thing
about
reconcile
here
and
dan
referred
to
it
slightly.
Is
that
if
you
look
at
a
classic,
you
know
kubernetes
controller,
they
usually
have
a
pretty
light
reconciler
and
then
expect
you
to
put
all
the
logic
in
there
and
there's
a
lot
of
corner
cases
and
logic
that
you
need
to
think
about
when
writing
your
own
reconciler,
especially
for
like
infrastructure
tasks.
So
this
actually
makes
it
a
lot
easier
to
go
through
the
common
patterns
of
managing
and
provisioning
infrastructure.
So
the
reconciler
is
actually
very
powerful.
B
Definitely,
and
if
you
want
to
dive
into
some
of
the
actual
work,
that's
happening
here
in
the
reconcile
loop,
which
we're
going
to
get
into
a
little
bit
more
in
a
moment.
But
this
is
your
generic
reconcile
loop
that
the
controller
manager
is
going
to
say.
Okay,
this
thing
has
registered
for
events
that
happen
on
teams.
Every
time
I
send
an
event.
I
need
to
run
this
reconcile
loop,
so
that's
what's
actually
getting
called
and
we're
just
basically
configuring.
This
reconcile
loop
in
our
controller.
B
The
connector
basically
has
a
single
method,
which
just
is
connect,
and
this
is
telling
me
how
do
I
get
this
external
struct,
which
has
our
crud
methods
on
it
that
are
going
to
be
called
by
our
manage
reconciler,
and
then
the
external
obviously
is
what's
returned
by
the
kinect
and
has
all
those
methods
defined
on
it.
So
before
we
get
into
external,
which
is
kind
of
the
meat
of
how
we
talk
to
the
external
provider,
let's
look
a
little
bit
about
the
connect
method.
B
So
we've
already
eluded
a
little
bit
when
looking
at
the
api
types
to
the
fact
that
we
use
this
provider
config
to
get
credentials
to
talk
to
an
external
api.
So
you'll
see
that
we
have
our
provider
config
type
here.
So
this
is
referencing
our
apis
directory
that
stephen
mentioned
earlier,
and
we're
basically
using
our
kubernetes
client
to
be
able
to
get
that
provider
config.
So,
as
I
mentioned,
every
manage
resource
has
a
provider
config
ref
and
we're
using
that
here.
B
B
That
basically
takes
the
string
and
gives
us
a
github
client
in
return.
One
of
the
benefits
of
kind
of
moving.
Some
of
this
client
logic,
which,
like
I
said,
is
admittedly
very
small
here
out
of
our
controller
body-
is
that
it
allows,
when
you
have
many
many
controllers,
to
not
have
to
duplicate
all
that
code.
So
basically
we're
just
going
to
return
from
our
connect
method.
Our
external
struct
populated
with
our
github
client,
which
is
now
authenticated.
B
So
now's
the
the
real
kind
of
meat
of
what
we're
doing
when
we
talk
to
the
external
api
and
that's
our
crud
methods,
so
we
have
observe,
create,
update
and
delete.
So
I
guess
it's
not
really
crud,
because
we're
using
observe
instead
yeah,
but
they
they
basically
get
called
in
fairly
sequential
order
that
you'd
imagine.
And
so
when
we
return
this
external
struct,
the
manage
reconciler
is
gonna,
say:
okay,
I
see
that
you
connected
successfully
and
now
I
have
this
external
type
and
I'm
going
to
call
these
in
a
logical
order.
B
So
the
first
thing
we're
going
to
do
is
observe
the
resource
and
based
on
the
result
we
get
back
from
that
we're
going
to
take
further
action.
So
if
the
resource
was
deleted
in
the
kubernetes
api,
then
we're
going
to
call
the
delete
method
on
the
external
that
was
returned
and
we'll
skip
over
some
of
this
other
logic.
For
a
moment
if
the
resource
does
not
exist.
B
So
if
we
observed
and
said
hey,
I
couldn't
find
this
in
the
external
api,
we're
going
to
call
the
external,
create
method
and
do
some
operations
and
then
the
last
thing
that
we're
going
to
look
at
is
is
the
resource
up
to
date.
So
if
the
observation
says
hey
this
resource
exists,
but
it
doesn't
match
that
spec
that
we
were
talking
about
earlier,
which
is
our
desired
state
of
the
resource.
Then
we
need
to
issue
an
update
and
it's
going
to
call
that
update
method
that
that
you
supplied.
B
B
So
here
we're
going
to
get
our
team
from
the
api,
so
you'll
see
that
we're
providing
that
org
and
the
name
of
the
resource
which
we
want
to
also
represent
the
name
of
the
team
on
github,
and
if
we
get
an
error
back
from
the
github
api,
we're
going
to
go
ahead
and
say
we're
going
to
go
ahead
and
return.
Our
external
observation,
which
is
that
struct
type,
that
the
manage
reconciler
is
going
to
check
and
you'll
see
it.
Has
these
three
fields
here
resource
exists,
resource
up
to
date
and
connection
details.
B
B
B
So
eventually
the
manage
reconciler
is
going
to
get
to
the
create
method
and
say
I
need
to
call
this
because
the
resource
doesn't
exist
yet
and
you'll
see
that
we're
once
again
using
this
team
service
from
the
github
client
to
create
our
team,
with
the
configuration
that
we've
defined
in
our
api
type
and
based
on
the
result
we
get
back
from
that.
We
return
an
external
creation
which
once
again
allows
us
to
supply
additional
connection
details
if
needed,
and
we
also
return
an
error.
B
So
if
the
manage
reconciler
gets
an
error
back,
it's
going
to
say:
okay,
I
see
that
I
tried
to
create
this
resource,
but
it
didn't
work.
So
I'm
going
to
try
again
in
a
little
bit
and
some
of
this
timing
and
the
delays
that
happens
between
reconciles.
Those
are
also
defaults
that
we
set
that
seem
to
be
common
accepted
patterns
for
the
managed
resources
that
crossplane
provides,
but
you
can
also
override
those
just
like
any
of
the
others,
with
providing
your
default
weight
and
that
sort
of
thing.
A
And
I
want
to
comment
something
here
this
pattern
here,
because
usually
when
you
write
a
lot
of
infrastructure
software,
you
usually
have
like,
if
then
statements
here
when
you're
comparing
things
one
of
the
nice
things
about
this,
is
that
this
returns
immediately
and
puts
it
in
the
reconcile
loop
there's
times
if
you're
provisioning
things
like
vms,
it
might
take.
You
know
20
30,
60
minutes
to
do
something
this
you
could
actually
keep
observing
it.
A
You
know
and
come
back
with
different
kinds
of
status,
like
other
tools
will
just
block
a
lot
of
times
and
not
return,
whereas
this,
usually
you
have
this
like
reconciliation,
loop
thing
where
it
could
keep
just
checking
in
the
background
for
you.
So
that's
very
nice.
So
this
is
kind
of
a
different
pattern.
If
you've,
you
know,
spent
a
lot
of
your
career
doing
if
exist,
then
this.
A
B
B
But
in
that
status
we
have,
I
think,
a
stage
field
for
their
bare
metal
device
type,
and
we
update
that,
as
you
were
saying,
as
it
goes
along,
so
you
can
kind
of
monitor
the
you
know
success
of
your
resource
provisioning
and
it
actually
provides
you
a
percentage
value.
So
it's
really
nice
to
do
your
cube,
control
describe
and
see.
Oh,
my
vm
is
77.
B
B
B
We
want
up
to
date
to
be
false,
and
then
we
do
that
same
check
for
our
privacy
field
here
and
then
based
on
that
we're
going
to
return
whether
the
resource
is
up
to
date.
If
we
return
false
there,
then
we're
once
again
going
to
call
the
update
method
which
is
going
to
use
this
edit
call
here
to
be
able
to
edit
our
team
and
set
it
to
the
fields
that
we
want.
Once
again,
you
can
provide
your
connection
details.
B
B
So
I
think
that
was
a
pretty
good
overview
of
of
what
you
can
do
here
with
the
controller
and
we've
got
a
pretty
full
working
controller
here
with
not
too
many
lines
of
code
and
a
lot
of
it
boilerplate
that
we
just
populated
ourselves.
So
what
do
you
say?
We
actually
maybe
change
a
little
bit
of
the
behavior
here
and
try
and
rerun
it
again
and-
and
we
can
see
how
this
helps
us
and
how
this
continuous
reconciliation
works.
B
So
one
of
the
things
that
I
pointed
out
earlier
is
we
have
this
node
id
field,
but
we
don't
actually
set
the
node
id
anywhere
in
our
controller
and
if
we
looked
at
the
yaml
output
here,
you'll
see
that
our
at
provider
is
just
empty
and
I'd
like
to
know
the
node
id
just
because
sounds
interesting,
so
you
know
to
populate
our
status.
We
usually
do
that
in
the
observe
method
here,
so
we
can
do
that
by
just
saying
okay.
B
B
Does
not
equal
nil,
then
we'll
go
ahead
and
set
that
and
I'm
actually
just
going
to
go
ahead
and
show
some
of
the
methods
that
we
defined
to
also
make
this
development
experience
really
nice
for
you.
So
when
you
clone
from
that
provider
template
we
have
a
make
file
in
here.
Just
has
some
really
simple
targets
I
like
to
do
this,
make
run
one
which
is
going
to
regenerate
your
crds
apply
them
to
the
cluster.
In
this
case
we
have
no
changes
and
it's
going
to
start
your
controller.
B
You
closed
basically
just
means
it's
visible,
so
let's
go
ahead
and
hop
over
to
our
kubecon
in
a
org
here
and
modify
this
a
little
bit
and
see
how
crossplane
drives
it
back,
and
this
is
a
bit
of
a
trivial
example.
But
stephen,
have
you
seen
any
kind
of
like
different
examples
in
your
experience
that
are
a
little
more
powerful
in
demonstrating
this
functionality.
A
Well,
I
think
this
is
good
just
for
compliance
purposes
right,
like
the
like
immediately
like
one
of
the
biggest
concerns
we
have
is
that
people
are
making
changes
manually
like
they're,
adding
users
they're
changing
permissions,
and
we
want
to
make
sure
that
if
that
happens,
that
gets
corrected
pretty
quickly
and
thanks
to
like
having
things
like
events
and
kubernetes,
you
could
actually
see
what's
happening
right.
You
could
be
notified,
so
I
think
that's
probably
one
of
the
best
use
cases
for
it.
B
For
sure
I
I
totally
agree
with
that,
and
a
nice
thing
is
we're
using
the
default
weight
here,
which
basically
checks
every
minute
to
make
sure
that
things
are
up
to
date.
You
can
obviously
configure
that
to
what
you
see
fit.
So
if
you
said
you
know,
I
need
to
be
more
stringent
or
I
really
only
need
to
check
this
resource
every
so
often
you
know
once
a
day,
maybe
and
see
if
it's
been
updated,
that
works
for
you
as
well.
B
Obviously,
if
you
modify
the
resource
in
the
kubernetes
cluster,
then
that's
going
to
be
an
immediate
action
taken,
but
I'm
going
to
go
ahead
and
set
this
to
visible
and
save
the
changes,
and
we
should
see
that
this
is
now
visible.
You'll
no
longer
see
that
secret
and
if
we
hop
back
over
to
our
controller
here,
our
last
status
here
was
external
resources
up
to
date.
B
But
if
we
actually
wait
a
few
minutes,
you
can
see
our
time
here.
So
we
should
be
coming
back
on
a
reconcile
again,
we'll
actually
set
that
field
back
to
secret
and
we'll
see
that
updated
and
while
we're
waiting
on
that,
we
can
also
do
the
opposite
right
and
modify
these
fields
in
our
resource
and
then
see
that
propagated
to
the
external
resource,
which
will
show
momentarily.
B
All
right,
so
there
we
see
that
we
got
a
successfully
requested
update
of
external
resource.
This
information
is
just
because
we're
actually
printing
out
the
struct,
for
you
know
a
demo
purpose
here,
but
we
should
see
if
we
hop
back
over
here
to
the
org
that
it's
once
again
in
secret
mode,
so
it's
basically
making
sure
that
you
stay
compliant
and
this
gets
really
powerful,
and
this
is
one
of
the
benefits
of
standardizing
on
the
kubernetes
api.
When
you
leverage
other
projects
as
well.
B
So
a
demo
we
like
to
show
a
lot
is
integrating
with
opa
and
one
of
the
examples
we've
shown
there
is
creating
a
database
that
you
know
you
want
to
have
a
limit
on
the
size
of
a
database.
Someone
can
create.
So
you
don't
have.
You
know
a
gcp
cloud.
Sql
instance:
that's
500
gigs,
or
something
like
that
costing
you
a
lot
of
money
in
a
development
environment.
You
could
create
a
open
policy
agent
policy.
B
B
If
I
can
type
here
and
we'll
save
that
and
I'll
go
back
to
the
terminal
and
like
I
said
when
you
change
the
spec
in
your
kubernetes
resource,
we're
going
to
see
immediate
action
taken
on
that
behalf,
because
the
controller
is
getting
an
event
from
the
kubernetes
api
server.
So
we'll
say
examples
org
team,
and
we
should
see
that
that
immediately
requests
an
update
of
an
external
resource.
B
So
we'll
quickly
see
that
propagated.
Now
it
says
some
other
description
and
we
can
also
manage
the
deletion
of
our
resource.
So
I'll
do
k,
delete
team
all
here
and
you'll
see
that
we
successfully
requested
deletion
of
external
resource,
and
it's
actually
going
to
reconcile
again
here
in
a
moment
and
make
sure
that
that's
actually
been
deleted
externally
and
then
allow
this
resource
to
be
cleaned
up.
B
B
We've
talked
about
having
a
cross-plane
cluster,
basically
manage
those
for
us
and
then
having
a
git
ops
pipeline
that
sends
some
of
our
you
know
cube
control
changes
basically
through
it
that
create
new
repositories,
update
teams,
update
permissions,
etc.
If
we
go
back
over
here,
you'll
see
that
our
team
has
been
deleted.
A
A
Whatever
features
and
parameters
that
you
want
to
manage.
Whatever
things
you
want
to
look
at
and
those
automatically
get
generated
into
crds
that
you
apply
to
your
cluster,
you
also
have
multiple
providers
that
you
can
talk
to
on
the
back
end
with
different
kinds
of
credentials.
If
you
want
to
segregate
out
which
accounts
can
do
what
on
different
parts
of
infrastructure.
So
that's
the
first
part
defining
our
api.
Then
we
define
the
controller
and
the
controller
has
three
main
functions.
A
One
of
those
is
to
talk
to
the
kubernetes
api
and
look
for
events
for
our
type,
our
team.
The
next
thing
is
the
connector,
where
it
actually
talks
and
creates
a
connection,
a
client
connection
to
github,
where
it's
going
to
talk
to
the
api
and
then
finally,
we
have
our
managed
events
right.
We
observe
the
external
resource
and
based
on
what
happens
in
an
external
resource,
we
either
create
update
or
delete
the
resource.
So
these
are
the
core
parts
of
the
controller,
and
you
can
see
here.
A
A
B
Okay,
so
now
that
we've
built
our
provider
out,
I'd
like
to
show
how
we
can
package
it
up,
push
it
to
a
registry
and
install
it
just
like
we
did
with
provider
aws
before
we
did
this
tutorial.
So
we
have
some
helpful
commands
here
and
to
start
off,
we
need
to
build
the
controller
binary,
which
is
what's
going
to
run
in
our
pod
and
manage
our
crds
package
that
into
an
image
and
then
push
it.
B
First
thing
we
need
to
do
is
make
build
and
you'll
see
that
we
are
running
the
build
there
and
while
we're
doing
that,
we
can
actually
go
ahead
and
go
into
the
package
directory
and
start
the
build
of
our
other
image.
Since
it's
just
going
to
have
a
reference
to
this
one
which
will
exist
after
we
push
it.
B
So
it
looks
like
that.
Build
is
still
going
so
let's
go
ahead
and
build
our
package
image.
So
we
have
some
helpful
commands
in
the
cross
plane
cli
here
we
can
say,
create
k,
cross
plane,
build
provider
and
since
we're
in
this
package
directory,
it's
going
to
go
ahead
and
look
at
the
crossplan.yaml
and
know
how
to
produce
a
package
all
right.
B
So
if
we
look,
we
should
see
that
we
now
have
this
x
package
directory,
which
is
basically
a
specialized
tarball,
which
is
an
oci
image
that
can
be
pushed
and
the
crossplan
cli
is
going
to
know
how
to
do
that
and
format
it
correctly.
But
before
we
do
that,
let's
go
ahead
and
finish
making
our
image
here.
So
that
was
a
pretty
quick
image,
build
and
I'll
go
ahead
and
make.
A
B
So
let
me
scoot
this
over
a
bit
and
we
can
look
at
what
we
have.
I
already
installed
crossplane,
so
we
have
the
cross
plane,
pods
running
and
let
me
go
ahead
and
just
close
out
this
window.
So
it's
a
little
easier
to
see.
So
we
have
our
cross
plane,
pods
running
and
just
like,
we
did
before
the
tutorial
to
install
provider
aws.
B
We
now
want
to
do
the
same
thing
with
provider
github,
so
we
can
do
k,
crossplane,
install
provider
and
I'll
specify
that
image
that
I
just
pushed,
which
was
hashdan
kc
provider
github,
and
we
want
v0.0.1
all
right.
So
it
looks
like
that
was
created.
It
will
take
it
just
a
moment
to
get
installed
so
you'll
see
it
doesn't
have
a
status
yet.
But
if
we
keep
watching
this,
we'll
actually
see
that
it
does
come
available.
So
it's
installed,
it's
not
healthy.
B
Yet
if
we
check
again,
it
looks
like
it
is
healthy
now
and
we
can
see
that
crossplane
has
looked
into
the
contents
of
our
package
and
it's
gone
ahead
and
started
our
controller
for
us.
So
we
see
our
kc
provider
github
running
here
and
we
can
also
see
that
we've
installed
crds.
They
were
specified
in
our
package.
So
here
we
have
our
provider,
config
provider,
config
usage
and
our
team
crd.
B
B
That
was
in
examples,
org
team
and
we
should
be
able
to
k,
get
team
and
see
that
it
is
synced.
And
if
we
go
back
over
to
our
github
org,
we
now
have
our
team
here
again
so
packaging
things
up
as
a
provider
makes
them
a
lot
easier
to
install
and-
and
you
can
also
have
specifications
for
how
you
want
to
reproduce
whole
environments.
So
maybe
you
want
environment
with
github,
aws
and
gcp
installed,
and
you
can
easily
reproduce
that
across
kubernetes
clusters,
after
you've
installed
crossplane
all
right.
So
we
have
our
team
present.
B
So
we
want
this
team
to
stick
around,
but
we
want
to
add
new
functionality
as
well,
so
I've
added
a
new
type
here,
a
memberships
type
which
basically
allows
us
to
specify
an
org,
a
team
and
a
user,
and
associate
a
specific
user
with
that
team
that
we
created
in
the
last
step,
for
example,
and
so
what
we
want
to
do.
I've
also
added
a
new
controller
to
manage
this,
and
what
we
want
to
do
is
publish
a
new
controller
image
as
well
as
a
new
package
image.
B
So
you'll
see
I've
updated
to
v0.0.2
here
and
we'll
also
want
to
make
sure
that
our
makefile
commands
here
are
going
to
update
as
well
so
I'll
go
ahead
and
run
those
again.
We
need
to
rebuild
our
binary,
and
this
will
take
just
a
moment
here,
all
right.
So
it
looks
like
that
completed
next
thing
we
want
to
do
is
do
our
make
image
and
that
should
go
pretty
fast
since
we're
using
a
lot
of
the
same
layers
here,
I
do
have
a
little
bit
of
latency.
B
B
B
B
So
we're
going
to
match
that
controller
image
and
we
should
see
that
pushed
up
successfully
and
now
what
we
want
to
do
is
actually
update
our
provider
that
exists
in
the
cluster.
So
let's
look
at
our
provider,
so
we
have
it
here
and
we're
using
that
0.0.1
image.
So
let's
go
ahead
and
edit
that
and
we'll
bump
it
to.
B
B
All
right-
and
we
should
see
if
we
get
that
provider
package
again,
that
it's
healthy
and
true,
and
we
should
actually
see
that
the
controller
has
been
switched
out
here
so
you'll
see
the
old
one
is
terminating
you'll,
see
this
new
digest
actually
present,
so
that
matches
our
image
digest,
and
we
should
see
that
our
new
controller
is
running.
We
should
see
that
we
have
all
the
same
crds
plus
our
membership
one.
B
B
Okay,
so
the
last
thing
we
want
to
look
at
today
is
how
we
can
compose
these
manage
resources
that
we've
created
for
this
provider,
we're
going
to
show
a
pretty
simple
example,
but
we
have
another
type
of
package
in
cross
plane
other
than
provider,
and
that
would
be
the
configuration
package
type
you
can
see
here.
You
can
declare
dependencies
on
providers
and
what
a
configuration
package
does
is
it
combines
different
infrastructure
primitives
in
this
case
we're
going
to
use
our
team
and
our
membership
into
a
higher
level
object.
B
The
other
nice
thing
about
this
is
the
ability
to
declare
dependencies
on
providers.
So
you
can
imagine
if
you
were
creating
a
networked
database
and
cluster
abstraction,
that
you
could
declare
dependencies
on
three
different
providers
have
them
all
installed.
Then
you
could
create
what
we
call
composite
resource
definition,
which
declares
the
schema.
This
looks
a
lot
like
a
crd,
in
fact,
actually
renders
out
a
crd
that
you
declare
the
abstract
schema.
B
So
we
can
package
these
up.
Just
like
we
did
a
provider
and
push
them
to
a
registry
and
also
be
able
to
install
them
and
when
they're
installed
they're
going
to
automatically
do
things
like
check,
the
cross,
plane
version
make
sure
all
dependencies
are
there
install
dependencies
if
they're,
missing,
etc.
B
So,
let's
go
ahead
and
do
that
so
I'll
go
into
the
configuration
directory
and
you'll
see.
This
is
a
lot
like
how
we
package
the
provider
so
we'll
do
k
cross
plane,
build
configuration
and
that'll
build
our
configuration.
Once
again,
we
see
our
x
package
here.
I
call
this
our
source
control
platform
as
a
service.
B
So
once
again,
this
is
going
to
put
you
to
the
registry
and
once
that
completes
remember
that
we
do
have
provider
github
already
present
here.
So
it's
going
to
see
that
that
provider
has
already
been
installed
and
won't
have
to
do
any
extra
installation.
It'll
just
bring
these
composite
types
that
we
were
talking
about,
so
we
can
go
ahead
and
k,
crossplane,
install
configuration
and
I'm
just
going
to
copy
paste
this
in.
B
B
B
Okay,
apply
dash,
f
examples,
org
user
team,
all
right
and
if
we
actually
look
at
the
rendered
out
resources,
this
should
take
a
minute
for
it
to
become
ready.
But
we
can
look
at
the
user
team
itself,
which
is
what
the
the
user
is
interacting
with
so
a
developer.
Who
just
wants
a
team
with
the
user?
So
they
don't
only
care
about
the
status
of
this,
but
being
infrastructure
aware
we
are
going
to
look
at
the
actual
rendered
out
resources.
B
It
looks
like
our
team
has
now
become
ready
and,
let's
see
if
our
membership
has
as
well
yep.
Our
membership
is
also
ready
and
that
will
result
in
the
abstract
resource
also
becoming
ready.
And
if
we
go
over
and
look
at
our
kubecon
n
a
org,
we
should
see
that
our
user
team
is
present
here
and
you'll
see
that
both
steven
and
I
are
in
it,
and
we
have
the
description
that
we
defined
and
that's
a
good
thing
to
point
out.
B
There
is
in
the
composition
you
can
have
arbitrary
mappings
from
the
abstraction
to
these
base
resources.
You
can
also
have
the
resources
reference
each
other.
So
here
we're
saying:
please
use
the
same
team,
that's
composed
with
me,
so
you
can
kind
of
resolve
those
references
automatically.
You
can
also
set
defaults
so,
for
instance,
we're
not
exposing
the
description
and
we're
just
saying:
please
always
set
it
to
a
composed
team
and
you
could
decide
if
you
wanted
to
expose
more
or
less
in
the
abstraction
and
also
make
parts
of
that
optional
or
not
all
right.
B
So
thanks
for
joining
us
today,
it's
definitely
a
blast
to
go
through
actually
implementing
a
kubernetes
controller
for
crossplane.
Please
feel
free
to
join
us
in
the
cross,
plane
slack.
You
can
use
this
link
here.
Slack.Crossplane.Io
set
up
an
account
and
we'd
love
to
chat
with
you
and
we'll
also
be
in
the
chat
here
for
the
presentation.