►
From YouTube: Take Envoy Beyond a K8s Service Mesh - to Legacy Bare Metal & VMs + More - Steve Sloka & Steven Wong
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
Take Envoy Beyond a K8s Service Mesh - to Legacy Bare Metal and VMs + More - Steve Sloka & Steven Wong, VMware
Envoy’s mission is to extract network and communication security code from applications in a way that developers and users can deploy components that just work no matter where they run or what hosts them. This session will show how to leverage Envoy to achieve interoperation of applications and services, split across Kubernetes and traditional VM or bare metal hosts. We’ll look at how to incrementally bring Kubernetes into an existing application architecture based on existing VM or bare metal applications and services. Specific examples will demonstrate: - Using Contour with Envoy as an Ingress and load balancer solution with a richer feature set than some common alternatives - Sending requests from VM workloads to Kubernetes services - Direct requests to services running on a VM from Kubernetes - Dynamical traffic steering - K8s and VM workloads at the same time
https://sched.co/Uadj
A
Sorry
little
difficult
there,
okay,
so
I'm
Steve,
Wong
I
work
for
VMware.
As
a
software
engineer,
I've
been
working
on
kubernetes
since
2015,
starting
in
the
storage
area.
I've
worked
in
the
cloud
provider
plug-in
for
running
kubernetes
on
vSphere
and
I'm,
currently
co-lead
of
the
IOT
edge
working
group
on
kubernetes.
A
So
just
a
recap:
the
micro
services
model
presents
a
lot
of
challenges.
You've
got
more
interconnects
of
more
network
nodes,
and
these
are
going
into
more
places.
On-Premises
public
clouds,
multi-cloud
edge.
These
new
models
place
app
components
much
less
deterministically
than
before,
and
these
things
are
often
very
short-lived.
A
It's
rare
to
find
an
app
developer,
who
has
great
skills
and
networking
and
security.
You
know
when
you
ask
people
to
take
on
their
jobs.
Take
on
jobs
that
are
beyond
their
skill.
Set
mistakes
will
be
made,
so
this
whole
concept
of
using
network
proxies
or
service
Mash
basically
amounts
to
helping
to
solve
this
problem
of
requiring
broad
swaths
of
expertise
to
eliminate
mistakes.
A
So
envoy
is
an
open
source
project
that
was
started
by
lyft
back
in
2016
and
I.
Its
goal
was
to
move
the
network
details
along
with
some
security
aspects
completely
out
of
the
application
and
make
the
network
transparent
to
both
app
developers
and
the
users
of
those
apps
I.
Think
the
key
aspects
of
its
architecture
are
that
it
was
completely
API
driven
and
it
supported
dynamic
configuration
that
meaning
that
you
didn't
have
to
restart
rebooted,
that
you
could
reconfigure
this
hot.
A
A
The
best
way
to
look
at
this
is
to
look
at
on
as
a
building
block
and
a
service
mash
as
a
higher-level
tier
that
configures
those
building
blocks
that
so
that
you
can
use
them.
You
know
if
this
is
a
lot
like
the
kubernetes
control
plane
could
be
viewed
as
an
Orchestrator
or
manager
of
the
lower
building
block
of
container
runtimes
and
container
images.
So
sto
is
one
example
of
a
service
mesh.
It's
perhaps
the
most
well
known
the
most
well
covered
in
conferences
like
this.
A
Its
features
fall
into
the
four
major
categories
you
see
here,
connecting
things
securing
things
controlling
operations,
both
at
the
app
deployment
level
and
at
the
network
level
and
finally,
observability,
which
involves
monitoring
things
for
things
being
healthy
or
going
wrong
and
helping
give
you
an
edge
on
troubleshooting
when
things
go,
do
do
go
wrong.
The
SEO
service
meshes
commonly
thought
of
something
that
would
support
kubernetes
workloads.
But
what
do
you
do
when
you
have
something
that
isn't
the
kubernetes
workload?
A
A
lot
of
us
have
legacy
components
whether
they
be
bare
metal
machines
or
VMs
are
those
things
just
dinosaurs
that
have
reached
the
end
of
their
life
or
is
there
something
you
can
do
about
this?
It
turns
out
that
there
are
a
couple
things.
One
thing
that
I'm
going
to
tell
you
exist,
but
not
cover
in
detail.
Now
is
something
called
sto
mesh
expansion
and
that's
a
way
to
connect
your
legacy,
Linux
machines,
whether
they
be
VMs
or
a
bare-metal,
into
an
sto
service.
A
Mesh
I
did
a
talk
on
this
at
open
source
summit
Japan
and
it
got
recorded,
but
it
was
so
detailed.
It
was
one
of
these
I
signed
up
for
the
talk.
I
got
a
one-hour
slot
and
when
I
finally
put
it
together,
it
really
needed
two
and
a
half
hours,
I'm,
not
going
to
try
to
reproduce
that
here,
but
I
took
my
slides
from
that
and
put
them
at
the
end
of
this.
A
So
when
you
download
the
pup
this
deck,
it's
already
uploaded
to
the
skate
app,
you
can
see
the
detail
on
that
so
come
back
to
that
later,
but
you
can
indeed
use
an
SEO
service
mesh
with
mesh
expansion.
To
talk
to
these.
The
only
thing
documented
at
this
time
is
doing
that
within
Google
cloud
talking
to
VMs,
hosted
within
the
Google
cloud,
but
like
I,
say,
I
gave
a
talk
on
using
it
to
connect
to
joy,
bare-metal
and
VMware
VMs
I
believe
you
could
use
it
generically.
It's
just
that
this
is
not
a
well-documented
subject.
A
Just
to
summarize.
What's
in
the
slides
hidden
in
this
deck,
the
preconditions
are
that
you
have
to
install
sto
with
mesh
expansion,
enabled
you'll
need
a
load
balancer.
If
you're
doing
this
kind
of
in
a
home,
lab
middle
elbe
will
work.
Otherwise
you
can
use
a
commercial
load
balancer
on
each
VM.
You
configure
a
cluster
dot,
E
and
V
file.
Some
key
insert
files.
You
installed
the
ISTE
o
envoy,
sidecar
debian
package.
A
You
know
sto,
actually
irv
envoy
predates
kubernetes,
so
it
actually
was
originally
deployed
as
a
package
for
Linux
I,
don't
believe,
there's
a
pre-built
distributed
package
at
rpm
if
you're
running
something
other
than
Ubuntu
or
Debian,
but
I
hear
that
you
can
find
them
out
there
somewhere.
You
verify
that
note.
Agent
works.
A
A
It's
actually
just
23
the
last
time
I
looked,
but
it
is
a
little
bit
complex,
I'm
about
to
turn
over
the
stage
here
to
Steve
who's,
going
to
show
you
an
alternate
method
that
still
uses
the
Envoy
proxy
like
if
Co
would,
but
it
both
does
it
in
a
simpler
way,
perhaps
with
a
few
less
features,
but
perhaps
with
a
few
features
that
you
can't
currently
do
with
this
deal.
So
take
it
away.
Steve,
okay,.
B
Thanks
to
you
yeah,
so
what
we're
gonna
do
is
figure
out
how
we
can
enable
things
like
a
surface
mesh
without
deploying
a
service
mesh
and
we're
gonna
use
some
tools
today
to
help
us
demonstrate
this.
One
thing
I
want
to
make
clear
is
that
the
tools
I'm
using
and
the
technologies
aren't
required
so
I'm
gonna
show
you
some
things
that
I
work
on
I'd
love
it
if
you
used
it,
but
by
no
means
you
have
to
use
those
tools.
B
Takeaway
from
this
is
the
pattern
that
we're
gonna
apply
and
then
insert
your
your
tool
and
your
proxy.
However,
you
want
to
do
that.
So
the
first
thing
is:
is
why
not
right?
Why
not
deploy
service
mesh
seems
like
everyone's
doing
that?
Well,
one
their
complex
right,
there's
a
lot
of
overhead!
That's
getting
added
to
your
cluster,
a
lot
more
resources.
They
can
make
things
difficult
to
debug
and
I'm
sure
by
the
time
the
video
comes
out
for
this.
B
While
these
problems
will
be
solved,
but
there's
a
lot
a
lot
going
on,
we
need
to
play
a
mesh.
So
what
I
want
to
do
is
look
at
using
an
ingress
controller
to
help
solve
this
problem.
So
what
you'd
look
at
using
a
contour,
so
contour
is
an
ingress
controller
for
kubernetes.
Again
it's
based
on
envoy
and
some
features
of
it
is
that
it's
dynamically
updated.
So
we
can
update
configuration
and
pass
that
down
to
to
envoy
without
losing
connections
or
reloading
configuration.
B
B
That
teams
can
self
manage
their
ingress
resources
and
not
have
the
issue
today,
where,
if
two
teams
define
the
same
path
with
the
same
prefix
you'll
get
a
production
outage
right,
we
can
solve
that
with
some
things
in
contour
and
lastly,
we
want
to
try
and
avoid
the
the
annotation
sprawl
right
so
place
things
in
the
spec
where
they
belong.
Things
like
service
weight,
full
of
balancing
strategies,
those
sort
of
things.
B
So
here's
how
OnPoint
gets
our
contours,
architected
so
you'll
see
we
have
ongoing
as
the
data
path
component.
All
traffic
routes
through
envoy
contour
is
the
ingress
Controller.
So
its
job
is
to
look
at
the
cluster
and
look
for
services
for
endpoints
secrets,
ingress
resources,
all
those
information
when
it
sees
something
change.
It
builds
a
new
configuration
and
streams
that
down
to
envoy
and
then
on
a
robot
request
in
your
cluster.
B
Well,
let's
take
this
this
kind
of
view
and
kind
of
build
it
up
a
little
bit
more
look
at
it
in
this
kind
of
view.
So
what
I
did
here
is
I
took
the
same
idea,
but
I've
introduced
this
routing
cluster
right.
So
if
we
leverage
kubernetes
I
get
horizontal
scale,
so
I
can
have
all
my
routes
or
my
traffic
in
this
rotting
cluster
be
routing
horizontally
and
then
what
I
can
do
now
is,
instead
of
just
targeting
a
single
cluster.
I
can
target
many
different
clusters.
B
Maybe
it's
a
bunch
of
different
kubernetes
clusters
or
it's
OpenStack
or
a
VM
or
even-
and
this
is
great
because
I
can
help
move
my
journey
to
kubernetes,
so
maybe
I'm
fully
a
VM
infrastructure
today.
This
gives
me
a
path
now
to
move
some
of
my
infrastructure
to
kubernetes,
but
in
a
stepwise
manner.
B
It
also
allows
me
to
route
two
endpoints
that
may
never
be
containerized
I
used
to
work
at
a
large
healthcare
organization
and
there
are
some
applications
that
just
will
never
be
containerized
or
put
in
a
kubernetes.
So
this
gives
you
a
path
to
move
your
other
apps
to
kubernetes
and
leave
those
apps
running
as
VMs
also
can
help
you
with
migrations
right.
You
want
to
move
from
cube,
115
and
116,
build
a
new
cluster
smoke
test
it
and
then
move
your
traffic
over
again
with
the
introduction
of
this
routing
cluster.
B
But
what
about
internal
quote?
Requests
right
meshes
are
great
for
this.
You
can
have
your
pods
and
your
services
talk
between
each
other,
so
I'm
going
to
look
at
a
way
that
we
can
help
introduce
this
concept
as
well
and
we're
gonna
add
another
tool
called
gimble
and
I.
Think
of
gimble
as
a
service
discovery
component
for
contour,
so
agimpels
job
is
to
go
out
and
look
for
endpoints
and
remote
clusters
right.
B
So
in
the
case
of
OpenStack,
it's
going
to
go
look
at
for
all
the
names
that
are
running
and
it's
gonna
copy
them
into
the
routing
cluster
and
it's
going
to
copy
them
and
store
them
in
that
cluster
as
services
and
endpoints,
so
leveraging
basic
kubernetes
objects
and
then
once
we
have
those
objects
in
this
routing
cluster
I
can
make
it
now
make
the
routing
decisions
against
that.
And
the
last
thing
I
want
to
say
is
that
contour
is
not
a
service
mesh.
B
So
if
you're
looking
for
a
service
mesh
looking
for
a
mutual
TLS,
this
will
not
solve
your
problem
right.
What
I'm
going
to
try
and
focus
on
here
is
to
have
you
to
enable
routing
and
having
all
your
applications
talk
together
in
a
very
simple
manner,
but
if
you
need
a
service
mesh
that
I
recommend
you're
going
to
ploy
that
and
go
down
that
road.
So
let's
go
and
demo
some
things.
So
I've
got
a
lot
of
hardware
up
here,
and
this
is
a
demo
or
overview
what
I've
gotten.
B
So
what
we
have
is
I've
got
on
my
Mac
I've
got
three
clusters
running
in
kind
kind,
is
kubernetes
and
dr..
So
if
you're
not
familiar
with
that,
it's
a
way
that
you
can
spin
up
a
kubernetes
cluster
using
only
docker,
sometimes
three
clusters
running
on
there
inside
a
Linux
VM
and
then
on
this
Intel
nook.
Here
I've
got
a
sphere.
B
A
B
C
B
Alright,
so
let's
go
ahead
and
start
by
looking
at
this
piece
for
API
right,
so
these
are
all
again
the
VMS
that
we
just
saw
on
the
last
screen.
I
have
my
two
API
VMs
here
on
my
two
web
server
VMs
and
when
you'll
notice
is
they've,
all
got
IP
addresses,
so
my
web
servers
are
running
on
Ubuntu,
VM
and
I
have
got
12
and
I
have
dot
11
right.
Those
are
the
two
IP
addresses
for
my
web
server
and
down
here.
B
What
we'll
see
is
I've
got
some
attributes
right,
so
these
attributes
are
a
way
that
we
can
define
metadata
to
our
VM
is
running
in
a
sphere
and
I've
added.
This
thing
called
an
application,
a
port
in
a
project.
So
what
gimble
does
is
gimbals
a
controller
that
runs
in
kubernetes
and
again
it
goes
out
and
it
finds
these
endpoints
and
copies
them
into
that
routing
cluster.
So
what
I
do
is
I've
got
a
mapping
now
so
the
project
maps
to
a
namespace
in
that
rotting
cluster.
So
this
is
an
example.
B
We're
gonna
have
a
marketing
team,
so
the
marketing
team
is
going
to
have
this
VM
and
it's
going
to
be
part
of
the
web
application
and
the
application
maps
to
a
service
in
kubernetes
right
now
that
I
have
a
namespace
and
a
service.
I
can
add
endpoints
and
my
end
points
come
from
the
IP
address
assigned
by
vSphere,
as
well
as
the
port
here
we've
defined
so
now
that
I
have
two
web
vm's
will
see
the
Weber
one
matches
the
same
thing
as
well
go
to
right.
A
B
So
let's
go
ahead
and
take
a
look
at
if
I
go
ahead
and
get
my
services
and
endpoints
in
the
marketing
namespace.
Well,
you
see
here
is
again
I've
got
that
mapping
now,
so
here's
that
web
service
that
we
applied
with
that
that
annotation
and
you
see
that
appended
VMR
to
it.
So
we
need
to
give
it
a
back-end
name
right:
I
could
have
multiple
clusters,
I
need
to
give
them
an
identity,
so
I've,
given
the
identity.
It's
just
called
it
VMware
right
for
this
demo.
If
I
had
another
cluster
running,
I
could
call
it.
B
B
So
now
what
we
can
do
is
let's
go
ahead
and
wire
some
things
up,
so
what
I
want
to
do
is
I
want
to
have
traffic
now
hit
my
marketing
website.
So
my
marketing
team
is
running
under
this
company
called
pixel
proxy
net
and
this
is
their
their
domain.
So
what
I'm
going
to
first
do
is
create
this
root
namespace.
So
in
contour
we
have
this
idea
of
a.
B
We
have
a
customs,
the
Rd
and
it's
called
HTTP
proxy,
and
it's
how
we're
going
to
solve
this
multi
team
multi
cluster
type
networking,
so
this
ingress
object
helps
us
again
to
find
all
these
features
we
describe
you
couldn't
do
these
things
with
ingress
today,
just
end
up
you
in
the
current
version.
So
what
we'll
do
is
we'll
have
a
route
proxy.
B
So
here
we'll
this
is
giving
us
permissions
to
the
marketing
team
and
we're
gonna,
give
it
to
this
proxy
called
default
proxy
down
here,
while
she
define
the
actual
proxy
right.
This
is
that
definition
in
the
marketing
namespace
and
what
you
see
is
that
basically
slash
for
pixel
proxy
net
is
going
to
route
to
the
VMware
web
service
and
again,
if
we
go
back
to
our
our
services
and
endpoints,
that
VMware
web
service
is
pointing
to
those
two
windows
or
two
Linux
VMs
running
my
website.
So
let's
go
ahead
and
apply
this.
B
You'll
see
I've
got
two
of
them
right:
here's
the
route
one
and
then
here's
the
who's,
the
one
that's
delegated
to.
So,
if
we
come
over
to
our
browser,
let
me
go
to
pixel.
Proxy
dotnet
will
seems
like
it.
The
requests
right.
So
this
is
hitting
web
o2
and
the
response-
and
this
isn't
very
exciting,
but
it
helps
you
understand.
Four
requests
are
going,
so
the
VM
is
responding
with
web
o2
or
web
o1.
B
So
if
we
go
ahead
here
and
do
it
and
do
a
curl
we'll
just
curl
it,
every
half
second
and
you'll,
see
it
better.
So
you'll
see
whether
one
and
web
Oh
to
respond
and
kind
of
half
and
half
right,
it's
getting
half
and
half
traffic.
So
now
we
basically
wired
up
our
VMs
to
get
production
traffic
through
this
rotting
cluster.
B
So
next
what
I
want
to
do
is
go
ahead
and
deploy
a
blog
and
in
our
case
the
blog
is
running
under
a
Windows
server.
So
down
here
back
in
view,
cedar
I've
got
this
Windows
box
and
again
it's
running
Windows,
Server
2019,
so
here's
that
home
screen.
So
what
we'll
do
is
we'll
go
wire
it
up,
but
they
were
going
to
give
them
a
path
for
that.
B
So
this
is
where
we'll
define
that
in
contour,
so
we'll
say
that
the
the
pixel
proxy
net
domain
gets
the
path,
slash
blog
and
for
that
path,
we're
going
to
route
to
the
VM
or
Windows
service
and
again
that
maps
to
the
service
that
gimble
went
and
discovered
for
us.
So
if
we
go
ahead
and
apply
this
one.
B
B
There
we
go
so
now
you
can
see
that
I've
got
requests
hitting
this
again,
hitting
this
routing
cluster
and
now
going
to
all
my
VMware
infrastructure
or
my
virtualized
infrastructure.
So
now
let's
go
ahead
and
move
that
infrastructure.
Let's
containerize
our
front-end
web
application.
So
this
one
here
so
we'll
move
this
one
now
from
our
virtual
eyes
of
the
ms2
to
containers.
B
So
what
we'll
do
is
we'll
first
go
ahead
and
we'll
deploy
a
service
right
and
I
have
I'm,
cheating
and
I
have
a
make
file,
so
I
can
say,
deploy
blue
and
what
this
is
gonna
do.
Is
it's
gonna
go
deploy
that
front-end
web
application
into
my
blue
cluster
right
so
again,
I
have
three
clusters:
I
have
my
routing
cluster
and
then
my
two
children
clusters.
So
now
my
blue
cluster
has
that
application
deployed.
B
So
if
we
go
ahead
and
get
our
services
and
endpoints
again
we'll
see
now
we
have
this
blue
service
that
came
through
again
I've
labeled,
that
back
in
blue
cluster
as
blue
and
it's
called
web.
So
now,
I
have
this
blue
web
and
I.
Have
these
three
endpoints,
because
I
have
three
replicas
of
three
so
now
what
I
can
do
is
we
can
go
wire
that
up?
So
what
we'll
do
is
we'll
do
a
canary
deployment.
So
this
is
what
this
will
look
like.
So
an
HTTP
proxy.
B
We
can
define
multiple
up
streams,
so
we
can
have
our
current
service,
which
is
the
VMware
web
again
X
living
on
the
the
VM
infrastructure
and
now
we'll
route
to
the
blue
service,
which
is
in
the
kubernetes
infrastructure
and
we'll
add
a
weight
to
this,
so
what
a
weight
of
92
the
VM
in
a
weight
of
10
to
the
kubernetes
one.
So
after
we
get
this,
we
can.
We
can
see
how
this
gets
routed
around
cool.
So
let's
just
deal
with
what
the
wild
live
here.
So
now
we
should
get.
B
We
should
get
mostly
the
web
of
wine
and
web
o2
and
every
now
and
again
we'll
get
the
blue
cluster
replying
and
there's
a
blue
cluster
flowing
through.
If
you
can
catch
that,
because
we
have
most
of
the
weight
hitting
the
VM
infrastructure.
So
let's
go
ahead
and
we'll
swap
the
flip-flop
those
weights
so
we'll
give
10
10
to
the
VM
and
90
to
the
kubernetes
1,
and
this
is
now
gonna
reverse
or
add
more
infrastructure
routing
to
our
our
kubernetes
infrastructure
right.
B
So
we
can
watch
our
logs
watch
a
metrics
see
how
it's
handled
once
we're
happy
with
it
see
the
blue
cluster
is
getting
most
of
the
traffic
and
then
the
web's
ones
getting
a
little
bit
once
we're
happy
with
that.
We
can
come
through
and
just
take
away
all
traffic
to
the
Yammer
one,
and
now
we've
successfully
moved
our
infrastructure
to
kubernetes
alright.
So
the
next
thing
you
want
to
do
is
move
our
API
right.
B
So
this
application,
when
we
access
it,
it's
not
hitting
an
API
at
the
bottom,
but
we
can
have
it
do
that.
So
what
I'm
gonna
do
is
go
ahead
and
create
an
internal
proxy.
So
up
until
now,
we've
solved
the
basic
ingress
resource.
You
know
solution.
We
have
this
public
request
hitting
the
front-end
application.
The
first
step.
Well
now,
I'm
gonna
go
deal
with
the
second
step,
and
this
is
where
mesh
is
kind
of
can
can
shine
and
do
full
things.
But
what
I
have
now
is
I
can
add.
B
A
dot
contour
domain
inside
my
cluster
and
I
can
do
is
create
routes
now,
like
I,
did
with
my
ingress
resource,
but
now
for
internal
requests.
So
what
this
is
going
to
do
is
it's
going
to
create
another
ingress
resource
and
this
URL
is
going
to
hit
this
VMware
API
again.
This
is
the
API
running
in
my
VM
infrastructure,
so
we're
gonna
have
our
containerized
cubed
is
one.
We
just
moved
access
this
VM
infrastructure
living
over
in
BMR.
So
let's
go
ahead
and
apply
this
one.
B
This
is
4k,
alright
cool
and
then
let's
go
look
at
our
proxies
again,
so
you
know:
I
have
this
extra
one,
this
API
top
marketing
that
contour,
so
what
I
have
to
do
next
is
I.
Have
to
go
tell
my
blue
service
to
go
use
that
so
here
I
can
pass
it
in
through
an
environment
variable,
so
semi
rate
variable
tells
tells
that
application
hey.
This
is
where
your
API
lives.
So
let's
go
ahead
and
switch
context
to
my
blue
cluster.
You
can
see
that
down
here
with
the
blue
and
I
will
apply.
B
On
our
quads,
you
can
see
those
are
rolling
out.
We
did
a
roll
out,
I
didn't
get
fast
stuff.
We
see
there
10
seconds
old.
So
now
what
should
happen
is
when
I
make
a
request
to
this
application.
The
kubernetes
infrastructure
running
in
the
blue
cluster
is
going
to
make
a
call
to
the
API
is
running
in
the
Emer
and
there
it
is
so
you
can
see
down
here
the
API
Oh
right.
You
see
it
hitting
API.
Oh
one
API
OSU
and
that's
the
spot
down
here.
B
So
the
second
half
is
the
web
server,
making
a
request
to
the
API.
So
now,
let's
go
ahead
and
move
that
infrastructure
over
like
we
did
for
the
web
app,
so
we'll
go
ahead
and
deploy
the
same
API
as
a
as
a
containers
running
in
kubernetes.
So,
while
I'm
still
in
the
blue
cluster,
we
can
apply
this
Oh
five
and
we'll
get
our
paws.
You
see
those
were
spinning
up
now.
There's
my
api
pod,
spinning
up.
B
Alright,
let's
go
back
to
here
and
let's
go
and
you
look
at
our
endpoints
and
we'll
see.
Now
we
have
a
blue
endpoint
from
Gibble's,
so
gimbal
one
discovered
that
endpoint
and
added
that
api
server
into
there.
So
now
we
have
that
we
can
go
and
update
our
applications
so
we'll
just
change
our
our
internal
proxy
instead
of
porting
to
the
VM,
our
infrastructure.
B
B
Now,
I'm
in
the
cluster:
that's
why
okay!
So
now,
if
we
go
ahead
and
do
that
curl,
let's
do
it
from
here
we'll
see
if
I
get
the
blue
API.
So
now
it's
hitting
the
containerized
infrastructure.
So
now
I've
successfully
moved
my
web
application
from
my
VMs
and
my
API
for
my
VMs
now
last
thing
we
want
to
do
just
for
fun.
We
will
go
ahead
and
talk
to
bare
metal
and
that's
my
raspberry
pi
sitting
there
I
don't
have
a
discover
and
gimbal
to
do
this.
B
Cuz,
there's
not
really
a
good
API
for
bare
metal.
We
probably
figure
something
out,
but
for
today,
we'll
just
create
basically
another
service
in
the
endpoint.
So
this
is
going
to
create
a
generic
service
for
me
called
bare
metal,
and
we
have
one
endpoint
here
which
points
to
by
an
IP
of
that
put
that
raspberry
pi.
So
if
I
go
ahead
and
apply
those
six,
if
we
look
at
our
services
again,
we'll
see
now
I
have
this
bare
metal
service
and
it
has
an
IP
address
of
dot
50.
B
B
Again,
this
isn't
gonna
solve
your
service
mesh
problem,
but
you
can
see
how
now
we
can
have
interrupted
interoperability
between
all
these
different
endpoints
living
across
my
cluster,
and
hopefully
this
helps
you
work
to
a
to
a
better
spot,
so
I
think
Steve
now
is
gonna
help
us
move
on
from
the
end.
Ok,.
A
So
where
do
you
go
to
learn
more
that
we've
been
talking
about
contour
gimble
they're,
both
open
source
projects?
The
contour
project
has
regular
working
group
meetings
it's
at
on
the
third
Tuesday
of
each
month.
It
turns
out
that
would
turn
out
to
be
today
so
because
we've
got
cube
con
going
on
we're
not
going
to
have
the
one
today
but
catch-up
on
the
next
cycle.
So
part
of
me.
D
A
We're
going
to
get
to
that
so
go
to
this
site
project
contoured
IO,
to
learn
more.
If
you
want
to
see
what,
if
you've
missed
all
the
meetings
before
they
got
recorded,
the
notes
and
agendas
are
recorded
and
the
portal
is
at
that
site.
I,
don't
know
if
we
have
very
much
time
for
questions,
but
it's
fortuitous
that
we
have
an
event
occurring
during
lunch.
Called
contour
meet
the
maintainer
z'.
D
A
Map
is
up
there,
so
this
is
in
hall
c
lunches
in
three
different
places,
but
we're
specifically
going
to
be
in
all
c
and
there
will
be
contour
signs
on
sticks
to
direct
you
to
the
area
where
the
contour
maintainer
z'
are
open
to
discussions
and
questions.
So
please,
come
by,
like
I
said,
there's
far
more
material
in
this
deck.
A
That
was
hidden
during
presentation,
but
you
know
we
simply
didn't
have
time
for
it,
but
this
deck
is
already
on
the
sched
site,
so
go
ahead
and
download
it,
and
you
can
learn
a
little
bit
more
from
there.
I
think
we
do
have
a
few
minutes
for
questions
5.
Ok,
so
if
anybody's
got
any
raise
your
hand
and
I
think
somebody
will
bring
you
a
microphone.
A
E
E
A
B
So
they're
gonna
be
night
and
day
so
so
SDO
has
you
know
psyched
re-injected
everywhere.
There's
lots
of
other
components
that
have
to
run
and
make
it
steel
work.
Contour
is
literally
like
one
controller
which
is
contour
and
then
a
set
of
envoys
to
handle
your
load
and
traffic,
so
they're
gonna,
be
its
contour
is
gonna.
Give
you
a
much
smaller
footprint
and
much
simpler
design
to
implement
what
I
just
kind
of
showed
you.
B
But
again
we
can't
compete
with
some
of
the
things
that
this
do
can
give
you
like
the
mutual
TLS
and
those
sort
of
things.
So
it
comes
down
to
you
know
what
what
do
you
need
out
of
out
of
your
your
your
network
requests?
You
need
the
things
that
I
match
gives
you,
then
I
may
have
to
bite
the
bullet
and
deploy
those
those
matches.
But
if
you
don't
need
that,
you
want
the
routing
and
I
think
this
will
be
a
great
alternative
to
investigate.
B
Have
anything
that
we
could
reference?
That's
the
interesting
yeah
I
know.
I
know
we
built
a
lot
of
this.
We
took
legacy
very
seriously,
so
we
we
don't
add
any
more
than
20
milliseconds
of
latency
to
your
upstream,
but
I
don't
have
any
comparisons
or
any
kind
of
metrics.
A
lot
of
it
comes
down
to
your
network
in
your
your
infrastructure.
So
it's
difficult
to
to
manage
some
of
those
numbers.
20.
B
F
F
B
Yeah
so
envoy
has
a
whole
suite
of
metrics
that
you
can
get
and
we
have
example
dashboards
in
Prometheus,
so
I
should
have
good
demo
that,
but
we
have,
if
you
deploy
all
the
metrics
and
Envoy
it,
because
everything
is
routing
through
that
routing
cluster
I'd
see
metrics
on
every
single,
every
single
hop
that
went
around
so
for
requests
from
the
front
end
to
your
application
and
from
your
application
to
the
back
end.
It
went
through
that
envoy
then
yeah
that
I
could
give
you
all
the
metrics
you
plan
on,
seeing
that
yes,.