►
From YouTube: K8GB - Kubernetes Global Balancer with Yuri Tsarev (Absa Group) | OpenShift Commons Briefing
Description
K8GB - Kubernetes Global Balancer with Yuri Tsarev (Absa Group)
https://github.com/AbsaOSS/k8gb
Slides: http://bit.ly/2O7OxBf
Upcoming OpenShift Commons Briefings:
https://commons.openshift.org/events.html
K8GB is a Global Service Load Balancing solution with a focus on having cloud native qualities and work natively in a Kubernetes context. Global load balancing, commonly referred to as GSLB (Global Server Load Balancing) solutions, have 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.
In this briefing, we get an intro to K8GB from Yuri Tsarev (Absa) & we’ll leave time for live Q/A!
more k8gb details here: https://github.com/AbsaOSS/k8gb
A
B
Yeah
yeah
sorry
go
ahead,
yeah
yeah!
Thank
you.
So
this
project
has
originated
out
of
the
needs
of
global
load
boundaries
that
is
kubernetes
native
and
pretty
much
cloud
native.
So
we
tried
multiple
vendors.
None
of
them
worked
for
us.
Well,
so
we
decided
to
develop
one
global
balancers
from
scratch,
but
this
load
load
balancer
is
not
a
standard
approach
for
load
balancing.
It
doesn't
pass
the
traffic
through
itself,
it
actually
modifies
dns
responses
on
fly
and
it
monitors
the
kubernetes
primitives
from
inside
the
cluster.
B
So
it
is
developed
as
an
operator
pattern
like
his
coin
from
chorus
back
in
the
days.
It
doesn't
have
any
single
point
of
failure.
So
controller
is
installed
on
top
of
the
target
clusters
where
workloads
are
running
and
there
is
no
control
cluster.
So
there
is
no
single
point
of
failure
in
that
regards
and
everything
is
built
on
top
of
standard
kubernetes,
primitives,
ingress
services
associated
endpoints
and
down
to
alignments
and
radiant
spots
probes.
B
So
the
core
of
the
operation
is
dns
protocol
and,
as
its
running
internet
is
pretty
reliable,
it
obviously
has
its
own
limitation,
but
for
glo
to
global
balancing
scenario.
It
works
pretty
good
and
we
built
we
try
to
build
the
kgb
this
way.
So
it's
as
much
independent
of
environment
as
possible,
so
meaning
that
we
are
relying
on
environment
dns.
For
example,
we
call
it
hdns
it's
route,
53
for
example,
or
infoblox
in
our
on-prem
scenario
or
ns1,
as
we
have
another
integration.
So
we
are
configuring.
B
So
from
implementation
standpoint
we
use
the
operator
is
the
sdk
and
it
worked
very
nicely
for
us
and
it
allowed
us
to
bootstrap
project
pretty
quickly,
another
integral
in
a
part
of
kgb
score.
Dns,
that's
exactly
the
tiny
part
that
serves
the
dns
and
responses
dynamically
and
basically
steering
traffic
to
desired
clusters.
According
to
load,
balancing
strategy.
B
External
dns
is
taking
care
of
communication
with
external
dns
for
these
hdns
providers,
as
I
mentioned,
so
it's
as
a
route,
53
ns1
info
blocks,
and
maybe
something
else
in
future,
so
these
three
were
already
very
well
tested
tested.
So
this
part
takes
care
of
automated
zone
delegation
and
we
also
were
using
ad
cd
like
dedicated
sd
cluster
and
associated
lcd
operator,
to
actually
populate
a
local
lcd
database
dynamically.
So
external
dns
would
read
information
from
dynamically.
B
Sorry
for
that
dynamically
populated
dns,
endpoint,
crd
and
external
dns
would
locally
create
the
lcd
entries
so
and
eventually
coordinates
would
breed
from
this
e3.
It's
so
called
the
sky
dns
back
end.
So
it
worked
like
out
of
the
box
with
the
last
community
procedure
here,
but
it
had
quite
amount
of
reliability
and
maintainability
problems
for
so,
for
example,
lcd
operator
is
dropped
by
community
completely
at
city
itself
and
it
wasn't
working
reliably
enough.
So
you
know
long
running
clusters.
B
We
were
fighting
at
cd
in
a
degraded
state
from
time
to
time,
so
it
was
a
problem
for
kgb
reliability
itself.
So
that's
why,
in
a
recent
version
we
dropped
that
cd
and
a
cd
operator
can
prove
completely
and
we
replaced
it
with
a
core
dns
build
with
a
custom,
kubernetes
crd
plugin
that
we
developed
recently
so
core
dns
in
our
case
can
read
information
directly
from
the
innocent
point.
I
will
show
everything
like
in
a
demo
how
it
works.
B
So
we
have
quite
amount
of
integrations,
so
this
hdns
providers
are
mentioned
so
infoblox.
We
carefully
testing
like
not
testing
using
in
the
bank,
and
that
was
the
first
provider
we
implemented
so
to
fulfill.
Our
business
needs
route
53.
We
using
advanced
reference
setup
that
I
will
show
you
today
on
top
of
two
geographically
dispersed
gas
clusters
and
ns1
is
our
future
integration.
B
We
are
very
close
collaboration
with
this
guys,
amazing
and
we
have
a
very
nice
open
source
cooperation
with
admiralty
project,
which
is
multi-cluster
scheduling,
and
it
works
very
nicely
where
admiralty
schedules,
workloads
on
top
of
multiple
clusters
and
php,
basically
enables
a
load
balancing
for
them.
So
we
have
a
associated
tutorial
for
that
on
both
of
the
on
the
pages
of
both
of
the
project.
So
you
can
quickly
go
to
the
demo
so
just
quickly
on
a.
B
B
Oh
cool,
thank
you
for
that
up
yeah.
So
we
will
run
a
demo
setup
similar
to
the
picture
here.
So
two
geographically
dispersed
clusters.
One
is
in
europe
and
dublin
another
one
in
africa,
cape
town
and
on
top
of
both
clusters,
kgb
is
already
predeployed
and
there
are
some
sample
workloads
and
we
will
work
with
jslb
custom
resource
definition
and
customer
search
definition.
Pretty
much
works
looks
like
like
that.
It's
on
the
index
page,
so
we
have
a
kind
gslb.
B
Obviously
I
have
a
special
api
and
we
have
embedded
ingress
resource
type.
So
basically
it's
kind
of
the
same
ingress
spec
as
a
standard
kubernetes
one.
It's
actually
behind
the
scenes
under
the
hood,
it's
exactly
the
same
goaling
type
and
we
embed
it
into
jsob
and
we
specify
the
pretty
standard
rules,
also
host
and
backend
service.
So
and
the
controller
will
be
monitoring
its
healthiness,
and
on
top
of
that,
we
attaching
the
adding
the
specific
load
balancing
strategy.
B
C
B
B
Demo,
script,
which
continuously
polling
the
associated
fqdm,
so
it's
just
while
true
right
and
it
grabs
the
message
because
it
it
can.
The
simple
application
contains
the
geotech
to
actually
demonstrate
where
it's
located.
So
it's
super
simple,
so
we're
continuously
pulling
it
currently,
every
everything
is
healthy
and
located
in
europe,
as
we
can
see
by
geotech
here.
So
let's
investigate
the
testing
setup.
B
So,
first
of
all
how
kgb
setup
looks
like
so
controller
itself,
core
dns
and
external
dns,
which
is
taking
care
of
routers
history
side
of
configuration
so
effectively
on
delegation?
So
so,
as
you
can
see,
pretty
minimal
footprint
as
of
now,
especially
after
we
got
rid
of
lcd
operator
and
lcd
specialty,
clustered
part
so
for
testing
workload.
So
we
are
running
in
test
gslb
namespace,
a
special
workload
which
is
like
standard
info
which
exactly
returns.
This
response
with
a
is
a
geotech
and
we
have
jsobs
so.
B
To
the
ones
that
I
showed
on
the
index
page
so
again,
failover
test
kgb,
I
o
is
the
main
cost
backend
service,
which
we
are
running
in
a
testing
namespace
of
testgsob
here
and
failover
strategy,
and
we
are
pinning
european
cluster
as
a
main
one
before
the
failure
occurs.
So
in
case
of
some
malfunction
it
will.
It
should
be
failed
over
to
african
one
to
the
cape
town,
so
in
in
run
time.
B
B
Now
we
will
have
in
a
edible
setup
that
we
are
running
as
a
city
10
lb.
So
if
we
dig
this
nlb,
you
will
see
this
addresses
and
that's
exactly
the
ones
that
are
getting
populated
is
in
dns
by
hgb.
So
you
pretty
much
can
dig
right
now
and
they
are
identical.
So
basically,
currently
our
code
is
running
and
we
are
pointing
to
european
cluster.
B
If
we
go
to
cape
town
so
just
to
verify
that
we
are
in
cape
town,
we
in
africa,
we
will
see
that
we
are
running
exactly
the
same
setup.
So
without
any
modification,
it's
the
same.
Spec
and
both
clusters
are
returning
consistent
responses.
So,
as
you
can
see,
this
african
cluster
also
returns
a
dns
response,
which
consists
ip
addresses
of
european
cluster,
where
workload
is
healthy
and
which
is
labeled
as
a
main
one.
C
B
Yeah
so
geoattack
it
is
specified
at
the
very
beginning
of
deployment
of
the
cluster.
So,
for
example,
if
you
look
in
every
european
kgb
configuration
right
when
you
it's
basically
calm
values,
so
we
specify
in
geoattack-
and
we
specify
geotext,
to
talk
to
and
in
case
of
in
case
of
african
configuration,
we're
doing
exactly
the
same
advice
versus
the
right
cluster
geotech
as
a
one
that
we
label
the
cluster
with
and
external
gtx.
The
top
two
is
european
one,
so
we
solve
them
and
the
rest.
B
B
So
what
about
to
happen?
Gslb
should
detect
unhealthiness.
This
is
a
reconsider.
The
next
reconciliation
loop,
so
as
you
can
see
the
limitation
of
the
ns
protocol,
so
we're
running
like
dns
dtl
30
seconds,
we're
also
running
some
reconciliation
loop
on
top,
so
there
will
be
some
five
or
streets
during
the
failed
level.
B
B
A
A
B
B
Usually
our
clusters,
like
we
are
controlling
them
with
rancher
centralized
way.
So
there
is
no
problem
to
spin
up
a
new
pair
of
clusters
for
a
team
and
they
will
fully
own
it,
but
sometimes
we
need
a
multi-tenancy
and
kgb
is
actually
not
ready
for
it
right
and
basically
yeah
if
failed
over
back
to
switch
back
to
the
main
customer.
B
So
now
we
are
in
europe,
so
everything
is
expected,
yeah
so
and
to
have
like.
If
we
go
to
the
github,
we
pretty
much
a
good
activity,
we'll
be
using
github
issues
as
a
not
just
like
the
reporting
bus,
but
also
doing
a
milestone.
So
we
have
quite
a
amount
of
plans
outstanding
months,
for
example,
how
to
implement
more
complex
strategies.
So
currently
it's
a
failover
and
a
round
robin.
B
Yeah,
so
basically
it
is
pretty
much
the
same
here.
In
this
example,
we
just
operating
several
applications.
Several
services
in
backhand
right
so
just
to
demonstrates
the
statuses
like
non-existing,
unhealthy
and
front-end,
which
is
skeletal
ready
and
a
round-robin
strategy
yeah
this
one
additional
controls
over
the
specific
stuff
like
dns
detail,
for
example,
if
you
want
to
make
it
shorter
or
longer,
so
it's
all
available
yeah
and
for
actually
I
can.
I
can
show
the
round
robin
run
time.
B
It
should
return
only
half
of
an
array
and
then
return
back.
So
while
it's
converging
yeah
so
the
next
step
for
us,
would
we
figure
out
how
to
implement
more
advanced
load?
Balancing
strategies
like
we
do
not
have
a
you
know
urgent
business
need
for
that,
like
these
two
reliable
strategies
separately
enough
as
of
now
for
us,
but
from
community
standpoint.
We
definitely
want
to
implement
something
like
more
interesting
like
geographically,
where
geographically,
like
returns,
the
closest
dns
response,
for
example,
poses
to
the
requester
and
all
that
stuff.
B
So
we
are
thinking
of
idea
of
writing.
Some
advanced
custom
coordinates
plugin,
which
is
like
aware
of
situation
more
and
can
modify
dns
responses
on
the
fly,
but
currently
it
is,
it
is
nice
it
can
do
its
job,
but
it's
pretty
much
if
you,
if
you
get
to
these
dns
and
points
right,
that's
how
it
works
in
the
back
end.
B
The
controller
dynamically
populates
this
dns
and
points
here
on
this
kind
and
cordinas
reads
it,
and
according
to
the
strategy,
but
list
is
a
specific
ip
addresses
and
obviously
it
has
its
limitation.
It's
enough
for
basic
load,
balancing
strategies,
one
I
demonstrated,
but
it's
not
enough
for
something
more
advanced,
like
weighted,
load,
balancing
or
again
geographically
geographical
locality,
because
it's
not
enough
dynamic
fear
right.
B
B
B
He
approached
us
he's
a
very
technical
question
regarding
kgb
and
it
looks
like
we
are
going
to
have
very
nice
collaboration
in
regards
of
integration
to
openshift,
so
yeah
looks
very
promising
and
we
definitely
have
some
some
plans
regarding
regarding
strategy.
So
here
pretty
much
look
in
the
issue,
so
we
want
to
add
the
topology
some
manual
weighted
and
consistent
round-robin,
because
currently
it's
pretty
much
random,
so
yeah.
B
B
B
So
one
of
the
main
goals
of
kgb
is
actually
to
give
development
team
a
power
over
global
load,
balancing
right
so
instead
of
standard
http
checks,
we
utilizing
both
probes,
which
are
defined
by
application
teams
so,
and
the
strategy
is
describable
by
a
simple
crd,
but
sometimes
like
it's
a
little
bit
overhead
to
add
yet
another
crd
into
helm,
charts
and
we
have
multiple
teams.
So
that's
why,
and
it
was
also
kind
of
a
community
request
for
modern
reality
project.
B
For
this
specific
congrats
referenced
it
and
you'll
close
the
loop
this
way.
So
basically,
application
teams
are
even
not
required
to
control
yet
another
crd.
They
can
pretty
much
utilize
a
standard,
ingress
visa
couple
of
additional
annotations
and
the
global
load
bouncing
will
work
for
them.
Control
controller
will
take
care.
A
B
B
A
B
C
B
I'm
not
sure
if
I'm
familiar
with
cis,
but
generally
how
it's
totally
different
from
any
kind
of
standard
load,
balancer.
So
the
two
things.
So
it
doesn't
pass
the
traffic
through
itself.
It
utilizes,
so
it
basically
works
purely
over
dns
and
it
is
a
layer
of
internal
cluster
resources.
So
it
doesn't
employ
any
standards
in
hdb
checks.
It
uses
the
port
line
as
an
urgent
check
tool
to
make
a
balancing
steering
decision
and
start
to
open
source.
C
A
C
C
B
C
Yes,
multi-cluster,
it
would
be
a
great
place
to
find
you
all
and
I
I
look
forward
to
seeing
it
used
in
at
scale
and
production
and
getting
some
more
feedback
on
this.
I
think
it's
going
to
be
a
great
addiction,
a
great
addiction.
I
almost
said
addition
to
the
cncf
and
to
you
know
just
to
the
open
source
communities.
This
is
really
a
very,
very
interesting
project,
so
I
will
be
definitely
following
it
along
closely.