►
From YouTube: OCB AMA on K8GB - Kubernetes Global Balancer with Yuri Tsarev (Absa) and Paul Morie (Red Hat)
Description
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'll get an intro to K8GB from Yuri Tsarev (Absa) & we'll leave time for 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
need
of
global
load
bouncers
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
globe
bouncers
from
scratch,
but
this
gold
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
it's
coined
from
korres
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
readiness
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
global
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
rely
on
environment
dns.
For
example,
we
call
it
hdns
it's
route,
53
for
example,
or
infoblox
in
our
own
print
scenario
or
ns1,
as
we
have
another
integration.
B
So
from
implementation
standpoint
we
use
the
operator
is
the
sdk
and
it
works
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
unions
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
lcd
cluster
and
associated
xd
operator,
to
actually
populate
a
local
lcd
database
dynamically.
So
external
dns
would
read
information
from
dynamically.
B
B
So
it
worked
like
out
of
the
box
view
the
last
community
procedure
here,
but
it
had
quite
a
amount
of
reliability
and
maintainability
problems
for
so,
for
example,
a
cd
operator
is
dropped
by
community
completely
at
city
itself,
and
it
wasn't
working
reliably
enough.
So
you
know
long
running
clusters.
We
were
finding
at
cd
in
a
degraded
state
from
time
to
time,
so
it
was
a
problem
for
kgb
reliability
itself.
B
So
that's
why,
in
a
recent
version
we
dropped
that
cd
and
lcd
operator
compre
completely
and
we
replaced
it
with
a
core
dns
build
with
a
custom
kubernetes
crd
plugin
that
we
developed
recently
so
core
coordinates
in
our
case
can
read
information
directly
from
the
innocent
point.
I
will
show
everything
like
in
in
a
demo
how
it
works.
B
B
We
using
advanced
reference
setup
that
I
will
show
you
today
on
top
of
two
geographically
dispersed
gas
clusters
and
ns1
as
our
future
integration.
We
are
very
close
collaboration
with
these
guys.
They
are
amazing
and
we
have
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
hdb,
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.
B
B
B
One
is
in
europe
and
dublin
another
one
in
africa,
cape
town
and
on
top
of
both
clusters,
kgb
is
already
pre-deployed
and
there
are
some
sample
workloads
and
we
will
work
with
jslb
customer
resource
definition
and
customer
service
definition.
Pretty
much
works
looks
like
like
that.
It's
on
the
index
page,
so
we
have
a
kind
jslb.
B
Obviously
I
have
a
special
api
and
we
have
embedded
ingress
resource
type.
So
basically
it's
kind
of
the
same
ingredient
spec
as
a
standard
kubernetes
one.
It's
actually
behind
the
scenes
under
the
hood.
It's
exactly
the
same,
go
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
adding
the
specific
load
balancing
strategy.
B
B
Demo
script,
which
continuously
pulling
the
associated
fqdn.
So
it's
just
while
true
right
and
it
grabs
the
message
because
it
it
can.
The
simple
application
contains
the
geotag
to
actually
demonstrate
where
it's
located.
So
it's
super
simple,
so
we
continuously
pulling
it
currently,
every
everything
is
healthy
and
located
in
europe,
as
we
can
see
by
geotag
here.
So
let's
investigate
the
testing
setup.
So,
first
of
all
how
hgb
setup
looks
like
so
controller
itself,
core
dns
and
external
dns,
which
is
taking
care
of
router's
history
side
of
configuration
so
effectively.
B
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
special
workload,
which
is
like
standard
info
which
exactly
returns.
This
response
with
a
is
a
geotech
and
we
have
psobs
so.
B
To
the
ones
that
I
showed
on
the
index
page
so
again,
failover
test
kgb
io
as
a
main
cost
backend
service,
which
we
are
running
in
a
testing
name,
space
of
test,
gsob
here
and
failover
strategy,
and
we
are
pinning
european
cluster
as
the
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
B
B
B
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
helm
values,
so
we
specify
in
geotech-
and
this
is
a
fine
geotext
to
talk
to
and
in
case
of
in
case
of
african
configuration,
we're
doing
exactly
the
same
advice
versus
right
quarter,
geotech
as
a
one
that
we
label
the
cluster
with
and
external
gtx.
The
top
two
is
european
one,
so
we
slope
them
and
the
rest.
B
B
B
A
A
B
B
Usually
our
clusters
is
like
we
are
controlling
them
with
a
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
you
need
a
multi-tenancy
and
kgb
is
actually
not
ready
for
it
right
and
by
the
way
yeah.
If
I
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
we
have
like
if
we
go
to
the
github
with
pretty
much
the
good
activity
we'll
be
using
github
issues
as
a
not
just
like
the
reporting
bugs,
but
also
doing
a
milestone.
So
we
have
quite
a
amount
of
plans,
outstanding
ones,
for
example,
how
to
implement
more
complex
strategies.
So
currently
it's
a
payload
and
a
round
robin.
B
Robbing
yeah,
so
basically
it's
pretty
much
the
same
here.
In
this
example,
we
just
operating
several
applications,
several
services
in
backhand
right
so
just
to
demonstrate
the
statuses
like
non-existing,
unhealthy
and
front-end,
which
is
skeletal
already,
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.
B
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
separate
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,
codings
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.
The
controller
dynamically
populates,
this
dns
and
points
here
on
this
kind
and
cordinius
reads
it,
and
according
to
the
strategy
populace,
is
a
specific
ip
addresses
and
obviously
it
has
its
limitation.
B
A
B
B
You
probably
know
him
a
very
nice
person.
He
approached
us
is
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
So
that's
why,
and
it's
also
also
kind
of
community
request
from
admin
reality
project
we
added
ability
to
add
the
specific
hb
annotations
on
top
of
standard
congress
controller
with
us.
The
the
same
information
as
we
specify
in
spec,
so
like
strategy
type
and
geotech
in
case
of
failover
controller,
would
pick
it
up
and
create
gslb
automatically.
B
For
this
specific
congress
reference
it
and
we'll
close
the
loop
this
way,
so
basically
application
teams
even
not
required
to
control
yet
another
crd.
They
can
pretty
much
utilize
a
standard
congress
with
a
couple
of
additional
annotations
and
the
global
load
bouncing
will
work
for
them.
Control
controller
will
take
care.
A
B
B
B
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
standard.
Hdb
checks.
It
uses
spot
lightness
and
very
nice
check
tools
to
make
the
balancing
steering
decision
kind
of
open
source.
C
A
C
C
B
B
C
Yeah
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.