►
From YouTube: Taking Your Database Beyond the Border of a Single Kubernetes Cl... Christopher Bradford & Ty Morton
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.
Taking Your Database Beyond the Border of a Single Kubernetes Cluster - Christopher Bradford, DataStax & Ty Morton, Google
Deploying applications on Kubernetes is getting easier every day. From a minimal deployment to distributed service mesh enabled applications with planning and a little bit of YAML resilient cloud-native applications are the norm. In this session, Christopher Bradford and Ty Morton will help answer the following questions: - What about your data behind these apps? - Are you running those in a multi-cluster environment or sending everything back to a common location? - How do you modernize to a distributed peer-to-peer data architecture? - How do you plan for this change? - Are there pitfalls on the road to enlightened data? Join this session to explore the key concepts needed when investigating multi-cluster deployments for data. This includes: - Cluster planning - Network design - Security - Failure handling
A
B
B
B
Why
would
we
want
to
do
this
high
availability,
better
performance,
geo
locality?
We
want
to
scale
up
this.
This
effectively
gives
us
double
the
capacity,
but
you
did
not
join
the
talk
on
why
cassandra
is
awesome.
We
don't
have
enough
time
for
that.
So,
let's
dig
into
how
we
make
this
happen,
so
it
seems
kind
of
simple
at
first
right.
Maybe
I
already
have
some
automation
to
spin
up
a
kubernetes
cluster
that
might
be
terraform
scripts.
That
might
just
be
some
sweet
command
line
scripts
I
might
be
clicking
through
the
console.
B
We
can
just
deploy
it
spin.
It
up
call
it
done
right,
maybe
it'll
just
work
well,
depending
on
your
environment,
it
might
work
well,
parts
of
it
might
work.
Some
parts
might
work
a
little
bit.
Some
may
make
you
think
that
they're
working
and
they're,
not
you-
might
have
a
stray
firewall
rule
hanging
out.
B
B
So,
let's
start
by
looking
at
networking
specifically
how
networking
works
inside
of
kubernetes,
we
go
back
to
our
first
cluster
and
take
a
look
at
the
layers
of
networking
involved
at
the
vpc
level.
We
have
a
cider
range,
representing
the
addresses
for
instances
launched
within
it
here.
It's
10.100
and
the
instances,
as
you
can
see
here
with
the
slash
32s,
are
given
addresses
out
of
that
space.
B
In
some
cloud
environments,
those
subnets
are
tied
to
availability
zones,
so
you
might
have
a
slider
range
per
subnet
that
your
your
nodes
are
launched
into
and
when
I
say
nodes
here,
I'm
talking
about
kubernetes
workers,
you
might
have
other
vms
inside
of
your
vpc.
But
that's
what
I'm
trying
to
illustrate
here
now.
Your
kubernetes
cluster
is
going
to
have
a
different
cider
range
for
its
own
network.
That's
a
network,
that's
just
used
within
the
kubernetes
cluster
and
specifically
that's
the
network
where
your
pods
are
running.
B
A
pod
is
a
collection
of
containers
that
have
shared
resources
such
as
storage,
networking
and
process
space.
So
here
in
our
example,
we
have
10.100
for
the
physical
well,
even
if
it's
virtual
for
the
actual
nodes
themselves
and
then
10.200
for
the
kubernetes
level
and
then
down
here.
You
can
see
the
workers
each
get
a
slice
of
that
10.200
range
for
the
pods
that
are
running
on
that
individual
instance.
B
Now,
in
some
cases
there
are
multiple
sider
ranges,
those
would
represent
the
pods
and
the
other
range
would
would
represent
a
service.
It's
not
uncommon,
to
see
two
sets
of
ips
within
a
single
kubernetes
cluster,
but
you
should
just
be
kind
of
aware
that
that
exists
now,
if
we
think
back
to
our
target
structure,
what
happens
if
both
clusters
utilize
the
same
or
overlapping
ip
spaces?
B
Well
it.
It
takes
me
back
to
think
about
this
error
message
when
I
was
first
learning
about
networking
and
honestly
typing
in
ip
addresses
and
hoping
that
the
two
computers
would
still
talk
to
each
other.
I
remember
seeing
these
these
messages
come
up.
Maybe
you
see
them
from
time
to
time
on
your
machines.
It.
B
B
B
I
know
ty
is
going
to
disagree
with
me
a
little
bit
because
there
are
some
ways
around
this,
but
at
a
high
level,
if
you're
overlapping,
you're
you're
asking
for
a
bad
time.
So
this
leads
us
to
our
first
point
really.
You
want
to
understand
your
address
space
for
each
cluster
and
carefully
plan
the
assignment
and
usage
of
those
ips.
Now
you
might
be
saying
chris,
we
don't
have
enough
ips
I've
had
that
conversation
with
users
before
we
can't
give
every
worker
in
every
pod
their
own
ip
address.
B
It's
it's
literally,
not
possible,
and
if
that's
the
case,
what
you
can
do
is
take
a
step
back
and
say:
okay,
well,
what
services
absolutely
have
to
be
uniquely
addressed
and
what
services
can
be
running
in
the
same
address
space,
maybe
because
they
aren't
talking
to
each
other.
A
good
example
of
this
is:
maybe
your
database
tier
requires
it,
because
each
product
needs
to
be
able
to
talk
to
each
and
every
other
pod,
but
your
application,
tier
in
the
east
coast
and
the
west
coast.
Maybe
they
have
their
indicate
dedicated
kubernetes
clusters.
B
Those
can
be
in
the
same
sizer
space,
because
they're
not
reaching
over
the
way
and
talking
to
each
other
they're,
just
talking
to
their
local
data
layer,
their
data
kubernetes
cluster.
So
that's
that's
an
option
to
get
around
this
and
that's
what
that
particular
user
ended
up
doing,
but
really
we
we
need
to
be
clear
on
where
the
delineation
is
of
these
services
and
how
those
addresses
get
assigned
now.
B
Center
ranges
now
we
can
move
on
to
writing
packets
between
pods
in
each
cluster
and
just
to
call
out
this
the
particular
values.
Here
we
are
very
specific.
You
can
see.
The
west
coast
is
10.100,
the
east
coast
is
10.300,
the
nodes
obviously
have
ips
coming
from
those
ranges.
The
kubernetes
clusters
have
their
own
ip
space,
200
versus
400
here
and
then
the
pods
again
are
sliced
off
just
like
they
were
previously.
B
A
You
bet,
and
the
answer
is,
it
depends
not
the
best
answer.
I
think
really.
What
we
need
to
do
is
focus
on.
How
do
we
go
from?
It
depends
to
giving
you
some
options.
If
you
will
in
some
cases
it
may
just
work
out
of
the
box,
you
may
get
lucky
some
some
cloud
providers,
you
know,
provide
vpc
routing
and
so
a
lot
of
that
triple
smoking.
A
Magic
is
is
left
into
the
cloud,
and
you
know
you
don't
have
to
do
a
lot
of
heavy
lifting
around
that
in
in
other
cases
it
may
require.
You
know
you
creating
automation,
or
you
know
worst
case
manually.
You
know
creating
routing
tables,
but
but
the
reality
is
is
that
you
know
damon
sets
bgp
tooling
things
of
that
nature.
You
know,
vpns
are
all
certainly
possible
answers.
A
They
may
not
always
be
the
the
best
answer,
and
some
of
that's
gonna
depend
on
what
what
this
multi-cluster
architecture
looks
like.
Is
it
within
a
single
cloud
provider?
Is
it
multi-cloud?
Is
it
you
know,
hybrid
cloud
where
it's
a
combination
of
on-prem
and
maybe
two
cloud
providers,
but
you
know,
while
you
could
certainly
go
instrument
all
that
across
all
those
different
environments,
it
really
can
be
a
little
bit
overwhelming
and
require
a
lot
of
time
and
effort.
So
how
do
we
take
things
up
a
notch?
A
What
what
is
the?
What
is
the
maybe
not
the
easy
button?
But
an
easier
answer
is
overlay
networks.
You
know
in
this
model
you
would,
you
know,
build
out
separate
ip
address
space
for
the
application.
In
this
case
you
know
cassandra
database
and,
and
you
would
run
that,
on
top
of
the
existing,
you
know
cube
network
leveraging.
You
know
proxies
side,
cars,
gateways,
ingress
and
egress
controllers.
A
Whatever
the
case
may
be,
it's
probably
a
little
bit
too
much
to
go
into
specifically,
but
I
know
there's
lots
of
content
around
around
how
to
do
that
at
a
high
level.
So
so,
what's
next,
assuming
that
we
get
the
network
in
place
and
we
have
all
the
appropriate
routing,
some
connectivity
between
these
clusters
exists
at
least
at
an
ip
layer.
A
Yes,
we
have
ipconnectivity,
you
know
pods
in
in
cluster,
one
can
talk
to
pods
in
cluster
two,
but
we
have
some
new
things
that
we
have
to
to
take
into
account.
Those
pods
are
going
to
need
to
be
upgraded
at
some
point
or
you
may
need
to
you
know,
redeploy
them
or
you
may
need
to
add
additional
pods.
You
know
to
scale
the
application
in
that
scenario,
now
we're
introducing
a
lot
of
dynamic,
ips
and
and
how
in
the
world
do
we
resolve.
A
You
know
dns
in
a
dynamic
ip
environment
across
multiple
cloud
providers
and
my
on-prem
data
center
potentially
like
what?
What
does
that
look
like
this
could
also
be
some
you
know
done
via
automation,
or
you
know
some
other
manual
intervention.
If
you
will,
if
you
want
to
leverage,
you
know
dns
services
within
each
cluster,
and
you
really
want
to
manage
all
that.
You
know
you
can
tell
kubernetes
to
forward
requests
from
cluster
a
to
cluster
b
and
vice
versa,
and
you
would
do
that
through.
A
You
know
some
sort
of
a
stub
right,
and
so
we
have
an
example
here
of
you
know:
forwarding
requests
for
us
west,
4
from
us
esport
to
the
specific
dns
server
that
lives
in
that
zone,
and
then
I
have
to
go
manage
all
the
entries
in
there.
The
the
big
gotcha
here
is
that
it's
going
to
require
a
different
dns
suffix,
which
is
set
through
a
cubelet.
A
It
is
possible
to
work
around
it
by
tweaking
the
namespace
names
and
each
cluster,
and
then
you
know,
setting
up
stubs
and
and
all
this
requires,
at
the
end
of
the
day,
a
lot
of
dns
knowledge.
And
if,
if
you
have
that
expertise
and
that's
what
you
really
want
to
do,
you
know
more
power
to
you
again
back
to
the
it
depends
answer.
You
know
what
what
works
for
for
for
one
environment
may
not
be
the
best
solution
for
others.
So
what
other
solutions
do
we
have
that
are
like
that?
A
Well,
the
the
next
option
would
be
a
managed
dns
offering
the
in
this
scenario
we're
talking
about
cloud
dns.
It
abstracts
away
a
lot
of
the
traditional
overhead
that
you
would
have
the
you
know
the
cloud
provider
is
going
to
manage.
You
know
the
scaling,
the
monitoring
and
security
patches
and
all
of
that
stuff,
if
you
will
as
a
managed
offering
and
so
that
will
offload,
certainly
a
lot
off
your
plate.
A
A
A
So
what
are
some
of
the
strong
alternatives
that
we
could
look
at
and
you
know,
keep
in
mind?
These
are
just
a
few
examples.
You
know
the
the
cncf
provides
a
a
multitude
of
options
and
there
are
tons
of
open
source
projects
that
really
have
have
come
a
long
way
in
in
helping
to
alleviate
some
of
these
pain
points
and
and
really
abstract
away
a
lot
of
the
heavy
lifting
and
and
provide
a
better
alternative
with
a
lot
of
the
really
big
benefits,
especially
again
in
that
cross-cloud
multi-cloud.
A
You
know
hybrid
cloud
type
of
scenario.
This
example
we're
looking
at
you,
know
istio
and
psyllium
running
side
by
side,
so
it
doesn't
have
to
be
in
either
or
it
can.
It
can
be
an
and,
if
you
already
have
istio
deployed
you
can
certainly
add
you
know
something
like
psyllium.
On
top
of
that,
you
know.
Pod
ip
routing
is
really
kind
of
the
foundation
of
multi-cluster
capabilities
and,
and
obviously
both
of
these
tools
provide
that
you
know
functionality
today
and
and
really
the
goal
is
you
know?
A
How
do
we
streamline
you
know
pod
to
pod
connectivity
and
ensure
that
you
know
they're
able
to
perform
multi-cluster
ip
routing
like
that's
where
we
want
to
get
to
how?
How
do
we
do
that?
Well,
as
we
mentioned
earlier,
you
know,
as
I
mentioned,
with
overlay
networks,
so
it
is
possible
to
tunnel
tunnel
all
of
this
through
encapsulation.
A
A
You
get.
The
added
benefit
of
encryption
disadvantage
to
that
is,
is
that
you
know
those
things
require
additional
cpu
or
you
need
some
kind
of
server-side
offline.
Not
a
big
deal,
it's
pretty
common
these
days,
the
other
potential
disadvantages.
You
know
around
mtu,
we're
we're
encapsulating
another
packet,
so
we're
going
to
get
a
little
bit
up
there.
A
So
you
can
actually
start
to
create
policies
that
are
beyond
what
you
may
have
seen
in
you
know
or
leverage
today.
Instead
of
saying,
I
want
to
create
a
firewall
rule
to
ensure
that
you
know
my
applica.
This
application
can
only
talk
to
this.
You
know
cassandra
server.
You
can
actually
take
it
down
a
few
notches
and
say
hey.
I
only
wanted
to
have
read
access
or
you
want
to
restrict
it
to
you
know
specific
records
or
tables.
A
A
When
you
look
at
projects,
you
know
galley
or
hubble
from
the
same
folks
that
are
bringing
a
psyllium.
I
think
the
the
big
advantage
is
not
only
do
you
get
all
this
instrumentation
out
of
the
box
and
observability
and
it
builds
you
know
a
visual
representation
of
who's
talking
to
what,
but
also
showing
you
kind
of
the
health
of
all
those
pods
and
and
just
tons
of
like
fine-grained
visibility
that
you
won't
get
traditionally.
A
You
know,
I
think
that
the
the
key
thing
here
is
that
not
only
does
it
do
all
that,
but
by
the
way
it
can
also,
you
know,
help
instrument
on
on
the
traditional
kind
of
you
know:
monitoring,
metrics
side
of
the
house
where
most
of
these
tools
have
the
ability
to
to
integrate
tightly
with
prometheus,
and
now
I'm
getting.
You
know,
metric
data
on
connectivity
between
all
of
the
the
pods
and
the
applications
and
and
where
the
latency
may
or
may
not
be
as
well.
A
As
you
know
what
policy
is
potentially
being
impacted,
and
yes,
you
could
certainly
you
know
instrument
that
in
the
past,
I
think
you
know,
we've
all
been
there
and
done
that
where
we've
you
know
collect
logs
to
some
central
log
aggregator,
we
we
build
custom
searches,
we
create
dashboards
all
of
that
good
stuff,
but
at
the
end
of
the
day,
this
kind
of
happens
out
of
the
box.
So
how
do
we?
A
B
Yeah
so
you're,
not
in
a
single
region
or
cluster
anymore,
there's
going
to
be
a
bit
of
juggling
involved.
You
might
be
pushing
manifest
and
resources
to
each
cluster,
one
by
one,
maybe
you're
tempting
things
out
and
using
tools
like
helm
or
maybe
some
git,
ops
or
other
pipeline
tools
to
make
sure
that
you
are
staging
appropriately
and
you're
working
through
different
environments,
but
really
there's
still
a
lot
more,
that
that
is
required
when
you're
in
these
types
of
deployment.
B
So
like
one
example
here
is
helm.
If
you're
using
helm,
you're
gonna
have
a
release
per
cluster
and
you're
gonna
have
to
maintain
and
manage
switching
between
those
various
contacts
and
making
sure
you're
upgrading
the
right
way
and
then
dealing.
If
things
goes
like
when
things
go
sideways,
how
do
you
stage
a
change
or
roll
back
a
change
before
you
switch
over
and
do
do
operations
in
the
other
cluster
or
the
other
region?
And
when
you
go
beyond
two
regions,
there's
even
a
bit
more
complexity.
B
In
other
cases,
you
might
have
a
like
a
control
plane
where
you're
running
the
operator
and
then
it's
opera,
it's
operating
on
it's
reconciling
resources
in
the
downstream
clusters.
So
maybe
we
have
an
ops,
kubernetes
cluster
or
maybe
just
us.
West
4
is
running
the
operator,
but
it's
it's
communicating
with
the
cube
api
and
us
east.
B
We
talked
a
lot
today
about
manually,
managing
things
versus
having
cloud
native
technologies
that
can
manage
them
for
us,
whether
that
be
service,
discovery
or
routing
tables,
or
even
just
adjusting
the
packets
in
flight
to
indicate
what
cluster
they
need
to
go
to
and
eventually
what
pod
they
need
to
get
down
to.
So
really,
as
we
go
to
wrap
this
up,
though,
and
think
about
the
application
of
this.
What's
the
what's
the
big
moral
of
the
story?
Well,
first,
you
need
to
plan
your
deployments.
B
Get
the
right
people,
I
would
say
in
the
room.
Kobe
has
changed
things
a
little
bit
get
the
right
people
together,
though,
whether
that's
on
on
zoom
or
what
have
you
and
hash
out
like
how
you
gonna
do
this
right?
Where
do
you
have
limits
in
your
system?
Maybe
you
have
a
scarcity
of
ip
addresses.
Maybe
you
were
looking
at
running
one
big
cluster
and
now
you're
talking
about
doing
many
small
clusters.
Maybe
you
do
clusters
along
the
lines
of
business
or
certain
ops
teams?
A
B
Systems
to
communicate
with
each
other,
and
that's
that
could
be
a
single
team.
It
could
be,
but
really
you're,
probably
looking
at
operations
teams
you're
looking
at
people
that
run
the
cloud
accounts
you're
looking
at
people
that
run
if
you're,
hybrid
or
multi-cloud,
you
probably
have
some
network
people
involved
too.
Maybe
there's
firewalls
that
that
need
to
be
adjusted
in
certain
ways
and
really
doing
a
lot
of
this
planning
up
front
is
really
beneficial
and
will
pay
out
huge
down
the
road
as
you're
as
you're
getting
into
implementing.
B
In
some
cases
after
you've
launched
the
cluster,
it's
not
something
you
can
just
change.
I
can't
just
change
the
cider
space
that
my
pods
are
running
and
after
I've
launched
the
cluster
I
would
then
need
to
migrate,
and
so,
if
I
do
some
of
this
planning
up
front,
I
can
avoid
some
of
those
those
unfortunate.