►
From YouTube: Episode 21: Antrea Policy in Action
Description
Come join Yang Ding and Grayson Wu to be the first to know about the new features in Antrea 1.6!! Antrea 1.6 is coming soon!!
A
Okay,
we're
live
hi.
Everyone
welcome
to
this
week's
entrance
live
show.
Today
we
have
a
young
dean
and
grantham
with
us
and
they
are
the
old
friends
of
entre
life
because
they
were
here
when
we
did
the
first
episode
so
for
the
new
audience
who
just
like
joined
a
show
with
us
today,
young
dean
and
grandson.
Would
you
like
to
like
do
a
self
introduction
shortly
for
them.
B
Yeah
sure
so
my
name
is
young
and
I've
been
mainly
working
on
the
policy
side
of
sides
of
things
in
gentria.
So
I've
been
on
the
part
of
a
lot
of
the
big
international
policy
features.
For
example,
you
know
the
all
the
international
policy
features.
I
would
say.
I've
basically
been
involved
in
developing
these
and
maintaining
these,
and
I,
I
think,
that's
also
basically
the
case
for
for
grayson
as
well.
So
we're
very
excited
to
to
be
here
to
present
some
the
exciting
features
of
the
intro
naturopathy.
C
A
B
Right
right
so
for
the
intro
policy,
it
has
been
around
for
a
long
time
and
we're
constantly
you
know
adding
new
features
into
the
intro
policies.
So,
for
example,
we
have
recently.
I
believe
we
have
something
like
you
know:
fqdm
policies,
policy
to
services,
support
stuff,
like
that.
I
know
grayson
cheerio,
who
is
also
our
team
and
myself
included.
B
A
B
A
B
Hi
hi,
so
let
me
get
started
real
quick.
Let
me
try
to
share
my
entire
screen:
okay,
so,
okay,
okay,
so
to
introduce
the
intranative
policies,
we
wanted
to
first
take
a
step
back
and
do
a
really
really
quick
review
of
what
the
kubernetes
network
policy
does.
So
in
kubernetes
osi
model.
If
there
are
no
policies
whatsoever
in
a
cluster
by
default,
kubernetes
prescribes
that
all
pots
can
definitely
talk
to
each
other.
B
You
know,
without
any
you
know
dna
on
everything
they
can
just
you
know,
connect
to
each
other
using
their
ips,
but
the
network
policy
coming
to
place
where
a
developer
might
want
some
sort
of
like
security
postures
imposed
on
some
of
their
workloads.
A
really
typical
use
case
is
that
you
know
some
pods
are
deployed
as
part
of
some
services
and
people
wanted
to
control
what
other
parts
or
what
other.
B
B
I
mean
that
once
a
pod
is
selected
by
some
network
policy
and
it
has
a
policy
type
of
ingress
or
egress
or
both
right.
So,
in
this
specific
scenario,
it
has
both
ingress
and
egress
rules,
meaning
that
ingress
to
this
pot
or
egress
from
the
spot
are
implicitly
denied
when
there's
a
policy
like
this
in
place,
except
for
something
that
is
explicitly
allowed,
which
is
specified
in
the
in
the
network
policy
rules.
B
So
in
this
case,
we
are
selecting
the
db
parts
and
we're
allowing
ingresses
from
a
specific
cider
from
a
specific
another
namespace
which
matches
you
know
this
criteria
and
we
are
also
allowing
ingress
matching.
You
know
this
specific
criteria
in
the
same
name.
Space
from
you
know
these
parts
on
specific
ports.
B
Obviously,
so
this
is
how
the
kubernetes
network
policy
works,
but
a
lot
of
discussions
has
already
come
up
in
the
sig
network,
sig
space
in
the
upstream
kubernetes,
because
you
know,
obviously
a
lot
of
clusters
means
we
want
to
control
some
traffic
in
their
cluster
on
a
namespace
level
right.
So
a
very
typical
use
case,
I
will
show
my
terminal
here.
I
guess,
because
I
prepared
a
really
simple
kubernetes
cluster
to
showcase
the
internet
of
policies
today
and.
A
A
quick
question:
yeah:
so
can
you
go
back
to
the
previous
yeah?
So
if
I
don't
have
the
ingress,
roll
and
egress
raw
defined
it
below,
I
only
have
the
policy
types
to
in
like
ingress
and
egress.
Is
that
means
that
the
pod
cannot
be
reached
by
anyone
any
other
pause
and
the
post
cannot
talk
to
any
other
pause
right.
B
A
A
B
B
So
what
I
can
tell
you
is
that
the
dev,
usbs
and
ws
west
has
label
app
or
type
equal
staff
for
the
namespace,
and
this
guy
has
a
type
equals
production
label
for
the
namespace
and
for
each
of
the
three
namespaces.
I've
basically
deployed
the
same
deployment,
which
is
a
client
deployment,
db
deployment
and
web
deployment
with
you
know
app
because
client
db
web
as
a
label
for
each
of
them.
So
it's
really
sort
of
like
a
minimalistic
and
simplified
version
of
how
you
know
some
production.
Kubernetes
cluster
can
look
like
now.
B
B
Now,
if
you
wanted
to
enforce
something
like
this
using
the
kubernetes
now
policy
I
just
mentioned
it
will
be
really
hard,
because
the
network
policy
resource
is
not
designed
for
a
use
case
like
this.
So
a
custom
admin
would
need
to
write
some
sort
of
like
controller
which
does
the
following.
It
needs
to
go
into
each
of
the
namespaces
here
and
select
everything
in
the
namespace
and
say
that
for
ingress
and
egress
I
wanted
to
allow
only
stuff
in
my
own
namespace
and
for
such
a
policy.
B
It
needs
to
be
created
in
each
of
the
workload
namespaces
that
are
present
in
a
cluster
so
which
means
that
once
a
new
namespace
come
up
or
something
similar,
the
controller
needs
to
go
into
the
namespace
and
create
another
kubernetes
network
network
policy
resource.
For
that
specific
use
case,
and
so
that's
another
sort
of
like
layer
of
policy
definition
on
top
of
the
top
of
the
resource
itself,
so
which
is
not
really
user
friendly.
B
Most
probably
I
I
would
guess
there
are
some
sort
of
like
controller
that
does
that
you
know
in
you
can
probably
find
some.
You
know
github
repo,
that
does
that
I'm
not
entirely
sure,
but
I
also
would
imagine
that
people
would
who
people
who
need
this
feature
would
also
use
a
cni
such
as
entria,
which
supports
cluster
level
network
policies.
So
so
this
you
know
basically
autumn
automates,
that
for
them.
A
B
Right
right,
so
this
is
the
first
this.
This
is
a
first
caveat.
I
want
to
mention
about
kubernetes
network
policy.
The
second
caveat
is
its
increased
isolation,
behavior
right.
So
as
long
as
in
the
namespace,
there
are
some
developer,
which
applies
some
network
policy
onto
on
the
workloads.
It
becomes
implicitly
isolated
other
than
something
that's
explicit
allowed.
B
So
a
lot
of
times,
people
often
forget
to
put
dns
into
the
ingress
and
rules,
and
when
they
apply
some
sort
of
narrow
policy,
they
suddenly
realize
that
you
know
hey,
you
know,
dns
doesn't
work
anymore
and
they
will
be.
You
know,
searching
down
the
rules
to
find
out.
You
know
what
am
I
missing
here,
but
they're
not
missing
anything
explicitly
they're,
just
missing
it.
You
know,
implicitly,
because
with
this
policy
specifically
for
example,
ingress
and
negros
dns
are
ex
implicitly
denied
because
they
are
not
explicitly
specified
in
the
rules.
B
B
B
B
This
is
a
cluster
level,
cluster,
the
entry
cluster
network
policy
and,
as
you
can
see
in
its
name,
it's
called
strict,
namespace
isolation,
which
means
that
it
does
what
I
just
told
you
about.
It
isolates
each
workload
namespace
so
that
the
parts
in
each
namespace
can
only
talk
to
their
own
namespace,
and
this
is
how
the
cluster
network
policy
will
look
like
with
this
single
resource.
B
Every
namespace
in
the
cluster
can
only
talk
to
depositing
their
own
namespace
with
this
one
single
yamo
and
I
will
walk
you
through.
You
know
what
it
does
right
now.
So
a
cluster
network
policy,
obviously
like
other
criminal
policies
or
other
kubernetes
objects,
will
have
a
name
and
a
spec.
So
in
the
spec
you
will
have
two
things
that
are
basically
determining
you
know
the
priority
of
the
cluster
network
policy
compared
to
the
others.
The
first
differentiating
factor
is
the
tier.
C
B
So,
on
entire
startup
we
create
six,
I
believe,
static
tiers,
which
are
defined
using
crds
that
people
can
refer
to
for
cluster
network
policies.
There
are
application,
security,
ops,
network,
ops
and
emergency,
and
there
is
something
else
I
I
forgot
about
its
name,
but
essentially
these
tiers
has
inherent
priority
among
the
others.
So
what
you've,
cr
every
cluster
network
policy
created
in
the
security
ops
tier,
will
have
higher
precedence
than
the
cluster
network
policy
created
in
application
tiers.
B
B
B
You
can
refer
to
this
specific
document
if
you
have
any
questions
regarding
the
entry
native
policies
but
for
the
tiers
crds,
you
can
see
here
that
these
are
the
tiers
that
entria
creates
for
you
automatically
and
all
of
the
policies
in
those
tiers
have
a
higher
precedence
than
kubernetes
network
policies,
except
for
a
specific
tier
which
is
called
the
baseline.
Every
policy
that's
created
in
that
specific
tier
will
have
a
lower
precedence
compared
to
the
kubernetes
network
policy.
I
will.
B
Otherwise,
if
they
wanted
to
impose
something
that
is
more
strict
or
non-overwritable,
they
can
impose
these
policies
into
these
specific
tiers
so
that
they
ensure
that,
no
matter
what
network
policies
are
created
by
developers,
they
cannot
be
able
to
override
the
cluster
network
policies
created
in
these
tiers.
If
that
makes
sense,.
A
B
C
A
B
The
pass
rule
in
the
in
the
front
which
has
a
higher
this
rule,
has
a
higher
precedence
than
this
rule.
Obviously,
and
then
this
rule
here
when
it's
saying
a
pass,
it's
trying
to
select
something
and
for
the
traffic
matching
dose,
these
traffic
will
not
be
subject
to
the
drop
rule
that
is
mentioned
below.
So
it's
like
for
every
traffic
matching,
this
specific
ingress,
pier
you
know
basically
for
every
traffic.
That's
from
here
to
whatever
it's
applied
to
this
will
skip
the
acmp
evaluation.
B
If
that
makes
sense,
I
I
think
I
I
skipped
the
apply
to
fill
here.
Let
me
back
up
a
little
bit
so
that
people
are
easy.
It
will
be
easier
to
understand
this,
so
the
applied
to
here
is
basically
like
the
it's
basically
like
the
past
lecture
field
in
the
kubernetes
network
policy,
but
because
the
kubernetes
now
a
policy
as
a
namespace
bond
resource.
B
B
In
our
example
here
it
will
select
all
the
name
spaces
which
are
not
coupe
system.
So
what
I'm
highlighting
here
right?
So
this
is
what
the
policy
applies
to
now
for
the
ingress
rule.
Let's
look
at
the
first
ingress
rule
here.
It
says
that
I
want
to
pass
every
name
spaces
that
matches
self,
and
this
is
more,
like
you
know,
a
synthetic
sugar
if
you
will
for
the
ingress
rules,
and
it
has
a
really
strong,
it's
a
really
strong
expression
which
basically
just
means
the
self
namespace.
B
In
this
context,
so
let
me
expand
a
little
bit
more
on
what
this
means,
because
we
have
three
different
name
spaces
here
right.
So
when
we
are
evaluating
this
particular
policy
for
this
specific
namespace,
that
specific
policy
rule
which
matches
self
namespace
means
every
workload
that
are
in
this
namespace
and
nothing
else.
B
B
So
with
these
two
rules,
what
will
happen
is
that
these
two
peers
are
not
affected
by
the
drop.
All
rule
that's
specified
below
and
what
it
means
is
sorry.
What
it
means
is
that
you
know
for
this
specific
namespace,
I'm
dropping
everything
ingress,
except
for
two
different
things,
one
if
the
traffic
is
coming
from
my
own
namespaces,
which
is
something
like
when
a
client
pod
wants
to
talk
to
a
webpart
in
my
own
namespace,
and
this
traffic
is
not
affected
by
the
drop
rule
and
the
second
one
is
the
dns.
B
So
if
I
try
to
resolve
google.com
from
my
client
pod,
it
will
basically
send
a
dns
request
to
the
coupe
system,
dns
components
and
when
the
result
comes
back,
it
will
not
be
affected
by
the
drop-out
rule.
It
will
still
go
through
other
than
these
two
kind
of
traffic.
Everything
else
will
be
denied,
and
the
same
is
true
for
the
two
other
namespaces,
because
for
the
other,
two
namespaces,
the
match
equals
self
will
resolve
to
different
network
peers.
B
For,
for
those
two
namespaces
and
end
result
by
applying
such
policy
will
be
that
each
namespace
will
be
isolated
on
its
own,
so
that
only
the
pause
in
its
own
name
place
can
talk
to
each
other.
But
everything
else
on
the
other
on
the
outside
will
be
isolated
to
these
name
spaces,
except
for
dns
components,
and
essentially
this
is
what
this
policy
is
saying,
and
you
can
see
that
it
has
the
same
rules
for
ingress
and
egress.
A
B
Oh
okay,
I
see
what
the
question
is
asking,
so
there
is
actually
a
upstream
effort,
we're
making,
which
is
merging
a
specific
resource
called
admin.
Echo
policy
in
the
in
the
kubernetes
upstream
so
shout
out
to
app
shack.
Also,
for
you
know
starting
this
effort,
but
you
know
right
now
we're
currently
still
deciding
how
you
know
this
at
the
main
network
policy
will
come
to
play
side
by
side
with
the
current
entry
native
policies.
B
The
end
result
of
that
is
that
for
the
core
dns
part,
it
will
only
accept
traffic
from
its
own
namespace,
which
is
coupe
system
or
the
crude
dns
part,
which
is
itself
which
doesn't
really
make
any
sense,
and
it
will
drop
everything
else
now.
What
that
will
mean
is
that
whenever
some
clients
in
the
same
cluster
are
trying
to
do
some
dns
resolving
that
request
will
get
dropped
by
this
cluster
network
policy,
and
it's
not
ideal.
B
A
B
All
right
so
so,
as
I
mentioned,
the
past
will
basically
just
skipped
the
route
evaluation
for
this
drop
rule
so
that
you
know
these
traffic
will
not
be
affected
by
the
draft
rule
below,
but
for
the
allow
rule
it
will
be
something
more
strong.
It
would
be
like
I
wanted
to
explicitly
allow
egress
towards
these
towards
the
service
and
there's
no
way
there's
other
lower
level
policies
can
override
this
behavior
unless
there's
a
deny
rule,
that's
of
higher
precedence
than
the
specific
policy.
B
A
B
Yes,
it's
a
it's
a
new
feature
added,
I
think
in
the
1.5
release,
if
I
remember
correctly
or
the
1.4
release,
so
that
this
is
a
like
a
really
cool
wrapper.
If
you
wanted
to
to
allow
or
deny
or
reject
any
traffic
towards
a
specific
kubernetes
service,
you
can
just
put
a
name
and
namespace
there
and
it
will,
you
know,
resolve
to
that
service,
so
you
don't
have
to
put
any
you
know
pod
selectors
and
put
the
service
ports
in
the
port
section.
C
Okay,
I
I
just
want
to
add
a
little
bit
comment
on
this
field.
It's
we
use
that
there's
a
little
caveat
since
the
two
services
only
select
it
rely
on
the
entry
proxy.
So
if
we,
if
we
so
the
entry,
I
will
do
the
load
balance
for
these
services.
So
if
you
connect
to
the
backend
endpoint
of
this
services,
it
will
not
be
selected
by
this
policy.
C
B
Yeah,
so
so
I,
if
I
wanted
to,
if
I
can
wrap
it
up
real
quick,
what
grayson
is
essentially
saying
is
that
you
know
if
you're
specified
to
services
rule
you're,
not
actually
specifying
the
rule
on
these
service.
Backend
endpoints
you're
just
specifying
a
rule
towards
the
cluster
ip
of
the
service.
So
if
you
really
wanted
to
have
complete
protection
against
the
service,
you
probably
wanted
to
protect
the
cluster
ip
and
the
back
end
communication
as
well.
So
but
that's
a
more
sort
of
like
advanced
topic
for
this
I
would
say.
A
B
Hey
guys,
okay,
so
as
promised,
this
live
show
is
about
the
intro
policy
in
action.
So
let's
see
some
actions,
we'll
apply
the
specific
policy
and
as
promised,
every
namespace
is
now
isolated,
except
except
for
the
dns
right.
So
let's
verify
really
quickly
if
that's
working
as
expected.
So
if
I
go
exact
into
one
of
the
client
parts
in
the
namespace
usws
east
right
and
I
do
a
flash.
B
So
if
I
do
a
curl
on
the
wrap
deployment
of
the
same
namespace,
which
is
this
guy
and
I'm
not
too
sure
what
the
pod
is
listening
on,
but
I'm
guessing
ade
right.
So
it's
it's
good
right,
so
I
can
basically
talk
to
the
web
part
for
my
own
namespace.
Now
what
will
happen
if
I
try
to
talk
to
the
web
part
of
a
different
namespace,
which
is
you
know
this
guy?
What
happened
there.
B
Look
at
it
denied
because
of
the
drop
rules
we
have
for
the
name,
swiss
isolation,
so
that's
how
it
works
and
as
promised
also
we
don't
regulate
dns
traffic
right.
So
the
the
coupe
system
coordinates
is
running
in
another
namespace,
but
we
can
still
talk
to
that
because
we
have
another
password.
So
let's
try
to
paint,
say
google.com
and
it's
good
and
you
might
probably
ask
we-
have
a
egress
drop
or
rule
right.
So
why
does
the
egress
to
google
still
works?
Because
you
can
see
here?
B
You
know
we
can
still
talk
to
google
as
an
egress.
That
is
because,
in
the
strict
names
of
acceleration
for
the
drop
rules,
we
are
selecting
two
and
the
name
space
selector.
Everything
means
that
I
wanted
to
drop
the
egress
of
the
parts
to
all
other
namespaces
within
the
cluster,
but
it
doesn't
really
specify
what's
the
behavior
for
all
of
cluster
traffic.
B
B
You
can
see
the
dns
still
works
right
because
we
made
a
explicit,
allow
rule
or
another
a
pass
rule
or
allow
rule
for
that.
So
the
client
was
able
to
receive
the
resolved
address
for
that
specific
domain
name,
which
is
google.com,
but
when
it
sends
the
traffic
out
of
the
cluster
it
gets
denied
because
we
have
a
deny
or
egress
policy
in
place.
So
this
is
how
you
know
this
works.
A
A
B
Yes,
because
the
namespace
letter
and
everything,
this
specific
clause
is
basically
saying
that
I'm
selecting
every
namespace
of
the
cluster,
but
obviously
we're
not
selecting
all
of
cluster
items
right.
So
what
this
rule
translates
to
is
that
I
wanted
to
drop
everything
to
all
I
addresses
in
the
cluster
if
you
will
right,
but
not
dropping
anything
to
out
of
the
cluster,
but
if
you
remove
these
two
lines
and
just
say
action
equals
drop.
This
is
a
completely
different,
meaning
rule.
B
A
C
I
mean
open
the
yaml
file
yeah,
for
example,
in
the
egress
you
only
define
the
two
as
the
to
all
name,
speed
to
empty
namespace
selector.
This
will
only
select
all
namespace,
but
you
you
can
also
define
a
field
called
ports
in
under
the
ports.
You
can
define
all.
I
only
want
to
drop
the
tcp
traffic
or
utp
traffic
or
http
traffic,
but
if
you
didn't
define
the
ports
field,
so
it
will
only
do
the
traffic
match
on
the
l3
layer,
so
the
ping
will
also
be
infected
by
this
part.
C
Yeah
and
also
currently,
I'm
working
on
the
add
icmp
support
in
the
in
the
cluster
network
policy,
so
you
can
define,
I
only
want
to
like
drop
the
icmp
type,
8
code
0
or
something
like
this.
You
can
do
this
in
the
next
version
cluster
network
policy.
It
will
bump
up
the
cluster
network
network
policy
to
view
alpha
2..
A
B
B
B
B
So
this
is
a
security,
ops
tier
of
power
to
one
policy
which,
on
the
policy
level,
it
has
a
higher
precedence
than
the
previous
name
space,
isolation
policy.
Now
what
it
does
is
that
it's
applied
to
type
equal
staff
namespaces,
which
selects
the
two
namespace
I
just
described
and
in
the
ingress
in
rules.
B
It
was
not
returning
everything
because
the
connection
was
dropped
and
let's
see
if
this
is
give
me
a
success
this
time
it
does
so
so
we
what
I'm
showing
here
is
I
applied
a
higher
powering
policy.
On
top
of
the
you
know,
strict
namespace
isolation,
so
that
it
overrides
the
drop
rule
of
the
of
the
original
policy
a
little
bit.
B
Okay,
so
let's
look
at
the
final
policy
that
I
prepared
here
is
the
allow
aws
for
db.
So
remember
we
have
a
bunch
of
applicants.
Db
parts
in
all
of
the
clusters
in
all
of
the
name.
Spaces
are
right,
so
one
specific
use
case
might
be.
You
know
these
db
parts
are
actually
constantly
trying
to
talk
to
you
know,
f3
buckets
or
whatever
to
you
know,
update
the
the
entries
there
right
and
from
a
security
perspective.
B
The
cluster
of
meaning
might
want
to
say
that
hey.
I
wanted
these
to
talk
to
the
dbpos
to
talk
to
this
online
or
another
cider
specifically,
and
that's
all
I
need
for
any
other
egresses.
I
don't
want
to
allow
it
because
that's
not
secure
so
by
this
example.
I'm
trying
to
showcase
the
new
fqdn
feature
we
added
into
the
alternative
policies
a
couple
releases
ago.
B
So
looking
at
this
policy,
we
are
actually
you
know,
selecting
every
db
part
in
the
cluster,
no
matter
what
the
namespace
is
and
we're
allowing
an
egress
to
this
specific
fqdn,
regular
expression.
Oh
I
shouldn't
say
regular
expression,
I
should
say
fqdn
wildcard
expression.
So
that
means
that
every
egress
request
to
you
know
maybe
www.amazonaws.com.
B
Or
s3bucket
blahblahblah.msjws.com
is
allowed
and
the
dns
components
is
also
a
pass
because
you
know
I
do
want
it
to
positively
still
able
to
resolve
things.
Obviously,
otherwise
this
will
will
be
in
vain,
because
if
a
part
doesn't
can,
if
a
part
can't
even
resolve
dns,
then
obviously
it
won't
be
able
to
egress
anywhere
right
so
other
than
these
two
cases
we
drop
all
egress,
which
means
that
you
won't
be
able
to
talk
to
google.com
or
everything
else
right.
So,
let's
see
this
guy
in
action.
B
B
B
B
B
B
Okay,
yeah
remember:
I
changed
this
policy
to
drop
all
egress
and
it's
effecting
so
basically
we
have
policies
stacked
with
each
other.
Now
this
amazon
aws
being
dropped
is
because
there's
another
policy
in
place
which
I
forget
to
apply
and
it's
dropping
all
egress.
So
that's
basically
the
reason
so
right
now,
if
I
configure
this
correctly
and
now
I
go
to
this
pod-
let's
do
this
again:
let's
do
google
again
it's
dropping
the
egress
and
that's
through
amazon
again
and
it's
connecting.
A
B
Does
not
if
you
look
at
if
you
look
at
the
allow
aws
db,
it's
a
it
doesn't
have
a
tier
keyword
and
what
happens
is
that
if
a
interior
cluster
now
policy
is
not
specif
specified
with
a
specific
tier
name,
it
will
be
associated
with
the
application.
Tier
and
the
conditions
here
has
a
lower
precedence
than
the
security
ops
tier,
which
is
what
we
put
the
name
service
isolation
policy
on.
So
what
happened
is
that
namespace
association
policy?
B
We
forgot
to
change
back
and
it
is
dropping
all
egress
for
all
the
namespaces,
and
so
so
it
doesn't
really
matter
what
you
define
in
the
application
tier
anymore.
What
the
ftd
and
policy
put
there,
because
every
egress
will
first
be
evaluated
in
the
egr
in
the
security,
ops,
tier
and
there's
a
rule
drop
in
rd
grass,
so
everything
will
be
dropped
for
all
of
clusters.
A
B
So
I
would
say
that
concludes
all
the
demo
we
have
today.
It's
really
it's
really
good
that
we
actually
run
into
a
small
problem
now.
It
really
basically
shows
you
how
we
kind
of
like
debug
these
kind
of
things,
because
you
will
probably
also
want
it
every
time
you
see
some
policies,
not
working
or
not
working
as
intended,
you
probably
wanted
to
check
what
the
other
all
the.
What
are
the
other
policies
that
are
applied
to
this
pod
and
if
these
policies
make
sense.
B
B
It
gives
you
what
policies
are
applied
onto
the
specific
part
at
the
time
being
so
for
client
parts.
The
only
policy
affecting
it
is
the
strict
namespace
isolation
which
is
we
just
put
on.
But
if
we
do
this
for
the
db
pod,
which
is
you
know
this
guy
in
this
namespace,
you
will
have
two
policies,
because
it's
affected
by
the
structure,
stricter
name
to
its
isolation,
and
it
is
also
affected
by
the
fqdn
rule.
B
B
A
Yeah,
I
think
that's
a
really
powerful
way
to
debug
the
network
policy,
because
sometimes
you
maybe
forget
it
which
which
policies
are
applied
to
this
part
right
right,
yeah,
yeah,
thanks
young
and
grandson
for
like
showing
us
the
entry
policy
today.
I
learned
a
lot
from
your
like
demo
and
hope,
like
our
audience,
also
have
a
have
an
idea
of
how
to
use
the
entries
policy
from
watching
our
show.