►
From YouTube: Webinar: AppSwitch- Proxyless Service Mesh
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
We are going through an interesting cycle of application decomposition and recomposition. While the microservice paradigm enabled by containers is driving monolithic applications to be broken into separate individual services, the service mesh paradigm enabled by the proxy sidecars is
helping them to be connected back together into well-structured applications.
This talk presents AppSwitch, an extremely fast and simple service mesh framework that offers traffic management and other service mesh functions without a proxy. AppSwitch provides a fundamentally new networking mechanism for containers based on transparent interposition
of the BSD socket API. In addition to providing connectivity for containers, the same mechanism also performs service mesh functions with several new advantages:
– It can perform traffic management without actually touching data traffic and hence extremely fast
– It does not require root privilege for its operation
– It elegantly addresses issues such as service startup order and supports otherwise uncooperative legacy applications
A
Hello:
everyone
I
worked
the
CNC
a
webinar
of
today
we're
gonna
get
started.
We
seem
to
be
a
fair
amount
of
people
on
the
webinar,
so
welcome
again.
So
today
is
recognize
about
apps,
which
proxy
less
service
mesh.
We
have
Dinesh
super
of
80
co-founder
of
orbit.
My
name
is
alessandro.
Sama,
CN,
CF,
ambassador
I'll
be
moderating
today's
webinar
again.
Thank
you.
Everybody
to
join
us
today.
This
webinar
will
be
recorded.
We're
gonna
publish
the
recording
afterwards,
so
a
bit
of
introduction
a
bit
of
housekeeping.
A
B
Thanks
Andrew,
hello,
everybody
thank
you
for
joining
today.
My
name
is
Dinesh
Trivedi
I'm,
the
co-founder
CTO
of
Apoorva,
and
also
the
creator
of
this
technology
that
I'm
going
to
talk
about.
It's
called
apps,
which
there
is
a
pretty
picture
on
screen
here,
I'm
going
to
get
to
it
in
a
bit.
But
let
me
start
with
a
couple
observations
around
the
broad
trends
that
we've
been
seeing
the
last
several
years.
B
So
there's
this
application,
decomposition
and
recomposition
that's
happening.
Microservices
paradigm
enabled
by
containers
is
driving
the
decomposition
of
otherwise
monolithic
and
legacy
applications.
There
is
a
whole
host
of
benefits
in
doing
that,
but
then
these
services
are
logically
separate,
but
not
independent,
so
naturally
there'd
be
some
problems
that
come
because
of
that,
and
there
is
this
other
compensating
trend
which
I
can
which
I
think
of
as
recomposition,
which
is
which
is
basically
driven
by
service
pair
so
paradigm
enabled
by
the
sidecar
proxy
approach.
It's
basically
putting
these
services
back
together
into
well-structured
applications.
B
It's
an
interesting
cycle
of
decomposition
to
accomplishing
that
we're
seeing
here,
but
if
we
look
more
closely
at
containers
the
technology
that
enables
this
decomposition
in
microservices,
it's
a
progression
actually
from
pista
missions
to
our
solutions
to
containers.
It's
a
right
abstraction,
it's
an
abstraction
that
is
the
application
layer.
It
is
fit
to
encapsulate
all
of
the
application
state.
So
that's
that's
good!
Now
you
have
you.
Have
these
problems
with
decomposition?
B
First
of
all,
when
you,
when
you
have
these
services
scattered
across
the
cluster,
they
need
to
find
each
other
their
service
discovery
problem,
and
there
may
be
some
dependency
or
ring
among
these
services,
which
may
be
typically
taking
care
with
internal
locking
mechanisms
of
a
monolithic
application.
Now
that's
surfaces
as
an
actual
problem
when
it
is
decomposed
and,
of
course,
these
services
need
to
authenticate
themselves
to
each
other
they're,
not
together
or
they're
separate
now,
and
all
of
these
needs
observability.
B
So
these
are,
the
problems
are
gonna
come
out
of
the
decomposition
and
service
mesh
is
basically
an
app
glue
layer
to
just
all
those
issues.
Now
the
question
is:
if
containers
are
the
abstraction
to
decompose
these
applications
shouldn't,
they
also
take
care
of
networking
after
all,
containers
abstract
all
of
these
resources
to
application
level,
and
that
includes
networking,
so
shouldn't
containers
address
that
problem
already
before
before
I
go
into
the
region.
Let
me
just
you
know,
talk
about
the
some
of
the
details
of
the
namespaces
and
and
how
this
came
about.
B
What
do
containers
do
right?
They
take
all
of
the
underlying
physical
resources,
abstract
them
to
a
level
CPU
becomes
threads
block
device
and
storage
device
has
become
final
points,
virtual
memory,
you
know,
but
when
you
look
at
networking
what
is
a
Nik
on
the
host?
Is
it
still
projected
as
a
network
device
inside
the
container
it's
a
virtual
equivalent,
but
it
is
still
a
device
artifact.
Nevertheless,
so
there
is
a
there's,
a
fundamental
misalignment
when
it
comes
to
the
network
aspect
of
the
containers.
B
If
you
you
know
to
appreciate
how
this
happened,
this
way,
I'm
gonna
take
a
brief
detour
to
to
outline
some
of
this
prehistory.
Actually,
I
spent
a
lot
of
time.
Thinking
about
these
problems,
as
as
part
of
my
grad
school
work
at
Kona
in
the
year,
2001
2002,
the
problem
that
I
was
thinking
about
was
how
to
encapsulate
all
of
this
application.
State
I
was
fascinated
by
virtual
machines,
but
then
they
have
their
shortcomings
now.
How
can
that
encapsulation
be
done
in
in
just
application
application
level?
B
So
that
was
a
problem
and
we
were
actually
doing
this
for
different
purposes,
particularly
like
migration
and
checkpointing
of
these
applications.
In
that,
in
that
context,
we
introduced
this
notion
of
pod.
We
talked
about
this
in
our
OS
di
2002
paper.
That's
that's
where
the
kubernetes
power
actually
comes
from
and
then
that
work
we
licensed
to
HP
Labs
I
spent
time
looking
at
application
of
this
pod
abstraction
to
checkpointing
of
distributed
HPC
applications
MPI
based
applications,
which
is
which
is
kind
of
an
old-world
equivalent
of
the
modern
service
mesh
micro
services
happen.
B
So
it's
a
you
know,
say
nothing.
No
idea
is
really
new,
but
but
after
applying
containers
to
that
problem
exposed
exposed
some
of
these
shortcomings.
At
that
point,
also,
how
would
we
connect
these
individual
pieces
of
the
application
together
in
a
way
that
that
aligns
with
the
application
of
abstraction
so
those
those
and
that
underlying
technology
became
the
basis
for
its
company
called
meiosis,
which
we
which
we
sold
to
IBM
in
2005
and
then
IBM
invested
in
pushing
some
of
those
namespace
and
things
like
technology
into
the
kernel
and
that
some
time?
B
Actually,
the
networking
aspect
of
containers
was
heavily
influenced
by
the
way
virtual
machines
did
their
networking
and
containers
needed
to
support
the
the
use
cases
of
virtual
machines
and,
and
to
that
extent
the
device
abstraction
was
actually
chosen.
That's
not
how
we
urgently
implemented
it
in
the
earlier
stages
of
this
work,
but
but
being
influenced
by
the
virtual
machines.
That's
how
the
abstraction
ended
up
being
now.
There
is
an
opportunity
to
undo
some
of
this,
and
perhaps
do
it
the
right
way.
You
know,
let
me
also
go
over
the
evolution
of
the
network
abstraction
here.
B
This
is
the
standard
application
operating
system
infrastructure
stack
the
simple
bare
metal
underlay,
with
virtual
machines.
This
overlay
networking
was
introduced
that
sits
between
our
existing
infrastructure
and
with
containers
and
cloud
and
cloud
native
applications
that
same
abstraction.
The
old
abstraction
is
is
stretched
to
accommodate
the
needs
of
these
applications
and
and
it
actually
introduces
problems.
B
So
what
really
needs
to
happen
is
the
destruction
needs
to
be
stepped
up
closer
to
the
application
and
that's
kind
of
what
I'm
going
to
talk
about
the
rest
of
the
stock
called
apps
which,
and
it
is
an
application
level,
networking
abstraction.
So
what
this
does
is
this
is.
This
is
also
a
progression.
It's
an
equivalent
progression
on
the
networking
stack
on
the
computer
side.
We
have
physical
machines,
virtual
machines
and
containers
progressively
going
closer
to
the
application
on
the
or
you
can
save
your
physical
networking
works,
networking
and
then
absolute.
B
It's
kind
of
the
up,
occasionally
level
equivalent
of
containers
on
the
networking
stack.
Let
me
go
into
the
details
of
how
this
actually
works.
So
what
what
we
do
is
is
abstract
the
network
artifact
to
application
level.
So
what
how
would
applications
think
about
networking,
it's
basically
sockets
and
sessions?
What
duplications
want
to
do?
They
probably
want
to
make
an
RPC
call
or
serialize
some
structure
as
JSON?
That's
applications
view
of
networking.
B
What
actually
does
is
it
projects
that
view
based
on
sockets,
something
that
an
application
can
relate
to
directly
as
opposed
to
the
network
interface,
and
in
order
for
the
application
to
talk
the
network
interface,
you
need
all
these
intermediate
layers.
So
if
you
do
it
this
way,
some
of
the
some
of
the
problems
associated
with
the
decomposition
can
actually
be
addressed
more
effectively
and,
at
the
same
time
retain
the
backward
compatibility
for
even
legacy
applications.
B
So
if
there
is
a
challenge
in
bringing
some
of
these
legacy
applications
to
the
new
world
of
service
flash
because
they
have
certain
expectations,
they
they
use
these
archaic
protocols,
I
mean
they
use
UDP.
They
may
have
certain
specific
dependencies
on
the
underlying
network.
Artifacts
and
those
can
be
reconciled
much
more
easily
with
with
a
layer
that's
closer
to
the
application.
So
let
me
again
go
into
the
details
of
how
this
works.
Ok,
so
this
is
the
architecture
of
apps
which
it
has.
B
It
has
two
counterparts,
one
that
plugs
into
the
application
itself,
think
of
it
as
application
apps,
which
client
and
the
other
part
is
this
apps,
which
daemon
the
apps
which
client
monitors
the
applications
network
API,
particularly
the
BSD,
socket
API,
as
the
application
is
making
calls
like
socket,
listen,
connect,
sex,
alcohol
or
even
netlink,
anything
that
tells
the
application
about
view
of
the
underlying
network.
All
of
those
calls
are
intercepted
by
by
this
by
this
ab
switch
client,
and
it
actually
has
this
trap
generator
the
the
trap
generator
traps.
B
These
system
calls
and
forwards
them
to
the
daemon.
That
is
a
trap
handler,
which
is
the
counterpart
of
traps
generator.
The
trap
handler
receives
those
calls
and
actually
conducts
all
of
applications,
networking
on
behalf
of
the
application
and
let's,
let's
take
an
example
here.
Let's
say
there
is
a
client
which
is
running
on
one
of
the
nodes
in
the
cluster,
and
it
makes
a
connect
call,
it
creates
a
socket
and
then
it
create.
It
makes
a
connect
call
and
it
provides
some
IP
address
to
connect
to
and
then
on
a
different
node.
B
There
is
a
server
which
creates
a
socket
and
then
performs
a
bind
and
listen
essentially
making
that
sock
into
a
listening,
socket
and
server.
At
that
point,
apps
which
records
the
existence
of
this
service,
this
new
server
that
has
come
up
and
it
doesn't
have
to
be
TCP.
It
will
be
uniquely
as
well,
but
the
service
comes
up
and
apps,
which
makes
a
note
of
it
and
then
communicates
the
existence
of
this
server
to
other
nodes
in
the
cluster
or
other
apps
which
demons
running
on
other
nodes
in
the
cluster.
B
B
The
client
thinks
that
it
is
connecting
to
a
certain
IP
address,
I,
say
1,
1,
1
1,
but
AB
switch
daemon
would
translate
it
to
the
appropriate
physical
IP
address,
on
which
the
server
is
actually
bound
to
and
then
on
the
server
side
after
we
do
the
reverse
translation
back
to
the
back
to
the
server.
So
this
is
one
instance
of
how
you
can
do
overlay
without
actually
getting
the
data
path.
Now,
once
the
connection
is
actually
established,
a
switch
is
completely
out
of
the
picture.
B
The
FD
or
the
file
description
socket
that
is
returned
to
the
application,
doesn't
doesn't
have
anything
that
says
what
IP
addresses
are
actually
being
used.
The
application
may
do
a
get
sock
name
or
get
Pierre
name,
in
which
case
again,
apps,
which
would
get
in
the
way
and-
and
it
would
translate
the
idea
to
Z
such
that
application
would
see
a
first
consistent
view
of
the
underlying
network.
B
So
going
into
the
details
of
this
apps,
which
daemon
here
it
has,
it
has
a
service
table
which
is
a
distributed
table
consisting
of
all
the
servers
that
have
come
up
on
all
the
nodes
in
the
cluster.
So
this
is
going
to
the
topology
here,
where
I'm,
showing
3
3
apps,
which
nodes
applications
all
plugged
into
this
apps,
which
daemon
and
apps
which
client
is.
It
is
actually
running
in
the
context
of
the
application
itself
and.
B
The
the
communication
among
the
apps,
which
demons
is,
is
conductor,
overhead,
gossip
channel
that
stitches
together
these
nodes
into
a
cluster,
and
there
could
be
other
clusters
of
apps
which
and
each
cluster
would
have
a
gateway
and
all
gateways
participate
in
a
different
Federation
as
a
channel.
So
basically
you
can
have
you
can
have
multiple
clusters,
all
of
them,
stitched
together
into
into
n
network
and
applications
on
on
one
cluster,
can
reach
applications
and
servers
on
a
different
cluster
over
these
IP
addresses
or
these
identities,
which
are
decoupled
from
the
underlying
network
identities.
B
So
that's
the
that's
the
high-level
view,
but,
as
you
can
imagine,
there
are
many
interesting
things
you
can
do
once
you
have
this
layer.
The
difficulty
in
being
able
to
do
this
actually
is
is
intercepting
the
API
without
performance
cost
and
without
requiring
changes
to
the
application
or
the
underlying
infrastructure.
B
This
should
actually
work
for
any
kind
of
application,
and
we've
tested
this
with
IP
in
websphere,
and
s
AP
or
libras,
and
things
like
that
and
the
performance
cost
also
has
to
be
very
low
or
in
fact,
in
this
particular
case
it
can
be
even
faster
than
native
and
explain.
How
and
the
other
requirement
for
this
is
that
it
should
not
require
privilege
it
shouldn't,
require
a
kernel,
module
or
or
even
run
as
root.
B
So
now,
why
do
we
do
this?
And
how
does
it
plug
into
the
service
mesh,
so
I'm,
just
showing
here
the
architecture
of
Sto
and
how
how
a
client
and
a
server
would
communicate
in
the
context
of
astillero?
You
know
so.
On
the
left,
you
see,
the
client
is
redirected
to
talk
to
its
sidecar
proxy
and
there's
some
iptables
rules,
and
this
can
be
and
there's
overhead
in
doing
that,
but
that
can
be
optimized
and
there's
fantastic
work.
B
No,
no
proxy
involved
in
this
case,
because
proxy
is
ultimately
a
way
to
get
in
the
path
of
interactions
between
these
services
and
if
there
is
a
way
to
do
it
without
being
the
data
path
by
just
swiss
ling
foreigners
at
the
connect
and
the
control
api
level,
then
that
that
would
result
in
this
optimized
flow
and
also,
if
you
look
at
how
the
container
networking
is
currently
done.
So
there's
this.
The
application
running
inside
the
container
would
see
the
one
end
of
the
we
eat
there.
B
So
all
of
this
will
also
be
removed
in
the
case
of
a
switch
because
because
the
the
client
and
server
are
connected
simply
over
directly
over
a
socket
cutting
through
some,
these
layers
and
we've
experimented
with
the
integration
of
AB
switch
into
Sto,
and
we
see
as
much
as
eighteen
times
improvement
in
latency
in
p50
latency,
and
there
is
a
blog
that
I
am
listing
here
at
the
bottom
of
screen.
It's.
It
basically
goes
with
the
details
of
the
integration
and
basically
shows
that
you
can.
You
can
bypass
these
layers.
B
Applications
already
can
access
network
today
on
the
on
the
host.
An
application
can
access
the
network
on
the
host,
even
as
a
regular
user,
but
the
moment
that
application
is
placed
in
the
network
namespace
of
a
container,
it
loses
all
connectivity
and
a
privileged
user
would
need
to
intervene
and
do
the
required
plumbing
for
this
container
to
get
Network
and
that
needs
to
go
through
the
suite
fair
and
the
linux
bridge
that
gets
plugged
into
not
a
link
host.
B
So
this
additional
steps
required
required
privilege-
and
in
fact
this
is
the
this-
is
the
main
reason
for
containers
container
adoption
being
being
influenced
by
this
additional
requirement
of
privilege.
You
know,
otherwise,
the
privilege
footprint
of
the
application
should
be
identical
to
the
privilege
footprint
off
its
containerized
equivalent.
So
what
has
changed
here?
In
fact,
there
is
no
container
object
in
the
kernel,
but
but
just
by
running
an
application
as
a
containerized
application.
B
You
need
this
additional
privilege,
so
the
privilege
fruit
is
expanded
and
if
there
is
a
way
to
not
require
the
privilege
now,
the
additional
barrier
for
container
adoption
would
be
more
freely
and
apps,
which
can
address
that.
As
well
see
once
you
can
imagine
right,
you
can
imagine
that
the
layer
of
interposition
right
below
application
has
interesting
implications.
It's
kind
of
like
what
we
have
been
doing
with
with
software-defined
networking
or
network
virtualization.
B
All
of
the
all
of
the
functionality
is
that
the
network
virtualization
can
provide,
can
also
be
done
at
this
at
this
layer
closer
to
the
application,
in
fact,
anything
that
the
application
would
need
in
terms
of
networking
can
actually
provide
it
more
effectively
at
this
layer.
So
I'm
just
listing
here
some
of
these
capabilities
that
absolute
support,
the
first
one
here
is
auto-generated
service
registry
because
acts
which
actually
knows
where
the
servers
are
actually
coming
up
it
either.
B
It
has
this
distributed
service
table
which
keeps
track
of
all
of
these
services,
and
you
don't
need
the
the
service
to
go
and
register
itself
with
a
centralized
service
registry,
and
this
is
automatically
curate
and
when
the
service
goes
away,
its
entries
are
manually,
moved
and
and
in
fact,
a
switch
capture,
some
additional
metadata
around
that
server
and
populates
the
tables
of
the
clients.
Looking
for
the
service
can
then
query
this
this
service
registry
and
and
connect
them
an
in
fact
automatic
automatic
service
dependency.
B
Discovery
can
also
be
performed
because
the
interactions
among
the
clients
and
servers
can
be
interleaved
in
a
way
such
that
the
the
the
clients
that
are
connecting
to
the
servers
would
be
automatically
waited
for
the
service
to
come
up,
so
that
there
is
no
case
where
the
client
just
falls
to
floor,
because
the
service
hasn't
yet
come
up.
Yet
no
I
mean
the
application
may
be
up,
but
the
service
may
not
be
ready.
B
Yet
there
are
other
ways
of
handling
these
kinds
of
problems,
but
a
more
effective
way
would
be
to
actually
do
this
interleaving
appropriately
at
the
call
level
which
mean
clients
and
servers,
and
that's
there's
actually
there's
a
there's,
a
blog
that
I
wrote
recently
on
sto
about
that
integration.
In
fact,
it
also
supports
applications
like
IBM
WebSphere.
The
details
are
in
the
blog
as
well.
B
You
can
also
do
load
balancing,
for
example,
the
client
is
connecting
to
an
IP
address,
we'll
say
one
one,
one
one,
and
there
may
be
multiple
instances
of
that
service.
That's
backing
the
IP
address
and
apps,
which
knows
about
all
of
them,
and
it
can.
It
can
decide
which
particular
instance
of
that
service
to
connect
this
client
to
so
you're,
doing,
load,
balancing
but
again
without
getting
into
the
data
path,
not
as
a
proxy
or
or
doing
load-balancing
at
the
the
network
packet
layer.
B
So
you
have-
and
you
can
do
this
on
the
client
side.
Obviously
it
is
more
efficient
and
the
other
point
here
is
the
clients
may
have
certain
dependencies
on
the
server.
Let's
say:
I
have
some
static
configuration
in
my
client
which
points
to
the
service
that
I'm
connecting
to,
but
the
service
has
moved
for
whatever
reason,
maybe
the
maybe
the
client
and
maybe
the
server
has
moved
migrated
to
cloud
and
they've
got
a
different
IP
address.
So
there
are
ways
of
reducing
these
kinds
of
rounds,
but
but
actually
in
in
apps,
which
this
is
this.
B
This
gives
actual
level
of
flexibility.
If
the
server
I
get
this
changes,
you
don't
have
to
reconfigure
the
client,
but
it
can
be
automatically
reprogrammed
to
to
point
to
the
new
location
of
the
server
and
as
I
was
showing
earlier
with
the
cluster
topology
of
apps,
which
you
can
have
a
flat
network
that
extends
across
multiple
clouds
and
on
primont
cloud.
So,
basically,
the
network
would
all
look
flat.
Even
across
these
boundaries
of
data
centers
and
clouds,
you
can
do
transparent,
TLS
insertion.
B
B
B
A
Thank
You
Dinesh
there
was
a
great
presentation
and
a
spark
a
lot
of
interest,
a
lot
of
questions,
so
we
have
about
10
now
so
good
that
we
are
a
bit
early
to
finish
so
I'm
gonna
just
start
repeating
the
questions
and
remember
there
are
ten.
So
please
be
brief
and
my
for
all
time.
So
the
first
question
is
from
Nik
and
he
wants
to
know
what
happens
when
the
up
switch
demon,
crashes,
I,
guess
in
support
I
suppose
also
have
the
same
question:
where
is
the
state
saved
for
the
up
switch
right.
A
B
Server
when
there
is
a
server
that
is
making
a
let's
created
a
socketing
and
is
calling
listen
at
that
point,
apps,
which
demon
is
actually
performing,
listen
on
behalf
of
the
application
navigation
is
still
running
and
when
apps,
which
diamond
eyes
that
listening
socket
actually
dies
when
apps,
which
comes
back
its
knows
that
it
was
listening
on
this
on
this
socket
and
and
it's
going
to
recreate,
that
state
and
and
the
service
would
be
fine.
Okay,.
A
B
An
important
question,
actually
I
I,
probably
didn't
emphasize
enough.
There
are
three
properties
that
need
to
be
met
here.
First,
in
fact,
the
probably
the
most
important
one
is
transparency
to
application
on
the
generality
of
support.
What
are
the
applications
that
apps,
which
can
work
for?
It,
is
actually
any
application.
B
Statically
linked
or
dynamically
linked
or
Java
or
applications
which
are
not
particularly
well
behaved,
that's
obviously
very
important,
so
yeah,
there
is
no
restriction
on
the
kinda
binaries.
This
supports
and-
and
the
question
is
fair
because
most
of
the
earlier
techniques
relied
on
techniques
like
le
preload,
which
depend
on
dynamically
linked
applications.
But
it
is
not
the
case
with
apps,
which
I.
B
Important
question
as
well:
I've
talked
about
this
in
in
that
blog.
Actually,
yes,
it
does
do
that,
and
the
way
that
would
work
is
if
the
user
chooses
that
kind
of
deep
inspection,
then
apps,
which
would
offload
the
data
traffic.
Normally,
it
doesn't
intercept,
read
and
write
and
send
message
and
receive
message.
B
You
know
the
data
path
calls,
but
it
can
do
so
and
and
in
fact
what
it
would
do,
then,
is
it
offloads
the
the
processing
of
HTTP
headers
to
plugins
and
and
the
way
does
it
is
somewhat-
were
efficient
than
directly
intercepting
the
data
path
calls.
It
actually
passes
the
FD,
so
the
FB,
the
socket
descriptor
that
apps,
which
accepts
that
FD
is
passed
to
the
plug-in
and
the
plug-in.
B
Will
the
plug-in
could
be
Envoy
or
it
could
be,
it
could
be
any
proxy
and
it
would
then
receive
that
FB
as
opposed
to
listening
on
a
different
FD
and
then
getting
the
traffic
on
it.
It
actually
receives
it's
as
if
it's
as
if
the
Envoy
proxy
has
acquired
some
of
these
capabilities
of
apps,
which
and
apps
which
facilitates
that
and
then,
of
course,
the
HTTP
plugins
and
all
the
processing
would
be
done
by
own
by
itself,
so
that
integration
talked
about
in
in
the
blog
here.
B
Yes,
in
the
yes
in
a
more
efficient
way
yeah,
so
there
is
a
fast
path
that
apps,
which
supports
if
the.
If
the
deep
inspection
is
not
needed,
but
if
it
is
needed,
then
it
hands
it
off
to
the
on
web
proxy
and
there
are
many
places
where
these
optimizations
are
enabled.
For
example,
maybe
you
are
just
making
the
traffic
decision
based
on
the
header,
just
the
header,
in
which
case
you
actually
don't
need
the
proxy,
because
the
header
occurs
right
at
the
first
call.
So
you
have
you,
do
the
initial
read?
B
Actually,
what
absolutely
does
is
it
doesn't
do
the
it
does
the
peak
there
is
a
message
peak
option
to
receive
message
system
calls
with
which
it
can
look
at
that
you
can
peek
at
the
header
and
based
on
that
it
can
make
a
decision
and,
and
then,
after
that
it
gets
out
of
the
data
path.
So
you
can
actually
do
some
of
these
things
without
requiring
a
proxy.
You
can
actually
do
this
processing
looking
at
the
HTTP
headers,
without
without
being
the
data
path
throughout
the
connection,
because
relevant
information
is
only
at
the
beginning,
I.
B
That
particular
functionality
is
not
well
formed
in
the
current
implementation,
that's
out
there,
but
it
is
available.
The
average
demon
itself
produces
copious
amounts
of
logs
and
and
they
can
be
mined
for
tracing
some
of
these.
Some
of
these
events
can
be
pushed
to
time,
series
database
and
analyzed,
but
because
of
the
richness
of
events
that
AB
switch
tracks,
that's
that's
an
important,
valuable
use
of
apps
which,
but
it
is
currently
not
integrated
with
Zipkin
and
other
tools
like
that.
A
B
Know
actually,
there
is
no
there's
no
specific
integration
required,
as
it
is
apps
which
daemon
and
the
client
are
both
packaged
as
one
statically
linked
binary.
It
is
all
implemented
in
go
with
some
C
and
a
little
assembly
parts,
but
ultimately
it
is
a
static,
binary
and
and
one
way
to
run
apps
which,
with
with
swarm
or
docker,
is
you
just
instead
of
running
your
application?
You
would
prefix
that
with
a
X
X
is
the
absolute
binary
command?
B
So
you
would
you
just
do
you
know
you
can
do
the
amount
of
apps
which
binary
into
the
container
and
then
run
that
binary
in
the
container
in
place
of
the
entry
point
for
the
container
and
then
pass
the
application
in
its
arguments
as
arguments
to
apps
which
so,
if
you
did
that,
then
you
basically
are
running
apps,
which
integrated
with
docker,
and
there
are
tools
you
can
make
this
change.
This
doesn't
require
change
to
darker,
or
this
doesn't
require
change
the
application.
It's
only
a
change
to
your
compose
file.
A
A
B
This
works
with
the
proxy,
so
there
is
a
built-in
proxy.
Actually,
if,
if
you,
if
you're,
not
pointing
as
switch
to
an
external
proxy
like
envoy,
there
is
a
built-in
proxy
that
actually
does
this.
So
it's
not
it's
not
particularly
distinguished
this
is
done
the
way
any
other
proxy
would
do
except
it
is
built
into
Apps,
which
comes
out
of
the
box.
B
B
A
B
Coupon,
it
is
networking,
in
fact
this
can
be
apps
which
can
be
used
as
a
networking
medium
for
odds
which
doesn't
require
privilege
which
doesn't
require
these
additional
layers
of
heat
pair
and
the
bridge,
and
things
like
that.
So
it
makes
communities
networking
more
efficient,
but
actually
kubernetes
doesn't
do
anything
special
about
l7
and
and
to
that
extent
apps
which
actually
works
fine
for
communities
and
for
l7.
Of
course
we
talk
about
that
so
for
that
it
uses
the
section
proxy.
Yes,.
A
B
We
have
done
testing
in
a
in
a
lab
kind
of
environment
with
with
as
many
as
a
couple
hundred
nodes
actually
a
couple
hundred
instances
and
in
terms
of
real
real-life
testing
with
hundreds
of
nodes
of
deployment
that
is
working,
progress
and
in
terms
of
the
breadth
of
application,
support,
we've
tested
with
all
kinds
of
applications,
almost
I
mean
we've,
never
seen
an
application
that
that
chokes
apps,
which
all
will
behave,
the
cloud
need
to
type
applications
and
also
the
legacy
old
world
applications
and
and
funny
Lee
constructed
C
binaries.
All
of
those
work,
fine.
A
B
A
B
B
A
A
B
Maps
which
supports
the
this
same
notion
of
labels
that
we
will
be
support
and
you
can
even
specify
label
selectors
to
to
enforce
the
policy.
So
when
you're
creating
a
server,
you
can
attach
some
labels
to
it,
and
then
you
can
specify
policy
based
on
those
labels
and
and
again
this.
This
needs
integration
into
kubernetes
network
policy,
but
but
the
policy
enforcement
itself.
The
enforcement
of
connectivity
can
be
done
today
with
with
the
built-in
support
for
labels
in
apps,
which
I
guess.
A
This
also
connects
to
the
next
word,
the
next
and
last
question,
which
is
does
UPS,
which
has
the
capability
to
block
services
to
be
consumed
by
only
a
set
of
consuming
services
instead,
so
is
this
the
same?
This
is
similar
or
can
up
switch
block
connections
or
allow
connections
use
specific
services
like,
as
you
said,
if
he
supports
the
same
labels
as
kubernetes,
can
also.