►
From YouTube: Cloud Native Global Load Balancer for Kubernetes - Yury Tsarev & Zak Anderson, Absa Group
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.
Cloud Native Global Load Balancer for Kubernetes - Yury Tsarev & Zak Anderson, Absa Group
Global load balancing, commonly referred to as GSLB (Global Server Load Balancing) solutions, has typically been the domain of proprietary network software and hardware vendors and installed and managed by siloed network teams. k8gb is a completely open-source, cloud-native, global load balancing solution for Kubernetes. k8gb focuses on load balancing traffic across geographically dispersed Kubernetes clusters using multiple load balancing strategies to meet requirements such as region failover for high availability. Global load balancing for any Kubernetes Service can now be enabled and managed by any operations or development teams in the same Kubernetes native way as any other custom resource. k8gb is a CNCF Sandbox project.
A
A
B
A
Cool
thanks
zach,
so
let's
jump
straight
away.
The
presentation
so
well,
where
are
and
how
it
all
started
somewhere
in
2019
apsa
group
figured
out
that
organization
needs
open
source,
global
service
load,
balancing
function,
some
cloud
native
solution
to
steer
the
traffic
in
a
smart
way
over
geographically
dispersed
kubernetes
clusters
and
we
needed
to
solution
to
be
able
to
be
aware
of
internal
workflow
workload.
A
It
stands
for
kubernetes
global
balancer
and
it
was
developed
in
an
open
source
in
a
github
as
a
repository
from
day
zero,
so
in
totally
open
minor
as
a
open
source
project.
From
the
very
beginning,
slightly
more
than
one
year
fast
forward,
we
managed
to
attract
a
small
community
built
to
mature
enough
projects
and
to
reach
the
cncf
sandbox
level,
acceptance
which
we
are
very
really
proud
of,
and
we
are
using
in
kgb
in
production
for
more
than
one
year.
A
A
Which
enables
us
to
be
highly
reliable
and
to
operate
in
a
global
scale.
Dns
is
used
both
for
traffic
steering
and
cross
cluster
state
exchange,
we're
trying
to
be
as
environment
agnostic
as
possible,
meaning
that
we
are
automatically
configuring
only
zone
delegation
on
a
environmental
dns
provider
like
royalty
screen
for
vlogs
or
ns1,
and
we
are
not
creating
any
other
resource
records
to
steer.
A
A
B
A
A
It
is
very
simple
flow.
One
important
thing
to
highlight
again
that
kgb
is
deployed
right
to
the
clusters
where
application
that
requires
to
be
enabled
globally
enable
the
same
cluster,
where
this
workload
is
running.
So
whenever
a
gsb
resource
is
created
now
by
application
team
or
associated
pipelines,
the
special
ingress
resource
is
created
and
enables
the
http
traffic
steering
and
to
whenever
the
actual
end
user
is
making
a
dns
request
like
this
browser
or
by
any
other
means.
A
This
request
is
going
to
end
up
on
a
kgb,
pulse
and
coordinate
spots
and
kgb
is
going
to
return
the
dns
response,
according
to
the
global
strategy
that
is
configured
within
a
gslb
crv
and
the
requester
will
get
appropriate
address
and
will
hit
the
ingress
controller
and
you'll
keep
it
eventually
the
application
code.
So
you
can
imagine
that
we
can
build
some
a
couple
of
obvious
strategies
there.
A
A
A
strategy
where
we
can
pins
one
of
the
data
centers
one
of
the
clusters
to
be
primary
and
whenever
we're
closing
this
primary
cluster
is
healthy.
That
traffic
will
be
served
from
csdc1.
Only
and
whenever
report
is
treated
unhealthy
votes
are
dead,
then
it
will
be
automatically
fail,
fail
over
filled
over.
B
A
B
Yeah
thanks
yuri
that
was
a
awesome
overview
of
the
components
of
the
solution.
Really,
it's
good
to
see
the
the
diagrams
again.
Okay,
so
from
an
absolute
internal
perspective,
I'm
going
to
talk
a
little
bit
about
what
we
do
and
why
we
do
it.
So
we've
got
about
12,
tenant
teams
that
are
running
this
and
from
a
perspective
of
clusters,
we've
got
122
kubernetes
classes
on-prem.
Today,
36
of
them
are
basically
enabled
for
kgb.
That's
mainly
our
core
api
payments
engines.
B
There
are
also
some
other
services
that
are
sitting
there
for
authentication,
so
we're
using
that,
for
example,
key
cloak
we've
got
an
active,
active
setup
setting
in
those
production
services
from
a
services
that
are
enabled
quite
easily
and,
like
yuri's
explained
it's
an
annotation
that
gets
enabled
and
that's
why
we
can
roll
out
these
gslb
enabled
services
quite
quickly
and
once
it's
installed
into
the
clusters,
they
become
goo.
So
it
doesn't
matter
whether
it's
in
one
data
center
or
the
other.
B
B
B
So
the
biggest
thing
about
this
whole
about
the
whole
solution
was
how
would
we
do
new
tenants
and
services
and
basically,
we
will
drive
failover
automation
as
far
as
possible.
We
are
trying
to
integrate
automated
pipelines
and
then
make
them
aware
so
that
the
teams
or
the
developers
can
actually
enable
their
own
exposed
services
without
going
to
the
network
team
or
going
to
the
dns
team
or
going
to
any
other
team
to
file
over
my
stuff
in
a
failure
scenario,
and
that
was
the
beauty
about
kgb.
B
It
gave
that
functionality
that
we
could
lose
a
whole
data
center
or
another
data
center,
and
if
we
had
cloud
and
on-prem,
we
would
have
officially
four
data
centers
running,
so
we
could
run
workload
in
all
four
data
center.
The
the
nice
thing
that
we
did
is
because
we
are
a
template
or
templatized
environment.
B
This
was
a
simply
a
module
that
we
added
into
our
crcd
and
we
templatized
the
actual
annotations
for
the
teams
and
all
they
had
to
do
was
put
like
three
variables
in
and
the
annotations
would
then
flow
into
their
pipelines
and
it
would
go
from
dev,
srt,
uat
and
prod,
and
it
would
enable
those
services
quite
quickly.
They
didn't
have
to
log
changes
or
engage
third-party
people
to
help
them,
and
things
like
that.
So
the
key
thing
and
why
we
built
this
is
we
wanted
to
make
sure
dr
automation
was
done
automatically.
B
So
people
usually
say
they
don't
know
what
went
wrong
and
where
it
failed
over
to,
but
now
we
have
a
way
to
automate
it
and
make
sure
that
we
can
actually
make
sure
our
services
run
24
7,
I
would
say
so-
and
the
cool
thing
about
this
app,
which
is
quite
awesome,
and
I
love
that
the
teams
themselves
are
in
control
of
that.
So
you
start
pushing
teams
to
become
high
performing
teams.
B
A
A
A
A
Created
associated
gslb
resource,
so
the
gslb
resource
looks
very
simple:
our
apa
namespace
ipa
group,
sorry
kind
standard
metadata
and,
as
you
can
see,
this
part
of
gslb
spec
is
like
one
to
one
to
standard
ingress
resource.
So
it's
a
standard,
ingress
spec
but
embedded
into
jsob
crd,
and
we
are
composing.
This
ingress
stack
with
jsob
strategy.
In
this
specific
case,
it's
a
failover
and
we
are
pinning
the
primary
to
be
u
west.
One
and.
A
A
A
We
are
using
this
trick
for
internal
adoption
as
well,
so
nah
yeah.
We
have
a
that's
just
a
b
namespace,
where
we
had
a
where
we
have
a
standard
like
to
very
popular,
not
standard
but
very
popular
for
the
info
application
deployed
and
we
are
using
it
to
test
the
gslb
function
and
we
have
gslb
already
applied
here
with
strategy,
failover
and
us1
primary
geotag.
Exactly
this
step
that
I
showed
before
it's
it's
already
running.
So
we
can.
A
B
A
B
A
A
B
A
Yeah
pretty
much
so
I
I'll
show
the
whole
chunk.
So
it's
a
standard
curl
right,
so
it's
a
sample
output
and
we
intentionally
populating
a
custom
message
with
the
geotag
according
to
the
pod
location
right.
So
whenever
we
reach
the
af
cells
one,
it
will
be
immediately
visible
in
the
output.
But
currently
again
we
are
using
failover
strategy.
A
A
A
Absolutely
the
same:
gslb
spec
same
strategy,
no
special
configuration
required,
so
it's
exactly
the
same
spec
as
was
applied
in
europe.
Also.
Africa
is
aware
that
the
main
primary
cluster
is
a
us1.
That's
why
it
is
returning
consistent
responses.
Dns
responses,
these
european
ip
addresses
as
well,
so
even
yeah.
B
A
B
A
We
have
a
symmetric,
consistent
configuration
on
both
of
the
clusters
and
everything
is
working
as
expected.
Every
everything
is
fine
in
europe.
So
let's
emulate
an
outage
in
europe
with
the
standard
kubernetes
approach
of
scaling
replicas
down
to
zero.
So
I'm
just
scaling
down
a
testing
workload
and
let's
get
it.
A
A
It
is
because,
on
this
global
load,
balancing
scale
we
are
operating
with
dns
and
dns
has
its
advantages
and
has
its
limitations
so,
and
one
of
the
limitation
is
operating
within
a
a
detailed
value,
a
time
to
lift
value
and
we
are
trying
to
keep
it
as
low
as
possible
for
us,
it's
30
seconds,
it's
already
pretty
aggressive,
not
too
from
operational
standpoint,
exactly
sleeping,
honest
yeah.
For
us
it
worked
pretty
nice.
B
Yeah,
so
that's
a
very
important
point
right,
so
this
is
failing
a
major
region
over.
So
from
that
aspect,
the
ttl
was
quite
acceptable.
All
the
other
back-end
stuff,
like
databases
and
things
would
also
have
failed
over.
So
the
app
would
have
come
up.
The
databases
would
have
failed
over
and
in
that
scenario
we
would
have
been
running
within
a
minute.
You
know
so
that's
more
than
acceptable
for
what
we
have
inside
our
bank.
A
B
The
kgb
installation
is
such
that
you
can
fail
it
over
even
re
reproduce
the
installation
and
get
going
if
your
pipeline
is
done.
The
way
that
you
want
it
to
set
up
right,
you
can
do
it
manually,
you
can
do
it
quickly
and
I
think
that's.
The
key
thing
for
me
was
the
easy
quick
way
we
could
get
kgb
up
and
running
when
we
lost
say
a
data
center
and
those
chaos
tests
that
we
do
actually
show
that
right.