►
From YouTube: TGI Kubernetes 085: Network Policies
Description
Episode directory on GitHub: https://github.com/heptio/tgik/tree/master/episodes/085
Join Josh Rosso as he returns to TGIK to explore Network Policies in Kubernetes. We'll explore how Kubernetes networking operates without policy, with policy, and how Container Networking Interface (CNI) plugins impact your capabilities.
Come hangout, ask questions, and share you experiences!
A
Hey
everybody
how's
it
going
happy
Friday
thanks
for
joining
us
here.
Some
of
you
might
even
be
the
weekend
already
all
right
so
who
do
we
have
Sean
from
Seattle?
Welcome!
Welcome
Madi,
welcome
Rory
glad
to
have
you
welcome
back
Martin
from
the
Netherlands.
Welcome
Martin,
hey,
hey,
hey,
hey
everyone!
It's
like!
We
got
Robert
from
Ireland
awesome,
Shahar,
Lana,
Georgia,
welcome!
Welcome!.
A
Okay,
fame
South
Korea
welcome.
Hopefully,
I
got
your
name
pronunciation
somewhat.
Close
I
eat
from
London.
Welcome.
Thanks
for
joining
us,
hey
everyone!
So
we're
gonna
give
people
a
minute
here
to
float
in.
If
you
are
floating
in
and
you
feel
so
inclined,
please
feel
free
to
say,
hey
in
the
chat
and
savor
you're
tuning
in
from
optional,
but
absolutely
welcome.
A
A
All
right
hope,
you
all
have
some
awesome
weekend:
plans
I'm
out
in
a
Colorado
and
the
weather's
looking
pretty
good
this
week,
so
I
think
we're
gonna,
get
some
good,
climbing
and
really
really
excited
all
right.
Everyone
cool!
So
let's
kick
it
off
and
as
people
filter
in
we'll
just
we'll
just
say:
hey
as
we
go.
B
A
Again,
I'm
Josh
you,
you
may
have
seen
me
a
couple
episodes
back
I
did
an
episode
on
pods
security
policies
and
today,
I
guess
kind
of
in
a
similar
vein.
I
hadn't
really
thought
of
it
till
now.
We're
still
talking
about
something.
That's
somewhat
security
focused
more
in
the
network
layer.
This
time
around
right
and
we're
going
to
talk
about
network
policy
today
and.
B
A
A
Kubernetes
back
in
it
back
in
that
time,
but
I
remember,
network
policy
was
kind
of
still
getting
fleshed
out.
There's
a
lot
of
confusion
about
it
and
I
think
it's
it's
come
like
massive
strides
from
that
right.
We
used
I
think
just
have
like
ingress
in
the
policies.
I,
don't
even
think
we
used
to
have
like
egress
as
a
rule,
if
I
remember
back
in
those
days
so.
A
Stoked
to
share
some
of
the
history
with
you,
some
of
the
pain
points
and
just
kind
of
thought
process
around
it
as
well,
and
we're
also
gonna
talk
a
bit
about
some
of
the
container
networking
interface
plugins
right,
like
calico
psyllium
and
like
how
these
network
policies
can
impact
that
as
well.
Let's
see
here,
oh
and
Duff,
you
wanted
me
to
talk
about
the
picture
inside
of
the
title
card
this
week.
So
I
don't
know
if
any
of
you
have
spent
much
time
in
Colorado,
but
that's
a
picture
of
the
diamond.
A
It's
on
Long,
speak
and
I
got
to
climb
the
face
of
that
a
couple
weeks
ago,
and
it
was
remarkably
beautiful,
except
for
the
fact
that
if
you
follow
weather
in
the
US,
we
had
a
pretty
heavy
snow
year
out
west.
So
I'm
not
I'm,
not
like
Chris
Nova
I'm,
not
I'm,
not
really.
A
big
fan
of
climbing
up
icy
snowy,
stuff
I
prefer
just
dry
rock,
so
I
was.
B
A
A
B
A
There's
a
medium
article,
that's
been
passing
around
here
from
Xavier
called
writing
your
first
kubernetes
operator.
So
you
probably
saw
Joe
a
couple
weeks
ago.
Did
a
operator,
nah,
I,
guess
more
of
a
controller
but
sort
of
an
operator
like
talk
where
he
built
that
minecraft
controller
with
a
cute
builder
and
I
know
he's
done
an
operator
SDK
when
back
in
the
day,
I
think.
But
this
medium
article
has
just
kind
of
a
really
cool
walkthrough
using
the
operator
SDK
as
the
framework
and
talks
about
building
it
packaging
it
pushing
it
up.
A
So
that's
the
hack
MD
as
well.
If
you
want
to
check
that
out
pretty
cool
stuff,
so
thanks
davier
for
putting
that
awesome
resources
together
for
the
community
and
then
last
but
not
least,
sorry
to
be
a
broken
record,
but
just
a
reminder
of
the
upcoming
1/16
API
deprecations.
So
it's
kind
of
nice
to
say
this,
because
Duffy
literally
recorded
a
video
around
a
similar
concept
last
week.
So.
B
A
Video
is
in
here
for
TGI
k08,
for
please
feel
free
to
check
that
out
and
then
also
there
was
a
blog
post
from
Valerie
and
duffed.
You
might
have
mentioned
this
last
week,
I'm,
not
sure
you
probably
did.
That
has
a
really
good
kind
of
overview
of
like
what
it
means
for
you
in
regards
to
these,
these
API
deprecations.
B
B
A
A
A
lot
of
you
come
here
with
different
levels
of
experience.
You
have
stories,
questions
so
on
and
so
forth.
So
don't
be
shy
and
chat.
Ask
questions
if
you
have
insight
or
it
can
correct
something.
I
said
even
I
totally
welcome
that.
So
please
don't
be
shy.
Adding
your
own
input
into
chat.
Okay
would
love
for
you
to
participate
as
we
as
we
kind
of
dive
through
this
stuff.
A
A
B
A
Your
own
kubernetes
clusters
right
and
when
we
have
these
namespaces
separated
again,
this
is
I
totally
acknowledge
review
for
all
of
you
for
the
most
part,
but
we
also
have
pods
inside
of
the
namespace
right.
So
this
would
be
our
pod
I'm
just
going
to
do
it
in
a
slightly
different
color
here.
So
we've
got
the
namespace
and
then,
of
course,
have
the
pods
themselves.
So
this
namespace,
of
course,
has
many
pods.
So
let's
go
and
put
two
in
here:
awesome.
A
A
B
A
That
all
right,
so
now
just
a
zoom
in
here
a
bit
and
do
kubernetes
right
all
right,
so
we've
got
the
kubernetes
boundary
now,
of
course,
one
of
the
things
that
most
commonly
gets
asked
right
out
of
the
gate
is
all
right.
So
I've
got
this
cool
kubernetes
cluster.
It
seems
to
be
able
to
post
applications
and
all
that
good
stuff.
How
do
I
actually
get
my
traffic
into
the
cluster
itself?
B
B
A
Potential
here
right
in
regards
to
what
the
network
path
is
to
the
end
result,
which
of
course
for
us
is,
is
the
pods
all
right.
So
if
I
kind
of
look
at
this
with
most
organizations,
we're
obviously
talking
about
ingress
traffic
here
right,
so
oftentimes
somewhere
outside
of
kubernetes,
and
this
this
piece
oftentimes
already
exists
right
company
will
introduce
some
level
of
load
balancer
all
right.
So
this
is
my
my
load
balancer
outside
of
the
cluster
here,
all
right
cool,
so
call
this
the
LB
all
right
all
right,
and
then
they
go
okay.
A
B
A
Face
I
meant
to
make
there
we
go
okay,
cool,
so
I've
got
these
happy
customers
right
and
they're
our
clients
and
they
are
gonna,
send
traffic
in
to
the
load
balancer
which
might
live
outside
of
the
cluster
right
and
then
eventually,
somehow,
and
there
are.
There
are
a
million
ways
to
do
this
right.
There
are
ingress
controllers,
there
is
routable
pods.
A
Okay,
all
right
so
just
just
kind
of
framing
the
problem
space
here,
because
we're
gonna
we're
gonna
build
on
this
as
we
talk
about
what
it
means
to
to
kubernetes,
specifically,
okay,
so
this
this
individual
is
partaking
and
what
we
would
typically
refer
to
as
ingress
traffic
right
networking
101
stuff
for
a
lot
of
you,
but
just
to
make
sure
we're
all
on
the
same
page.
What
we're
talking
about
here
is
effectively
ingress
person
makes
a
request
in
that
ingress
is
into
our
cluster.
We're
concerned
about
ingress.
B
A
Here
we
have
to
concern
ourselves
with
ingress
traffic.
Okay,
now
your
company
probably
goes
rx
great.
We
have
a
load
balancer
here,
but
that's
probably
not
the
only
part
of
the
equation
that
they
have
set
up
right,
there's
oftentimes
another
layer
somewhere
in
here
that
is
making
sure
that
the
things
that
are
occurring
are
in
fact
safe
right.
So
we
need
to
make
sure
the
people
that
are
coming
in
are
trusted
so
on
and
so
forth.
All
right!
So
a
lot
of
the
times
in
these
structures.
A
A
Okay
is
some
layer
of
a
firewall
okay
and
a
lot
of
you
probably
feel
very
passionately
about
your
corporate
firewall,
whether
that
be
positive
or
negative,
because
if
you've
ever
had
an
application
and
you
needed
to
poke
holes
in
that
firewall,
you
probably
know
that
it's
not
always
the
easiest
fastest
process
in
a
lot
of
legacy.
It
for
good
reason
sometimes,
but
you
know
this
is
what
kind
of
play
into
the
overall
story
of
where
we're
headed
with
this
right,
but
firewalls
they
can
be
pretty
naive.
They
could
be
pretty
advanced,
there's
trade-offs.
A
Some
of
them
operate
on
lower
layers
of
the
OSI
model.
Some
of
them
operate
on
higher
layers,
like
even
upwards
of
layer,
7
to
be
able
to
understand
what
it
should
let
through.
But
you
know
one
of
the
most
common
use
cases
that
a
firewall
is
gonna
look
at
is,
of
course,
the
source,
IP
right
and
then
the
destination
IP.
A
B
A
Person
comes
in
with
their
request
and
it
goes
into
the
firewall
and
then
based
on
that
person
there,
their
client,
the
source
IP
and
then,
where
they're
trying
to
head
to
the
firewall,
can
make
some
type
of
termination,
whether
it's
gonna,
let
it
go
in
through
the
load
balancer,
then
the
load
balancer,
of
course,
assuming
the
traffic
goes
through,
we'll
be
able
to
get
to
the
pot
right.
So
pretty
pretty
simple
stuff
here,
overall
and
the
firewall
could
be
in
the
load
balancer.
Theoretically,
with
certain
wave
technologies,
it
could
be
outside
of
the
load
balancer.
A
There's
a
million
million
places
that
you
go
right,
but
with
kubernetes
we
have
the
ability
to
do
a
similar
thing
right.
We
have
the
ability
to
do
a
similar
thing,
with
both
ingress
and
egress,
with
with
network
policies
themselves.
Okay,
so
if
I
just
zoom
into
the
namespace
here
and
I,
don't
even
concern
myself
like
I,
don't
even
care
what's
above
this
I,
just
I
know
that
this
pod
is
getting
traffic
in
okay
and
that
pink
line
hits
my
pod.
So
at
this
point
at
least
from
the
pods
perspective,
this
is,
of
course,
ingress
traffic.
B
A
And
theoretically,
we
could
consider
similar
concepts.
We
can
consider
the
source
the
destination,
should
we
allow
it
blah
blah
blah,
blah
and
and
all
that
good
stuff
and,
of
course,
pods
inside
of
a
cluster
might
even
intercommunicate,
or
they
might
talk
to
external
services
like
services
running
in
your
data
center
or
running
in
in
you
know,
the
cloud
somewhere
does
doesn't
matter
just
outside
of
the
cluster.
So
if
we
look
at
the
traffic
path
say,
this
pod
is
gonna.
A
A
Alright,
and
really
both
of
these
points
in
time
are
kind
of
like
our
east-west
as
it's
sometimes
called
egress
traffic
right,
so
we've
kind
of
got
the
the
north
or
south
whatever
it
would
be,
directionally
right
traffic
that
we're
going
to
qualify
hidden
graphs
from
this
pods
perspec
and
then
the
pods.
You
know
communication,
east
and
west
being
the
egress
traffic
and,
of
course
like,
if
you
were
to
get
like
really
pedantic
here
and
kind
of
you
know,
try
to
pull
out
every
technical
piece
of
this.
A
You
know
there's
obviously
like
ingress
happening
here
right
because
from
a
theoretical
level
right,
this
pod
right
here
is
receiving
traffic.
So
it's
it's
getting
ingress
traffic
from
the
pod.
That's
be
dressing
over
to
it
to
a
degree
right.
So
the
reason
that
I
kind
of
call
these
out
and
I
know
this
again
is
something
that
a
lot
of
you
know
the
reason
I
call
this
out
is
because
this
is
going
to
be
the
type
of
rules
that
we
can
kind
of
impact.
A
Where
I
should
say
these
traffic
flows
are
things
we
can
impact
with
our
own
rules
inside
of
here,
so
just
kind
of
setting
a
baseline
for
ingress,
egress
and
and
how
all
of
that
looks
inside
of
inside
of
kubernetes.
Okay,
all
right
so
we're
gonna,
we're
gonna
hop
over
to
my
machine
here
in
a
moment
and
we're
gonna
set
some
things
up:
okay,
but
I
just
want
to
kind
of
call
out
a
couple
more
things
here
to
kind
of
kind
of
set
us
up.
So
obviously
this
this
routing
that
we're
seeing
here
right.
A
So
all
of
this
traffic
between
pods
and
inner
communication
right.
Many
of
you
know
that
that
routing
happens
through
something
called
the
container
networking
interface
or
CNI.
Okay,
and
particularly,
we
use
CNI,
plugins,
plugins,
okay
or
providers
or
whatever
you
want
to
call
them
right.
So
if,
if
you
deploy
kubernetes
cluster
today,
as
many
of
you
know
and
you'd
start
it,
you
know
this
essential
components
will
come
up.
The
API
server,
blah
blah
blah
like
these
things
that
use
just
the
host
main
networking,
but.
B
A
Order
for,
like
your
DNS
servers,
work
yeah
core
DNS
in
order
for
like
pods
to
be
able
to
come
up
and
get
IP
addresses,
and
things
like
that.
We
need
some
type
of
CNI
plugin
right.
So
some
of
the
players
here
are,
of
course,
plugins
like
calico,
and
calico
is
one
that
I've
been
using
for
a
super
super
long
time.
At
this
point
really.
A
It
you
know
not
only
from
a
feature
set
standpoint,
but
also
just
because
it's
really
bad
attested.
In
my
experience,
I've
seen
lots
of
companies
run
it
for
a
long
amount
of
time
with
great
stability,
but
I'm,
not
I'm,
not
a
specific
CNI
purist
like
another
CNI
plugin
that
is
looking
really
really
awesome
is
psyllium,
which
I
can't
remember
whether
it's
two
L's
or
1l.
Maybe
someone
in
check
and
tell
me
I'm
gonna,
guess
that
it's
1l
for
now
and
then
you
guys
can
correct
me.
You.
A
Another
really
common
one
right
was
flannel.
Okay,
some
of
you
might
even
remember
people
at
one
point
we're
taking
flannel
and
they
were
going
I
like
how
simple
flannel
is
I
like
this,
like
overlay
like
Network,
it
does
with
the
X
LAN
and
blah
blah
blah.
It's
just
super
simple,
but
I
want
the
policy
enforcement
that
calico
offers
right.
So
some
of
you
might
remember
a
project
I.
A
B
A
And,
of
course,
another
really
common
one
in
here,
which
is
weave
okay,
another
really
common
player
in
the
space
has
been
around
for
really
long
time.
So
you
choose
yes,
I
agree,
Duffy
long
live
canal.
It
saved
us
a
lot
back
in
the
coral
s
days
when
we
had
flannel
and
we
needed
to
answer
some
of
those
Network
policy
things.
It's
pretty
cool.
So.
A
A
With
with
IP
and
IP
stuff,
you
can
do
anyway,
it's
like
you
just
have
to
consider
like
what
does
my
networking
fabric
look
like?
What
does
the
feature
set?
I
need
I,
oftentimes.
Tell
people
like
you
know
this.
Is
this
this
technology
you're
seeing
I
plug-in,
is
a
pretty
like
low
level
important
detail
so
like
while
I
love
a
lot
of
the
motion.
A
B
A
B
A
Ones
that
do
do
the
net
policy
right.
We
have
calico,
psyllium,
Canal,
technically
does
and
we've
and
I'm,
obviously
leaving
out
a
lot
of
network
plugins,
like
VMware,
has
see
a
nice
for
NSX
and
and
so
on
and
so
forth.
So
calico
psyllium,
right
canal
and
we've
in
in
this
again
shortened
abridged
list.
Okay,
these
are
going
to
support.
A
B
A
And
use
a
lot
of
the
benefits
we
have
like
the
declarative
nature
of
the
Cades
api,
the
ability
to
use
labels
to
identify
what
should
be
able
to
access
what
so
on
and
so
forth.
Right
and
oftentimes
alleviate
some
of
the
the
speed
requirements
right,
we're
like
rather
than
someone
logging
into
a
firewall
and
doing
XY
and
z.
We
could
just
you
know,
source
control,
the
firewall
rules
and
and
commit.
B
A
Thing,
ok,
so
oh
and
duffy
brings
up
a
great
point.
This
is
actually
true
for,
if
you
think
about
it,
it's
kind
of
true
for
pod
security
policies.
We
talked
a
bit
about
this
last
week
right,
so
the
network
policy
API.
Is
there
right
just
like
the
pod
security
policy?
Api?
Is
there
if
you
start
applying
network
policies
in
your
cluster
today,
regardless
of
your
CNI,
it's
gonna
accept
them.
A
But
the
thing
to
keep
in
mind
here
is
your
enforcer
of
the
policy
right,
the
one
that
goes
in
and
says:
I
am
going
to
respect
this
egress
or
an
ingress
rule
that
was
set
up.
That
is
done
by
the
CNI
plugin
right.
So
anyone
could
submit
Network
policy,
but
it
is
on
these
CNI
plugins
to
actually
enforce
them
over
time.
So
good
call
out
duffy
all
right
cool,
let's
get
another
machine
and,
let's
start,
let's
start
diving
into
some
of
these
pieces.
So.
A
Back
between
the
diagramming
and
my
machine,
just
so,
as
we
kind
of
go
through
this
stuff,
we
can
talk
about
exactly
what
we're
impacting
visually.
Ok,
so
here's
the
deal,
we're
gonna
start
off
by
just
setting
up
two
namespaces
set
up
some
pods
and
those
namespaces
and
just
see
how
communication
works
pod
pod
by
default.
No.
B
A
Since
calico
respects
the
CNI,
this
should
work.
Fine.
Those
of
you
may
be
more
less
familiar
with
calico
calico
node
is
the
daemon
set.
That's
gonna
run
on
every
node
kind
of
acts
as
like
a
little
router
and
does
some
other
things
as
well
as
far
as
like
making
sure
that
the
the
it
can
communicate
with
the
other
nodes
and
let
them
know
about
routes
and
all
that
stuff
again
deeper
than
what
we
need
to
get
today.
But
calico.
A
Running
and
it's
gonna
facilitate
the
the
network
in
here,
alright,
so
let's
go
ahead
and
just
kind
of
set
up
some
of
the
basic
things
and
I
think
one
of
the
things
that
we
should
figure
out
first
is
kind
of
like
what
what
is
this
clusters
IP
space
from
a
pod
perspective?
Okay,
so
I'm
just
gonna.
Take
this
this
random
calico
node
here
all
right,
we're
gonna!
A
A
What
was
at
0-0
16
all
right.
So
this
is
our
pod
cider
for
our
entire
cluster,
okay
and
then,
of
course,
we
will
start
making
some
namespaces
now.
So
let's
go
ahead
and
do
that
so
back
in
this
cluster.
We're
gonna
make
two
namespaces.
Okay,
so
we're
going
to
create
a
namespace
named
teammate
and
then
we're
going
to
create
the
namespace
named
Team
B.
So
we
we
work
in
this
organization
together.
Everyone
right
and
we've
just
decided,
let's
provision
team,
a
a
namespace,
let's
provision,
Team
B,
a
namespace
in
this
cluster-
got.
A
Policy,
the
only
thing
that
we've
set
up
is
the
CNI
plugin
at
this
point.
Okay,
all
right,
so
we've
got
team
a
and
we've
got
team
B.
So
again,
going
back
here
will
just
draw
out
our
two
namespaces
real
quick.
So
this
one
is
going
to
be
team,
a
okay.
So
let's
go
ahead
and
dupes:
let's
go
ahead
and
call
that
team
a
cool.
So
this
is
team,
a
right,
good,
good,
all
right
and
then
we're
just
gonna
make
one
for
Team
B,
because
we've
already
got
that
in
place.
A
B
A
A
Now
we're
gonna
go
ahead
and
create
some
pods
inside
of
here
all
right.
So,
let's
see,
if
we
can,
we
can
throw
this
together
all
right.
So
inside
of
here
we're
gonna
make
a
pod
called
ta
just
to
keep
it.
Keep
it
easy.
So
ta
ta
will
be
the
pod
that
runs
the
team,
a
namespace.
So
it's
going
to
make
a
pod
called
ta
da
camel
inside
of
here.
Alright,
alright,
so
pretty
simple,
we'll
just
kind
of
create
one
out
of
the
gate
here
and
then
we'll
copy
and
paste
that
over
all
right.
A
So
this
pod
is
API
one.
The
kind
is
pod
I
ranked
inside
a
pod.
We
have
the
ability
to
put
in
metadata
which
will
give
us
a
name.
The
name
will
be
team,
a
the
name.
Space
will,
of
course,
be
team
a
and
then
this
is
something
that
will
be
important
to
our
policies
later,
but
we
have
the
ability
to
apply
labels
inside
of
these
policies
right.
So,
as
you
might
be
aware,
with
Todd's
you
can
set
up
labels,
and
the
label
inside
of
here
can
be
just
arbitrary
data.
A
Now,
a
really
common
one
that
I've
seen
people
use
is
they'll
have
an
app
label
inside
of
here,
and
in
this
case
the
app
label
will
call
it
ta.
So
we
can
identify
this
pod
as
the
app
ta
and
then
they
might
have
other
things
as
well
like
if
I
wanted
I'm
gonna
run
nginx
here
so
like,
let's
say
that
the
run
label
identified,
like
maybe
the
container,
that
I'm
running
or
the
executable
whatever
it
might
be,
just
random
arbitrary
labels,
but
things
that
we
can
actually
act
on
and
use.
Okay,
alright.
A
A
When
the
pod
starts,
if
the
image
for
this
particular
tag
is
already
there
just
use
it
otherwise
go
ahead
and
download
it
from
the
registry
and
then
the
image
itself
which
I've
got
on
my
repo
in
docker
hub.
So
that's
my
name
and
Jeannette
curl
v2,
alright!
So
overall,
this
should
be
a
pretty
solid
pod,
spec
here
and
then
inside
of
this
pod
spec.
A
Let's
go
ahead
and
put
a
service
in
as
well
because,
as
you
might
remember,
from
learning
about
kubernetes
pods
might
recycle,
especially
if
they're
fronted
by
things
like
deployments
and
their
IPs
might
change,
and
so
on
so
oftentimes
we'll
set
up
a
service
which
is
basically
like
a
virtual
IP
that
we
can
use
to
access
the
pot
right,
and
this
will
tie
into
our
network
policy
a
little
bit
as
well.
Okay,
so
not
too
different,
I'm,
just
gonna
go
ahead
and
copy
some
of
these
basic
things
up
here
so
still
be
one.
A
The
type
here
is
going
to
be
service.
Okay,
our
metadata
name
is
going
to
be
team.
A
our
namespace
is
going
to
be
team
a
and
then
our
spec
for
service
will
look
a
little
bit
different,
so
the
spec
is
going
to
have
a
section
called
ports.
Okay,
ports
will
have
an
array
that
will
be
the
the
ports.
We
want
to
specify.
Okay,
so
I'm,
going
to
start
off
by
saying
I
want
port
80.
All
right.
This
will
be.
A
Have
this
service
exposed
called
TA,
it
is
going
to
allow
traffic
in
through
TCP
on
port
80
and
it
will
route
it
to
the
pods
on
port,
80
and
I
know
my
pod,
my
container,
if
you
will
exposes
itself
on
port
80,
so
I
should
be
able
to
use
that
and
then
last
but
not
least,
services
also
need
a
selector.
So
let
me
just
bring
this
back
one
cool,
so
the
services
need
a
selector
and
that
selector
is
basically
going
to
be
what
we
had
above
here.
A
So
we
know
that
this
particular
pod
has
the
label
apt,
EA
and
just
like
we're
gonna,
do
a
network
policy
pretty
soon
here
we're
going
to
introduce
the
selector
app
and
call
this
team
a
right
all
right,
so
I've
got
a
service
in
place.
We've
got
a
pot
in
place
now
the
chance
that
I
did
all
this
right
without
a
typo
is
pretty
unlikely.
But
let's
see
what
we
let
me
come
up
with
here.
A
A
Is
there
any
way
to
make
Calico
dns
elf,
seven
aware
so
on
that
question,
bill
calico
in
dns
would
usually
be
separate
things.
So
maybe
you
could
clarify
the
question
of
it
like
there
are
ways
to
do
things
with
calico
network
policy,
where
you
can
do
like
layer,
seven
oriented
policy
like
HTTP
methods
and
things
like
that.
But
maybe,
if
you
clarify
the
question,
I
think
that
the
term
DNS
is
confusing
me
there
so
see.
If
you
can
help
me
out
there
bill
cool,
so
we've.
A
That's
teammate
just
like
that,
so
let's
go
ahead
and
do
the
same
thing
for
Team
B,
so
we're
gonna
go
ahead
and
write
in
a
TB
dot.
Yeah
Milles
here,
alright
and
I
will
open
up
TV,
let's
hop
over
to
watch
the
TV
namespace
seems
pretty
good,
alright
and
then
we've
got
ta,
which
I
am
going
to
replace
with
TB
and
we'll
replace
with
TB
all
right
TB.
B
A
A
I've
got
this
pod
here.
This
is
our
team.
B
pod
TB
running
the
same
image.
It's
running
in
the
team,
B
namespace
we've
got
the
service
with
the
selector
pointed
to
TB.
Up
top
seems
good.
So
let's
go
ahead
and
try
to
apply
this
thing
and
see
if
it
creates
down
here
in
this
namespace.
Alright
great
so
we've
got
the
ta
pod
and
then
we've
got
the
TB.
B
A
A
Is
ta
right
then
the
service
label
was
T,
makes
I'm
getting
name
space
in
the
Hat
and
the
label
they're
mixed
up.
So
this
should
be
ta.
No
big
deal
we'll
just
correct
that
then
we'll
apply
it.
Cool
I
should
change
the
service
there,
all
right.
So,
let's,
let's
do
some
sanity
checking
here.
Okay,
so
we've
got
team.
A
we've
got
all
right.
So
inside
of
Team,
a
we've
now
got
the
ta
pod.
B
A
So
we
will
there
we
go
so
we
will
grab
this,
make
it
black
like
the
box
there
we
go
good
good,
all
right
and
then
a
team
B
in
blue.
We
have,
of
course,
got
the
TV
pod
running
now
as
well.
Okay,
all
right!
So
here's
the
deal,
we're
gonna
do
a
quick
test
here,
but
these
simple
images
or
containers
I
expect
the
ability
to
go
in
and
to
go
in
and
actually
communicate
fully
right
without
any
issue
at
all
right.
So
so
teammate
can
communicate
with
team
B
team
B
can
communicate
with
team.
B
A
A
I
totally
see
what
you're
saying
I'm
sorry
that
that
makes
so
much
more
sense.
So
I
know
that
calicos
Network
policy
API
they
have
their
own
custom
resource
definition.
I'm
gonna
be
showing
you
that
later
today
it
does
have
some
support
for
layer.
Seven,
so
I've
seen
it
before
be
able
to
do
path
and
verb.
I
would
guess
that
it
could
do
hostname
as
well.
A
Maybe
Duffy
can
check
for
us
or
answer
he
might
already
know,
but
we'll
check
on
that
a
little
bit
later,
when
I
open
up
the
Calico
CRD,
because
there
are
some
layer,
seven
concepts,
you
may
very
well
be
able
to
do
domain
names
as
well
or
DNS
records
for
your
for
your
network
policy.
Great
question
all
right
so
back
to
our
machine
here.
Alright,
let's
go
ahead
and
just
test
this
out
real,
quick,
alright,
so
I
have
two
exact
commands
set
up,
so
in
my
top
window,
I
will
be
exacting
into
ta
inside
of
teammate.
A
B
A
A
B
A
Of
these
these
pods
here
right.
So
if
I
wanted
to
send
a
request
out
to
team
B
from
Team
A,
one
of
the
things
that
you're
able
to
do
in
kubernetes
is,
you
can
say,
team
a
are
sorry:
Team
B,
the
pod
TV
dot,
the
name
space,
TV
T
team
B.
So
this
is
going
to
do
a
lookup
for
the
service
DNS
record
for
this
particular
pot
or
sorry
for
this
particular
service.
Really
so
I.
Look
it
up
and
it's
gonna
say.
B
A
Tb
team
b
service
cluster
local-
it's
this
address
here
right,
so
if
I
were
to
curl
that
same
address,
I
will
get
an
engine.
X
page
back
to
me
and
same
goes
with
down
here,
so
we
can
curl
the
T
a
in
this
case
team
a
right
and
we'll
get
an
edge
next
page,
so
pods
can
inter
communicate,
which
also
means
that
they
can
accept
ingress
traffic
right
now
and
also
that
they
can
send
traffic
outside
as
well.
Alright,
so.
A
B
A
Up
the
CNI,
and
then
it
generally
just
opens
the
traffic
altogether
okay,
but
we
have
the
ability
to
add
network
policy,
which
is
obviously
the
crux
of
this
episode
and
we're
gonna
take
a
look
at
how
exactly
this
impacts,
the
the
kind
of
model
that
we're
so
far
seeing
here
with
kind
of
ease
of
this
open
network
all
right.
So,
let's.
A
Hypothetically
I
want
Team
a
to
be
able
to
egress
to
team
B,
okay,
but
I,
don't
want
team
a
to
be
able
to
send
traffic
out
to
the
external
internet.
So
let's
use
that
as
an
example.
Real
quick,
all
right,
I'm
gonna
just
draw
a
quick
line
here,
so
the
key
thing
that
we
want
to
disallow
all
right.
If
we
kind
of
jump
over
this
line
here,
we
want
to
disallow
this
path
for
Team
a
we
only
want
team
a
to
be
able
to
it
or
communicate
in
the
cluster
in
areas
like
that.
A
So
this
two
team,
beep,
should
be
no
problem
but
again
going
to
the
external
web
should
not
work
okay.
So
this
is
obviously
something
that
we
can
use
network
policy
to
enforce
all
right
now,
going
back
to
actually
getting
the
network
policy
set
up
here.
All
right,
let's
flip
over
here
and
I-
am
going
to
get
out
of
that
window.
Get
out
of
this
window
all
right
and
we're.
B
A
Make
a
network
policy
okay!
So
how
do
we?
How
do
we
approach
actually
looking
at
this,
this
network
policy
stuff?
Alright?
So
just
to
kind
of
pull
up
the
kubernetes
documentation
here?
Alright,
there's
a
whole
page
on
network
policy
and
honestly
I
forget
the
network
policy
API
all
times
so
I'm
oftentimes
coming
here,
just
to
kind
of
see
how
how
some
of
these
things
work.
Okay
and
actually
I-
found
the
example
here
to
be
to
be
pretty
solid.
So
I'll
tell
you
what,
let's
just
copy
the
example
alright
and
we'll
break
it
down
and
see.
A
B
A
The
network
policy
here,
okay,
I'll,
move
this
out
of
the
way
and
we'll
call
this
team.
A
egress
got
em
all
and,
let's
put
it,
may
be
met
Paul
at
the
beginning,
so
that
we
don't
mix
up
our
different,
manifests
all
right
so
and
well,
maybe
just
get
rid
of
this
for
now,
all
right
cool,
great
all
right!
So
let's
break
this
down
here.
So
we
have
a
network
policy.
Api
object
right
and
we
have
a
name
inside
of
here
as
well.
Okay,
so
the
name
in
this
network
policy.
A
We
will
again
call
Team
a
B
dress
right
and
this
namespace
will
go
inside
of
team
a
now.
An
important
thing
to
note,
as
we
get
into
some
of
the
other
API
is
that
you
can
use,
is
that
Network
policy
and
kubernetes
is
name-space.
Scoped.
Okay,
that's
an
important
detail,
so
we
create
these.
We
can't
do
like
you
know
how,
like
with
our
back
there's
cluster
roles
and
roles
right
and
create
something
on
a
cluster
level
or
a
namespace
level,
but
with
network
policy
they're,
just
namespace
scope.
That's
that's
effectively!
A
A
Now
we
know
that
we
want
this
to
go
on
Team
a
right.
So
once
again,
we've
got
one
of
those
match:
labels,
alright,
and
if
we
look
at
team
a
for
just
a
moment
here,
the
ta,
the
mo
file,
we
know
that
it
has
the
label
app
ta
right.
So
if
we
go
back
up
to
where
we
have
role
and
we
do
app
ta,
okay,
this
policy
should
apply
to
that
ta
app.
Okay.
A
Now
we
have
policy
types
which
are
important.
So
what
we're
going
to
end
up
doing
here
is
we're
gonna
end
up
applying
a
list
of
allow
okay,
because
that's
what
network
policy
is
as
an
API,
it
defines
things
that
you
want
to
allow
network
traffic
wise,
so
think
about
that.
For
a
moment,
you
can't
set
up
deny
rules.
Okay,
you
can
only
add,
allow
rules
so
when
we
apply
these
policy
types
think
for
a
moment
about
what
doesn't
happen
or
sorry,
let's
let
phrase
it
this
way.
A
What's
gonna
happen
to
the
network
paths,
the
egress
and
ingress
traffic
that
you
don't
define
in
this
document
think
about
that
for
a
moment.
So
right
now
we
know
it
just
allows
everything
by
default,
but
once
we
apply
this
policy,
if
this
is
a
list
of
allow
rules,
what
is
going
to
happen
to
the
non
explicitly
called
out
rules
right,
so
we
can
delete
and
rest
for
now,
you're
only
concerned
about
egress
right
all
right,
and
that
means
we
can
get
rid
of
this
whole
ingress
block
we'll
come
back
to
it
all.
A
The
sample
that
we
have
here
right,
the
egress-
this
is
kind
of
interesting.
It
has
a
cider
block.
Now
we
know
going
back
to
our
diagram.
We
know
that
our
pod
cider
is
10,
3000,
16
right
so
you're,
just
kind
of
naively
looking
at
this
and
exploring
it
for
a
moment
right.
We
can
go
in
and
say
10
30000
16.
A
So
theoretically,
we
should
now
be
able
to
route
to
pots
right
and
then
the
protocol,
of
course,
is
TCP
and,
as
we
know,
this
is
going
to
be
port,
80,
okay
and
Shaun
our
network
policy
stateful,
so
that,
if
you
allow
us
it
will
allow
the
response.
Yes,
yes,
okay,
cool,
so
you've
got
the
answer
there.
Yes,
it
will.
A
It
will
allow
the
response
in
regards
to
the
traffic
coming
back,
because
I
can
see
how
you
can
almost
visualize
that
as
ingress
right
in
a
certain
world,
but
yes,
that
the
request
response
is
all,
let's
think
of
it,
like
one
unit
for
right
now,
okay,
cool,
great
question,
so
IP
block,
we
got
the
sire.
We've
got
the
ports
again,
not
I'm
just
playing
around
here.
So
we'll
see
how
all
this
goes,
so
we
have
a
cider.
Let's
save
it
up.
A
B
A
A
Into
team
a
all
right
and
ta,
there
we
go
so
we've
got
bin
bash
start
and
I'm
inside
of
the
ta
pod.
Now,
okay,
can
we
go
to
google.com/chrome
google.com?
We
can't
so.
Apparently
we
are
blocked
on
a
network
level,
so
we've
achieved
it
at
least
so
far.
We've
achieved
it
right,
ta
going
to
Google
seems
to
be
blocked.
Obviously,
if
we
looked
up,
Google's
IP
address
I'm
sure
it's
not
in
the
10.30
range
right
that
wouldn't
make
that
much
sense:
okay,
cool,
so
good
good!
Now
what
about
the
traffic
we
wanted
to?
Laos!
B
A
A
A
A
You've,
basically
flipped
your
model
here
right,
you've
gone
from
this
model
of
the
pod
tbta
allows
everything
right,
but
then
you've
introduced
network
policy
wherein
you
have
set
up
to
match
this
pod
and
to
set
up
policies
for
egress,
which
means
now
that
we
have
a
list
of
explicitly
allowed
egress
rules.
Okay,
everything
that's
not
defined
here
is
blocked.
We've.
B
A
B
A
A
Let's
see
if
we
can
fix
this
up,
so
we
go
back
inside
of
the
team,
a
pot
down
here
in
the
bottom
and
then
we
just
introduce
you
know
another
another,
two
or
actually
well.
First,
let's
expand
this.
So
let's
do
zero,
zero,
zero,
slash,
eight
right,
okay
and
then
we've
got
this
in
place,
so
we're
basically
opening
up
traffic
all
over
to
that
whole
site
or
age
right,
so
we'll
save
it
up.
A
B
A
B
A
B
A
We
curl
Team
B,
now
we're
going
through
the
motions
right
so
now
we've
unlocked
our
ability
to
contact
DNS,
which
is
actually
running
in
the
cluster.
Technically,
that's
at
least
the
first
DNS
point
we
talked
to.
So.
If
we
add
us
lookup,
google
comm,
we
get
an
IP.
If
we
nslookup
TV
team
b
ranks,
we
get
an
IP
and
of
course
we
can
curl
it
as
well,
but.
A
Still
can't
get
to
google.com,
okay.
So
again,
this
is
just
an
example
showing
when
you
add
these
rules
in
just
kind
of
grazing,
through
the
chat
here,
but
I
think
kind
of
like
to
Duffy's
point
down
there
at
the
bottom,
about
the
implicit,
allow
right,
we've
kind
of
flipped-
that
at
least
for
this
namespace,
at
least
for
this
selected
pod
right.
A
Another
misconception,
I
oftentimes
talk
to
customers
about,
is
they
think,
oh
once
I
add
a
network
policy
in
the
namespace.
It
just
blocks
all
traffic
by
default,
but
your
pod
selector
is
critical
here
right,
so
we've
really
only
impacted
the
pods
with
an
apt
EA
label
and
we've
actually
only
impacted
their
egress
abilities.
They
still
have
the
ability
to
accept
again
right
and
we
could
prove
this
pretty
easily.
A
If
we
exit
out
of
here
and
exact
into
that
team,
beep
HOD
real
quick,
we
can
still
curl
team
a
right
and
that
will
still
work,
so
we
haven't
impacted
in
grass.
We've
only
Apep
impacted
egress
on
this
particular
on
this
particular
pot.
Okay,
so
another
big
thing
about
our
are
our
pods
here.
Our
network
policy
on
our
pods
is
a
lot
of
times.
We
won't
want
to
use
IP
addresses
right,
like.
A
A
A
Let's
try
to
keep
this
exact
same
model
in
place,
but
let's
do
it
based
on
labels
rather
than
site
or
ranges
in
the
case
of
kubernetes
here,
okay,
so
we
go
back
to
the
Linux
machine
and
we
will
edit
to
that
one
more
time,
all
right.
So
inside
of
egress
okay
inside
of
egress,
we
currently
have
a
to
rule
for
an
IP
block.
Now
inside
of
the
kubernetes
docks,
you
may
have
seen
that
we
actually
have
the
ability
to
specify
a
namespace
selector
and
a
pod
selector
in
here
as
well.
B
A
Want
to
egress
track
up
to
based
on
labels,
so
let's
go
ahead
and
take
this
model
real,
quick
and
see
if
we
can
just
reuse
it
real
fast
to
kind
of
update
our
existing
block
all
right.
So
this
is
in
our
two
block,
all
right,
so
that's
good
there.
That
seems
good
pod
selector
seems
good
and
then
I'll
just
get
rid
of
IP
block
real
quick
IP
block,
10
0,
K
cool
cool,
and
you
know
what
we'll
do
just
to
make
this
a
bit
cleaner,
I'm
gonna,
add
another
another
to
expression
here.
A
So
we'll
do
two
ok
and
then
we'll
bring
that
in
one
more
time
so
namespace
selector
looks
good,
alright,
so
we'll
get
the
IP
block,
as
is
to
make
sure
that
DNS
still
works
for
UDP
53,
okay,
and
we
can
do
fancier
stuff
like
we
should
be,
allowing
traffic
to
cube
system
or
something
like
that
right,
but
we'll
just
keep
this,
as
is
for
DNS,
make
sure
make
sure
it
still
works.
Okay,
so
and
Sean
you
asked:
can
you
specify
a
pod
selector
without
a
namespace
selector
which
would
match
all
pods
with
that
selector?
A
No
matter
what
the
namespace,
that
is
an
awesome
question
I
will
answer
that
in
an
example
and
just
a
second
here,
so
it's
actually
kind
of
tricky
how
the
namespace
and
pod
selector
play
together.
It
messes
with
my
brain
all
the
time,
there's
like
a
30%
chance.
I'll
get
this
wrong,
but
I'll
try
to
demonstrate
it
here.
So,
let's
start
off
with
just
a
namespace,
selector,
okay,
so
I'm
gonna
comment
out
the
pod
selector
right.
A
This
is
kind
of
like
your
question
Sean,
but
reverse
like
just
just
the
namespace
selector
right,
I,
totally
get
where
you're
going
with
this.
But
if
we
go
into
the
match
labels,
okay,
let's
go
ahead
and
change
this
to
app.
We'll
change
this
to,
let's
see
we're
egressing
to
TB
or
it's
the
team,
D
namespace
right
all
right!
So,
theoretically,
with
this
in
place,
it
should
work.
So
if
we
have
a
team
B
in
place,
it
should
allow
the
traffic
there.
A
So
let's
go
ahead
and
save
this
up,
see
if
we
have
any
typos
or
anything
weird
like
that,
so
net
Paul
path
does
not
exist.
Let's
see
here,
cube
cuddle,
apply
net
Paul,
new
dress,
okay,
that's
good
cool,
so
I've
reapplied
to
grass.
Let's
go
ahead
and
exact
back
into
team
ank
to
see.
If
we
can
do
this
teamate,
alright,
we're
back
in
two
min.
Can
we
curl
team,
be
the
namespace
OTB
dots
team
be
alright
and
we
seem
to
be
blocked
because
I
messed
up.
My
labels,
like
I,
always
do
as
I
had
mentioned.
A
I
should
not
have
named
these
so
similar
wow.
This
is
killing
me
today.
So
apt
is
TB,
but
this
demonstrates
hopefully,
if
it
works
in
a
second.
This
should
demonstrate
that
it's
working
right
so
I'll
save
that
up.
Oh,
you
know
what
I'm
I'm
off
here,
we're
on
a
namespace
selector
right,
so
namespace
selector
I
need
to
have
the
name
of
the
namespace
right,
which
is
teammate
now.
This
is
an
interesting
thing,
because
we
need
the
label
of
the
team,
a
namespace
that
is
name.
So
some
of
you
might
be
aware
of
this
problem.
A
You
don't
necessarily
have
labels
on
your
namespaces
right
away.
Okay,
so
the
first
thing
I
need
to
do
is
I
need
to
use
the
cute
cuddle,
able
command,
okay
and
I
need
to
say,
go
ahead
and
label
this
namespace
okay
and
we're
gonna
label
it.
The
team,
a
namespace,
we're
gonna
label,
it
name
equals
teammate
all
right,
so
we've
labeled
the
namespace,
which
is
going
to
then
allow
us
to
utilize.
Namespace
selectors
set
up
policies
on
the
namespace,
okay,
so
kind
of
had
it
right.
A
B
A
Here
right,
come
on
Josh,
alright,
so
again
we're
egress
into
team
B.
So
we
need
that
this
is
good.
We'll
have
both
new
spaces.
Note
both
namespaces
labeled
right,
yeah,
you're,
totally
right
Sean.
If
only
there
wasn't
lag
in
the
video
you'd,
be
you'd,
be
fixing
my
problems
before
before
I
actually
mess
it
up
myself.
So
let's
go
ahead
and
label
that
so
let's
do
team,
D
and
then
we'll
label
that
team
B's.
A
A
Exact
into
team
a
then
we
curl
TV
dot
TV.
Now
we
have
an
unguent
ax
page
okay,
so
we
can
open
up
the
e
graphs
to
an
entire
namespace.
No
problem
now
check
this
out.
This
is
the
thing
that
always
trips
me
up
and
it
kind
of
gets
a
little
bit
closer
to
Shawn's
question.
So,
if
I
uncomment
this
pod
selector
here,
let's
say
I,
don't
want
to
allow
traffic
to
all
of
the
team.
A
A
Then
we
do
the
label
of
TB.
This
should
technically
still
work
right,
so
I'll
apply
it.
Okay
and
I
will
curl
it
and
it
seems
like
it
still
works
right
now.
Obviously,
like
any
good
test
is
not
good
unless
you
test
the
failure
condition,
so
I
could
just
kind
of
pull
the
curtain
over
your
eyes
and
say:
oh,
it
works,
but
let's,
let's
try
this
out.
So
if
we
do
TC,
which
we
know
is
not
a
label
right,
in
fact,
let's
just
do
something
like
this
right:
this
should
break
it.
A
A
Got
pod
selector
here
match
labels
TV,
and
then
we
go
ahead
and
apply
this
alright
and
it
does
fail.
So
you
you'd
need
some
level
of
like
that
name,
space
selection
mechanism.
If
there
is
a
way
to
do
blanket,
pod
selection
across
the
entire
cluster
I,
don't
know
if
how
to
do
with
the
native
API
I
do
know
how
to
do
it
with
some
of
the
additional
api's
that
things
like
calico
and
psyllium
offer,
but
more.
B
A
A
A
Gonna
have
a
line
here,
that's
gonna,
say
ingress
instead
right
and
instead
of
two
we're
gonna
have
from,
but
the
same
mechanism
supply
you're
just
worried
about
where
the
traffic's
coming
from,
rather
than
where
the
traffic
is,
is
going
to
write,
if
that,
if
that
sort
of
makes
sense,
so,
let's,
let's
just
do
it
a
simple
ingress
example:
real,
quick
just
so
I
can
kind
of
kind
of
show.
You
show
you
how
this
works
right
shouldn't
take
too
long.
So,
let's
say
hypothetically
that
Team
B
is
a
service
inside
of
kubernetes.
A
B
A
I
just
kind
of
zoom
in
here,
let's
give
G's,
hang
tight.
You
switch
my
keyboard
over
still
getting
used
to
this
drawing
pad
you
all
will
have
to.
Let
me
know
at
some
point
if
these
preschool
level
drawings
are
all
helpful
for
understanding
this
stuff
I'm
just
giving
it
a
shot
today
to
see
if
it's,
if
it's
any
good,
all.
A
A
A
Rule
all
right
now
to
do
this,
let's
hop
back
to
our
machine
and
let's
just
demonstrate
real,
quick,
that
TB
is
accessible.
So
again,
we
know
that
if
we
curl
TB,
we
are
able
to
to
to
go
in
and
access
the
spot.
Now.
How
about
externally
so
check
this
out
look
way
inside
of
kubernetes
weep
geez,
once
I
learn
how
to
spell
clear
inside
of
kubernetes
if
we
do
a
get
service
inside
of
the
name
space
team
be
here
so
TB
we've
got
this
service.
That's
exposing
this!
This
pod
right
and
we
know
services.
A
Just
virtual
ip's,
basically,
and
if
in
our
networking
fabric
we
can
tell
our
router
about
how
to
get
to
this
virtual
IP,
then
we
can
actually
route
to
our
services.
Theoretically,
we
came
in
route
to
our
pods.
If
we
wanted
to
right
so
to
demonstrate
this.
Here's
one
thing:
I
can
do
I
think
I
still
have
the
command
terminal.
B
A
A
So
inside
of
the
routing
table
in
my
computer,
I'm,
basically
going
to
say
that
if
you're
going
to
this
address,
okay
I
am
going
to
send
it
to
this
gateway,
which
is
actually
one
of
my
kubernetes
house,
so
I'm,
basically
cheating
here
right.
It's
like
adding
something
to
my
hosts
file,
almost
right,
I'm,
basically
going
to
say.
If
you
go
to
this
virtual
IP
machine
I,
actually
want
you
to
use
this
virtual
machine
that
I
have
running
kubernetes
as
my
gateway.
A
So
if
we
curl
this
address
now-
and
this
is
just
from
my
local
machine-
alright-
it's
great
I
can
get
to
nginx.
So
I
am
the
stick
figure
person
and
I
am
allowed
to
request
nginx,
even
though
the
IP
on
my
computer
is
not
coming
internally
from
the
cluster
alright.
So
let's
go
ahead
and
fix
this
with
an
ingress
role.
A
Alright,
so
we'll
go
ahead
and
save
this
as
net
Paul,
Team
B
ingress
camel
okay,
let's
go
ahead
and
edit
that
Nepal
Team
B,
okay,
alright
easy
stuff
here,
so
we
basically
just
have
to
chop
this
thing
up,
just
to
kind
of
show
you
how
similar
it
is
right.
So
we
know
that
the
namespace
is
gonna,
be
team.
B,
we're
gonna,
call
this
team
B
ingress
right.
We
know
that
the
app
name
we
want
to
apply
this
to
is
TV.
Sorry,
let
me
let
me
switch
back
to
my
screen
here.
A
A
B
A
To
doesn't
make
much
sense
within
dress
because
we
don't
care
where
we're
going
to
we
care
where
we're
coming
from
right,
so
that
will
be
for
now
we've
kind
of
already
set
ourselves
up.
This
is
sort
of
perfect
right.
We've
got
a
namespace
selector
here.
We've
got
even
the
really
tight
permission,
so
let's
go
ahead
and
set
this
to
team
a
right
and
we've
got
the
app
ta.
A
B
A
A
B
A
Ingress
perspective
is
going
to
be
blocked
implicitly
now
for
the
pods,
with
app
TB
as
their
label
all
right.
So,
let's
see
what
I
messed
up
here.
Okay,
so
we're
gonna
go
ahead
and
it's
good
our
curl
ready
actually
on
the
on
my
host
here.
So
this
is
just
my
host
in
the
bottom.
We
will
apply
this
network
policy,
so
apply
the
net
Paul
Team
B
oops.
That
was
too
fast.
Sorry,
okay,.
A
A
B
B
B
A
A
So
let's
talk
about
this
API
now
here's
the
deal-
and
this
is
this-
is
like
the
requirement.
I
almost
always
get.
What
once
we
talk
to
the
customer
and
they
say:
let's
talk
about
network
policy
and
we
go
okay,
here's
what
you
can
do
they
instantly
say
awesome.
So
how
do
I
make
my
entire
cluster
deny
all
by
default
right.
B
B
A
Bunch
of
things
that
you
can
actually
put
into
that
namespace,
alright
and
sorry
for
those
sirens,
you
can
hear
them
I'm
sure
you
probably
can
hopefully
they'll
be
gone
in
a
second,
so
you've
got
a
namespace.
What
are
the
kinds
of
things
that
you
might
put
in
a
namespace?
Well,
obviously,
one
of
the
super
common
ones
is,
you
might
put
our
back.
Actually
let
me
just
label
this
robux.
This
is
gonna,
be
a
namespace
right.
A
So
some
of
the
things
you
might
put
in
here
are
our
back.
Ok,
you
might
put
in
quotas,
so
these
would
be
things
like
how
much
CPU
or
memory
you
think
the
workloads
gonna
take
all
right.
You
also
might
put
in
limits
which
are
sorta
like
Lotus,
but
have
a
bunch
of
other
implications,
because
the
the
resources
that
you
allow
it
can
actually
be
in
force,
and
that
can
be
good
and
bad
depending
on
how
you
look
at
it.
A
A
So
what
does
that
look
like
if
we
go
in
here?
What
a
lot
of
people
end
up
doing
in
my
experience?
Is
they
end
up
creating
the
sky
and
it
almost
is
always
called
the
exact
same
thing,
the
namespace
create
or
alright-
and
you
know,
luckily,
there
are
some
open
source
projects
around
this
now
I,
don't
know
any
of
them.
Offhand
I
think
like
github.
Might
have
released
one
I
can't
recall,
maybe
someone
knows
they
can
link
it
in
chat,
but
basically
the
idea
of
namespace
creator
is
some
person
or
system.
A
A
And
they
like
fill
out
some
kind
of
form.
Okay,
and
this
form
is
like
hey.
My
team
needs
a
name
space
in
this
kubernetes
cluster
right.
Well,
that
forms
paper
or
digital
or
literally
automated,
and
nobody
fills
anything
out
that
just
depends
on
how
against
the
company
is.
But
usually
this
paper
ends
up
making
CRD
okay
and
then
that
CRD
is
looked
up
by
the
namespace
creator.
Okay
and
then
the
namespace
Kreider
goes
in
and
it's
a
controller
just
like
anything
else.
B
B
A
When
people
say-
and
this
is
just
one
example
right-
it
is
something
that
this
pattern
may
be
something
that
people
do
use
Sean
as
an
example
like
you
haven't
seen
this
yet
right
like
it's
something
that
I've
seen
quite
a
bit
when
folks
are
starting
to
make
their
clusters
a
little
bit
more,
like
multi
team,
I,
don't
really
want
to
say,
multi
tenant
because
that
sometimes
harder
and
more
complicated
but
like
they
have
more
people
onboarding.
They
want
to
kind
of
slice
out
all
these
defaults.
B
A
A
The
team,
a
or
sorry
team,
a
my
brains,
all
over
the
place
here
they
have
the
default.
Deny
all
examples
so
like
this
one
is
a
default
deny
all
for
all
ingress
traffic
and
the
egress
traffic.
One
doesn't
look
too
different
at
all
right,
it's
actually
a
pretty
simple
model.
So
if
you
make
a
policy
that
looks
something
like.
B
A
So
let's
go
ahead
and
we'll
create
one
called
default:
deny
all
team
a
ok,
so
we
make
a
network
policy.
It
looks
like
this
all
right
and
then
inside
a
pod
selector
we
open
up
a
curly,
brace,
we
close
a
curly
brace
think
of
this
like
an
asterisk.
This
is
like
a
select
all-star,
more
or
less
okay
and
then
for
ingress
same
thing
rather
than
putting
it
a
bunch
of
ingress
rules,
we're
just
keeping
it
kind
of
blank
here,
which
is
basically
our
way
of
saying
I
want
to
sorry
I
plan,
rapid
owl,
yeah.
B
A
A
Here's
our
default
tonight
all
to
your
point,
Rory
good
catch.
So
again,
the
pod
selector
thing
was
right
now,
starting
to
notice
it
with
the
ingress
piece
because
it
was
doing
select
all
on
all
the
rules.
Basically
right,
so
pod
selector
is
select
all
right.
It's
applies
to
every
pod
in
this
namespace.
Okay
and
our
namespace
might
be
again
TV
and
then
the
policy
type
is
egress
and
you'll
notice
that
we
are
completely
absent
of
the
egress
rules
itself
by
keeping
it
blank.
A
We
flip
the
model
on
its
head,
turn
it
to
a
denial,
and-
and
that's
it
so
now,
if
we
apply
this
to
the
team,
D
namespace,
all
egress
traffic,
let's
try
this
out
real
quick
should
be
blocked
for
default
denial
team,
a
okay,
so
we'll
keep
that
consistent.
Let's
do
a
teammate
here,
all
right,
so
we'll
apply
default
denial
of
team,
a
we're
still
in
the
team,
a
pod
up
here.
A
B
A
B
A
A
B
A
B
A
A
Just
go
back,
I'll
kind
of
show
you
what
I
was
what
I
was
looking
at
here,
so
the
team
be
alright
thing
that
I
was
trying
to
access
I
had
an
allowable
in
place,
as
I
showed
in
the
diagram
I've
deleted
that
egress
rule.
So
now
the
only
thing
I
have
applied
right
is
the
default
deny
all
for
team
a
so
inside
the
team,
a
pod.
A
If
I
go
to
curl
team,
B,
I
freeze
up
and
nothing
works,
okay,
which
is
exactly
what
we
expect
and
if
we
go
in
here
we
can
then
delete
the
default,
deny
all
alright,
and
if
we
go
back
team
B
now
we're
working
again.
Okay,
so
I
will
remember
to
switch
back
and
forth
this
time.
Hopefully
so
now,
we've
got
this
created.
We've
got
the
network
policy
in
place,
pretty
cool,
so
the
thing
I
want
to
kind
of
wrap
up
with
today
is
talking
about
alternative
api's.
A
You
can
use
to
achieve
the
same
thing
and
achieve
other
things,
so
the
only
the
only
problem
that
I
have
with
this
model
and
again
I
have
helped
implement
this
model.
It's
not
I'm,
not
trying
to
say
it's
bad,
there's
just
trade-offs
right.
So
the
one
thing
that
I
always
consider
with
this
model
is
what
ends
up
happening
oftentimes.
Is
you
end
up
with
these
network
policies
that
are
like
your
default
policies?
You
have
in
every
namespace
right.
So
let's
say
that
whatever
namespace
creator
runs.
B
A
So
that's
not
the
end
of
the
world,
but
like
what
do
you
think
about
this?
If
you
want
to
make
a
change
to
the
network
policy
right,
you
now
have
all
these
instances
of
network
policies
scattered
all
over
the
place,
and
you
need
to
worry
about
changing
them
everywhere,
right.
Hopefully,
your
namespace
creator
is
smart
enough.
We're
like
you,
can
update
some
master
config
and
it
can
reconcile
all
of
the
you
know,
namespaces,
but
again,
like
kind
of
like
cluster
roles
with
our
vac
I.
Keep
going
back
to
that.
A
A
All
right
cool
all
right,
so
they
are
only
namespace
scoped,
and
this
could
be
a
feature
for
you.
Right
like
this
could
actually
potentially
be
a
good
thing,
depending
on
how
you
look
at
it,
but
in
our
case
it's
at
least
a
limitation
to
be
aware
of
their
only
namespace
scoped
all
right
and
for
the
most
part
they
don't
allow.
What
I
consider
to
be
advanced
expressions.
A
B
A
Then
destination,
depending
on
how
you've
got
this
set
up
from
an
ingress
or
egress
level
right
now,
a
lot
of
these
CNI
providers
recognize
that
there
are
some
limitations
in
the
ingress,
API
and
maybe
I
should
even
call
them
limitations.
It's
like
it's
a
generic
API
that
satisfies
many
CN
eyes.
It's
awesome
for
that.
A
But
if
you
want
to
do
things
more
specific
to
the
provider,
you
might
need
a
more
advanced
API
to
do
that
with
okay,
so
I'm
gonna
switch
away
from
this
white
board
in
just
a
second,
but
I
want
to
just
pull
up
one
piece
of
documentation
and
have
it
ready
for
you
when
I
switch
over.
So
you
see
if
I
can
pull
this
up,
that
looks
good.
Okay,
let's
bring
back
my
Linux
machine,
so
calico
as
an
example
and
cilium
has
their
own
as
well.
A
That
I'm
aware
of
calico
has
a
set
of
network
policy
CR
DS.
Now
these
C
R
D's
have
a
larger
set
of
features.
Okay,
as
an
example,
you
can
just
see
from
the
sample
here.
You
have
the
ability
to
do
these
more
like
expression,
looking
like
syntaxes
okay.
So
as
an
example
in
the
spec,
you
can
do
things
like
I
want
to
see.
If
I
can
show
you
some
of
the
different
selectors
here
right,
so
here's
some
of
the
selectors
you
can
do
equals
you
can
do
not
equals
you
can
say
contains.
A
A
Calico
converts
it
into
some
data
model
and
then
it
respects
all
that,
even
if
you
mix
their
CR
DS
with
kubernetes
specific
network
policies-
okay,
so
some
pretty
cool
stuff
inside
of
here
they've
even
got
application
layer
policy
which
I
believe
I
can't
remember
who
was
asking
about
it
earlier
and
Duffy
I.
Think
you
feel
that
some
of
the
the
question
there,
but
this
is
probably
where
the
answer
would
lie
in
regards
to
whether
you
can
do
layer,
7
policy
with
calico
now
again.
B
A
Normal
network
policy-
it's
not
possible
to
express,
but
with
calico,
as
you
can
see
here,
it
looks
like
paths
and
methods
are
the
key
things
and
I
think
Duffy.
You
were
expanding
on
the
hostname
concept
and
why
that's
harder
right,
but
effectively,
you
can
see
that
at
least
some
of
the
feature
sets
are
starting
to
get
more
advanced
and
even
go
into
some
of
the
higher
levels
of
the
OSI
model.
If
you
will
okay,
so.
B
A
A
Used
this
thing
quite
a
bit
to
solve
some
of
those
use
cases.
I
was
telling
you
about
so,
as
the
name
implies,
as
you
could
probably
guess,
global
network
policy
allows
you
to
define
network
policy
that
applies
to
the
entire
cluster
okay,
so
you
have
these
CR
DS
that
will
define
general
and
the
model
that
I've
seen
work.
Quite
a
bit
is-
and
this
is
oftentimes
in
like
really
large
boards,
where
the
clusters
are
hosting
multiple
teams
right
where.
B
A
Gonna
basically
put
in
the
global
network
policy,
okay
and
they
are
going
to
basically
be
able
to
set
like
what
are
the
sensible
defaults.
What
is
maybe
you
want
it?
Maybe
you
want
to
to
stop
all
egress
and
ingress
traffic
by
default,
and
you
want
the
app
developers
to
explicitly
define
kind
of
like
they
could
it
with
security
groups
in
AWS
right
to
define
what
ingress
they
want
to
allow
and
what
egress
they
want
to
allow
okay.
So
this
is
really
really
great
for
that,
because
the
network,
administrators
or
whoever
it
is,
can
apply.
A
B
A
B
A
A
Okay
and
oftentimes
you'll
get
even
fancier
like
you'll,
have
admission
control
in
place,
so
you
validate
the
the
access
web
developers
are
asking
for
or
web
developers
app
developers,
whoever
it
is
are
asking
for
and
you
either
approve
or
deny
it
there's
fancy
stuff
you
can
do,
but
it's
it's
kind
of
nice.
So
looking
through
chat
Mardin.
A
B
A
B
A
A
lot
of
times
what
I
end
up
seeing
is
you
have
a
global,
Network
policy?
Okay,
that
applies
to
the
entire
cluster,
so
you've
got
your
global
network
policy
document
right
alright,
and
this
applies
to
the
cluster,
and
then
you
have
your
users
right
or
network
teams,
whoever
it
is
and
they're
going
in
and
they're
basically
applying
a
network
policy
right.
So
this
is
not
a
global
network
policy,
but
just
a
network
policy
like
a
kubernetes
Network
policy,
you've
been
seeing
right
and
rather
than
just
accepting
that
often
times,
you'll
have
OPA.
A
B
A
A
Into
Duffy's
point
down
there,
you
can
do
validating,
you
could
do
mutating
as
well,
so
you
know
have
things
get
mutated
eyes?
Just
apply
these
policies,
it's
kind
of
a
nice
flow.
You
can
kind
of
see.
This
is
the
beauty
of
the
composable
nature
of
kubernetes
right.
You
can
kind
of
see
how
all
these
pieces,
plug
together
and
as
a
platform
as
a
piece
of
your
platform.
A
Is
saying
that
cig
networking
is
maybe
talking
about
doing
some
type
of
implementation
with
global
network
policy?
That
is
awesome
again.
I
probably
sound
like
a
calico
fanboy
here,
but
they
deserve
some
credit
right,
like
back
in
the
day,
I
remember
only
calicos
network
policy
supported
like
egress
policy,
expression,
right
and
I.
Remember
they
build
this
thing
out.
They
included
how
it
would
be
shown,
and
then
they
worked
in
cig
networking
to
bring
that
into
the
generic
API,
because.
A
Ingress
was
like
the
only
definition,
at
least
to
my
memory
right.
So
that's
really
awesome.
I
would
love
to
see
something
that
happen
again
where
global
network
policy
gets
adopted
on
that
level.
Okay,
so
I'm
gonna
end
today
by
showing
you
a
global
network
policy,
I'm
gonna
show
you
some
tools
that
are
kind
of
cool
things,
for
you
to
check
out
and
I've
kept
you
all
for
a
very
long
time,
so
we're
gonna
wrap
up
in
about
five
to
ten
minutes
here.
Okay,
so
here
here's
our
here's,
our
final
wrap-up,
all
right.
A
So
if
we
look
at
a
global
network
policy,
I'm
just
gonna
pull
up
one
that
I
have
already
created
here
and
I
will.
I
will
share
this
by
the
way
in
the
in
the
github
as
well.
But
let
me
just
pull
this
alright,
so
this
is
gonna,
be
my
example:
global
network
policy,
great
all
right
cool.
Let's
take
a
look
at
this
real,
quick
all
right,
so
this
is
the
CR
D
and
I
have
got
it
heavily
documented,
because
I
had
a
feeling.
A
A
So
the
network
policy,
with
calicoes
API
and
against
cilium,
has
a
bunch
of
advanced
feature
sets
too,
but
the
global
network
policy
with
calicoes
api
actually
allows
you
to
do
ordering.
So
you
can
get
really
fancy.
I
would
also
argue
really
complicated
with
your
network
policy,
because
you
can
actually
define
deny
and
allow
rules
with
their
API,
which
is
good,
gives
you
a
lot
of
flexibility,
but
can
make
things
more
complex,
so
you
can
actually
order
how
all
these
things
work.
A
Now,
a
long
time
ago,
I
asked
somebody
at
calico
or
I
think
was
actually
a
tiger.
Employee
I
asked
them
hey.
You
know
how
do
I
know
what
we're
to
put
my
global
network
policy
and
basically,
if
I
put
it
up
mm
it
is.
It
is
good
when
people
submit
kubernetes
global
network
call
or
sorry
kubernetes
Network
policy.
It
automatically
gets
a
value
of
1000,
at
least
that
used
to
be
the
case.
A
So
what
what
I'm
getting
at
here
is
the
lower
order
takes
precedence,
the
larger
order,
so
the
reason
I
want
global
network
policy
to
be
2000
is
because,
as
network
policies
get
added
in,
they
don't
have
an
order
in
their
API
right.
That's
just
the
kubernetes
network
policy.
Calico
automatically
converts
that
and
assigns
1,000
by
default.
At
least
they
used
to
and
by
making
sure
global
number
policy
is
2000.
I
will
make
sure
that
people
can
overwrite
this
global
rule
right.
So
here's
my
global
network
rule
as
an
example.
Okay,
so
this.
B
A
A
What
this
says
is:
hey
I'm
gonna,
allow
all
egress
traffic
for
any
pod
running
and
cube
system
and
a
lot
of
times
my
customers
will
have,
or
the
people
I
work
with,
will
have
more
system,
level,
namespaces
and
just
cube
system,
so
we'll
actually
make
an
array
of
all
the
namespaces
that
they
want
to
use
right.
Additionally,
from
an
egress
perspective,
we
allow
UDP
everywhere,
because
we.
A
A
couple
use
cases.
Nonetheless,
we
open
up
UDP
egress
for
any
pod
inside
of
the
entire
cluster
all
right,
and
then
we
basically
allow
ingress.
In
this
case.
This
is
one
we
sometimes
end
up
modifying
to
anything
trying
to
get
in
to
cube
system,
so
cube
system
allows
ingress
and
that's
it
now.
Anything
that
is
not
specified
here
is
denied
okay.
So
we
apply
this
policy
and
we
have
completely
locked
out
the
cluster,
except
for
DNS
cube
systems,
ability
to
egress
and
our
ability
to
ingress
traffic
to
cube
system.
Everything
else
is
locked
down.
A
Okay,
so,
let's
see
if
I
can
apply,
this
I
haven't
even
tested.
This
example
a
really
long
time,
so
maybe
that'll
be
good.
Oh,
you
know
what
actually
so
I'm
gonna
I'm
gonna
leave
this
as
homework
for
you
all
to
apply.
If
you
try
it
so
I
should
be
using
Calico
CTL.
They
have
their
own
command
behind
utility
to
apply
this
and
I,
don't
think
I
have
Cal.
I
do
have
calico
CTL
Wow.
That
is
not
expected.
Okay,
let's,
let's
see
what
happens,
this
might
be
early
version
of
calico.
Ctl
failed!
Oh
right
right!
A
Alright,
let
me
just
grab
some
really
old
documentation,
apparently
on
how
to
do
this.
Okay,
so
alright,
so
yes,
cool,
yeah,
I,
so
Duffy
is
right.
I
can't
just
apply
the
manifest
I
thought
Duffy
correct
me.
If
I'm
wrong,
I
thought,
calico
CTL
did
some
additional
validation
right
and
that's
why
they
still
recommended
it,
but
maybe
with
the
structured
schema
thing
that's
been
introduced,
see
our
DS.
Maybe
that's
not
actually
a
problem
anymore,
I'm
not
entirely
certain.
Maybe
you
can
give
us
some
insight
on
that.
You
only
live
once.
A
A
Basically,
I
had
to
tell
the
CTL
that
it
was
using
calico,
kubernetes
datastore,
which
means
calicoes
talking
to
the
API
server
around
the
net.
Cd
and
I'd
have
to
point
it
to
my
cube
config.
Just
so
you
know
that's
that's
effectively
why
it
failed.
Let's,
let's
see
what
happens
here,
it's
it's
Friday,
we're
all
about
to
get
out
for
the
day,
anyways
right,
hopefully
so.
A
What
I'll
I'll
update
this
for
you
all
and
I'll
post
it
in
my
example,
but
this
this
is
an
example
of
again
going
back
to
our
white
board
here.
This
is
an
example
of
how
we
could
basically
do
this
default
Network
policy
on
a
global
level.
Okay,
so
I
just
need
to
get
my
schemas
right
and
then
you
can.
You
can
effectively
apply
this
inside
of
here
guessing.
B
A
Api
version
has
changed,
so
let's
get
my
keyboard
back
over.
Hopefully
this
gives
you
a
pretty
good
idea
of,
like
all
the
different
network
policy
chunks,
how
global
network
policy
works,
how
you
can
expand
on
that
Network
policy
and,
if
you,
if
you
ever
play
with
network
policy
in
your
clusters
and
start
to
bang
your
head
against
the
desk
thinking,
why
has
stuff
stopped
working?
Hopefully
this
video
would
be
a
good
resource
for
that.
There's,
a
couple
things
that
Duffy
and
I
have
put
together.
A
A
It
sounds
like
it's
right
in
your
wheelhouse
honestly,
but
it'd
be
cool
to
kind
of
talk
about
some
of
the
tools
and
ways
that
we
can
check
like
how
is
network
being
blocked,
how
our
packets
getting
routed
blah
blah
blah
blah
blah.
That
would
be
a
really
interesting
one,
but
there's
a
couple
resources
that
are
gonna
be
in
the
readme
in
our
in
our
in
our
hack
MD.
One
of
those
is
augment
has
a
really
really
good
recipes
page.
A
You
should
check
it
out
what
I
love
about
this
is
his
diagrams
move
because
they're
gifts,
but,
most
importantly,
some
of
these
things-
I've
been
talking
about
like
allow
all
traffic
to
an
application.
I
click
on
this
readme
right
and
it
gives
an
example
of
what
the
network
policy
looks
like
and
most
of
them
had
those
really
nice
fancy
diagrams.
Let
me
see
if
I
can
find
one
deny
all
traffic.
Do
you
have
one.
A
A
lot
of
them
have
these
cool
diagrams
and
then
an
actual
example
of
what
you
can
apply
so
basically
like
a
much
shortened
version
of
the
things
we've
been
talking
about
so
check
out
his
reference.
We've
got
that
in
the
hack
MD,
it's
really
cool.
This
one
is
sweet.
I
haven't
gotten
to
try
it
so
I
don't
want
to
vouch
for
it.
Quite
yet,
cuz
like
it
relies
on
some
like
IP
tables,
logging
of
packet
traffic.
So
I,
don't
really
know
how
that
impacts
the
system
just
yet
and
how
exactly
it
works.
A
I've
only
looked
at
it
today,
but
it's
really
neat.
Basically
what
this
does.
If
I,
if
I
read
the
story
correctly
box,
the
company
uses
calico
and
they
were
getting
really
frustrated
with
wanting
Stanley,
where
packets
getting
blocked
and
how
is
all
the
stuff
working,
because
one
thing
I
didn't
mention
is
a
lot
of
this
stuff
happens
depending
on
your
CNI,
but
a
lot
of
this
stuff
actually
happens
in
IP
tables,
with
Calico
right
or
at
least
inside
of
the
host,
with
Calico
to
kind
of
block
traffic,
and
things
like
that.
A
So
this
this
tool
called
cube.
Ip
tailors
basically
allows
you
to
run
a
daemon
set
instead
of
IP
tables
logging
on
your
hosts.
Okay,
and
then
you
can
do
this
command
cube,
cut'
will
describe
pods
and
you
can
actually
get
or
you
can
actually
do
I
think
again.
Events
would
work
too.
You
can
do
it
get
events
for
your
namespaces
and
it
will
actually
tell
you
where
the
packets
were
dropped.
That's
pretty
freaking,
cool
and
I
know
a
lot
of
people
pay
like
like
I
know:
ty
Guerra
has
an
enterprise
product
a
lot
of
these.
A
A
B
A
This
is
like
a
step
in
that
direction
right,
at
least
it
will
give
you
some
visibility
into
how
packets
are
being
dropped
based
on
the
IP
table
logs,
and
things
like
that,
so
you
can
actually
see
the
impacts
and
troubleshoot
the
impacts
of
your
network
policy,
pretty
cool
stuff
and
another
one
that
I
have
technically
haven't
tested.
I'm
sorry,
I
wish
I
could
vouch
for
some
of
these
things,
but
I
love.
A
The
idea
cuz
this
in
particular
I
have
built
versions
of
it
in
bash
before
I'm
sad
to
say
it's,
it's
been
very,
very
ugly
and
Mike
goodness
from
formally
from
Ticketmaster
now
at
MLB.
If
you
ever
talk
to
him,
he
can
tell
you
the
horror
stories
of
that
thing.
Actually,
I
think
he
might
have
Ronit
so
I'll
blame
him.
Anyways
netzer
allows
you
to
write
tests
about
the
network
traffic
in
your
cluster
okay.
So
this
could
make
your
network
team
pretty
happy.
You
have
all
these
policies
floating
around
right
going
back
to
our
diagram.
A
Maybe
you
have
one
of
these
self-service
models
in
place
right
we're
effectively.
Our
our
little
person
here
is
basically
submitting
network
policy
in
and
it's
going
through,
oppa
and
blah
blah
blah
right.
So
this
is
actually
going
to
allow
you
I'll
just
go
down
to
one
of
their
example
tests.
This
is
going
to
allow
you
to
set
up
these
test
cases
that
define
what
you
are
able
to
access,
and
then
it
can
run.
These
tests
drive
your
cluster
and
tell
you
what
may
have
failed.
A
A
Hopefully,
you
learned
some
cool
things
about
network
policy.
It's
been
such
a
pleasure
spending
the
end
of
this
Friday
with
you
all
some
of
you,
your
Saturdays
and
yeah.
We're
we're
super
looking
forward
to
seeing
you
all
next
Friday,
okay,
so
so
tune
in,
will,
will
post
soon
what
that
episode's
going
to
be
and
we'll
see
you
next
week
have
a
great
weekend.
Everybody
see
ya.