►
Description
Any managed Kubernetes is basically a bunch of VM's..no magic. Kubernetes networking is basically interfaces and routing rules (mostly IP tables). Come and Join us to learn about the fundamentals of Containers and Kubernetes networking.
A
Thank
you
thanks
for
the
intro
and
welcome
to
kcd
chennai,
and
I
know
that
you
guys
are
busy
with
saturday
course,
but
still
thanks
for
taking
your
time
to
attend
this
fantastic
event
organized
by
kcd
team
and
I'm
very
excited
to
present
you
guys
about
talk
about
deconstructing
kubernetes
for
networking
and
knowledge
profit
or
you
know
you
can
call
it
as
a
profit
right.
So
this
is
based
on
the
microsoft
internal
training
presented
by
stephan
griffith.
A
Let's
say
the
via
muscle
scales
that
are
aks,
but
still
the
commands
and
the
constructs
or
the
concepts
are
same
across
the
kubernetes
right
and,
let's,
let's
proceed
with
these
sessions,
since
we
have
a
40
plus
slides,
I'm
trying
to
condense
into
25
minutes
session
and
then
see
how
best
I
can
you
know
responsible
on
this
provided
time
and
the
session
objective
is
you
know
I'll
set
the
context
by
introducing
the
layers
around
the
kubernetes
and
starting
with
the?
What
is
parts?
What
is
services,
what
is
components
and
around
the
networking?
A
The
reason
is,
in
the
presented
time
it's
so
difficult
to
set
up
for
the
whole
thing
and
record
assets
and
kubernetes
network.
First
of
all,
we
have
to
agree
that
accept
that
kubernetes
is
hard
right.
It's
not
like
I'm
a
certified,
I'm
a
master
in
the
kubernetes
area
right,
so
we
have
to
accept
the
fact
that
community
is
hard,
but
network
isn't
magic
at
all.
A
So
network
is
also
equally
hard
and
we
see
many
people
shy
away
discussing
about
the
networking
concepts
because
of
the
complexity
involved
and
at
the
end
of
the
day,
it's
all
wild
zones
to
you,
know
simple
ip
tables
and
build
with
a
lot
of
overlay
networking
concepts
around
the
ip
tables,
and
then
we
have
the
cni
already
kubernetes
and
we
will
deconstruct
the
whole
thing
in
the
coming
slides
check.
Okay,
so
the
kubernetes
networking
as
a
the
key
concepts
are,
I
mean
I'm
going
to
cover
some
of
those
key
concepts
right.
A
So
the
first
thing,
the
fundamental
thing
is
about
the
cubelet.
This
cubelet
is
responsible.
Alright,
the
agents
are
demonstrate
responsible
for
certain
things
right,
so
there
are
like
145
plus
parameters
you
see,
but
in
the
after
the
docker
stream
removal
in
1.24,
it
is
expected
to
have
120
parameters,
but
still
it
is
a
huge,
but
so
if
you
ssh
into
one
of
the
nodes,
one
of
the
kubernetes
nodes
using
the
ps
command,
you
can
see
this.
A
You
know
what
is
the
network
plugin
used
in
the
underlying
architecture
right,
so
you
see
that
briefly
in
the
diagram,
you
see
a
network
plug-in
as
a
cube
net
in
this
case.
Well,
you
would
also
see
this
cni
from
the
respective
provider.
If
it
is
an
aks,
then
azure
cni
are
other
providers.
Also
you
have
the
equivalent,
you
know
celium
name
and
they
provide.
I
think
there
are
like
1520
providers.
A
You
provide
a
cna
network
on
top
of
the
default
networking
and
these
agents
and
the
no
the
node
agents
of
cubelet
is
responsible
for
various
things,
and
I
I
suggest
you
know
take
time
to
go
through
it
and
then
we'll
proceed
with.
You
know
how
you
can
actually
log
into
one
of
our
ssh
into
one
of
the
nodes.
The
commands
are
same
still.
Maybe
the
cloud
provider
is
different,
but
the
commands
are
same
and
you
could
use
one
of
those
in
a
box
and
then
try
to
run
a
spinner.
A
You
know
troubleshooting
the
container.
What
I
see
the
mcr.microsoft.net
runtime.
There
is
an
image
which
I'm
using
to
troubleshoot
and
then
you
can
run
the
top
command
or
add
up
command
and
then
see
the
container
d.
These
are
the
some
of
these
agents
in
the
cubelet.
Also,
you
will
find
it
as
a
first
thing
here
and
you'll
find
other
agents
are
equally
running.
A
You
know
in
those
missions
and
those
are
like
run
as
a
demand
side
or
sorry,
the
agent
or
process,
so
they
are
responsible
for
certain
networking
concepts
which
we'll
see
in
a
moment
and
the
key
con
components
around
the
kubernetes
networking
of
it's
almost
I
mean
most
mostly
revolves
around
cubenet
or
cmi
right
by
default.
A
We
started
with
the
cubenet
when
the
community
started,
but
over
the
period
of
time
due
to
the
limitation
with
the
cubenet
we
now
we
are
branching
towards
the
cni,
are
a
layer
on
top
of
the
default
one
and
the
respective
providers,
like
you
see,
the
azure
has
got
their
own
and
gcp
aws
and
vmware
and
celium,
and
there
are
like,
I
think,
as
I
said,
the
20
plus
networking
players
are
cni.
Plugins
are
available
to
achieve
the
some
robust
networking
concepts
around.
You
know
the
the
default
one
and
the
parts.
A
Actually
it's
been
talked
a
while
parts
of
the
fundamental
constructs
are
maybe
the
low
level
compute
execution
of
your
application
and
it's
all
it
could.
It
can
have
a
multiple
container
or
maybe,
as
a
sidecar
proxy.
Yesterday
we
talked
about
service
maps,
you
know
as
a
sidecar
proxy,
so
these
parts
are
responsible
to
run
a
container,
manage
these
containers
and
also
manage
the
ip
address
for
these
containers
so
and
then
we'll
jump
into
the
services
also
services.
Also.
A
So
if
you
look
at
the
the
way
the
slides
are
organized
right,
so
I'm
trying
to
get
deeper
deeper
and
then
show
you.
You
know
how
you
can
actually
slice
and
dice
these
networking
concepts.
So
when
we
drill
down
to
the
service
level
service
levels,
you
know
there
are
four
types
of
services:
cluster,
ip
node
port
and
the
load
balancer
and
external
name,
and
I
believe
that
one
more
is
also
there.
But
there
are
four
basically
four
types
of
major
linear
use
thing.
These
are
like:
it
operates
in
the
layer.
A
Four,
it
means
that
it's
it
doesn't
know
anything
about
the
application
in
the
back
end
right,
it's
it
does
what
has
been
prescribed
here.
Let's
say
if
I
create
a
cluster
ip,
it
gives
an
ip
of
you
know
cluster
code,
private
ip
in
the
cluster,
to
work
with
the
london
c5
spinner.
If
I
define
as
a
load
balancer,
it
gives
me
a
a
public
ip
from
the
respective
load
balancer,
I
mean
sorry
cloud
providers,
load,
balancer
and
then
and
it's
kind
of
abstraction,
and
you
should
know
how
to
run
this
command.
A
A
You
would
see
the
the
back
and
the
I
mean
back
is
having
a
single
ip
address
or
end
points,
whereas
the
front
has
got
four
different
parts
and
there
are
like
you
know,
four
different
copies
of
the
parts,
and
then
you
see
that
the
the
ip
address
are.
You
know
in
the
range
of
10.24
I
mean
the
idea
here.
Is
it
matches
the
end
points,
what
we
see
it
in
the
command
and
also
the
parts
what's
been
assigned
from
the
kubernetes
right,
so
so
how
this
matching
has
happened?
A
A
7.,
it's
been
talked
a
while
adding
a
lot
of
fingers
available
in
the
community
space,
and
if
you
see
that
the
ingress
control
by
default,
we
in
azure,
we
provide
azure
application
gateway,
ingress
controller,
you
have
a
choice
to
run
an
engine
exercise
or
a
traffic
or
any.
This
will
essentially
will
help
you
to
route
the
traffic
in
a
designated
way.
It
works
on
the
application
layer,
that's
very
important
concepts.
You
should
be
out
off
in
the
communities
networking
and
then,
let's
deep
dive,
assume
that
you
are.
A
You
are
an
sreri
development
uncertainly
and
the
devops
engineer.
You
are
going
to
debug
some
issues
right.
So
first
thing
that
the
networking
concept
starts
with
you
know
the
ammo
spec,
what
you
see,
what
is
the
port?
What
does
the
ip
address
defined?
How
these
selectors
and
labels
are?
You
know,
mapped
to
each
other
right
in
the
right
side.
There
is
a
kind
of
service
which
has
been
created
for
the
deployment
in
the
bottom.
A
Let's
say
there
is
a
selector
labels
which
matching
is,
as
you
know,
flask
application
dash
a
right
so
see
the
service
has
been
created.
On
top
of
this
container-
or
this
part,
the
replica
set
is
nothing
but
the
copy
of
your
part,
and,
and
then,
if
you
see
this
one
one
fine
day,
you
get
an
issue
saying
that
hey
I'm
trying
to
do
a
curl
command.
Maybe
in
the
left
side
you
see
it's
working,
fine,
but
we're
in
the
right
side.
It's
failing
right,
so
one
of
the
part
is
failing
to.
A
You
know,
maybe
respond
in
a
way
that
it's
showing
as
an
operation
timed
out
right.
So
it's
a
normal
thing
which
you
might
have
seen
or
come
across.
So
the
the
thing
I'm
trying
to
say
here,
isn't
how
would
you
approach
this
problem
or
troubleshoot
this?
Let's,
let's
deep,
dive
and
then
see
in
a
high
level?
If
you
look
at
I
mean
there's.
One
thing
you
have
to
be
very
over
here
is
the
cubenet.
A
You
will
not,
I
mean
in
cubenet,
you
will
find
route
tables
created
by
default
and
then,
but
in
case
of
a
cni
networking,
and
you
will
not
see
that
route
tables
created
right,
I
mean
you
ought
to
be
very
mindful
about
whether
you
are
troubleshooting,
a
cubenet
issue
or
a
plugin
or
cni
plug-in
right,
so
based
on
that
the
the
underlying
network
stack
of
the
the
the
approach
would
differ.
A
So
in
this
case
of
I
mean
in
this
case
I
mean
here
in
this
case
we
are
trying
to
check
what
are
the
I
mean.
Various
knobs
of
you
know
the
networking
complexities.
A
The
fundamentals
are
same
again:
don't
carry
it
away
by
the
screenshot
of
azure
or
a
case,
but
so
when
you
get
into
the
system
or
when
you
get,
I
mean
when
you
look
at
the
resources,
what
has
been
created
by
the
managed
provider,
you
ought
to
check
the
default
route,
that's
going
via
the
firewall
or
it's
getting
blocked
by
certain
things
right.
You
always
have
an
networking
concepts
defined.
I
mean
the
route
tables
configure
to
separately
for
ingrass
and
egress.
A
So
make
sure
that
you
know
the
there
is
no
overlapping
ips
are
created
this
one
of
the
I
mean
these
are
like
some
of
the
checkpoints
you
try
to
check,
but
when
you
further
deep
down
to
check
right
so
there
isn't,
there
shouldn't
be
an
energy
created
or
associated
to
the
the
v-net
by
default.
When
you
create
a
cluster
in
the
you
know,
cube
net
right
in
the
left
hand,
side
left
hand
side
in
the
cube
lat.
I
mean
the
left
left
hand.
Side
is
another
cube
net.
A
By
default,
you
see
that
the
energies
are
attached
to
the
subnet,
but
where,
in
case
of
cni,
you
know
it's
been
attached
to
sometime
in
the
v-net
or
in
the
node
level.
Right
so
make
sure
nothing
has
been
assigned
to
the
subnet,
so
the
the
default
setting
of
the
subnet
sorry
energy
changes
depends
on
the
the
plug-in.
What
you
choose
make
sure
these
you
know
energies
are
not
assigned
or
maybe
propagate
to
the
top
to
bottom
make
sure
you
know
the
energies
are
not
blocking
your
access
right.
A
We,
when
you,
when
you
drill
down
further,
is
again
the
one
more
view
of
to
check
it
in
the
azure.
So
you
go
to
the
the
particular
resource
group
and
then
see
whether
the
nsgs
have
been
kind
of
blocking
that
access
endpoints
and
then
it's
confirmed
that
it
doesn't
seems
to
be
blocking
anything.
A
A
So
far
we
were
troubleshooting
or
maybe
looking
at
what's
outside
of
the
cluster
by
looking
in
the
portal
nsg-
or
maybe
you
know
the
definition,
what
we
set
in
the
you
know
start
of
the
cluster
and
the
spark
spec
and
other
thing,
but
in
case
of
when
we
get
into
the
cluster-
and
you
ought
to
make
sure
the
fundamental
concepts
has
like
you
know,
the
the
cube
net
versus
cna.
The
concepts
are
clear
right,
see
as
I,
as
I
said,
the
cni
in
in
cni.
You
will
not.
A
You
will
not
see
the
route
table
created,
but
in
case
of
a
cube
net
you
will
see
the
route
tables
created
to
make
sure
you
know
that
things
are
improper
and
also
these
are
like
kind
of
a
definition
I
mean,
maybe
the
difference,
but
I'm
sure
that
most
of
the
things
are
same.
As
you
know,
even
though
providers
are
different
and
yeah
one
thing.
Actually
I
want
to
say
here
the
networks
I
mean
the
cubenet
fundamentally,
the
cubenets
are
the
network.
A
Concepts
are
put
in
a
way
that
you
know
it's
actually
nothing,
but
an
overlay.
On
top
of
your
the
network
provided
by
the
nodes
and
in
case
of
cni,
you
can
define
a
range
of
a
subnet
range
and
also
you
have
a
flexibility
to
set.
You
know,
let's
say
if
you
are
setting
a
30
ip
address
per
node
and
plus
one
node
one
ip
for
that
particular
node,
the
31
ip
address.
A
Fundamentally,
the
cni
would
operate
within
that
range,
but
in
case
of
next
version
of
cni,
I
believe
the
dynamic
allocation
of
ipad
is
also
coming
in
picture.
So
I
think
we
are
most
I
mean
the
focus
here
is
mostly
into
cni,
because
I
mean,
if
you
look
at
the
cube
net,
it's
kubernetes.
We
all
started
playing
with
cubenet,
but
when
you
get
into
the
production
grade
application,
the
cni
is
what
I
see
our
vc
mostly
used
are
majorly
considered
right
the
cni
version
two,
which
is
going
to
be
a
dynamic
allocation.
A
So
I
encourage
to
check
cni
version
two
also
and
then
so,
as
I
I
mean,
as
we
discussed
the
cube
net
versus
azure
c9
in
the
first
diagram
in
the
top
in
the
top
most
when
the
node
ip
address
is
like
10.10.504
5.4
has
been
that's
your
node's
ip
address,
but
in
case
of
I
need
actually
okay
yeah,
so
the
the
parts
I
mean
for
the
azure
cni
the
iphones
are
assigned
from
the
subnet
cidr.
A
But
the
external
load
balancer
remains
same.
Both
are
going
to
be
having
you
know
same,
it's
just
a
public
air
pressure.
At
the
end
of
the
day,
it's
a
public
advertising
moment
you
create
a
service
type
as
a
load
balancer
you
get
a
public
aperture
and
then
there's
no
difference
here.
Let's,
let's
get
into
the
what's
actually
happening
right
when
we
do
a
curl
command
like
here
you
I
mean
we
got
an
operation
timed
out
right.
This
is
a
problem
statement.
We
are
trying
to
troubleshoot.
A
So
so
that's
a
public
ip
address
you
can
make
sure
the
public
ipad
is
from
the
respective
providers
are
in
a
proper
and
in
the
right
format,
but
in
the
in
this
case
you
know
we
are
troubleshooting
with
the
aks
cluster,
so
I'm
trying
to
make
sure
the
azure
load
balance
are
you
know,
functional
and
also
properly
configured
and
the
ports
are
listening
and
then
5000
support
where
we
are
trying
to
reach,
and
then
the
side
by
side
in
the
screenshot
you'll
see
5000
is
also
configured
back.
A
End
is
also
5
000.,
the
the
sliders
I
mean
from
the
kubernetes
view.
Kubernetes,
I
mean,
doesn't
understand
whether
you
are
running
in.
I
mean
operating
with
the
aks
or
ek.
It
works
in
the
way
that,
because
it's,
a
all
other
things
are
put
as
an
abstraction
or
layer
around
communities
are
extended.
So
the
kubernetes
view
you
will
see
these
load
balancer
having
the
public
ip
address
and
also
ports
with
the
incoming
and
outgoing
and
then
external
ip.
A
So
that's
a
service
view
and
the
linux
view,
if
you
assess
it
to
the
ssh
into
one
of
the
machine.
What
is
the
linux
kernel
view
looks
like
for
those.
So
if
you
do
a
sudo
ip
tables
of
dash
d
and
that
dash
nl
and
cube
services
grap
up
for
that
application,
you
will
see
that
the
daemon
set
and
the
tool
chain.
So
there
were
multiple
tool
chains
and
then
finally,
it
reaches
the
destination
of
2081.
A
That
is
our
load
balancer
ip
right.
So
we
are
trying
to
see
what
I
mean.
How
many
tool
signs
are.
You
know
how
many
hops
it
takes
to
not
hops.
Actually,
the
the
the
tool
signs
are
involved
to
reach
the
destination.
A
The
case
node
right
so
like
inside
the
case
node
there
is
a
part
and
then,
when
you
do
this
cube
ctl
get
endpoints
and
come
apart.
You
see
that
the
ip
address
of
the
endpoints
and
parts
assigned
to
iphotos
are
matching
so
so
far
good
and
then
get
into
the
linux
view,
kernel
view
and
similarly
in
the
linux
tables,
I
mean
when
you
I
mean
the
same
linux
node.
When
you
try
to
do
these
iep
tables
and
then
the
commands
of
cube
service
with
some
height
and
certain
hash.
A
You
will
see
that
the
the
cube
dash
sip,
which
is
actually
matching
with
the
ip
tables
of
what
is
that
nat
listed
right
and
also
the
power
type,
is
also
precisely
matching.
That's
a
that's
a
destination.
We
are
trying
to
put
the
traffic
to
right
and
then
there's
another
view.
A
So
when
you
do
the
cri,
ctl
ps
you'll
see
that
the
container
name
that
flask
application,
which
you
are
trying
to
curl
having
the
hash
of
container
name
and
then
you
can
also
crictl
inspector
dash
dash
output
and
then
go
to
the
template
of
the
particular
container
id
and
then
try
to
see
that
you
know
what's
actually
the
loopback
address
and
other
thing
by
the
way
these
I
will
share
the
slide.
A
These
commands
are
properly
put
in
a
way
that
you
know
you
can
try
to
do
the
same
thing
on
your
own,
I'll
put
it
in
my
github
so
that
you
can
grab
the
slide
and
then
all
these
steps
are,
you
know
we
are
trying
to
get
deeper
and
deeper,
and
then
it's
okay.
So
so
far
good
have
you
have
we
confirmed,
or
I
mean,
does
it
work
now
way?
A
We
expected
no
still,
the
still,
you
know
the
the
timeout
issues
are
happening,
and
then
we
see
that
the
we
are
trying
to
get
into
the
machine
and
also
we
confirmed
that
and
we
ran
some
commands
and
then
we
confirmed
that
things
are
fine
and
there
is
no
firewall
issues
and
there
is
no
energy
issues
here
and
we
looked
in
the
kernel
view.
A
Sorry,
the
the
linux
kernel
we
looked
in
the
azure
view,
our
provider
view
we
looked
from
the
cube,
ctl,
endpoints
and
service
view,
and
but
still
the
nodes
are
not
receiving
traffic
rights.
I
mean
the
timeout
issues,
I
mean
the
time
route
errors
are
not
getting
solved
right
and
there's
one
more
revenue
we
can
check.
A
We
can
also
check
with
the
load
balancer
metrics,
whether
the
the
particular
part
which
is
running
inside
the
the
cluster,
which
is
you
know,
receiving
the
traffic
or
not
right,
and
you
see
that
in
the
load
balancer
matrix
in
the
bottom
towards
the
bottom,
there
are
like
a
couple
of
red
marks:
are
there
right
that
shows
that
and
there's
somewhere
you
know
something
is
breaking
with
the
load.
A
Balancer
I
mean
the
traffic
is
not
actually
really
hitting
the
load
balancer
or
reaching
the
road
balance
right,
so
we
could
also
use
the
I
mean
we
can
now
use
the
tools
like
a
wire
shark
and
by
the
way
in
the
wireshark,
is
the
ui
version,
but
when,
when
we
use
the
t
sharp,
which
is
equivalent
to
the
command
line
version
of
y
sharp,
we'll
be
able
to
specifically
set
filters,
let's
say
when
we
right
now
we
are
doing
a
curl
command,
that's
okay,
but
we
can
actually
set
the
commands.
A
Like
you
know,
the
http
requested
method.
It's
a
get
method.
If
you
are
interested
and
then
the
ports,
you
know,
there's
a
source
port
destination
port
and
we
can
actually
try
to
collect
this.
You
know
the
the
the
logs
of
same
like
wireshark,
equal
and
denote
t-shirt
log
and
then
see
how
these
you
know.
A
Patch
packets
are
in
exchange
between
each
other
and
then
there's
a
command
to
run
it
and
then
packet
flow
test
with
the
t-sharp,
and
I
have
to
talk
about
the
hey:
hey
is
a
load
gen
loaded
generator
written
in
go
language.
A
It's
a
very,
very,
very
useful
and
also
nimble,
little
utility
to
generate
some
low
test,
it's
available
in
github
and
then
I'm
commanding
I
mean
using
a
command
here
in
the
top
saying
that
you
know:
hey,
generate
a
load
for
this
particular
ip
address,
which
I'm
trying
to
resolve,
or
maybe
you're
trying
to
debug,
and
then
someone
in
the
working
scenario.
A
You
see
that
when
I
run
the
wireshark,
you
see
the
proper
response
in
the
green
color
section
right,
you
see,
the
2081
is
reachable
on
5000
port
and
then
it's
it's
working
as
expected,
but
in
case
of
a
non-working
scenario
and
there's
no
traffic,
which
is
actually
it's
again
timed
out
issue,
and
then
we
can
now
get
into
a
tcp
dump
the
for
the
same
scenario.
How
tcp
dump
would
help
us
to
dump
out
the
traffic
between
you
know
to
client
and
server
right.
A
And
finally,
we
reach
to
the
application
code
right,
so
we
started
somewhere
outside
and
we
layer
after
layer
we
reach
to
the
particular
application
in
the
application
code.
We
see
that
the
host
has
been
set
as
a
0.0.0.0
right.
That's
been
kind
of
none
of
the
listening
port
inside
that
application
code
and
by
the
way,
this
is
how
the
flask
I
mean.
This
is
a
template,
a
flash
code.
I
we
copied,
I
mean
copied
from
the
internet
and
just
put
it
for
a
sake.
A
You
know
for
troubleshooting,
and
this
is
how
the
application
code
looks
like,
but
when
we
get
into
the
docker
file,
when
we
create
for
the
for
the
flask,
you
know
we
create
a
docker
file.
This
is
how
it
looks
like
right
so
for
the
working
file
and
we
are
injecting
with
the
parameters
in
a
dash
dash
host
of
zero
zero
zero.
But
in
the
non-working
scenario
it's
been
hard
coded
with
127.
Maybe
the
non-working
scenario
might
work
with
them
with
the
developer
in
the
development
environment.
A
But
when
we
move
to
the
kubernetes
world
we
are
forcing
to
work
on
127.
That
is
the
issue
we
are.
You
know
we
we
were
able
to
find
out
from
this
whole
discovery,
so
so
underlying
I
mean
in
a
nutshell
and
the
dash
dash
host,
which
has
been
set
as
a
127,
which
was
actually
not
worked
as
expected,
but
when
we
changed
back
to
0.0,
which
means
that
flexibility
in
you
know
assigning
some
ipads
from
the
host,
we
are
not
actually
forcing
any
iprs
right.
We
are
just
saying
free
ip
address.
A
I
mean
free
to
pick
from
the
host
right,
so
this
actually
I
mean
the
left
side
worked
properly
and
then
right
check
was
actually
failing.
That
is
the
issue
here,
which
we
troubleshoot
all
the
way,
and
we
could
also
look
at.
You
know
whether
it's
listening
in
the
right
ip
and
address.
I
mean
this
is
just
a
command.
I
put
it
for
useful
sake
right
so
click
I
see
I
mean
cri
ctl
inspect,
that's
a
command
and
template.
A
I
think
you
will
find
it
in
the
the
slide
at
which
you
get
it
later,
so
key
take
away
from
out
of
this
right.
So
the
see
the
way
we
have
to
approach
this.
There
are
two
ways
you
can
actually
start:
troubleshooting,
let's
we
always
start
from
top
to
bottom
approach.
Top
is
nothing
but
we
look
at
in
the
portal
respectively
cloud
provider
portal
and
then
we
try
to
debug
one
after
the
other.
But
once
if
you're
familiar
with
this
concept,
you
can
actually
do
the
reverse.
A
Also,
but
see
we
have
been.
You
know.
Maybe
we
found
that
the
troubleshooting
from
bottom
to
top
layer
is
the
most
convenient
or
maybe
most
useful,
to
isolate
some
of
this
issue
issue,
because
the
the
easiest
thing
is
like
top
to
bottom
right.
You
look
at
from
the
azure
portal
or
maybe
a
respective
cloud
provider
portal
load,
balancer
nsg,
that's
anybody
can
do,
but
some
of
the
hard
issues
right.
A
You
have
to
start
from
the
bottom
to
top
stack
so
that
you
know
you'll
be
able
to
do
and
at
the
end
of
the
day,
the
communities
are
the
only
networking
concepts
which
discussed
it's
all.
It's
all
built
on
ap
tables
and
the
routing
rules,
and
that's
what
you
know
don't
get.
You
know
scared
off.
Maybe
I'll
try
to
talk
about
this
or
learn
more
about
it
and
in
the
process
of
elimination
start
from
the
start
to
high
level.
A
You
know
start
with
route
tables,
energies
and
the
general
networking
routing
issues
or
if
you
wanted
to
follow
up
the
high
level
approach
start
from
the
channel
or
maybe,
as
I
said,
ssh
into
the
node
and
then
you
know
go
to
the
top
top
view
as
well.
Some
of
the
tools
I
found
are:
maybe
it's
been
used
internally
to
we
see
you
know
it's
used
for
troubleshooting
and
I
found
that
useful
to
share
it
here
and
cubectl.
A
I
know
you
must
be
knowing
about
some
of
these
cube,
ctl,
troubleshooting
commands
and
as
a
search
into
the
respective
cloud
provider
provider,
agent
notes
and
by
the
way
it's
not
recommended
to
it's
not
advised
to
always
association
to
the
notes.
Unless
there
is
a
troubleshooting
requirement
right
and
we
strongly
discourage,
you
know
changing
anything
in
the
notes
and
because
it's
it's
like
at
the
end
of
the
day,
these
are
like
a
temporal
notes
right.
A
So
if
the
note
goes
down
we'll
get
another
note,
so
don't
try
to
customize
anything
in
the
notes
and
make
use
of
the
respective
providers
load.
Balancer
insights.
That
will
get
some
kind
of
you
know
clues
to
nail
down.
You
know
what
goes
wrong
inside
then
these
are
like
a
five
commands.
You
know
cri
ctl
and
ns
enter
and
then
to
troubleshoot
effectively,
let's
say
tcp
dump.
Our
tcp
dump
was
in
the
windows,
I'm
in
windows,
world,
which
has
been
now
ported
to
linux.
Also,
and
there
are
other
tools-
also
system
internal
tools.
A
If
you
look
at
system
internal
tools
by
margaret
snowwick,
was
there
like
30
plus
r
tools,
mostly
built
for
windows,
has
been
now
ported
back
to
window.
I
mean
sorry
linux
world
as
an
so
so
you
will
find
the
some
of
the
good
benefits
from
system
internal
tools
going
to
linux.
World
and
one
of
them
is
the
tcp
dump
and
t
shark
is
nothing
but
the
wire
shark
equivalent
in
the
command
line
and
ls
off
is
the
file
open.