►
From YouTube: Manage More Clusters with Less Hassle, with Argo CD Application Sets - Jonathan West & Kshama Jain
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.
Manage More Clusters with Less Hassle, with Argo CD Application Sets - Jonathan West, Red Hat & Kshama Jain, Independent Contributor
Many organizations have discovered the advantages of using Argo CD and a GitOps workflow to manage their Kubernetes clusters, with Git repositories as the source of truth for defining the desired application state, and Argo CD responsible for keeping the cluster synchronized with those repositories. However, managing deployments of large numbers of applications/clusters with Argo CD requires complex custom scripting to keep those Applications in sync. The newly released Argo CD ApplicationSet controller aims to solve this problem, by working alongside Argo CD to automatically generate Application deployments using templates and parameterization: manage multiple Kubernetes clusters at once, deploy large numbers of applications from multiples respositories, and more. Best of all, the entire deployment is managed by only a single ApplicationSet Kubernetes custom resource, which means no more juggling of numerous Argo CD Application resources to target those multiple clusters/repos.
A
A
And
we
start,
we
thought
we'd
start
out
by
giving
you
a
brief,
elevator
pitch,
say
90
seconds
or
so
on.
What
application
sets
are,
how
they
work
and
some
of
the
features
that
you
might
find
interesting
there.
So
application
sets
or
new
kubernetes
custom
resource
and
a
controller,
that's
responsible
for
managing
that
custom
resource
which
works
alongside
an
existing
argo
cd
install.
A
So
you
specify,
with
your
application,
set
a
template,
a
generator
which
is
used
to
customize
that
template
and
then
the
application
set
goes
and
creates
applications
based
on
the
template
and
generator
combination.
You
specified,
so
you
can
think
of
application
sets
as
being
kind
of
like
a
factory
for
agua
cd
applications.
A
You
specify
the
template
the
generator
and
then
the
application
set
controller,
automatically
outputs,
a
bunch
of
applications
that
meet
your
specific
application
specifications
and
that
lets
you
do
some
really
neat
things
like
say:
if
you've
got
git
repositories
containing
50
applications
that
you
want
to
deploy,
and
you
want
to
deploy
them
to
50
clusters,
you
can
manage
all
of
those
combinations.
All
those
deployment
combinations
using
argo
cd
applications
within
an
argo
cd
application
set
as
a
single
unit,
so
it's
very
easy
to
manage.
A
A
B
B
Hence
argo
city
comes
into
picture,
so
argo
city
is
one
such
kittops
agent.
Now,
what
is
argo
cd,
so
argo
city
is
a
github
space,
continuous
delivery
tool
for
kubernetes,
which
uses
kid
as
source
of
truth.
It
is
declarative
and
supports
a
variety
of
configuration
management
tools
such
as
casino
json,
customize
him
and
any
conf
any
custom,
config
management
tool
configured
as
configure
config
management
plugin.
B
B
B
B
B
Algo
city
is
argo
city
application
is
a
logical
grouping
of
related
resources,
managed
managed
and
deployed
as
a
unit
in
the
middle.
You
can
see
the
resource
tree,
and
this
is
showing
that
there
are
four
resources
currently
being
managed
in
good.
Two
service
objects,
one
deployment
and
one
stateful
set,
and
each
item
in
the
resource
tree
is
selectable
and
by
clicking
on
them
you
can
see
further
details.
B
B
So
now
our
application
is
being
deployed.
As
you
can
see,
argo
cd
provides
real-time
activity
of
of
the
application
and
it
also
shows
relations
between
the
objects.
For
example,
this
deployment
created
a
replica
set
which
in
turn
created
three
pods,
and
you
can
see
further
details
such
as
part
summary
for
events
and
pod
locks.
B
Now
argo
series
provides
mainly
two
or
two
statuses.
First
is
the
health
status
which,
which
is
the
overall
overall
health
summary
of
your
application,
and
it
is
argo
city
gets
started
by
aggregating
the
health
of
of
its
resources
of
the
applications,
resources
and
the
second
is
the
sync
status,
which
is
the
overall
synchronization
status
of
the
application
it
lets.
You
know
if
your
application
is
in
sync
with
kit
or
if
there
is
any
configuration
drift
now,
our
application
isn't
is
deployed
as
an
and
is
in
sync
with
gear.
B
B
A
Okay,
awesome
thanks
sharma,
so
shama
showed
us
a
demonstration
of
the
argo
cd
web
ui.
So
this
is
the
kubernetes
representation
of
applications,
as
we
were
seeing
in
the
argo
cd
web
ui
so
like
this
is
the
central
custom
resource
that
argo
cd
uses
to
do
get
ops
so
because
this
is
gitops,
we
have
a
source
repository
that
contains
the
kubernetes
resources
within
a
git
repository,
in
this
case
I'm
deploying
a
guestbook
from
the
guestbook
path.
A
So
that
looks
like
this,
so
just
a
simple
git
repository
with
the
deployment
resource
and
a
service,
so
nice
and
simple,
and
I
want
to
deploy
that
to
a
kubernetes
cluster,
so
I've
got
my
source.
These
are
the
kubernetes.
These
are
the
resources
that
I
want
to
deploy,
and
this
is
the
destination
for
those
resources,
so
the
guestbook
namespace
and
the
particular
cluster,
which
is
just
going
to
be
my
local
cluster.
A
Once
they're
applied
it's
up
to
argo
cd
to
keep
those
in
sync
so,
as
we
saw
with
shama's
demo,
if
the
git
repository
changes,
it's
up
to
argo
cd
to
make
sure
that
what's
in
kubernetes,
is
always
consistent
with
what's
in
git,
but
notice
that
in
the
application,
cr
there's
only
one
source
and
one
destination,
so
you
can't
say
I
want
to
specify
you
know
I
want
to
deploy
this
one
git
repository
to
10
clusters
for
like
musty
multi-cluster
deployments.
You
can't
say:
oh,
I
want
to
deploy
these
10.
A
A
A
You
can
deploy
from
a
bunch
of
git
repositories,
all
from
a
single
application
set
managing
them
as
a
single
unit,
and
I
will
show
you
exactly
how
to
do
that
as
a
demo
in
a
few
moments,
so
the
application
set
controller
is
open
source.
Of
course,
it's
an
argo
cd
sub
project
hosted
within
the
argo
proj
labs
organization,
and
it's
built
from
contributions
from
many
different
folks,
including
individual
contributions
from
folks
from
red
hat,
snic,
intuit,
mlb,
alibaba
cloud
and
more.
A
So
how
exactly
does
an
application
set?
Allow
you
to
deploy
from
many
different
git
repositories
to
many
different
clusters?
Well,
it
starts
out
with
the
application
set
custom
resource,
which
is
the
main
custom
resource
of
the
application
set
project
in
here.
There
are
a
couple
of
fields
which
correspond
to
the
two
major
concepts
of
application
sets.
We
see
generators
which
are
responsible
for
generating
template
parameters
and
template,
which
is
responsible
for
using
those
parameters.
A
A
Generators
are
responsible
for
producing
the
parameters
that
templates
consume
in
this
case,
I'm
using
the
list
generator
it's
one
of
six
generators
that
are
currently
within
the
application
set
controller
and
the
list
generator
is
very
simple.
It's
you
within
the
yaml,
you
specify
a
set
of
values.
In
this
case,
we've
got
a
value
called
cluster
value,
called
url
they're,
both
strings
and
those
are
being
inserted
into
the
corresponding
values
within
the
template.
A
So
that's
all
courtesy
of
the
list
generator
the
list
generator
is
definitely
the
simplest
generator.
It's
literally
just
a
set
of
simple
keys
and
values.
So
everything
that
you
want
the
template
to
do
is
going
to
be
harder
coded
up
front
into
the
application
set
resource-
it's
the
least
reactive,
but
you
can
already
start
to
see
some
of
the
power
here.
So
in
the
last
side
you
slide,
you
saw,
we
had
a
single
cluster.
A
Now
we've
got
two
so
just
by
adding
these
two
extra
lines
of
yaml.
It
now
allows
us
to
deploy
our
guestbook
application
to
a
second
cluster.
So
the
first
one
was,
let's
say,
an
engineering
team
cluster
for
development.
Now,
just
by
adding
these
couple
of
lines,
we
can
deploy
to
the
engineering
team's
production
cluster.
A
A
So
what
are
generators?
Generators
are
responsible
for
generating
parameters
which
are
then
rendered
into
the
template
into
the
fields
of
the
application
set.
Resource
generators
are
usually
named
for
and
based
on,
the
particular
external
data
sources
that
they're
generating
template
parameters.
For
so,
for
example,
the
list
generator
is
just
a
literal
list
of
values
you
define
within
the
applications
set
resource
itself.
The
cluster
generator
is
generating
values
based
on
the
clusters
that
are
defined
in
argo,
cd
and
I'll.
A
So,
looking
at
the
diagram,
you
can
see
the
general
pattern
that
generators
follow,
so
the
list
generator
produces
a
set
of
parameters,
those
parameters.
So
in
this
case
I've
got
a
cluster
field
and
a
url
field
and
a
couple
of
rows
corresponding
to
each
cluster.
I
want
to
deploy
to
so
those
sets
of
parameters
flow
into
the
template.
A
So
that's
the
application
set
data
flow
in
a
nutshell,
generators
produce
parameters,
templates,
consume
parameters
and
then
the
application
set
controller
turns
those
rendered
templates
into
argo
cd
applications
and
from
there
it's
the
responsibility
of
argo
cd
to
actually
deploy
those
to
the
cluster.
To
look
at
the
gate,
repository
compare
it
with
what's
in
kubernetes
and
keep
them
in
sync.
A
So
that's
enough!
Talking
for
the
time
being,
let
me
show
you
a
demo
of
all
that,
so
I'm
going
to
jump
over
to
my
argo
cd
installation
here
and
you'll
notice
that
I
have
no
applications
defined
at
the
moment
and
I'm
going
to
bring
up
my
application
set
resource.
This
is
nearly
exactly
the
same
as
the
one.
I
just
showed
you.
A
A
To
our
rocd,
namespace
and
you're,
going
to
see
that
the
application
set
controller
is
going
to
pick
that
up
and
automatically
generate
our
go
cd
applications
for
each
of
those
one
for
each
cluster
that
we
want
to
deploy
to.
So
in
our
list
we
had
the
prod
cluster,
the
dev
cluster,
and
here
you
see,
the
application
set,
has
read
the
application,
set
cr
and
generated
the
corresponding
argo
cd
applications.
A
But
you
can
also
use
argo
cd's,
automated
sync
to
automatically
have
it
deploy
applications
as
soon
as
they're
created
by
the
application
set.
So
just
as
we
saw
with
shama's
demo,
we've
got
our
service
and
deployment
created,
the
replicas,
that's
going,
it's
creating
pods
and
yeah.
Rcd
is
doing
its
thing
and
keeping
the
kubernetes
cluster
namespace
in
sync,
with
the
git
repository
that
we
have
defined
for
it.
A
But,
as
I
said,
you
can
customize
applications
based
on
the
contents
of
the
application
set
template.
So
I
can
go
into
our
list
and,
for
example,
just
make
a
simple
change.
Let's
say
I
want
to
rename
our
applications
by
adding
demo
in
front
of
them,
for
example,
now
normally
what
I
would
have
to
do.
If
I
want
to
do
this
within
the
web,
ui
is,
I
would
have
to
like
go
into
app
details.
A
Click
edit
make
the
change
that
I
want
save,
that
and
so
on,
and
I
would
have
to
do
that
for
every
single
application
that's
defined
here.
I
can
just
edit
this
single
resource,
this
single
application
set
adjusting
the
template,
saving
that
applying
it
and
it
will
automatically
take
effect
for
all
of
the
applications
that
we
have
defined.
A
A
Yeah,
so
let's
sum
up
everything
that
we
just
saw
so
when
you
create
an
application
set
resource,
the
application
set
controller
automatically
detects
that,
if
you
have
generators
specified
that
are
based
on
external
sources
like
cluster
resources,
like
argo
cd
clusters
like
git,
the
application
set
controller
automatically
detects
those
inserts
them
into
the
template
of
the
application
set,
and
then
the
application
set
template
is
rendered
into
argo
cd
applications.
So,
as
we
saw
in
that
particular
example,
the
list
generator
produced
two
applications
as
soon
as
the
application
set
was
created.
A
As
you
modify
the
applications
at
resource,
it
automatically
updates
all
the
child
applications
and
when
you
delete
the
applications
that
resource
it
deletes
all
of
the
applications,
so
the
application
set
and
its
child
applications
are
always
kept
in
sync.
So
that
way,
all
you
need
to
worry
about
is
what's
in
the
contents
of
the
application
set.
You
don't
need
to
worry
about
the
contents
of
the
individual
applications
ever
deviating
from
from
what
you
have
defined
within
the
template.
A
The
actual
deployment
of
applications
remains
the
responsibility
of
argo
cd.
So,
as
we
saw
in
the
shama's
demo,
argo
cd
will
see
your
applications
and
as
soon
as
you
click
sync
or
if
using
automated
sync,
argo
cd
will
automatically
start
syncing
them.
But
it's
still
argo
cd's
responsibility
to
actually
deploy
those
application
sets
the
only
response
that
those
applications,
the
only
responsibility
of
the
application
set
controller,
is
to
create
these
the
actual
connection
to
the
cluster
and
say
identifying
deployments
and
services
and
doing
all
that
comparison
and
all
that
good
git
up
stuff.
A
A
We
already
saw
the
list
generator
where
you
had
to
hard
code,
a
set
of
values
in
order
to
insert
them
into
the
template,
but
there
are
much
more
powerful
generators,
starting
with
the
cluster
generator
you'll
recall
with
the
list
generator.
We
actually
had
to
hard
code
the
particular
clusters
that
we
wanted
to
deploy
to,
and
that's
fine,
but
what,
if
you
could
automatically
detect
the
clusters
that
are
available
so
within
argo
cd
within
the
settings?
A
There
is
this
clusters
section
where
you
can
see
all
of
the
clusters
that
argo
cd
has
access
to.
In
my
case,
it's
very
simple,
I'm
just
running
on
my
laptop,
so
there's
the
one,
but
if
you're
doing
multi-cluster
deployments
you
could
have
like.
I
don't
know
five
ten
fifty
you
know
as
many
as
you
want
with
argo
cd
managing
all
of
those.
A
So
what
if,
rather
than
needing
to
hard
code
them
as
we
did
with
the
list
generator,
we
could
just
pull
all
of
those
clusters
that
were
already
defined
within
argo
cd
and
that's
exactly
what
the
cluster
generator
does.
It
looks
at
the
clusters
defined
within
argo
cd
and
all
you
need
to
do
is
just
specify
this
simple
one
line
of
yaml
and
it
will
automatically
detect
those
and
start
deploying
your
applications
to
them
from
git
ops,
so
pulling
the
name
and
server
values
from
argo,
cd
and
deploying
your
applications.
A
Now,
let's
say,
you've
got
prod
clusters
and
dev
clusters.
Maybe
you
only
want
to
deploy
to
development.
You
can
target
a
subset
of
clusters
very
easily
using
cluster
annotations.
You
can
see
the
docs
for
that
and
as
new
clusters
are
added
or
removed,
the
application
set
controller
automatically
detects
that
and
updates
the
corresponding
applications.
A
A
So,
within
this
cluster
add-ons
directory,
I've
got
a
couple
of
applications.
I
want
to
deploy
one
called
argo
workflows
and
one
called
prometheus
operator.
Our
go
workflows
is
the
argo
projects.
Workflow
controller
for
our
orchestration
prometheus
operator
is
for
application.
Monitoring
workflows
is
customized
and
prometheus
operator
is
helm.
A
Wouldn't
it
be
great
if
we
could
just
scan
this
git
folder
for
all
the
applications
contained
within
it
and
automatically
deploy
the
applications
that
are
found.
So
you
know
not,
surprisingly,
that
is
exactly
what
the
git
directory
generator
will
do.
It
will
scan
through
the
path
that
you
have
defined
for
applications
contained
within
that
git
repository
within
the
path
and
deploy
them
to
the
cluster
and,
again
that's
great
for
folks
that
have
multiple
workloads
or
components
or
microservices,
and
they
have
kubernetes
resources
defined
for
them
within
a
single
git
repository.
A
Some
folks
prefer
the
opposite
approach
when
they're
doing
get
ops
so,
rather
than
having
one
single
git
repository
containing
the
resources
for
multiple
applications.
Instead,
they
have
a
one-to-one
relationship
between
application
and
repository,
so
one
application
and
it's
kubernetes
resources,
go
in
one
repository,
one
to
one.
A
So
for
them
we
have
the
scm
provider
generator
which
will
scan
a
github
or
git
lab
organization,
in
this
case
I'm
using
github,
and
it
will
look
for
all
the
repositories
within
the
organization
that
match
a
particular
name.
So
in
this
case
example
apps.
So
if
I
had,
like
example,
apps
one
example,
apps
two
example
labs
three,
the
scm
provider
will
scan
through
my
organization
automatically
find
all
of
those
applications
that
match
that
path,
or
that
name
and
deploy
them
to
the
kubernetes
cluster,
using
the
template
values
that
are
generated
by
the
stm
provider.
A
The
third
git
base
generator
is
the
git
file
generator
real,
quick.
This
allows
you
to
define
json
or
yaml
files
within
a
git
repository
and
have
them
automatically
processed
and
parsed
and
inserted
into
the
application
template
by
the
application
set.
This
allows
you
to
have
more
fine,
grained
control
over
individual
fields
of
the
template
versus
other
generators.
A
A
So,
let's
say
that
you
know
you
like
the
idea
of
using
the
git
directory
generator
to
find
every
application
within
a
path
of
your
repository,
and
you
like
the
idea
of
using
the
cluster
generator
to
deploy
to
every
cluster,
that's
defined
within
argo
cd.
But
what,
if
you
want
to
do
both?
What
if
you
want
to
find
every
application
and
deploy
it
to
every
cluster
so
before
you
couldn't
before
you
could
just
do
either
one
or
the
other
you
either?
A
You
need
to
pick
one
of
those
two
generators
so
either
use
the
git
generator
to
find
all
the
applications
or
use
the
cluster
generator
to
deploy
to
all
the
clusters.
Fortunately,
with
the
matrix
generator
you
no
longer
have
to
choose,
you
can
now
have
both
of
them
together.
So
we've
got
the
git
generator
here.
The
cluster
generator
here
the
git
generator
is
going
to
run
it's
going
to
find
all
of
your
applications
under
the
path
you
specified.
A
Cluster
generator
is
going
to
run,
find
all
your
clusters
and
then
the
parent
matrix
generator
is
going
to
combine
the
two.
So
let's
say
you
have
five
applications:
10
clusters,
it's
going
to
generate
all
50,
so
5
times,
10,
50,
individual
combinations
and
then
automatically
deploy
them.
So
with
this
matrix
generator
using
these
two
child
generators,
you
can
deploy
every
application
and
get
to
every
arduous
cd
cluster.
A
A
Finally,
we've
got
the
cluster
decision,
resource
generator,
which
is
definitely
the
most
complex
generator,
but
probably
also
the
most
powerful.
It
allows
you
to
outsource
the
logic
of
which
clusters
to
place
applications
on
to
an
external
custom
resource.
So
here
you
actually
have
to
write
your
own
custom
controller.
A
So
that
is
a
lot
of
work,
but
fortunately
the
open
cluster
management
folks
already
have
an
example
of
this,
with
their
placement
rule
rule
custom
resource
where
they
have
their
own
set
of
fancy,
complex
rules
for
where
applications
should
go,
and
it's
easy
to
hook
up
that
placement
rule
custom
resource
into
applications.
That's
using
this
generator,
but
this
generator
will
work
with
any
custom
resource
that
meets
the
particular
generic
api
contract
that
the
generator
is
looking
for.
A
So
hopefully,
all
these
generators
have
piqued
your
interest
in
how
you
can
use
them
to
handle
your
own
individual
kubernetes
deployment
use
cases
at
red
hat
application
sets
are
built
into
our
red
hat.
Open
shift
get
ops
product
along
with
argo
cd,
so
the
two
are
bundled
together
for
use
on
openshift
and
you
can
learn
more
about
how
to
deploy
using
argo,
cd
application
sets
and
openshift
git
ops
in
these
two
blog
posts.