►
From YouTube: Lightning Talk: GitOps and Controllers: It’s Not That Simple for Multi-cluster- Alex Ly, Solo.io
Description
Lightning Talk: GitOps and Controllers: It’s Not That Simple for Multi-cluster- Alex Ly, Solo.io
GitOps has become a valuable approach to manage configuration for applications and infrastructure. Having a source of truth that can be automated, auditable, and is easy to understand is increasingly important when expanding to many deployments. However, enabling multi-cluster capabilities typically presents new challenges: not every cluster is the same, context is important, and managing every lower- level configuration across multiple environments can get cumbersome (and dangerous) quickly. This talk will focus on a specific example where multi-cluster GitOps is difficult: application-networking and security with service mesh. The goal is for platform teams to provide the right point of demarcation with abstractions that focus on the intent, while abstracting away the translation and orchestration of lower-level config (mesh-specific API resources in this case). We share our experiences building these abstractions with some of the largest deployments of service mesh in the world.
A
Hi
everyone,
my
name,
is
alex
lee
today
I'll
be
talking
about
git,
ops
and
controllers.
Title
is
it's
not
that
simple
for
multi-cluster
and
I'll
be
going
through?
Why
some
value
points
today
on
what,
where
to
use
and
what
the
value
points
between
using
git,
ops
and
and
when
to
kind
of
match
that
with
controllers
so
yeah,
like
I
said
my
name
is
alex
lee,
I'm
a
field
engineer
based
out
of
san
francisco
at
solo.
It's
a
pleasure
to
be
here
in
valencia.
A
A
However,
when
you
move
to
multi-cluster,
it
starts
to
require
some
context
right,
so
you
start
have
to
focusing
on
your
your
team,
your
networking
team.
How
do
I
define
your
traffic
or
engineering
policy
intent
and
how
do
we
effectively
translate
this
intent
into
policy
or
configuration
at
scale,
and
this
gets
a
lot
more
complicated
as
you
move
to
more
clusters
in
this
picture?
It's
just
three,
but
you
know
we
have
some
customers
that
run
tens,
if
not
hundreds
of
clusters.
A
So
one
question
I
like
to
kind
of
talk
to
my
customers
about
is
when
you're
going
through
these
slides
think
about
who
is
the
control
plane
right
so
in
this
slide
right
here
we're
kind
of
doing
multi-cluster
manually
right
and
my
networking
admin
team
needs
to
focus
on.
You
know
the
stuff
to
the
left
of
the
network:
admin
icon
here:
service,
routing
traffic
policy,
processing,
mtls
rate,
limiting
xoth.
All
these
api
gateway
features
as
well
as
service
mesh
features.
A
On
top
of
that,
they
need,
to
kind
of
you
know,
focus
on
the
intent
right,
the
high
level
policy
intent
and
their
tasks,
which
is
in
this
case,
defining
the
high
level
policy
translating
those
into
the
istio
resources
validating
the
expected
behavior
committing
it
to
get
deploying
and
managing
all
these
on.
Each
cluster,
ad
hoc,
maintaining
control
and
drift
of
all
these
yaml
manifests
in
istio
and
managing
this
at
scale.
You
know
it
starts
to
see
yeah,
as
you
can
start
to
see.
A
A
You
know
allow
them
the
git
ops
to
do
what
it
does
best,
which
is
managing
at
scale
many
apps
and
many
clusters.
However,
we
start
to
focus
some
of
that.
You
know
those
tasks
that
the
networking
admin
team
shift
down
to
automation
again
right
with
the
control
plane.
So
we
allow
the
control
plane
to
translate.
Is
your
resources
for
us,
provided
that
we
have
a
simple
to
use
api
at
the
high
level?
A
So
here's
a
couple
kind
of
examples
of
you
know
where
the
controller
value
here
comes
into
play.
One
of
the
key
pieces
is
the
usage
of
labels
and
label
selectors.
So
you
see
on
the
left.
It's
really
more
of
kind
of
a
manual
approach
to
this
say
I
want
to
kind
of
you
know,
provide
ingress
to
an
application
on.
I
have
five
clusters
cluster
one
two
three
have
applications,
but
I
only
want
to
expose
my
app
on
apps
on
cluster
one
and
two.
A
My
networking
admin
team
here
needs
to
understand
this
context
understand
that
they
need
to
create
those
issue,
resources,
the
gateway
and
virtual
service
and
place
them
on
cluster
one
and
cluster.
Two,
and
imagine
this:
if
you
had
you
know
tens
or
hundreds
of
clusters
right
so
on
the
right.
When
you
shift
this
to
a
to
the
use
of
a
controller,
you
can
actually
start
to
leverage
labels
and
label
selectors
similar
to
how
we
do
in
kubernetes
at
the
top.
Here
you
have
a
workload
selector
selecting
by
the
label.
A
Ingress
is
true,
and
then
on
each
cluster
you
would
have
a
label.
Ingress
is
true
and
therefore
the
control
plane
can
auto
discover,
as
we
scale
from
you
know,
tens
to
hundreds
of
clusters
automatically
know
that
hey.
I
need
to
deploy
this
gateway
or
virtual
service
there,
and
it
no
longer
is
a
task
of
that
admin,
networking
admin,
group
or
team
to
manage
that
you
know
cumbersome
task
so
how
we
can
expand
that
label
and
label
selection
idea
here
really
start
to
take
this
to
policy
and
other
things
that
are
in
the
mesh.
A
For
example,
in
this
in
this
diagram
we
have
our
waff
policy,
you
can
only
you
can
just
create
it
once,
rather
than
having
to
kind
of
codify
it
into
an
envoy
filter
and
deploy
it
in
git
ops.
Here
I
can
just
create
the
waf
policy.
The
control
plane
will
now
know
to
look
for
a
label.
Waff
is
true
on
on
the
cluster
and
deploy
that
waft
policy
to
to
the
clusters
that
need
be.
A
I
can
take
and
expand
this
label
selection
and
paul
uniform
policy
concept
to
many
other
pieces
of
the
mesh,
such
as
rate
limiting
authentication
fault,
injections,
failovers
and
transformations,
and
you
can
start
to
see
how
you
know
the
or
I
hope
you
can
start
to
see
how
the
get
ops
approach,
along
with
along
with
controllers,
can
provide
a
lot
of
value
to
managing
istio
at
scale
thanks.
Everyone.