►
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
Using Ambassador to Build Cloud-Native Applications - Steve Flanders, Omnition
In Cloud-Native environments it is common to deploy one or more API gateways to route, authenticate, limit, and observe traffic. In Kubernetes, constructs such as annotations are a powerful way to configure applications. Ambassador is an open-source API gateway built on top of Lyft’s Envoy proxy which uses Kubernetes constructs to provide dynamic configuration options. In this session we will demonstrate how Ambassador can be used to migrate to or build Cloud-Native applications via different architectures and configuration approaches. Considerations for internal versus external traffic, ingestion versus queries, multi-tenant environments and non-provided services will be covered. You will leave with an understanding of how Ambassador is run in real production environments, how it is different from other API gateway solutions available today and how you can get started with Ambassador.
https://sched.co/NrlZ
A
Okay,
let's
go
ahead
and
get
started
thanks
for
attending
this
session
on
using
ambassador
to
build
cloud
native
applications,
quick
introduction
of
myself.
My
name
is
Steve
Flanders,
I'm,
head
of
product
and
experience
at
a
stealth,
startup
called
omniscient.
We
were
based
in
California
and
the
United
States
and
we're
in
the
observability
space
we
actually
leverage
the
Ambassador
API
gateway,
and
many
of
our
customers
do
as
well.
If
you're
interested
in
learning
more
about
me,
I
have
some
links
at
the
bottom.
Okay,
so
I
have
a
lot
to
cover
and
only
35
minutes.
A
I
want
to
start
with
some
quick
background
information.
Tell
you
what
ambassador
is
and
then
the
meat
of
the
presentation
will
be
about
building
cloud
native
applications
using
Ambassador
with
real
use
cases.
So
some
background
for
you.
Many
people
are
now
moving
from
a
monolithic
application
to
a
microservices
application.
They
actually
look
very
similar.
A
The
primary
difference
is
that
in
a
monolith
you
had
one
application
and
every
circle
here
basically
represented
a
different
process
or
a
thread
or
a
JVM
or,
however,
you
had
constructed
your
monolith,
whereas
in
the
microservices
world
you
remove
that
single,
isolated
container
and
you
have
every
circle
representing
a
different
service.
So
the
different
services
have
different
communication
paths,
they
may
have
errors
and
it
can
be
hard
to
route
and
troubleshoot
your
environments
in
a
microservices
worlds.
There
are
also
a
couple
of
other
changes.
A
Besides
what
the
circles
represents,
for
example,
the
front
ends
which
might
be
your
web
tier
is
often
replaced
by
an
API
gateway
and
the
micro
services
worlds,
where
you
probably
didn't
have
one
in
the
monolithic
world
and
your
web
tier
front
web
services,
those
become
other
services
downstream
from
the
API
gateway,
okay
and
then
kubernetes
I
think
we
all
know
what
kubernetes
is
I'm
not
gonna
spend
a
lot
of
time
on
this,
but
it
is
important
from
an
embassador
perspective,
because
ambassador
is
kubernetes
is
native.
It
actually
takes
advantages
of
the
constructs
that
kubernetes
provides.
A
So,
for
example,
if
you're
familiar
with
the
yam
will
syntax
ambassador
can
actually
leverage
this
syntax
in
order
to
handle
the
configuration
of
an
api
gateway.
This
makes
it
much
more
native
if
you've
already
deployed
into
kubernetes
with
that
I'd
like
to
introduce
ambassador.
So
what
is
an
ambassador
ambassador
is
an
open-source
kubernetes
native
micro
service,
API
gateway,
that's
built
on
top
of
the
Envoy
proxy
and
I
should
define
the
Envoy
proxy
as
route.
Well,
as
it
serves
a
critical
role
here.
A
It's
an
open-source
edge
and
service
proxy
designed
for
cloud
native
applications,
so
envoy
was
actually
developed
at
lyft
completely
open-source
software.
It's
used
in
API
gateways.
It's
used
in
service
meshes
that,
for
example,
sto.
It's
also
used
in
api
gateways
like
in
the
case
of
Ambassador.
The
thing
to
notice
is
that
envoy
is
a
data
plane.
It's
responsible
for
routing
and
handling
traffic
for
you,
but
it
needs
to
be
controlled.
A
Ambassador
is
the
control
plane.
It
sits
on
top
of
envoy
and
handles
the
configuration
of
envoy.
Now
the
ambassador
architecture
kind
of
looks
like
the
following.
So,
basically,
what
you
would
do
is
you
would
go
ahead
and
configure
manifests
in
kubernetes
to
basically
tell
ambassador
how
you
want
the
state
of
the
world
to
look
ambassador
would
then
get
that
information
from
the
kubernetes
api
and
it
would
transform
it
into
a
format
that
envoy
understands
and
then
it
would
tell
envoy
to
reconfigure
itself
so
that
it
could
handle
the
configuration
that
you
asked
it
to
now.
A
It
can
do
this
without
dropping
any
data.
So
even
if
you
reconfigure
Ambassador
or
in
this
case
envoy,
the
data
will
continue
routing
normally
as
it
had
before,
and
then
the
basic
flow
is
that
traffic
would
come
in
to
and
go
out
of
the
Envoy
proxy
in
your
environment.
So
what
does
ambassador
provide
it's
self-service
via
kubernetes,
annotations
and
attributes
and
constructs?
This
is
very
powerful
if
you're
running
in
kubernetes,
it's
completely
native
to
it,
you
don't
have
to
really
learn
another
syntax
or
configure
something
outside
of
kubernetes
to
take
advantage
of
Ambassador.
A
It
does
have
integrations
with
things
like
Sto
and,
besides
being
used
from
a
software
development
perspective,
it
can
be
used
by
software
developers
as
well.
So
you
can
handle
things
like
canary
deployment
and
traffic
shadowing
and
I'll
show
that
in
the
coming
slides
and
then
it
supports
most
of
the
normal
features,
you'd
expect
from
an
eight
p.I
gateway.
The
primary
focus
of
ambassador
is
around
edge
routing,
basically
sitting
on
your
perimeter
and
handling
traffic
coming
into
and
going
out
of
your
environments.
A
This
means
it
needs
to
handle
things
like
the
different
protocols
that
you
support:
HTTP
G
RPC.
It
has
to
handle
things
like
TLS
termination,
circuit,
braking
and
routing.
Some
of
these
are
similar
to
some
of
the
things
you'll
see
in
the
server
smash
world,
but
there
are
differences
as
well.
Now,
how
is
the
difference?
Api
gateways
can
basically
be
classified
into
three
different
types.
You
can
have
a
hosted
one,
so
maybe
your
cloud
provider
provides
an
api
gateway
as
a
platform
service
that
you
can
consume.
A
You
have
more
traditional
gateways
like
kong,
which
is
part
of
the
CN
CF,
and
then
you
have
layer,
7
gateways,
I'm
sure,
you've
heard
of
at
least
nginx
or
H
a
proxy
before
and
of
course,
Envoy
can
be
used
by
itself,
you're
just
responsible
for
handling
the
configuration
of
it
in
that
deployment
model.
Now
what
are
the
differences
that
ambassador
offers
from
some
of
the
other
api
gateways
that
are
available
today?
Well,
no
vendor
lock-in.
A
So
if
you
use
a
hosted
vendor
provided
solution
like
the
Amazon
API
gateway,
then
you're
kind
of
bound
to
using
that
only
in
Amazon's
AWS
cloud.
If
you
want
to
use
that
somewhere
else,
not
really
an
option.
So
if
you
want
more
portability,
one
of
the
things
that
kubernetes
provides
is
portability
of
your
data,
no
matter
where
it's
running
embassador
being
native
to
kubernetes
is
also
portable.
There's
no
dependency
on
an
external
database,
so
this
one
I
actually
think
is
pretty
critical.
A
Ambassador
will
leverage
kubernetes,
basically
at
CD,
to
handle
all
the
configuration
and
that's
where
the
state
is
stored.
So
you
don't
have
to
manage
your
own
external
database,
whereas,
for
example
Kong
you
do
have
to
manage
a
sequel
or
Cassandra
or
some
database
to
actually
store
the
state
or
you
have
to
handle
it
yourself
and
replicate
it
between
all
the
different
instances
that
you
have
self
service
in
kubernetes
native
again,
I
can
use
the
constructs
of
kubernetes
I.
Don't
have
to
learn
some
sort
of
new
configuration
syntax
or
manage
it
through
some
other
system.
A
I
can
leverage
what
I'm
already
doing
in
kubernetes
and
then
leveraging
envoy
again.
I
think
this
one
is
critical
envoy
is
a
CNC
F
graduated
project,
I'm,
aware
of
many
people
that
are
running
this
in
production
today
at
scale
and
highly
rely
on
it,
whether
it's
for
service
mesh
or
API
gateway
or
a
variety
of
other
use
cases.
It's
very
common
to
see
envoy
being
adopted
in
the
cloud
native
world
and
the
fact
that
ambassador
takes
advantage
of
it
I
think
is
pretty
critical.
A
So,
with
that
background,
let's
talk
about
cloud
native.
Eight
applications
I
want
to
do
this
by
providing
some
different
ways
you
can
deploy
ambassador
and
then
give
you
real-world
examples
of
how
I've
seen
it
done.
So.
The
number
one
use
case
for
ambassador,
as
I
mentioned
earlier,
is
for
edge
routing.
A
That
basically
means
it
sits
on
the
perimeter
of
your
environments,
and
data
coming
into
your
environment
would
go
through
the
Ambassador,
API
gateway
and
then
get
routed
accordingly,
depending
on
how
it
has
been
configured
now
to
do
this,
you
probably
need
some
key
features
like
authentication.
If
your
edge
proxy
is
being
exposed
to
the
Internet,
you
probably
don't
want
to
expose
that
without
authentication,
encryption
handling,
different
types
of
protocols
that
are
important
to
your
environment,
so
all
these
things
need
to
be
considered
now.
A
These
are
solved
problems,
but
they
can
get
tricky
depending
on
your
environments.
So,
let's
walk
through
some
examples.
How
would
I
use
the
Ambassador
API
gateway
in
an
edge
configuration?
Well,
let's
say
you're
moving
from
a
monolith
to
microservices.
A
lot
of
people
are
doing
that
today.
That
means
that
all
your
traffic
comes
into
your
monolith.
A
Maybe
you
have
a
load
balancer
in
front
of
it
to
handle
traffic,
but
if
you're
thinking
about
moving
to
microservices
a
common
first
step
is
to
put
an
api
gateway
in
front
of
the
monolith,
because
this
now
gives
you
flexibility.
If
you
want
to
spin
up
new
microservices
and
route
traffic
to
it,
instead
of
to
the
monolith
now
you
can
and
because
you're
probably
gonna
need
an
api
gateway
anyway,
when
you
get
to
microservices,
this
is
a
great
first
step.
A
This
is
what
we
see
a
lot
of
people
doing
as
their
you
move
to
a
micro
services
based
architecture
and
then
over
time
they
will
start
creating
micro
services
off
of
the
monolith.
There
are
two
primary
ways
that
I've
seen
this
happen.
Number
one
is
I,
have
a
new
feature:
I'm
gonna,
build
it
as
a
micro
service,
instead
of
putting
it
in
my
monolith.
The
second
is:
I
need
to
refactor
my
code
inside
of
my
monolith.
Maybe
I'll
break
off
an
existing
service
and
I'll
make
that
be
a
new
micro
service
going
forward.
A
This
is
kind
of
a
hub-and-spoke
model.
Typically,
when
you're
doing
this,
when
you're
spinning
up
new
services
or
breaking
them
off,
you're
still
gonna
communicate
directly
with
the
monolith
first
and
then
the
monolith
will
call
out
to
the
micro
Service
it's
necessary
and
typically
in
this
model,
the
micro-services
don't
talk
to
each
other,
at
least
not
in
the
early
days.
So
again,
having
an
API
gateway
is
helpful,
but
it
didn't
really
provide
any
additional
benefits
yet
other
than
I
can
route
to
those
two
micro
services.
A
If
I
want
to
now
over
time,
the
monolith
will
hopefully
get
smaller
and
smaller
and
eventually
you'll
get
to
a
state
where
you
start
connecting
these
micro
services
together.
Maybe
I
want
the
API
gateway
now
to
go
directly
to
a
micro
service
before
that
micro
service
calls
into
the
monolith,
maybe
I've
spun
off
a
new
application.
That's
purely
micro
services
based
and
doesn't
need
to
communicate
with
the
monolith
anymore
over
time.
A
You'll
continue
chipping
away
at
that
monolith,
and
hopefully
it
goes
entirely
away
and
now
I
have
an
API
gateway,
that's
possible
of
handling
different
routing
depending
on
the
traffic
needs
in
my
environment.
So,
let's
take
an
example
of
a
saz
service,
just
something
kind
of
generic.
Let's
assume
that
you
have
something
that
has
to
ingest.
Some
data
has
to
provide
an
interface
to
query
that
data
back
out,
because
there's
data
involve
it
needs
to
be
persisted,
and
I
probably
want
to
authenticate
that,
because
it's
a
sad
service
on
the
Internet.
A
A
I'll
talk
about
best
practices
in
a
minute,
I
want
to
touch
on
TLS,
real
quick,
because
it
definitely
comes
up
with
edge
Ed's,
proxy
and
API
gateways
in
general.
So
you
have
two
basic
models.
You
can
either
terminate
TLS
on
like
say
the
API
gateway
in
this
case
Ambassador
or
you
can
pass
through
the
TLS
connection
and
make
it
be
handled
downstream
by
your
application
or
service.
So
ambassador
does
support
both
models
depending
on
your
needs
and
does
have
different
routing
capabilities
that
are
possible
as
well.
A
It
also
supports
SNI
server,
name,
I
forgot
what
it
stands
for
sorry,
but
s
and
I
basically
allows
you
to
route
based
on
the
host
header
of
the
packet
that
you're
sending
in
because
when
the
payload
is
encrypted,
if
you
don't
know
how
to
route
that
traffic,
then
you
wouldn't
be
able
to
send
it
to
a
downstream
service,
especially
in
a
multi-tenant
environment,
so,
and
that
later
versions
of
ambassador
do
support
s,
and
I
use
case
number
two.
So
let's
keep
with
this
north-south
routing.
A
So
if
you
heard
of
edge
an
edge
api
gateway,
it's
usually
north-south
traffic.
Basically,
it
comes
in
and
goes
down
into
my
environment
and
then
comes
back
up.
Another
use
case
for
that
wouldn't
be
on
the
edge,
but
it'd
be
more
internal
to
my
environment,
so
I
may
still
have
an
edge
api
gateway,
but
then
I
have
kind
of
a
tiered
approach.
A
If
you
think
of
like
a
three-tier
app,
maybe
between
my
web
tier
and
by
middleware
or
between
my
middleware
in
my
back-end,
I
might
want
to
have
an
api
gateway
as
well
to
handle
different
routing
needs
again.
This
is,
can
be
used
for
things
like
multi-tenant
environments
and
it
can
provide
a
whole
lot
of
benefits
that
I
can
offload
from
my
app
like
buffering
and
retries
and
different
caching
policies.
So
again,
going
back
to
my
real-world
example:
I'm
kind
of
enhancing
the
sass
service
here,
let's
assume
that
every
tenant
gets
its
own
namespace.
A
Every
namespace
has
the
same
set
of
services.
So
now
I'm
talking
about
more
of
a
multi-tenant
sass
with
some
isolation.
How
could
I
route
traffic
using
the
previous
example?
Well,
the
edge
proxy
can
still
do
this
internal
routing.
For
me,
that's
completely
supported,
but
you
may
want
to
actually
separate
out
those
responsibilities.
Maybe
I
want
the
edge
Ambassador
instance
to
be
totally
separate
from
the
internal
ambassador
instance.
There
are
actually
valid
reasons
to
separate
these
out.
I'll
talk
about
them
and
lessons
learned
in
just
a
second.
A
Then
we
have
internal,
east-west
traffic.
So
let's
say
I
have
micro
services
that
want
to
talk
to
each
other
on
the
same.
Tier
I
could
also
use
an
API
gateway
for
that.
How
would
I
do
that
and
the
kubernetes
world
is
a
question
that
often
gets
asked,
and
why
would
I
want
to
do
it?
The?
Why
is
because
of
things
like
I
want
to
handle
different
load.
Balancing
policies.
I
want
to
have
different
service
discovery
models.
How
can
I
do
that?
A
I
could
implement
it
in
my
app
I
could
leverage
some
third-party
service
like
console
I
could
have
used
something
like
an
API
gateway,
so
in
this
deployment
model,
if
I'm
in
kubernetes
I
can
actually
deploy
Ambassador
as
a
daemon
set,
which
means
it
runs
on
every
single
host
and
then
from
a
DNS
perspective.
I
can
actually
have
all
of
my
micro
services
talk
directly
to
Ambassador.
A
So,
for
example,
if
I
want
the
analytic
service
to
talk
to
the
ingest
service,
the
DNS
record
can
be
on
the
Ambassador
instance
itself,
so
the
analytic
service
will
actually
talk
to
ambassador
ambassador
handles
the
routing
up
to
the
ingest
service.
This
can
also
happen
across
house.
So
if
the
analytic
service
wants
to
talk
to
the
quarry
service
again,
it
can
do
that
through
Ambassador,
so,
instead
of
doing
it
directly,
this
provides
a
lot
of
flexibility
and
again
I
can
offload
some
of
the
responsibilities
that
it
otherwise
have
to
code
into
my
application
itself.
A
Service
mesh
also
comes
up
when
you
think
about
east-west
traffic.
You
probably
think
about
a
service
master.
Something
like
Sto
su
is
based
on
envoy
uses.
Envoy
is
a
data
plane,
though
other
ones
are
going
to
be
supported,
and
then
SEO
has
a
control,
plane
called
mixer
today
and
that
can
basically
handle
this
east-west
traffic.
So
basically
the
Envoy
proxies
talk
to
each
other.
A
So
if
the
query
service
wants
to
talk
to
the
billing
service,
the
envoys
can
handle
that,
but
SEO
handles
the
configuration
of
envoy
and
all
the
different
policies
that
you
want
to
have.
Even
in
a
service
mesh,
you
can
leverage
ambassador,
so
maybe
ambassadors
used
from
an
edge
Gateway
perspective,
so
it's
only
used
in
the
edge.
The
perimeter.
I
could
also
be
used
on
a
internal
routing
perspective
too,
like
per
namespace
I
could
have
an
ambassador
instance
and
then
offload
the
rest
of
responsibilities
to
the
service
mesh.
A
Some
non
application
base
use
cases
for
ambassador.
One
of
the
biggest
ones
is
chat
traffic
shadowing
this
one's
really
cool.
So
basically,
let's
say
I
have
an
application.
That's
running
available
in
my
environment
and
I
want
to
spin
up
another
copy
of
that
environment
and
I
want
to
replicate
the
traffic
to
it.
So
I
can
test.
Let's
say
a
new
software
build
or
a
new
configuration
parameter
new
sizing
things.
A
I
can
do
that
with
ambassador
I
can
say,
keep
routing
a
hundred
percent
of
the
traffic
to
my
production
service,
but
send
either
a
hundred
percent
copy
of
that
data
to
a
new
location
or
a
small
percentage.
One
percent
five
percent
ten
percent.
It's
actually
configurable
how
much
data
you
shadow
to
the
other
destination.
This
allows
you
to
really
test
in
production
and
you
have
real
data
so,
instead
of
trying
to
simulate
it
or
use
a
staging
or
development
environment,
you
could
actually
do
this
live
in
production,
very
powerful
for
testing
new
features.
A
Now
how
this
works
is
when
I
send
to,
in
this
case,
slash
my
service
I,
actually
send
the
data
to
that
service
and
I
receive
the
acknowledgement.
Ambassador
receives
the
entire
communication
path.
In
the
case
of
the
shadow,
it
sends
the
data
to
the
shadow,
but
it
never
listens
for
the
acknowledgment,
it's
kind
of
a
fire-and-forget.
If
you
will
that's
because
if
invalid
ambassador
acknowledged
it
that
could
cause
some
issues,
but
this
is
extremely
powerful.
You
can
get
all
your
limit
tree
data
metrics,
prometheus
stats
out
of
Ambassador
to
see
how
that
traffic's
being
handled.
A
You
can,
of
course,
monitor
your
shadow
application,
it's
great
for
software
developers
that
want
to
test
code,
another
one
for
software
development
for
more
of
a
testing
perspective
ambassadors
from
a
company
called
data
wire
I
do
not
work
at
data
wire,
I
work
at
a
mission.
They
have
another
product
called
telepresence.
It's
part
of
CN,
CF
and
telepresence
allows
a
local
developer
that
has
code
running
on
their
local
device.
They
allow
them
to
connect
that
into
an
existing
kubernetes
environment
and
run
it
live.
You
can
actually
hook
this
up
into
ambassador
as
well.
A
So,
for
example,
if
I
have
a
software
developer
here,
Jane
who
wants
to
send
a
request
in
get
authenticated
by
ambassador
and
then
actually
connect
to
her
local
desktop
in
a
production
environment
via
telepresence
that
can
be
done
where,
as
another
user,
let's
say,
Bob
wants
to
connect
not
using
telepresence
not
connecting
to
their
local
desktop.
They
would
see
the
real
production
environments.
This
is
extremely
powerful
and
flexible.
Big
disclaimer
here
this
part
is
not
free,
so
ambassador
is
an
open-source
project,
but
they
do
have
a
pro
paid
version.
A
This
is
one
of
the
paid
version
features.
Telepresence
is
free,
open-source
project
so
is
ambassador,
but
when
you
want
to
tie
them
together
that
part
cost
money
today,
all
right.
So
with
that
context,
let's
go
ahead
and
talk
about
configuration,
configuration
matters
depending
on
the
version
that
you're
running
if
you're
running
a
version
later
than
0.6
50,
please
upgrade.
That
version
is
quite
old
at
this
point,
but
back
in
those
days
your
options
were
config,
Maps
or
annotations.
A
Ambassador,
but
I
wouldn't
be
surprised
of.
Annotation
support
goes
away
in
the
future,
so
I
would
definitely
look
at
C
or
these
I
do
want
to
provide
some
configuration
examples
for
you.
This
is
from
the
documentation.
I
just
want
to
call
out
some
important
things
to
be
aware
of,
including
some
lessons
learned
that
I
had
I'm
actually
providing
two
different
forms
of
the
configuration
for
you.
A
If
you
were
to
use
an
annotation
versus
if
you
were
to
use
a
C
or
D,
because
some
people
have
not
moved
to
0.70
or
greater
yet,
as
you
can
see,
they
look
remarkably
similar,
it's
just
a
C
or
D
is
a
top-level
parent
construct
or
an
annotation
gets
written
into
another
existing
a
resource,
for
example
a
service.
So
a
few
things
to
call
out
here,
ambassador
configurations
are
versions
version
one
came
out
at
0.50:
you
should
be
using
version,
1,
0
person,
zero
is
deprecated.
A
Another
thing
to
call
out
here
is
that
all
configuration
is
done
by
a
kind,
so
here
we're
looking
at
encryption,
so
that
kind
is
module.
There
are
different
types
of
kinds
of
configuration.
They
are
all
documented
for
you,
the
Ambassador
ID
is
critical.
So
if
you
run
a
one
ambassador
cluster,
you
don't
need
ambassador
ID,
but
if,
let's
say
you
have
an
ingress
one
and
a
separate
internal
ambassador
cluster,
you
need
to
have
unique
identifiers.
Otherwise
the
system
won't
know
how
to
configure
itself
and
you'll
have
overlapping
config
between
your
instances.
A
So
my
general
advice
is
even
if
you
only
have
one
ambassador
cluster
today
go
ahead
and
set
that
ID
it'll
make
your
life
easier
in
the
future.
If
you
happen
to
add
another
ambassador
cluster
and
then
finally
the
name
so
every
configuration
section
has
a
name.
That
name
needs
to
be
unique.
So
we'll
talk
about
mappings
here
in
a
second
one,
common
mistake
that
I
see
made
is
that
the
same
name
is
used
for
multiple
different
mappings
that
will
not
work.
You
will
have
configuration
problems.
A
It
can
be
hard
to
troubleshoot
because
sometimes
the
logs
are
not
clear
as
to
what's
happening
from
an
authentication
perspective.
This
is
actually
a
big
feature
in
my
opinion
of
using
Ambassador
as
an
edge
gateway.
You
can
actually
have
it
require
authentication
at
every
request
that
is
made.
So
basically,
when
a
request
comes
in
to
the
API
server,
it
will
go
off
and
authenticate.
It
make
sure
you're
authenticated
before
it
makes
the
call
downstream.
A
Now
there
are
configuration
parameters,
it's
a
bypass,
the
authentication
service,
I
personally,
don't
recommend
that
I
would
rather
add
that
logic
into
the
authentication
service
myself.
But
that's
just
my
opinion
and
how
I've
seen
it
done
what's
worth
mentioning
here.
Embassador
does
not
provide
an
authentication
service.
You
must
provide
that
there
are
plenty
of
open
source
options
out
there.
It's
very
easy
to
get
it
configured,
but
ambassador.
The
open-source
version
does
not
have
authentication
service.
The
pro
version
which
you
pay
for
does
have
an
authentication
service.
A
If
you're
interested
in
that,
basically
how
this
works
is
you
specify
hey?
My
authentication
service
is
located
here.
Here
is
the
path
and
ports
to
connect
to
it,
and
then
you
can
specify
different
headers
that
you
want
to
receive
or
send
to
the
authentication
service
to
authenticate
that
request
mappings.
This
is
probably
the
most
critical
thing
in
Ambassador,
so
you
authenticate
your
request.
You
have
encryption
in
place.
That's
kind
of
initial
configuration,
especially
from
an
edge
routing
perspective,
but
the
primary
use
case
for
ambassador
is
actually
mapping
and
routing
calls
within
your
environments.
A
So
a
mapping
basically
says
I
have
some
source
here.
It's
called
hosts
and
I
have
some
paths
here.
It's
called
prefix
so
in
this
particular
example,
I'm
saying
if
the
host
equals
omniscient,
oh
and
the
path
is
slash,
then
I
want
you
to
send
that
traffic
I,
want
you
to
map
it
to
the
service,
which
is
called
web
dot
default.
So
if
I'm
in
kubernetes,
that
would
be
a
service
called
web
in
the
default
namespace.
A
So
if
it
goes
down
or
if
you
have
performance
problems,
you're
gonna
want
to
know
about
that.
You're
gonna
want
to
be
able
to
observe
the
system,
so
out-of-the-box
ambassador
provides
previous
metrics
through
us.
That's
d
exporter
it
has
logs
natively
built
in
it,
has
a
diagnostic
UI
that
you
can
access
on
port
8/8,
seven
seven,
which
tells
you
about
the
configuration
and
the
general
health
of
the
system,
but
it
also
has
the
ability
of
sending
out
distributed
tracing
data
in
the
form
of
Zipkin.
So
this
is
just
a
configuration
parameter.
A
We
basically
say:
hey
I,
have
a
in
this
case
destination
that
except
Zipkin
called
collector
dot
dot
default,
and
I
want
to
use
the
zip
pin
driver
to
export
that
data
and
now
I
can
see
distributed,
trace
information
in
my
environment,
which
is
very
important
for
micro
services
based
environments.
Alright,
so
lessons
learned
dedicate
ambassadors,
/
responsibility.
I
showed
you
in
just
in
query,
going
to
the
same
Ambassador
instance
and
the
fact
that
ambassador
could
route
to
multiple
namespaces
I.
Don't
recommend
this
I
recommend
that
you
separate
per
responsibility.
A
Ingest
has
a
dedicated
ambassador
with
its
own
ID
quarry
has
its
own
ambassador
with
its
own
ID
internal
routing
is
handled
by
its
own
ambassador
by
its
own
ID.
Yes,
that's
three
different
clusters.
It's
really
not
that
hard
to
manage
them,
but
that
isolation
provides
a
whole
lot
of
the
benefits,
for
example,
fault
tolerance.
If,
for
example,
ingestion
brings
down
query
everyone's
gonna
be
sad,
but
if
ingestion
and
quarry
are
separate,
then
even
if
ingestion
is
having
a
problem,
quarry
is
still
available.
That
separation
of
responsibilities
is
quite
powerful.
A
This
does
require
a
unique
ambassador
ID
per
cluster.
Second
time
outs
I
got
burned
by
this
one.
So
worth
noting,
there
is
actually
a
timeout
of
three
seconds
for
every
ambassador
cluster
that
you
have
so
here
you
can
see
if
I
have
an
edge
ambassador
instance,
it
has
a
three-second
timeout
if
I
have
a
downstream
ambassador.
That
also
has
a
three
seconds
timeout.
Well,
let's
say
the
quarry
path
is
not
responding.
Well,
the
call
came
in
from
the
intranet
here,
and
the
time
starts
for
this
ambassador
cluster
immediately.
It
calls
the
converter
service.
A
Maybe
that
takes
a
hundred
milliseconds.
It
calls
ambassador
that
takes
ten
milliseconds.
It
calls
the
quarry
path
this
times
out.
That
timeout
is
going
to
happen
here
first
before
this
one
times
out
that
can
bring
down
your
service
I've
seen
it
happen.
The
flipside
of
that
is,
if
you're
running
a
load
balancer
in
front
of
your
ambassador,
which
you
probably
are
in
the
edge
there
are
probably
timeouts
for
that.
The
default
AWS
load
balancer
time
out
of
60
seconds.
That's
a
long
time.
Try.
Upgrading
Ambassador
doesn't
go
so
well
with
those
timeout
defaults.
A
So
you
need
to
make
some
changes.
You
can
actually
override
these
again
in
the
yamo
configuration
there's
a
way
to
override
the
defaults
I'm,
showing
you
an
example
for
AWS,
but
other
clouds
are
supported
as
well.
These
are
just
annotations
that
you
add
and
you
can
set
the
thresholds
that
you
care
about
and
you
can
override
the
timeouts
in
Ambassador.
So
if
you
have,
for
example,
a
north-south
configuration
with
an
ambassador
on
the
edge
and
another
one
internally,
I
recommend
that
your
edge
one
have
a
higher
timeout
than
your
internal
one.
A
That
way
that
things
timeout
properly
and
you
get
the
right
error
messages
when
things
are
not
working
properly.
You
can
do
that
from
a
request,
perspective
and
idle
timeout
and
a
connection
perspective
that
can
be
done
per
mapping
or
globally
for
the
entire
Ambassador
instance.
So
a
lot
of
flexibility
there,
understanding
service
discovery,
so
by
default
service
discovery
is
done
by
kubernetes
services
and
that's
done
via
DNS
use,
service
or
service
dot.
Namespace,
don't
do
service
namespace
that
SVC
dot
cluster
that
local.
This
is
not
an
ambassador
thing.
A
This
is
a
kubernetes
thing
from
a
DNS
perspective,
that's
very
inefficient,
so
I
don't
recommend
putting
the
SVC
to
cluster
that
local
on
the
end,
ambassador
does
support
other
routing
mechanisms.
Besides
a
kubernetes
service,
for
example,
you
can
do
endpoint
routing
in
kubernetes,
as
well
as
console
routing
and
then
from
a
load
balancing
perspective.
Round-Robin
is
the
defaults
if
you're,
using
like
endpoint
routing
but
ring
hash
and
Maglev
are
supported
again.
This
is
based
on
envoy,
so
anything
that
envoys
supports
can
also
be
added
to
ambassador
and
other
load.
A
Balancing
policies
will
be
added
in
the
future
and
then
I'll
point
out.
One
problem
that
I
have
personally
experienced
with
Ambassador
and
I
think
it's
more
of
a
kubernetes
problem,
but
we
had
an
example
where
we
would
try
to
upgrade
a
downstream
service.
So
let's
say
I
terminate
one
of
my
converter
pods
and
a
new
one
comes
up
because
the
replication
set
is
set
to
two.
When
that
happens,
ambassador
starts
generating
503
s
until
you
kick
ambassador,
not
good
from
a
performance
standpoint.
So
this
is
something
that
we're
actually
actively
investigating.
A
There's
a
github
issue
open
about
it,
I,
don't
think
it's
necessarily
ambassador
specific,
but
I
did
want
to
point
it
out
in
case
you
see
it
yourself.
Finally,
some
other
lessons
learned
I
think
ambassador
is
great
to
get
started.
I
was
able
to
deploy
it
and
get
it
running
in
minutes
like
less
than
an
hour.
I
had
this
working
in
a
production
environment
very
simple,
it
provides
the
basic
constructs,
but
you
do
need
to
do
some
work
to
yourself.
For
example,
you
want
a
fent
ocation.
You
need
to
go
solve
that
problem.
A
A
So
how
do
you
do
want
to
handle
that
when
you
run
across
that
from
a
best
practices
perspective,
make
sure
you
store
your
configuration
with
your
service,
so
the
exception
I'd
say
here
is
the
authentication
service
itself
I
highly
recommend
that
the
configuration,
whether
it's
an
annotation
or
a
CR
D
for
authentication,
be
stored
with
Ambassador,
not
with
your
authentication
service?
Why?
Because
I
want
to
ensure
that
ambassador
requires
authentication
for
my
calls.
If
my
off
service
fails
to
deploy
or
is
misconfigured
I,
don't
want
ambassador
to
bypass
it
and
try
to
route
traffic
downstream.
A
That
would
be
very
insecure
other
than
the
authentication
service.
You
should
store
anything.
That's
ambassador
configuration
related
for
a
service
in
the
service
repository
so
Mike.
My
quarry
service
will
have
annotations
or
C
or
DS
for
the
Cori
service
same
for
my
ingest
service,
and
then
everything
should
go
through
CI
C
D,
so
treat
configuration
as
code
and
routing
is
much
harder
than
internal
routing.
A
So
you
need
to
answer
questions
like
how
would
you
address
end-to-end
encryption
and
you
need
to
answer
questions
like
from
a
thent
ocation
perspective
which
headers
you
care
about
routing
in
and
out
and
then
from
an
observer
ability.
Standpoint
ambassador
is
actually
pretty
good,
because
envoy
is
actually
pretty
good
when
it
comes
to
observer
ability.
There
are
very
good
Prometheus
metrics
that
are
exposed
that
you
can
take
advantage
of.
In
my
opinion,
they're
a
little
bit,
not
granular
enough.
A
A
A
Your
gateway,
yeah
gotcha,
so
SEO
is
a
service
mesh.
The
goal
typically
is
for
internal,
east-west
communication
for
Asia.
That's
its
primary
focus.
It
can
do
edge
as
well,
but
that's
not
its
primary
focus.
Ambassadors
and
primary
focus
is
the
exact
opposite.
It
primarily
focuses
on
edge
and
not
as
much
on
east-west,
but
it
can
do
east-west.
A
So
what
I
often
see
is
a
combination
of
both
I've
seen
a
lot
of
customers
that
will
deploy
sto
for
their
internal
traffic
and
have
ambassador
sit
on
the
edge
to
route
traffic
in
and
out,
because
ambassador
typically
is
more
feature-rich
for
things
like
G
RPC,
TLS
termination
of
data,
where
sto
doesn't
have
some
of
those
features.
Yet
today.
B
A
C
A
A
So
I
mean
from
an
issue
perspective,
just
configure
your
app
like
you
normally
have
ambassador
just
sits
on
the
edge
gateway,
so
it's
the
traffic
routing
into
your
environment,
so
think
of
it
as
a
separate
ingress
controller
from
sto,
and
then
the
API
gateway
of
Ambassador
can
be
used
to
route
directly
to
your
application.
Through
is
do
so
there
there.
There
really
isn't
any
overlap
there.
You
can
completely
isolate
the
two
from
a
configuration
standpoint.
D
A
Recommendation
would
be
to
use
series
because
I
think
CDs
in
the
future.
If
you
start
listening
to
some
of
the
talks
this
week,
Cabrera's
is
moving
to
a
C
or
D
model,
so
I
I
personally,
wouldn't
be
surprised
if
annotations
get
removed
from
ambassador
in
the
future.
But
that's
my
opinion.
I
can't
speak
for
what
data
wire
is
planning
to
do.
Annotations
are
fully
supported
in
0.70.
You
do
not
need
to
move
to
c
or
DS.
I
can
see
some
big
benefits,
though.
A
If
you're
running
kubernetes,
114
or
newer,
then
you
can
actually
do
C
or
D
server-side
validation,
which
you
cannot
do
with
annotations
today.
That's
a
huge
benefits.
I
can
now
make
sure
that
the
config
is
the
way
that
I
expect
it
to
and
that
it's
going
to
work
properly.
That's
something
missing
from
annotations
and
I
wouldn't
expect.
Cooper
needs
to
add
so
long
term,
I
think
C,
or
these
are
the
way
to
go.
Okay,
thank.