►
From YouTube: Flux is Incubating + The Road Ahead
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
friends,
stefan
and
I
are
here
to
talk
about
flux,
becoming
an
incubating
project
and
to
give
you
a
little
bit
of
a
view
of
the
road
ahead.
Super
excited
here
to
be
joining.
Stefan.
A
Yeah
me
as
well
lee
kapili
also
on
the
developer
experience
team
at
weave.
Stefan
and
I
have
been
in
the
cloud
native
space
for
a
while.
If
you
contribute
in
the
kubernetes
community,
you
may
have
noticed
me
over
there.
I
used
to
work
on
kubernetes
quite
a
bit
and
now
we're
doing
cluster
add-ons
and
interested
in
some
other
kinds
of
deployment.
Artifacts
for
flux,
also
really
interested
in
security
and
multi-tenancy.
A
I
maintain
a
project
called
ignite,
which
does
micro
vms
in
a
docker-like
way.
So
both
stefan
and
I
really
like
helping
people,
which
is
why
flux
is
a
great
project
for
us
flux
is
super
awesome
and
I'd
like
to
tell
you
a
little
bit
more
about
why
we
think
so
it's
one
of
the
most
mature
technologies
right
now,
that's
developing
in
the
cloud
native
space.
Here
you
can
see
flux
along
with
a
bunch
of
other
amazing
projects
and
flux
alongside
helm,
as
reported
by
the
cncf
technology
radar.
Last
year,
mid-june
they
were
saying
hey.
A
These
are
some
things
that
you
should
really
be
looking
at.
Adopting
into
your
production,
workflows
and
many
users
have
chosen
to
be
on
that
journey.
With
us
in
the
project,
the
flux
community
has
done
so
much
to
really
learn
and
pioneer
what
it
means
to
do
get
offs.
You
can
see
we
have
a
diverse
set
of
users
and
users
who
operate
flux
and
do
get
offs
at
different
scales,
different
kind
of
formats
and
varieties
and
so
get
ops.
A
We
find
is
working
for
people,
whether
they
are
managing
their
own
services
or
offering
flux
as
part
of
their
product
and
as
the
flux
project
has
developed,
we've
come
to
start
to
formalize
a
little
bit
about
what
a
good
opinion
for
doing.
Get-Offs
can
be
there's
a
couple
of
principles
that
we
like
to
help
people
get
on
the
road
to
guiding
towards
good
social
and
technical
solutions
with
git
and
declarative
systems.
A
A
Your
system
declaratively:
this
is
a
good
prerequisite
that
you
need
to
be
able
to
meet
if
you're,
working
with
systems
that
have
imperative
apis
thinking
about
how
to
do
those
things.
Declaratively
can
help
you
on
the
road
to
get
ops.
Then
you
put
those
declarations
as
configuration
stored
in
source.
A
So
when
you
have
source
control
systems
like
git
or
subversion,
or
even
things
like
google
sheets,
which
can
be
a
versioned
and
declarative
store
for
information,
then
you
are
getting
to
that
second
tenant
and
then
using
software
agents
that
can
then
take
those
machine,
readable
configurations
and
reconcile
them
towards
your
infrastructure,
your
process
or
your
policies.
A
So
whatever
you
are
trying
to
manage
with
git
ops
to
either
ensure
correctness
or
alert
for
adrift
when
it
occurs,
is
kind
of
that
third
point:
you,
you
really
do
need
some
sort
of
constant
reconciliation
here,
it's
what
we
found
the
good
recommendation,
not
just
something.
That's
only
eventing,
although
events
can
be
a
powerful
part
of
the
good
ops
platform
and
help
you
integrate
with
other
systems
like
ci.
A
A
We
know
that
devs,
no
git
some
would
even
say
that
they
loved
it.
Other
people
may
not
right,
but
devs
all
have
adopted
git,
and
this
means
that
you
likely
have
a
solution
for
managing
git
already
in
your
organization.
So,
regardless
of
the
complexity
of
your
team,
you
have
some
of
that
organizational
complexity,
coded
into
how
you
store
and
version
your
code.
A
There's
no
version
control,
that's
meant
to
be
accessed
by
humans
inside
of
the
kubernetes
api
and,
in
the
same
way,
collaboration
on
comments
and
missing
fields,
and
things
like
that
why
things
were
done,
what
order
they
were
done?
Who
was
involved
in
making
decisions?
That's
not
kubernetes
responsibility,
but
it
can
be
the
responsibility
of
your
git
platform
and
that's
how
we
get
get
offs,
and
so
why
is
flux,
a
good
tool
set
and
what's
the
scope
of
the
project
we
talk
about
git,
ops?
A
Well,
we
talk
about
flux,
helping
you
provide
complete,
continuous
delivery
capabilities
on
top
of
kubernetes,
specifically
and
then
supporting
kubernetes
best
practices
by
tying
in
the
best-in-class
cloud-native
tools
that
are
emerging
things
like
customize,
helm,
metrics
with
prometheus
and
so
on,
and
we've
broken
up
that
architecture
to
be
kubernetes
native
and
to
be
very
extensible
open,
community
friendly-
and
I
mentioned
that
we
have
such
a
large
flux
user
base
already
and
that
points
to
really
a
multi-year
journey
as
we've
come
to
learn
and
make
git
ups
more
mature.
A
We've
also
learned
that
we
need
to
make
the
software
more
mature
and
so
for
the
past,
the
better
part
of
a
year
now
the
maintenance
team
that
has
been
involved
with
flux
has
grown
and
we're
working
on
flux
too.
A
The
main
kind
of
difference
that
we
want
to
point
out
is
that
flux1
was
really
built
as
a
targeted
but
monolithic
piece
of
software
that
was
responsible
for
syncing,
a
single
git
repository
and
also
applying
it
to
a
local
cluster.
And
then
there
was
this
image.
Automation
feature
that
people
grew
to
really
use
and
love.
A
A
So,
if
you
need
to
implement
git
ups
to
meet
your
particular
organization's
needs,
we've
split
up
the
apis
so
that
you
can
do
exactly
what
you
want
and
we've
accomplished
the
reconciliation
of
those
get
ops
configurations
or
git
ops
related
configurations.
I
should
say
how
you
actually
assemble
your
platform
with
kubernetes
native
apis
and
microservices
rewritten
from
scratch,
so
that
it's
possible
now
to
sync
multiple
git
repositories,
apply
them
at
different
times.
You
can
get
this
really
rich
feature
set.
A
A
I
want
to
talk
about
what
makes
flex
2
so
awesome,
all
right,
so
flux,
one
really
great
first
step
and
if
you're
using
flux
one
I
just
want
to
help
you
understand
what
is
getting
better
and
what
you're
getting
out
of
flux
too
things
that
have
traditionally
been
challenging.
We've
really
thought
about
them,
and
the
project
is
moving
in
a
super,
exciting
direction.
A
Flux
gives
you
flexible
tools
to
implement,
get
ups
for
your
team's
specific
needs
right.
So
if
you
want
to
do
declarative
helm,
then
you
can
take
those
imperative,
like
local,
laptop
workflows,
where
you're
iterating
on
a
cluster
and
modifying
it.
You
can
move
that
into
some
place
where
it's
possible
to
collaborate
with
gitops
flux.
Lets
you
do
declarative
helm.
A
If
you
want
to
represent
each
piece
of
your
infrastructure's
configuration
as
separate
bits,
separate
packages,
components
or
folders,
you
can
then
configure
health
checks.
You
can
create
dependent
ordering
between
those
components
through
the
use
of
a
dag,
a
directed
a
cyclical
graph.
You
can
create
a
dependency
tree
if
you
would
like,
and
that
creates
a
super
awesome.
Bootstrap
story
that
we've
also
done
extra
work
to
help
with
external
platform
creation
like
github
and
get
lab
and
pocket
et
cetera.
A
This
is
an
amazing
feature
set
and
something
that
brings
organizations
a
lot
of
success
and
peace
with
regard
to
disaster
recovery
scaling
out
new
deployments
for
new
customers
or
whatever
it
may
be.
These
are
some
of
the
immediate
benefits
that
you
get
from
doing.
Git,
ops
in
declarative
way
and
flux
can
now
do
dependencies
as
part
of
that
flux
can
do
very
sophisticated
actuations
of
continuous
delivery.
A
If
you
want
your
get
repo
to
only
release
config,
when
you
make
a
tag
that
is
a
semver
patch
bump,
you
can
tell
flux
to
do
that.
The
same
thing
is
true:
if
you
are
holding
home,
helm,
charts
inside
of
a
home
repository,
and
we
also
support
storing
your
health
charts
directly
in
git
with
some
caveats,
and
so
lots
of
very
powerful
feature
sets
there
for
automating
the
mechanisms
that
are
needed
to
do
continuous
delivery
so
that
you
have
to
do
less
stuff
when
you're,
actually
just
trying
to
release
software.
A
Along
with
that,
we've
got
some
forming
apis
and
controller
mechanisms
for
doing
image.
Tag
updates
that
compose
really
well
with
these
tagging
strategies,
and
so
lots
of
mechanisms
available
for
you
in
flux
to
do
awesome
get
offs.
The
way
that
you
need
to
something
that
I'm
particularly
excited
about
is
our
ability
to
compose
multiple
repositories:
folders
branches,
refs-
everything,
whatever
you
could
imagine
like.
Oh,
I
want
to
store
my
configuration
in
that
place,
or
this
way
or
in
a
bucket,
it's
possible
to
do
with
flux.
A
This
also
gives
us
really
nice
synergy
with
our
multi-tenancy
story,
so
each
one
of
these
pieces
that
you
would
want
to
reconcile
to
a
cluster
for
a
particular
tagging
policy
or
whatever
you
need.
You
can
also,
then
restrict
it
via
our
back.
Their
support
for
service
accounts,
which
also
leads
into
our
support
for
coop
configs,
it's
possible
to
for
any
of
the
artifacts
that
you're
synchronizing
to
your
cluster
using
flux.
A
Apis
also
mention
that
you
want
it
to
be
synced
to
a
remote
cluster
which
gives
you
the
ability
to
do
central
management,
fleets
or
central
cluster
multi-cluster
management
from
a
specific
management
cluster
or
all
kinds
of
fun
things.
So
you
could
even
use
this
in
a
b2b
relationship
where
you're
offering
a
service
right.
You
could
use
a
management
cluster
to
remotely
apply
stuff
from
your
githups
control
repo
into
a
customer's
cluster.
A
Lastly,
because
we
built
everything
with
cloud
native
tools
in
mind
and
in
a
kubernetes
native
way,
flux
is
way
more
observable
than
ever,
and
so
previously
in
flux.
One
we
would
frequently
have
issues
where
folks
were
struggling
to
read
the
log
messages
or
understand
why
syncs
were
not
occurring
and
because
things
have
now
been
broken
out
into
their
individual
pieces
and
they're
represented
declaratively
in
your
git
repository
subsequently,
in
the
kubernetes
api
you
can
tell
if
something
is
failing
to
fetch
on
the
git
repository
object.
A
A
Additionally,
our
notification
controller
is
super
generic
and
very
powerful.
Just
across
the
board.
Flux
is
built
in
a
way.
It's
factored
so
that
the
individual
pieces,
you
can
control
them
and
you
can
also
extend
them,
which
is
an
expectation
that
I
think
we
should
hold
a
high
bar
for
in
the
cloud
native
ecosystem.
That
flux
gladly
needs.
A
We've
seen
more
of
this
maturity
occurring
as
we've
come
to
constrain
and
expand
github's
the
definition
of
what
it
is
and
to
to
really
make
it
more
mature
with
things
like
get
off
stays,
if
you
even
just
look
at
the
statistics
with
the
project,
we're
at
40
000
contributions
and
counting
26
000
of
those
have
been
since
sandbox,
and
so
just
from
sandbox
to
today,
which
is
incubation
lots
of
activity.
A
16
000
plus
commits
we
have
14
maintainers
now
from
five
different
companies,
and
there
were
six
maintainers
and
three
companies
at
sandbox
type,
so
really
points
to
sustainable
growth
in
the
leadership
and
maintenance
of
the
project.
We
are
building
something
that
is
sustainable
and
a
true
community
effort
here.
12,
000
plus
github
stars
definitely
lots
of
growth
there
and
it's
just
clear
when
you
get
involved
with
community
that
we're
building
something
super
healthy
people
helping
each
other
and
lots
of
love
as
well
as
an
excellent
code
of
conduct.
A
So
if
you're
looking
to
get
started
with
flux,
say
you're
new
here
and
you're
just
learning
about
it,
our
website
has
a
great
path
for
you.
So
go
ahead
and
check
out
our
getting
started
guides.
Also,
we've
done
our
best
to
really
transparently
show
throughout
the
flux
to
development,
progress
or
process.
What
these
new
features
look
like
how
they're
supposed
to
be
used.
We've.
A
We
have
a
call
every
other
monday
that
you
can
join
check
out
the
meetup
page
and
the
recordings
there
get
posted
to
a
youtube
playlist,
where
you
can
see
very
often
me,
but
also
other
flex.
Community
members
either
fail
through
a
demo
or
do
something
really
fun
and
cool.
Also
just
call
out
to
victor
farsight,
who
did
a
great
dive
into
and
demo
of
how
flux
2
is
working,
go
ahead
and
check
out
the
youtube
videos.
A
Again,
you
can
get
there
by
just
going
to
flex
cdio
or
at
these
links
below
so
flux2
community.
I
I
can't
stress
this
enough.
I
mean
I'm
so
excited
about
what
we're
doing
with
flux,
to
produce
flexible,
tooling,
that
lets
you
do
things
the
way
that
you
need
to
to
accomplish
or
to
build
the
proper,
get
ops
approach
for
your
org,
which
includes
thinking
about
not
just
technical
solutions,
but
also
social
ones
and
flux.
Two
is
going
in
a
really
good
direction.
A
B
B
A
B
The
developer
teams
get
more
velocity
and
they
also
do
engineering
work.
They
can
extend
flux
in
in
ways
that
we
haven't
figured
out
yet
or
they
can
trim
it
down
and
use
only
those
components
that
they
they
need
in
their
workflows
and
finally,
app
developers.
Of
course
they
rely
on
continuous
delivery
to
get
their
code
on
production
systems,
but
it's
not
only
about
production
system
is
the
journey
of
you
know.
You
commit
something
to
your
source
code,
how
it
goes
through
different
stages:
ci,
cd
environments,
promotions.
B
You
know
feedback
of
what's
going
on
with
your
app
before
it
reaches
its
final
state
in
a
in
a
production
cluster,
so
I'll
I'll
try
to
to
explain
flux
from
from
these
three
perspectives,
let's
start
with
cluster
operators.
B
So
what
what
the
cluster
operator
have
has
to
do?
It
has
to
develop
work
on
a
cluster
definition.
First
right,
it
can
be,
let's
say:
nikkes
cattle
config,
where
you
set
up
your
iron
rolls
your
vpcs,
your
node
groups
and
so
on.
It
can
be
a
terraform
project
where
you
use
some
cloud
provider
or
you
target
your
on-prem
clusters
or
even
bare
metal
systems.
B
B
Step
two
is
what
you
want
to
provide
with
within
that
cluster
right,
the
cluster
add-ons,
what
cni
you
are
going
to
use?
What
ingress
controller?
Are
you
going
to
use
a
service
mesh
and
so
on?
So
there
is
a
lot
of
you
know
different.
There
are
so
many
differences
between
how
clusters
get
composed.
You
you
it's
hard
to
find
two
clusters
alike.
Like
everybody,
there
are
so
many
add-ons
out
there.
B
If
you
look
at
the
kubernetes
cluster
is
always
something
new,
maybe
run
some
add-on
that
you
never
heard
about,
because
there
are
so
many
add-ons
out
there
right
and
and
third,
as
a
cluster
operator,
you
want
to
onboard
tenants
now
what
is
a
tenant?
A
tenant
can
be
a
dev
team
or
a
tenant
can
be
a
whole
organization.
If
you
provide
this
as
a
service
to
others
and
so
on.
The
idea
of
a
tenant
is
when
that
you
have
to
you,
know,
isolate
and
put
some
boundaries
around
what
the
tenant
can
do
to
your
infrastructure.
B
Can
a
tenant
delete
nodes
can
at
an
end,
you
know,
wipe
out
your
ingress
controllers
and
so
on.
Maybe
not
so.
You
have
to
set
some
boundaries
for
for
these
tenants
and,
lastly,
you
have
to
maintain
these
clusters.
You
have
to
upgrade
them
cvs,
kubernetes
on
a
fast
track.
Even
now
is
not
that
fast,
but
it
used
to
be
very
fast,
so
you
have
to
keep
up
with
with
the
latest
version
and
not
only
of
the
cluster,
but
also
of
the
add-ons
and
so
on.
B
One
way
to
do
it
is
you
store
everything
in
a
single
ripple
and
you
call
that
your
infrastructure
or
fleet
management
repo,
where
you
can
put
together
all
these
definitions,
be
terraform,
be
it
some
config,
that's
one
consideration,
but
once
you
have
the
the
cluster
up
and
running
all
the
add-ons
and
all
the
tenants
they
can
be,
they
can
subscribe
to
the
same
github's
principle
as
delivering
apps.
The
main
difference
between
delivering
apps
and
delivering
cluster
add-ons
is
the
fact
that
you
don't
control
the
ci
system.
B
Don't
control
the
build
system
of
the
cluster
item.
You
are
a
consumer
of
it.
You
are
also
in
most
times
of
consumer,
of
the
configuration
of
the
add-on.
You
may
be
using
some
helm
chart
to
install
let's
say
an
ingress
controller.
You
will
not
be
developing
that
from
scratch.
You
want
to
reuse,
what's
already
there
and
may
and
then
make
some
small
changes
to
it.
B
So
you'll
be
changing
things
in
your
infrastructure,
git
ripple.
Then
there
is
some
continuous
delivery
system.
That
applies
those
changes
to
your
fleet
of
clusters.
Right,
that's
the
gitobs
principle.
I'm
calling
these
different
clusters
environments.
You
can
have
a
dev
environment,
staging
environment
and
so
on
so
you'll
have
we
call
them
overlays
like
in
customized
overlays,
where
you
take
an
add-on
and
you
do
small
modifications
over
it
depending
on
which
environment
it
needs
to
end
up
on
and
so
on.
B
For
example,
maybe
you
want
to
have
a
database
with
ephemeral
storage
for
your
for
your
dev
cluster,
but
on
your
production
cluster,
you
want
to
change
the
how
how
the
storage
is
managed
and
switch
to.
I
don't
know
pvc
state
for
sets
and
so
on.
So
there
are
challenges
in
making
these
overlays
and
feed
them
into
your
into
your
environments.
B
B
The
idea
is,
you,
tell
flux,
hey.
I
want
to
create
a
repository
on
my
git
provider,
where
I
will
like
to
store
all
the
infrastructure
items
for
not
only
one
cluster
for
my
whole
fleet
of
clusters,
so
you
run
this
flux,
bootstrap
command,
you
give
it
your
organization,
name
your
toy
story
name
and
you
you
tell
flux
which
cluster
to
target
right
flux
will
use
the
cattle
cube
config.
B
So
whatever
you
have
there
in
your
the
default,
the
flux
bootstrap
will
address
that
now,
maybe
our
git
provider
implementations
are
not
enough
for
you.
So
that's
why
we
also
reused
much
of
the
flux,
bootstrap
code
and
created
a
flux
platform
provider,
so
you
can
use
our
terraform
provider
and
target
your
own
git
hosts
your
own
clusters
and
so
on.
So
there
are
here
are
two
ways
of
you
know:
setting
up
flux
on
your
cluster
configure,
deploy
keys
so
that
flux
has
access
to
your
your
repo.
B
You
can
also
specify
teams
access
to
that
particular
ripple
and
flux.
Bootstrap
is
also
the
way
to
upgrade
flux
on
clusters.
It's
either
important.
You
can
run
it
no
matter
how
many
times
you
want.
If
something
is
new,
if
you
specify
a
new
version
or
you
are
using
the
embedded
version
in
the
flex
client,
it
will
detect.
Oh,
I
need
now
to
upgrade
and
what
it
will
do.
It
will
coming
back
to
your
git,
repo
and
flux
will
update
itself
so
flux
version.
2
is
managing
itself
through
git.
B
Let's
see
how
this
looks
so
you
have
the
fleet
repo
there.
You
store
all
your
definitions
and
an
overlay
for
for
each
cluster.
Then
all
these
flux
controllers
are
running
on
each
cluster
and
they
will
pull
changes
from
from
the
free
triple
any
change
to
an
infrastructure
item.
Or
let's
say
you
add
the
tenant
or
you
change
the
you
know
the
access
policy
of
a
particular
app
you
change
some
airbag
and
so
on.
Flux
will
detect
that
change
and
will
apply
it
on
one
cluster
or
on
many
clusters.
B
Terms
of
cluster
management
version,
2
comes
with
many
features.
One
important
feature
that
we
we've
built
into
version.
2
is
dependency
management
for
infrastructure
and
apps,
and
I
will
I
will
give
you
an
example
of
what
that
means.
Let's
say
you
have
you
want
to
install
a
controller
that
comes
with
its
own
custom
resource
definition?
Let's
say
you
want
to
provision
certificates
from
let's
encrypt
dynamically
for
your
apps.
B
Maybe
you
refer
to
the
upstream
helm,
chart
for
set
manager,
and
you
want
to
install
server
manager
from
that
chart.
Maybe
you
want
to
get
the
cell
manager
custom
resource
definitions
from
their
github
repository
release.
Page
flux
allows
you
to
combine
things
like
plain
yamls
that
come
from
urls
with
other
yamas
that
come
from
git,
repos
and
other
configurations
that
come
from
helm
repository,
so
you
can
bundle
them
together
and
create
an
a
definition
that
reconciles
set
manager
on
your
cluster
and
keeps
it
up
to
date.
B
Why
we
we
did
that
because
we
want
to
make
sure
that
every
commit
that
you
do.
Every
change
of
your
infrastructure
is
applied
as
a
transaction
on
your
kubernetes
cluster.
So
if
you
change,
let's
say:
10
manifests,
one
change
is
not
acceptable.
Maybe
you
have
something
that
I
don't
know
something
like
a
gatekeeper
will
reject,
or
maybe
even
the
kubernetes
api
reject.
There
is
a
typo
there.
Instead
of
I
don't
know,
type
load
balancer
you
mistype
stuff,
like
that
the
kubernetes
api
rejected.
B
B
Then
I'll
also
declare
here
health
check
which
looks
at
cert
manager,
deployment
and
I'm
saying
hey.
I
want
to
install
set
manager,
it's
custom
resource
definitions,
I
want
to
make
sure
set
manager
is
up
and
running
and
only
then
apply
the
certificates
manifests,
and
this
applies
to
many
things,
not
only
self
manager.
B
Maybe
you
want
to
enforce
policies
right
at
the
cluster
bootstrap.
So
maybe
you
want
to
say
I
want
kiverno
or
opa
gatekeeper
to
be
the
first
thing
that
gets
deployed
on
my
cluster
and
only
then
apply
other
configuration
that
I
don't
have
control
over.
Maybe
those
other
configurations
are
coming
from
repositories
that
are
managed
by
your
dev
teams
or
by
your
clients,
and
so
on.
B
You
want
to
apply
the
policy
right
at
bootstrap,
so
this
is
how
you
you
can
do
it
by
by
building
a
dependency
graph
out
of
your
infrastructure
and
apps,
and
you
can
you
can
define
dependencies
between
helm
releases
between
plane,
ammos
and
other
customizations
between
customized,
overlays
and
so
on.
That
depends
on
graph
takes
into
account
all
all
the
flux
things
so
to
say.
B
So
let's
say
you
have
a
health
chart
and
you
don't
have
control
over
what's
in
that
hand
chart,
but
you
know
for
sure
that
that
particular
app
shouldn't
shouldn't
create,
for
example,
when,
when
it
gets
installed,
shouldn't
create
an
ingress
definition
or
it
shouldn't
create
the
cluster
role
binding.
It
shouldn't
make
itself
cluster
admin
and
so
on.
How
can
you
prevent
that?
B
You
can
prevent
it
by
telling
flux
hey
when
you
install
this
particular
app
use
this
service
account,
and
for
that
service
account
you
can
set
up
restrictions
using
a
roll
binding,
for
example,
and
you
can
say
from
this
repository
or
from
this
hem
chart.
All
the
things
that
are
applied
on
the
cluster
cannot
modify
anything
else,
but
objects
inside
that
particular
namespace
right.
So
we
have
namespace
encapsulation,
but
it's
not
only
about
namespaces
one
app
can,
you
know,
reflect
itself
inside
the
cluster
in
multiple
link
spaces
right.
B
Maybe
an
app
is
composed
of
microservices
and
you
have
a
database
namespace
and
a
front-end,
namespace
and
so
on.
B
What
you
can
do
is
create
a
cluster
role
binding
for
that
particular
service
account
and
grant
that
service
account
access.
Only
to
those
namespaces,
so
it's
it's
not
only
about
one
app
one
namespace
is
about
what
that
app
needs
to
do
inside
the
cluster
you'll
allow
it
to
do
it,
but
only
that
thing
nothing
more.
So
this
is
how
I
call
it
soft
multi-tenancy
that
kubernetes
offers
through
namespaces
and
and
arbut,
but
that
doesn't
mean
that
you
know
is
the
right
way
for
everybody
in
in
many
cases
you
may
want
hard
multi-tenancy.
B
B
Other
things
with
we
have
in
flux.
We
have
integrated
with
mozilla
soaps.
If
you
haven't
heard
of
it
is
mozilla
subs
is
a
tool,
is
a
cli
that
lets
you
encrypt
fields
inside
that
file,
so
you
can
safely
place
a
kubernetes
secret,
manifest
in
a
public,
git
repo
and
no
one
will
be
able
to
see.
What's
in
there,
the
manifest
will
be
encrypted
and
only
flux
or
the
cluster,
where
flux
runs.
Only
there
is
the
private
key
and
you
don't
need
to
run
a
yet
another
controller
flux.
Does
that
by
default?
B
You
just
tell
flux,
say:
use
this
pgp
key
to
decrypt
the
secrets
in
my
git
ripple
or
connect
to
this
cloud.
Kms
implementation
beat
aws,
azure,
vault,
google,
kms
and
so
on,
sops
integrates
with
so
many
backends,
even
hash,
corp
vault.
I
think,
and
flux
will
use
these
mozilla
stops
as
a
library
and
can
connect
all
these
providers
pull
the
the
private
key
from
there
decrypt
the
secret
before
it
applies
it
on
the
cluster
right.
B
B
We
also
use
you,
you
can
also
use
gpg
to
authenticate.
Not
authenticate
to.
You
know
verify
that
the
person
that
made
the
particular
change
in
in
the
cl
in
the
git
repo
is
allowed
to
do
that
and
and
the
way
to
to
enforce
this
kind
of
authentic.
This
kind
of
validation
is
by
making
your
teams
use
gpg
to
sign
commits.
Then
you
collect
the
the
public
keys
from
all
the
team
members
that
are
approved
to
make
a
change.
Let's
say
on
your
production
cluster
and
you
tell
flux
hey.
B
Only
these
people
are
allowed
to
make
changes.
So
let's
say
someone
hacks
your
your
github
account
you
to
have
access
to
the
repository
everything
in
there.
It
can
change
something
and
that
something
will
be
deployed
on
production.
B
That
change
will
not
be
applied
on
the
cluster,
because
flux
will
verify
the
signature
it
will
not
match
or
it
will
have
no
signature
to
reject
any
change
to
the
cluster
from
that
moment
on
and
what
flux
will
do
will
send
an
alert,
kubernetes
event
and
you
can
configure
alerting,
through
slack
to
other.
B
B
Going
next
we
already
mentioned
flux,
observability
features.
We
expose
now
things
as
a
custom
resource
in
the
custom
resource
substatus
resource.
So
what
what
that
means
is
that
you
can
do
cattle
get
cuddle,
describe
and
see
if
something
goes
wrong
when
or
when
did
the
flux
last
apply
the
commit?
What
gitsha
is
is
applied
on
the
cluster
and
so
on?
B
We
we
also
allow
you
to
create
health
checks
for
workloads
and
also
custom
resources.
For
example,
you
could
create
a
check,
for
I
don't
know,
open,
fast
function
or
something
like
that.
That's
not
native
kubernetes,
but
if
it
has
a
ready
condition
or
or
something
that's
compatible
with
k
status,
we'll
be
able
to
look
at
it,
and
you
know
give
you
the
end,
result
and
flux
when
you,
when
you
define
a
health
check,
what
flux
does?
Is
it
waits
for
that
health
check
to
resolve?
B
B
We
also
issue
kubernetes
events
for
everything
that's
happening.
So
if
you
have
a,
if
you
have
a
tool
that
you
know,
gets
the
kubernetes
events
and
stores
them
in
your
elastic
search
and
so
on,
you
can
build
your
own
notification
system
only
based
on
those
events.
We
also
also
the
flux
controllers
are
using
structured
logging
in
json
format.
So
if
you
use
a
cloud
for
storing
logs,
you
will
you
can
automatically
create
automatically,
you
can
easily
create
items
based
on
type
error
or
filter
by
custom
resources,
and
so
on.
B
We
also
ship
graphana
dashboards.
You
have
an
example
here,
where
everything
does
define
in
in
flux
exposes
promiscuous
metrics,
so
you
can
use,
let's
say
prometheus
alert
manager
to
build
your
alerting.
You
have
so
many
options
now
on
how
you
want
to
you
know,
look
into
what
flux
is
doing,
and
I
also
want
to
mention
the
commit
status
update
feature.
This
was
implemented
by
philip
one
of
the
flux
maintainers,
so
like
ci,
if
you,
if
you
go
to,
I
know,
github,
gitlab
and
so
on.
B
You'll
see
that
when
a
ci
job
runs
the
result
of
that
job
is
posted
back
on
your
commit
in
git,
and
you
can
see
if
that
commit
has
been
successfully
built
or
it
failed
now.
In
the
same
way,
flux
can
reflect
what's
happening
with
your
your
changes
inside
the
cluster.
If
you
configure
flux
to
write
back
to
github
commit
status,
you
should
create
a
token
that
allows
fox
only
to
do
that.
B
For
example,
if
a
health
check
fails
flux
right
back
to
your
to
your
git
on
that
commit,
and
it
will
tell
you
what
let's
say
what
deployment
is
failing
or
if
the
validation
fails
and
so
on.
So
if
you
want
instant
feedback
in
your,
you
know,
git
platform,
without
going
to
slack
or
discord
or
other
platforms,
you
can
have
that
status
posted
right
there
and
it
works
with
also
with
asia.
Devos
bitbucket
and
we
are
working
on
on
expanding
this
commit
status,
feature
to
other
platforms.
B
Okay:
let's
talk
about
platform
engineers,
so
you're
a
platform
engineer,
and
you
want
to
build
something
that
you
know
flux
doesn't
do
you
can
you
can
use
our
toolkit
so
in
order
to
develop
flux
version
2,
we
first
built
it's
like
an
sdk.
If
you
think
about
it
and
we
call
it,
the
github
store
kit
and
github's
toolkit
is
composed
out
of
apis,
which
are
represented
as
kubernetes
custom,
resource
definitions,
controllers
and
golang
packages.
B
So
all
these
things
together,
if
you
put
them
together,
you
can
build
cd
pipelines,
but
maybe
you
don't
want
to
build
continuous
delivery
things.
Maybe
you
want
to
build
continuous
integration
things,
and
maybe
you
want
to
use
some
components
from
from
flux
to
achieve
that,
but
flux
will
not
build
your
source
code
or
not
do
anything
with
it,
but
you
can
use
the
tokyo,
then
build
your
own
controllers
and
extend
it
in
that
way.
B
If
that's
what
you
are
looking
for
at
the
core
of
the
github's
toolkit
is
a
controller
and
an
api
called
source
controller.
What
source
controller
does
is
it
can
pull
artifacts
from
external
sources
like
git
repos
like
s3
buckets
menio,
any
kind
of
s3
compatible
storage
will
work,
also
helm
repositories
and
so
on,
and
you
can
build
your
own
consumer
that
reacts
to
source
changes.
B
Let's
say
you
do
a
git
commit
source
controller
will
pull
that
commit
inside
the
cluster,
then
we'll?
Let
your
consumer
know
hey.
There
is
a
new
version.
You
want
to
do
something
with
it
and
your
consumer
can
take
that
new
version
and
act
on
it
so
based
on
this
workflow,
this
is
how
we've
built
flux
version
2
and
we've
we've
developed
specialized
reconcilers
that
are
using
the
the
source
apis
and
the
artifacts.
B
We
have
a
helm
controller
that
is
specialized
for
helm
operations.
It
knows
how
to
install
a
helm
chart
how
to
upgrade
it,
how
to
run
tests
for
it.
It
knows
how
to
roll
back
that
particular
version
if
the
test
failed
and
so
on,
and
we
also
have
controllers
that
are
built
for
automation,
like
the
image
reflector
controller
and
the
image
automation
controller
I'll
talk
about
that
in
a
bit.
B
If
you
want
to
get
started
with
the
with
the
github
circuit
and
write
your
own
controller,
we
have
a
guide
published
on
our
docs,
where
you
can
create
a
source
watcher.
So
it's
a
controller
built
with
cube
builder
and
controller
runtime
that
collaborates
with
source
controller
detects
that
something
has
changed
and
pulls
the
artifact
from
source
control
and
from
there
you
can
take
decisions
on
your
own.
B
What
you
want
to
do
with
those
changes
yeah,
so
please
check
out
source
watcher
if
you,
if
you
are
into
you,
know,
building
your
own
pipelines,
okay,
we
finally
got
to
app
developers
as
as
our
use
case,
so
as
an
app
developer.
If
you
want
to
do
if
you
want
to
deliver
your
app
on
some
cluster
you'll
have
to
take
several
steps.
B
B
B
Now,
if
we
add
automation
to
this,
workflow
ci
can
can
help
you
get
to
an
immutable
artifact,
a
container
image
that
you
push
to
your
registry
and
you
never
change,
and
you
can
do
that
by
using
your
git
shot
and
the
timestamp
or
december,
or
something
that
you
is
unique.
B
You
have
to
tag
your
image
with
something
that
is
unique
and
the
important
part
is
you'll,
never
override
that
image
tag.
That's
the
only
way
to
have
a
consistent
versioning
of
your
of
your
system.
Now
the
continuous
delivery
part
will
deal
with
something
change.
The
deployment
manifests.
Okay,
I
have
to
deploy
on
one
cluster
many
clusters,
depending
on
the
environments.
B
Now,
who
does
the
update
in
the
deployment
manifest
itself?
You
can
have
your
ci
system
right
to
the
the
git
repo,
where
the
manifests
are.
Maybe
the
git
repo
is
the
same
as
the
source
code,
but
that
means
see,
I
have
to
you,
know
deal
with
yaml.
We
have
to
do
replace
on
that,
and
so
on
flux
comes
with
its
own
automation
solution
for
that.
B
Let's
see
so
we
have
two
controllers
that
are
collaborating
on
on
this
feature.
One
controller
is
called
image,
reflector
controller,
and
what
this
controller
does
it
scans
container
registries,
based
on
a
policy
that
you
have
defined
and
based
on
a
image
repository
configuration
where
you,
for
example,
specify
how
the
reflector
should
authenticate
to
connect
to
that
repository
and
inside
the
policy
you
specify
which
tags
should
be
taken
into
account
and
how
flux
should
order
them?
B
For
example,
you
could
use
symbol,
ranges
and
determine
the
latest
version
based
on
assembler
expression,
or
you
can
use
regex
and
ordering
by
timestamps
or
using
a
numbering
order.
Let's
say
you,
you
have
an
incremental
build
id
and
you
can
add
that
to
your
tags
and
you
can
tell
flux
to
order
them
by
by
the
bill
id
to
determine.
What's
the
latest
version
that
you
want
to
define,
and
finally,
you
configure
flux
to
write
back
that
change
to
the
git
repo
and
that's
the
image,
automation
controller.
B
B
It
replace
that
that
tag
in
your
yaml
file,
then
it
commits
the
yaml
file
back
to
the
ripple
right
when
that
happens,
source
controller
will
detect.
Oh,
there
is
a
new
change
in
the
cluster
configurable
on
your
fleet
management
report,
and
it
will
do
what
it's
supposed
to
do.
It
will
pull
the
change,
then
helm
or
customize
control
or
whatever
reconciler.
You
have
will
apply
that
new
image
on
your
cluster.
B
So
how
flux
does
image?
Automation
is
not
by
changing
the
cluster
state
directly
is
by
always
reflecting
changes
from
other
systems
inside
your
git
repo,
and
what
that
means
is
that
you
can
see
a
commit
made
by
flux.
You
can
you
know
during
an
incident,
you
can
pause
the
image,
update,
automation,
you
can
roll
back
that
commit.
You
can
go
there
and
disable.
Maybe
the
automation,
for
I
don't
know
the
weekend
and
so
on.
Maybe
you
don't
want
you
don't
want
to
deploy
on
fridays
right,
so
you
can.
B
You
can
disable
only
that
object,
which
is
the
image
update,
automation
that
doesn't
mean
your
cluster
state
is
not
correcting
drift
sense
on
what
you
are
doing.
You
are
just
pausing,
a
certain
automation
in
your
continuous
delivery
system
and
we've
we've
added
futures
for
you
to
feel
comfortable
during
an
incident
to
not
fight
flux,
so
in
in
version
one
you
had
to
scale
flux
to
zero,
because
if
you
want
to
edit
something
then
flux
will
override
it
and
so
on.
B
In
version
two,
we
allow
you
to
suspend
for
a
for
a
time
interval
a
particular
reconciliation.
So
let's
say
you
have
you
have
an
incident
for
a
particular
app
and
that
app
comes
from
helm
release
instead
of
disabling
everything
you
can
just
say.
I
want
to
suspend
the
reconciliation
of
that
helm.
Release
from
this
moment
on
doesn't
matter
what
changes
I
don't
want
the
hand
release
to
be
upgraded.
I
want
to
go
there
use,
I
don't
know,
helm
cli
and
do
my
own
thing
to
fix
the
issue.
B
Then,
after
you
determine
what
needs
to
be
fixed,
those
changes
should
end
up
in
it
as
a
fix
right
after
you
committed
the
the
fixing
git,
then
you
can
resume
flux,
operations
and
flux
will
pull.
The
latest
version.
Maybe
is
the
same
stuff
with
what
you
already
did
on
the
cluster
and
nothing
will
change,
but
the
idea
is
that
now
you
have
fine
grain
control
of
what's
happening
and
when
is
happening
inside
your
cluster,
it's
not
the
do
it
all
thing
like
I'm,
reconciling
everything
or
nothing.
B
So
that's
those
are
some
good
steps
we
made
in
in
in
that
direction.
You
want
to
mention
something
new
here
about
updates
automation,.
A
Yeah
this
is
this
is
a
cool
thing
to
point
out.
I
oh,
can
you
you
can't
hear
me.
No,
I
can't
yeah
cool
yeah.
This
is
a
cool
thing
to
point
out.
Is
that
image
update
automations
because
we've
built
flux
in
such
a
composable
way,
and
there
are
these
other
powerful,
continuous
delivery
features.
A
A
You
can
get
those
changes
into
your
repository,
but
that
doesn't
necessarily
need
to
release
at
that
point
to
every
environment
that
you
have
right
and
so
because
you
can
still
keep
manual,
control
or
use
other
systems
to
decide
when
a
stage
tag
gets
applied
to
that
commit
that
flux
made
to
your
repo
right
or
when
the
production
tag
gets
promoted
to
that
point
in
the
repo-
and
I
think
that
that's
really
cool
the
other
point
is
that
the
way
that
we've
done
image
updates
composes
super
well
with
more
mature,
manifest
workflows.
A
So
I'm
really
excited
about
how
that
comment.
Annotation
on
any
structured
file
in
the
repo
can
function
with
manifest
generation
style
use
cases
like
from
flux1,
where
you
can
now
get
those
image,
automation
updates
into
some
config
that
then
produces
your
manifests
without
being
worried
about
it
having
to
be
coupled
to
the
specific
type
of
deployment
resource.
You
have
so
just
like
way
more
flexible
way
of
designing
it
right
right,
composes
super
well.
B
Yeah
right
good
point:
we
in
in
the
past
flux
version,
one
was
only
capable
of
patching
image
tags
inside
the
native
kubernetes
workload,
definitions
that
means
deployment,
stateful,
set
demon,
set
and
cron
job,
but
now,
in
version
2,
and
because
we
use
the
kml
library,
we
are
able
to
patch
any
kind
of
kubernetes
custom
resource.
We
don't
have
to
know
about
it
if
it's
a
custom
resource
if
it
subscribes
to
kubernetes
api.
We
based
on
on
the
marker
that
you've
had
there
we
are
able
to
patch
it.
B
Customization
configuration
we
can
patch
a
hand,
release
file.
We
can
patch
on
a
text
on
task
that
you
know,
builds
builds
your
images.
Maybe
you
want
to.
Let's
say
you
have
a
tecton
task
that
builds
with
go
right
so
and
you
want
to
always
build
using
the
latest
go
patch
version
where
cvs
are
shipped
right,
so
you
want
to
keep
your
api
system
up
to
date.
B
You
can
just
use
these
two
controllers
and
you
can
you
can
update
all
your
all
your
ci
pipelines,
so
they
will
be
using
the
the
the
latest
yeah.
A
It
doesn't
even
need
to
be
an
object
that
lives
in
kubernetes
that
you
update
the
image
tag
with
it
can
be
any
yaml
file
that
has
some
kubernetes
structure
like
the
customization
yaml
that
you
mentioned,
and
that
opens
the
door
for
like
communicating
your
image
updates
to
not
just
kubernetes
right,
but
systems
that
produce
kubernetes
manifests
or
other
things
that
would
want
to
know
about
your
image
updates,
like
a
ci
system
that
does
security,
vulnerability
scanning,
you
know
lots
of
cool
things.
You
could
do.
B
Yeah
and
one
one
last
thing
about
image:
automation.
What
we
are
currently
working
on
is
being
able
to
push
the
change
to
a
different
branch
and
how
this
works.
You
say
hey,
I
want
to
use
the
image
automation,
but
I
don't
want
it
to
commit
back
to
the
same
branch,
so
it
doesn't
get
deployed
automatically.
B
I
want
to
commit
it
to
a
new
branch,
then
maybe
I'm
using
a
github
action
or
a
gitlab
ci
helper
that
will
open
a
pull
request
with
all
the
changes
that
flux
has
determined
that
you
need
on
your
cluster,
so
someone
from
your
sra
team
can
review
it,
merge
it,
and
only
then
those
updates
will
be
applied
on
the
cluster
and
that's
that
that
will
be
released
in
the
in
the
next
in
the
next
couple
of
weeks.
B
Okay,
I'm
running
out
of
time,
I'm
going
to
escape
real
fast
here.
So
this
is
how
flux
version
2
looks
like
built
on
top
of
the
toolkit.
It's
in
a
way,
it's
a
continuous
loop
here
you
push
changes
manually,
ci
pushes
artifacts
flux,
pushes
patches
and
so
on,
and
everything
ends
up
as
an
event
back
to
you.
As
a
notification
and
so
on
and
of
course,
flux
now
can
you
know
control
more
than
one
cluster
and
reconcile
it
from
more
than
one
source.
B
If
you
have
questions,
if
you
have
proposals,
if
you
want
to
talk
to
us,
we
are
happy
users
of
github
discussions.
That's
where
all
the
api
changes,
all
the
proposals
are
going.
So,
of
course
you
can
reach
us
on
the
cncf
slack,
but
for
you
know,
future
requests
and
so
on.
Please
use
the
discussion
is
a
great
environment
to
debate
on
on
new
things,
and
that
was
it.
Thank
you
very
much.