►
From YouTube: Keynote: From One to Many, the Road to Multicluster- Kaslin Fields, Developer Advocate, Google Cloud
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.
Keynote: From One to Many, the Road to Multicluster - Kaslin Fields, Developer Advocate, Google Cloud
A
A
A
While
there
are
some
useful
tools
in
kubernetes
for
isolating
multi-tenant
workloads,
sometimes
it
makes
more
sense
to
use
the
cluster
boundary
to
isolate
a
team
application
or
service
for
security
and
compliance
reasons.
This
would
mean
you'll
end
up
having
multiple
clusters
in
order
to
meet
your
security
and
compliance
needs.
This
is
just
a
quick
look
at
a
few
of
the
reasons
I
see,
customers
in
users
site
for
their
multi-cluster,
architectures
and
most
organizations
have
a
combination
of
these
constraints.
A
Let's
imagine
you
have
applications
running
in
a
cluster
on-prem
and
one
in
the
cloud.
Maybe
you're
running
a
website
on-prem
and
in
the
cloud.
Maybe
you
have
a
mobile
app.
Your
first
challenge
in
working
with
this
multi-cluster
architecture
will
be
networking
and
that
challenge
comes
in
two
dimensions:
first,
the
vertical
dimension:
how
are
you
or
your
users
going
to
access
the
apps
running
in
each
of
these
separate
clusters?
A
A
I
joke,
but
really
dns
is
a
fragile
tool
that
causes
a
lot
of
problems,
as
we've
seen
on
the
cluster
end,
we'll
need
to
use
kubernetes
ingress
objects
to
manage
traffic
coming
into
our
apps,
though,
of
course,
the
networking
details
of
how
we
reach
those
clusters
and
apps
will
vary
per
environment
and
we're
also
going
to
need
some
load
balancers
in
the
cloud
you
can
use.
The
cloud
providers
load
balancer
make
your
own
and
on-prem.
You
have
a
variety
of
options
for
load
balancers,
not
to
mention
any
automation.
A
You
want
to
write
to
make
use
of
these
connections
and
I
barely
touched
on
anything
you'd
need
to
know
about
kubernetes
ingress
itself.
All
this
is
getting
pretty
complicated.
Two
kubernetes
sigs
have
been
hard
at
work,
creating
api
standards
to
help
make
solutions
to
these
challenges
simpler
and
more
consistent
across
environments.
A
Sig
multi-cluster
has
created
the
new
multi-cluster
services.
Api
standard,
multi-cluster,
services
or
mcs
creates
a
concept
in
your
kubernetes
cluster.
That
is
very
much
what
it
sounds
like.
It
enables
you
to
export
and
import
services
across
clusters.
This
doesn't
change
where
your
apps
are
running,
but
it
does
make
it
so
that
each
cluster
knows
about
the
services
running
on
your
other
clusters.
A
A
The
gateway
api
is
a
new
implementation
of
kubernetes
capabilities
for
managing
that
vertical
or
ingress
traffic
to
your
applications.
It
includes
a
variety
of
improvements
to
make
managing
ingress
easier
and
aims
to
provide
a
consistent
way
to
manage
your
kubernetes
clusters
interactions
with
networking
infrastructure
gateway.
Api
can
be
used
to
implement
a
concept
of
multi-cluster
ingress
where
a
centralized,
kubernetes
api
server
is
used
to
deploy
ingress
controls
across
multiple
clusters.
A
A
A
If
you
want
to
get
more
hands-on
with
multi-cluster
services
and
gateway,
api
check
out
the
gateway,
api's
documentation
and
also
this
cool
tutorial
on
github,
that's
useful
for
learning
more
about
multi-cluster
services.
This
work
is
still
in
its
early
stages
and
there's
so
much
left
to
do
so.
Join
sig,
multi-cluster
or
sig
networking
at
their
regular
meetings,
which
you
can
find
on
the
kubernetes
contributor
calendar
and
also
reach
out
on
slack.kates.io
to
get
involved.