►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Virtual Application Networks for Cloud Native Applications - Ted Ross, Red Hat
The Internet is built for client-server architectures. Cloud-native software needs better abstractions for service interconnect. Learn about Virtual Application Networks (VANs) and how they advance the capabilities of cloud-native applications. Identify and access services deployed in remote clusters, balance workload across clusters, and multicast across clusters. Create multi-cluster networks where private and edge networks are involved, IP subnetworks overlap, and topology is redundant. In this session, we will introduce the Skupper project as a VAN implementation. We will then demonstrate how a VAN can be stood up by a non-privileged developer and how it solves many vexing multi-cluster communications problems. The demonstration will involve a multi-cluster network, in a redundant but not full-mesh topology, running an HTTP-based application in both public and private data centers.
https://sched.co/ekCc
A
A
I've
spent
most
of
my
career
working
in
embedded
data
networking
systems
and
in
network
security,
and
more
recently,
I've
spent
a
lot
of
my
time
working
on
the
more
abstract
notions
of
communication
like
messaging
and
such
today.
What
I'm
going
to
talk
to
you
about
is
some
challenges
with
cloud
native
interconnect,
I'm
going
to
introduce
the
notion
of
a
virtual
application
network
and
I'm
going
to
do
a
demonstration
of
the
scupper
project.
A
So
some
terms
before
we
get
into
the
meat
of
everything
here
that
I'm
going
to
be
using
to
make
sure
that
you
understand
first
of
all,
is
a
virtual
application
network.
Sometimes
I
will
refer
to
this
as
a
van,
so
this
is
really
about
multi-site,
hybrid
edge
cloud
interconnect,
it's
about
connecting
processes
and
services
together,
no
matter
where
they
are,
even
if
they
are
on
multiple
sites
or
multiple
clusters.
A
A
A
There
are
private
edge
networks
as
well
and
of
this
there
are
literally
hundreds
of
millions
of
overlapping
private
edge
networks.
They
use
the
same
addresses
address
space
overlapping,
and
this
is
the
reason
why
the
internet
scales,
as
hugely
as
it
does,
and
the
typical
pattern
of
communication,
then
that
you
see,
is
this
vertical
communication,
where
the
clients
in
private
edge
networks
use
the
server
servers
that
are
in
the
public
internet
and
that's
that's
a
generalization,
but
that's.
This
is
the
the
way
that
the
internet
is
basically
structured.
A
Endpoints
in
the
edges
with
each
other
is
actually
an
illusion,
because
that
traffic
is
actually
going
to
a
server,
then
back
back
down
again,
that's
the
way
that
those
applications
are
actually
written.
So
that's
why
I'm
going
to
claim
that
the
internet
and
client
server
architecture
kind
of
go
hand
in
hand.
They
both
grew
up
together
and
the
internet
is
very
well
suited
for
client
server
architecture.
A
I
will
further
claim
that
cloud
native
architecture
is
not
client
server
architecture.
Cloud
native
wants
to
do
things
much
more
flexibly.
We
want
to
be
able
to
talk
horizontally,
east
west
north
south
in
every
every
such
direction
that
might
exist,
and
we
don't
want
to
be
constrained
necessarily
by
where
things
are
located.
A
So
let
me
then
also
talk
a
little
bit
about
addressing
as
background
and,
as
I'm
sure,
you're
all
familiar
with.
Tcpip
and
internet
use
a
host
address,
plus
a
port.
Now
we
don't
generally
talk
about
numeric
host
addresses,
we
actually
use
names,
and
but
those
names
are
then
locally
mapped
to
addresses
using
a
name
lookup
service
like
domain
name
service,
so
the
name
maps
by
dns
to
a
host
address
the
host
address,
addresses
a
host.
The
port
then
says
which
process
on
that
host.
Am
I
wishing
to
communicate
with
now.
A
The
names
reference
a
process
rather
than
a
host,
so
we're
routing
to
processes
rather
than
hosts,
and
the
van
is
natively
multi-access
rather
than
unicast,
and
what
this
means
is
that
it
is
expected
that
multiple
services
will
be
deployed
with
the
same
address,
and
this
is
actually
what
we
want.
As
cloud
native
developers,
we
almost
never
want
to
create
a
single
singleton
instance
of
a
service.
We
almost
always
want
to
have
multiple
instances
of
a
service,
and
we
do
this
because
we
want
to
have
high
availability
in
case.
One
of
them
fails.
A
We
want
to
be
able
to
handle
high
high
amounts
of
load
so
that
we
can
spread
the
load
across
different
instances
of
the
service
or
we
might
be
interested
in
locality
where
we
want.
You
know
a
service
in
asia,
pacific
to
have
a
client
in
asia,
pacific
and
another
service
in
east.
You
know
western
europe
to
handle
services
that
come
from
western
europe,
and
that
makes
for
a
better
experience
for
for
everybody
involved.
A
So
multi-access
comes
in
two
flavors
as
the
anycast,
which
is
about
load
balancing
as
I've
just
been
talking
about
and
there's
multicast
for
distribution,
so
say,
for
example,
the
event
distribution.
If
I
wish
to
create
an
event
but
have
that
received
by
multiple
consumers
across
my
network,
then
I
would
use
a
multicast
flavor
of
multi-access.
A
Now
I
should
mention
that
you
know
vans,
as
I
said
before,
are
really
about
multi-cluster
multi-site
interconnect,
so
this
routing,
whether
it
be
any
cash
load,
balancing
or
multicast
distribution,
is
network
wide.
It's
not
constrained
to
a
lan.
It's
not
constrained
to
a
data
center.
It's
not
constrained
in
any
way
by
the
underlying
network.
So
if
I
want
to
multicast
across
the
globe,
that's
how
my
application
is
set
up,
then
I'm
going
to
do
be
able
to
do
that.
And
if
I
want
to
load
balance
across
the
globe,
I
can
do
that
as
well.
A
So
a
virtual
application
network
as
an
abstraction,
is
a
layer
that
we
can
insert
in
between
our
application
processes
and
the
well-known
tcpip
network.
So
it
utilizes
the
strengths
of
the
internet
and
doesn't
ask
the
internet
to
do
anything
that
it
wasn't
intended
to
do
so.
It
uses
that
you
know
that
really
strong
connect
connectivity
and
communication
capability,
but
doesn't
try
to
get
it
to
do
things
like
you
know,
global
multicast.
A
So
one
of
the
important
aspects
of
a
virtual
application
network
is
the
independence,
the
orthogonality,
so
the
shape
of
the
application
and
the
shape
of
the
network
are
not
related
and
they
are
independent
from
each
other.
So
as
devops,
we
want
to
allocate
our
services
to
site
for
our
business
reasons.
We
don't
want
to
do
it
because
the
network
is
constrained
or
demands
that
we
do
in
a
certain
way.
A
We
want
our
sensitive
data
to
be
located
in
our
private
data
centers.
We
don't
want
to
put
them
in
public
clouds.
In
fact,
it
may
be
required
by
law
for
us
to
do
this.
So,
even
though
these
data
services
may
be
needed
by
things
outside,
we
don't
want
to
locate
them
there
and
then,
in
terms
of
development.
Maybe
we
want
to
connect
our
laptop
to
a
van,
so
we
can
do
development
and
debugging
in
context
without
having
to
actually
use
a
container
platform
for
that
that
process,
which
is
makes
the
development
process
much
easier.
A
So
the
only
time
that
this
application
would
actually
open
a
port
to
public
is
if
they
actually
wish
to
do
so,
to
provide
an
ingress
or
a
portal
or
a
website.
For
example,
no
vpns,
no
ipsec,
no
sdn,
nothing
but
vanilla
networking
is
used
here
and,
furthermore,
it's
developer
accessible.
So
as
a
developer,
I
don't
need
admin
privileges.
I
don't
need
cluster
admin
privileges.
I
don't
need
anything
elevated.
I
don't
need
to
make
any
phone
calls
to
set
this
up.
A
All
I
need
is
access
to
name
spaces
in
these
locations
and
I
can
hook
them
together
using
a
van.
The
redundant
paths
are
recommended
because
they
provide
resilience
to
failure.
I
don't
need
a
full
mesh,
but
I
do
want
to
have
redundancy
in
case
in
case
there
are
failures
somewhere
in
the
network
or
if
data
centers
go
down.
A
A
I've
got
oc4
openshift
version
4
running
in
aws.
This
is
actually
in
europe.
I've
got
azure
kubernetes
services
running
in
u.s
east,
and
this
is
straight
vanilla,
kubernetes,
11711
deployment
and
I've
also
got
a
remote
system
in
a
remote
data
data
center.
That's
running
an
old
version
of
openshift
311
so
and
I'm
going
to
hook
them
up
in
a
network.
So
what
I'm
going
to
show
you
when
I
do
this
demonstration
is
a
k-native
service
that
I'm
going
to
deploy
on
the
laptop
and
aws.
A
A
This
is
sometimes
referred
to
as
cloud
bursting,
so
I'm
going
to
show
edge
to
edge
in
direct
connectivity
because
I'm
going
to
put
my
load
generating
client
over
here
on
remote
and
it's
going
to
be
able
to
use
these
services,
one
of
which,
on
the
laptop,
is
not
directly
accessible.
It's
going
to
be
a
two-hop
proposition
to
get
there
and
the
other
thing
I'm
going
to
show.
As
I
mentioned
before
is
multi-multi-cluster
load
balancing
because
I'm
going
to
show
that
service
being
offered
on
the
two
places
simultaneously,
so
let's
get
started.
A
So
what
I'm,
showing
you
is
this
sort
of
my
demonstration
view
on
the
upper
left
shows
the
topology
and
then
I've
got
a
command
line
terminal,
color
coded
for
each
location,
so
you
can
see
what's
going
on
there.
So
the
very
first
thing
I
do
here
is
I
first
of
all
I
have
to
get
the
scupper
executable
from
the
scupper
project,
but
what
I
will
then
do
is
just
issue.
This
simple
command.
A
A
And
this
one
is
a
ws,
so
I'm
just
going
to
discovering
it
site,
name,
aws
and
I'll.
Do
the
same
thing
here
called
azure
the
same
thing
here
called
remote
I'll,
do
the
same
thing
here,
I'll
call
it
laptop,
but
one
of
the
things
I'm
doing
on
laptop
is
I'm
enabling
a
console,
because
I
want
to
show
you
the
scupper
console
while
I'm
at
it.
So
I'm
turning
off
the
console
auth
for
the
purposes
of
this
demonstration,
because
I
trust
my
audience
not
to
be
attempting
to
hack
it
while
I'm
doing
the
demonstration.
A
So
this
this
now
has
enabled
scupper
it's
injected
the
router
into
my
namespace,
a
scupper
router
that
can
be
used
to
set
up
this
network.
So
the
first
thing
I
need
to
do
for
my
two
public
sites
is
create
a
which
called
a
connection
token,
so
I'll
create
a
connection
token
for
aws
and
I'll
create
one
for
azure.
A
A
So
I
can
make
a
connection
and
then
I
will
establish
my
first
connection
between
azure
and
aws,
so
I
will
scupper,
connect
my
aws
and
configure
it
to
make
this
connection,
and
the
next
thing
I
will
do
is
I
will
configure
both
of
my
edge
systems,
my
laptop
and
my
remote,
to
make
redundant
system
connections
in
to
each
of
the
public
locations.
So,
let's
see
if
I
can
get
this
to
work
right,
so
let's
connect
for
aws
and
azure,
and
then
I
will
do
the
same
in
my
remote
aws.
A
And
they
are
configured
to
connect
and
off
it
runs
all
right,
so
while
things
are
stabilizing
here,
let
me
talk
a
little
bit
about
this
picture.
You'll
see
that
there
are
arrowheads
depicted
in
these
connections
and
these
arrowheads
are
significant
only
in
that
they
depict
the
direction
of
the
connection
establishment.
A
A
So
so
what
happens
now
is
once
those
connections
are
established.
The
arrowheads
are
no
longer
significant
because
the
connections
are
long-lived,
they're
established,
they're,
secure
and
once
they're
in
place.
They
operate
bi-directionally.
So
this
is
my
network
now
that
is
established
between
the
four
different
locations.
So,
while
I've
been
talking
I'll
give
it
a
chance
to
stabilize
let's
see
what
happens
here,
I
will
ask
my
laptop
to
say
scupper
status.
A
What's
the
status
here
and
it's
going
to
tell
me
that
it
is
connected
to
three
other
sites,
one
indirectly,
that's
kind
of
what
we
expect.
Isn't
it
because
it's
connected
to
three
sites,
but
one
of
them
doesn't
have
a
direct
connection
to
it.
Now,
if
I
were
to
ask
azure
the
same
question
scupper
status,
and
it
should
get
back
to
me,
hopefully
with
something
similar.
Yes,
it's
connected
to
three
other
sites
and
none
of
them
indirectly.
So
this
is
correct.
Azure
has
a
direct
connection
to
all
the
other
sites.
A
And
I've
got
one
called
scupper
controller.
I'm
going
to
grab
his
external
ip
address,
I'm
going
to
go
to
a
web
browser,
I'm
going
to
web
to
this
port
8080
as
it's
exposed.
This
is
the
scupper
console
and
it's
connecting
up
and
if
I
go
to
the
sites
tab,
this
is
going
to
tell
me
what's
actually
happening
in
my
network
and
it
looks
kind
of
familiar.
So
this
is
a
good
sign
that
what
we've
set
up
manually
is
actually
what
we
got.
So
we
here
we
have
a
network.
A
You
saw
the
whole
thing
set
up
and
it's
all
established
and
ready
to
go.
So
it's
time
to
go
on
to
the
next
step
and
before
I
do,
I'm
just
going
to
do
a
little
oc
get
services
here
on
my
remote
for
reference,
and
I'm
now
going
to
and
you'll
see
that
there
is
the
load
gens,
the
client
load
generating
client.
I
talked
about
and
there's
a
couple
services
associated
with
the
scupper
deployment
itself.
A
A
A
A
So
greeting
is
a
service
for
which
there
is
no
pod
backing
it
or
deployment
backing
it
locally.
But
this
is
actually
what
has
been
done
by
scuffer
so
sk.
I
I
put
these
k
native
servers
up
on
aws
and
laptop,
and
then
I
scupperized
them,
and
now
I
have
services
in
all
four
locations
that
can
be
used
to
access
them
so
think
of
this
as
a
proxy
service
that
can
get
to
that
load
that
remote
place.
A
So
I've
got
the
greeting
pod
running.
This
comes
up
initially,
but
when
it's
not
used,
k
native
will
scale
it
to
zero.
Okay,
get
pods
same
here
and
you'll
see
that
since
I
did
this
one
earlier,
this
one
has
already
scaled
down.
So
there
is
there's
no
pod
running
here,
even
though
this
is
the
primary.
A
A
So
let's
see
I've
got
that
running
now.
I
can
look
at
the
status
from
my
load
generated,
client
and
I'll
see
that
of
the
last
hundred
items.
One
hundred
percent
were
served
by
zm
ll-8,
so
that
means
that,
even
though
my
client
here
is
here
on
remote,
it's
accessing
the
service
deployed
on
laptop
and
if
I
come
back
and
get
the
pods
here
on
aws,
I
presumably
that
one
will
be
gone
and
it
is
so
because
it's
not
needed.
A
A
Let's
increase
the
load,
let's
take
it
up
to
10
concurrent
clients
making
requests
at
the
same
time,
and
when
I
do
that,
I'm
going
to
come
over
the
threshold.
So
I
expect
that
in
aws
I'm
going
to
see
a
pod
spin
up
and
there
it
is
so.
I
will
now
go
back
to
my
status
view
and
I'm
going
to
see
that
I
am
balancing
my
load
between
zml8,
which
is
on
my
laptop
and
the
new
one
which
is
h5fph,
and
that
is
what's
running
here.
A
So
I
will
see
if
there's
a
balance
between
these
so
of
the
last
100
requests.
52
were
handled
locally
on
my
laptop
and
48
were
handled
out
on
aws,
so
the
balancing
is
not
round
robin
it's
based
on
the
actual
completion
rate
of
the
services,
so
it
balances
dynamically
to
the
services
that
are
running
fastest.
And
now,
if
I
go
back
to
my
console
again,
look
at
my
deployments,
I
will
see
that
they're
being
balanced
between
aws
and
laptop.
A
A
A
And
if
I
look
here
again,
you'll
see
that
the
numbers
are
increasing
on
my
laptop
but
they're
not
increasing
on
aws,
because
aws
is
no
longer
handling
load
because
it
is
not
needed
and
I'll
take
one
more
look
over
here
to
see
if
it's
still
running
but
it'll
take
a
minute
to
go
down
and
be
terminated.
So
what
I'll
mention
right
now
is
that
if
you
go
to
scupper.io
and
look
in
the
the
github
repository
associated
with
it,
there
are
examples
in
there
and
there
is
an
example
in
there.
A
So
it
has
all
the
ammo
all
the
source
code
for
everything
that's
being
run
in
terms
of
my
client
and
server
and
the
instructions
for
doing
all
of
this.
So
if
you
wish
to
replicate
this
experiment
and
demonstration
yourself,
everything
you
need
is
there
and
you
can
have
a
look
at
that.
So
now
that
I've
been
talking
long
enough,
we
will
see
on
aws
that
k
native
has
scaled
me
to
zero
and
I'm
no
longer
using
those
resources
that
are
no
longer
needed.