►
Description
#OpenSource #Istio
At this meetup, we celebrated 4 years in the open source world. The presentation and questions covered contributions that have helped build Istio. For the demo, please watch https://youtu.be/4AONRFwUsz8
A
A
We
started
to
you
know,
look
at
how
to
solve
these
common
problems
with
service
to
service
communication
and
use
service,
mesh
design
pattern
about
four
or
five
years
ago,
and
we
started
off
with
actually
with
just
java
libraries
embedding
them
and
services
to
solve
these
problems.
Then
we
moved
to
a
out
of
process
sidecar.
You
know
like
essentially
following
the
mesh
design
pattern
with
linguity
sidecar
and
then
in,
I
think,
around
2017.
A
However,
at
that
time
there
was
no
good
open
source
product
that
we
could
use
as
the
control
plane
and
therefore
we
started
off
with
a
in-house
control
plane
that
was
bare
minimal.
That
would
work
for
our
needs
to
configure
our
own
ways
that
we
had
and
then
in
2018,
when
istio
released
its
first
version
when
we
looked
and
looked
at
it
upon
initial
review,
it
looked
like
it
was
solving
some
of
the
same
problems
that
we
were
trying
to
solve.
A
Our
in-house
control
plane
worked
great
for
us
and
and
in
fact
it
still
runs
in
some
of
our
production
data
centers,
because
we
haven't
fully
migrated
to
sdo,
but
we
were
starting
to
get.
You
know
a
lot
of
use
cases
for,
let's
say:
stateful,
set
support,
service
manager,
sorry
service,
specific
config
that
was
making
it
was
becoming
harder
and
harder
for
us
to
evolve
our
in-house
control
plane.
So
that
is
why,
when
we
looked
at
istio
in
2018,
it
looked
upon
an
initial
review.
A
It
looked
like
a
feature-rich
control
plane
that
was
solving
for
the
same
problems
that
we
were
trying
to
solve
and
therefore
was
a
good
fit,
and
it
also
seemed
to
have
a
great
community.
That
was,
you
know,
that
contributing
to
the
product
and
therefore
we
decided
to
do
a
poc
on
istio
and
then
eventually
migrated
to
it.
With
our
adoption
with
istio.
A
We
first,
you
know,
had
to
get
feature
parity
with
our
in-house
control
plane
in
order
to
even
think
about
adopting
it
and
then
in
our
existing
deployments,
we
the
intention
our
intention
was,
as
we
were,
swapping
out
the
control
plane
we
had
to
make.
We
wanted
to
keep
the
customer
interface
changes
minimal
so
that
they
we
could
just
swap
it
out
without
them
having
to
do
much.
A
So
we
would
be
brought
up
both
the
control
planes,
the
in-house
and
the
and
sto
in
these
deployments,
and
then
we
migrated
services
gradually
and
then
in
new
deployments.
We
just
run
with
the
istio
only
mesh
platform
now
for
the
first
part
of
it,
which
is
to
get
feature
parity
with
our
in-house
control
plane.
This
is
kind
of
the
high
level
what
it
looks
like
we
run.
We
used
to
run
our
in-house
control
plane,
but
now
run
is
tod.
A
So
that
is
that
was
our
first
contribution
to
istio,
which
is
making
mtls
work
with
a
custom
ca
and
that's
what
we
run
in
our
production
data
centers
today-
and
this
is
what
it
looks
like
today.
It
didn't
look
like
this
two
years
ago,
but
this
is
what
it
looks
like
today,
envoy.
The
istio
proxy
communicates
with
pilot
agent
via
a
secret
discovery
service.
A
Api,
an
sds
api
and
pilot
agent
then
reads
the
search
from
the
file
mounted
or
in
memory
volume
mounted
certs
rather
than
from
istio
d
or
citadel,
and
we
have
a
custom
cert
refresher
that
is
salesforce
pacific,
that
we
run
in
our
kubernetes
clusters
that
refreshes
these
sets
so
we're
able
to
get.
You
know:
custom
custom,
search
provisioned
by
a
custom,
ca
work
with
envoy
for
mtls.
A
So
this
is
our
first
contribution
to
istio,
which
not
only
do
we
do
did
we
do
that?
First,
you
know
pr
to
actually
make
it
work,
but
over
time
as
istio's
sort
of
the
features
related
to
mtls
and
how
we
do
how
we
manage
so
it's
changed.
We
have
evolved
this
custom
ca
integration
so
that
we
can
ensure
that
it
continues
to
work
for
us,
so
we
were
involved
with
the
pre
sds
implementation.
A
We
added
integration
tests
to
ensure
that
this
integration
with
our
custom
ca
will
not
work.
It
will
not
break
and
and
then,
when
we
switch
to
the
sds
implementation,
we
made
changes
there
so
that
as
it
evolves,
this
feature
continues
to
work.
As
you
can
see,
it's
one
of
the
fundamental
features
that
we
would
expect
out
of
the
mesh
platform.
A
So
it's
crucial
for
us
moving
on
coming
back
to
that
diagram
that
we
were
looking
at
earlier,
our
in-house
control
plane
publishes
metrics,
so
essentially
the
the
proxies
publish
metrics
to
a
metric
service
onward.
You
know
it
has
a
metric
service
api
that
our
metrics
relay
service
implements
and
then
it
it
transforms
or
filters
out
metrics
before
it
publishes
them
to
our
matrix
platform,
with
the
intention
that
our
service
owners
should
not
have
any
change
in
their
interface
and
how
they
observe
traffic.
A
A
couple
of
years
ago
would
only
publish
metrics
via
mixer
and
it
sort
of
aggregates
metrics
and
does
not
let
you
publish
more
lower
level
telemetry.
We
enhanced
that
so
that
we
could
publish
more
lower
level
on
white
telemetry
and
we
did
a
couple
of
things
there.
So
we
made
the
metric
service
be
configurable.
So,
as
you
can
see,
you
can
configure
the
proxies
to
you
to
point
to
a
particular
metric
service.
A
If
you
want,
and
that
communication
also
uses
mtls,
so
you
can
configure
tls
for
it,
and
we
also
made
some
enhancements
to
publish
these
metrics
using
a
alias
so
that
we
could
maintain
the
metrics
queries
that
our
service
owners
were
using.
We
could
maintain
that,
and
so
they
could,
they
didn't
have
to
change
their
metrics
and
alerting
that
that
they
were
used
to
coming
back
to
that
diagram
there.
Let's
talk
a
little
bit
about
this
config
web
hook
with
our
in-house
control
plane,
we
were
applying
some
default
config
to
all
the
services.
A
For
example,
we
we
have
a
resiliency
framework,
a
testing
framework
that
runs
through
some
common
scenarios
like
rolling
upgrades
crashes
of
services,
transient
failures
and
we
tweaked
the
resilience
policies
of
the
proxy
to
maximize
the
success
rate
of
requests.
When
these
issues
happen,
and
then
we
apply
those
resilience
policies
using
our
in-house
control
plane.
A
So
what
we
did
was
we
had.
This
config
web
hook
automatically
generate
the
virtual
service
and
destination
rules,
but
then
we
hit
a
point
where
we
couldn't
apply
those
resilience
policies
because
they
were
not
exposed
as
as
istio
api,
so
the
next
set
of
yeah,
so
our
next
set
of
improvements
were
related
to
well.
You
know
what
I
think
I
missed
hold
on.
A
Let
me
go
back
yeah
yeah,
so
our
next
set
of
improvements
were
related
to
being
able
to
apply
these
resilience
policies
via
the
istio
api,
and
we
did
this
in
two
ways.
In
some
cases
these
resilience
policies.
It
made
sense
to
make
them
the
default
in
the
istio
product,
so
we
discussed
it
with
the
community,
and
we
said
yes
for
http
this.
A
A
However,
in
order
for
this
bare
metal
service
to
participate
in
the
mesh,
we
continue
to
use
zookeeper
for
announcements
as
a
service
registry
for
these
service
experimental
services,
and
we
have
a
sync
service
that
creates
a
service
entry
object.
Now
a
service
entry
object
allows
is
an
stoc
or
dnsu
api
again
that
allows
these
services
that
are
not
running
on
kubernetes
to
be
to
participate
in
the
mesh
just
like,
as
if
they
were
a
kubernetes
service.
So
we
created
these
service
entry
objects
via
the
sync
service
into
and
created
them
in
kubernetes.
A
Now,
when
we
did
that,
we
noticed
that
the
control
plane
wasn't
as
performant,
we
had
a
ton
of
different
service
entry
objects
and
the
control
plane
wasn't
fast
enough
in
processing
these
requests.
We
saw
issues
with
reliability
of
availability
of
the
control
plane,
so
we
made
improvements
to
the
control
plane
in
how
it
processes
these
service
entry
objects
and,
in
general,
we've
made
changes
to
the
to
improve
the
performance
of
config
generation.
A
As
you
may
already
be
aware,
istio
takes
the
kubernetes
service
objects.
It
takes
the
istio
configuration
these,
the
crds
that
you
create,
and
then
it
processes
them
and
converts
them
into
onway
config.
So
in
within
that
config
generation
process
or
logic,
we
made
some
performance
improvements
over
time
so
that
it
is
efficient.
A
A
We
also
made
some
changes
to
the
sidecar
crd
and
how
it
how
that
is
processed,
so
the
sidecar
crd
allows
us
to
to
configure
the
listeners
at
a
proxy,
and
we
made
some
changes
to
how
the
clusters
are
created.
Based
on
that
information,
so
we're
reducing
we're,
reducing
the
number
of
clusters
to
only
what's
required
for
that
envoy,
using
the
sidecar
crd
and
more
recently,
we've
adopted.
You
know
the
new
feature
of
istio,
which
is
intercepting
dns
requests
or
the
dns
proxy
feature
we
made
some
enhancements
to
that.
A
A
A
A
Good
example
of
where
you
know
our
bet
to
use
istio
paid
off
was
when
onward
deprecated
the
v2
xds
api,
and
we
had
to
switch
to
the
v3
api
with
our
in-house
control
plane.
We
would
have
had
to
re-factor
our
in-house
control
plane
to
support
v3,
otherwise
it
would
be
incompatible
with
newer
versions
of
envoy.
A
A
If
it's
even
a
good
thing
to
to
make
that
change,
we've
run
some
tests.
We
are
comfortable
with
the
change
and
then
we
take
that
to
the
community
and
and
figure
out
how
to
expose
that
feature
as
an
istio
api.
So
rather
than
first
make
the
hto
api,
in
which
case
we
have
to
be
very
careful
about
how
you
expose
it
via
the
sd
api.
Instead,
we
try
out
try
out
the
change
directly
with
onward
config.
A
You
know
we
get
good
confidence
in
what
the
change
is
and
then
we
take
it
to
the
istio
community
and
make
those
changes.
So
the
onboard
filters
has
definitely
helped
us
sort
of
adopt
a
service
mesh
for
a
variety
of
use
cases,
and
but
I
will
talk
about
one
of
the
side
effects
of
using
envoy
filter,
especially
when
you
have
to
do
upgrades
in
a
little
bit
staple
set.
Support
is
another
sort
of
broad
area
that
we
are
really
thankful
for
all
the
contributions
from
the
community.
A
We
are
adopting
mesh
for
a
ton
of
different
stateful
set
type
use
cases,
and-
and
this
support
has
definitely
helped
us.
We've
also
contributed
a
few
changes
related
to
this,
as
we
have
adopted
istio
for
these
use
cases
at
salesforce,
I
talked
about
multi-cluster
mesh
a
little
while
back
essentially
when
I
say
multi-cluster
mesh.
What
we
at
salesforce
are
looking
for
is
within
the
same
network
boundary.
A
We
might
run
multiple
kubernetes
clusters
with
different
services
there
for
a
variety
of
reasons,
but
we
would
the
mesh
platform
that's
on
top
of
it,
should
function
and
should
abstract
the
fact
that
we
run
on
multiple
kubernetes
clusters
so
that
a
service
that's
running
on
one
cluster
can
communicate
with
the
service
running
on
another
cluster
and
no
and
it's
no
different
from
if
they
were
running
on
the
same
cluster.
So
that's
what
we're
looking
for
and
we've
adopted
the
multi-cluster
mesh
features
of
sto2
to
make
that
happen.
A
So
we
are,
we
have
done
some
spikes,
but
we
haven't
actually
rolled
it
out
to
production
as
yet
we're
in
the
process
of
doing
that
again.
The
web
assembly
extension
support,
which
is
essentially
running
custom
code
and
dropping
that
into
the
data
plane
or
or
onto
an
onboard
running
envoy
for
to
add
custom
business
logic.
A
And
some
scale
related
enhancements
so,
as
I
talked
about,
some
performance
related
fixes
that
we
have
done
and
and
that
will
continue
to
happen,
but
there
are
also
some
scale
related
enhancements
that
are
being
made
within
the
community.
An
example
is
improving.
The
efficiency
of
the
config
delivery
between
the
envoy
and
the
control
plane
is
to
you
by
using
the
delta
xds
api
that
will
be
beneficial
for
us,
as
as
our
match
grows.
A
We
have
we
use
spinnaker
at
salesforce
for
as
our
deployment
pipeline
and
we
use
helm
to
define
these
operators
crds
and
in
general
to
configure
kubernetes
objects
and
and
and
use
our
pipelines
to
deploy
them
before
I
talk
about
how
we
upgrade
just
setting
some
context
here.
So,
as
I
mentioned,
we
use
the
operator
flow.
A
A
A
We
first
upgrade
the
canary
control
plane
and
we
have
some
sample
services
that
we,
you
know
we
we
communicate
that
communicates
with
this
canary
control
plane
and
we
run
some
tests.
We
rely
on
the
alerts
that
we
have
to
ensure
that
everything's,
okay
and
then
we
validate
additional
types
of
use,
cases
using
the
canary
control
plane
and
then
once
we
are
ready
with.
A
We
then
do
an
in-place
upgrade,
so
we
upgrade
the
primary
control
plane
in
that
kubernetes
cluster
we
validate
with
sample
services,
and
then
we
either,
you
know,
initiate
a
rolling
restart
of
the
services
or
we
let
the
services
restart
on
their
own
to
to
get
the
new
proxy
injected,
and
then
we
upgrade
the
ingress
gateway
so
and,
as
I
mentioned
before,
we're
continuing
to
monitor
all
of
these
environments.
So
we
let
it
bake
in
these.
A
You
know
in
these
higher
level
environments
for
a
bit
before
we
propagate
them
further
and
eventually
deploy
the
staging
and
production,
as
I
mentioned
before.
I
actually
should
go
back
to
this
diagram
here,
as
I
mentioned
before,
we
use
onboard
filters
for
for
certain
types
of
configuration
and
in
some
we've
not
had
too
many
issues
with
this
upgrade.
A
But
one
issue
that
that
we
have
seen
that
we're
hoping
to
do
something
about
is
the
on
wave
filter
sometimes
becomes
incompatible
with
the
control
plane
and
we've
seen
issues
where
those
error
out
so
we're
hoping
to
to
be
hoping
to
fix
that
soon.
The
envoy
filters
have
a
proxy
version
that
you
can
tie
them
to.
So
that's
potentially
one
way
we
might
look
to
fix
it.
A
So
there's
we
haven't
taken
action
on
this
as
yet,
but
that's
one
one
of
the
ways
we
hope
to
fix
it
and
maybe
a
couple
of
times
you've
run
into
some
bugs
when
we
do
run
into
those
bugs
when
when
we
are
validating
the
or
sort
of
getting
ready
to
qualify
this
version
of
istio,
if
you
run
into
bugs
here
we
you
know,
we
go
back,
fix
it
in
the
open
source
product.
We
bring
it
back
to
the
canary
cluster
and
then,
and
only
then
will
be
propagated
forward.
So
we
so
we
do.
A
A
Let's
see,
I
think
that's
all
I
had
for
today.
I
think
we
came.
We've
come
a
long
way
in
our
journey
to
adopt
mesh
and
specifically
istio.
We
still
have
a
long
way
to
go
a
couple
of
years
ago,
when
we,
when
we
started
off,
you
know
sending
that
first
pr
to
to
the
istio
open
source
product,
it
was
a
little
rocky.
A
It
took
a
little
while
for
it
to
be
looked
at
and
and
for
it
to
be
checked
in,
but
since
then,
we've
had,
you
know
a
great
experience
with
making
changes
to
the
product.
We've
had
very
good
responses
from
community
members
on
to
for
prs
that
we
send
great
discussion
and
before
it
actually
gets
checked
in
pretty
quickly
also,
as
we
have
adopting
istio
for
a
variety
of
more
complex
use
cases
we
have
had.
A
You
know,
we've
been
able
to
rely
on
the
expertise
of
the
community
to
try
different
things
to
solve
those
problems
in
how
we
use
the
product
and
or
and
sometimes
some
cases.
If
we
find
a
gap,
we've
been
able
to
come
to
consent,
consensus
on
how
to
fix
it
in
the
product,
and
we
then
we
send
that
back
as
a
pr
and
it
gets
approved
and
becomes
part
of
the
product.
A
A
A
B
C
There
are
a
lot
maria,
yes,
I'm
gonna.
I
can
go
to
like
the
very
very
first
one.
Yes,
so
the
like
one
of
the
very
very
first
questions
was
from,
I
believe
it
was
from.
I
was
gonna,
say
it's
from
the
show,
but
actually
no
pratima
yeah.
It
was
from
prashant
michelle
asked.
How
can
I
manage
multiple
clusters
with
single
in
still
service
mesh.
C
A
Yeah,
so
you
know
the
way
we
if
I
understand
the
question
correctly,
the
way
we
run
istio
we
have.
There
is
a
primary
cluster
where
the
control
plane
runs
and
any
of
the
the
config
hook,
et
cetera
the
things
that
I
talked
about
run
and
then
we
can,
you
can
configure
and
then
you
have.
Let's
say
you
have
a
remote
cluster
right
and
that
you
want
to
make
it
part
of
the
same
mesh.
A
A
C
Thanks
for
tima
vishal,
I
hope
that
answers
your
question.
If
not
you
can
come
off
of,
you
can
raise
your
hand
and
come
off
the
mic
or
drop
down
a
follow-up
question
in
the
chat.
The
next
question
is
from
chris
kim
and
oh
before
I
ask
the
question.
I
just
want
to
remind
everyone
who
is
participating
right
now.
If
you
would
like
to
be
considered
in
the
istio
swag
campaign,
please
fill
out
the
google
form.
C
A
A
There
are
different
working
groups
for
based
on
the
different
areas
of
of
the
product
and
you
as
a
community
member,
can
participate
in
any
of
those
working
groups
as
you
as
you
feel,
as
based
on
what
you
need,
and
then
there
is
a
doc
related
to
how
you
can
actually
send
prs
in
order
to
send
prs.
You
don't
actually
necessarily
have
to
be
part
of
those
working
groups.
You
can
based
on
your
requirements.
A
C
B
A
B
A
A
Yeah
or
wc.com
yeah
yeah
yeah,
so
we
will
be
using
it,
so
we
are
trying
it
out
in
our
test
environments,
and
we
see
that
it
will
definitely
help
us
get
rid
of
some
of
the
you
know
the
zookeeper
and
the
sync
service
that
we
have
so
yeah.
I
definitely
encourage
you
to
try
it
out
it
it.
We
we've
tried
it
out
in
our
test
environments,
it
works.
We
haven't
rolled
it
out
as
yet
and
we
are
definitely
going
to
use
it.
A
In
fact,
that
was
one
of
our
feedbacks
as
we
were
first
starting
off
to
use
istio.
The
fact
that
you
know
it
had
very
little
support
for
vms
and
bare
metal
was
was
was
one
of
the
feedbacks
that
we
that
we
gave
and
and
then
since
then,
and
there's
a
lot
of
work
that
has
been
done
for
vm
support
and
this
auto
registration
is
just
an
awesome
way.
A
C
D
Sorry,
I'm
nervous.
I
have
one
question
regarding
as
far
as
so
I
think
you
have
your
presentation
and
we
filter,
and
I
have
one
question
regarding
it
so
I'll
try
to
to
simplify
it
as
much
as
possible
regarding
hot
tepe
filter
can
we
use
a
hot
tip
filter
to
forward,
let's
say
all
hot
tip
requests
from
istio
ingress
to
some
like
odd
audit
api.
D
A
Log
service
and
ram-
if
I'm
am
I
describing
it
correctly,
we
don't
actually
use
it
yet,
but
there
is
an
access
log
api
that
you
can
use
to
to
send
those
requests
of
sends
part
of
the
data
to
a
a
service
that
that
you
run,
but
it
has,
I
think
it
has
to
implement
a
certain
api.
We
can
try
to
look
for
the
documentation
and
send
it
to
you
later,
but
there
is
a
way
you
could
do
that.
D
B
A
Like
I
mentioned
before,
you
know
we
with
running
those
proxies
between
you
know
when
you
route
the
traffic
via
the
proxy
on
the
client
side
and
then
the
proxy
on
the
server
side.
We
expect
a
two
millisecond
latency.
We
have
seen
that.
But
beyond
that
you
know
we
haven't
seen
any
other
issues
with
latency.
A
A
We've
also
added
a
discovery,
selectors
feature
where,
if
you
have,
let's
say
a
kubernetes
cluster
and
only
you
know
like
five
namespaces
out
of
that
are,
or
only
these
set
of
objects
are
really
mesh
services.
You
can
use
the
discovery
selectors
to
scope
it
down
to
just
those
so
so
they're.
The
the
two
ways
that
you
can
do
that.
B
A
Yeah
so
we
have
like
I
mentioned,
we
use
an
internal
ca,
so
that
is
what
manages
everything
for
us.
So
if,
even
across
multiple
clusters,
we
actually
use
a
in
separate
internal
ca.
That
is
what
manages
the
trust
for
us.
We
don't
use.
We
don't
use
citadel
because
that
runs
in
one
cluster,
but
our
our
infrastructure,
for
you
know
for
for
pki
kind
of
takes
care
of
that.
B
E
E
F
A
A
That's
part
of
our
sort
of
the
flow,
and
there
was
a
point-
and
you
know
there
is
a
way
to
turn
that
off
with
istio,
because
in
our
in
summer
for
yeah,
I
have
to
get
back
to
you
on
the
details,
but
there
is
a
way
you
can
turn
it
off.
Essentially,
you
can
remove
the
istio
authentication,
the
thing
that
kicks
off
that
those
extra
checks
that
you
talked
about.
A
A
F
F
A
So,
in
our
case,
you
know
we
we
picked
enroy
as
our
proxy
technology
because
it
really
suits
our
needs.
There
are
other
control
planes
available
that
are
not
sdo,
but
they
don't
have
the
features.
I
think,
for
example,
for
example-
I
mean
I
don't
I
can't
say
enough
about
those,
because
it's
been
a
while,
since
we
picked
istio
and
we
haven't
looked
at
some
of
those
products
in
more
recent
times.
So
I
don't
want
to
answer
that
question
because
I
don't
know
where
they
are,
and
I
don't
want
to.
A
A
B
Okay,
we
have
a
few
more
questions
and
I
I
just
wanted
to
remind
everybody
if
you
are
looking
forward
to
connecting
afterwards,
please
make
sure
to
join
the
istio
slack
space
and
that's
an
easy
way
to
to
find
a
pratima
and
other
student
committee
members
to
to
continue
the
conversation
about
using
histone
production.
I
can.
I
can
share
the
link
to
the
slack
space
in
a
in
a
minute,
but
otherwise
it's
on
the
website.
Istio.Io
from
this
is
from
senghei
marusi.
A
We
look
at
latency
and
request
rate
error
rates,
but
from
performance
perspective,
it's
throughput
and
latency
that
we
that
we
have
looked
at
and
this
goes
beyond.
Like
you
know,
we
are,
we
have
a
separate
performance
engineering
team
that
runs
performance
loads.
So
I
don't
have
you
know
information
about
what
types
of
tools
they
use
but
yeah.
We
have
a
team
that
runs
these
performance
loads
to
to
to
test
with
respect
to
performance,
but
the
telemetry
that
we
use
is
is
always
telemetry
right.
A
I
saw
someone
ask
about,
I
think
message,
queue
and
caching
and
whether
we
run
this,
you
know
issue
and
onward.
For
that.
Yes,
we
we
run,
you
know
we
run.
We
have
redis
that
uses
envoy
and
essentially
service
mesh,
it's
onboarded
onto
mesh
and
it's
exposed
via
sdo.
We
also
use
cupid
in
our
internal
deployments
and
cupid
is
also
it
uses
more
tcp
style
communication
between
the
client
and
server
also
onboarded
onto
service
mesh.
B
A
We,
if
you
are
you
talking
about
like
for
mobile
or
maybe
if
you
can
clarify
well
what
type
of
what
what
you
mean,
but
we
we
mostly
use
service
mesh
internally,
where
you
know
for
internal
communication,
are
if
you're.
If
your
question
is
related
to
mobile,
we
don't
use
mesh
there.
We
do
use
it
at
the
ingress,
so
any
traffic,
that's
coming
in
from
the
public
internet
flows
through
ingress
gateway,
which
is
essentially
a
steel,
ingress
gateway.
C
A
A
No,
some
of
our
services
actually
don't
use
istio
as
in
like
as
in
they
don't
use
envoy
either
they
let's
say,
for
example,
there
might
be
a
service
that
does
its
own
mtls
termination
and
validation.
So
we
on
board
them
using
this
service
entry
crd
so
that
the
clients
that
are
running
on
mesh
can
still
communicate
with
it
so
yeah.
C
A
A
We
I
mean
I
would
love
to,
and-
and
I
know
that
you
know
so-
rama
who's
who
is
from
salesforce
is
a
very
active
member
of
of
the
istio
community
and
actually
the
only
community,
and
he
spends
you
know
like.
There
are
some
people
who
spend
personal
time
as
well
to
contribute
absolutely,
but
from
a
company
perspective
we
we
solve
for
business,
use
cases
of
sales
force,
and,
and
that
is
what
drives
our
contributions
to
the
product
and
even
for
future
like
like.