►
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.
Kubernetes Advanced Networking Testing with KIND - Antonio Ojea, RedHat
Kubernetes project evolution and its ecosystem is demanding new and more complex network requirements: multi-cluster and multi-zone connectivity, service topology awareness, traffic engineering, quality of service, ... KIND is a tool for running local multi-node Kubernetes clusters using Linux containers, it leverages current Linux networking capablities to emulate the cluster networking in a nested environment. This flexibility can be used to emulate more complex scenarios, let's go through some of these Kubernetes networking scenarios, and demonstrate how to use KIND to emulate and test them.
A
A
A
A
A
The
way
that
kind
works
is
using
these
images
to
create
a
cluster,
and
once
the
images
are
created
and
running,
it
runs
cubadmin
on
top
to
configure
the
cluster.
So
in
the
slide
you
can
see
what
is
the
most
common
deployment
of
kind
for
testing,
with
one
control,
plane,
node
and
two
worker
nodes
for
this
presentation.
We
are
going
to
focus
in
the
networking,
so
what
we
are
interested
in
is
how
kind
implements
the
networking
kind
in
by
default,
uses
docker
and
the
docker
networking
creates
a
linux
bridge.
A
Another
important
feature
from
kind
is
that
it
has
an
api
and
we
can
use
this
api
to
create
plugins.
So
we
don't
need
to
wait
for
the
project
to
implement
the
feature
that
we
want.
We
just
can
use
this
api,
and
this
is
what
we
are
going
to
demonstrate
in
this
presentation:
how
to
use
kine
api
to
create
complex
network
scenarios.
A
One
of
the
most
common
requests
in
kind
that
we
didn't
implement
it
officially,
is
to
be
able
to
simulate
nodes
with
multiple
interfaces
and
multiple
networks.
This,
usually,
this
is
common
in
bare
metal
scenarios
when
you
want
to
provide
different
networks
for
different
functionalities.
In
this
case.
In
the
example,
we
have
an
installer,
a
storage
network
and
an
external
network,
so
let's
explain
how
we
can
create
a
plugin
to
stand
kind
without
having
to
have
the
feature
in
the
kind
project
itself.
So
what
we
are
going
to
do
is
to
deploy
a
kind
cluster.
A
A
B
A
B
A
B
A
The
cluster
is
able
to
use
both
network.
One
of
the
good
things
of
kind
is
that
it
uses
the
docker
custom
networks
that
allow
to
resolve
the
container
name
so
for
the
server
we
don't
have
to
use
a
piece
we
just
can
use
the
name
of
the
container
here
directory,
so
this
spot
is
going
to
mount
this
new
folder
and
it's
going
to
create
a
file
called
dates
with
the
time
in
a
loop.
B
A
A
A
A
A
A
A
Okay,
so
let
me
show
you
how
to
do
this,
so
in
this
case
we
are
going.
We
have
a
new
plugin
called
multicaster
and
I
created
a
configuration
file.
This
is
up
to
you,
you
can
define
you
can
create
the
configurations
that
you
want
for
this.
What
I
used
is
a
template
that
allows
you
to
to
indicate
the
cluster
name
and
the
number
of
nodes
that
you
want
per
cluster
and
the
network
characteristics,
because
in
multicluster
we
need
different
subnets
per
cluster.
A
A
B
B
B
A
B
A
A
A
A
A
A
So
we
are
going
to
get
into
this
container
and
we
are
going
to
emulate
a
latency
of
100
milliseconds
to
emulate
the
latency.
What
we
are
going
to
use
is
the
traffic
control
from
the
linux.
This
is
this
and
we
know
that
each
cluster
is
connected
to
the
eth1
and
eth2
interfaces.
If
you
have
more
clusters,
you
just
need
to
map,
then
the
commands
to
the
corresponding
interfaces
and
we
are
going
to
tell
to
add
a
100
milliseconds
today.
B
A
We
can
see
that
the
pin
starts
to
go
100
milliseconds.
This
is
in
one
directions:
let's
do
it
for
the
other
direction,
so
we
see
that
we
have
200
milliseconds
and
what
do
I
want
to
demonstrate
with
this?
Okay,
so
we
have
more
latency.
Okay,
we
can
live
with
that,
but
let's
see
what
happens
to
the
ipad.
B
A
You
see
now
we
have
43
megabits
per
second.
That
is
why
it's
important
to
emulate
real
scenarios.
If
you
are
testing
a
multicluster
and
you
are
not
emulating
the
latency,
you
are
in
a
very
happy
scenario,
because
when
somebody
deploys
your
application,
whatever
in
a
multicultural
scenario
and
with
long
distances
like
europe
to
acl
to
us,
they
are
going
to
have
latency
and
the
latency
impact
directly
on
the
bandwidth
of
the
tcp
connections.
A
For
our
last
example,
we
are
going
to
simulate
a
multi-sony
scenario
and
demonstrate
a
new
feature
that
is
going
to
be
released
in
this
new
kubernetes
1.21
version
that
is
called
topology
aware
things,
so
basically,
users
start
to
deploy
more
multi-sound
scenarios
to
improve
the
resilience
of
their
clusters,
but
current
implementation
of
service
doesn't
provide
a
good
way
to
indicate
the
traffic
to
remain
on
zone,
so
it
usually
is
a
spread
all
over
the
cluster.
However,
the
users
may
want
to
give
some
affinity
to
improve
performance
and
reduce
costs,
for
that.
A
We
can
demonstrate
this
new
and
test
this
new
feature
with
kai
an
example
on
how
to
do
this.
Is
I've
created
a
plugin
that
deploy
a
multi-song
cluster?
So
you
just
need
to
give
the
parameters
with
the
topology
that
you
want.
It
means
the
the
songs,
the
number
of
songs.
We
are
going
to
say
two
zones
and
the
number
of
notes
person.
A
Once
we
have
our
cluster
working,
we
are
going
to
create
a
deployment
with
your
replicas
one
part
per
node.
So
for
that
I
have
a
template
here
that
you
can
use,
so
we
are
going
to
deploy
three
replicas
and
this
this
program
is
a
server
that
replies
with
the
name
of
the
bot.
So
we
are
going
to
create
a
deployment.
A
A
Server
deployment,
so
we
can
see
that
these
are
the
name
of
the
pots,
but
there
is
no
value
in
the
hints
field.
This
is
because
the
service
has
to
be
annotated
with
a
special
annotation
to
enable
the
topology
hints,
so
we
are
going
to
annotate
the
service.
This
is
the
notation
service.kubernetes
topology
aware,
hints
equal
auto.
A
So
once
we
annotate
the
service,
we
should
be
able
to
see
the
topology
hints
okay,
so
we
have
this
endpoint
that
are
preferred
to
have
traffic
from
zones
here,
zero
and
the
other,
this
other
one
that
is
prefer
to
have
traffic
from
some
one.
So
how
can
we
test
it?
So?
The
most
simple
way
to
test
this
is
to
send
traffic
to
the
pods
from
one
specific
zone.
A
In
this
case.
I
have
this
query
that
is
going
to
give
us
the
name
of
the
nodes
and
the
zone.
It
belongs,
so
that's
using
the
well-known
label
for
the
nodes,
topology.kubernetes.oh,
so
okay
and
we
can
see
that
the
kind
worker
2
is
in
song
one.
So
if
we
query
the,
if
we
query
the
service
from
this
node,
the
feature
should
give
us
affinity
to
the
pod
in
the
song
one
only
so
for
doing
that,
we
can.
A
A
B
A
My
recommendation
is
to
try
to
keep
it
always
these
scenarios
as
close
as
possible
to
the
reality,
as
we
saw
in
the
multi
multi-cluster
example,
adding
latency
to
the
to
the
test,
make
a
big
difference.
Another
important
point
is
the
kind
is
not
a
replacement
for
system
testing.
There
are
things
that
you
are
not
going
to
be
able
to
emulate
in
containers.
A
With
this,
if
you
are
interested
in
helping
or
contributing
or
you
have
some
idea,
you
want
to
create
your
own
plugins
or
collaborate
with
me
or
with
the
kind
community
in
this
plugins.
You
have
the
links
to
the
luck
channels
and,
if
you're
interested
in
the
in
this
presentation
code,
you
have
the
link
to
my
own
repo.
So
you
can
go
through
the
examples
on
your
own.