►
From YouTube: Antrea Community Meeting 07/27/2020
Description
Antrea Community Meeting, July 27th 2020
A
A
A
B
B
I
actually
have
a
really
nice
demo
that
I
prepared
for
the
poster
presentation
for
those
of
you
who
are
interested
in
like
the
internet,
poster
presentation
that
will
be
on
the
30th
and
I
can
send
you
some
information
for
that.
Anyways
just
give
me
one
moment
and
I
can
pull
up
the
video
also
if
the
video
isn't
doesn't
really
work.
When
I'm
sharing
my
screen,
I
have
a
one
drive
version,
so
I
could
share
that
with
you
guys.
But
just
let
me
know
if
there's
any
problems
with
audio
or
anything
like
that.
B
A
A
A
B
B
Well,
every
network
policy
has
the
ability
to
select
the
endpoint
and
for
each
network
policy
there
is
sort
of
a
list
of
selectors
which
have
the
ability
to
select
that
endpoint
either
as
and
applied
as
a
either
as
that
network
policy
could
apply
to
the
endpoint
or
it
could
reference
it
in
egress
or
ingress
role.
So
you
could
see
that
if
you
have
a
very
large
amount
of
network
policies,
then
to
actually
examine
which
network
policies
are
relevant
to
a
certain
endpoint.
B
You
have
to
iterate
through
the
entire
list
of
network
policies,
and
you
know,
as
a
user.
Eventually
that
could
be
a
burden,
so
our
solution
is
rather
simple
and
it
draws
infrared
inspiration
from
some
of
the
other
relevant
networking
plugins
for
kubernetes
and,
as
we've
been
discussing,
the
solution
is
ant.
Ctl,
query
and
sort
of
the
idea
of
ant
cto
query
is
that
it's
a
more
sophisticated
tool
to
track
relevant
resources.
B
B
So
the
way
it
works
you
can
see
from
this
sample
output.
What
the
of
like,
what
the
results
of
a
simple
endpoint
query
are
and
I'll
show
you
the
the
the
whole
demonstration
of
the
tool.
Shortly
after
I
go
over
this.
Given
a
pod
and
a
namespace,
you
are
able
to
see
the
policies
which
apply
to
that
end
point
and
those
which
reference
the
end
point
and
egress
or
an
ingress
rule
yeah.
So
I'll
show
you,
hopefully
the
audio
isn't
as
choppy
as
it
was
before
so
now.
B
C
D
B
B
B
All
right,
so
the
audio
are
the
visuals
coming
out
a
little
bit
there.
But
what
I'm
doing
is
I'm
creating
a
busybox
container
running
with
access
at
the
false,
and
what
we're
going
to
do
is
we're
going
to
see
the
results
of
nctl
query
endpoint
for
both
the
engine
server
and
for
busybox,
with
the
access
label
set
to.
B
A
A
B
B
B
B
Yeah
and
so
that
sort
of
that
wraps
up
a
brief
demo
I'll
be
sending
in
a
longer
demo
to
antonin
shortly
yeah
so
going
on
from
there.
I
talk
about
future
work,
so
some
future
work
that
we're
considering
is
providing
support
for
querying
network
policies,
and
you
can
sort
of
see
that
as
working
like
in
the
reverse
direction,.
B
And
having
more
general
selection,
a
more
general
selection
mechanism
so
that,
instead
of
having
to
just
do
like
a
pod
and
a
name
space,
you
have
the
ability
to
say
like
return
a
list
of
endpoints,
we
also
have
something
some
more
ambitious
visions
that
I
think
might
be
cool
like
using
this,
just
as
like
a
general
policy
filtering
mechanism
for
other
sorts
of
visualization
yeah.
So
that's
how
the
tool
works.
B
A
D
E
B
B
B
Right,
so
you
can
see
that,
like
any
network
policy
is
able
to
reference
endpoint
in
three
different
places.
The
first
is
in
the
actual
pod
selector
like
which,
which
pods
does
this
policy
actually
apply
to,
and
that's
that's
determined
by
the
labels
in
the
pod
selector,
and
then
you
could
reference
an
endpoint
as
an
ingress
rule
which
specifies
a
communication
from
some
pod
and
an
egress
rule,
which
is
the
opposite
to
some
pod.
B
E
E
B
E
A
E
A
C
A
Yeah,
I
think,
steve,
that's
a
great
question,
because
one
could
just
like
write
a
tool
which
would
just
like
connect
to
the
communities,
api
server
and
look
up
like
the
full
list
of
network
policies
and
then
do
some
computation
and
kind
of
like
answer
those
queries
right.
But
that
would
have
required
a
kind
of
like
replicating
a
lot
of
the
logic
that
we
already
have
written
in
the
in
the
entry
controller.
In
a
way.
C
C
A
A
Entry
that
kind
of
stuff
already
existed
right
right.
We
can
quickly
do
those
lookups
because-
and
I
think
another
thing
that
we
didn't
mention
is
we
kind
of
like
want
the
tool
to
also
work
with
the
andrea
specific
network
policies
like
for
different
personas
right,
so
cluster
network
policy
and
the
entry
specific
name
space
network
policy,
so
yeah
the
tool
is
going
to
work
with
those
as
well.
C
I'd
suggest,
maybe,
when
you
submit
this
pr,
I
assume
it's
going
to
come
along
with
some
documentation
and
maybe
put
that
in
the
design
documentation
to
explain
it
to
others
that
follow,
because
I
can
picture
somebody
going
out
there
to
evaluate
andrea
versus
other
cni's
saying.
Oh,
I
see
this
feature
in
there.
That
would
be
valuable.
C
I
wonder
if
it's
in
all
the
other
cni's
too,
but
when
you
go
through
the
the
backing
description
of
your
design
and
the
reasoning
that
went
into
your
decisions,
it
would
become
apparent
to
the
evaluator
that
hey
this
is
andrea,
specific
and
they're
they're
likely
to
have
that
question
in
the
back
of
their
mind.
So
maybe
answer
it
in
design,
docs
documentation
or
both
yeah
sounds
good.
A
E
A
E
F
E
A
G
Okay,
just
one
last
question,
so
I
I
think
I
overheard
that
when
you
deployed
all
those
pods,
the
nginx
pod
that
you
were
deploying
at
the
very
beginning
also
had
the
access
equals
to
true
label.
I
don't
know
if
I
hear
that
wrong
or
but
you
know,
on
the
on
the
get
endpoint
on
the
nginx
pod
on
the
ingress
rule.
I
don't
actually
see
the
part
itself
because
it's
you
know
selecting
ingress
from
the
label.
From
my
understanding
it
should
be
also
selecting
itself.
G
G
B
A
Okay
thanks
everyone
thanks
jake
for
for
attending.
I
know
it's
late,
your
time
and
thanks
for
the
presentation,
we're
gonna
move
to
the
next
topic
on
the
on
the
agenda,
because
we're
a
bit
of
running
out
of
time
here
and
it
was
an
update
regarding
cluster
network
policy
matrix
by
chen,
so
chan,
if
you're
ready.
D
But
I
can
talk
about
the
details
later
and
overload
the
the
proposal
is
to
collect
and
they
expose
the
statist
statistic
state
of
nato
policy
and
when
working
on
this,
I'm
I'm
thinking,
maybe
not
on
not
only
for
andrea
specific
net
policy.
We
could
also
do
that
for
kubernetes
network
policy
because
they
follow
the
same
model
and
the
way
they
just
has
a
diff
a
little
difference
when
enforcing
them
and
so
and
if
we
don't.
D
So,
oh,
it
should
be
good
to
have
it
for
kubernetes
nail
polish
too,
and
the
policy
the
metrics
api
will
be
exposed
by
entry
controller
and
the
entry
controller
will
is
responsible
for
collecting
the
metrics
from
omg
agent
and
solve
it
and
show
it
through
its
methods
api.
Then,
the
monitoring
solutions
and
the
users
can
access
this
state
where
the
entire
controller
metrics
api
and
also
it
could
be
accessed
by
end
cartel
get
metrics
narrow
policy
making
it
easy
to
wield.
D
D
So
if
the
metric
state
is
collected
every
minute,
it
means
that
each
agent
will
report
1000,
metrics
per
minute,
and
the
entry
controller
will
have
to
sum
up:
1
million
metrics
for
100
000,
individual
net
forces
per
minute.
So
this
sounds
no
performance
issue.
When
collecting
and
aggregating
the
data
in
about
scale
but
for
storage.
D
Assuming
we
want
to
process
the
data
to
kubernetes
crd,
then
we
have
to
perform
100
000
api
writing
per
minute.
It
means
one
thousand
more
than
one
thousand
api
writing
per
second
by
average
and
the
even
we
we
consider
make
the
process
make
the
interval
to
up
to
10
minutes.
It
could
be
mean
it
could
mean
more
than
100
acre
writing
per
second.
D
So
I
think
it's
it's
not
a
reason
more
reasonable
to
write
the
state
to
to
possess
the
state
to
kubernetes
crd
and
actually,
the
only
difference
that
we
possessed
is
in
crd
or
way
we
sell
this
api
while
android
controller
is.
There
is
no
difference
from
user
perspective
because
they
all
get
this
data
phone
api.
The
only
difference
is
that
the
data
will
be
lost
or
not
because
if
we
persist
in
crd,
then
after
con
entry
control
restarts,
we
can
reload
the
state
and
keep
counting.
D
As
we
in
the
as
we
can
see
in
the
conjunction
match
flow.
We
only
match
the
one
direction
of
the
session
and
it
always
come
from
it
all.
It
has
always
the
the
the
sender
it
always
matches
the
the
sender's
address
as
the
source
address
and
the
destination
the
receiver
address
as
the
destination
address.
D
So
even
for
the
reply
package
it
will
hit
by
this
rule,
but
we
also
see
some
drawbacks
in
this
solution.
First,
the
ct
network
source
adjusts
requires
open
with
switch
2.8.
I
think
some
discharge
don't
have
it
yet,
and
the
second
is
in
ingress
table
in
ingress
table.
We
we
are
not
using
destination
address
as
a
condition,
but
the
off
port,
so
it
is
impossible
for
if
we
want
to
continue
using
the
off
port,
it
is
impossible
to
leverage
the
city
network,
source
or
city
network
destination,
and
the
third
one
is
released
by
srika.
D
I
think
he
mentioned
that.
Currently
we
only
need
to
match
each
pack
each
each
session
once
because
the
following
packets
can
just
hit
the
the
generic
flow,
but
if
we
change
the
flow
in
this
way,
the
the
first
packet
of
the
reply
package
will
also
have
to
go
through
the
pipeline
and
match
the
conjunction
condition
flows
so
by
the
overhead
should
be
very.
It
should
be
minor
so,
but
it
is,
it
still
has
some
overhead.
D
So
we
I
had
a
discussion
with
wayne
and
she
proposed
to
possess
the
conjunction
id
to
kind
of
track
labor
and
how
dedicated
dedicated
the
metrics
collection
flows
to
match
the
connect
kind
of
track
label.
The
flow
will
be
like
this.
In
this
way,
we
don't
need
to
change
the
original
narrow
policy
flows
a
lot.
We
just
need
to
resubmit
the
packets
to
another
matrix
collection
table,
and
another
change
is
that
we
need
to
load
this
conjunction
id
to
to
the
contract
label.
D
Then,
in
the
matrix
collection
table
we
could
use
the
connection
label
as
a
match
field,
and
we
we
can
then
use
city
state
new
or
not
new,
as
another
condition
to
collect
to
discrimi
distinguish
the
first
packet
of
our
session
and
the
following
package
and
the
new.
The
the
stats
for
the
new
state
will
be
considered
as
the
session
count
and
the
sum
of
them
will
be
considered
as
the
pac
the
package
card
and
the
sum
of
the
bytes
will
be
considered
considered
as
the
bytes
code
and
after
enter
engine
entry.
D
D
Instead
of
controller
pulling
data
from
agent,
we
I
propose
to
let
anti-agent
push
metric
state
to
api
or
for
entry
controller,
similar
to
the
the
current
way
that
entry
agent
pulls
the
internal
network
policy
from
mj
controller
api,
and
so
in
this
way,
the
same
authentication,
authorization
mechanism
and
even
the
tcp
connection
for
the
internal
network
policy.
Api
can
be
reused.
D
D
So
if
entry
agent
sends
the
whole
stats
to
android
entry
controller-
and
they
are
a
synchronous,
so
it
is,
it
is
very
hard
for
android
controller
to
aggregate
the
whole
stats,
given
that
each
agent
could
restart
itself
and
recess
its
data
individually,
and
so
in
this
proposal
I
want
make
energy
agent
to
calculate
the
incremental
stats
and
only
report
the
incremental
stats
to
energy
controller.
So
the
controller
can't.
Oh
sorry,
this
is
a
type
one.
D
D
And
because
the
polish
it
could
have
the
same
name
and
the
name
space,
so
they
could
conflict
with
each
other.
So
I'm
I
add,
a
type
field
here
to
this
screen
distinguish
from
them
and
the
the
stat
state
includes
package
bytes
and
sessions,
and
the
api
endpoints
doesn't
need
to
follow
the
kubernetes
api
pattern
and
we
can.
We
cannot
follow
it
because
we
want
to
repo.
We
want
to
push
the
stats
in
batch,
not
by
individual
item.
D
Otherwise
it
will
be
api
api
overhead,
so
the
the
mesh
agent
will
report
the
well.
We
report
the
a
batch
of
narrow
process
stats
every
minute.
While
this
api,
then
ap
and
then
entry
controller
will
collect
the
will,
get
this
state
and
then
sum
them
up
and
equilibrate
them
then
store
them
in
cache
in
memory,
and
there
is
another
group
of
api
code,
I'm
calling
them
metrics
api.
For
now.
D
D
D
So
the
api
group
for
now
another
intermediate
and
share
tensor
well
more
account
and
the
endpoint
will
be
like
this,
and
I
I
still
have
an
open
question
that
should
we
have
separate
api
endpoint
for
kubernetes,
neuropathy,
glass
and
neuropathy
and
adrenal
forces.
The
the
reason
is:
if
we
we
just
use
one
endpoint,
then
then
there
is
difficult
to
have
rbac
for
this
resource.
But
you
know
the
customer
policy.
Is
cluster
scoped?
D
So
this
is
a
question
we
could
discuss
and
after
having
this
user
can
access
the
narrow
processing
metrics,
while
this
matrix
api
and
they
can
also
use
encoder
to
get
the
matrix
and
by
specifying
a
a
nail
voice,
a
name
and
a
namespace
or
a
noun
or
on
or
not
specify
a
name
to
get
the
list
of
metrics
and
that
that's
all
for
the
detailed
design.
Any
question.
E
D
G
G
So
I
I
see
on
the
agent's
side,
when
we
watch
for
address
groups-
and
you
know
apply
to
groups,
for
example,
we
sort
of
tend
to
you,
know,
disconnect
and
reconnect
and
everything
if
the.
If
the
matrix
you
publish
to
a
path
server
is
sort
of
like
stated,
how
would
you
guarantee
the
the
increment
increments
are
sort
of
like
added
correctly
meaning
we
don't
like
miss
any
increments
or
double
count?
Any
increments.
D
D
D
G
So
if
that's
the
case,
you
know
a
new
fresh
agent
will
install
new
flows
for
the
network
policies,
whereas
you
know
the
old
flows
will
sort
of
you
know
just
hanging
there
right
and
the
new
agent
will
not
be
able
to
we're
not
basically
looking
to
the
these
old
flows
and
in
fact
these
old
flows
might
still
be.
You
know
having
traffic
hits
and
and
whatnot
in
the
agent
downtime,
so
yeah,
I'm
thinking
you
know
those
will
be
the
things
that
we
definitely
gonna
miss.
If
we
have
you
know
a
stateless.
D
C
D
For
for
the
first
case,
I'm
considering
that
when
the
agent
comes
up,
it
should
have
a
snapshot
of
the
current
stats
and
uses
as
the
base
of
the
incremental
date
and
and
after
a
period
like
one
minute.
It
should
collect
it
another
time
and
calculate
the
incremental
part
and
report
the
incremental
part.
Only
so
if
so,
the
data
between
it
is
it
is
off,
and
it
is
on
the
the
matrix,
the
the
stats
between
that
time
window
will
be
lost.
D
D
A
A
D
Okay,
thank
you
anthony.
I
did
some
performance
tests
in
my
private
test
bed.
It's
a
kom
based
and
I
don't
think
the
absolute
value
is
reliable,
but
we
can
tell
the
difference
between
the
two
modes.
One
is
when
and
when,
when
we
use
cube
prophecy
to
proxy
the
access
to
service
and
another
one
is,
we
have
open
flow
to
proxy
the
service
access
and
we,
I
have
two
tables.
D
One
is
for
the
intranode
case,
as
you
can
see
from
the
pictures
that
the
tcp
stream,
if,
if
is
if
it
is
the
queue
proceed
case,
compared
with
the
port
port
and
the
product
to
service,
it
will
decrease
a
lot.
I
think
it
is
because
in
this
mode
we
have
to
load
the
traffic
to
the
host
network
namespace
once
and
then
the
package
will
have
to
go
to
the
habitable
rules
in
the
hostname
host
network
and
also
the
and
also
look
up.
D
D
So
so
this
is
expected
and
when
I,
when
I
add
a
lot
of
service
back
background
service
to
that
process
and
angioprosis
to
creating
a
lot
of
habitable
loss
and
open
flow
loss,
the
the
effect
the
influence
influence
on
the
performance
is
also
overwhelms
like
for
cube
process
case.
We
can
see
that,
along
with
the
increase
of
the
service
number,
the
throughput
will
decrease
a
little
but
the
for
for
anti-proxy
case.
The
support
is
consistent
regardless
the
number
of
the
proxy
of
the
number
of
narrow
policies,
sorry
services
and
another
metrics-
is
the
tcp
crr.
D
Repeat
repeatedly,
connect
and
request,
then
use
and
exit
and
then
get
the
response,
then
destroy
the
connection
and
create
another
new
connection.
So
it's
for
the
short
connection
case
and
when
q
process
is
used,
we
can
see
that
the
performance
decrease.
Obviously,
when
the
number
of
service
increase
and
for
an
entry
proxy
case,
it
is
consistent.
I
think
this
is
because,
by
the
way,
the
when
I'm
talking
about
cube
process,
I
mean
the
iv
table
small
of
cube
processing.
D
I
think
the
performance
gap
is
because
for
applicable
it
how
to
do
liner
search
of
tables
loads,
to
select
the
character
d
net
destination
and
for
open
flow,
the
net.
It
only
need
to
do
some
tuple
space
search
and
it's
based
on
hashi,
so
the
the
performance
is
consistent
and
for
tcp
this
is
a
case.
It
is
a
long
connection,
but
it's
a
request
response
mode.
D
So
this
is
for
internal
case
and
another
is
the
internal
case.
I
didn't
see
a
considerable
difference
between
these
two
modes.
I
think
it
is.
It
is
mainly
because
that,
for
internal
case,
the
main
bottleneck
is
not
in
the
it's
not
in
the
live
tables
or
open
floor
match
it's
in
the
in
the
in
cap
of
the
decap,
so
both
of
them
has
a
similar
performance
in
in
the
in
the
different
scenarios.
D
D
D
But
recently,
where
we
are
comparing
that
with
four
four
zeros,
but
that
is
different
from
this
case
and
that
is
for
performing
performance
gap
between
andrea
with
other
things
yeah,
but
for
cupola
and
anti-proxy.
I
think
there's
no
scenario
that
acupuncture
the
way
we
integrate
with
the
cube
policy
will
perform
better
than
the
way
we
have
open
flow
for
for
service
access.
D
D
A
D
F
D
A
A
Results
yeah.
So,
basically,
if
anyone
has
deployed
entria
with
the
proxy
feature
at
scale,
I
think
we
would
appreciate
that
feedback
and
if
anyone
runs
into
any
issues
that
we
should
take
into
account
when
making
the
decision
of
enabling
entry
proxy
by
default,
that's
also
something
we
would
like
to
hear
about.
So
we
can
make
that
decision
so
yeah.