►
From YouTube: Episode 33: eBPF KPNG proxying w stoycos.
Description
Join us with andrew stoycos to go over our later addition to the KPNG family, the eBPF proxy !!!
B
B
A
B
To
get
tell
him
to
get
out
of
the
meetings,
whatever
meeting
he's
in
leave.
Okay,
where
are
you
you're
here
right?
This
is
a
soup.
This
is
an
exciting
show,
because
we
we
haven't
done
a
kpng
update
for
a
couple
episodes
so
for
folks
that
don't
know
about
it.
Kpng
is
this
new
back
end.
It
was
originally
written
by
mikhail
cluseau,
and
then
we
kind
of
adopted
it
as
a
sort
of
a
community
and
we've
taken
it
all
over
and
we've
added
all
these
back-ends
to
it.
B
B
A
B
A
B
Whatever
you
want,
it
was
pretty
bad,
okay,
so
we'll
I'll
edit,
that
out
later
or
whatever.
That
was,
if
it
showed
up
in
the
comments
anyways
here
we
go
so
soycast
made
a
ebpf
backend,
which
is
I
mean
this
is
really
exciting.
Mikhail
did
the
nft
one
originally
right
so
for
folks
that
are
new
to
the
coupe
proxy
there's
different
backends
that
write
proxying
rules
and
that's
how
the
service
ip
addresses
wind
up,
getting
forwarded
to
pods
right
in
any
kubernetes
cluster
and
stoichis.
A
B
So
let
me
fetch
the
latest
here
and
then
to
run
k
png.
It's
really
easy
to
test
it
out
for
folks
that
want
to
try
it
all
you
got
to
do
is
just
this
hack
like
this.
We
just
got
to
run
this
we'll
see
if
it
works.
We
did
a
very
quick
test
of
it
earlier.
It
looked
like
it
wasn't
working,
but
we'll
we'll
double
check,
and
I
think
the
other
reason
is
because
of
my
system,
but
we
can
figure
that
out.
A
Here
it
is,
and
the
interesting
thing
on
the
control
plane
side
of
things
with
kpng
is
the
nft
back
end
does
implement
this
kind
of
full
state
model
where
anytime
there's
an
update
to
services
or
endpoints.
You
get
the
full
state
of
the
world,
so
it's
essentially
a
level
driven
controller,
whereas
the
iptables
backend
as
it
stands
right
now
implements
more
of
a
event-driven
controller
where
you're
responding
to
endpoint
and
service
events-
and
you
know
kubernetes-
writing.
Kubernetes
controllers
is
kind
of
like
you
know,
the
the
suggested
way
is
to
always
do
it
level
driven.
A
B
Yeah,
so
so,
there's
two
exactly
so,
there's
two
ways
to
build
one
of
these
so
as
this
comes
up
we'll
put
this
on
the
side
over
here,
so
this
is
coming
up
and
then
yeah,
okay,
so
it's
coming
up,
and
so
so
when
we
run
test
d2e
dot
sh,
it
creates
a
kind
cluster
inside
that
kind
cluster.
It
disables
the
coupe
proxy
right
and
because
you
can
run
kind
with
the
disabled,
coop
proxy
and
then
that
comes
up
and
then
it
installs
kpng
as
an
alternate
coupe
proxy
afterwards.
B
We'll
see
that
in
a
second
dimitri
I
see
you
here
since
this
is
a
live
stream.
It's
a
usually
a
camera's
on
live
stream,
so
you
gotta
hang
out
with
us,
but
I'm
really
glad
you're
here,
because
dimitri
is
writing.
The
dimitri
is
writing
the
coup
proxy
updates
for
the
windows
kernel
space
right.
So
we
have
this
one
here.
B
Maybe
he's
even
got
an
update
for
us,
so
we
have
this
other
one,
which
is
the
windows
kernel
space.
So
I
made
this
mr
originally
and
now
dimitri's
kind
of
taking
it
over
and
this
one
I'll
show
you
all
what
stoichis
is
talking
about
in
here.
So
this
is
the
windows,
implementation
and
yeah,
so
we
can
see
here
set
service
right.
You
can
see
here.
B
A
B
B
Okay,
anyways.
The
point
is
that
wrong
or
right?
This
is
the
way
the
iptables
proxy
works
in
the
current
kubernetes
and
also
how
it
works
in
kp
g,
because
basically
ripped
all
that
code
out
and
got
it
working
in
kubernetes,
but
that's
not
how
kpng
was
really
designed
to
be
run.
The
way
it
was
really
designed
to
be
run
is
that
you
take
the
entire
state
space,
and
then
this
is
what
you're
calling
a
level
driven
controller
is.
That
is
that
is
that,
like
is
that
yeah?
Okay,
I
can
show
what
I'm
talking
about.
B
A
B
C
B
B
C
A
A
B
The
deleted
the
existing
coupe
proxy
and
then
we
loaded
the
compiled
images
that
have
this
from
stoichus's
fork
in
it
and
then
this
sort
of
came
up,
but
let's
see
coop
ctl
okay,
so
we
can
see
we
see
yeah
we
can
see.
We
can
see
that
these
are
all
in
crash,
that
back
off.
So
let's
look
at
the
kp
and
g,
so
the
a
regular
coupe
proxy
right
has
these
running
on
every
node
right,
so
coupe
gtl
get
nodes.
We
can
see
here
that,
like
there's
three
nodes
here,
it's.
B
D
A
D
A
A
A
A
B
A
B
So
this
container
for
folks
that
are
new
to
kpg
this
container
as
andrew
said
I'll,
say
it
again.
This
thing
is
just
watching
the
api
server.
So
this
is
this
part
over
here
right.
It's
watching
the
api
server
and
it's
just
saying:
hey
like
what
services
and
what
endpoints
are
there
because
I'll
write
those
networking
rules
for
you,
that's
what
the
regular
that's
half
of
what
the
coup
proxy
does.
The
other
half
is.
It
goes
and
it
writes
ip
tables
rules
on
your
node
right.
B
A
A
B
D
A
B
A
So,
let's
check
out
what
kernel
my
machine
is
running
on
running
with,
as
I
said
before,
I'm
on
5.18.6,
okay,
coming
from
jay's
4.15,
so
pretty
old,
there's,
probably
a
lot
of
dependencies
missing
on
that
old
of
a
kernel
so
and
and
remember.
This
is
kind
of
a
funny
deployment
scenario
for
evpf
program.
A
So
if
you
don't
know
what
ebpf
programs
are
there's
a
bunch
of
great
resources
online,
I'm
happy
to
point
them
out
to
you,
but
essentially,
when
you
run
evpf
programs
like
on
docker
containers
or
within
docker
containers,
really
at
the
end
of
the
day,
all
that
matters
is
the
kernel
version
on
your
underlying
system.
So
that's
why
this
is
important,
so
it
failed
to
spin
up
on
jay's
cluster.
But
let's
check
out,
if
things
are
working
over
here.
A
B
A
A
A
A
A
B
A
So
why
don't
we
sounds
you
might
just
okay
anyways
go
on?
Why
don't
we
check
out
these
back
ends?
We've
been
talking
about
for
a
while.
Obviously
here
we
have
ip
tables
ipvs,
nft
user
space,
lin
blah
blah
blah
jay
showed
earlier
in
this
program.
How
iptables,
for
example,
implements
sort
of
a
let's
see?
Where
is
it
in
here?
I
can't
even
remember
sort
of
a
yeah
right
here.
Service
delete
service,
it's
essentially
event,
driven
bpf.
B
B
A
Yep,
essentially
it
isn't
the
smartest,
but
it's
a
true
level
driven
controller
and
thankfully
kpng
has
also
given
us
some
libraries
to
help
out
with
you
know,
figuring
out
what
we
need
to
do
on
each
reconciliation
cycle.
One
of
these
libraries
is
this
light
diff
store
library
which
essentially
just
allows
you
to
figure
out
if
something
has
changed
in
a
service,
a
given
service
or
a
given
endpoint
on
every
reconciliation
cycle.
So
that's
really.
Nice
makes
things
pretty
easily
and
we're.
B
A
C
A
So
diff
store
is
kind
of
the
core
one.
I
think
mikhail
was
using
that
to
prototype
a
bunch
of
different
things
with
different
data
structures
and
then
light
discord
is
actually
what
he
intended
to
be
used
by
us.
So,
let's
check
out
this
test
and
and
see
what
it
does.
Basically,
we
create
a
new
light,
diff
store
and
the
first
thing
we
do
is
we
store
two
entries:
it's
basically
a
map
so
key
a
value,
alice,
key
b
value
bob
and
what
light
diff
store.
A
B
Yeah,
so
exactly
so,
this
is
a
way
of
for
for
some
history
here.
The
way
that
the
way
the
kernel
space
coupe
proxy
works
is
it
basically
in
memory
calculates
the
difference
every
single
time,
a
change
happens
and
says:
has
the
network
state
space
changed
or
not?
And
if
so,
it
has
a
little
data
model
in
memory
that
it
modifies
and
it
sets
a
changed
bit
and
then
every
like.
B
I
don't
know,
I
think
it's
like
every
second
or
something
the
existing
kernel
space
coupe
proxy
goes,
and
it
looks
at
that
state
space
and
it
rewrites
networking
rules.
So
what
what
the
way
kp
g
handles
this
sort
of
similar
problem
of
calculating
the
differences
when
you're
using
this
proxy
type,
there's
two
types
of
proxies,
as
in
kpng,
as
we've
shown
that
when
you're
doing
the
type
that
actually
reads
the
entire
networking
state
space
every
time
you
have
this
problem,
which
is
that
you're
reading
in
the
entire
state
space.
B
So
you
need
to
calculate
a
diff
somehow,
because
you
have
the
entire
state
space
a
minute
ago
and
now.
So
this
is
the
tool
that
mikhail
put
into
the
project
to
allow
us
to
calculate
this
diff.
So
you
write
right
right
right
right,
you
hit
a
reset
and
then
you
right
right
right
right
right
now
you
can
see
the
difference
between
the
first
batch
of
rights
and
the
second
batch
of
rights.
A
A
Because
diff
store
was
essentially
when
I
asked
michael
about
this
at
this
store
was
like
his
attempt
to
just
prototype
things,
and
you
know
here
he
used
a
different,
a
couple:
different
data
structures
and,
in
light,
diff
store,
it's
literally
just
using
a
b
tree
at
its
core.
I
believe
so,
if
we
go
in
it's.
A
A
I've
been,
I
had
to
figure
out
how
to
use
a
light
disk
store
in
the
evpf
backend.
So
that's
where
we're
at,
but
this
is
kind
of
cool.
So
I
can
see
what
this
test
is
failing,
because
I
forced
it
to
fail,
but
you
can
essentially
see
we
add
two
new
entries,
one
for
a
corresponding
to
a
value
of
alice,
one
for
b,
corresponding
to
a
value
of
bob
and
then,
when
we
print
map.updated,
we
can
see
that
those
two
entries
were
added
so
put
this
in
the
context
of
services.
A
B
B
A
So,
there's
a
lot
going
on
here.
Basically,
I
started
by
looking
at
what
psyllium
has
kind
of
done
and
seeing
like
what
we
had
to
do
to
remove
it
from
their
control
plane.
So
that's
what
we've
done
here
right
now,
what
I'm,
showing
you
is
still
in
the
control
plane
side
of
things
we're
not
in
the
data
plane
yet
so
in
the
control
plane.
A
A
Yeah,
it's
essentially
it's
what
I've
used
to
reference
like
an
eb
evpf
controller
right,
so
it
holds
some
things
like
references
to
our
bpf
programs,
ip
family
and
then
the
most
important
thing
is.
It
holds
basically
an
in-memory
cache
of
what's
going
on
in
in
our
services
and
endpoints
world
right,
yeah.
B
A
D
A
All
we're
doing
is
we
make
a
key
that's
made
out
of
the
namespace
name
for
a
service.
Namespace
name
is
literally
just
the
name
of
the
service
and
the
namespace.
It's
in,
so
it's
unique
the
specific
port
for
that
service,
so
a
single
service
could
have
multiple
entries
in
multiple
ports
and
then
the
protocol
for
that
service
right
for
that
service,
endpoint
mapping.
A
A
A
B
A
A
Yeah
we'll
go
look
at
that
a
little
bit
later,
but
the
way
that
my
go
program
confers
with
my
c
program
is
with
this
concept
of
ebpf
maps.
Okay.
So
basically,
what
I
do
in
sync
is:
I
load
those
ebpf
maps
with
the
data
that
represents
my
current
services
and
endpoints,
so
this
is
for
deleting.
But
if
we
look
at
all
of
the
entities
that
were
updated
since
the
last
iteration,
we
are
then
going
to
add
corresponding
entries
for
a
given.
What.
A
A
B
D
A
A
B
I
know
yeah,
so
I
mean
this
is
a
full
state,
yeah
yeah.
This
is
full
state,
so
there's
no
periodic
anything
in
the
in
the
I'll
say
it
again,
because
there's
a
lot
of
new
people
here,
I'm
sure
that
I'm
going
to
watch
this
in
the
old
in
the
existing
kernel,
space
cube
proxy
and
in
the
kpng
iptables
implementation,
we
do
periodic
syncs,
in
other
words,
there's
a
data
structure,
that's
sitting
there
and
that's
figuring
out
what
the
differences
are
in
memory
and
then
every
like
one.
B
Second,
if
there's
a
if
there
is
a
difference
in
the
way
in
the
pods
or
the
services
in
all
of
kubernetes,
that
needs
to
be
written
out
so
that
you
can
write
new
iptables
rules
like
a
pod
got
deleted
and
a
new
pod
came
up
or
a
service
got
created
or
whatever
those
new
ip
tables
rules
are
written
and
there's
a
thing.
That's
periodically
running
that
so
there's.
A
D
A
Me
so
the
idiots
like
me
could
copy
people,
no,
no,
this.
It
made
sense.
It
made
sense
then,
but
it
has
made
it
a
bit
confusing
for
people
who
are
new
coming
in
to
write
a
new
back
end
like
I
want
to
standardize
this
like
I
want
to
do
it
either
with
a
set
service
or
with
a
generic
callback,
full
state.
Every
time
sort
of
thing
right.
B
B
A
A
Is
basically
like
a
rule
brace
proxy
or,
as
you
write
more
rules
like
for
every
packet,
you
essentially
have
to
loop
through
all
the
rules
and
make
a
match
or
not,
and
you
interact
with
it
in
in
user
space
right
with
just
a
simple
iptables
command
and
it's
handling
natting
interacting
a
contract.
It's
handling
a
lot
of
things.
A
B
A
A
B
B
A
A
A
D
A
We
need
to
fix
that
now
we're
we're
in
a
tools
container
and
we
can
use
bpf
tool
to
see
what's
going
on
on
our
system.
So
if
we
write
bpf
tool
map
we
can
see,
we
have
three
different
copies
of
both
a
service
map
and
backend
map,
and
this
is
how
we
share
information
between
our
kernel
and
our
user
space
program,
and
you
can
also
do
really
interesting
things
like
dumping
apps,.
A
A
The
reason
we
see
all
three
of
those
in
kind
is
because,
at
the
end
of
the
day,
all
these
bpf
programs
are
running
on
a
single
node,
so
there
is
no
concept
of
of
name
spaces
for
bpf
programs.
Yet
so,
therefore,
we
see
everything.
It's
just
an
unfortunate
fact
of
running
this
in
kind.
At
least
I
haven't
found
a
solution
yet
around
it.
Does
that
make
sense.
D
A
B
B
Okay,
so
those
are
that's
running
on
node
three,
so
I
have
three
nodes
in
my
cluster
and
I've
got
inside
of
the
third
node
in
my
cluster
I
have
two
ebpf
maps
that
have
been
written
for
me
by
stoichis's
back
end.
One
of
them
is
called
the
service
map.
The
other
is
a
back
end
map
and
each
one
of
those
maps.
It's
a
bunch
of
bindings,
a
bunch
of
networking
rules
in
it
now
you're
going
to
show
us
all
the
networking
rules
so
which
one
are
we
going
to
do?
First,
133
again,.
A
B
A
Yeah
we
can
even
try
to
well,
we
don't
know,
that's
fine,
no
yeah,
just
just
keep
going
cool.
So
that's
how
we
see
our
maps.
Let's
now
go
talk
about
the
actual
bpf
program.
That's
doing
all
the
fun
data
plane
bits.
So
that's
down
in
the
bpf
directory
and
it's
titled
c
group
connect
for
dot
c.
This
is
where
all
the
magic's
happening
and
remember
those
maps.
We
were
just
talking
about.
Well,
here's
where
they're
defined.
We
have
our
v4
service
map
and
v4
back-end
maps.
A
B
B
A
A
B
A
Whatever
so,
I'm
not
gonna
go
super
in-depth
into
this
c
code
because
it's
not
extremely
exciting.
It's
pretty
easy,
but
I
want
to
talk
about
the
concept
behind
it.
So,
whenever
a
client
on
a
node-
or
in
this
case,
something
in
a
container
on
a
node,
whether
that's
curl
a
go
client,
a
c
client,
we
don't
care
whenever
a
client
tries
to
reach
out
to
an
ip
one
of
the
sys
calls
that
happens
is
a
connect
forces
call,
and
let
me
show
you
how
kind
of
proof
of
that.
A
A
B
A
Okay,
so,
whenever,
whenever
a
client
on
a
linux
machine
kind
of
reaches
out
to
a
server,
a
connect
force
is
called
is
made,
and
whenever
that
connect
forces
call
is
made,
this
bpf
program
is
called
okay.
Does
that
make
sense?
So
here's
where
that
actually
happens
whenever
a
client
tries
to
reach
out
to
something
whether
that's
with
curl
or
any
other
client?
A
A
Now
this
function
sock
four
forward
at
a
high
level
grabs
the
traffic
and
says,
looks
at
the
destination
ip
and
the
port
calling
says:
do
we
care
about
this
traffic
so
90
times
we
don't
care
right.
All
we
care
about
for
a
service
proxy
is
if
the
traffic
is
destined
for
a
vip
and
a
given
port
right.
Does
that
make
sense.
B
A
D
A
Invocated,
whenever
a
connect
forces
call
is
made
and
then
once
they're
indicated,
they
look
at
the
values
in
our
evpf
map,
which
are
basically
a
list
of
vips
and
they
look
at
the
actual
destination
ip
of
the
packet
and
they
say
is
the
destination
ip
of
the
packet.
One
of
these
vips
I
know
about,
does
that
make
sense.
Okay,.
B
So
you're
really
so
you
so
it's
a
generic
api
call
to
the
kernel
yep.
You
just
make
a
generic
call
to
the
kernel
and
you're
saying
that
here's
a
map,
here's
a
map
of
vips
and
then
that
data
is
sent
to
the
kernel
and
because
ebpf
was
written
to
deal
with
networking.
It
knows
how
to
see
with,
for
that.
Ebpf
was
written
to
read
these
ip
address
rules.
A
This
out,
so,
as
I
was
saying
before,
whenever
a
connect
forces
call
is
made,
this
sock
for
connect
program
is
called,
and
then
this
sock
for
forward
program
is
called.
So,
let's
look
at
the
sock,
4
forward
program.
What's
passed
to
the
user.
Here
is
a
bpf
sock
address
and
the
bpf
sock
address
is
whoa.
Look
it's
a
bunch
of
information
about
our
packet,
so
family
ip
address
destination,
ip
address,
etc,
etc.
A
Right
so
now,
in
our
bpf
program
we
make
a
key
and
the
key
literally
looks
at
the
user,
the
the
destination
ip
address
of
the
packet,
the
destination
port
and
a
back
end
slot,
which
were
isn't
super
important.
It's
kind
of
an
internal
subtlety,
and
we
say
we
do
a
look
up
to
our
bpf
maps,
which
is
done
here
and
and
if
we
care
about
that
ip
import,
then
we
go
do
other
other
things.
A
A
The
next
thing
we
do
is
we
look
up
a
back
end,
so
we
know
we
have
a
service
we
care
about,
but
we
need
to
figure
out
which
endpoint
we
want
to
direct
this
connection
to,
and
so
the
first
lookup
we
did
was
to
look
up
and
see
if
we
had
a
vip,
we
cared
about
ie
service.
The
next
look
up
we
do
is
is
to
find
a
back
end
for
that
vip.
A
B
A
B
A
A
And
then
the
last
thing
we
do
is
literally
rewrite
the
destination,
ip
and
port
of
the
packet
and
remember
this
is
the
first
packet
in
a
connection,
and
this
is
happening
before
the
packet
has
even
been
directed
to
the
linux.
Networking
stack
so
we're
kind
of
cheating
like
we're
tricking.
The
linux
networking
stack
into
thinking
that
a
client
is
just
talking
to
a
pod.
So
really
we're
tricking.
A
B
A
B
B
That
you're
you're
inside
the
cluster
network
and
you're
not
writing
any
kind
of
a
you're,
not
writing
any
kind
of
a
forwarding
rule
or
anything
you're,
rewriting
the
packet
and
but
you're
rewriting
it
at
a
point
where
the
packet
has
no
problem
being
routed
to
that
new
place,
because
it
knows
where
it
is
right.
Yeah.
A
A
Really
basic
neogenics
deployment,
so
two
genetics
to
pods
backing
this
service
with
a
cluster
ip
of
1096
one
through
one
one,
one:
five
we
can
go
over
in
to
my
temp
shell,
it's
just
a
temporary
client
pod.
We
can
verify
that
this
works
right.
So
I'm
going
to
curl
the
vip
ta-dah
things
work,
but
it
works,
but
let's
go
check
out.
What's
actually
going
on
like
what
does
the
the
node
see?
That's
what
I
want
to
see.
So
what
node
is
my
client
on.
B
This
is
like
a
personal
like
a
self-affirmation,
okay,
so
james,
it's
good
to
see
you
man,
so
I
just
want
folks
to
realize
the
gravity
of
what
stoic
has
just
showed
us.
This
is
a
kubernetes
dash,
sigs,
slash
kpng
project.
This
is
a.
This
is
very
soon
going
to
be
ebpf,
supported
as
a
proxying
option
in
a
project
that
is
maintained
by
the
kubernetes
community
in
the
in
the
upstream
and
holy
upstream.
A
I
do
my
curl
and
obviously
we
get
a
bunch
of
stuff,
but
let's
look
at
the
first
packet
of
this
connection.
This
is
like
the
coolest
thing
ever
right,
the
first
packet
of
connection.
Let's
look
again
what
what
ip
did?
I
just
curl
1096
131
115
right,
look.
What
the
linux
networking
stack
sees
right.
It
does
not
see
that
ip
anywhere,
all
we
see,
is
10.244.2.3
going
to
10.244.2.2,
it's
literally
seeing
podopod.
That's
it
that's
the
exciting
part.
A
A
You're
such
a
big
nerd,
I
can
see
how
happy
you
are
right,
I'm
a
huge
nerd.
I
actually
found
a
kernel
bug
in
this
and
I'm
gonna
be
posting
a
kernel
patch
try
to
so.
We
also
I've
implemented
some
logging.
So
we
can
see
whenever
our
epf
program
catches
a
packet.
We
can
kind
of
see
what
was
the
backend
address
note.
This
is
in
hex
and
it's
a
network.
B
A
B
A
Yeah
and
that's
the
cool
part-
and
you
know,
cilium-
has
been
doing
this
forever,
but
psyllium,
really,
all
their
code
is
really
tightly
tied
to
their
control
plane
right
and
what
we've
done
here
is
pull
it
out
that
design
and
apply
it
to
the
kpng
control
plane.
So
now
everyone
can
use
it
pretty
easily
right
really
easily
so
yeah.
One
last
thing
I'd
like
to
talk
about
is
we
looked
at
our
c
program.
A
We
looked
at
our
control,
plane
go
program,
but,
and
a
really
interesting
thing
that
I
do
here
is
using
psilium's
evpf
library,
which
is
their
public,
go
evpf
bindings,
basically
which
for
note
they
don't
even
use
in
their
production
code.
It's
kind
of
interesting
I
can
manage
the
compiling
and
loading
of
my
bpf
programs
and
maps
in
go.
That's
a
pretty
powerful
thing
too.
Okay,.
B
B
B
A
A
Yeah,
I
think
we
have
to
actually
that's
probably
one
another
reason
it
was
failing
on
your
machine,
but
if
we
look
at,
if
we
use
llvm
object
dump
on
these
elf
files,
you
can
get
more
information
about
them.
So
remember
our
bpf
program
here
it
is
c
group
connect
four
right,
that's
a
cool
little
tidbit.
I
use
that
so.
B
A
I
don't
have
some
stuff,
but
a
lot
of
it.
They
have
like
scripts
that
build
their
byte
code
on
the
fly
right,
so
they
don't
have
a
go
generate
which
you
know
for
for
everyone's
info.
It's
just
wrapping
clang.
They.
They
literally
have
a
script
that
runs
clang
and
compiles
their
bpf
c
code
into
bikes.
A
No
because
byte
code
is
portable
and
it's
gotten
more
portable,
especially
with
btf
like
okay,
like
the
goal
for
bpf,
is
to
have
compile
once
run
anywhere
by
code
like
and
we're
getting
closer
to
that.
So
that's
kind
of
why
I
included
just
pre-compiled
byte
code
in
here,
but
in
reality
you
know,
probably
for
the
current
state
of
the
kernel
and
the
current
state
of
folks
not
being
on
the
bleeding
edge
of
the
kernel.
It
makes
more
sense
to
build
on
the
fly.
Does
that.
B
You
know
like
a
middle
of
the
road
solution,
is
you
could
put
this
dotto
file
on
like
an
s3
bucket
and
then
you
could
have
a
configuration
thing
in
the
deal
that
said
where
to
pull
it,
pull
the
auto
file
from
or
you
could
have
some
kind
of
a
thing
that
mount.
You
know
you
could
use,
go
bin
data,
my
favorite.
B
A
Yeah,
I
definitely
am
going
to
go
back
and
think
about
how
I
do
that,
but
yeah
anyway.
So
this
library
is
nice,
though,
because
it
allows
us
in
go
in
our
control
plane
world
to
maintain
a
reference
to
our
v4
service
map,
our
v4
back-end
map,
the
two
ppf
maps
we
were
looking
at,
and
it
also
allows
us
to
maintain
a
reference
to
our
program
right,
so
it
it
generates.
These
go
bindings
that
give
us
go
representations
of
our
program
and
maps.
A
B
B
I
just
love
dropping
it.
Look
this
somebody
just
joined
super
late.
I
don't
know
who
you
are,
but
you
missed
the
show,
I'm
sorry
so,
okay,
let's
let's
wrap
up
here.
So
in
summary,
let's
go
back
to
your
stuff,
so
here's
the
wait,
I'm
sure
on
the
wrong
screen,
even
though
I
kind
of
wanted
to
share
that
one
too.
B
A
B
So
now
here's
his
now
he's
generating
all
this
byte
code
right
and
these
are
binaries.
So
he's
got
this
in
the
pr
and
he's
going
to
change
this,
though
somehow
you
could
encode
these
in
gobind
or
whatever
you
want.
I
don't
think
it's
a
big
deal
to
merge
this,
as
is
I'm
just
saying
so.
No,
I
need
to
change
it.
B
Okay,
so
he's
got
these
binaries
and
then
those
binaries
are
so
then
this
backend
sync
says:
okay,
it
receives
the
it
just
receives
the
updated
state
space
and
then
it
uses
the
diff
state
thing
that
he
showed
you
earlier
to
say.
Oh,
I
have
a
new
service,
it's
12.0.0.2
or
whatever.
I
need
to
write
a
new
service
out
so
then
that
thing
decides
to
write
a
new
service
out
and
it
generates
an
ebpf
map
which
is
right
to
an
ebps
map.
That's
already
there
yeah
okay.
B
B
So
so
then
he
writes
a
key
to
the
map
to
update
whatever
the
thing
is
that
he's
updating
and
the
the
ebpf
rule
and
then
next
time
a
packet
comes
in
if
it's
destined
for
one
of
these
cluster
ipvips
right.
So
if
it's
destined
to
this
new
thing
here,
the
before
we
even
hit
the
kernel
that
packet's
ip
address
gets
rerouted
right.
So
you
have
a
packet
diagram
right
so
that
rewritten.
A
B
A
B
B
A
No,
it
thinks
it's
the
pod,
where
the
client
called
the
connect
four.
So
if
you
were
in
a
temporary
client
pod
and
you
curled
a
service,
so
what
if
I'm
coming
in
from
the
outside
world,
if
I
was
doing
like
a
node
port
or
if
I
was
doing
an
external
here's,
some
harder
harder
things,
you
would
hook
into
a
different
bpf
hook
point,
and
that's
like
my
next
one
of
our
next
items
on
these.
That's.
A
Node
port,
yet,
okay,
all
right!
It's
a
lot
harder!
Yeah!
Well,
not
a
lot
harder,
but
you
can't
really
just
trick
the
kernel
anymore,
because
you're
you're
coming
in
and
out
of
a
network,
whereas
here
you're
pretty
much
in
the
same
network
you're
just
defining
fips
right
you're
in
the
cluster
overlay
you're
in
the
pod
network.
Rod.
B
A
A
B
B
B
B
A
B
You
know
this
would
be
a
lot
harder.
We
wouldn't
yeah-
we
wouldn't
be
here
today,
so
all
right
and,
of
course,
to
mikhail
for
building
all
the
kpg
stuff
for
us
to
put
these
back
ends
into
so
all
right
thanks,
everybody
we'll
see
you
all
later
thanks
everybody
for
showing
up
entry
life
like
and
subscribe.