►
From YouTube: Flux Deep Dive: A GitOps Approach to Progressive Delivery - Stefan Prodan & Hidde Beydals
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Flux Deep Dive: A GitOps Approach to Progressive Delivery - Stefan Prodan & Hidde Beydals, Weaveworks
“Progressive Delivery” refers to a set of techniques for reducing deployment risk by decoupling the deployment from the release process. In this session, Stefan and Hidde will talk about implementing these techniques on Kubernetes. We will discuss in depth how canary releases can be orchestrated through Git operations, declaratively, using Kubernetes custom resources and Flux git-to-cluster synchronization. We will demo a GitOps pipeline that automates the release process of a web application. The demo will feature: - Flux for cluster state management - Flux Helm Operator for app deployments - Flagger for app testing and incremental rollout
https://sched.co/Zev2
A
A
A
Just
to
give
you
a
background,
we
started
flux
at
we
works
four
years
ago
and
since
then,
kubernetes
ecosystem
has
evolved.
A
lot
flux
was
made
to
reconcile
the
cluster
state
with
git,
using
a
single
repository,
a
single
git
repository
as
the
source
of
truth
for
for
both
infrastructure
and
workloads
alike.
A
A
A
A
A
A
We
can
extend
flux
capabilities
with
extensions
such
as
let's
say
you
want
to
trigger
reconciliation
through
a
github
web
web
hook
receivers
or
you
want
to
send
kubernetes
events
and
toolkit
alerts,
slack
or
microsoft
tools.
All
this
will
be
possible
by
adding
more
components
to
your
current
installation.
A
A
The
fleet
controller
will
be
interacting
with
kubernetes
cluster
api.
Various
implement
implementation
to
drive
detox
workflows
across
your
whole
fleet,
not
just
a
single
cluster.
What's
important
here
that
all
these
specialized
ripple
sellers
will
be
getting
their
manifest,
their
stores
from
the
source,
api
and.
A
At
the
core
of
our
toolkit
is
the
it's
a
future
called
source
management,
so
we
extracted
git
and
helm
repository
operations
from
flux
and
helm
operator
and
made
a
dedicated
component
called
source
controller.
The
source
controller,
fetches
kubernetes,
manifests
from
different
sources,
let's
say
heat
repository
or
heavenly
poison
or
multiple
of
those
and
expose
the
the
manifests
inside
the
cluster
and
immutable
artifacts.
It
also
deals
with
authentication
and
it
reacts
to
events
from
outside,
for
example,
a
github
web
hook
or
or
something
like
that.
A
B
Thank
you.
Stefan,
due
to
the
limited
amount
of
time
you
have
today,
you
will
see
me
skipping
some
slides.
These
are
comparison,
slides
between
flux,
v1
and
toolkit
component
driven
flux,
v2
features.
Basically,
when
the
slides
are
published,
please
go
and
have
a
look
at
them,
because
you
will
get
a
better
picture
of
the
new
possibilities
and
features
that
toolkit
components
introduce
compared
to
flex
v1.
B
It
introduces
a
new
customization
custom
resource
which
contains
a
reference
to
a
source
controller
kit
repository,
unlike
the
name
suggests,
it
supports
both
customized
overlays
and
yammer
manifest.
The
latter
is
made
possible
by
generating
a
customization.gmo
on
the
flight
during
the
reconciliation
of
the
customization
resource.
B
B
B
These
readiness
status
can
be
used
to
keep
color
weight
on
the
customization,
but
it's
also
used
in
depends
on
relationships
defined
in
other
customization
resources,
which
will
make
the
controller
wait
for
all
the
depends
on
definitions
to
be
ready.
This
way
you
can
control
the
apply
order
of
customizations,
and
one
of
the
reasons
you
may
need.
This
is
because
you're
making
use
of
a
custom
resource,
but
the
good
resource
definition
is
reconciled
by
another
customization
so
present
in
another
kit
repository.
B
B
Some
actions
like
install
an
upgrade
have
now
their
own
extensive
configuration
flags
in
the
custom
resource
and
different
remediation
strategies
can
be
configured
for
when
things
go
wrong.
It
also
supports
depends
on
relationships
like
the
customized
controller.
It
does
no
longer
perform
dry
range
for
hamster
swift
detections
and
has
an
overall
simplified
operation
model.
B
B
The
resource
on
the
right
right
defines
a
github
receiver,
which
works
to
push
attention
from
github.
When
a
notification
provider
receives
an
event
from
getting
to
validate
the
payload
based
on
the
configured
token
in
the
secret
draft,
and
it
will
trigger
a
reconciliation
of
people
with
resources
during.
A
A
Thanks
so
some
of
you
may
be
familiar
with
with
flagger
it's
a
project
that
we've
been
working
on
in
the
past
two
years.
Almost
you
can
think
of
flagger
in
the
github's
toolkit
context,
as
a
specialized
controller
that
helps
you
reduce
the
risk
of
production
releases
and
flagger
can
enable
you
to
use
advanced
deployment
strategies
when
you
are
releasing
applications
with
the
toolkit.
A
Another
strategy
that
you
could
use
is
called
a
b
testing
how
ap
testing
works.
You
will
be
segmenting
your
users
and
based
on
http
headers
or
a
user
cookie.
You
can
configure
a
flagger
to
route.
Only
those
specific
users
to
the
new
version
and
flair
will
observe
how
the
the
users
are
interacting
with
the
new
version.
If
there
are
errors,
if
there
are
things
like
increased
latency
and
based
on
those
metrics,
it
will
promote
or
roll
back
the
new
version.
A
Another
strategy
is
blue,
green
with
traffic
mirroring
this
kind
of
strategy
works.
If
you
have
one
ingress,
controller
or
service
mesh
like
histo,
that
knows
how
to
do
traffic
mirroring
and
it
it's
it's
well
suited
for
either
important
apis,
something
like
a
machine
learning
work
workload
or
something
that
does
reporting
any
kind
of
api
that
does
only
read.
Actions
should
fit
with
with
this
type
of
strategy.
A
The
idea
here
is
that
all
the
traffic
that
your
users
are
generating
on
the
old
release,
that
traffic
is
being
long
forward
due
to
the
new
release,
flagger
looks
at
the
metrics
and
decides
if
it
should
promote
it
or
not,
and
finally
is
the
classic
blue
green
strategy,
where
flagger
will
spin
up
the
new
version,
it
can
run
your
end-to-end
tests,
conformant
tests.
You
can
also
do
load
testing
for
for
for
the
new
version
and
based
on
those
results,
it
will
promote
or
not.
A
So
flagger
works
out
of
the
box
with
the
gitos
toolkit.
You
can
use
it
even
today.
What
we
are
trying
to
do
in
the
future
is
making
the
toolkit
aware
of
the
canary
analysis
that
flagra
performs,
and
in
this
way
we
can
leverage
the
depends
on
relationship
that
the
toolkit
introduces
with
flagger
canadi.
So
you
can
imagine
you
can
say
I
want
to
run
first.
A
A
We
invite
you
there
to
create
a
new
discussion
and
you
know
come
up
with
proposals.
If
you
have
any
or
comment
on
the
current
proposals,
we
have
a
thing
in
place
where,
when
we
want
to
add
the
new
api
or
we
went
or
or
when
we
want
to,
you
know
create
a
new
future
inside
of
it
we'll
be
creating
a
discussion.
Everybody
should
debate
on.
What's
the
right
decision
to
implement
that
future
and
once
that
is,
is
finalized.
Only
after
then
we
create
an
issue
under
write
repository
and
we
do
the
implementation.
A
B
A
A
Namespace
access,
slash
admin
only
and
use
flux,
so
in
the
box
d2
we
we
have
a
way
of
restricting
what
a
git
repository
can
alter
on
the
cluster,
so
flux,
v2,
made
out
of
toolkit
components,
will
run
as
cluster
admin
on
each
cluster
on
your
fleet.
But
then
you
can
say
for
this
particular
git
repository
all
the
things
that
users
will
be
placing
in
that
industry
will
be.
A
One
milestone
is
the
first
one
is
getting
future
parity
with
lux
read
only
mode.
What
flux
with
only
mode
means
is
when
you
run
flux,
only
to
apply
changes
in
it
without
allowing
flux
to
write
back
to
things
like
image
updates,
for
example,
so
flux
in
read-only
mode
parities
is
at
eighty
percent
right
now.
We
we
want.
A
We
are
left
with
implementing
soap,
soaps,
decryption
and
writing
a
guide
on
how
you
can
upgrade
from
v1
to
v2,
and
we
are
currently
experimenting
with
the
image
update
controllers
and
we
welcome
anyone
that
you
know
if
you
have
ideas
on
how
we
can
make
the
image
update
work
for
you.
Please
join
our
discussion
on
on
github.
A
As
for
the
helm
operator,
we
are,
let's
say
around
50.
We
still
want
to
work
on
automated
rollbacks,
based
on
specific
events
such
as.
If
a
helm
test
fails,
then
maybe
you
want
to
do
an
automatic
rollback
or
if
the
upgrade
fails
and
so
on
and
all
these
roll
back
conditions
are
are
are
being
developed
right
now.
B
There's
a
question
about
how
damn
release
vrs
are
synchronized
to
the
cluster.
It's
basically
very
simple:
the
customized
controller,
syncs
them
and
you
can
put
any
resource
into
a
and
the
customize
controller
will
auto
generate
a
customization
dot
gmo
for
it.
So
the
loop
is
basically
that
the
customized
controller
applies
them
to
the
cluster
and
then
the
home
controller
will
pick
up
the
apply
of
the
resource
and
that's
how
it's
synchronized
from
get
any
other
questions.
B
There's
a
question
about
the
graphic
user
interface:
we
have
a
very
advanced
prometheus
that
dashboard
that
automatically
ships
for
every
controller
and
we're
looking
at
other
options
to
give
you
a
better
overview
of
custom
resources
which
are
part
of
the
toolkit.
But
there
are
no
specific
plans
at
the
moment.
A
Yeah,
I
can.
I
can
second
that
and
say
the
crime
maintainers
of
the
flux.
Cd
organization
are
mostly
backend
people,
so
I
don't
feel
comfortable
writing
ui
for
flux,
and
I
don't
think
if,
if
someone
wants
to
contribute
that-
and
has
I
know,
front-end
skills
knows
javascript
very
well.
We
are
happy
to
to
collaborate
on
that,
but
the
current
thing
will
not
be
working
on
a
on
a
user
interface.
A
Another
question:
will
there
be
an
arm
release
for
the
github
toolkit
we've?
We
have
experimented
experimenting
with
docker,
build
x
inside
github
actions
to
build
a
multi-arch
image
for
kubernetes
controllers
and
it
works.
It
takes
around
half
an
hour
to
build.
We
have
in
the
toolkit
in
the
end
will
be
around
seven
controllers,
so
you
can
imagine
waiting
30
minutes
after
each
build
after
each
commit
doesn't
doesn't
scale.
We
cannot
work
with
this
kind
of
build
pipeline,
so
we
are
we'll
be
collaborating
with
with
github
and
find
the
solution.
A
Another
question
was:
what
is
the
migration
path
from
flags?
You
want
flux
v2,
so
if
you
are
using,
let's
say
flux
in
read-only
mode
right
now
you
could
uninstall
flux,
run.
Dk
install,
add
the
git,
the
same
git
repository
that
flux
was
synchronizing
with
and
the
toolkit
will
take
it
from
there
with
no
downtime
your
workloads
or
anything
like
that.
A
If
you
are
using
flux.yaml
and
you
do
a
customized
build
inside
with
flux,
the
same
thing
will
work
with
no
changes.
But
if
you
are
running
custom,
shell
scripts-
or
I
don't
know,
you
run
your
make
files
and
you
do
set
to
replace
things
in
your
yamas
that
will
there
is
no
migration
path
to
that.
Basically,
we're
not
going
to
support
in
flux,
v2,
custom
scripts.
A
Those
are
more
for
ci,
so
our
recommendation
is,
if
you
are
doing
custom
mutations,
templating
or
whatever
you
are
doing
with
your
yamas,
try
to
do
it
in
ci
and
publish
the
end
result
the
yaml
output
to
a
particular
branch
and
then
configure
the
toolkit
to
synchronize
with
that
branch,
and
the
only
exception
to
this
is
customize
overlays
I
mean
in
flux,
v2.
You
can
you
can
tell
the
reconciler,
where
is
the
path
to
a
specific
customized
overlay,
and
the
toolkit
will
will
build
that
for
you,
but
accept
customize
and
help.
A
B
A
There
was,
there
is
a
question:
what
is
the
developer
experience?
Okay,
let
me
talk
for
one
minute
about
developer
experience,
flux,
v2
runs,
let's
say
asynchronous
from
your
git
operations
like
you.
Do
a
git
push
then
at
some
point,
flux
will
synchronize
that
on
the
cluster
and
if
you
want
to
find
out
if
it
failed
or
not,
you
have
to
look
at
flux
logs
or
you
can
configure
slack
notifications,
for
example,
have
to
look
there
with
the
github
storkit
and
in
flux
v2.
B
A
A
The
toolkit
will
will
apply
those
those
changes.
Then
it
will
write
back
to
github
on
that
particular
commit
was
the
final
status?
Did
it
worked?
Did
it
fail?
It
also
publishes
a
health
check
results
so,
for
example,
maybe
the
apply
worked,
but
then
your
deployment
has
failed
to
rolled
out
and
we'll.
Let
you
know
in
the
in
the
status
object
inside
github
that
that
particular
deployment
failed,
and
we
are
also
publishing
the.