►
From YouTube: Flux: Multi-tenancy Deep Dive - Philip Laine, Xenit
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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: Multi-tenancy Deep Dive - Philip Laine, Xenit
Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories) and automating updates to the configuration when there is new code to deploy. In this presentation, we will look at how Flux can be used in multi-tenant environments to simplify the day to day work of developers and Kubernetes cluster operators.
A
Hello
and
thank
you
for
joining
this
flex
deep
dive
session.
My
name
is
philip
lane
and
I
work
as
a
devops
engineer
at
senate.
We
are
a
swedish
based
company
who
builds
developer-centered
experiences
around
cloud
kubernetes
and
gitops.
I
am
also
part
of
the
flux,
maintainer
team,
and
that's
what
I'm
here
to
talk
to
you
about
today.
A
A
A
In
this
example,
here
it's
very
simple,
but
you
can
make
you
can
scale
this
out
to
run
across
multiple
teams
and
and
have
different
types
of
functionality
and
automation,
but
there
isn't
really
any
requirement
to
do
so.
So
that's
kind
of
the
beauty
of
flux
is
that
it
works
for
smaller
teams,
but
also
works
for
large
enterprises
at
the
same
time
quickly,
before
we
get
started,
I
just
want
to
go
through
a
quick
timeline
of
flux
and
flagger.
A
So
currently
flex
is
incubation
project.
It
has
14
containers
at
five
companies,
but
it
started
it's
been
around
for
a
while
now
so
in
2016
it
started
developing
at
weworks.
Since
then,
we've
had
the
fighter
project
showing
as
a
sub
project.
For
those
that
don't
know,
flagger
is
a
progressive
delivery
operator
that
works
really
well
with
flux.
A
A
I
was
kind
of
looking
around
looking
at
what
other
opera
like
cluster
are
considered
were
out
there,
and
I
stumbled
upon
a
blog
post
about
sony
building
a
raspberry
pi
based
kubernetes
cluster.
I
found
it
kind
of
interesting.
I
wanted
just
to
find
a
hobby
project,
so
I
started
building
one
of
my
own
somewhere
after
that.
A
So
as
flux
works
by
pulling
an
external
git
repository,
work
really
well
with
having
a
small
cluster
that
could
not
get
public
ips
moving
forward
to
around
well
now,
my
cluster
does
have
the
ability
to
get
public
ips,
but
it
still
runs
flux
because
flux
is
a
great
project
and
I
think
somewhere
along
along
the
line
there,
I
realized
how
what
a
novel
idea
flux
was.
So
I
started
getting
involved
in
the
project.
I
was
using
it
as
at
work
and
eventually
around
what
flux
v2
started.
A
A
Together,
antennas
can
raise,
they
can
rise
range
anywhere
in
size
between
a
couple
of
applications
to
50
plus
we
are
heavy
azure
users,
so,
as
you
can
see,
we
have
an
aks
cluster
and
a
couple
of
resource
groups,
so
each
tenant
is,
is
confined
by
default
to
their
own
namespace
within
the
kubernetes
cluster
and
it's
linked
together
to
an
azure
resource
group.
So
this
brings
the
challenge
of
how
to
expose
these
namespaces
or
tenants
to
our
end
developers
in
a
safe
and
secure
way,
which
has
a
reasonable
maintainability
in
the
long
run.
A
A
A
Any
any
changes
to
the
cluster
or,
if
you
wanted
to
replace
the
cluster,
would
require
you
to
go
into
into
each
and
every
application
and
update
them
to
point
them
towards
a
different
cluster
and
any
small.
Manifest
change
would
well,
first
of
all
require
you
to
rebuild
the
whole
image
as
adding
custom
logic
to
detect
manifest
changes
and
skipping
the
build
was
complex
and
it
depended
on
if
the
teams
were
willing
to
build
that
type
of
logic,
but
also
it
would
require
you
to
trigger
all
of
the
applications.
A
So,
for
example,
we
all
know
that
api
versions
sometimes
get
deprecated
in
a
situation
where
we
were
using
an
old
api
version
and
we
needed
to
upgrade
the
kubernetes
cluster
and
we
need
to
make
sure
that
each
development
team
was
upgrading
their
manifest.
That
would
require
somebody
to
go
into
60
applications
and
manually,
update
or
re-trigger
that
application
to
deploy
a
new
helm
chart
to
the
cluster.
A
So
my
idea
was
that
flux
would
solve
a
lot
of
the
bigger
issues
that
we're
seeing
with
development
teams,
mostly
around
trying
to
keep
what
developers
already
knew
and
worked,
but
replaced
things
that
were
still
new
for
for
certain
developers,
but
could
simplify
their
lives
and
our
lives.
Also.
So
after
implementing
flux,
one
of
the
main
benefits
that
we're
getting
is
we're
getting
a
unified
entry
point
towards
kubernetes.
A
As
it
is
a
pull-based
deployment
method,
we
don't
have
to
export
any
service
account
tokens
outside
of
the
cluster.
We
don't
have
to
configure
individual
deployment
pipelines
to
tell
it
which
cluster
to
look
at.
So
this
opens
up
opportunities
of
running,
for
example,
blue-green
deployments
of
clusters.
A
A
So
when
we,
if
we,
for
example,
come
up
with
a
new
recommendation
or
we
want
to
run
new
api
versions
being
able
to
just
go
into
a
single
repository
or
a
couple
of
repositories
is
way
much
easier
and
way
much
better
than
just
having
to
do
that
for
for
50
or
so
so.
One
of
the
cool
things
with
flux
is
that
you
can
run
it
in
a
multi-tenancy
solution.
A
What
this
means
is
that
you
can
configure
a
single
git
repository
to
only
have
access
to
a
namespace.
In
this
case,
a
tenant
would
have
one
git
repository
and
one
namespace,
and
these
would
be
linked
together
with
flux,
so
anything
that
you
place
into
this
git
repository
would
then
be
synchronized
into
that
namespace.
A
This
allows
for
a
good
separation
between
teams
where
they
can
cooperate
through
opening
up
their
namespaces
with
network
policies,
but
only
a
specific
team
would
have
access
to
their
own
namespace,
because
this
configuration
is
all
based
on
yaml.
It
becomes
very
easy
to
automate,
so
you
can
configure
flux
in
multiple
ways,
so
one
of
them
is
by
using
the
flux
cli.
Another
one
is
using
the
terraform
provider
which
helps
you
bootstrap,
the
cluster
with
terraform
and
the
last
one
is
writing
manifests
on
your
own.
A
A
A
In
here
we
have
a
tenant
directory
and
right
now
we
have
our
tenant
a
configured,
so
the
tenant
a
deploys,
a
or
creates
a
service
account
a
role
binding,
a
git
repository
and
a
customization
for
this
tenant
and,
as
you
can
see
here,
it's
pointing
towards
a
separate
git
repository.
This
git
repository
is
located
here.
So
this
is
tenant
b's,
get
repository
and
they've
been
super
nice
that
they've
actually
set
up
all
the
manifesting
configuration
before
or
ahead
of
time.
A
The
new
tenant
configuration
that
it's
committed
to
the
repository
and
then
it's
going
to
go
off
to
the
next
git
repository
and
for
the
tenant
b
and
synchronize
the
the
manifesting
configurations
from
there.
So
now
the
terraform
has
completed.
We
can
actually
jump
in
and
look
what's
being
changed
here,
so
jump
into
production
database
or
production
any
space
for
the
tenants
and
let's
get
the
ingresses
and
you
can
see.
Oh
great,
an
ingress
has
been
applied
to
the
cluster.
A
A
A
This
creates
the
new
challenge
configuration
with
new
role
bindings
to
a
different
name
space
and
a
new
git
repository
and
then
from
there
on
fleek
infra,
repo
kind
of
loses
responsibility
over
what
else
is
created
here.
So
then
flux
is
going
to
reconcile
this
git
repository
and
look
at
the
b
tenants
repository
and
here
we
see
and,
for
example,
production
that
we
have
created
an
ingress
resource
for
guestbook
a
certificate,
and
we
have
our
base
here
and
the
base
is
deploying
our
guest
book
application.
A
A
Initially,
flux
can
seem
a
bit
foreign
in
the
way
that
it
works
to
some
people
and
it's
mostly
because
it
strays
away
initially
from
the
traditional
cd
promotion
pipeline,
where
you
have
a
first
deployment
to
a
dev
environment
and
then
a
qa
and
then
a
production
and
there's
like
a
logical
pipeline
of
promotion
in
it.
One
of
the
earlier
issues
with
flux
was
that
there
was
no
feedback
loop
between
a
commit
and
an
actual
successful
deployment.
A
A
This
uses
the
same
apis
that
the
ci
does
so
it
shows
up
as
a
green
check
mark
or
a
red
cross
if
it's
unhealthy.
So,
as
you
can
see
here,
this
commit
would
be
reconciled
and
it
might
be
that
your
application
has
a
bug
in
it
or
that
it
can't
pull
the
image
and
then
the
reconciliation
would
eventually
fail,
because
the
health
checks
fail
and
it
would
post
back
a
unhealthy
commit
status
back
to
it.
A
What's
also
cool
with
this
feature
is
that
we're
now
able
to
build
promotion
flows
around
this
without
actually
needing
access
to
the
cluster?
Everything
is
pulled
in
by
flux,
so
flux
just
needs
access
to
the
kit
repositories,
but
also
the
feedback
is
posted
by
flux.
So
there's
nothing
going
back
to
the
cluster
to
check
the
actual
deployment.
A
A
A
A
A
Hopefully,
we
will
also
see
a
change
being
done
in
qa.
So
if
we
jump
into
our
commits
in
the
senate,
git
ops
repository-
we
see
a
couple
of
things
here.
So
one
of
the
things
is
that
we
have
our
status
objects
on
our
commit,
and
this
looks
slightly
different
from
github,
gitlab
and
other
git
providers.
A
A
We
can
now
maybe
see
that
yeah,
let's
wait
for
qa.
So
what
is
happening
is
that
we're
running
a
a
pipeline
that
is
creating
pull
requests
for
us.
So
if
you
look
at
completed,
pull
requests
we
can
see
here
is
a
pull
request
that
changes
the
image
tag.
So
after
this
pull
request
can
be
automatically
completed.
If
a
status
check
passes,
we
can
merge
it
and
the
change
will
then
be
applied
to
the
cluster.
A
So
this
allows
us
to
build
a
promotion
flow
outside
of
having
access
to
the
cluster
itself,
and
here
we
can
see
also
that
qa
has
updated
and
maybe
production
will
eventually
update
too,
and
this
is
all
done
by
by
our
commit
status
feature
so
the
commit
status,
as
I
said
before,
as
changes
are
reconciled,
it
will,
it
actually
knows
the
hash
of
the
commits
that
it's
reconciling.
So
that
way
we
can
post
the
status
of
the
commit
back
to
the
club
back
to
the
git
repository,
and
then
it's
kind
of
up
to
you.
A
You
have
all
the
opportunity
and
all
the
options
to
to
build
whatever
automation,
tools
or
non-automation
tools.
You
want
around
this
feature,
but
the
main
thing
here
that
is,
it
closes
the
loop
in
the
same
way
that
a
traditional,
continuous
delivery
pipeline
would,
from
operations
perspective.
A
major
benefit
of
running
flex
is
that
you
have
the
options
of
doing
proper,
blue-green
deployments
of
clusters
without
having
to
cooperate
with
all
your
developers
to
re-trigger
pipelines.
If
you
weren't,
using
flux
and
you'd
have
multiple
continuous
delivery
pipelines
that
were
pushing
applications
into
your
cluster.
A
A
So,
let's
just
first
wait
for
our
cluster
to
be
planned
and
applied.
Okay,
so
the
cluster
has
now
been
created
and
everything's
been
provisioned.
So
if
we
just
check
we've
now
configured
a
new
context,
we
have
two
clusters
aks2
and
nps,
one
in
eks2.
We
have
our
pawn
info
deployments.
If
we
jump
back
to
aks1,
we
should
see.
We
also
have
them
running
here.
If
we
then
scale
our
deployments
down
in
aks1,
because
dns
has
triggered.
A
A
Our
old
cluster
and
see
that
we
have
or
a
new
cluster
sorry
and
see
that
we
have
all
our
name
spaces
here
now
deployed
again.
So
that's
all
for
today.
Folks,
thank
you
all
for
joining.
If
you
want
to
get
involved
or
start
a
discussion
within
the
flux
project,
I
recommend
going
to
the
discussions
and
get
up
and
we're
also
on
slack,
so
the
flux
and
flagger
slack
channel
is
where
you
can
find
us
yeah.
Thank
you
and
I
hope
I
will
see
you
there.