►
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.
Flux's Roadmap to General Availability - Hidde Beydals & Michael Bridgen, Weaveworks
The past year has been an important one for Flux and GitOps. The team has built a new Flux made of multiple controllers that are now seeing production use. The project has matured and is on its way to General Availability. Flux v2's core is a set of precise API’s for controlling and delegating every element of a GitOps platform. A single Flux install can now work with many parts of multiple git repositories, and Flux is more usable and observable than ever. The project has first-class support for popular technologies like Kustomize, Helm, Prometheus, SOPS, GitHub, and GitLab, and it provides extension points in all areas to integrate with other technologies and platforms, much like Kubernetes itself. This session will consist of a cool 15 minute demo of common and novel Flux use-cases that show just much progress the community has made. Join in afterwards for a 20 minute discussion on the remaining roadmap items for the v2.0.0 GA release candidates.
A
Today,
we're
going
to
talk
about
road
map,
flux
v2
through
to
general
availability
or
ga,
and
a
peak
beyond
that.
I'm
going
to
talk
about
the
road
map
weighted
somewhat
towards
future
developments.
Then
here
it
will
give
you
a
demo
of
what
you
can
do
with
flux
v2.
Today,
first
of
all,
who
am
I
or
just
some
engineer?
Let's
move
on
to
summarize
the
history
of
flux.
A
What's
now
called
flux,
v1
was
created
at
weaveworks
to
deploy
new
versions
of
services
to
a
software
as
a
service
implementation
called
wecloud
prior
to
version
1.0.
It
concentrated
mainly
on
upgrading
upgrading
container
images,
but
then
we
made
a
big
change
in
june
2017,
which
turned
it
all
around
so
that
it
applied
everything
from
git
and
made
updates
by
committing
to
git.
This
was
the
big
bang
event
for
gitops
flux
was
inducted
into
the
cncf
as
a
sandbox
project
in
august
2019,
but
by
then
it
was
creaking.
A
A
A
What
does
that
mean?
What
does
general
availability
mean?
Usually
it's
taken
to
mean
that
a
piece
of
software
is
considered
ready
to
run
in
production
within
open
source.
People
have
different
appetites
for
risk,
so
many
would
have
already
adopted
a
product
before
ga
release,
but
here
is
what
it
means:
flux,
v2.
A
A
A
A
A
A
A
A
A
So
the
picture
on
the
slide
shows
the
general
situation,
the
source,
the
application
and
the
target
for
the
application
can
all
have
different
owners
or
name
spaces,
but
you
still
want
our
back
to
be
in
effect,
if
you
know
flux
well,
you
might
ask:
isn't
this
already
possible?
Yes,
it
is,
but
it's
not
well
enforced.
A
A
A
Another
change
coming
up
for
documentation
is
having
specialized
sections
for
the
cloud
platforms
as
your
gcp
aws
and
so
on.
It's
useful
to
collect
box
together
this
way,
because
typically
you're
using
one
of
those
at
a
time,
and
so
the
sections
will
serve
as
a
one-stop
shop
for
all
the
relevant
information,
and
these
changes
to
documentation
are
not
all
prerequisites
for
ga,
but
I
wanted
to
mention
them
here,
because
they
are
nonetheless
a
part
of
flux's
growth
and
maturity
as
a
product.
A
A
Flux,
v1
and
flux
v2
have
always
included
quebectol
or
cubical
in
their
container
images
as
the
means
of
applying
configurations
to
the
kubernetes
api,
and
that's
because
quebectyl
contains
a
lot
of
logic.
That's
difficult
to
reuse
or
to
reproduce,
for
example,
doing
three-way
merges
of
resource
definitions.
A
It's
now
possible
to
rely
on
kubernetes
api
server
to
do
the
tricky
bits
like
merging
definitions
and
avoid
the
need
for
shelling
out
to
quebector
and
in
particular,
the
field
management
mechanism.
Also
lets
you
see.
Fine-Grained
conflicts,
which
means
flux,
can
be
more
sophisticated
in
how
it
applies
configs
and
keep
out
of
the
way
of
other
actors
like
auto
scalers.
A
The
one
goal
of
flux
is
to
provide
primitives
to
people
to
build
their
own
git,
ops,
flavored,
continuous
delivery,
there's
different
varieties
of
that
hooking
up
your
system
to
the
inputs
and
outputs
of
the
controllers
and
flux,
which
I
would
call
integration
and
making
your
own
types
and
controllers
that
can
be
used
with
those
and
plugs
which
I
would
call
extension
and
for
the
purpose
of
extension.
The
api
is
not
as
open
as
it
could
be.
A
By
open,
I
mean
that
you
don't
need
flux
to
be
changed
for
you
to
be
able
to
add
to
it
right
now.
It
is
possible,
as
shown
in
the
picture
there,
to
write
a
controller
that
consumes
sources,
but
it's
not
possible
to
write
a
controller
that
provides
a
new
kind
of
source,
because
the
source
types
are
hard
coded.
A
A
Some
of
these
are
pretty
close
to
being
standalone
and
generic
functions
in
themselves,
which
could
be
moved
into
their
own
api
types
and
controllers.
The
benefit
to
doing
this
would
be
extensibility
again.
It
would
be
easier
to
build
a
flagger
analog
that
caters
to
a
scenario,
not
in
the
scope
of
flagger.
A
For
example,
flagger
deals
with
workloads
deployments
and
demon
sets,
but
you
might
want
it
to
roll
out
another
kind
of
object
that
doesn't
follow
the
same
rules.
You
could
use
the
metrics
routing
and
gating
parts
of
flagger
and
write
your
own
shadowing
logic
to
have
your
own
form
of
progressive
delivery.
A
A
A
B
Thank
you,
michael
and
hello
folks,
just
another
engineer
here
who
is
going
to
demo
the
most
recent
part
of
flux
to
reach
this
table
api
image,
update
automation.
If
this
is
not
a
topic
of
interest
to
you,
you
can
find
other
demos
on
how
to's
on
the
flux
website
to
run
the
demo,
I'm
going
to
share
my
screen,
which
means
you
will
have
to
miss
out
on
my
face
for
a
little
while.
B
Plugs
comes
with
the
cli
which
allows
you
to
generate
flex
api
objects
and
control
the
life
cycle
of
them,
but
also
provide
access
to
bootstrapping
features
for
this
demo.
We
are
going
to
bootstrap
against
github
bootstrapping
against
gitlab
or
playing
kit.
Server
is
possible
as
well.
I'm
now
going
to
type
out
the
bootstrap
command
and
explain
some
of
the
flags.
B
B
Now,
as
you
can
see,
the
bootstrap
command
showed
that
everything
was
actually
already
set
up
and
the
controllers
are
already
running
in
the
cluster.
This
is
because
I
cheated
and
run
the
command
before
the
demo
to
save
us
some
time.
I
show
you
it's
idiom
potent
and
will
only
make
changes
if
things
aren't
up
to
date.
Let's
click
quickly
clone
our
bootstrap
repository
and
navigate.
B
B
B
B
B
B
B
I
spotted
him
for
his
release
of
proper
sam
versioning.
I
created
the
policy
to
select
the
latest
version
within
the
major
5
sample
range
now,
with
these
two
objects.
Flux
knows
where
to
look
for
image
stacks
and
what
the
latest
stack
is
based
on
the
defined
policy,
but
it
doesn't
do
anything
with
this
information
yet
to
make
it
start
looking
into
outdated
references
in
a
git
repository,
we
need
to
create
an
image,
automation,
object
that
tells
flux
where
it
should
look
and
how
it
should
write
the
new
images
back
to
git.
B
B
B
The
get
to
object
at
the
top
defines
what
git
reference
should
be
checked
out
and
inspected
for
outdated
images.
What
the
commit
message
should
look
like
and
where
the
commit
should
be
pushed
to
with
the
current
configuration
options,
changes
are
pushed
directly
to
the
branch
that
is
synchronized
to
the
cluster
and
updates
should
be
fully
automatic.
B
The
commit
template
ensures
that
if
multiple
images
are
updated
in
a
single
commit
they
are
listed
in
the
commit
metadata.
The
update
object
defines
the
scope
of
the
update
and
limits
it
to
the
part
of
the
cluster.
The
strategy
is
something
you
can
forget
about
for
now,
as
there
is
only
a
single
option
available
at
the
moment.
Now,
let's
commit
these
files
to
git
and
see
what
happens.
B
B
B
B
B
B
As
you
can
see,
the
customized
controller
has
processed
the
git
commit
by
now
and
applied
the
change
made
by
the
image
automation,
controller
onto
the
cluster
and
body
info
is
now
happily
running
version
5.2.1.
Congratulations.
You
have
witnessed
image,
update
automation,
driven
by
flux.
Now
before
I
call
this
the
end
of
the
demo,
I
want
to
highlight
the
existence
of
two
dog
pages
that
will
probably
help
you
further
shape
a
mental
model
of
how
image
automation
works
with
flux.
B
B
Second,
if
you
create
an
image,
automation
object
that
pushes
to
another
branch
that
it
reads
from
you
can
create
a
gated
automation
approach
which
will
force
the
updates
through
a
pull
request.
The
page
shown
explains
how
to
do
this
for
getup,
but
the
same
technique
can
be
used
with
many
other
git
providers.