►
Description
This session will take a demo-based, deep-dive, covering the major features found in the Argo project, and explore how we got here, and where we’re going.
A
Next,
we're
joined
by
hong
and
kelsey
hong
is
a
founding
member
of
the
argo
project
and
prior
to
founding
acuity.
He
was
the
argo
team
manager
at
intuit
and
he
built
the
control
plane.
That's
used
to
manage
hundreds
of
kubernetes
clusters
and
thousands
of
namespaces
hong
has
extensive
experience
and
distributed
system
projects
ranging
from
storage
to
cloud
infrastructure
to
spring
past
cisco
and
yahoo.
Hong
received
his
ms
in
electrical
and
computer
engineering
from
carnegie
mellon
university
and
we're
also
joined
by
kelsey
hightower
kelsey
is
a
principal
engineer.
A
At
google
working
on
google's
cloud
platform
he's
helped
develop
and
refine.
Many
google
cloud
products,
including
google's
kubernetes
engine
cloud
functions
and
api
gateway,
kelsey
spends
most
of
his
times
with
executives
and
developers
spanning
the
global
fortune,
1000
helping
them
understand
and
leverage,
google
technologies
and
platforms
to
grow
their
businesses.
Welcome
hong
and
kelsey.
B
So
we're
just
going
to
cover
a
bunch
of
things
today,
and
I
just
want
you
to
give
me
that
authentic
look
that
maybe
the
look
that
people
haven't
seen
before
when
it's
like
building
platform
tools
inside
of
a
company
like
the
one
you
just
came
from
so
we're
just
going
to
jump
off
a
little
bit,
maybe
give
people
a
little
bit
of
the
day-to-day
kind
of
activities.
You
were
doing
that
led
up
to
the
creation
of
argo
cd.
C
Yeah
definitely
so
we
created
our
goal
to
solve
the
practical
problem,
because
when
we
looked
over
the
intel
landscape,
we
have
so
many
clusters,
so
many
segments
and
so
many
namespace
advantage
and
in
the
end
we
figured
out
hey
what
we
look
at
as
a
landscape,
about
open
source.
There's
no
open
source
project
actually
trying
to
give
you
a
multi-cluster
management
control
plan
for
clusters,
especially
for
the
deployment
pattern,
and
that's
why
we
decided
hey.
C
We
got
the
argo,
workflow
worked,
fine
and
how
about
we
create
another
open
source
project
which
is
called
argo
cd
and
so
as
to
we're
moving
towards
our
routes.
Every
single
product
we
created
was
trying
to
solve
a
particular
use
case.
Add
into
it,
however,
because
we
use
it
at
including
production
and
we're
using
large
scale.
So
we
were
able
to
put
all
our
expertise
and
experiences
into
it
and
make
it
better
and
better.
B
Yeah
one
thing
I
like
about
the
whole
story
and
the
origins
of
argo
cd
is
that
a
lot
of
times
tools
like
these
will
come
from
like
a
dedicated
product
company.
You
know
look
when
you're
in
a
product
company.
You
don't
really
have
to
use
it
in
production,
even
though
we
might
try
to,
and
you
don't
have
to
deal
like
the
organizational
issues
of
a
larger
enterprise.
B
But
one
thing
I
think
that's
unique
about
this
particular
story.
You
like
a
lot
of
people
that
are
probably
listening
to
this
call
like
you,
have
a
bunch
of
kubernetes
clusters.
Look
kubernetes
is
pretty
great
out
of
the
box,
but
we
all
know
at
some
point
you're
going
to
be
developing
some
custom
tooling
to
either
manage
rollouts
or
do
something
that
is
filling
a
gap
in
kubernetes.
C
Yeah,
basically,
that
is
our
philosophy
and
actually
applied
to
every
single
of
the
product
like
we
saw
the
artwork
workflow.
Basically,
that
is
a
very
advanced
version
of
the
kubernetes
job,
which
can
only
run
one
pot,
but
added
at
some
stage.
You
will
definitely
need
to
chain
several
parts
together
to
do
something
more
sophisticated.
C
B
Yeah,
let's
start
with
workflows,
you
know
when
I
think
about
kubernetes,
and
there
are
going
to
be
some
people
that
are
new
to
kubernetes.
One
thing
that
stands
out
about
kubernetes
is
this
concept
that
you
can
have
different
types
of
workloads
like
the
first
workload.
I
think
most
people
get
familiar
with
these
days.
Is
the
deployment
workload
right
this
concept
of
here's,
my
application
all
of
this
dependencies
and
then
I
can
hand
that
off
to
kubernetes
and
we'll
do
the
right
thing,
but
there
was
never
really
any
workload
type
I
mean
we
had
cron
jobs.
B
We
can
set
a
timer
and
run
a
container
every.
So
often
we
have
things
like
batch
jobs
that
you
can
run
a
job
until
completion,
but
there
was
no
kind
of
workflow
thing.
Is
this?
You
know
what
made
you
first
of
all,
what
was
the
use
case
that
made
you
feel
like
hey?
We
need
a
new
workload
type
that
kubernetes
can
execute,
and
then
you
know,
how
would
you
go
about
doing
that.
C
Yeah,
it
has
what's
a
long
story.
Basically,
as
the
founding
engineer,
I
started
argo
workflow
project
five
years
ago
and
with
several
other
key
members,
so
argo
workflow
was
quite
a
different
product.
At
that
time
it
is
a
full
ci,
cd
solution
and
with
a
lot
of
features,
a
lot
of
the
complications
is
quite
heavy.
So
until
then,
we
decided
hey,
cre
is
there,
which
is
great
revolutionary
and
we
said
hey.
C
We
took
that
opportunity
to
rewrite
it,
because,
instead
of
trying
to
do
some
proprietary
or
very
complicated
thing,
we
won't
make
it
kubernetes
native,
because
that
is
kind
of
like
the
spirit
of
the
open
source.
You
want
to
open
through
something
and
make
it
the
core
and
enable
others
to
do
additional
things
that
basically
makes
argo
our
initial
article
and
our
workflow
so
successful,
basically
boom.
So
many
people
are
building
things
on
top
it
because
we
made
the
right
decision
to
make
the
core
and
credit
native
queue
flow.
B
But
basically
you
have
the
command
line
tool,
coupe
ctl,
trying
to
orchestrate
the
rollout
of
software,
and
if
you
close
your
laptop
mid-flight,
then
it
would
just
stop
right,
and
it
was
just
this
weird
place.
Like
does
koopsie
tail
pick
up
and
keep
going,
and
so
I
don't
think
we
ever
gotten
to
a
point
where
we
have
very
sophisticated
ways
of
rolling
out
software,
and
then
argo
rollouts
show
up
what
was
the
kind
of
motivation
behind
that
and
maybe
give
people
a
little
bit
of
how
it
works
and
how
it's
a
little
different
than
deployment.
C
C
First
is
a
quite
a
good
percentage
of
the
instance
actually
happened
around
the
software
release.
It's
a
big
number,
like
20
50
percentage
of
that.
Second,
we
paid
10
million
dollars
to
have
the
best
login
solution,
magic
solution,
tracing
solution,
great
money.
However,
we
use
it
most
of
the
time
trying
to
root
cause
some
problem
of
something
that
happened.
So
it's
not
trying
to
prevent
something
from
happening,
but
rather
than
just
root
cause
it.
C
So
then
we
say
hey
what's
the
point,
so
it's
basically
a
no-brainer
at
that
time
is
we
want
to
build
this
feeder
back
loop
by
using
the
matrix
data
to
dry
the
software
release?
That's
how
we
start
that
idea.
We
talked
with
our
application
team.
They
really
love
it
and
that
we
create
the
overalls
nowadays.
C
B
Yeah,
so
I
always
explain
to
people
when
people
say
what
are
the
kubernetes
best
practices
and
out
of
the
box.
Look
there's
basic
functionality
there,
but
I
always
tell
teams,
like
you
have
a
couple
of
choices.
You
can
either
buy
or
build
some
of
these
extensions,
and
these
patterns
are
born
in
in
practice,
they're
born
in
production,
and
it
sounds
like
you
have
to
support
your
developers.
My
guess,
you
probably
started
like
the
rest
of
us.
B
C
Yeah,
basically,
that
is
I
we
don't
want
to
make
it
to
be
more
like
proprietary
or
customized
to
us.
Basically,
we
try
to
generate
a
general
pattern.
That's
why
we
think
that's
beneficial
to
make
it
open
source
and
also
we
have
this
called
the
analysis
template
which
is
quite
flexible,
so
you
can
hook
up
on
any
logic
you
want,
and
that
can
help
you
to
drive
the
blue,
green
or
canary.
So
we
think
that's
the
future
pattern.
We
understand
kubernetes
trying
to
be
like
bare
mental.
B
All
right
so
look,
you
got
workflows,
you
got
rollouts
and
so
a
lot
of
people
would
say:
look
I'm
just
going
to
take
these
things
and
probably
glue
them
together
in
my
cicd
tool,
and
you
can
pick
any
tool
and
probably
just
grab
those
two
components
and
enhance
their
capabilities
in
terms
of
interacting
with
kubernetes.
But
if
we
just
go
through
the
product
line
again
we
get
this
argo
cd.
So
it
seems
like
things
coming
back
full
circle
where
you
go
from.
C
Yeah,
we
need
the
multi-cluster
support
from
day.
One,
the
reason
is
include
is
a
large
enterprise
environment
and
for
a
single
application
you
will
have
many
environment
in
different
clusters.
You
will
have
dev
staging
production
and
even
for
the
production,
you
may
have
three
different
regions
to
deploy,
and
you
definitely
need
one
control
plane.
Making
that
much
easier
to
auction
means
you
want
to
deploy
to
one
environment,
one
cluster.
First,
you
then
can
propagate
to
others,
and
that
is
basically
our
rational
reason
behind
it.
C
We
need
a
multi-cluster
manager
and
secondly,
one
big
reason
we
did
rlcd
in
this
way
is
also
its
ui.
It's
application-centric
view
because
we
think
application
is
the
best
granularity
for
application
developers,
sre
and
devops
to
collaborate
and
talk
with
each
other
and
trying
to
getting
things,
make
things
better
rather
than
you
using
the
namespace
view
or
cluster
view.
That
is
just
the
granularity.
It
doesn't
work
in
a
large
scale.
B
B
How
do
we
make
sure
that
each
of
these
clusters
have
the
right
set
of
configs
or
running
the
right,
apps,
different
versions,
and
also
how
do
we
implement
all
of
these
patterns
and
one
approach
I've
seen
people
do
is
like
the
pool
model
right,
they'll
set
up
these
clusters,
configure
them
all
to
point
to
one
get
repository,
make
the
change
and
then
bam
the
change
rolls
out
to
all
their
clusters
worst
case,
everything
goes
down
at
the
same
time.
Right
when
I
looked
at
argo
cd,
it
seems
like
you
took
a
different
approach.
C
That,
basically,
is
we
are
not
trying
to
go
to
a
big
band.
We
are
trying
to
give
you
the
flexibility.
You
can
show
yourself.
Yes,
you
can
still
do
the
big
bang,
because
we
have
the
auto
sync
feature.
Baking
means
if
you
want
in
autopilot
mode,
so
be
it,
but
what
we
thinking
works.
The
better
is
using
your
using
your
ci
solution
to
to
orchestrate
more
in
your
granularity,
basically
to
control
what
you
want
like
you
can
go
to
the
staging
very
quickly,
but
you
won't
have
approval
step
for
the
production,
so
be
it.
B
All
right
so
now,
what
I'm
going
to
do
is
pivot
to
the
elephant
in
the
room
I'm
going
to
pull
up
the
kudi
website.
So
I'm
going
to
read
the
top
of
this
akuti
announces
4.5
million
seed
to
modernize
the
cloud
native
tool
chain
with
argo
number
one.
I
remember
seat
rounds
used
to
be
like
fifty
thousand
dollars
that
you
raised
from
like
friends
and
family.
So
look
you're
now
raising
eight
rounds
of
c
rounds.
C
So
it's
actually
not
that
complicated,
very
simple.
It's
basically
a
decision
based
on
my
own
priorities,
so
argo
project
is
so
successful
because
we
spend
so
much
effort
in
the
community
and
we
use
it
in
production
at
intuit.
However,
I
as
the
manager
I
was
struggling
to
balancing
between
the
internal
and
external
things
and
as
an
engineer,
you
always
have
some
struggle
with
priorities.
That's
common!
C
Then
I
think
this
basically
is
not
sustainable.
For
me
to
keep
to
keep
the
argo
project
as
my
side
project,
I
have
to
make
a
choice
at
some
time.
So
that's
basically
my
decision
with
my
co-founder
jesse.
So
we
want
to
put
a
company
behind
our
goal
that
allow
us
to
be
full-time
to
work
on
our
goal
and
also
not
just
helping
intuit.
We
can
help
many
other
companies
adopt
our
goal
in
a
large
scale
and
share
our
experience
in
a
large
scale.
C
B
Awesome
and
just
like
any
other
great
company
here
as
we
wind
down
look,
the
open
source
project
is
super
successful.
I
think
one
of
the
challenges
you're
going
to
have
going
forward
is
that
you're
going
to
have
all
these
people
who
have
also
decided
to
build
their
business
and
back
their
companies
behind
argo
project?
How
do
you
deal
with
like
stewardship?
How
do
you
collaborate
with
the
community
on
the
roadmap?
What's
coming
forward
for
the
project.
C
Definitely
so
we
want
to
make
the
project.
The
next
stage
is
more
extensible
means
we
are
introducing
a
plug-in
framework.
I
think
we're
talking
about
argo.
Workflow
has
plugging
we're.
Also
talking
about
argo
cd
has
plugging
and
we're
less
basic
direction.
We
want
to
open
it
up
more,
so
we
will
help
the
people
to
getting
the
customized
experience
they
want,
but
the
core
part
should
still
stay
with
open
source.
C
The
core
thing
we're
talking
about
workflow
engine
armor
city
as
github's
engine
organ
ross
as
a
deployment
engine,
that's
basically
our
direction,
so
we
definitely
want
to
support
each
other
to
do
the
innovation.
On
top
of
that,
that's
why
we
are
happy
to
partner
with
all
the
companies.
If
you
want
to
have
the
customized
experience,
we
know
you
might
need
it
like
find
us.
We
are
the
expert
in
this
area.
B
Awesome,
I
think
we're
look
we're
out
of
time.
So
I
think
one
of
the
big
takeaways
is
that
argos
sounds
like
it's
going
to
be
here
to
stay,
and
I
think
a
lot
of
people
in
the
community
are
going
to
be
looking
forward
to
things
like
argo
conformance,
how
to
make
sure
that
there's
compatibility-
and
it
sounds
like
you
all-
are
working
on
extensions.
I
mean
with
that.
We're
gonna
wrap
it
up
for
today.
Hon.
Where
can
people
find
you
if
they
want
more
information
or
follow
along
what
you
all
are
working
on.