►
Description
Kubernetes is the foundation of any cloud-native architecture today, however it is just one part of a modern enterprise infrastructure. In order to truly unlock cloud native agility, platform teams require new components and methodologies in order to successfully operationalize the entire stack. In reality many enterprise IT teams are faced daily with production challenges resulting from managing multi-cluster Kubernetes across multiple clouds.
What should you consider when designing and deploying a Kubernetes-centric architecture?
Solo.io and Weaveworks are teaming up to discuss common pitfalls and to demonstrate how GitOps workflows in the Weave Kubernetes Platform along with Gloo and Service Mesh Hub can configure, operationalize and extend your application environment across clouds.
* What do you need for a production grade Kubernetes infrastructure?
* What pitfalls to avoid when managing multi-cluster and multi-cloud
* How to control application traffic and security from Ingress to Service Mesh
* How to deliver sophisticated cluster lifecycle management of maintenance, upgrades and patches with GitOps
Download the presentation here
https://speakerdeck.com/soloio/gitops-powered-management-for-multi-cluster-kubernetes-across-any-cloud
Learn more about Solo https://solo.io
Join the Solo Community https://slack.solo.io
Learn more about Weaveworks https://www.weave.works/
Join the Weaveworks community https://slack.weave.works/
A
Today's
session
is
get-ups
powered
management
for
multi
cluster
kubernetes
across
any
cloud
and
your
speakers
today
we
have
Christian
posta
global
field
CTO
here
at
solo,
Paul,
Curtis
on
principle,
solution,
architects,
Leif
works
and
both
myself
and
Paul
have
some
custom,
fun
backgrounds,
virtual
backgrounds.
Christian's
background
is
real,
so
questions
can
be
anything
about
the
session.
The
topic
here
get
ops
cover,
Nettie's
service
mesh
or
what's
up,
what's
in
Christian's,
bookcase.
A
C
We
also
have
a
lot
of
Engineers
that
are
contributors
directly
into
kubernetes,
but
the
focus
of
what
we're
going
to
talk
about
today
is
get
ops
and
the
methodology
behind
using
get
as
your
declarative
source
for
everything
that's
running
in
your
kubernetes
cluster
and
springing
out
of
all
of
these
projects
that
we've
done
has
been
to
things.
We
do
a
lot
of
training
and
a
lot
of
consulting
for
companies,
large
and
small,
as
well
as
a
curated
kubernetes
platform,
which
is
all
upstream
and
packaged
with
tools
and
management
tools
as
well.
C
So
that's
we
Eve
in
a
nutshell
and
I
guess
we'll
move
to
the
next
slide.
So
we
talked
about
the
kubernetes
user
challenge
and
this
I'm
gonna,
be
very
quick
here,
really
focuses
on
four
major
categories
of
people
or
personnel.
So
when
you
think
about
the
kinds
of
people
that
we're
talking
to,
which
are
the
applications
developers
usually
sres
and
cluster
ops,
what
you're
seeing
is
is
that
kubernetes
is
very
well
received.
C
People
like
to
use
the
developers
like
to
work
in
that
environment,
but
in
a
very
quick
minute
it
becomes
very
complex,
and
so
what
get-ups
and
some
of
the
other
technologies
you're
beginning
to
see,
come
out
now
the
use
of
controllers
and
operators
in
order
to
simplify
it
and
methodologies
to
manage
kubernetes.
It's
scale
not
only
in
big
clusters
but
fleets
of
clusters,
and
so
this
is
a
whole
new
set
of
challenges.
C
There
really
isn't
addressed
and
we're
beginning
to
see
those
tools
appear
now
next,
so
I'll
put
up
the
five
buzzwords,
but
everybody's
has
at
least
two
of
these
and
every
conversation.
I
have
I,
usually
get
four
of
them,
but
the
top
ones
definitely
tend
to
be
reliability,
security
and
high
availability.
C
This
is
practical
use
cases
where
we
have
customers
doing
this
today
and
the
tools
that
needed
to
do
this
effectively
or
what
we're
gonna
show
you
actually
so
next,
so
very
quick
on
git,
ops
and
the
difference
between
get
ops
and-
let's
say
infrastructure
is
code,
so
it
becomes
the
sole
source
of
truths
about
everything
in
your
cluster.
What's
running
there
now
the
deployment
section
there
is
all
kubernetes
objects.
We
don't
really
care
what
they
are.
That
could
be
everything
from
a
pod.
C
All
the
way
up
through
service
meshes
arbok
security,
all
of
the
baseline
things
that
you
need
to
run
your
cluster,
but
the
difference
here
is
is
that,
unlike
infrastructure
is
code,
which
is
you,
you
execute
something
to
do
it
like
a
an
ansible
playbook,
for
example,
or
you
click
a
button
to
make
this
happen.
The
get-ups
methodology
makes
the
management
of
the
cluster
based
on
observing
the
cluster
itself,
meaning
that
the
agent
runs
in
the
cluster
basically,
is
what
controls
what
is
running
there
and
it
uses
git
as
the
declarative
source
of
truth.
Next.
C
Now,
when
you
put
all
of
this
together
when
you
look
at
a
whole
cluster
now
this
is
a
single
cluster.
You
have
a
number
of
different
things.
So,
depending
on
how
you're
running
kubernetes,
you
may
actually
be
building
out
the
infrastructure,
in
some
cases
you're
using
a
vendor
to
do
that
or
you're
using
a
managed
service,
so
a
que
se
gke
eks,
but
everything
else
above
that
kubernetes
line
pretty
much
has
to
be
managed
by
your
operators
to
your
s
ret.
C
C
C
So
our
view
of
the
world
and
everyone
that
looks
at
get-ups
says
that
you
have
the
kubernetes
part,
which
is
the
operators.
Part
and
get-ups,
makes
it
very
simple
because
it's
easy
to
manage,
and
then
you
have
the
developer
part
where
you
want
to
have
DevOps
able
to
deploy
out
applications
in
secure
ways,
and
that
part
is
also
part
of
get-ups.
D
Those
applications
need
to
talk
with
other
other
systems
running
outside
of
kubernetes
databases,
message,
queues,
caches
and
so
forth,
and
what
what
cloud
helps
us
do
is
decentralize
how
we
implement
this.
It's
this
traffic
control
and
securing
the
traffic
and
so
forth.
In
maybe
previous
years
previous
generations
of
technology,
we
might
have
both
formed
groups
within
our
organization
that
are
responsible
for,
let's
say
integration
or
API
management,
and
we
we
tasked
them
with
solving
that
that
problem,
and
at
least
in
in
previous
years,
that
usually
meant
standing
up
a
highly
centralized
highly
governed.
D
You
know
that
vendor
product
that
would
would
attempt
to
solve
this
now,
with
kubernetes
and
with
with
cloud
and
the
way
we
organize
our
teams
to
be
able
to
go
faster.
What
we
want
is
a
highly
decentralized
way
of
implementing
things
like
Rick,
letting
things
like
edge
security,
things
like
service
to
service
traffic,
routing
and
and
so
forth,
and
at
solo
specifically
we're
focused
on
how
do
we
build
tools
that
are
more
modern
and
play
much
nicer
in
a
cloud
environment
specifically
kubernetes,
but
not
just
kubernetes?
D
Things
like
shared
gateways,
things
like
service,
mesh,
service,
proxies
and
so
forth,
and
so
the
glue
does
is
it
sits
at
the
edge
implements
things
like
rate
limiting
transformation,
various
security
protocols
like
oh,
I
DC.
What
about
the
Web,
Application,
Firewall
and
so
forth,
and
it
forms
the
the
edge
gateway
that
allows
traffic
into
the
cluster
as
well
as
decouples.
The
API
is
that
clients
see
and
that
how
they're
actually
implemented
inside
the
cluster
so
they're,
not
just
exposing
api's,
as
they
exist,
they're.
D
Giving
a
layer
of
decoupling,
which
is
what
you
want
from
an
api
gateway
now
inside
your
boundary,
you
will
have
services
communicating
with
each
other
and
what
becomes
interesting
is
you
know
how
service
mesh
can
solve
those
those
challenges,
but
then,
more
importantly,
you're
not
going
to
deploy
in
a
single
boundary
right,
you're
not
going
to
deploy
in
a
single
kubernetes
cluster.
You
probably
have
multi
all
different
careers
clusters
for
reasons
like
compliance,
maybe
team
ownership,
maybe
blast
radius.
D
But
so
basically,
service
mesh
hub
ends
up
driving
the
different
control
planes
in
each
of
the
various
clusters
and
then
unifies
them
makes
it
look
like
one
single
one,
single
mesh,
one
single
federated
mesh.
So
now
in
your
clusters,
you
can
have
multiple
different
entry
points.
We
have
the
gateway
kind
of
securing
that
in
a
unified
way
and
once
traffic
gets
into
your
clusters
as
they
start
to
communicate
with
other
applications
in
different
clusters.
D
D
Right
so
now,
together,
where
we
have--we've,
you
know
providing
the
tools
to
bootstrap
and
manage
the
Cooper
days
clusters,
as
well
as
the
automation
and
the
processes
around
getting
the
applications
into
and-
and
you
know,
maintaining
this-
the
desired
state
declared
in
git,
as
well
as
the
processes
that
that
form
around
making
changes
to
those
pull
requests
and
so
forth
to
make
changes.
Now,
let's,
once
we've,
we've
established
the
platform
where
we
can
deploy
applications.
Now
you
can
use
the
solo2
tooling.
That
fits
very
nicely
with
that
model.
D
Everything
that
we've
done
in
in
the
solo
projects
like
service,
macabre,
glue
or
anything,
is
based
on
declarative
configurations
and
incriminates
that's
their
DS.
So
we
can
plug
everything
that
we
we
see
to
control
traffic,
to
control
security
into
the
clusters
between
the
clusters
and
so
forth
can
be
done
with
with
CR
DS,
and
it's
not
depend
on
any
particular
cloud
or
on
whether
you're
running
on
premises
or
our
relay
Paul.
Is
there
anything
you
wanted
to
add
to
that
before
we
start
getting
into
the
demos.
C
Just
one
more
point
is:
is
that
in
any
declarative,
configuration
kubernetes
by
its
nature
can
allow
you
to
not
only
just
have
one
of
those
you
may
have
clusters
with
multiple
teams
with
multiple
requirements,
and
so
you
can
have
different
declarative
areas.
Different
get
repos
for
different
teams
based
on
the
requirements,
specifically
things
like
networking
and
any
kind
of
ingress
passing
so
there's
a
whole
lot
of
things
that
you
can
do
in
building
out
either
a
big
multi,
tenant
cluster
or
a
fleet
of
clusters
that
make
this
very
simple.
B
C
C
C
Okay,
and,
as
you
can
see
here
on
the
left
side,
where
it
says
cluster
components,
you
have
a
basic
set
of
services
that
every
cluster
gets
and
when
you
go
to
look
at
where
that
lives
and
how
that's
configured
it's
fundamentally
in
get
so
when
you
actually
look
at
the
cluster
manifests
that
make
up
what
that
platform
looks
like
here.
They
are
at
the
time
that
kubernetes
is
bootstrapped.
C
The
first
thing
that
happens
is
that
you
bootstrap
the
software
agent,
which
is
called
flux
in
the
cluster,
which
then
reads
this
git
repo,
and
this
is
the
declared
state
for
the
basic
cluster
from
this
point
forward.
Everything
is
done
through
get
once
that
occurs.
We
get
a
basic
cluster
where
we
have,
for
example,
we
install
the
helm
operator,
we
install
Prometheus
and
scope
and
gravano,
so
we
have
a
set
of
tools
that
we
put
in
in
the
weave
Nettie's
platformer
world.
C
We
also
put
in
a
controller
for
workspaces
which
we'll
talk
about
in
a
second,
which
are
also
these
get
up
and
github
services
here,
but
this
is
the
base
cluster
right.
So
this
is
what
the
operations
people
perhaps
would
do
alright,
so
they
would
have
control
over
that
get
repo
that
manages
this
configuration
now.
So
when
we
talk
about
that,
the
ability
to
divide
this
up,
it
then
becomes
well
now
I
want
to
put
tenants
in
so
in
our
world.
C
But
that
requires
them
to
also
be
able
to
modify
and
build
out
their
underlying
networking
and
storage
and
all
these
other
operations.
You
don't
want
them
to
build
it
out
at
the
cluster
level.
You
may
only
want
it
to
build
it
out
at
the
application
or
project
level,
in
which
case
this
is
what
workspaces
and
namespaces
and
arbok
give
you.
C
So
when
we
look
at
the
baseline
cluster,
the
other
part
of
get-ups
that
is
required
for
flux
to
work
is
it
actually
has
to
be
able
to
monitor
and
observe
the
cluster.
So
we
find
that
our
customers
genuinely
and
pretty
much
all
the
time
put
in
prometheus
as
they're
monitoring
or
one
of
its
derivatives,
but
Prometheus
for
a
cluster
scale
is
fine.
C
We
also
tend
to
find
customers
putting
in
this
tool
called
scope
which
we're
going
to
use
a
little
bit
later,
but
basically
scope
allows
you
to
visualize
the
whole
cluster,
so
you
can
actually
look
at
it
from
pods
and
examine
what
is
actually
running.
So
you
can
see
in
our
case.
Here
is
the
actual
flux
agent
that
is
running
the
whole
cluster.
You
can
see
it's
in
band
and
its
outbound
connections,
and
things
like
that.
So
there's
a
lot
of
capability
here,
but
it's
great
for
visualization,
because
it
actually
visualizes
the
network
connections
as
well.
C
So
when
you
get
to
dealing
with
your
application
and
the
sidecar
proxies
that
go
with
it,
and
the
connections
to
the
mesh
scope,
for
example,
will
show
you
all
of
that
visually
and
obviously
you
can
do
it
by
namespace.
So
you
can
just
look
at
a
particular
namespace
and
you'll
see
right
now
that
none
of
these
are
connected,
but
they
would
all
be
this
visualization,
and
this
observability
is
very
much
required
in
order
for
the
operators
to
maintain
the
cluster
at.
You
know
to
keep
it
running.
C
Basically,
so
if
we
I'm
just
going
to
pick
up
one
of
the
charts,
so
we
as
a
company,
we
endorse
using
best
practice
to
go
ahead
and
install
the
observability.
The
other
thing
is
is
that
if
you're
doing
manage
progressive
deliveries
and
things
like
that,
you
need
to
be
able
to
observe
what's
going
on
in
the
cluster.
You
also
need
to
be
able
to
observe
when
there's
problems
is.
If
you
do
something.
If
you
take
an
action,
for
example,
upgrading
an
application,
you
need
to
be
able
to
roll
it
back
very
quickly.
C
So
one
of
the
benefits
of
get-ups
from
an
application
level
is
rolling,
back,
becomes
ooh
well,
I
just
have
to
move
the
head
of
that
git
repo
back
one
commit
ID
or
change
the
manifest
and
recommit
it
or
change
the
helm
chart
and
recommit
it.
That's
how
you
do
roll
back
in
the
get
ops
world
and
it
makes
it
very
simple
because
you
can
see
it,
everybody
can
look
at
it.
C
But
the
key
thing
in
our
demonstration
today
is
that
get-ups
works
with
any
kubernetes
object.
It
doesn't
discriminate,
so
you
can
use
it
to
build
out
declarative
service
message
which
glued
to
us.
So
you
have
the
ability
to
say:
not
only
can
I
build
out
the
cluster
put
in
some
services
and
maybe
some
applications,
but
I
can
configure
all
the
underlying
infrastructure
as
well
and
I
can
do
it
declaratively
and
if
I
make
a
change,
I
can
roll
it
back
very
quickly.
C
So
when
you
talk
about
a
fleet
of
clusters
now
you're
talking
about
clusters
that
would
exist
over
many
different
domains,
a
they
may
be
on
different
providers.
They
may
be
bare
metal.
They
may
be
in
a
hosted
service
like
a
packet,
for
example
digitalocean
or
they
may
be
in
decide
virtual
machines,
OpenStack
or
ec2.
C
The
thing
is
is
that
when
you
manage
that
kind
of
environment
you
not
only
have
to
be
able
to
manage
the
clusters,
ok
actually
going
in
and
see
what
is
running
on
any
given
cluster.
So
here's
one
with
five
workspaces-
and
here
they
get
repos-
that
they're
attached
to
this
one
happens
to
have
nothing
in
it,
but
this
get
repo
controls
that
one
application
for
that
one
tenant
on
that
one
cluster.
C
The
other
benefit
of
get-ups
is-
is
that
you
can
have
more
than
one
cluster
pointing
to
the
same
git,
repo,
so
building
out
disaster
recovery
and
high
availability
becomes
very,
very
simple:
okay
and
it
can
be
done
across
multiple
cloud
vendors,
pointing
to
the
same
git,
repo
I.
Don't
need
to
learn
a
new
tool
either
every
developer.
Well,
not
every
developer,
but
pretty
much
any
cloud
native
developer.
I've
met
knows
what
git
is
knows
how
it
works.
So
I
can
go
in
and
say:
hey!
C
You
know,
I
need
to
see
what
actually
changed
in
this
particular
deployment,
and
here
it
is
I-
can
use
git
diff
to
find
out
what
was
changed
when
this
cluster
was
built
out
and
deployed,
and
you
can
see
what
it
did.
It
changed
the
git
repos
it
set
up
my
deploy,
keys
things
like
that
at
an
application
level,
I
can
find
out
if
somebody
changed
the
number
of
replicas,
simple
things
like
that,
makes
this
very
observable
and
very
powerful.
C
C
You
want
all
the
developers
to
go
in
and
see
what
is
running
on
a
particular
cluster
so
that
they
know
what
versions
and
things
like
that
there
you
have
to
take
a
look
at,
but
the
flipside
of
that
is
is
that
that
means
that
maybe
that
a
dev
team
can
write
to
some
get
repos,
but
not
all
and
operations
can
only
write
to
the
ones
that
control
the
whole
cluster.
So
you
begin
to
see
that
it
gets
very
powerful
very
quickly.
C
You
need
to
manage
what
could
be
hundreds
of
nodes
across
multiple
data,
centers
and
multiple
environments,
and
get-ups
gives
you
that
ability
in
the
tool
kit
that
we've
has
in
both
in
the
open
source
and
the
ones
that
we
package
commercially
with
support.
You
can
see
where
this
would
be
a
very
powerful
combination,
so
I'm
going
to
stop
for
a
second
and
I'm,
going
to
flip
to
Christian.
D
D
D
The
comparison
to
its
tio,
for
example,
is
that
well,
SVO
is
an
implementation
detail
of
our
solution.
We
do
support
sto
and
what
we
do
is
pretty
try
to
provide
a
better
user
experience
with
multi
cluster
capabilities,
simplified,
so
go
come
check
out,
solo,
dot,
IO,
and
we
go
into
more
detail
about
the
different
things
that
that
we're
working
on
a
second
thing
and
the
question
that
often
comes
up
is
well
so
glue
is
any
edge
api
gateway.
D
What's
the
difference
between
that
and
sto
in
go
speedway
and
or
any
of
the
service
mission
educate
way?
So
how
is
that
overlap
happen?
If
you
click
on,
if
you
go
to
my
blog
I've
written
about
this
quite
extensively
on
a
very
most
recent
entry
here,
this
goes
into
quite
excruciating
detail
about
what
are
the
differences?
D
What
are
the
roles
of
those
proxies
in
those
gate
limits
and
when
you
might
want
one
or
the
other
or
both
alright,
then
of
these
are
not
mutually
exclusive,
but
you
want
to
understand
when
and
why
you
would
want
to
use
them
now.
What
we're
going
to
talk
about
right
now
is
the
service
brush
hub,
open
source
project
which,
when
you
have
multiple
clusters
of
kubernetes
setup,
you
have
your
application
deployment
pipelines
or
using
git,
ops
and
so
forth.
Now
you
need
these.
These
applications
to
communicate
with
each
other.
D
You
need
to
treat
multiple
disparate
service
meshes
as
as
a
unified,
federated
mesh,
and
that's
what
we're
doing
with
with
service
mesh
hub
which
I'll
which
I'll
show
you.
If
you
go
to
the
github
like
I,
said:
there's
open
source
project
and
you
can
click
on
the
docs
down
here.
There's
a
link
for
the
docs.
You
can
see
how
to
get
started.
D
Click
on
get
started,
so
you
get
the
appropriate
tools
and
one
of
the
simplest
way
to
get
started
even
with
multiple
clusters
is
to
use
kind
and
I
just
do
mesh
detail
demo
in
it.
That'll
spin
up
spin
up
to
two
kubernetes
clusters
for
you
install
this
deal
and
allow
you
to
kind
of
play
around.
If
you
have
more
complicated
that
maybe
any
of
existing
clusters-
and
you
want
it
for
real
and
not
inside
of
kind,
then
you.
B
D
D
What
we're
going
to
do
is
we're
going
to
use
service
mesh
hub
to
administer
these
it's
the
afaik
control
of
them
and
unify
them,
and
so
they'll
be
treated
as
one
single
virtual
mesh
now
the
actual
deployment.
So
we
could
use
a
third
cluster,
but
what
we're
actually
gonna
do
in
the
in
the
demo
is
co-located
sort
of
switch
off
on
one
of
the
clusters.
So,
let's
accidentally
do
it
so
start?
What
do
we
have?
D
Let's
connect
up
to
our
different
clusters,
the
ones
that
Paul
showed
some
of
the
ones
that
polish
up
from
earlier
we
see
we
have
sto
installed
on
cluster
one.
This
is
sta
1.5.
By
the
way
we
also
have
sto
installed
on
cluster
two.
Now
these
are
two
installations
of
sto
live
is
separate.
We
also
have
elements
of
the
book
info
is
sample
running
on
cluster
Winans
T.
D
We
have
version
1
and
version
2
of
the
review
service
and
then
version
1
of
so
many
others
and
we'll
take
a
look
at
at
this
in
a
little
bit
more
detail
on
cluster
2,
we
have
some
components
of
that
book
info
sample,
but
we
have
only
version
3
of
the
review
service,
so
we
have
version
1
and
version
2
of
a
review
service
here
in
version
3
running
on
a
separate
cluster
in
a
different
mesh.
Now
these
are
like
I,
said
independent
meshes.
D
D
And
let's
register
cluster
two
with
the
service
messed
up
here,
and
so
what
that
will
give
us
is
basically
this
diagram
cluster
1
and
cluster
2
service,
mesh
burning
on
cluster
1
and
now
knowing
about
hopefully,
these
different
service
rushes.
So
if
we
do
get
kubernetes
clusters,
we
see
that
service
mesh
hub
has
found
these
two
clusters.
This
is
a
CRD
that
comes
along
with
service
mesh
hub
there's
another
Ciardi
called
mesh,
and
we
should
see
that
the
to
sto
clusters
have
been
automatically
discovered.
D
Now,
that's
all
great,
now,
they're
registered
in
the
management
plane.
Now,
let's
see
how
we
can
federate
them.
The
first
thing
we're
going
to
do
is
we're
gonna,
look
at
AC
or
D.
Actually,
no,
that's
not
the
first
thing.
The
first
thing
we're
gonna
do
is
see
that
these
two
meshes
have
a
different
root
identity.
D
So
what
we
did
here
is
we
made
a
call
between
the
review
service
and
the
reading
service.
Now
it's
steel
in
this
case
in
this
configuration,
has
mutual
TLS
set
up
inside
of
the
mesh
running
on
cluster
1,
and
it
also
has
mutual
TLS
set
it
up
for
the
mess
mesh
running
on
cluster
2.
Both
of
them
have
a
different
root
root
root
CA.
So,
if
we
look
at
on
cluster
1,
we
see
that
the
root
ends
up
being
something
like
B
BC,
equal
sign.
We
do
the
same
thing
on
cluster
2.
D
So,
let's
create
this
virtual
mesh
resource
and
what
service
mesh
hub
is
going
to
do
it's
going
to
direct
the
different
clusters
to
do
is
inside
their
own
clusters,
create
a
new
certificate,
and
private
key
pair
then
request
that
service
mesh
hub
signs,
this
new
certificate
with
the
route
and
then
each
SCO
cluster
should
use
those
key
and
certain
as
the
as
the
root
CA
in
it.
So
now,
SPO
will
manage
distributing
out
the
certificates
to
the
different
workloads
rotating
them.
D
Updating
them
and
so
forth,
but
they
need
to
use
a
CA
chain
that
is
anchored
in
the
same
route
root
certificate.
So
let's
take
a
look
and
cross
our
fingers.
Hopefully
that's
exactly
what
happened
all
right.
We
see
that
we
grab
the
resource
that
everything
looks
like
it's
been
accepted.
We
have
created
a
new
route
CA.
If
we
look
at
here,
we're
gonna
get
this
secret
when
I
get
that
secret
here,
which
will
match
the
asserts.
We
see
the
certificate
ends
in
queue:
equal
equal
will,
remote
cluster
created
a
certificate
signing
request.
D
D
To
look
at
it,
we
can
look
at
it'll
skip
and
kind
of
running
out
of
time.
We've
created
a
new
intermediate
CA
on
the
on
clustered
one
for
the
sto
running
there,
we've
created
a
new
intermediate
CA
on
cluster,
we
haven't
exchanged
any
private
keys
or
anything
over
the
over
the
network.
And,
lastly,
there's
a
is
a
there's,
a
bug
in
SEO
that
we're
working
on
to
fix
that
for
the
controlling
to
pick
up
this
new
intermediate
CA,
we
need
to
bounce
the
control.
D
And
now
we
should
be
set.
We
should
have
the
same
route,
trust
for
both
clusters
or
any
number
of
clusters.
We
haven't
exchanged
any
private
keys
over
the
network.
Now,
when,
when
we
establish
connections
over
the
clusters
using
mutual
TLS,
they
they
should,
they
should
be
able
to
verify
each
other.
The
traffic
should
flow
smoothly.
Now
we've
also
updated
the
work
or
bounced
the
workloads
here,
so
we
might
see
them
fluctuating
a
little
bit,
so
they
more
quickly
pick
up
the
donated
certificates
instead
of
sitting
here.
D
Waiting
that
looks
like
it
might
be
good
enough
now,
if
we
go
back
and
we
check
that
the
certs
in
the
workload
for
chain
or
for
cluster
1,
when
we
click
on
reviews,
talks
to
ratings
and
there's
mutual
TLS
flow,
you
should
see
Q
equals
equals,
which
was
the
route
that
we
created
earlier
and
then
I'm
clustered
too.
We
should
see
Q
equals
equals
over
there
as
well.
B
D
Up
there
we
go
so
now
the
the
root
the
root
certificate
on
both
clusters
is
terminated
on
the
same
same
root.
Ca,
that's
all
good!
Now,
with
this
power,
we
can
get
things
like
automatic
service
discovery
between
the
clusters,
so
the
service
mashaallah
takes
care
of
creating
service
entries
in
is
TSO
if
you're
familiar
with
this
Co.
D
This
is
how
we
expose
we're
closed
at
run
outside
of
the
measure
enter
and
outside
of
a
cluster,
but
we
can
do
that
on
both
the
cluster
1
and
cluster
2,
so
that
we
can
and
we
can
communicate,
communicate
across
clusters.
The
mutual
TLS
stuff
has
already
been
set
up,
so
what
we
now
need
is
an
API
that
we
can
use
a
declarative
API
that
we
can
use
to
specify
policies
about
the
traffic
going
between
the
clusters
and
do
so
in
terms
of
this.
B
D
All
right,
I,
don't
know
there
might
be.
There
might
be
some
issues
with
the
cluster
here.
Maybe
it's
auto-scaling
or
something
but
but
so
sort
of
session
also
has
an
API
for
managing
things
like
traffic
policy
and
access
control
policy.
So
I
was
going
to
show
this.
This
particular
part
the
traffic
policy
spec,
but
we'll
have
to
do
that,
maybe
differently
or
a
little
bit
later.
D
C
B
A
You
can't
rib,
we
can
transition
to
some
of
the
questions.
Folks,
we
do
have
a
number
of
questions
in
here
and
if
you
have
more
questions
as
we
kind
of
chat,
please
go
ahead
and
type
them
into
the
Q&A
window,
but
first
one
here
what
I
got
is
I
think
if
we
go
back
to
this
slide,
real
quick
pause,
someone
was
asking
if
you
could
explain
what
an
immutability
firewall
is.
C
Yeah,
it's
actually
I'm,
looking
at
the
first
three
questions
and
I'll
do
them
all
at
once.
So
when
we
talk
about
this
conceptually,
it's
the
firewall
between
dev,
ops
and
the
CI
process
and
get
ops
and
the
CD
process
now
they
can
be
the
same.
You
can
use
the
same.
Get
to
do
this,
but
typically
you
want
to
separate
development
from
operations.
This
typically,
why
that's
there?
C
The
next
two
have
to
do
with
flux
and
multiple
multiple
git
repos.
So
one
question
was:
can
flux
support
multiple
git
repos?
No,
it's
one-to-one,
but
you
can
run
multiple
fluxes
in
a
cluster.
So
that's
that's,
basically
how
you
build
out
tenant
spaces.
The
second
one
is:
how
do
you
do
upstream,
failover
forget
and
that's
really
on
you.
His
flux
uses
a
git,
URL
and
I.
Get
URL
could
be
any
SSH
get
URL
that
you
choose.
C
So
if
you
want
to
see
naman
and
load
balance,
you
can
do
it
that
way
or
if
you're,
using
one
of
the
big
services
like
github
or
get
lab
online
or
bitbucket,
or
something
like
that,
they're
doing
it
for
you.
So
it's
a
choice
you
can
make.
We
don't
say
you
have
to
use
github,
we
don't
say
where
it
has
to
be.
All
we
say
is:
is
that
the
cluster
where
the
agent
is
running
flux
has
to
be
able
to
reach
it.
C
The
next
one
was
also
mine,
so
we
put
monitoring
in
the
base
cluster
and
not
logging.
The
reason
is
is
that,
for
a
lot
of
the
tools
that
we've
works,
builds
rely
on
Prometheus
to
get
metrics
on
the
fly
so,
for
example,
progressive
delivery.
You
set
thresholds
for
the
progressive
delivery
tool,
flagger
based
on
whether
there's
enough
CPU
or
your
or
the
latency
of
the
HTTP
request.
C
Whereas
logging
is
so
diverse
right
now,
I
mean
it
it
it's
settled
down
a
lot,
but
I
mean
there's
no
reason
you
couldn't
put
fluent
bit
as
one
of
the
things
in
your
base
cluster.
Why
not
and
as
I
said
that
this
could
be
any
kubernetes
objects,
we
give
you
a
set
of
defaults
to
start
with,
but
we
don't
force
you
to
use
them,
so
you
can
go
ahead
and
pick
which
ones
you
want
Wow
a
lot
of
good
ops,
questions.
D
Answers
yes,
so
we
we
showed
that
we're
grouping
two
of
those
clusters,
but
we
specify
which
clusters
we
want
part
of
that
virtual
mesh.
So
and
we
do
that
with
the
virtual
machine.
I
also
saw
just
real
quick
just
to
get
it
out
of
the
way.
The
question
from
Steve
thanks
for
joining
us
Steve
good
to
see
here.
D
D
C
A
Christian
clarification
on
the
multiple
virtual
missions
sounds
like
if
cluster,
so
the
example
that
the
person
laid
out
is
cluster,
three
is
combined
with
cluster
1
and
cluster
3
is
also
combined
with
lesser
two.
So
can
the
same
cluster
be
part
of
multiple
virtual
meshes.
It's
like
a
Venn
diagram
of
clusters,
yeah.
D
Suggestion
for
that
is
to
join
our
slack,
and
let's
talk
about
talk
about
that,
a
little
bit
more
say
that
again,
yeah
I
want
to
understand
what
that
use
case
is
I'm.
It
sounds
like
an
interesting
one,
so
I
just
want.
Let
me
give
a
bit
more
information
about
it
because
yeah
the
answer
is,
the
answer
is
yes,
there
is
a
way
to
do
that,
but
it
might
be
a
little
bit
more
involved
in
something
that
we
can
maybe
simplify
for
you.
Let's
chat
a
little
bit
more
join
our
slack.
A
B
D
C
C
C
A
C
I
did,
and
the
answer
is
no,
but
you
use
multiple
instances
of
flux
to
achieve
what
you
need
to
do
and
that's
how
we
do
multi-tenant
and
namespaces
so
and
from
the
perspective
of
an
application
developer,
the
operations
people
want
to
manage
one
part
of
the
cluster.
The
DevOps
want
to
manage
only
their
application
stack.
So
that
gives
you
a
way
to
do
two
repos
that
are
completely
separate
and
authorized
differently,
and
it
also
means
that
you
can
control
all
of
the
underlying
functionality.
That's
provided.
C
C
So
that's
a
good
question,
so
what
flux
does
is
when
it
first
starts?
It
does
get
clone
into
the
container
that
it's
running
in
so
it
has
a
clone
copy.
What
it's
looking
for
is
a
change
in
the
commit
ID
of
the
head
branch
right.
So
if
you
point
flux
to
master,
it
is
checking
the
commit
ID
of
head
when
that
changes,
it
refreshes
and
then
propagates
those
changes
into
the
kubernetes
api.
So
it's
a
pull
methodology
that
does
it
that
sort
of
answers.
C
A
D
Yeah,
okay,
so
we
do
it
right
now
by
registering
the
cluster
with
the
with
the
sort
of
special
health
management
plane,
and
what
that
does
is
it
gives
the
management
plane?
Basically,
a
slimmed
down
version
of
your
cube
of
your
cube
config
that
you
use
to
access
the
the
configuration,
so
you
might
want
to
create
one
that
is
locked
down
or
that
is
specifically
scoped
to
what
a
service
mesh
hub
can
do,
and
so,
from
that
perspective
it
doesn't.
But
as
long
as
the
cluster
is
reachable
that
we.