►
From YouTube: CNCF SIG Network 2021-04-01
Description
CNCF SIG Network 2021-04-01
A
Yeah,
some
of
the
april
fool's
jokes
get
so
subtle
that
I
was
sitting
there
reviewing
a
pr
earlier
today.
The
this
particular
contributor
does.
This,
like
you
know,
was
one
of
those
engineers
that
actually
enjoys
documenting
and,
like
writing
things
down,
and
it's
just
what
a
lovely
thing
and
so
consistently
this
this
contributor
will
take
a
well
usually
like
it's
an
animated,
gif
sort
of
demonstrating
the
function
or
the
thing
that's
changed,
and
and
this
time
I
sat
there
looking
at
it
and
finally
figured
out
it's
just
a
static
screenshot.
A
A
A
A
A
There
are,
I
think,
all
the
votes
are
in
in
terms
of
those
who
or
I
guess,
if
I
guess,
if
you're
on
the
call-
and
you
haven't
taken
a
look
at
if
you
don't
aren't
familiar
with
this
project,
please
go
take
a
minute
if
you
haven't
whether
you're
familiar
with
the
project
or
not.
If
you
want
to
just
make
a
remark
or
a
vote
on
the
logo,
for
it,
please
do
indecision
is
awful.
A
And
so
the
I'll
give
a
project
progress,
update
on
behalf
of
a
couple
of
the
contributors
of
the
project
and
vinayak
is
here
with
us
now,
so
he
might
have
another
portion
to
this
update.
There's
been
been
progress
on
the
build
of
nighthawk
for
for
a
binary,
that's
compatible
with
the
base
image.
That's
used
for
the
meshri
project.
A
Those
builds
take
a
couple
of
hours
in
github
or
there's
a
custom.
Github
action
that's
been
written
now.
I
think
those
builds
take
a
couple
of
hours
in
part
because
of
all
that's
included
all
of
envoy's
tool
chain.
That's
included
for
those
builds.
There's
been
a
recent
contributor.
Jubril
gibril.
Are
you
on.
A
Nope
been
a
recent
contributor
that
had
was
trying
to
figure
out
if
they
could
get
nighthawk
on
alpine,
and
so
we
don't
have
I'm
unqualified
to
speak
to
that
so
and
jabril
isn't
here
so
the
last
item,
as
an
update
on
get
nighthawk
is
well.
We
have
a
few
of
these
today,
but
a
maintainer
nomination,
and
I,
for
my
part,
I
had
intended
to
get
to
this
a
bit
earlier
and
that
is
to
get
to
get
an
email
out
about,
in
this
case
about
vinayak
sharma.
A
So,
mr
sharma,
just
to
embarrass
you
a
little
bit
your
your
stewardship
of
the
project
site
and
how
you've
been
giving
accepting
prs
and
giving
direction
to.
I
don't
know
about
five
others
that
work
doesn't
go
unnoticed.
I
think
you've
shown
great
great
intentions
towards
the
project.
The
site
is
coming
along
nicely.
You've.
A
A
That's
fantastic
good,
good,
good,
good
service
mesh
performance,
so
the
next
project
to
rehash
service,
mesh
performance
and
we'll
just
cover
mastery
in
the
same
swoop,
and
that
is
both
of
those
two
projects
have
been
being
advanced
through
the
service
mesh
working
group
they're
both
submitted
for
proposed
for
thanks
to
ken
and
they've
both
been
submitted
for
sandbox
consideration.
This
last
go
round
which
was
well.
It
got
rescheduled.
It
was
a
few
days
ago.
It
was
supposed
to
be
a
few
days
before
that.
A
A
A
So
for
service
mesh
performance,
though,
as
it's
as
the
contributorship
and
the
maintainership
has
grown,
and
it
is
growing,
there's
been
and
as
as
it's
being
proposed
for
adoption,
there's
been
well
a
more
concisely
articulated
roadmap.
I
wanted
to
to
bring
this
up
as
hopefully
just
a
point
of
discussion
and
feedback.
There's.
B
No
thanks
for
this
for
adding
me
to
review
this,
so
I
think
it's
a
really
good
start
as
to
dividing
into
them
suspect
or
publication
participation,
research.
It
covers
different
areas
in
terms
of
roadmap,
so
I
do
have
a
few
items
you
could
add,
so
I
think
some
of
them
are
being
captured
in
the
the
proposal
smp
sandbox
proposal.
B
So
that's
another
thing
we
could
add
here
internally,
we've
been
doing
some
work
to
kind
of
provide
an
effectiveness
of
a
service
mesh,
so
yeah.
So
pretty
much
at
some
point.
Once
we
have
some
definition
there,
I
I'd
be
happy
to
share
as
we
go
forward
yeah.
Some
of
these
things
could
be
added
here.
Yeah.
I
think
I'd
definitely
take
a
look
at
this
a
little
bit
more
and
provide
an
update
to
this
nice.
B
B
A
A
A
One
item
that
I'm
just
reminded
of
in
looking
at
and
thinking
about,
research
is
yeah
how
we're
being
your
assistants
and
specific
and
and
others
that
might
be
interested
and
ken
has
actually
brought
forth.
Some
of
this
as
well
is
so
we've
got
a.
We
were
able
to
meet
with
any
rude,
the
professor
of
at
nyu
and
we
didn't
get
to
the
last
time
we
got
together.
A
One
item:
that's
it's
a
bit
of
an
action
item.
It's
well
does.
Let
me
ask
you
all
if
this
makes
sense,
so
the
you
know
the
the
service
mesh
working
group
it
hasn't
had
had
has
a
number
of
you
know,
small
initiatives
that
have
been
growing
and
growing,
and
some
of
those
like
smp
growing
enough
that
they're
kind
of
you
know
that
they're
as
big
as
it
is
now
do
like,
even
as
we
go
to
and
so
by
the
way.
The
next
topic
here
is
about
maintainer
nominations
and
suku.
A
B
B
A
A
One
of
them
had
studied
a
bit
more
deeply
around
nighthawk
and
it's
kind
of
kind
of
around
get
nighthawk.
It's
it's
all
sort
of
intertwined
some.
The
two
gentlemen
are
I'll
write
their
names
down
I'll
make
an
introduction.
I
had
recent.
I
think
I'd
recently
sent
them
both
the
draft
of
what
that
roadmap
looked
like,
because
they
were
in
part.
I
was
letting
them
know.
Hey
steam
is
building
steam,
is
building
it's
about
time
to
to
jump
in
and
because
they'll
need
some
they'll
need.
A
A
I'm
misspelling
it
and
the
other
one,
the
other
one
done
some
linux
kernel
work
around
networking
nisarg
introduction
is
going.
You
know
immediately,
there's
no,
I
think
they'll
they'll
have
questions.
They
have
questions
that
you
can
help
answer
and
I
can
help
answer
as
well
around
you
know,
I'll
I'll.
Send
you
some
of
their
questions.
I
mean
they'll.
They're
gonna,
want
to
you
know,
scope
a
scope
of
scope
of
the
goal,
scope
of
the
work.
How
closely
can
they
engage.
A
This
call
a
number
of
times,
but
he's
long
been
a
supporter
of
smp
and
helped
shaped
a
few
of
the
well
a
few
of
the
the
initial
roadmap
items
actually
around
open
application
model
and
smi,
and
how
these
three
specs
ohm
smp
and
smi
line
up
so
and
then
otto
vandershaw
is
quite
keen
on
the
spec
he
and
jacob
mum
have
been
are
jacob
sobham.
I'm
sorry,
I'm
calling
him
by
his
github
name
of
google.
A
B
A
A
A
Other
reviews
that
are
open
is
linkades
up
for
graduation.
It's
reviews
and
process.
William
morgan,
who
was
on
last
time,
has
been
really
helpful
with
lots
of
data.
Lots
of
helping
with
making
sure
the
write-up
is
getting
complete.
He's
been
so
helpful
that
I've
heard
from
him
almost
every
day,
she's.
That
team
is
ready,
for
you
know
public
review
and
so
the
the
sig
review
can
the
draft
of
it
will
be
in
your
inbox
later
today
for
your
input,
feedback
approval,
disapproval,
no
problem.
A
E
E
D
E
Right
hi
guys,
I'm
guri,
I
work
as
principal
engineer
for
apps
and
let
me
share
my
screen:
do
you
see
my
screen
guys?
Everything
is
cool
yeah,
so
I
tend
to
keep
like
minimal
sorry
for
that
minimal
amount
of
slides
and
just
to
provide
a
context,
and
then
we
go
right
to
the
live
demo.
So
kgb
was
originated
in
apsa
as
a
totally
open
source
project
from
day
zero
and
the
idea
behind
it
is
to
create
cloud
native
global
service
load,
balancing
solution.
E
Why
we
needed
it
is
pretty
much
our
business
needs
because
so
upset.
First
of
all
is
financial
organization
which
serves
african
continent.
It's
a
south
african
bank
pretty
much
and
the
usual
deployment
pattern
is
to
at
least
two
geographical,
disparate
clusters,
data
centers
and
to
achieve
reliability
and
availability
for
financial
applications,
and
given
that
a
substantial
amount
of
workloads
already
running
on
top
of
kubernetes,
we
needed
something
to
enable
global
global
global
service
load,
bouncing
like
kubernetes,
kubernetes
way
and
cloud
native
way.
E
E
One
of
the
things
that
differentiates
us
from
existing
solution
is
also
absence
of
a
single
point
of
failure.
So
we
do
not
have
anything
any
instance
that
passing
a
traffic
through
itself.
It
just
doesn't
exist
and
we
do
not
have
any
form
of
control
clusters.
So
there
is
no
single
point
of
failure.
Any
of
our
bottleneck,
the
controller
and
operator,
is
getting
deployed
right
to
the
target
target
clusters
where
workloads
are
running.
E
E
The
most
prominent
one
is
a
time
to
leave
right,
ttl
and
how
fast
and
user
customers
are
getting.
The
updates
we
will
see
it
in
the
demo
and
solution
is
designed
the
way
that
is
as
much
er
diagnostic
as
possible,
meaning
that
we
do
not
create
dns
records
in
a
environment
dns
like
crowdfit
history
or,
like
informally,
using
infoblox
or
ns1,
whatever
we
are
only
automatically
configuring
dns
zone
delegation,
which
points
and
redirects
the
the
dns
queries
down
to
our
coordinates
ports,
which
are
integral
part
of
kgb.
E
So
we
are
answering
to
dns
queries
with
our
dns
responses
that
are
dynamically
modified
according
to
the
global
global
load,
balancing
strategy
and
associated
workload
healthiness.
So
from
implementation
standpoint,
we
based
our
solution,
initial
bootstrap
by
operator
framework,
and
we
following
the
recent
upgrades
and
trying
to
keep
up
with
the
project.
So
we
actually
like
switch
to.
We
started
testing
with
the
release
0.6,
where
it
was
quite
a
little
bit
disconnected
from
kit
builder.
E
Now
it's
pure
builder
and
giant
distancing
on
top-
and
we
migrated
to
the
recent
version
and
try
to
keep
up
with
upstream,
is
like
at
least
-1
release
coordinates
is
very
important
part
of
kgb.
So
that's
exactly
the
part
that
provides
the
dns
responses.
External
dns
is
used
to
integrate
with
this
environment,
dns
and
new
infrastructure,
so
like
route
53,
if
you
and
aws
is
one
of
good
examples
of
that.
E
So
it
we
used
to
have
quite
a
amount
of
reliability,
problems
with
city-based
setup
and
lcd
operator
from
coordinates.
Originally
it's
already
deprecated,
so
we
invested
in
developing
just
special
plugging
and
kgb,
currently
consists
of
just
three
components:
the
controller
coordinates
and
external
dns
made
it,
making
it
the
whole
setup
much
more
reliable
and
this
project
drives
only
single
crd
of
kind
gsob
and
that's
it.
E
So
we
try
to
keep
things
as
simple
as
possible
from
a
management
perspective,
oh
from
integration
with
other
projects,
so
we
call
it
tagit,
dns,
it's
environment,
one!
So
we
tested
heavily
like
you
know,
info
blocks
and
route
53.
They
should
be
production.
Ready.
Ns1
is
already
well
very
well
tested.
We
just
do
not
use
it
yet
and
like
our
scale,
but
all
the
tests
are
passing
and
again
potentially
works
for
other
providers.
E
By
is
that
external
dns
provides,
but
we
heavily
tested
only
these
three
and
there
are
another
projects
open
source
projects
that
we
integrated
with
an
admiralty
is
one
of
the
good
examples
where
admiralty
is
used
for
global
workload.
Scheduling
across
multiple
clusters
and
kgb
is
enabling
global
load
balancing
for
this
global
workload.
So
we
have
a
nice
tutorial
there
on
admiralty
project,
page
yeah,
and
we
can
get
straight
to
the
demo,
but
before
that
just
provide
the
context
on
the
demo
setup.
So
I'm
on
a
kgbio
page.
E
E
Yeah,
it's
not
a
so
dina's
zone
is
the
same,
so
everything
like
is
behind
the
same
of
cdm
so
well.
Basically,
I
maybe
can
start
a
demo
to
answer
to
unpack
the
answer
for
a
question.
So
in
the
right
plane
we
will
run
a
test
script
which
is
basically
doing
this
stuff,
like
curling
the
test
application.
E
Already
installed,
so
we
have
exactly
these
three
components:
kgb
operator,
controller
itself,
which
drives
all
the
logic
like
orchestrating.
It
coordinates
to
handle
the
dns
queries
and
responses
and
external
dns.
This
one
is
special
for
router
history,
which
is
deployed
according
to
the
helm,
values
configuration
and
it
is
handling
this
as
on
delegation
automatically.
E
E
Sorry
it
was,
it
was
hell.
Well,
it's
yama's
back
definition.
Is
there
so
our
api
group
for
kgb,
kai
and
gclb
standard
metadata
and
what
we
are
doing
here.
We
have
embedded
ingress
pack
as
a
part
of
giselle
b
spec.
So
it's
a
pretty
standard
ingress
with
specifying
cost
and
associated
service
right
port
and
pass.
So
it's
actually
the
same
ingress
type
in
a
go
link
behind
the
scenes
right.
So
we
just
embed
it
into
this
adjustability
instance.
E
E
E
This
gslb
is
already
deployed
here
as
a
test,
gslb
failover,
and
we
can
see
it
runtime.
What
kind
of
status
does
it
have?
So,
as
you
can
see
exactly
the
same
spec-
and
here
we-
we
have
a
current
cluster
geotech
and
a
healthy
record,
so
it
identifies
healthiness
of
the
of
the
workload
again
transitively
through
through
the
service
and
a
number
of
endpoints.
E
Let's
say
health
cap
addresses,
so
there
is
additional
kind
of
internal
dns,
endpoint
crv,
now
which
we
are
using
this,
the
crd
from
external
dns
project
from
the
crd
source.
So
if
we
get
the
ammo
here
so
you
can
see
that
failover
is
populated
with
this
ip
addresses
and
the
accordions
given
it
has
our
special
crd
plugin.
It
is
capable
to
read
from
this
crd
and.
E
E
So
in
our
edible
less
scenario,
we
have
a
network
load
balancer
like
a
local
load,
balancer
in
which
is
sits
in
front
of
the
workload.
So
it's
like
standard
ingress
engines
deployed
here
in
test
setup
and
we
have
this
associated
and
I'll
be
deployed.
So
if
we
make
a
dick
to
this
nlp,
that's
exactly
these
three
ap
addresses.
So
we
are,
we
are
assuming
the
workload
is
healthy.
We
populating
dns
response
with
a
healthy
network
load
balancer
ip
addresses
associated
with
the
workload.
E
E
E
E
That's
why
we
are
still
hitting
the
open
point
and
we
operating
with
the
dns
ttl
limits
and
currently
ttl
is
30
seconds
plus
some
like
deviation
with
us,
which
associated
to
reconciliation
loop,
and
here
we
already
see
a
switch.
So
there
was
in
case
of
followers,
there
is
small
downtime
and
now
we
are
already
steering
traffic
to
africa,
because
30
seconds
ttl
is
expired
and
we
already
clearing
the
healthy
workload
in
a
secondary
data
center.
E
E
Ip
addresses
of
euro-
and
you
can
see
in
this
demo
querying
loop
that
it's
already
failed
over
back
to
to
europe,
so
there
was
no
downtime,
because
workload
in
africa
and
secondary
was
always
healthy.
So
that's
another
use
case
how
we
can
steer
the
traffic
in
a
controlled
way.
If
you,
if
you
like
to
so
see,
I've
seen
things
we're
doing
like
a
mono,
no
pin
of
the
main
data
center
from
one
to
another,
so
actually
making
some
form
of
global
blue
green.
E
E
E
E
You
know
very
random
ground
robin
over
the
geographical
data.
Centers
and
yeah.
That's
pretty
much
two
basic
strategies
that
we
utilize
in
apsa
and
it's
enough
for
our
business
case
and
definitely
have
some
more
advanced
stuff
in
our
roadmap
and
trying
to
gather
some
feedback
from
communities
the
next
one
would
be
probably
so
something
about
geographical
proximity
and
this
kind
of
things
in
this
case
you'll,
have
to
create
some
advanced
coordinates
plugins
to
modify
the
responsive
zone
fly
according
to
in
the
situation.
E
E
B
E
Well,
we
operate
now
only
two
factors
underlying
both
healthiness
of
the
target
workload
and
the
load,
balancing
logic
that
that's
it
so
from
we
do
not
imply
any
kind
of
end-to-end
health
checks.
It's
it
is
just
readiness
and
liveness
props
and
they
can
be
as
sophisticated
as
application
team
wants
to
be.
So
that's
a
cool
idea
to
provide
the
power
and
control
to
application
team
over
the
global
load,
balancing
for
their
applications.
B
E
E
E
E
So,
okay,
that's
the
that's
the
current
current
way,
how
it
works,
not
sure,
if
maybe
in
future,
we
will
extend
it
to
some
other
crds.
Even
we
will
have
some
advanced
service
mesh
deployment,
but
currently
we
never
actually
like
tested
or
integrated
into
more
sophisticated
from
service,
mesh
and
point
environment.
A
E
A
And
yeah
you're
right,
I
think,
as
you
got
as
you
mentioned
some
things
I
think
maybe
some
road
map
strategies
with
respect
to
geoproximity
geolocation
and
some
advanced
calculations
that
would
probably
probably
require
deep
integration
into
core
dns
yeah.
I
think
that
was
what
I
was
having
a
really
hard
time.
Framing
a
question
around
earlier
was
was
those
types
of
strategies,
so
that
makes
sense
you
know
elegant
in
terms
of
oops
elegant
in
terms
of
how
you're
relying
on-
and
I
guess
it
you
say
it-
you
stipulate
it
in
your
goals.
D
A
E
E
Yeah
for
sure,
that's
how
we
actually
checked
is
pretty
important
part
of
the
project,
because
it's
not
just
installation
it
also.
It
does
also
have
like
important
configuration
points
which
affect
the
load
balancing
operation
further,
so
we
actually
taking
this
initial
taking
the
cluster
with
initial
helm,
installation
so
reinstalling.
E
This
is
configuration
for
us
one
right,
so
we
specifying
geotech
us1
and
we
specifying
the
neighbor.
That's
another
jso
b
enabled
clusters
that
it's
going
to
work
with
here
and
then
like
through
a
convention
or
a
configuration
they
started
to
talk
and
share
information,
also
over
dns
and
the
similar
configuration
it
is
for
africa
right.
So
it's
kind
of
flipped,
so
it's
a
cluster
geotech
and
the
another
cluster
to
talk
to
is
hero.
So
I
already
showed
to
use
this
dns
and
it's
actually
on
the
screen.
E
Yeah
v
populates
a
special
fqdn
kind
of
service,
one
which
is
not
exposed
to
user,
but
it's
just
around
so
clusters
acquiring
each
other
for
this.
This
is
for
this
special
service
of
qdn
and
basically
is
asking
about
the
health
and
health
status
of
associated
workload
under
control
from
another
cluster.
E
A
E
E
E
Actual
question:
yeah,
that's
a
great
question.
So,
by
design
we
are
not
limiting,
we
are
not
limiting
amount
of
clusters
to
operate
so
here
we
have
a
comma
separated
list
right
and
the
round
robin
already
works
out
of
the
box.
But
failover
strategy
is
honestly
not
really
ready.
This
kind
of
work,
but
the
secondary
will
be
not
obvious,
so
we
have
actually
an
issue
in
our
github
to
test
kgb
in
more
more
than
two
cluster
deployments
to
make
our
operation
more
ready
for
the
scenario.
E
E
F
E
E
Thank
you
cool
closing
thoughts,
and
maybe,
while
we
on
the
spec,
it
may
be
worth
to
mention
that
we
have
so.
We
operate
a
single
crd
right,
which
is
pretty
like
convenient
way
to
steer
the
the
traffic,
but
during
adoption
in
apsa,
we
realized
that
even
some
additional
crt
may
be
like
a
little
bit
overhead
for
teams,
given
that
they
already
have
the
established
helm,
charts
they
like
a
new
type
drop-in,
might
be
as
an
overhead
and
plus
operating
on
a
like
pretty
reasonable
scale.
E
So
assuming
your
workload
already
has
standard
ingress,
you
can,
and
it
is
most
probably
the
case
you
can
create
the
annotations
on
already
existing
ingress
or,
like
extends
your
pre-existing
counter
with
the
json
we
strategize
there
and
in
case
of
failovers.
It
will
be
a
primary
geodetic
and
the
controller
and
the
kgb
controller
will
react
to
it
and
will
create
the
gslb
resource
automatically
out
of
the
annotations
and
we'll
we
will
just
link
existing
ingress
with
a
visa.
Jso
b
type
is
the
jso
cr
and
it
will
close
all
this
way.