►
From YouTube: Like Peas And Carrots: Argo CD And Crossplane For Infrastructure Manag... Jesse Suen & Viktor Farcic
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
Like Peas And Carrots: Argo CD And Crossplane For Infrastructure Management - Jesse Suen, Akuity & Viktor Farcic, Upbound
Kubernetes adopters have realized the benefits of declarative APIs and the ability to leverage modern deployment practices such as GitOps for safe and repeatable application delivery. These teams naturally wish to apply these same processes and tools to manage infrastructure deployments. The Crossplane project extends Kubernetes to enable the provisioning of cloud infrastructure. Combined with Argo CD, they become a powerful infrastructure management dashboard. This talk covers the benefits of using Kubernetes as a control plane of your cloud infrastructure over Terraform and CloudFormation, such as native RBAC and seamless integration with other cloud-native tools. See how Akuity uses Argo CD and Crossplane to manage its production AWS infrastructure. Learn to leverage advanced Argo CD features (health checks, resource actions, extensions) to get the most out of your Crossplane installation. Implement best practices recommended directly from the project maintainers Upbound and Akuity.
A
Thanks
everyone
for
attending
our
talk
on
Cross
plain
and
Argo
CD.
My
name
is
Jesse
suan
I'm,
one
of
the
co-creators
of
the
Argo
project
and
co-founder
of
a
company
called
Acuity,
which
offers
fully
managed
Argo
CD
in
the
cloud
and
speaking
with
me
today
is
Victor,
who
you
probably
already
know
from
his
very
popular
YouTube
channel.
B
The
rest
of
you
might
have
trouble
to
follow
up.
This
is
going
into
into
All
the
Troubles
that
this
guy
was
facing
with
crosswind
anyways.
So
let
me
give
you
a
very
quick
introduction,
very,
very
quick
introduction
into
in
into
Cross
Point
right
and
I'm.
Gonna
show
it
in
a
way
from
from
the
point
of
view
of
History
right
at
the
very
beginning,
we
got
confirmations
management
tools,
Chef
puppet
ansible.
You
know
all
those
things.
B
Some
of
you
are
probably
using
our
civil
steel
and
they
were
all
based
on
the
idea
that
things
are
mutable
right.
I
know
that
they
can
do
immutable
things,
but
based
on
mutable
principles,
you
can
call
that
the
first
generation
what
later
on
became
infrastructures
code
and
they
were
they
were
mostly
based
for
bare
metal.
You
know
real
servers,
you
know
before
virtual
machines
and
before
cloud
and
all
those
things,
and
then
we
got
into
the
second
generation
of
such
tools
that
we
called
that
second
generation
infrastructure
is
called.
B
Containers
is
wrong
right,
that
that
containers
are
just
one
of
the
implementations
of
kubernetes
scheduler,
and
we
have
many
many
many
others
and
one
of
those
others
is
cross
play.
So
what
we're
trying
to
do
with
crossplay
can
be
described
through
two
main
areas.
Right,
one
area
would
be
one-to-one
matching
between
resources
in
kubernetes
or
custom
resource
definitions
and
something
on
the
other
end
right.
B
So
if
you
need,
if,
if
on
the
other
end,
you
have
easy
to
instances
in
AWS,
then
you
have
a
custom
resource
that
you
can
apply
in
your
kubernetes
and
use
all
the
good
things
that
we
like
with
kubernetes,
to
manage
the
ec2
instance
or
whatever
else
that
is
right.
Ordering
pizzas,
it's
up
to
you
I
mean
depends
on
the
providers.
Now.
The
second
and
equally
important
or
more
important
part
about
cross
planning
is
the
ability
to
create
compositions
right.
B
Compositions
are
a
way
for
you
to
create
your
own
custom
resource
definitions
with
controllers
that
Define
what
something
means
to
you
right.
What
does
it
mean
to
you
to
have
a
cluster
to
have
an
application
to
have
a
database
right?
What
does
it
involve
and
as
such,
when
you
combine
all
those
things
you
can
expose
through
those
custom
resources,
you
know
work
your
operational
knowledge
to
everybody
else
in
your
company,
but
as
effectively.
B
A
A
Yeah
thanks
Victor,
so
today,
I'll
be
covering
how
Acuity
uses
cross
plane
and
some
lessons
and
learnings
based
on
our
experience
with
it.
So
let
me
start
by
explaining
like
why
we
chose
crossplay.
So
the
main
reason
we
wanted
cross-plane
was:
we
wanted
to
manage
our
infrastructure,
the
same
way
that
we
manage
our
applications
and
that's
using
things
like
Argo
CD
in
in
githubs.
So
we
wanted
to
apply
the
same
tooling
the
practices
and
processes
to
our
infrastructure,
especially
when
we
want
to
encourage
a
you
know
these
devops
based
workflows.
A
So
these
days,
the
the
line
between
your
infrastructure
and
your
applications
are
getting
more
and
more
blurry,
and
so
there's
a
lot
of
this
coordination.
That
needs
to
happen
between
your
Cloud
resources
and
your
kubernetes
resources
and
the
best
example
of
this
is
things
like
IAM,
so
Amazon
has
irsa
and
and
Google
has
something
called
workload
identities
and
even
though
you
know
we're
a
small
team
and
we
don't
really
have
like
a
separate,
you
know
platform
engineering
team.
A
We
still
wanted
to
provide
this
simple
interface
to
developers
to
basically
lay
the
groundwork
for
scaling
up,
providing
standardized,
self-service
infrastructure
and
just
exposing
a
much
more
simpler
set
of
knobs,
and
this
enables
us
to
treat
our
infrastructure
more
like
cattle.
So
not
it's
not
like
a
big
deal
to
you
know,
create
more
and
more
of
these
things
so
cross
pane
enables
just
you
know,
treating
these
things
like
like
cattle.
A
So
these
are
the
type
of
resources
that
we
deployed
today
using
cross
plane
where
primarily
AWS
shop,
and
we
only
use
three
cross
plane
providers,
the
AWS
provider,
Helm
provider
and
the
kubernetes
provider.
We
do
have
a
presence
on
gcp,
but
it's
quite
small
and
currently
they're
not
managed
by
cross
plane
but
I.
Think
in
the
future.
That
could
change
and
will
be,
you
know
pretty
prepared
to
use
cross
plane
for
both
managing
gcp
stuff,
as
well
as
AWS.
A
So
probably
the
most
powerful
feature
that
you
want
to
be
using
cross
brain
for
is
its
ability
to
compose
resources
into
higher
level
resources.
What
they
call
compositions-
and
here
are
some
of
the
compositions
that
we
created
for
our
own
internal
purposes,
and
so
we
started
with
upbounds
reference
architecture,
so
they
publish
a
bunch
of
reference
implementations
for
AWS
or
gcp
Azure,
and
then
we
tweaked
it
a
bunch
of
things
to
kind
of
suit
our
own
needs.
For
example,
we
we
changed
it
to
run
in
three
availability
zones.
A
Instead
of
two,
we
enabled
KMS
Secrets
encryption,
we
added
the
AWS
add-ons
and
then
we
also
did
something
created
our
own
add-ons,
which
I'll
explain
in
a
little
bit.
But
if
you're
looking
to
get
started,
I
highly
suggest
using
those
reference
implementations
as
a
good
starting
point
on
modeling,
your
your
compositions
and
also
there's
this
you'll,
see
this
one
composition
up.
A
There
called
the
irsa
composition
and
that's
specifically
to
handle
I
am
roles
and
policies
associated
with
kubernetes
service
accounts,
so
now
I'll
get
to
why
that's
needed
in
a
bit
so
and
along
with
those
compute
and
networking
compositions.
We
also
have
this
concept
of
a
add-on
composition
for
kubernetes
clusters
here
I'm
showing
six
such
add-ons,
and
each
add-on
is
different
from
the
other.
So.
B
A
So
one
example
is,
you
know,
the
one
will
require
different
policies,
and
so
their
their
policy
manifest
will
be
different.
Some
is
installed
using
Helm,
the
others
are
just
installed
through
raw
kubernetes
manifest,
and
so
you
can
see
which
of
these
lower
level
objects
are
composed
into
this
higher
level.
Composition.
A
A
We
just
exposed
a
few
of
the
carpenter
parameters
that
we're
interested
in
and,
if
so,
looking
at
this
example,
this
cluster
will
want
to
use
spot
instances
and
it
wants
to
only
use
these
four
instant
classes
and
it
will
have
like
a
Max
Auto
scaling
of
100
vcpus.
So
all
of
these
values
will
get
passed
all
the
way
down
to
the
carpenter.
You
know
config
map
or
provide
provisioner,
but
how
that
happens
is
is
abstracted
away
from
the
user
deploying
this.
A
And
this
this
is
just
an
illustration
of
how
this
nesting
of
composition
works.
So
you
can
see
here
we
have
this
top
level,
eks
composition
and
then
inside
that
you
have.
You
know
things
your
normal
managed
resources
like
cluster
and
node
groups,
the
way
they
see
provider.
But
then
you
can
include
your
your
own
self-written
compositions,
like
my
Carpenter
add-on,
that's
composed
of
like
a
Helm
release
and
instance
profile
provisioner,
and
in
that
thing
encompasses
another
composition.
A
So,
let's
talk
about
when
I
think
probably
one
of
my
biggest
annoyances
about
how
privileges
are
handled
in
AWS.
So
AWS
has
this
feature
where
you
can
give
your
pods
IAM
privileges
without
using
long-lived
static
credentials,
and
they
call
it
irsa.
I
guess
called
IAM
roles
for
service
accounts.
Google
has
their
own
version
of
it
called
workload
identity
and
they
they
work
basically,
the
same
way.
A
So
the
way
it
works
is
you
have
your
you
know
your
normal
I
am
policy,
and
your
IM
role
and
they're
like
attached
to
each
other
and
to
give
I
am
privileges
to
the
Pod.
It
has
to
go
through
an
oidc
provider
which
you
you
to
create
along
with
your
cluster,
then
you
need
to
reference
this
oidc
provider
in
like
two
different
places
in
that
IAM
role,
and
then
you
have
your
service
account.
A
The
service
account
is
the
one
that
you
want
to
give
privileges
to
your
cloud
and
This.
Server
account
has
to
have
an
annotation
which
references,
the
Arn
of
the
I
am
World,
which
we
want
to
impersonate
and
then
that
I
am
role
once
should
then
have
a
reference
back
to
the
surface
account.
So
this
bi-directional
trust
is
established.
A
So
this
this
is
a
really
pain
to
manage,
but
we
use
cross
plane
to
kind
of
help,
coordinate
and
manage
all
these
references
so
to
simplify
things.
We
we
have
another.
This
composition,
which
we
call
an
irsa,
and
this
RSA
resource
accepts
all
of
those
previous
things
that
I
talked
about
as
inputs.
So
like
what
service
account
name,
you
want
to
give
permissions
to
the
namespace.
A
So
this
slide
is
just
showing
the
fact
that
we
also
use
cross
plane
to
deploy,
managed
resources
directly
and
managed.
Resources
are
kind
of
like
the
lowest
level
provider,
resources
that
have
have
like
a
one-to-one
mapping
with
the
cloud
provider.
So
there's
going
to
be
a
lot
of
times
where
you
just
want
to
create.
You
know:
Cloud
resources
not
tied
to
any
other
objects.
In
our
case
we
want
to
create,
you
know,
Route
53,
entries
or
routes,
Transit
gateways-
or
maybe
we
just
want
to
create
a
like.
A
A
bespoke
I
am
role
to
give
to
one
of
our
services,
and
so
this
the
example
that
we
use
it
for
is:
let's
say
you
have
you
create
two
VPC
networks
in
our
case,
like
so
eks
VPC,
and
then
a
database
VPC
and
then
later
on.
We
want
to
connect
those
two
so
then
we'll
use
cross
plane
to
deploy
a
Transit
Gateway
and
then
the
attachments
to
connect
those
two
vpcs.
A
So
you
might
be
wondering:
okay,
where
does
Argo
CD
come
into
the
picture
so
far,
I've
been
talking
about
add-ons
and
and
how
we
use
cross
plane
to
install
those.
But
what
about
Argo
CD
and
the
answer
is
we
actually
use
both
so
and
there's
some
trade-offs
that
you
should
understand?
When
you
decide
you
want
crossblink
to
install
something
through
a
Helm
chart
or
you
when
you
want
Argo
CD
to
do
something.
A
So
the
advantages
of
using
cross-plane
to
to
have
like
an
add-on
installed
as
part
of
a
cluster
object
is
that
you
know
everything
is
handled
in
that
composition.
So
you
just
basically
apply
that
one
top
level
eks
object
and
then
20
minutes
later
you
have
a
fully
functional
cluster.
It
has
all
the
add-ons
it
needs
and
it's
ready
to
use
out
of
the
gate,
and
this
includes
things
like
I
am
privileges
to
the
the
controllers
that
need
it.
A
But
the
flip
side
is
that
these
add-on
versions
are
are
more
cumbersome
to
manage
so
they're
they're,
tied
to
your
eks
composition
that
you
wrote,
and
so
let's
say
tomorrow
you
want
to
upgrade
AWS
load
balancer.
You
have
to
kind
of
modify
your
composition
to
get
the
new
helmetry
version
and
then
publish
that
that
new
composition,
and
so
the
the
upgrade
process
of
that
island
is
much
more
tedious.
A
Also,
if
it's
part
of
that
composition,
it
also
means
that,
like
all
the
Clusters
that
are
created
from
that
composition,
they
all
get
the
same
version,
and
so
you
don't
have
that
flexibility
of
you
know
maybe
picking
different
versions
for
different
clusters.
They
they're
all
kind
of
tied
to
what
you
chose
in
in
your
composition,
on
the
rocd
side.
The
best
benefit
you
get
is
you
can
use
a
git
Ops
based
workflow
for
for
managing
your
add-on.
So
this
means
you
can
control
the
versions
for
different
environments.
A
You
use
you
know
gear
dots
to
modify
the
config
map
used
by
those
add-ons
and,
unlike
a
composition,
you
actually
get
to
choose
like
which
add-ons
get
to
be
deployed
in
the
cluster.
So
with
the
composition
you
basically
deciding
like
you
know,
these
end
add-ons
are
part
of
it
and
there's
no
way
to
kind
of
turn
off
and
on
it's
just
like
it's
an
all
or
nothing
kind
of
decision.
A
Some
of
the
drawbacks
of
you
know
Argos
CD
using
to
deploy.
Is
it
can't
do
this
coordination
of
in
referencing
passing
of
like
IAM
to
other
resources,
so
that's
one
limitation
of
Largo
CD
and
second,
if
you're
using
rcd
to
manage
your
add-ons,
it's
going
to
be
like
the
second
step.
You
know
you
create
your
cluster
first
and
then
followed
by
you
know
installing
some
cluster
add-on.
A
So
so
we
I
mentioned
we
use
both,
and
so
we
decide
a
different
strategy
depending
on
the
type
of
add-on
and
so
there's
three
different
kinds.
What
the
first
is
what
they
call
like
critical
elements.
These
are
atoms.
They
are
kind
of
essential
for
a
cluster
to
function,
for
example,
without
Auto
scaling.
You
can't
even
probably
install
more.
B
A
A
A
Next
I
want
to
talk
about
what
we
feel
is
a
best
practice
for
using
cross
plane.
One
issue
you
might
face
is
that
when
you
release
a
new
composition
or
update
a
provider,
it
could
be
risky
because
you
know
when
you're
updating
those
things
all
instances
of
that
composition
get
updated
at
the
same
time,
and
so
it
could
mean
that
you
break
all
your
clusters
at
the
same
time.
So
what
we
do
is
we
run
multiple
cross
planes,
one
per
environment,
so
test
stage
prod,
and
then
we
progressively
promote
a
composition
through
the
environments.
A
It's
just
so
we
can
control
the
blast
radius
if
something
goes
wrong
and
here's
an
illustration
of
this,
so
here
we
have
three,
those
three
environments,
so
our
AWS
accounts
and
you
can
see
a
there's
a
cross
plane
in
each
account
to
manage
the
infrastructure
of
that
account.
And
when
we
roll
out
a
new
version
of
our
composition,
then
it
first
goes
to
test
and
staged
in
prod
and
meanwhile,
Argo
CD
is
deploying
to
all
the
Clusters
that
you
see
in
this
picture.
A
A
A
One
thing
you
might
know:
this
is
that
Argosy
has
a
is
pruning
feature
and
it
wants
to
delete
resources
which
think
it
you
know
are
no
longer
managed
and
get,
and
it
does
it
by
seeing
the
live
object
and
looking
at
a
label
and
says:
oh,
that
label
was
tied
to
this
application,
but
it's
missing
from
git.
Therefore,
I
should
prune
it.
A
The
thing
is
cross
plane
kind
of
carries
over
that
label
that
you
apply
in
your
your
your
claims
resource
to
the
com
composite
resource,
which
is
is
kind
of
like
a
child
of
the
the
claim,
and
so
because
of
that,
if
you're
using
label-based
tracking
Argosy
turns
around
oh
I'd,
better
go
delete
it.
It
must
be
something
they
removed
from
git.
So
what
annotation
based
tracking
does?
Is
we
we,
instead
of
labeling
it
with
a
simple
name?
We
annotate
it
with
a
lot
of
metadata
and
based
on
that
metadata.
We
can.
A
We
understand
if
something
was
a
label
or
annotation
was
just
carried
over
from
some
parent
object
and
we
will
decide
not
to
prune
it.
So
this
is
a
feature
you
definitely
want
to
turn
on,
even
if
you're
not
using
cross-plane.
This
is
a
better
way
to
use
Argo
CD
and
it
will
be
the
default
in
the
future,
I'm
sure
yeah.
A
Okay,
where
are
we
okay,
so
I
have
some
performance
tricks?
One
thing
to
know
about:
cross-plane
is
it
it
can
install
like
hundreds
of
crds
and
you're,
probably
not
going
to
be
using
most
of
them.
The
problem
that
happens
is
argosity,
wants
to
list
and
watch
those
those
resources,
even
if
you're
not
using
them,
because
you
might
be
using
them
and
it
needs
to
discover
them
so
this
causes.
A
Another
use
of
resource
exclusions
and
this
kind
of
improves
the
usability
of
the
user
interface
is
something
called
Crosslink.
Has
this
object
called
a
provider
config
usage
and
for
the
most
part
it's
an
implementation
detail
of
cross
plan.
You,
don't
you
don't
ever
manage
those
objects
and
you
probably
shouldn't
ever
care
that
they
exist,
but
the
problem
is
they
actually
show
up
in
the
Argo
CD
UI,
because
they
they're
they're,
always
Children
of
the
low
level
of
managed
resource,
and
so
one
thing
to
kind
of
just
declutter.
A
Foreign
with
high
number
of
crds
is:
it
makes
something
called
API
Discovery
pretty
slow,
so
you
might
actually
notice
this
from
like
Cube
CTL
itself,
so
keep
keep.
Cto
has
to
kind
of
ask
kubernetes
about
like
hey.
What
do
you?
What
kind
of
crds
do
you
have
in
the
system?
If
you
have
hundreds
of
these
things,
it's
actually
can
get
slow.
A
Argosy
does
the
same
Discovery,
but
right
now,
there's
like
this
bug
or
performance
problem
which
makes
it
inefficient.
So
you
can
work
around
this
problem
by
just
bumping
up
the
QPS
which
we're
currently
getting
throttled
on
to
the
controller,
and
this
should
be
a
temporary
workaround
that
you
don't
need
in
the
future.
A
Health
checks.
Okay,
so
if,
if
you
don't
know
cross
plane,
has
very
homogeneous
statuses
for
all
of
the
resources
it
creates,
so
they
all
get.
This
condition
like
is
the
resource
synced
or
is
it
ready?
And
so
it's
Argo
City?
Has
this
feature
which
lets
you
write
a
snippet
of
Lua
script
and
evaluate
the
the
object
to
see
if
there's
any
return,
if
it's
healthy
or
degraded
or
progressing?
A
And
so
here's
this
a
simple
resource
health
check
that
you
can
write
for
that
DB
instance
that
I
showed
in
the
previous
slide,
and
this
as
you
can
see
it
just
iterates
the
conditions
see
if
it's
not
synced
and
then,
if
it
isn't
ill,
show
cause
the
resource
to
show
up
as
degraded
and
then
you
can
see
in
this
little
screenshot.
It
will
actually
get
surfaced
to
the
Argo
CD
UI
and
you
can
quickly
identify
problems
in
your
cross-plane
resources
and
get
a
lot
better
visibility.
A
One
thing
is:
if
you
want
cross
plane
to
adopt
existing
resources,
it
could
be
challenging,
especially
for
AWS,
and
this
is
because
AWS
has
this.
This
Behavior,
where
it
just
generates
like
random
IDs
for
for
some
things
like
VPC,
subnets
and
crd
groups
and
cross-plane,
when,
when
you
recreate
a
resource,
let's
say
you
wanted
to
take
over
existing
one
or
maybe
you're,
just
moving
your
you
know
migrating
to
a
different
cross-plane
cluster.
A
So
when
you
apply
it
a
second
time,
it
doesn't
know
that
existing
one
already
exists
and
it
should
adopt
it.
So
now,
you're
left
with
like
two
vpcs
there's.
You
know
ways
around
this.
You
can
annotate
your
resources
in
with
an
external
name
so
that
you
can
take
it
over,
but
this
kind
of
breaks
the
whole.
A
Some
things
I
I
limitations
in
the
cross,
plane,
but
I
think
they're.
You
know
being
worked
on,
they'll
be
addressed
in
the
future.
As
of
now
a
composition,
you
can't
conditionally
create
resources
depending
on
like
like
input
parameters,
so,
for
example,
for
us
like
I,
would
love
the
ability
to
enable
or
disable
a
cluster
add-on,
based
on
like
some
true
false
values
in
the
parameters.
A
A
And
another
limitation
is
we
cross
between,
doesn't
have
a
ability
to
reference
another
resource
and
get
status
information
to
feed
into
the
input
of
the
current
resource.
So
if
you're
currently
working
all
within
the
same
composition,
it's
fine
because
it's
all
the
references
happen
in
the
same
yaml.
But
if
you
want
to
kind
of
a
more
Loosely
coupled
process.
So
maybe
you
have
an
eks
Network,
another
ecos
Network,
and
you
want
to
attach
them
today.
A
A
So
so
far,
we've
been
running
cross-plane
for
the
better
part
of
a
year
and
it's
been
working
great
for
us.
These
are
improvements
that
we
want
to
make
internally.
These
are
not
things
about
cross-plane
So.
Currently
are
we
ran
like
an
eqs,
dedicated
eks
cluster
as
a
cross-plane
control,
plane,
and
so
the
more
environments
we
have
like.
Then
it
becomes
more
expensive
because
you're
kind
of
dedicating
an
eks
cluster
for
this,
so
it
should
be
possible
right.
C
With
a
composition,
revision
arriving
soon
in
Cross
plain,
do
you
think
you're
gonna
keep
a
separate
instance
of
cross
plane
to
test
between
environments
with
composition,
revision
arriving
cross-plane?
Soon,
it's
a
feature
flag
today.
Do
you
think
you're
going
to
keep
the
multiple
instance
of
cross
brain
to
Stage
to
test
for
each
environment
or
you're?
Gonna
have
all
I'm.