►
From YouTube: Inside Kubernetes Networking - Dominik Tornow, Cisco
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Inside Kubernetes Networking - Dominik Tornow, Cisco
Kubernetes Networking is a core abstraction of Kubernetes: At the core, the Kubernetes Networking Model guarantees that all Kubernetes Pods on a cluster can communicate. On top of the Kubernetes Network Model, Kubernetes provides additional core abstractions, most notably Kubernetes Services and Kubernetes Ingress. Although K8s Networking is an essential aspect of every K8s Cluster and by extension every K8s Application, even experienced K8s users struggle to reason about K8s Networking end-to-end. Using a systems modeling approach, this presentation will provide a holistic mental model of K8s Networking - integrating Pod-to-Pod communication, Pod-to-Service communication, and Ingress, applicable to all CNI implementations. Walk away with a dependable, holistic understanding of the entire network stack, fill in the blanks and connect the dots between Kubernetes Networking, Kubernetes Services, and Kubernetes Ingress.
A
A
A
A
A
A
A
The
specification
requires
that
a
container
c1
that
is
executing
in
the
context
of
a
part
p
can
communicate
with
any
other
container
c2.
That
is
also
executing
in
the
context
of
p,
via
localhost
or
via
the
ip
address
of
p,
again
represented
graphically
a
container
c1
that
is
executing
in
the
context
of
a
part.
P
can
communicate
with
any
other
container
c2.
A
A
A
The
specification
requires
that
a
daemon
d
that
is
hosted
on
a
node
n
can
communicate
with
any
container
c
that
is
executing
in
the
context
of
a
part
p.
That
is
also
hosted
on
n
via
the
address
of
p
again
represent
it
graphically
a
daemon
d
that
is
hosted
on
a
node
n
can
communicate
with
any
container
c
that
is
executing
in
the
context
of
a
port
p.
That
is
also
hosted
on
n
via
the
address
of
p.
A
In
this
presentation,
we
will
rely
on
conceptual
instead
of
actual
implementations
of
a
kubernetes
network
to
reason
about
the
life
of
a
message
in
the
kubernetes
cluster.
So
the
model
we
are
about
to
discuss
describes
a
conceptual
network
plugin.
It
does
not
describe
an
actual
network
plugin.
We
use
this
model
as
an
educational
model.
A
A
A
A
switch
can
be
modeled
as
a
function
and
a
forward
information
base.
A
switch
can
match
any
part
of
a
message.
Typically,
the
source
address,
source
port
target
address
and
target
port
against
its
forward
information
base
to
determine
the
next
action
here.
We
assume
that
a
switch
may
either
drop
a
message,
deliver
a
message
to
a
container
or
daemon
forward
a
message
to
another
switch
or
translate
a
message
before
calling
itself
recursively
with
the
translated
message.
A
A
We
will
now
discuss
one
possible
network
as
discussed.
We
will
reason
about
the
kubernetes
network
in
terms
of
a
network
graph,
but
how
does
a
network
graph
that
is
a
valid
kubernetes
network
implementation,
satisfying
the
kubernetes
network
specification
actually
look
like
from
here
on
out.
We
will
use
a
simple
kubernetes
cluster
as
an
example.
A
A
So
for
this
example,
what
does
a
possible
network
graph?
Look
like
first,
we
assume
that,
for
every
part,
there
exists
a
corresponding
switch
from
here
on
out
called
portswitch
for
every
container
executing
in
the
context
of
a
pod.
There
exists
a
link
from
the
container
to
the
corresponding
part
switch.
A
A
First
messages
that
target
a
part
that
is
hosted
on
the
corresponding
node
are
forwarded
to
the
corresponding
part
switch
and
next
messages
that
target
a
part
that
is
not
hosted
on
the
corresponding
node
are
forwarded
to
the
node
switch
corresponding
to
the
node
that
does
host
the
part
later
on.
We
will
expand
the
forward
information
base
of
node
switches
to
accommodate
for
kubernetes
services
and
add
rules
to
translate
messages.
A
In
this
last
section,
we
will
walk
through
a
sequence
of
examples,
highlighting
container
to
container
communication,
part-to-part
communication
demon,
support
communication
services
and
ingress
a
fair
warning.
This
section
is
tediously
repetitive,
but
if
you
follow
along,
you
will
gain
a
solid
understanding
of
the
underlying
mechanics.
A
A
A
The
part
switch
p1
will
receive
the
message
and
match
the
message
against
its
forward
information
base.
It
will
find
a
relevant
entry
that
instructs
the
port
switch
to
deliver.
The
message
to
container
c1.2
port
switch
p1
will
send
the
message
m
via
its
edge
to
container
c
1.2,
and
finally,
the
container
will
receive
the
message
next.
In
this
example,
we
will
discuss
port
to
part
communication.
A
A
A
A
A
The
port
switch
p3
will
receive
the
message
and
match
the
message
against
its
forward
information
base.
It
will
find
a
relevant
entry
that
instructs
the
port
switch
to
deliver.
The
message
to
container
3
1
portswitch
p3
will
send
the
message
m
via
its
edge
to
container
31,
and
finally,
the
container
will
receive
the
message
next.
In
this
example,
we
will
discuss
part-to-part
communication.
A
A
A
A
A
A
A
A
A
The
port
switch
p1
will
receive
the
message
and
match
the
message
against
its
forward
information
base.
It
will
find
a
relevant
entry
that
instructs
the
port
switch
to
deliver.
The
message
to
container
c
1.1
port
switch
p1
will
send
the
message
m
via
its
edge
to
container
c
1.1,
and
finally,
the
container
will
receive
the
message.
A
A
Kubernetes
services
is
an
anycast
domain,
where
a
message
that
is
sent
to
the
anycast
domain
is
routed
to
an
arbitrary
member
of
the
anycast
domain.
A
cluster
service
is
intended
for
internal
communication.
That
is,
the
source
of
the
message,
is
a
container
executing
in
the
context
of
a
part
on
the
same
cluster.
A
A
Here
we
focus
on
container
c1.1
executing
in
the
context
of
part
p1
hosted
on
node
n1
and
on
the
container
c2.1
and
c4.1
executing
in
the
context
of
port
p2
and
p4
both
hosted
on
node
n2
note
that
both
p2
and
p4
have
a
label
value
pair
of
fu
bar
container
c.
1.1
will
communicate
with
the
service
with
the
ip
address
of
the
service
on
port
80..
First
container
1.1
will
send
a
message
m
via
its
edge
to
port
switch
p1.
A
The
target
address
of
n
is
the
address
of
the
service.
The
target
port
of
n
is
80..
The
pod
switch
p1
will
receive
the
message
and
match
the
message
against
its
forward
information
base.
It
will
find
a
relevant
entry
that
instructs
the
port
switch
to
forward
the
message
to
nodeswitch
n1
port
switch
p1
will
send
the
message
m
via
its
edge
to
node
switch
and
1..
A
A
A
A
A
A
Here
we
start
our
journey
with
the
receive
event
of
message
m
at
node
switch
n1.
The
target
address
of
m
is
the
address
of
the
node.
This
node
switch
corresponds
with
the
target.
Port
of
m
is
thirty
thousand
the
node
switch
and
one
will
match
the
message
against
its
forward
information
base.
It
will
find
the
relevant
entry
that
instructs
the
node
switch
to
translate
the
target
address
to
the
address
of
port
p2
and
the
target
port
to
8080,
or
to
translate
the
target
address
to
the
address
of
port
p4
and
the
target
port
to
8080..
A
Kubernetes
ingress
is
an
api
gateway
for
http
messages.
This
listing
defines
an
ingress
that
consists
of
two
request
level:
routing
rules.
A
proxy
is
responsible
to
process
these
routing
rules.
Here
the
proxy
is
fronted
by
a
node
port
service
to
admit
external
messages,
http
requests
with
the
host
header
of
example.org
and
the
path
a
will
be
proxied
to
service
foo
on
port
8080..
A
Here
we
start
our
journey
with
the
receive
event
of
message
m
at
node
switch
n1.
The
target
address
of
m
is
the
address
of
the
node.
This
node
switch
corresponds
with
the
target.
Port
of
m
is
thirty
thousand
additionally,
but
not
shown
in
the
picture.
The
message
is
an
http
message
with
a
host
header,
of
example,
org
and
a
path
of
a.
A
A
The
target
address
is
translated
to
the
address
of
port
p1,
and
the
target
port
is
translated
to
8080..
The
node
switch
will
call
itself
and
match
the
new
message
against
its
forward
information
base.
It
will
find
a
relevant
entry
that
instructs
the
node
switch
to
forward
the
message
to
port
switch.
P1
node
switch
n1
will
send
the
message
m
via
its
edge
to
port
switch
p1.
A
The
port
switch
n1
will
receive
the
message
and
match
the
message
against
its
forward
information
base.
It
will
find
a
relevant
entry
that
instructs
the
port
switch
to
deliver.
The
message
to
the
proxy
port
switch
p1
will
send
the
message
m
via
its
edge
to
the
proxy,
and
finally,
the
proxy
will
receive
the
message.
A
Next,
the
proxy
performs
request
level
routing
the
proxy
matches,
the
http
host
header
and
the
path
of
the
message
against
its
decision
table.
It
will
find
a
relevant
entry
that
instructs
the
proxy
to
proxy
the
message
to
service
foo
on
port
8080..
Finally,
the
proxy
will
send
a
message
m
via
its
edge
to
node
switch
p1.