►
From YouTube: CNL: Setting up monitoring for Calico’s eBPF Data Plane
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
every
week
we
bring
a
new
set
of
presenters
to
showcase
how
to
work
with
cloud
native
technologies.
They
will
build
things
and
they
will
break
things
and
they
will
answer
your
questions
so
join
us
every
wednesday
to
watch
live,
and
this
week
we
have
chris
from
taguera
here
with
us
to
talk
about
amazing
topics.
As
always,
and.
A
B
Yeah
hi
there
thank
you,
so
my
name
is
chris
tompkins.
I'm
a
lead
developer
advocate
at
tigera
tigera
make
a
piece
of
software
called
calico,
which
is
an
open
source
cni
for
kubernetes.
I
did
a
previous
session
actually
on
cloud
native,
live
and
lots
of
other
sessions.
You
can
find
on
youtube
about
calico,
generally,
so
in
the
interest
of
timing
and
seeing
the
things
we
want
to
see
today,
I
won't
go
too
much
further
into
that
today,
but
yeah.
A
B
There
we
go
yeah,
perfect
correct,
so
I'm
people
will
be
pleased,
I'm
not
going
to
every
part
of
this
diagram,
but
what
we're
looking
at
here
is
actually
the
flow
of
traffic
through
a
linux
node,
and
this
image
is
courtesy
of
yan
engelhart.
It's
you
can
see
it
on
on
wikipedia,
but
what
this
actually
shows
us
is
as
a
packet
comes
into
a
kubernetes,
node
or
any
linux
host.
B
It
comes
in
on
the
left-hand
side,
it
works
through
this
complex
flowchart
and
then
it
and
then
packets
leave
on
the
right-hand
side.
Now
the
reason
I've
got
this
diagram
up
is
because
there's
a
fair
amount
of
complexity
going
on
here
and
and
people
who
are
familiar
with
computer
networking
will
know
that
you've
got
the
link
layer,
network
layer
and
and
protocol
and
application,
and
most
of
the
packet
processing
thing
happens
in
in
the
collectors
in
the
middle.
B
B
Great,
so
so,
with
with
eppf,
you
can
attach
our
networking
code
at
these
hooks
before
and
these
hooks
at
the
end
of
the
packet
flow,
and
you
can
actually
do
the
networking
outside
of
this
flow,
and
in
doing
so,
you
avoid
needing
to
go
through
most
of
the
complexity
in
the
middle
of
the
diagram.
So
just
to
kind
of
restate
it.
What
we're
seeing
here
is
an
ebpf.
It
is
a
is
a
linux
node
we
use
eppf
and
then
we've
reimplemented
calico's
kubernetes
data
plane
in
ebpf
as
one
choice.
B
So
the
cool
thing
is
because
you're
attaching
at
the
start
and
end
and
you're,
avoiding
some
of
that
complexity.
I've
really
wanted
to
avoid
having
a
lot
of
slides.
So
I
should
say
up
front.
I've
only
got,
I
think,
it's
three
more
slides
after
this
and
then
we'll
dive
straight
into
a
live
demo.
But
the
key
these
key
benefits
apply
across
all
environments.
B
You
basically
get
improved
performance,
and
that
happens
because
when
you
attach
code
at
those
ebps
hooks
you're
running
the
code
inside
the
linux
kernel
with
the
performance
that
you
would
expect
to
gain
there
and
you
can
you
can
cut
out
bits
of
code
that
you
didn't
intend
to
run.
So
you
get
you
get
better
performance
which
is
less
cpu
or
more
throughput,
which
are
opposite
sides
of
the
same
coin.
B
You
get
native
kubernetes
service
handling
that
we'll
talk
about
more
in
a
moment,
and
then
you
get
source
ip
preservation
and
direct
server
return.
I'm
going
to
dive
into
all
of
these,
but
very
superficially,
because
I've
done
much
longer
talks
on
all
of
these
things
and
the
previous
cloud
native
live
session
discussed
these.
So
I
feel
like
if
people
want
to
see
these
in
detail,
they
should
check
out
those
older
sessions,
but
I'm
just
gonna.
They
need
to
be
said
today.
B
B
So
when
we
rewrote
the
data
plane
in
ebpf,
we
had
to
replace
kuproxi's
functionality,
but
instead
of
that
being
a
negative.
Actually,
we
re-implemented
a
ton
of
the
code
and
improved
upon
it.
So,
as
well
as
the
performance
improvements
that
I
mentioned
before,
I
can
actually
jump
forward
to
yeah
here
yeah.
You
can
see
that
there
are
three
different
ways
to
implement
coup
proxy.
B
Technically,
it's
not
good
proxy,
but
it's
that
same
functionality
and
what
we're
seeing
in
this
graph
is,
as
you
add,
more
services,
ipvs
and
ebpf.
The
connect
time
remains
constant,
regardless
how
many
services
you
have
and
the
eppf
data
plane
is
even
faster,
but
the
ip
tables
data
plane,
the
old
way
of
doing
things
was
basically
increasingly
slow,
as
you
added
more
services
to
your
cluster,
so
you've
got
performance.
You've
got
that
tcp
connect
time
advantage,
which
just
be
really
frank.
B
If
you
only
had
a
couple
of
services,
you
wouldn't
notice
it
and
you
wouldn't
care,
but
if
you
have
a
large
number
of
services
or
a
lot
of
session
churn,
then
you
really
start
to
care
about
this
and
then
the
last
big
advantage
really
is
that
this
one
source,
ip
preservation,
which
is
where,
as
an
external
client,
comes
into
your
cluster?
So
at
the
bottom
of
the
diagram,
we've
got
these
two
kubernetes
nodes.
Now
this
could
be
50
kubernetes
nodes.
B
It
depends
on
how
many
is
in
your
cluster,
but
as
your
external
client
comes
in,
their
traffic
hits
coupe
proxy.
So
what
we're
seeing
here
is
the
coup
proxy
way
of
doing
things
without
our
ebps
data
plane,
and
you
can
see
that
the
first
thing
that
happens
is
the
coup,
proxy
destination
maps
and
sourcenaps
the
traffic,
and
it
does
that
to
make
sure
that
the
traffic
gets
forwarded
across
to
the
service
pod
correctly,
but
also
the
source
that
is
required
to
make
sure
that
the
traffic
returns
back
through
coop
proxy.
B
So
then
the
traffic
gets
forwarded
onto
the
service
pod
and,
as
you
can
see,
as
a
result
of
the
destination
there
and
the
source
nap,
the
pod
never
sees
the
ip
address
of
the
external
client
and
the
side
effect
of
that
is
that,
let's
say
you
have
an
an
auditing
requirement
to
capture
your
to
capture
your
client's
ip
source,
ip
address
on
the
service
pod.
You
wouldn't
be
able
to
do
that
with
the
crew
proxy
implementation.
B
So
I'm
speeding
through
this
a
bit
but,
like
I
said
if
people
want
to
hear
this
same
content,
but
in
a
bit
of
a
more
peaceful
way,
then
I
would
suggest
going
back
to
that
previous
one.
So
when
you
enable
calico
evpf
instead
of
that,
the
source
now
happening,
the
bbf
bpf
code
happening
on
the
kubernetes
node
forwards,
the
traffic
across
without
needing
the
source
net,
and
that
basically
means
that
the
service
pod,
that's
actually
serving
the
customers
or
clients.
B
Workload
actually
does
see
the
real
ip
address
of
the
external
client,
which
means,
maybe
you
want
to
block
a
certain
country
or
or
a
certain
set
of
users.
I'll
avoid
saying
the
obvious
example
at
the
moment,
then
you
could
do
so
using
this
code,
so
yeah
that
that's
it
at
a
really
high
level.
I'll
move
on
to
the
next
slide
in
a
moment.
A
Perfect
really
great
extensive
advantages
there
yeah
and
everyone,
as
I
said
in
the
chat
as
well,
leave
all
of
your
questions
throughout
the
presentation
as
well
to
the
chat
box
and
and
your
streaming
service,
and
we
will
get
to
them
throughout
the
presentation
as
well
as
in
the
end
but
yeah
chris.
What
are
what
targets
are
then
available.
B
You
want
to
be
monitoring
all
the
components
of
it
right
so
both
to
capture
logs
and
so
on
when
things
go
wrong,
but
also
proactively,
like
distributed
systems
are
complicated,
so
we
tend
to
proactively
monitor
as
many
components
as
possible.
So
when
I
was
thinking
up
this
session,
what
I
wanted
to
capture
was
this
idea
that
just
to
talk
about
what?
What
components
can
we
actually
monitor
in
this
data
plane?
What
data
can
we
capture
and
how
do
we
go
about
doing
that?
B
And
so
in
a
moment
when
we
build
this,
cluster
you'll
see
that
it's
got
four
nodes
and
there'll
be
some
service
pods
running
in
each
node
and
then
because
we're
using
the
ebpf
data
plane
on
each
node,
the
logic
that
that
actually
helps
the
comp.
The
traffic
come
in
on
a
service
and
get
redirected
to
a
pod,
either
on
the
same
node
or
on
another
node,
that's
implemented
in
ebpf
and
using
maps
to
store
the
the
data
that
needs
to
be
stored.
B
To
do
that
now
there
are
three
components
that
can
be
monitored
here,
specifically
for
the
data
plane
and
I'll
show
you
how
to
set
up
all
three,
so
the
first
is
typhum.
Now
I
should
have
to
be
honest
with
you.
I
should
have
had
this
on
the
diagram
and
it
slipped
my
mind
to
add
it,
but
in
any
kubernetes
deployment
you
have
the
kubernetes
api
and
that's
something
that
lots
of
components
within
the
cluster
need
to
speak
to
and
anytime.
B
Now
they
are
actually
again
pods
that
run
in
the
cluster
and
their
job
is
to
perform
actions
based
on
the
cluster
state.
So
maybe
a
new
node
gets
created.
Excuse
me,
a
new
pod
gets
created,
it's
calico
coupe
controller's
job
to
set
up
the
networking
to
to
match
the
desired
state,
so
we'll
be
able
to
monitor
that
as
well,
and
then
the
final
one
you've
got
this
agent
called
felix,
which
is
our
agent
that
runs
on
every
node.
So
felix
is
the
thing.
B
A
B
No,
it
doesn't
make
service
mesh
obsolete,
but
there's
there's
a
larger
conversation
that
we
could
have
and
I
have
had
several
times
actually
the
most
recent
time
we
talked
through
this
in
detail
was
we
do
this
session
called
calico
live
and
if
you
look
back
on
the
most
recent
calico
live,
I
think
that's
where
I
was
discussing
it.
We
talked
a
bit
about
this.
Oh
no
excuse
me,
it
wasn't.
I
knew
I
was
wrong.
That's
why
I
was
hesitating.
It
was
devsecops,
london
gathering.
B
We
had
a
chat
about
this
on
their
podcast,
which
will
be
released
soon,
but
a
service
mesh
adds
a
lot
of
extra
functionality
above
and
beyond
the
cni.
They
can
complement
each
other,
but
this
doesn't
replace
that
functionality.
What
this
replaces
is
the
functionality
of
the
traditional
iptable
cni
that
we
run.
B
B
B
The
same
functionality
is
happening
in
the
day
inside
the
data
plane,
and
so
therefore,
it
no
longer
needs
to
run
as
a
separate
part.
So
it
replaces
it
so.
The
ebpf
implementation
isn't
good
proxy,
but
it
does
the
same
job
with
slight
improvements
like
the
source,
ip
preservation.
Essentially,
I
guess
I
could
address
one
more
thing,
which
is
depending
on
the
nature
of
your
kubernetes
cluster,
how
you
turn
off
the
proxy
varies.
B
So
in
the
case
of
what
we're
going
to
do
today
with
well,
that's
a
good
opportunity
for
me
to
talk
about
what
we're
going
to
build.
Actually,
as
you
can
see,
we're
going
to
use
google
cloud
we're
going
to
build
a
four
node
cluster
with
the
pod
subnet
192.168.16
and
the
addressing
10
to
40
24
for
the
nodes
and
in
the
case
of
gcp,
because
this
is
just
vanilla,
kubernetes
we're
going
to
turn
off
coupe
proxy
by
stopping
the
demon
set.
B
But
if
you
run
something
else
like
k3s,
where
coupoxy
can't
be
turned
off,
because
it's
not
running
as
a
separate
component,
then
there's
different
ways
to
disable
that
functionality
and
the
project
helicopter
documentation
for
ebpf,
which
I
think
I
may
have
a
link
to
at
the
end.
If
I
remember
correctly,
it
actually
tells.
B
Yeah
yeah,
it
would
be,
it
would
be
ideal,
so
yeah,
let's
dive
in
so
I'm
going
to
do
the
demo
now,
but
before
we
do
this
is
the
last
slide.
I
think
there
is
an
oddity
and
I
thought
I
would
I
would
point
it
out
at
this
point,
and
that
is
that
so
here
we
have
three
nodes.
I
don't
know
why
I've
shown
three
nodes
here
rather
than
four
on
my
previous
diagram.
B
We
don't
use
a
service
like
that.
We
use
the
service
to
discover
the
location
of
the
felix
agents,
but
what
I've
tried
to
show
here
with
the
dotted
lines
and
the
crosses
is
that
we
don't
actually
use
the
service
for
polling.
We
only
use
it
to
discover
where
the
things
that
we
want
to
monitor
are,
and
then
the
polling
traffic
actually
goes
directly
to
the
phoenix
agent
on
each
node.
B
B
Well,
actually,
we
are
going
to
dive
straight
in
now,
so
I
think
watch
this
demo
now
and
see
if
it
answers
that
question,
because
I
think
it
it
probably
will,
and
if
not
we
can,
we
can
answer
it
again
at
the
end
or
I
can
take
it
at
the
end.
So
I
should
have
a
terminal
here,
let's
see
if
this
works
now
I
was
apologizing
to
annie
before
we
started
that
I'm
having
a
minor
problem
with
my
it
set
up
today.
B
So
I
am
not
on
my
usual
setup,
which
means
that
I'm
going
to
be
looking
down
here,
a
lot
more
than
normal.
So
I
apologize
for
not
looking
at
the
camera.
What
I'm
talking
about?
Hopefully
you.
Hopefully
you
can
put
up
with
my
side
profile,
no
so
yeah,
so
to
start
with.
I've
bought
I've
built
this
for
four
node
cluster
and
I
built
it
literally
45
minutes
ago.
B
So
the
details
are
exactly
the
same,
but
you
can
see
that
the
status
is
not
ready
and
that's
because
I
wanted
to
show
the
whole
process,
including
building
the
evf
data
plane
onto
this.
But
again
I'm
going
to
do
the
ebpf
part
enable
enablement
part
quite
quickly,
because
we've
already
done
this
in
a
in
a
webinar.
So
I
so
I
thought
that,
although
it's
nice
to
see
it
again,
I
didn't
want
to
spend
too
long
on
it
so
oops.
B
A
B
B
B
Here
we
go,
we've
got
a
four
node
cluster
master,
node
and
three
other
nodes,
everything's,
not
ready,
which
is
what
we
expect
and
the
reason
it's
not
ready
is
because
there's
no
networking
on
this
cluster,
yet
there's
no
calico,
no
other
cni.
So
it's
not
ready.
So
we
can
see
the
pods
and
we
can
see
that
the
dns
pods
are
pending
because
they
have
no
networking
and
everything
else
is
running,
but
not,
but
there's
no
networking
and
there's
no
mention
of
calico
here.
B
B
Piece
of
yaml
here-
and
this
is
an
installation
resource-
it's
a
custom
resource
and
it
tells
the
tigera
operator
that
we
want
to
install
calico.
We
want
to
use
this
ip,
addressing
this
block
place
and
vxlan
and
vxlan
is
the
right
encapsulation
to
use
when
you're
using
the
bbf
data
plane.
So
the
only
other
customization
at
this
point-
that's
important.
Is
this
typhometrics
port?
B
So
with
all
that
said,
if
I
now
just
feed
that
yammel
to
excuse
me,
I
just
had
a
missed
call
from
my
daughter,
I'm
gonna
watch
that
and
just
if
she
calls
back,
I
may
have
to
take
that
because
she's
only
12
and
she's
on
her
way
home
from
school.
So
I'm
sure
I'm
sure
the
audience
will
need
to
take
it.
If
she
calls
back
I'll
I'll
have
to
pick
it
up.
A
B
Yeah,
let's
let's
push
on
for
a
moment
and
then
we'll
come
to
those
so
hopefully
everything's
over
under
control
over
there,
I'm
going
to
keep
looking
over
there
now.
Excuse
me,
okay,
so
what
I've
done?
Is
I've
fed
that
manifest
which
we
saw
before
to
the
tiger
operator
and
that
and
as
a
result,
the
operator
has
gone
away
in
its
creative
nodes,
you'll
notice
that
there's
one
per
kubernetes
node
and
then
it's
created
the
typher,
the
fanout
agent
and
it's
createless.
B
And
if
you
recall
these
are
the
three
things
that
we're
going
to
set
the
monitoring
up
for
as
well
we're
going
to
monitor
calico
controllers,
we're
going
to
monitor
felix,
which
is
part
of
this
pod
and
then
we're
going
to
monitor
typho
the
fanat
agent.
So
while
I
was
doing
a
little
check
there,
those
things
were
coming
up
anyway,
so
we
didn't
really
lose
any
time.
So
that's
okay!
So
we
have
enabled
calico
on
this
cluster
now,
which
is
why
the
dns
servers
are
running,
but
we
haven't
yet
enabled
ebpf.
B
So
I'm
going
to
do
that
now
now.
One
nuance
of
this
is
that
we
need.
We
need
felix.
The
agent
to
be
talking
directly
to
the
kubernetes
api
and
that's
because
it
usually
talks
to
the
kubernetes
api
through
coupe
proxy
and
you
can
spot
the
problem
that
since
we're
taking
proxy
away
so
what
we
do
is
we
have
a
quick
look
and
we
look
at
an
existing
config
map
for
coop
proxy
and
we
find
out
where
the
kubernetes
api
server
lives.
B
So
here's
its
address
and
here's
its
port.
So
the
next
thing
we
do
is
I
prepared
some
yaml
beforehand
that
looks
like
this
and
we're
going
to
apply
a
config
map
in
the
tiger
operator
namespace
and
that's
going
to
tell
calico
that
it
needs
to
talk
directly
to
the
kubernetes
services
endpoint
and
and
within
the
details
here.
B
Yeah
good
okay,
so
we
can
see
that
as
soon
as
we've
applied
that
yaml,
the
tiger,
restarting
the
other
components
to
tell
them
to
reconfigure
them.
Essentially
now
I
do
this
last
command
kind
of
superstitiously
and
I'll
probably
get
told
off
later
for
doing
this
by
my
colleagues,
but
it
used
to
be
a
long
time
ago
that
you
need
the
tiger
operator
pod
to
make
it
re-read
this
config
map
that
we
created.
B
A
Yes,
perfect
and
to
quickly
answer
rahim
about
the
journal
screen
seeing
a
bit
blur.
I
am
not
experiencing
at
least
the
same
issue,
so
you
can
maybe
try
refreshing
your
browser
or
closing
tabs
and
and
so
forth,
but
then
to
get
to
the
technical
questions
we
had
one.
Is
it
possible
to
deploy
both
q
proxy
and
edf
and
parallel
in
order
to
migrate
so
put?
In
other
words,
how
would
you
replace
q
proxy
by
edf
on
a
running
in
production,
cluster.
B
B
I
always
say
the
same
thing
when
I,
when
I
discuss
this,
which
is
in
theory,
you
could
enable
the
bpf
data
plane
on
a
running
cluster
and
as
long
as
you
met
the
prerequisites,
you
wouldn't
have
any
outage
you.
Basically
any
new
server
as
it
changed
over
any
new
flow
would
start
to
use
the
new
data
plane.
Any
old
flow
would
use
the
old
data
plane
in
practice.
B
I've
been
networking
for
20
years
and
I
I'm
too
cautious-
and
I
think
you
know
in
practice
why
make
your
life
difficult
it's
best
to
to
have
just
to
use
the
data
plane
from
the
start?
Having
said
that,
depending
on
your
appetite
for
risk,
it
is
actually
possible
to
non-disruptively
switch
over
and
as
long
as
you
follow
this
sequence,
which
I'm
going
to
go
through
now,
then
then
it
will.
B
On
performance
or
production
services,
so
now
that
we've
stopped
the
felix
agent
from
talking
directly
to
sorry
to
from
talking
to
coop
proxy.
The
next
step
is
to
remove
couproxy.
So
that's
what
we're
going
to
do
now
and
I
mentioned
earlier
how
this
can
be
done
in
different
ways
depending
on
your
deployment.
B
In
this
case,
I'm
going
to
patch
the
daemon
set
and
for
coup
proxy
demon
set
is
just
a
construct
that
tells
kubernetes
to
run
something
on
every
node.
So
what
I'm
actually
saying
here
is
I
want
to
daemon
set
for
cuproxy,
I'm
going
to
patch
it
and
modify
and
say
I
only
want
it
to
run
nodes
which
are
not
running
calico,
which
is
the
same
thing
as
saying
I
don't
want
it
to
run
at
all
right
because
they're
all
running
calico,
so
you
could
have
here.
B
B
And
then
the
last
step
is
to
to
enabling
the
epf
data
plane
is
to
run
this
command
and
what
what
that's
actually
doing
is
it's
patching
the
insulin
and
merging
in
this
new
bit
of
config,
specifying
that
we
want
to
use
bpf
data
plane
and
that's
it.
So
you
can
see
that
calico
node
is
restarting
again.
B
You
can
see
that
one
of
them
has
restarted
and
the
other
three
haven't
yet,
but
they
will
in
a
moment-
and
that's
it
so
now
just
to
just
to
take
us
into
you
know
and
to
kind
of
discuss
where
we
are
and
make
sure
we're
all.
On
the
same
page,
now
we're
running
a
four
node
cluster.
It's
running
calico
ebpf
data
plane
with
vxlan
encapsulation
q
proxy
is
gone.
Felix
is
talking
directly
to
the
api
and
we
have
typha
the
fanout
agent.
B
We
have
two
instances
that
are
running
and
they
are
running
a
metrics
node,
because
the
original
point
of
this
session
was
to
show
the
metrics.
So
so
we've
turned
on
metrics
for
those
two
and
we're
going
to
now
go
ahead
and
show
you
how
to
actually
see
those
metrics
did
you
want
to
address
any
other
questions
before
I
dive
into
that.
B
You
will
find
that
in
the
documentation,
if
you
go
to
you'll
find
that
it
describes
the
exact
pretty
much
the
exact
steps
that
I'm
taking
now-
and
it
tells
you
to
do
that
on
different
cluster
types
as
well.
So
you
just
have
to
identify
what
what
is
your
cluster
type
and-
and
it
will
tell
you
how
I
am
there's-
also
a
blog
post.
B
B
A
B
Type
us
running,
so
let's
have
a
look,
so
we
you
can
see
that
all
the
nodes
have
restarted,
which
is
intentional.
So
we
can
see
that
we're
running
two
type
of
nodes-
and
these
are
the
ip
addresses
of
those
nodes.
Now
typha
runs
with
host
networking.
That
means
it
doesn't
have
a
portable
ip
address
of
its
own.
It
uses
the
host's
ip
address,
so
if
we,
this
command
is
quite
long.
A
B
Okay,
so
a
ton
of
metrics
came
back
and
all
we've
really
been
doing
at
this
point
is
proving
that
typha
is
there
and
it's
responding
with
with
metrics.
So
that's
cool
okay,
so
the
next
thing
we
do
is
we
create
a
service
to
expose
them.
Now,
if
you
recall
what
I
said
about
how,
unlike
a
normal
kubernetes
service,
this
is
actually
going
to
get
used
to
discover
the
felix
agents,
but
it's
not
actually
going
to
be
used
to
pull
them.
That's
done
separately,
I'll!
Show
you
how
later
on.
B
We
can
see
that
we
are
able
to
hit
the
service
directly
and
we'll
get
some
metrics
back
now.
Just
to
reiterate
that
point,
when
we
actually
monitor
this,
this
is
not
how
we'll
do
it
we
won't.
We
won't
ever
hit
this
for
metrics,
because
this
actually
illustrates
the
problem
nicely,
because
if
you
hit
this
service,
you
might
end
up
on
one
typhoon
agent
or
you
might
end
up
on
the
other
typher
agent,
but
we
want
to
monitor
both
right.
B
B
A
B
B
B
Using
this
right
now
so,
basically,
all
I
was
going
to
do
was
run,
which
was
run
the
calico
cuttle
to
find
the
port
on
which
prometheus
was
responding,
wanting
to
collect
metrics
for
calico
coupe
controllers.
So
I
already
know
the
answer.
Luckily,
so
when
I
run
that
command,
I
would
have
got
it,
it
would
have
output
into
port
1994..
B
B
B
B
B
B
B
B
Right
so
just
to
remind
ourselves
where
we
were,
we
were
for
felix.
What
we
need
to
do
is
just
slightly
different.
We
need
to
turn
on
prometheus
metrics
because
they're
not
on
by
default,
so
we
patch
the
configuration
and
we
turn
on
prometheus
metrics,
and
we
should
find
that
we
can.
Then
those
will
be
on
port
1991
by
default.
B
So
we
can
hit
any
node
that
we,
like
so
again
we're
ssh
into
the
controller
and
we're
curling
the
first
node,
but
this
will
work
any
of
the
nodes
will
work
on
port
1991,
and
here
we
go.
We've
got
symmetrics
so
now
we're
getting
to
where
we
can
start
to
see
interesting,
visual
things,
so
I'm
going
to
just
quickly
create
a
service
again.
B
B
Oh,
I
did
a
little
bit
more
than
1922,
never
mind,
that's
okay,
so
here
we
can
see.
Basically,
I
copied
in
some
yaml
I
created
a
cluster
role,
so
this
is
kubernetes
role
based
access
control,
so
we
created
a
user
called
calico,
prometheus
user
and
this
user
can
look
at
the
url
metrics
and
do
a
get
on
that
and
we
created
a
service
account
and
then
we
bound
those
two
things
together.
So
we
just
created
some
role-based
access
control.
B
So
I
won't
go
into
the
detail
of
this.
If
people
want
to
see
the
exact
detail
of
this,
then
the
best
place
is
probably
a
combination
of
our
documentation
and
the
blog
post
that
I
mentioned
that
was
about
six
weeks
ago.
On
this
point,
so
that's
the
prometheus
configuration
file
and
now
we
create
a
prometheus
pod
and
this
pod
is
going
to
read
the
configuration
file.
B
And
so
we're
creating
a
pod
again
in
the
calco
monitoring
namespace
we're
labeling
it
appropriately
we're
telling
it
which
service
account
to
run
with
and
we're
using
that
service
account.
We
created
before
we're
using
vanilla,
prometheus
image
and
we're
feeding
it
the
config
from
the
config
volume,
and
it
will
respond
port
1990.
B
B
B
B
B
So
what
I've
done
here
is
just
to
reiterate:
I've
created
this
prometheus
time
series
database,
I've
created
a
service
for
it,
and
now
I've
created
a
port
forward
from
my
local
laptop
into
the
cluster
running
in
gcp,
and
I'm
port
forwarding
port
1990
on
my
local
laptop
to
port
1990
in
the
cluster
on
that
service.
So,
finally,
if
I
run
this
curl
on
against
my
local
laptop
on
port
1990,
I
should
see
yeah
here
we
go.
I
see
a
response
from
the
server,
so
this
shows
that
prometheus
is
running.
B
B
We
can
work
through.
It
just
means
that
we
won't
actually
be
able
to
see
the
graphs,
which
is
a
bit
of
a
shame,
but
we're
a
little
bit
low
on
time
anyways.
So
I
think
we'll
just
push
on.
So
what
we've
done
is
we've
created
a
premier's
time
series
database
that
is
now
scrap,
scraping
the
endpoints
that
we
created
and
it's
listening
on
port
1990..
A
B
Vxlan
yeah,
that's
right!
So
that's
a
really
good
question
and
the
answer
is
it
doesn't
so
the
so
to
take
a
step
back
and
not
talk
about
ebps?
For
a
moment,
traditional
iptables
data
plane,
calico
can
use
bgp
and
no
encapsulation
or
it
can
use
the
xlan
or
it
can
use
ip
ip
encapsulation
and
which
of
those
is
the
correct
choice
depends
on
your
environment
but
in
most
environments
the
correct
choices
to
use
vxlan,
but
actually
any
of
those
three
are
possible.
B
Once
you
switch
to
ebpf,
you
can
still
use
bgp
and
have
no
encapsulation,
and
that
will
work
just
fine
or
you
can
use
vxlan
encapsulation,
but
but
you
shouldn't
use
ipm
ipip
encapsulation,
because
the
it's
not
the
performance,
it
will
not
be
as
good
as
vxlan.
So
once
you
so
just
to
reiterate
that
once
you
move
to
the
eppf
calico
epf
data
plane,
you
want
to
either
be
using
no
encapsulation
and
bgp,
and
that
will
be
great
or
you
want
to
be
using
vxlan
encapsulation.
Either
of
those
options
should
work.
Fine.
A
B
It
depends,
unfortunately,
it's
the
only
real
the
only
answer.
I
can
give
that
what
I
can
fit
into
the
time
we
have
so
you
can.
If
you
go
to
the
caliper
website,
there
are
several
courses
that
we
have
that
go
into
a
lot
more
detail
about
this.
If
you
want
to,
if
you
want
to
deal
into
it,
but
let's
say
you're,
deploying
your
cluster
in
aws.
B
One
option
is
that
you
use
aws's
eks
service
and
that's
an
entirely
managed
service.
So
it's
kubernetes,
but
you
don't
care
about
any
of
the
workings
of
how
it
works.
You
just
accept
that
amazon
make
it
work
for
you,
but
that's
not
what
I'm
doing
today.
I
am
running
in
google
as
it
happens,
but
I'm
replacing
the
instead
of
using
their
managed
service.
I've
built
my
own
cluster,
so
ebpf
is
in
this
case
replacing
the
data
plane.
B
B
Similarly,
if
you
have
a
particular
environment,
like
you
have
an
aws
environment,
perhaps
we
actually
have
a
free
course
that
content
that
will
give
you
a
ton
of
information
about
what
the
various
options
are
and
what
the
pros
and
cons
are.
One
thing
to
keep
in
mind,
though,
is
that
all
of
these
are
like
advanced
options.
So
if
you
just
deploy
calico
on
a
vanilla,
kubernetes
cuff,
it
will
work.
What
we're
doing
here
is
kind
of
a
more
advanced
configuration
to
bring
out
some
of
the
benefits
so.
A
B
A
B
A
B
B
B
B
Obviously,
there
are
more
options
than
just
grafana,
but
it's
by
far
the
most
people
and
I'm
aware
of
so
what
we're
going
to
do
is
we
stick
refiner
on
the
front
of
this
and
what
graphana
does?
Is
it's
just
a
visualization
tool
that
allows
you
to
take
the
data
in
the
prometheus
time,
series
database
and
visualize
it
in
ways
that
are
useful,
so
we
create
a
config
map
and
that's
called
grafanaconfig.
B
B
Can
apply
some
default
dashboards
so
we're
just
applying
a
manifest
from
projectcalico.org
that
needs
to
change
the
322
and
we're
just
applying
some
vanilla
dashboards.
Sadly,
we're
not
going
to
be
able
to
see
these
dashboards
because
of
the
shared
screen
sharing
issue,
but
you
have
to
take
my
word
for
it.
They're
very
beautiful
and
the
last
thing
to
do
is
to
actually
create
the
graffana
itself.
A
A
B
Here
and
I
highlighted
the
api
server-
we're
not
monitoring
that,
I
don't
know,
I
highlighted
it,
then
we
have
prometheus,
which
is
the
time
series
database,
and
then
we
have
grafana,
which
is
the
actual
visualization
tool.
So
if
all
of
that
has
worked
correctly-
which
I
hopefully
it
has,
you
should
be
able
to
start
a
new
word
from
my
local
laptop
on
3000.
This
time.
B
If
we
hit
that
url
calico
felix
dashboards
dashboard,
then
if
we
were
doing
this
in
a
proper
browser,
we'd
be
able
to
log
in
and
we'd
be
able
to
see
the
graphs
for
for
the
customer.
But
sadly
we
can't
at
this
point,
luckily
we're
out
of
time
anyway.
So
I
think
I
would
have
slightly
run
over
time
if
I
had
been
able
to
do
that
so
yeah
that
that's
that's
all
I
can
demo
today,
without
without
limitation,
we've
got
so.
Are
there
any
other
questions
you
wanted
to
cover.
B
So
I'm
going
to
take
that
in
the
context
of
ebpf,
calico
and
psyllium
are
both
cni's
for
kubernetes
that
use
the
ebpf
that
you
that
use
evpf
to
implement
their
their
data
plane.
I
won't
speak
to
the
details
of
psyllium
because
I
am
not
on
their
team,
so
I
don't.
I
don't
know
the
details
as
well
as
they
would,
but
essentially
we're
both
using
ebpf
to
create
a
data
plane
for
kubernetes.
B
In
the
case
of
calico,
we
have
other
choices
that
can
allow
us
to
suit
other
environments
and
not
only
to
use
eppf
but
to
use
other.
For
example,
you
might
choose
to
use
rip
tables
data
plane
because
you
want
battle
tested
code,
that's
been
run
in
production
for
five
years,
approximately
five
years,
so
both
calico
and
psyllium
implement
a
kubernetes
data
plane
using
ebpf.
I
think
that's
the
best
answer.
A
B
B
A
A
B
B
B
A
Yeah,
of
course,
and
as
always
thank
you
for
everyone
for
joining
the
latest
episode
of
cloud
native
live.
It
was
great
to
have
this
amazing
session
on
setting
up
monitoring
for
calico's,
epf
data
plane
and
really
amazing
interaction.
Today,
thank
you.
Everyone
for
commenting
sticking
with
us
and
as
bringing
a
lot
of
good
comments
and
questions
to
the
table,
love
the
interaction
jay
and,
as
always,
we
bring
you
the
latest
cloud
native
code,
every
wednesday
so
tune
in
next
week
as
well,
and
we
have
a
great
session
coming
up
then
as
well.