►
Description
How To Automate Everything In 2021 - Viktor Farcic, Shipa
Automation of all the repeatable tasks is nothing new. We've been doing it for years or even decades. But the technology changes, so do the tools and the processes we use in automation. Today, we are practicing not only continuous delivery (CD), but also GitOps and progressive delivery. Our applications are running in Kubernetes and are designed around event-based decoupled architecture. So, how do we automate everything in 2021? Which practices should we use, and which tools should we choose? How can we combine events with workflows, pipelines, GitOps, and progressive delivery using tools designed from ground-up to be cloud-native and Kubernetes-first. We'll use Argo project (Events, Workflows & Pipelines, CD, and Rollouts) combined with SealedSecrets and Kaniko for the hands-on demo.
PLEASE NOTE: This talk has similar content to the GitOps talk titled Combining Progressive Delivery with GitOps and Continuous Delivery.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
What
do
we
get
when
we
combine
events
with
workflows
or
pipelines
and
then
sprinkling
some
git
tops
and
progressive
delivery?
What
do
we
get
when
we
do
all
when
we
combine
all
those
things?
The
short
answer
is
that
we
get
something
absolutely
awesome
slightly
longer
answer
still
short
is
that
we
can
get
full
automation
of
everything,
or
at
least
full
automation,
of
everything
happening
after
pushing
a
change
to
git
repository,
and
we
get
all
that
in
a
way
that
is
appropriate
for
2021..
A
Now
we
could
do
that
before
we
could
ultimate
stuff
before,
but
we
don't
live
in
the
past.
This
is
how
you
do
it
in
2021,
full
automation
of
everything.
So
what
do
we
need?
What
is
all
this?
What
are
we
going
to
use
today
to
begin
with
the
obvious
one
kubernetes
right,
everybody
uses
kubernetes
or
fully
partly
somehow
anyway.
Kubernetes
is
here
right,
we're
going
to
use
git,
because
that's
the
only
source
code
repository
that
matters
today,
specifically,
it
will
be
github,
but
everything
I'm
going
to
show.
A
You
applies
to
git
or
whichever
other
git
provider
you
might
be
using,
and
then
we
need
the
container
registry.
I'm
going
to
use
docker
hub
again
applies
to
any
container
registry.
I
don't
care
which
one
you
have
they're
all
the
same.
To
me
and
now
comes
the
interesting
part.
Now
comes
the
real
part.
We
are
going
to
use
argo
and
argo
and
argo
and
arbor
to
be
more
specific.
A
Argo
events
for
events,
argo
workflows
for
breakfast
or
pipelines,
argo
cd
for
github's
type
of
deployments
and
dargo
rollouts
for
canary
deployments
for
progressive
delivery.
It
could
be
blue,
green
as
well,
but
today,
canary.
Why
not?
And
finally,
the
last
thing
we
need
is
a
way
how
to
manage
our
secrets.
I'm
going
to
go
with
the
git
tops
type
of
managing
secret,
so
it
will
be
sealed
secrets.
We
are
going
to
create
a
platform
to
create
a
system,
unlike
dealing
with
individual
tools
like
we
did
before.
A
In
other
words,
I'm
going
to
show
you
everything
you
might
need
to
do
to
automate
everything
before
we
jump
into
hands-on
part
of
all
this.
There
are
a
couple
of
things
I
did
in
advance
to
begin
with,
I
created
a
kubernetes
cluster.
I
already
have
a
cluster.
I
will
not
show
you
how
to
create
a
cluster.
You
know
how
to
create
a
cluster
right.
You
know
it
inside
of
the
kubernetes
cluster.
I
installed
the
nginx
ingress
and
I
installed
sealed
secrets.
That's
the
only
thing
that
I
installed.
A
I
need
sealed
secrets,
because
without
them
I
cannot
create
manifest
with
my
secrets
and
and
that's
about
it.
That's
all.
I
have
kubernetes
cluster
english
sealed
secrets.
Let's
try
to
figure
out
whether
we
can
use
argo
and
a
few
other
projects
to
automate
absolutely
everything.
So
I
have
a
empty
cluster.
Basically
only
nginx
thing
just
running
over
there
and
yeah
sealed
secrets,
and
the
first
step
we
need
to
do-
is
to
set
up
everything
we
need
for
production
and
that
everything
means
everything
really,
but
there
is
an
important
rule.
A
A
You
you'll
understand
in
a
second
what's
going
on,
so
let
me
go
to
the
directory
where
I
clone
the
repository,
and
that's
this
one
and
let's
see
what
I
have
prepared
here
for
you
for
me,
and
that
is
the
directory
production
and
inside
of
that
directory,
I
have
argo
cd
applications
that
define
absolutely
everything
I
need
today.
For
you
guys,
I
will
need
to
install
argo
cd.
I
will
need
to
install.
I
will
deploy
an
application
that
will
be
a
demo
application.
A
I
need
argo
events,
rollouts
workflows,
istio,
prometheus,
sealed
secrets,
everything
even
those
things
like
sealed
secrets
that
are
already
installed,
they're,
defining
it
as
well,
so
we
cannot
really
apply
git
without
having
argo
cd
installed.
So
it's
a
chicken
and
egg
problem,
so
we
do
need
to
install
argo
cd,
but
after
that
argo
cd
should
make
sure
that
all
those
applications
are
up
and
running
in
our
cluster
and
that
the
desired
state.
A
What
is
defined
in
this
directory
in
this
git
repo
is
always
the
same
as
the
the
actual
state
or
actually
the
other
way
around.
The
actual
state
is
the
same
as
the
desired
state.
So
I
will
execute
cube
cattle
actually
customize,
to
deploy
argo
cd
and
from
there
on
argo.
Cd
will
be
managing
everything
in
this
cluster,
including
argo,
cd
itself,
so
any
future
upgrades,
but
basically
I
will
not
be
running
cube
cattle
commands
ever
again.
A
Cd
is
the
directory
and
I
want
I
have
it
defined
in
overlays
production
and
then
I'm
going
to
type
that
to
cube
cattle,
apply,
dash
dash
file
name
and
then
dash
meaning
standard
input,
and
this
will
take
a
few
seconds.
And
after
that
we
should
have
argo
cd
applied,
not
yet
up
and
running
but
applied
there.
We
are
all
the
resources
were
created.
Now.
All
that's
left
from
margo
cd
perspective
is
to
make
sure
that
it
is
running.
A
A
Those
commands
will
update
the
the
username
and
password
actually
the
password
only
of
argos
cd,
changing
it
to
be
admin
right,
like
every
good
password.
Admin
is
always
a
good
choice
for
a
password.
Isn't
it
and
let's
open
argo
cd
and
see
whether
it
is
really
up
and
running
open
http
data
and
argo
cd
then
base
host?
I
think
that
that's
how
I
defined
it-
and
here
we
are
here-
is
the
argo
cd
ui
admin
admin,
as
you
can
guess,
and
there
is
absolutely
nothing
inside
of
no
definition,
nothing.
The
targo
city
is
managing.
A
We
are
going
to
change
that
in
a
second.
So
far
we
only
installed
argo
cd
and
now
we're
going
to
do
the
full
blown
everything
the
whole
production
without.
Actually
this
will
be
this.
This
time
will
be
the
last
time
I
will
access
the
cluster
ever
again
in
right
mode.
Read-Only
is
okay
right,
so
we
need
two
more
things.
We
are
almost
done
with
everything
we
need
from
deployment
perspective.
Everything
one
is
to
create
a
project.
A
So
here
is
the
project
cut
project
yaml,
it's
a
simple
project,
targo
cd
project
that
defines
staging
and
production.
So
here
is
the
production
here
is
staging.
I
will
not
bother
you
with
details,
so
I
assume
that
you
watch
the
video
about
targo.
This
is
not
about
target
it's
about
everything
right,
so
cube
cattle
apply
and
then
file
name
is
project.yaml,
and
now
that
we
have
those
two
projects,
I'm
going
to
create
two
applications,
optimal
and
basically
the
same
logic,
defining
staging.
A
That
will
be
pointing
to
this
repository,
the
repository
where
I
am
right
now
and
to
the
directory
staging
and
another
second
application
that
will
be
production,
right,
production
environment,
pointing
to
the
same
repository
but
to
the
directory
production
and
re.
This
is
now
now
I'm
serious.
This
is
the
last
time
I'm
going
to
change
anything
inside
of
my
cluster
myself.
From
now
on,
argo
cd
will
manage
absolutely
everything,
so
cube
cattle
cuddle
apply
and
then
file
name
is
file,
name
is
abstiamo
and
that's
about
it.
A
Now,
let's
take
a
quick
look
at
what's
going
on
in
argo
cd
ui.
Here
we
are
two
applications
created.
I
don't
know
if
you're
fast
enough
project
production
staging
and
those
two
applications
figured
out
that
there
are
other
applications
and
they're
all
being
created
right
now
right,
so
it
figured
out
everything
now.
This
is
my
whole
product
production
stage.
Everything
at
least
everything
for
this
demo
is
right
here
and
all
I
did
was
just
tell
argosy
hey
these:
are
the
repositories
do
whatever
is
defined
over
there?
Don't
bother
me
much
now.
A
This
will
take
a
couple
of
moments,
so
I
will
fast
forward
again
to
the
end
of
this
process.
There
is
a
lot
of
going
on
like
dem
application,
staging
istio,
egress
resources,
seal
secrets,
argo
combined
approaches
same
application,
demo,
application
production
is
to
itself
argo
events,
argo
workflow,
sergeant,
rollouts,
ingress
for
istio,
argo,
cd,
it's
managing
itself
prometheus
and
staging
and
production
environments.
Whole
shenanigans
everything
happening
with
us
in
the
single
command,
basically
applying
argo
cd
application.
A
So,
let's
fast
forward
to
the
end
of
the
process,
that's
it
everything
is
up
and
running,
except
the
demo
application
running
in
production,
that's
normal,
because
I
didn't
create
the
first
release.
I'm
actually
surprised
that
the
same
one
in
staging
is
running-
that's
surprising,
probably
from
previous
tests
of
of
this
script.
Anyways.
If
you
ignore
the
demo
applications,
those
called
argo
combined
up
and
I
will
combined
up
staging
everything,
is
up
and
running
now.
We
know
how
we
will
deploy
stuff
just
by
pushing
changes
to
git.
A
That's
what
argo
city
does
and
we
need
to
now
figure
out.
How
do
we
create
a
workflow
or
a
pipeline
that
will
do
everything
that
needs
to
be
done
when
we
push
some
changes
to
a
repository
of
an
application.
You
know
it
needs
to
build
container
images.
Maybe
some
binaries
create
some
releases
deploy
to
staging
run
some
tests
deploy
to
production.
You
know
the
process
depends
and
the
exact
steps
will
differ.
A
But
the
point
is
that
we
need
to
figure
out
how
to
do
all
the
automation
before
argo
cd
can
take
over
and
do
the
deployment
itself.
So
everything
happening
until
the
deployment
or
after
deployment
we're
going
to
see.
So
now
we're
talking
about
pipelines
workflows.
So
let
me
go
back
to
the
terminal.
The
next
thing
we
need
are
events.
A
We
need
to
tell
github
to
send
a
web
cook
request
to
our
cluster
and
we
need
to
tell
some
processes
in
a
cluster
to
trigger
some
pipelines,
and
we
are
going
to
do
that
through
argo
events
and
the
pipelines
themselves
will
be
argo
workflows
and
let's
see
how
that
works.
By
the
way.
I
assume
that
you
watch
the
video
about
argo
events.
Argo
workflows,
argo
cd.
A
If
you
didn't
it's
in
the
description
right,
this
is
not
rehashing
the
same
thing
just
how
to
combine
everything,
absolutely
everything
so
argo
events
and
then,
if
you
see
to
overlays
and
then
production
and
then
even
sources
right,
these
are
the
even
sources
from
argo
events
and
basically,
what
this
is
doing
is
telling
hey.
This
is
going
to
be
called
github.
A
There
are
some
ports
to
be
opened
and
I
want
you
to
notify
repository
argo
combined
up.
Actually,
I
want
you
to
modify
repository
combined
up
to
send
the
webhook
request
to
this
specific
address.
Basically,
this
is
creating
a
webhook
request
that
will
be
firing,
events
or
notifications
to
our
cluster
and
english.
That
will
enable
that
communication
right
and
the
second
thing.
So
now
we
know
how
to
trigger
events
into
the
cluster
from
github.
A
Now
we
need
to
figure
out
how
to
pick
up
those
events,
that's
decoupled
and
do
something
with
them
and
specifically
how
to
run
a
pipeline
and
that's
defined
in
a
separate
file.
So
argo
events
overlays
what
was
it
production
and,
I
think,
sensors?
Yes,
this
is
where
I
defined
it
now.
This
is
a
long
one.
I
will
not
go
through
the
details
again.
A
Watch
argo
workflows,
argo
events,
videos
what
matters
is
just
a
quick
overview,
so
this
will
basically
monitor
those
events
coming
from
github
in
the
event
name
is
arco
combined
up,
which
is
event
from
repository
the
very
same
name
and
then
setting
up
few
secrets,
and
after
that
we
have
templates.
This
is
where
things
are
happening:
build
a
container
image
with
kaneko.
How
do
we
build
container
image?
I
don't
know
because
there
is
a
template
that
is
already
defined
in
a
cluster
argo
cd
deployed
it
right.
A
A
A
Basically,
what
we
are
doing
here
is
we
are
getting
the
parameters
we
are
parsing
webhooks
from
github
and
then
extracting
certain
values
like
git
url
and
then
passing
those
values
as
parameters
for
the
workflow
above
right.
So
instead
of
hard
coding,
what
is
the
name
of
the
application?
What
is
name
of
the
image?
What
is
the
repository?
What's
or
not?
We
are
getting
all
that
information
from
web
hooks
right,
so
this
template
could
be
used
not
for
this
application.
A
This
could
be
used
for
any
application
that
uses
the
same
steps
right
not
only
for
this
one,
because
nothing
here
is
hard
coded
nothing.
All
the
things
are
retrieved
from
github
itself,
so
amazing,
very
reusable.
What's
or
not
now
what
else?
Let's
confirm
that
the
web
hook
was
created
really,
and
it's
just
opening
the
hooks
in
github-
and
here
we
are-
you
can
see
here
that
it
created
the
web
cook.
A
Now
don't
be
alarmed
that
it
is
red,
that's
normal,
because
when
argue
events
created
the
web
hook
problem
the
load
balancer
that
allows
the
capturing
those
web
hooks
was
not
created.
At
the
same
time,
this
is
race
condition,
but
trust
me
it
will
work.
Actually.
I
can
confirm
that
right
away
that
this
is
just
a
temporary
problem,
because
load
balancer
was
not
created.
If
I
redeliver
look
at
this,
it
will
be
green
there.
We
are
right.
A
This
is
just
because
load
balancer
was
not
created,
but
web
hooks
are
set
up
up
and
running
magic
right
now.
Let
me
go
back
to
the
terminal
and
I'm
going
to
open
another
address,
to
show
you
something
else:
http
and
then
argo,
workflows
and
then
base
host.
This
is
where
I'm
hosting
my
this
is
where
I'm
hosting
argo
workflows.
Ui
now
this
looks
horrible.
This
looks
like
a
bad
joke
because
it's
empty
think
of
it
as
a
bug
or
a
temporary
problem.
A
A
So
we
have
here
workflows.
We
have
brick
wall
templates,
cluster
workflow
templates.
Those
are
the
templates
that
were
created
by
argo
cd,
because
this
template
builds
container
image.
This
one
promotes
to
staging
of
production
or
whatever
we
want
all
that
is
already
set
up,
and
what
do
we
have
else
even
flows?
We
can
see
how
the
events
are
connecting
things.
What
is
missing
here
is
workflow,
but
that
will
appear
when
the
first
workflow
successfully
is
executed.
So
you
will
see
that
that
soon
and
we
have
even
sources.
A
A
So
now,
let's
go
back
to
the
terminal
and
make
a
change
to
the
application
and
see
whether
the
whole
pipeline,
the
whole
workflow
really
really
works,
and
I'm
going
to
do
that
by
clearing
the
screen.
First,
clear,
I
don't
know
how
to
type
and
then
I'm
going
to
go
to
the
repository
of
the
application,
which
is
argo
combined
up,
I'm
going
to
change
the
the
address
of
production,
which,
basically
it's
it's
based
on
history.
You
will
see
later,
why
is
you
and
only
production
or
staging
you
can
ignore
this
command?
It's
not
important!
A
I'm
going
to
also
change
the
the
address
through
which
my
application
production
can
be
accessed.
I
should
have
done
this
in
advance
again,
not
important.
What
is
important
is
this
guy
over
here,
so
I'm
going
to
open,
conflictomal
config
tunnel
and
I'm
going
to
make
some
silly
change
to
the
application
so
that
you
see
that
it's
working.
So
I'm
going
to
change
this
text
here
and
it
says
where
devops
becomes
practice
and
what
should
they
do?
I'm
simulating
it
I'm
creating
a
new
feature
or
something
like
that
modifying
the
application.
A
I
will
say:
hey
yeah
subscribe
now,
that's
a
good
thing,
so
making
change
to
my
application
and
then
I'm
going
to
do
what
every
developer
does
imagine
that
I
already
tested
it
locally,
that
it
works
as
it
should
be,
and
all
that
stuff
and
I'm
going
to
push
it
to
get
so
get
that
get
commit
dashem
no
commit.
I
don't
know
how
to
type
today
in
dasham
and
what
should
be
the
a
silly
message.
I
hate
writing
messages,
but
they're
very
useful
though,
and
git
push.
A
So
I
push
the
change
to
git
repository
and
now
I
should
see
the
new
pipeline
workflow
running
in
the
ui.
Let's
see
whether
that's
true
I'm
going
to
go
to
the
workflows,
and
here
it
is,
it
is
running
the
pipeline
is
running.
It
is
building
my
container
image
and
remember
not
only
that
I
cannot
access
the
cluster,
but
other
tools
cannot
access
the
cluster.
This
workflow
will
not
deploy
anything
anywhere.
A
What
it
will
do
is
that
it
will
build
a
new
image,
that's
happening
right
now,
and
then
it
will
modify
the
repository,
the
defined
staging
and
then
argo
cd
will
pull
that
information,
deploy.
Something
and
then
I
will
run
functional
integration
tests
and
if
both
are
successful,
I
will
modify
the
repository
that
defines
production
and
then
argo
cd
will
again
do
this,
do
whatever
it
does,
and
it
will
be
running
in
production
now
fast
forwarding
to
the
end
of
the
process.
A
I
have
20
minutes
to
go
through
all
this
for
you
guys
there
we
are
it's
already
program
promoted
to
staging,
and
now
it
is
running
integration
tests
and
functional
tests.
If
you're
wondering
why
am
I
doing
that
right
away
instead
of
waiting
for
a
while,
I
tend
to
use
functional
integration
tests
before
deployments
during
deployments
after
deployments,
but
this
is
mock
now,
so
it
doesn't
matter.
But
what
does
matter
is
that
I
will
go
to
argo
cd.
A
Where
is
argo
cd
and
we're
going
to
confirm
that
staging
changed,
I'm
going
to
go
here
and
I'm
going
to
go
to
the
deployment
and
I'm
going
to
look
for
the
desired
manifest
and
the
image
is
still
the
old
one
right.
So
argo
cd
did
not
pick
it
up
yet
it
will
pick
it
up
in
a
second
or
two
up
to
three
minutes.
That's
the
pulling
frequency
okay.
Now
it
is
progressing.
A
I
could
have
created
the
pull
request
to
do
continuous
delivery
instead
of
deployment,
but
I
was,
I
went
all
the
way
in
complete
continuous
deployment
and
we
should
see
argo
combined
up
here
in
production
also
running
in
in
production,
and
this
is
special,
I'm
using
canary
deployments
and
because
I
wanted
to
allow
only
fraction
of
users
to
use
it.
So
now
we're
jumping
into
the
fourth,
the
last
project
of
argo.
A
We
are
using
canary
deployments
only
in
production,
because
canada
deployments
make
sense
only
in
production.
So
let
me
show
you
what
it
looks
like.
So
how
did
I
define
kind
of
deployments?
Here's
the
rollout
yaml.
This
is
the
definition
only
applied
to
production
of
this
application,
and
it
has
some
some
analysis.
Like
average
number
of
successful
percentage
of
successful
requests,
average
response
time
all
the
jazz
and
it
is
doing
ten
percent
and
then
waiting
for
two
minutes
and
then
reach
increasing
the
weight
to
30
percent
running
analysis.
A
A
A
You
can
see
that
it
is
failing
it's
failing
big
time,
but
that's
normal.
I
can
actually
explain
why
it's
failing.
I
expected
it
to
fail
simply
because
it
is
doing
analysis
of
average
request,
duration
and
the
error
rates
and
stuff
stuff
like
that,
but
it
has
no
data
and
promote
use
simply
because
nobody
is
using
this
application
so
expect
it
to
fail.
If
we
started
using
the
application,
then
we
would
see
some
results,
but
in
case
of
country
deployments,
if
nobody's
using
up
that
application,
that's
a
bad
sign.
A
Absolutely
bad
sign
horrible
sign
anyway,
so
it
is
scaling
down.
But
this
is
this
is
the
proof
we
got
country
deployments
as
well.
We
got
progressive
delivery
and
that's
all
combined.
So
let
me
go
back
to
the
main
screen
full
screen
me
no
more
terminal
and
explain
what
happened,
because
a
lot
of
things
happened
and
I
tried
to
squeeze
it
into
20
minutes.
I
hope
I
did.
Maybe
I
didn't
I'm
not
sure
anyways,
let's,
let's
go
through
what
just
happened,
so
this
was
essentially
a
combination
of
everything.
A
To
be
honest,
I
was
preparing
this
video
for,
like
last
four
or
five
months.
Significant
number
of
videos
I
made
in
the
past
were
made
as
a
preparation
for
this
one,
in
which
I
wanted
to
combine
everything:
progressive
delivery,
githubs
workflows,
events,
secrets
management
through
kit
and
so
on
and
so
forth,
and
we
did
that
by
combining
all
the
tools
that
I
explored
before.
So,
if
you're
confused,
if
you
don't
know
what
happened,
you
probably
haven't
seen
those
videos
so
go
to
the
description
and
check
out
targo
cd,
argo
events,
argo
rollouts,
argo.
A
What
else
is
missing
there?
Something
is
missing,
yes,
workflows
and
sealed
secrets
and
conical
right.
I
explored
those
all
those
in
separation.
This
is
how
to
combine
them
all
together,
and
that
was
the
sinister
reason
I
had
behind
creating
all
those
videos
in
the
past.
I
knew
that
I
will
get
to
this
point,
but
I
had
to
get
there
step
by
step,
and
this
is
the
automation
of
everything
in.
B
A
B
B
A
A
Okay
last
chance,
the
I
I
don't
to
be
honest.
I
don't
not
expect
too
many
questions
or
any
because
this
is
so
many
things.
I
never
did
more
intense
combination
of
so
many
things
in
such
short
time.
So
I
guess
that
it's
confusing
more
than
anything
else.
Tarek
says:
how
do
you
deal
with
the
private
triples
depends
if
you're
talking
about
targo
cd,
you
just
tell
argo
cd,
you
just
provide
credentials
to
argo
city,
so
it
can
pool
contents
of
private
repositories
right.
A
So
argo
city
is
a
pool
based
mechanism,
and
then
we
have
argo
workflows,
which
is
a
pipeline
type,
push
type
mechanism
that
among
many
other
sources,
can
use
web
hooks,
and
in
that
case
it's
really
about
you
setting
up
the
repository
and
you
do
that
by
creating
argo
event,
the
third
one
and
for
argo
event,
you
need
to
provide
credentials
for
your
private,
repo
or
public.
Even
so,
it's
just
kubernetes
secrets
with
credentials
the
short
version
of
the
answer.
A
A
Then
we
use
the
cluster
to
do
cicd
vidargo
for
all
other
kubernetes
clusters
deform
the
deployment
depends
on
the
model
right
and
depends
also
which
argo
projects
we
are
talking
about.
If
you're
talking
about
argo
workflows,
which
is
a
pipeline
type
of
solution,
then
yes,
you
run
it
normally
in
one
cluster,
and
there
is
no
need
for
that.
Argo
workforce
to
know
the
existence
of
any
other
cluster,
because
what
pipelines
do
eventually
is
modify
git
repositories.
A
They
do
not
deploy
anything
directly
and
as
for
deployments,
which
is
argo
cd,
you
can
have
a
model
that
you
have
a
central
argo
cd
that
is
connected
to
all
other
clusters
or
the
one
that
I
prefer
actually
more
is
to
have
argo
cd
agent
in
each
cluster
and
that
way
I
do
not
need
to
give
anybody
or
anything
credentials
to
my
clusters.
If,
if
it's
running
in
each
cluster-
and
it
is
pulling
data,
then
it
can
be
completely
locked
completely
secure.
A
A
And
how
and
then
jeff
says
so,
all
interaction
with
the
kubernetes
clusters
are
through
higher
level.
Argo
interactions,
it's
true,
so
all
interactions
with
kubernetes
when
we're
talking
about
deployment
and
only
deployment
interactions,
are
cargo
running
in
your
kubernetes
cluster
and
pulling
git
repositories.
Whenever
there
is
a
drift
between
what
is
in
a
git
repository.
What
is
the
actual
state?
It
will
do
whatever
needs
to
be
done
to
converge.
Those
two
states,
if
you're
talking
about
targo
cd,
if
you're
talking,
I
you
said
thanks.