►
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
Deep Dive: Telepresence - Adnan Abdulhussein, Bitnami & Rafael Schloming, Datawire
One of the challenges facing Telepresence is growing the contributor community. It’s a complex application that requires a good understanding of OS networking, VPNs, Kubernetes, and everything in between. We’ll kick off this meeting with a general architectural overview of Telepresence. We’ll talk about how we’ve managed the project to date, and our investments to make it easier. We want to then turn it over for an interactive discussion with participants to see what we can do to make it easier to contribute and grow the Telepresence community.
To learn more: https://sched.co/GrdI
A
Welcome
to
the
telepresence
deep-dive
session,
my
name
is
reka
Shlomi.
This
is
Luke
shoemaker.
We
both
work
at
data
wire
and
data
wire.
If
you
haven't
heard
of
us,
we
make
both.
We
make
ambassador
an
API
gateway
built
on
top
of
Envoy
and
we
make
telepresence
as
well.
So
we
are
a
group
of
brave
individuals,
who've
decided
to
build
a
company
that
builds
developer
tooling,
so
it's
a
fun
job
scary
at
times,
but
this
is
some
of
the
stuff
we
get
to
work
on.
A
A
Okay,
some
future
roadmap,
stuff
and
I'd
feel
a
little
bit
of
a
demo
at
the
end,
and
then
we
should
have
some
time
for
questions
as
well.
So
I'm
gonna
cheat
a
little
bit
here
and
make
this
dive
a
lot
deeper
by
starting
at
a
very
high
level.
So,
what's
the
goal
of
telepresence?
Well,
it's
its
goal
is
to
give
fast
high-quality
feedback
to
developers,
and
this
distinguishes
it
in
almost
no
way
from
any
other
tooling
related
to
software.
We
have
lots
of
tools
for
this
kind
of
thing.
A
A
You
know
it's
like
a
crystal
ball
that
that
is
trying
to
answer
the
question
of
what
would
the
world
be
like
if
I
press
that
big
shiny
red
deploy
button
right
now-
and
this
is
still
actually
a
very
broad
goal,
because
this
is
a
big
part
of
our
job
as
developers,
there
are
thousand
tons
of
dev
tools
and
techniques
for
doing
this,
everything
from
IDs
to
integration,
test,
Suites
and
figuring
out
the
right
set
of
tools
to
use
and
keeping
them.
You
know
in
a
given
problem
domain,
keeping
them
all
up
to
date
and
everything.
A
That's
you
know,
that's
what
we
do
as
developers
and
when
we
get
it
right.
It's
actually
pretty
awesome,
like
I,
sincerely
hope
everyone
has
had
the
opportunity
to
work
on
an
interesting
project
that
gets
this
sort
of
thing.
The
thickest,
the
sort
of
thing
right,
because
when
it's,
when
it's
done
right,
it's
a
pleasure
to
develop
one,
but
it's
also
one
of
the
things.
That's
sort
of
really
easy
to
neglect
or
just
get
plain
wrong,
and
sadly
I'm
pretty
sure.
We've
all
experienced
that
as
well
so
and
with
cloud
native
development.
A
This
is
actually
getting
harder
and
harder,
because
what
you're
working
on
is
distributed
at
many
levels,
the
code
itself
is
distributed
across
a
bunch
of
different
repos,
probably
written
in
different
languages,
maintained
by
different
teams,
probably
runs
on
different
networks
and
all
your
services
probably
have
different
sets
of
external
cloud
vendor
dependencies
and
so
and
so
with
cloud
native
systems.
You
end
up
with
this
very
unpleasant
choice.
A
A
A
A
A
We
have
a
strategy
for
each
of
these
goals
so
to
keep
it
fast,
we
run
the
code
locally,
so
you
can
use
all
of
your
favorite
tools
to
keep
it
realistic.
We
we
wired
that
code
into
a
remote
cluster,
so
it's
actually
interacting
with
all
of
its
real
dependencies
in
real
environment,
to
keep
it
Rock
proof.
A
So,
let's
take
a
closer
look
at
how
this
works
so
on
the
right.
You
have
your
code
in
kubernetes
and,
as
you
can
see,
it's
a
very
rich
environment
and
it
gets
richer
all
the
time,
so
your
code
might
be
running
in
a
pod
and
the
container
might
have
a
bunch
of
secrets
mapped
into
it.
The
that
container
might
also
have
a
bunch
of
persistent
volumes
or
volumes
on
any
kind,
mapped
into
mapped
into
the
container
file
system.
A
Maybe
some
of
those
dependencies
will
actually
call
back
into
your
code,
either
directly
or
indirectly
through
other
services,
and
you
know
this
I'm
sure
it
feels
dirty.
But
you
know
what
happens,
and
you
know
the
if
you're
using
single
sign-on,
some
kind
of
oh
I,
DC
or
whatever.
What's
that?
What's
the
other
acronym
I
forget
it?
But
then
you
know
you're
kind
of
stuck
with
this
on
day,
one
day,
one,
no
matter
how
how
small
your
app
might
be
so
on
the
left.
A
You
have
your
code
running
on
your
laptop,
which
also
has
a
rich
set
of
useful
things
like
a
keyboard,
but
it
doesn't
have
all
the
stuff
on
the
right.
So
this
is
a
problem.
We
need
to
solve
this
problem
and
in
order
to
solve
that
problem,
we
actually
what
telepresence
does?
Is
it
actually,
when
you
swap
the
deployment
or
when
you
run
telepresence
with
the
swap
deployment
argument,
we
actually
replace
your
container
with
the
telepresence
proxy
and
that
proxy
then
working
in
cooperation
with
the
telepresence
client.
A
A
A
A
We
we
actually
pretty
much
need
to
hijack
DNS
and
IP
in
order
to
capture
traffic
or
capture
traffic
from
your
code
back
and
direct
it
back
into
the
cluster,
and
we
do
this-
the
firewalls
iptables
on
Linux
PF
on
the
Mac
and
this.
Actually
we
do
this
via
a
something
called
Isis,
a
struggle
you
might
have
heard
of
that
and
I'm
gonna
talk
get
into
that
a
little
more
later,
but
and
then
we
use
we
use
intercepting
of
DNS
and
IP
to
direct
the
right
traffic
back
into
the
cluster.
A
There's
another
option
here
you
can
also
try
to.
It
also
has
a
strategy
where
it
tries
to
use
all
the
pre
log.
We
don't
like
to
talk
about
this
a
lot
because
it's
increasingly
impractical,
LD,
preload,
intercepts
see
library,
call
or
is
a
way
to
intercept,
see
library
calls
see
library's
change
over
time,
so
it's
brittle
and
more
and
more
things
are
statically
linked
these
days.
So
we
tend
to
try
and
avoid
that.
A
So
that's
pretty
much
the
picture,
it's
it's
kind
of
a
complicated
one.
If
if
you
start
here,
but
if
you
build
it
up
slowly,
it's
it's
fairly
straightforward,
and
so
you
now
kind
of
understand
how
telepresence
work.
It's
basically
a
really
really
long
extension
cord,
that's
pieces,
that's
pieced,
together
with
a
lot
of
adapters
and
when
it
works,
it's
actually
pretty
awesome,
and
on
that
ominous
note,
I'm
gonna
switch
gears
for
a
little
bit
here
and
talk
about
what
you
can
use
it
for
when
it
actually
works
so
use
cases
that
telepresence
excels
at.
A
So
one
way
to
avoid
the
hard
choices
I
talked
about
the
beginning
is
just
to
not
develop
locally,
actually
run
everything
in
a
terminal
section
or
a
remote
desktop.
This
is
kind
of
the
same
idea
as
telepresence
just
plug
in
that
complicated
extension
cord
into
your
keyboard
and
monitor
instead
of
into
the
OS
level
abstractions
that
we're
working
with
and
doing
this
often
involves
giving
up
or
avoiding
some
heavier-weight
tools
that
you
might
be
more
inclined
to
use
locally.
So
one
of
the
early
use
cases
for
telepresence
was
developing.
A
You
know
we
those
tools
with
your
ID
and
your
debugger.
It's
pretty
easy
to
understand,
pretty
easy
to
explain.
So
you
know
one
of
these
things
about
telepresence
is
it's
kind
of
a
newish
animal?
A
lot
of
the
problems
you
run
into
in
tech.
You
can
just
sort
of
you,
you
Google
you
kind
of
find
some
some
solutions
and
it's
it's
sort
of
things
get
popular
really
quickly.
It's
easy
telepresence
is,
you
know
it's
kind
of
like
a
microwave,
a
little
bit
right.
It
lets
you
do
some
things.
A
You
didn't
necessarily
think
about
being
able
to
do
right
off
the
bat,
so
this
is
extra
popular
too,
with
Java
developers
they
like
they
like
their
IDs
and
so
there's
a
couple
of
tutorials
on
the
telepresence
website.
You
can
check
out-
and
you
know
we're
always
interested
in
contributions
on
the
documentation,
front
or
integration
front.
If
anyone
has
experience
with
doing
anything,
any
of
these
kind
of
things
we'd
be
happy
to
update
the
documentation
or
or
get
get
more,
even
get
more
write.
More
sort
of
direct
integrations
contributed.
A
So
the
other
another
use
case
is
full
stack
development.
Sorry
I,
don't
have
a
prettier
diagram
for
this,
but
if
you're,
if
you're
hacking
on
a
single
page
app
that
has
server-side
logic
that
sits
behind
an
API
gateway,
you
know
kind
of
like
most
JavaScript
hackers,
you're,
probably
so,
used
to
live
file.
Reload
at
the
moment,
you
have
to
wait
for
a
compile
cycle.
A
You
reflexively
reach
for
a
gulp
of
caffeine
and
next
thing
you
know
you're
kind
of
way
over
caffeinated
and
maybe
you
start
frantically
pushing
bugs
into
production
and
disaster
ensues
and
so
telepresence.
You
can
actually
swap
out
that
note
j/s
app
and
get
simultaneous
live
reload
across
the
front
end
and
back
end
now,
just
to
be
clear.
Some
of
the
details
of
this
might
be
imagined,
but
this
is
actually
a
real
use
case.
A
A
Use
case
for
automated
testing
with
CI,
so
telepresence,
you
can
use
it
inside
your
CI
system
so
that
your
tests
can
actually
directly
use
remote
dependencies
it
it
it's
actually
pretty
handy
in
a
bunch
of
ways
there.
It
ensures
your
your
sort
of
integration
testing
and
your
local
dev
environments
are
in
much
closer
parity
and
it
avoids
having
to
sort
of
overuse
mocks
the
the
the
falling
into
that
and
not
not
to
say
anything
bad
about
mocks,
they're,
they're,
they're
good
for
their.
A
They
have
good
uses,
but
using
them
as
a
substitute
for
integration
testing
is,
is
not
a
great
use,
and
so
this
is
something
you
can
do
really
nicely.
You
can,
you
know,
run
any.
You
can
run
any
code
under
travela
presence,
so
you
can
run
you
know
using
your
favorite
unit
test
framework,
but
have
access
to
all
your
remote
dependencies
use
case
five
I'm
going
to
talk
about
this
one
in
a
little
more
specifics
because
it
is
familiar
to
me.
We
actually
use
it
internally
for
developing
and
testing
Ambassador,
but
I'm
pretty
sure
this.
A
All
this
stuff
we
do
would
apply
pretty
well
to
any
developing
any
coronaries
extension
so
ambassador,
as
I've
mentioned
before
it's
an
API
gateway,
it's
built
on
Allah
by
proxy.
It's
integrated
pretty
deeply
with
kubernetes.
You
can
figure
it
the
annotations
on
services.
That
means
it
needs
to
watch
watch
for
updates
to
services.
It
needs
to
be
able
to
talk
to
services
and
these
people
access
sort
of
communities
metadata
all
that
stuff,
and
so
you
know
it's
also
an
API
gateway
right.
A
It
expects
to
run
in
a
cluster,
but
we
actually
develop
it
on
our
laptops
and
we
just
telepresence
to
do
this
and
when
it
runs
on
our
laptop
under
telepresence,
it
actually
behaves
just
like
it's
in
the
cluster
and
it's
pretty
nice,
because
we
can.
We
can
have
lots
of
services
of
different
kinds
deployed
and
in
the
thermal
cluster
we
can
be
hacking
on.
We
can
be
hacking
on
an
ambassador.
We
can
run
our
tests
against
it
and
we
can
actually,
you
know
when
you're
testing
a
proxy
or
an
API
gateway.
A
A
A
A
It
always
does
all
of
these
things
at
the
same
time,
and
we
think
it
could
be
very
interesting
if
these
things
were
broken
down
into
more
of
a
toolkit.
So
telepresence
is
actually
a
bit
of
a
mini
monolith.
You
might
wonder
what
exactly
that
is.
Well,
that's
when
you
well,
you
get
when
you
take
very,
very
dense
code
and
have
it
also
be
tightly
coupled
with
itself,
it's
kind
of
like
a
I
guess,
a
neutron
star,
maybe
a
lot
of
black
holes,
something
like
that,
so
the
implementation
is
monolithic.
A
We've
actually
started
to
decomposing
some
of
the
implementations
so
that
we
can
actually
build
a
better
UX,
starting
with
the
outbound
element
of
what
it
is
proxying.
So
if
we
take
a
look
at
this
picture,
these
are
some
of
the
updates.
We're
working
on
I
would
actually
do
much
of
the
work
for
this
already
we
built
the
replacement
for
s,
shuttle
called
tell
approxi.
It
builds
on
the
same
iptables,
PF
abstractions,
but
it's
kind
of
a
more
of
a
domain-specific
version,
and
that
gives
us
a
lot
more
control.
A
So,
instead
of
just
proxying
and
existing
into
an
existing
dns,
it
actually
includes
its
own
dns
implementation,
which
can
bridge
to
multiple
different
discovery
sources
and
even
override
routing
behavior
on
a
per
name
basis,
and
we've
also
started
looking
at
a
sidecar
model
for
the
in
cluster
proxy,
rather
than
just
evicting
your
deployed
code
entirely,
and
so
this
actually
gives
these
changes.
You
can
actually
give
us
quite
a
bit
of
possibilities
going
forward,
and
what
might
we
actually
do
with
those
possibilities
to
help
users?
Well,
so
for
one
thing
we
can
make
telepresence
multi-user
friendly.
A
One
thing
you
may
be
aware
of
is
that
when
you
deployment
it's
kind
of
global
right,
only
one
person
can
swap
a
deployment
at
a
time,
and
so
you
can
work
around
this.
But
it
takes
a
lot
of
work.
You
need
to
basically
build
out
the
tooling
infrastructure
whatever
to
either
create
/,
+,
/,
developer
clusters
or
have
a
you
know.
You
know,
high
of
each
developer,
have
their
own
namespace
to
be
able
to
roll
out
the
app
in
that
namespace,
and
so
with
a
sidecar
mod
we
could
avoid.
A
A
This
would
also
make
telepresence
require
less
privileges,
because
it
doesn't
need
the
ability
to
actually
rewrite
your
deployments.
If
you
know
much
of
the
setup
could
happen
ahead
of
time,
and
you
know
you
could
use
it
on
a
much
more
lockdown
environment
separating
the
inbound
outbound
means
you
could
you
know
pipe
inbound
and
outbound
to
or
from
different
clusters.
This
might
be
interesting
because
you
could
potentially
do
something
like
shadow
or
dynamically
route,
requests
from
a
production
environment,
our
production
cluster
and
then
send
the
output
from
your
dev
code
into
a
staging
environment.
A
A
A
A
This
is
something
that's
possible,
I'm,
not
sure
it's
useful,
but
you
could
do
something
like
Union
clusters,
where
you,
you
know
kind
of
like
a
union
file
system,
but
with
kubernetes
clusters.
You
know
you
take
the
services
running
in
a
they.
Take
the
services
running
into
clusters
and
sort
of
run
your
code
against
an
arbitrary
combination
of
those
of
those
those
clusters.
A
So
those
are
some
things:
I'd
love
to
hear
feedback
on
whether
people
think
some
of
those
things
might
be
useful
because
you
know
a
lot
of
stuff
there
to
build.
I
only
want
to
build
what
people
might
actually
want
to
use,
but
those
are
some
of
the
things
we'd
like
to
sort
of
there
is
we'd
like
to
be
able
to
explore,
but
there's
actually
one
more
important
thing.
We'd
like
to
do
with
this
decomposition,
and
so
it
turns
out
adapters
and
extension,
cords
are
actually
kind
of
brittle
and
to
make
it
worse
when
they
break.
A
It's
not
super
obvious.
Why
you
often
end
up
in
one
of
those
not
sure
whether
to
call
a
plumber
or
electrician
places,
and
with
this
decomposition
we
actually
hope
to
make
it
more
self
diagnosing
when
something's
wrong
yeah.
We
hope
that
will
also
enable
some
common
use
cases,
even
when
some
of
the
more
advanced
ones
might
not
be
available.
So
what's
the
holdup
to
actually
getting
access
to
all
this
good
stuff?
A
Well,
telepresence
is
very
environmentally
sensitive
on
the
server
you've
got
different
flavors
of
kubernetes
different
kubernetes
deployment
options
and,
if
that's
not
bad
enough
on
the
client,
you've
got
Linux
vs..
Mac
you've
got
IP
tables
versus
PF.
You've
got
different
dns
configurations
both
on
the
laptop
itself
and
in
the
network,
the
laptop
to
live
in
and
laptops
move
around
too.
Sadly.
A
A
You
know,
I
think
we
changed
it
to
resolve
it
to
a
specific
IP
or
something
like
that,
but
hang
a
sec
right
soon,
as
we
did
that
we
learned
that
max
actually
actually
started
not
as
soon
as
we
did
that.
Some
time
later,
after
that,
we
learned
that
max,
actually
cached
negative
domain
queries.
This
is
very
surprising
to
somebody.
Well,
I
think
it's
very
surprised.
It
would
be
very
surprising
to
anyone,
but
very
surprising,
to
somebody
coming
from
Linux.
A
I
have
no
idea
why,
but
they
do
this,
so
if
it
doesn't
resolve,
if
a
DNS
name
doesn't
resolve
the
first
time,
you
query
it:
it's
not
going
to
resolve
well
for
a
long
time,
at
least
from
telepresence
perspective,
so
you
need
to
flush
this
cache
and
well.
How
do
you
flush
this
cache?
It's
funny
you
should
ask,
there's
actually
and
I'm,
not
sure,
let's
see
if
I
can
show
you
this.
A
A
Yeah,
so
FAC
is
great.
This
I
love
this
repo.
It
is
super
useful.
It's
not
was
it's
not
easy
to
find,
but
but
if
you
dig
into
the
right
places
and
run
to
this
problem,
you'll
see-
and
if
you
take
a
look
at
that,
if
ladder
you
can
see
that
that
the
way
you
actually
flush
the
cache
the
DNS
cache,
the
Mac
has
jumps
back
and
forth
between
different,
like
even
like
patch
versions,
and
you
know,
there's
that,
like
nice,
happy
little
shrug
at
the
bottom
of
that
else
to
inspire
confidence
there.
So.
A
And
you
know,
because
there
isn't
an
obvious
way
to
write
a
test
for
this.
We
didn't
really
we.
You
know
we
have
a
whole
lot
of
code
that
is
sort
of
has
this
kind
of
knowledge
baked
into
it,
and
we
don't
want
to
change
up
that
code,
because
that
codes
running
it's
working
for
a
lot
of
people,
a
lot
of
people
use
it.
We
have
a
lot
of
users,
we
don't
want
to
well
and
that
well,
unfortunately,
that
means
to
get
from
here
to
the
grand
future.
A
There's
gonna
have
to
be
some
disruption,
and
we
don't
want
to
go
through
that
disruption
if
we
don't
have
a
good
way
to
write
tests
when
people
do
run
into
bugs.
So
that
really
is
the
problem
that
Luke
here
is
going
to
talk
about,
because
before
we
actually
roll
out
this
thing
roll
out
some
of
this
grand
new
future
stuff,
we
want
to
make
sure
we
have
a
way
to
do
it
to
do
that.
A
B
That's
been
configured
in
a
very
specific
way,
so
this
is
what
that
looks
like
this
is
an
actual
report
generated
by
telepresence
CI
on
each
row
is
a
is
one
of
our
unit
tests
and
each
column
here
is
a
different
environment
that
we've
configured
it
to
run.
The
tests
in
the
in
this
shot
is
a
fedora,
a
Debian
and
a
Arch
Linux
setup
that
are
all
set
up
a
little
bit
differently.
B
Well,
test
bench
contains
a
fork
of
something
called
make
OSI,
which
is
make
operating
system
image
and
from
that
we've
inherited
this
kind
of
neat
ini,
ish
format
for
specifying
how
to
set
up
these
operating
systems.
But
unfortunately
we
have
to
augment
that
with
some
shell
scripts.
Then
you
have
to
keep
these
things
in
sync
and
then,
as
you
add,
more
environments
you
have
into.
B
B
Ideal
format
even
looks
like,
yet
we
don't
know
which
things
we
want
to
be
able
to
toggle
freely,
because
you
know
when
we
find
out
a
new
bug,
it's
probably
because
it's
and
change
that
we
didn't
think
it
could
change
and
but
then,
on
the
same
token,
we
don't
know
which
things
aren't
going
to
change.
We
probably
don't
need
to
be
writing
that
with
network
equals
yes
line
every
single
time,
and
so
there's
a
lot
of
inspiration
of
places.
We
could
look
for
what
does
our
ideal
telepresence
developer?
B
Experience
look
like
here,
you
know
maybe
still
mostly
looks
like
make.
Os
I
just
tweaked
a
little
bit.
Maybe
it
looks
like
parabolas
OS
I
make.
Maybe
it
looks
like
docker
file
because
working
with
kubernetes
we're
all
very
familiar
with
that,
and
just
there's
some
comfort
there
or
maybe
you
end
up
going
super
parameterised
and
end
up
making
a
travesty
I's
matrix
feature.
B
A
B
On
their
machines,
although
that
should
be
happening
fairly
soon,
but
also,
we
have
really
three
layers
that
come
into
the
environment,
the
local
environment,
your
network
and
then
your
remote
cluster
and
right
now,
telepresence
is
only
our
test.
Bench
is
only
trying
to
capture
that
local
bit,
whereas
raphe
was
talking
about
the
higher
bits
very
much
matter
to
you
know
if
you're
in
that
coffee
shop,
where
DNS
acts
funny,
we
need
to
capture
that
and
how
we
configure
the
network,
and
so
that's
a
a
major
thing
that
we
need
out
of
test
bench.
B
We
need
to
grow
Cooper
not
to
enable
us
to
test
telepresence
more
robustly,
so
these
are
all
very
exciting
things
that
we
are
going
to
be
working
on
in
the
future
and
it's
going
to
be
a
lot
of
work
and
it's
going
to
require
a
lot
of
community
contribution.
If
we
want
to
get
this
done
in
a
reasonable
timeline.
A
A
Alright
and
I
guess
I
am
on
the
network
because
I
just
used
it
to
show
that
github
URL,
so
I'm
gonna
run
the
tell
epoxy
component
here-
and
this
is
the
this-
is
the
component
responsible
for
that
outbound
portion
of
what
telepresence
is
doing,
and
this
is
you
know
it's
responsible
for
basically
capturing
the
traffic
that
leaves
your
laptop
and
making
sure
it
goes
to
the
right
place.
Normally,
that
would
be
a
kubernetes
cluster,
but
it
also
happens
to
listen
to
locally
running
docker
containers
and
I.
A
A
If
I
run,
let's
all
die,
I
got
that
all
right,
the
first
time
yeah.
So
if
I
run
a
simple
HTTP
server
there
on
port
80
go
over
here,
curl
toes
you
can
see,
I
didn't
have
to
do
any
port.
Map
things,
I
didn't
have
to
remember
numbers
I
didn't
have
to
do
anything.
I
can
use
the
natural
port
port
80
on
the
left,
and
I
can
curl
right
there
from
my
shell
on
the
right,
and
this
is
actually
kind
of
Handy.
It
doesn't
even
involve
any
any
external
network
or
anything
it's
all
local.
A
A
But
we're
also
hi.
We
also
happen
to
be
connected
to
a
core
Nettie's
cluster,
and
you
know
you
can
see
a
bunch
of
services
there.
I'm
actually
gonna
see
if
I
can
flip
over
to
this.
Yes,
so
this
is
actually
the
public
thing.
That's
running
on
that
it's
it's
actually
the
demo
app
that's
running
in
our
booth
and
the
at
the
vendor
area.
A
You
can
actually
go
check
it
out
if
you
want
and
get
a
lot
more
detail,
there's
a
lot
more
stuff
there,
that's
being
demoed,
but
it's
a
single
page,
app
just
being
served
by
ambassador
and
ambassador
behind
ambassador
is
running
a
bunch
of
services
that
it
talks
to
to
get
quotes.
Those
quotes
are
getting
streamed
out
here.
A
So
that's!
What's
going
on,
you
can
see
here
we
have
the
stream
stable
service.
That's
where
the
UI
actually
talks
to
to
get
the
Croke
quotes.
We
can
Karl
Karl
stream
stable
and
get
the
plus
ourselves
we're
talking
directly
to
the
cluster
port,
forwarding
nothing.
Nothing
needed
is
kind
of
like
port
forward
on
steroids.
In
fact,
you
get
the
whole
cluster.
A
A
A
So
that's
some
of
the
some
of
the
things
it
can
do
now.
You
know
we're.
Look
we're
eager
to
get
this
sort
of
available,
it's
kind
of
available,
it's
kind
of
available.
Now
you
know
if
you're
sort
of,
if
you
want
to
be
a
brave
sort
of
new
brave
new
user,
you
can
actually
run
it
through
the
released
version
of
telepresence.
If
you
know
the
right
commands,
but
we
didn't
want
to
make
it
sort
of
default
right
out
of
the
box,
because
you
know
we
didn't
want
to
break
people.
A
So
that's
our
demo,
you
know
I,
think
the
other
big
testing
thing
for
us
is
to
give
sure
get
usability
testing
on
sort
of
where
we
take
where
we
take
sort
of
this
decompose
thing
and
so
we'd
love
to
hear
from
people
here
feedback
on
whether
on
whether
you
know
these
ideas
seem
useful,
whether
some
of
the
directions
were
going
get
people
excited
whether
they
want
to
contribute
so
join
in
our
community.
There's
a
lot
of
ways
to
get
involved.
A
You
can
learn
more
about
the
project
check
out
the
URLs
up
there.
We
have
a
slack,
so
you
can
join
the
slack
by
hitting
that
URL
follow
us
on
Twitter
and
yeah.
If
you
want
to
learn
more
about
any
of
this
stuff
for
learn
more
about
ambassador,
come
by
the
booth
to
talk
to
us
and
and
we'll
set
you
up
come.
A
Sshd,
it's
actually
kinda
it's
kind
of
arbitrary
if
I
mean
well
so
a
lot
of
a
lot
of
telepresence
sort
of
the
first
incarnates
the
Dupree
decompose
things
we've
built
from
off-the-shelf
components,
so
sht
was
just
a
handy
image
to
use
it
lets
us.
Do
the
reverse
proxying
thing
it
can
dynamically
do
stuff.
You
know
just
like
with
the
outbound
part,
where
we
kind
of
use
an
off-the-shelf
thing,
but
then
ended
up
kind
of
digging
in
and
and
using
something
more
custom.
You
know,
I
wouldn't
be
surprised.
A
We
did
that
with
the
proxy
part
as
well,
but
yeah.
Basically
it's
it's.
You
know
we,
we
run
the
port
forward.
That
gets
us
that
gets
us
into
the
cluster,
and
then
we
run
the
sshd
because
it
sshd
can
do
reverse
tunneling
out
of
the
box
and
that
that
that's
pretty
much.
Why?
But
you
know
it's
any
there
there
there
are
half
a
dozen
reverse
tunneling
solutions
that
could
work.
So,
oh,
it's
not
I
mean
the
authentication.
A
A
A
So
when
the
swap
deployment
happens,
it
replaces
the
actual
it
replaces
your
container
in
the
cluster
with
the
proxy
right
and
so
the
proxy
hears
about
anything
your
code
and
the
cluster
would
have
heard
about
so
yeah
that
we
ran.
You
know
the
it
replaces
one
of
the
ways
it
replaces
that
one
of
the
ways
it
modifies
the
deployment
slightly
is
it
reduces
it
down
to
one.
So
you
don't
have
the
multiple
the
multiple
instance
problem,
yeah
yeah,
exactly
yep
yeah,
but
you
know
looking
at
the
sidecar
option,
there's
there's
some
some
more
interesting
ways.
A
A
B
You're,
dr.
Campos,
yeah
mo
looks
mostly
like
here
kubernetes
animal,
just
slight
differences,
and
so
you've
got
that
work
of
just
keeping
them
in
sync
and
sometimes
there's
some
mismatch
with
things.
Don't
quite
work,
the
same
between
kubernetes
intraocular
compose,
and
so
that's
just
some
overhead,
that's
kind
of
silly
to
have
to
deal
with
and
telepresence
less
used
to
avoid
that
by
just
using
your
you're,
the
same
kubernetes
animal
that
you're
using
free,
actual
cluster
yeah.
A
B
A
B
A
A
It's
an
undocumented
sub
command
of
town
so,
like
it
said
this,
we
just
released
it
out
a
few
weeks
ago
and
like,
and
so
we've
done
internally
to
usability
testing
on
it.
But
we're
like
we
don't
want
to.
We
don't
want
to
make
more
options,
but
yeah
you
do
tell
presents
outbound
telepresence
space,
outbound
and,
and
you
can
play
with
it
and
you
know,
come
come
grab
us
on
slack
the
documentation.
B
A
In
you
know,
one
of
the
things
we
want
to
avoid
doing
is
making
a
monolithic
UI
with
many
options
even
more
confusing,
but
you
know
maybe
we
have
to
I,
don't
know
but
yeah.
Definitely,
if
you
play
with
it,
definitely
come
back
and
talk
to
us
and
let
us
know
what
you
you
know
what
your
experience
is
with
it.
You
know
I
I'm,
honestly
curious.
It's
worked
well
for
us.
We
use
a
mix
of
it's
worked
well
for
us
internally.
We
have
a
mix
of
Macs
and
Linux
laptops.
A
You
know
so,
but
you
know
we
probably
I,
don't
know,
have
only
five
different
network
configurations
that
it
ends
up
getting
running,
I'm
sure
they're
way
more
than
that
out
in
the
world.
So
well,
you
know
I'm
hoping
that
the
way
we
put
things
together
is
a
little
more
architectural,
robust,
and
so
maybe
it
won't
be
as
sensitive
to
network
different
network
configurations.
But
I
would
love
some
confirmation
about.