►
From YouTube: Istio Networking WG meeting - 2019-06-20
Description
- ServiceEntry resolution
- Envoy listener split and how it can help with traffic to the same POD IP
- NF Tables as alternative to IPTables
- Envoy filters and patching
A
Okay,
hi
everybody
welcome
to
this
unit
working
work
group
community
meeting.
Today
we
will
try
to
do
a
few
things.
First
of
all
get
some
resolution
on
the
service
entries
discussion
we
had
last
week.
There
is
a
document,
there's
been
comment,
so
John
will
give
us
a
short
overview
of
the
situation
and
also
discuss
the
open
items.
Next
there
be
funny
little
balancing
so
I'm,
not
sure
who
added
this,
but
hopefully
sorry.
A
He
also
okay,
okay,
John,
so
sure
we'll
discuss
about
that
as
well,
and
then
Andrew
will
talk
about
the
my
additional
split
and
some
issues
related
to
that.
We
have
quite
a
bit
of
quite
a
few
items
on
the
agenda.
Okay
and
there
is
a
proposal
I
see
and
that
poses
a
better,
not
alternative
to
IP
tables.
I
can
not
sure
when
did
this.
Please
add
your
names.
It
makes
it
easier
to
handover.
A
B
Yeah,
so
for
the
service
center
resolution,
quick
summary
for
those
who
haven't,
read
the
doc
or
forgot
about
it.
Basically,
the
problem
is
with
kubernetes.
Host
names
are
unique
across
name
states,
because
the
name
space
is
part
of
the
host
name,
so
you'd
have
like
fou
default.
That's
a
risk
cluster,
local
whatever,
but
with
service
entries,
you
can
define
a
host
name
like
google
calm
and
it's
scoped
to
a
namespace
that
the
service
entry
was
created
them,
and
so
this
opens
up
the
problem
of
having
multiple
the
same
host,
name
rather
prudent.
B
Right
so
like
so
two
names
faces
to
define
a
google
calm
and
all
of
pilot
code
are,
is
mostly
keyed
off
of
host
name.
So
we
assume
that
names
are
unique
and
this
runs
into
all
sorts
of
problems.
For
example,
telemetry
it
has
the
source
name
space.
It
will
just
pick
an
arbitrary
name
space
that
has
that
host
name
in
it,
there's
other
ones
where
they
get
like
the
instances
of
a
service,
and
it
will
pull
from
all
of
the
name
spaces,
which
is
usually
not
what
people
want.
B
And
so,
if
you
had
google
comm
to
find
in
namespace
a
a
namespace
b,
you
could
have
pods
that
see
the
google.com
and
a
and
pod
to
see
the
google.com
and
b.
But
you
would
never
have
a
pod
that
will
either
arbitrarily
choose
between
one
of
them
or
get
both
instances
of
this
and
which
one
it
gets
is
determined
by
the
sidecar
scope.
It's.
D
D
B
Yeah,
so
the
the
prom,
though,
is
the
virtual
services
just
defining
the
actual
routing,
and
so
that
virtual
service
has
a
namespace,
but
the
name
space
is
not
really
exposed
in
the
actual
Envoy
in
there
right
with
the
service
anchors,
it's
different.
We
have
a
telemetry
uses
the
namespace,
the
clusters
endpoints
us,
it's
a
like
if
you
have
a
completely
new
space,
so
for.
C
What
nice
thing
is
that
only
if
you
have
virtual
services,
destination,
dude
and
so
on,
yeah
I
start
conflict,
then
it
will
only
import
from
the
namespaces
that
you
actually
specify.
And
if
you
don't
it's
a
very
name
place
then
the
you
know,
the
conflict
resolution
is
undefined
in
some
sense
for
virtual
services.
Basically,
we
just
say
like
some
things
might
crash
and
we
don't
actually
give
a
guarantee
and
for
destination
boots.
We
have
a
certain
specific
pattern
that
resolve,
but
for
service
entry
for
external
services
alone,
and
that's
when
coping
it
for
service
entries.
C
Traditionally,
you've
only
said
you
can
only
have
one
service
entry
for
that
little
bit
personal
to
the
entire
mesh.
There
is
external
or
internal,
and
what
a
few
of
these
customers
wanted
is
unlike
didn't
want
just
like
the
way
we
can
specify
destination
boots,
drive
it
to
a
mainstream
or
virtual
service,
or
a
private
or
namespace.
You
would
like
to
specify
for
the
ten
things
that
are
private
to
a
namespace,
where
only
that
sidecar
can
actually
use
it
and
it
will
not
get.
F
C
But
that
has
always
been
the
case
right.
The
beam
not
Navdeep
always
said
that
they
will
not
do
merging
for
virtual
services
from
different
namespaces
for
a
site
card.
So
do
you
have
to
use
a
sidecar
CRD
to
import
the
right
virtual
service
and
make
sure
you
only
import
one?
If
you
import
multiple,
then
it's
is
that
gonna
be
undefined
behavior.
C
So
I
would
say,
however,
that
we
just
simply
stick
with
the
same
behavior
as
your
choice,
all
this
for
consistency
and
we
simply
say,
like
an
users
like
ours,
the
idea
to
import
a
single
service
entry.
If
you
import
multiple,
we
will
just
leave
the
behavior
to
be
undefined,
which,
rather
than
having
a
specific
resolution
behavior-
and
we
want
to
scope
it
down
to
the
point
of
saying
that
this
whole
service
entry,
multiple
service
and
drinking,
you
can
only
guarantee
correct
working
for
external
services.
C
C
C
Then,
a
simple
example
is,
if
you
like,
even
at
IBM,
if
you
are
just
talking
into
like-
let's
say
you
know
the
logging
server
to
talking
to
DB
service
and
if
somebody
is
playing
with
with
their
application
a
specific
namespace
and
they
don't
actually
want
to
go
talk
to
the
entire
login
service,
but
they
have
a
mock
version
of
a
login
service.
The
clad
and
specified
and
running
in
a
simple
Marc
application
or
mock
service
in
that
name
will
face
like
they
don't
want
to
modify
that
existing.
C
Let's
say
big
Java
code
base,
which
is
actually
designed
to
directly
call
that
logging
service
right,
but
when
they
actually,
they
can
add
a
local
service
entry
effectively
like
a
proxy.
That
says,
then
call
noggin
further
leave
out
to
this.
You
know
local
dummy,
often
for
my
own
being,
and
so
there
is
a
definite
development
level
like
you
know,
utility.
C
What
that
we
can
actually
make
that,
for
example,
if
they
go
to
staging
environment-
and
they
still
want
to
point
to
a
local
staging
version
of
a
particular
things,
and
then
they
want
to
take
the
exact
same
unmodified
code
and
deploy
it
in
production
and
let
it
actually
call
the
actual
DNS
name
that
specified
inside
that
code,
then
it
actually
becomes
much
it.
This
facility
would
actually
be
very
helpful
pretty
much
what
virtual
services
help
you
to
date.
D
So
I
think
it's
a
good
to
have
consistency
I'm
if
we
I
understand
sure
and
what
you're
saying
I
think
we
might
be
thinking
same
see
so
I'm
thinking
if
I'm
having
if
I,
enable
my
global
cycle,
then
so
so,
let's
say
for
1.2
for
the
default
behavior,
which
is
everything
is
globally.
All
the
configurations
are
push.
So
in
that
case,
if
I
have
maybe
multiple
services
in
different
namespace
that
needs
to
refer
to
the
same
login
service
or
Google
services,
then
oh,
it's.
B
One
of
the
main
drivers
for
this
is:
we
have
users
that
have
really
big
clusters,
where
teams
are
separated
out,
the
name,
states,
boundary
and
there's
basically
a
zero
trust
situation
where
one
namespace,
assuming
it's
not
important,
psycho
research
should
not
be
able
to
impact
other
namespaces
and
today
this
is
almost
true,
except
for
this
case,
and
there
may
be
some
small
other
cases,
but
this
is
the
name
on
that
I'm,
aware
of
that
they
can
kind
of
hijack
your
host
name
and
redirect
your
traffic
somewhere
else
with
us
ever
since.
So.
F
C
F
D
It's
okay,
I'm
with
Niraj
I,
actually
misunderstood!
You
are
John
at
the
beginning.
I
thought
you
meant
you
want
to
make
an
exception
for
service
entry,
so
even
without
global
cycle
scope
you
want
to
do
something
special
for
service
entry,
which
I
had
a
little
hard
time,
because
I
think
it's
very
hard
to
explain
to
user.
Oh
I.
B
C
Leave
it
as
undefined
for
the
case
where
there
is
no
sidecar,
let
it
be
like
you
know,
Pelletier,
where
things
call
it
while
just
like
what
we
do
it
for
virtual
service
destination
would
so
on,
but
when
a
sidecar
is
defined,
we
provide
the
proper
isolation.
I
mean
the
isolation
as
like
you
know.
You
kind
of
I
cut
leave
for
a
namespace.
Only
that
namespace
a
service
entry
will
definition
see
and
nobody
else's
service
entry
definitions.
The
important
thing
if.
C
F
I
would
add
if
we
are
changing
the
default
behavior
when
we
have
no
sidecar.
We
should
make
it
consistent
across
the
board
when
you
on
just
have
a
resolution
logic
for
service
and
case,
because
I
I
appreciate
the
effort
John
that
you're
trying
to
make
it
simple,
but
as
a
user
I
will
have
two
different
cases.
That
I
will
have
to
think
about
right.
Yeah.
C
That's
why
I
mean
that,
like
keep
it
same
as
undefined
the
behavior
for
virtual
services
and
service
entries
just
like
today,
all
right,
you
have
a
sidecar.
Let's
make
sure
that
this
bug
is
fixed
in
some
way,
which
is
that
when
you
import
a
service
entry
from
one
namespace,
you
only
import
that
service
entry.
In
other
words,
that's
trees,
endpoints
and
nobody
else
can
interfere
by
declaring
a
similar
service
and
doing
somewhere
else.
But.
C
Don't
have
it,
we
have
not
enabled
it
today
or
default
installation,
because
the
reason
is
because
Helen
does
not
allow
you
to
create
that
globally,
global
config
namespace
the
history
of
config.
It
only
allows
you
to
create
only
one
single
namespace,
which
is
a
co
system,
but
we
need
the
sidecar
CRD
to
be
in
a
special
configuring
space
called
with
your
config,
which
is
where
you
would
specify
this.
The
default
sidecar
thing
and
helm.
Doesn't
let
you
do
the
two
names
through
this
thing,
but
if
you
manage
yeah
I,
don't
know
why.
But
it's
yeah.
C
A
D
C
They
can
do
that.
Actually,
yes,
I,
and
if
they
do
that,
then
yes,
then
they
have
done
on
the
site
card
for
everybody,
and
then
people
can
go
and
override
that
fight
card
in
their
namespace,
by
declaring
special
stuff
and
I
would
say
as
part
of
the
validation.
You
should
probably
add
that
we
will
just
disallow
star
slash
time
or
if
you
just
I'll,
have
to
ask
lash
tagging,
which
is
a
fan
of
use
of
no
sidecar.
G
C
A
D
A
B
A
And
as
long
as
we
target
of
solution
where
this
site
that
would
be
configured
by
default
during
the
installation,
then
they
won't
need
to
do
additional
configs
right.
If
we
can
like
yes,
we
will
ask
that,
but
once
the
Installer
is
ready,
that's
going
to
be
in
1
3
or
it
is
already
ready,
but
not
everybody
uses
it.
C
You
could
I
change
a
documentation
to
say,
like
you
know,
that
first
step
toward
chased
you
install
is
to
enable
the
sidecar
peoples
and
actively
educate
people
that
they
should
explicitly
declare
dependencies
on
other
namespaces.
So
that,
like
you
know,
by
default,
you'd
only
get
namespace
local
access
only
and
then
you
can
X,
basically
our
other
namespaces
to
your
system
who
correct
for
white,
which
would
be
a
which
would
actually
make
it
easy.
Even
though
we
don't
mandate
default
installed.
C
A
E
If
it
goes
through,
only
the
inbound
listener-
and
you
have
you
know,
require
em
TLS
turned
on
it,
doesn't
work,
and
so
that
that's
sort
of
the
fundamental
issue,
this
twelve
five,
five
one
and
so
there's
kind
of
two
ways
to
fix
it.
One
is,
if
you
talk
to
yourself,
you
get
to
short-circuit
all
SEO
palsy,
telemetry,
everything.
If
you
talk
to
yourself
in
your
external
IP,
why
the
other
option
would
be
to
go
through
both
listeners.
One.
C
E
Yeah
so
I
flew
back
yep
yep,
so
so
literally
one
two
seven
zero,
zero
one
skipped
all
of
this
and
talks
to
itself.
If
you
talk
to
your
own
odd
IP,
you
go
through
the
IP
table
as
you
get
to
envoy,
but
you
only
go
through
one
of
those.
That's
what
the
the
breakage
is.
So
you
can
fix
it
either
way.
We
talked
about
it
a
couple
months
ago
and
didn't
really
decide
on
what
fix
it,
but
the
this
PR
13
666.
E
It
looks
to
me
like
the
beginning
of
stuff
in
IP
tables,
to
split
so
that
envoy
could
correctly
differentiate
inbound
traffic
from
outbound
traffic.
So
if
it's
an
outbound
connection
to
its
own
IP,
it
could
potentially
run
it
through
both
listeners.
But
the
thing
is
that,
well
it
does
the
IP
table
stuff.
It
didn't
look
to
me
like
it
did
the
Envoy
side
of
things,
but
I
don't
know
that's
actually
the
goal
or
not.
It's.
C
Because
if
we
had
the
ability,
the
thing
is,
the
target
IP
address
in
the
pods
own
IP
address
might
be
tables,
then
the
I
mean
they
could
have
burnt
even
with
a
single
virtual.
It's
not
but
I,
don't
think
we
have
that
ability,
station
room,
so
I
took
things
point
I
like
the
we
have
this.
What
about
the
like
gate
inside
the
IQ
table
thing
that
says
all
traffic
for
loopback
address
will
just
be
like
ignored
no
capture
and
no
envoy.
C
We
don't
have
a
thing
either
the
rule
that
says
all
traffic
to
the
sports
IP
address
a
specific,
a
dot,
B
dot,
C
dot
d
IP
address
should
not
be
captured
from
within
the
pod,
and
the
reason
is
because
we
don't
know
that
IP
address
a
priori,
maybe
mean
maybe
we
could
do
some
parameterization
and
know
that
address
a
priori,
in
which
case
then
a
cast
apart
calls
itself
that
traffic
will
probably
just
not
getting
to
accept.
Also,
it
still
goes.
One.
A
Day
so
when
we,
when
you
refer
love
to
your
localhost,
yes,
you
can
bypass.
But
when
you
refer
to
your
quad
IP,
you
still
want
to
go
through
the
outbound
and
inbound
to
get
all
the
telemetry
and
all
the
things
right,
because
you
may
want
to
be
able
to
have
metrics
on
the
calls
you
made
to
yourself
as
well.
Right,
I.
Think
this
like
this.
This
listener
space
will
definitely
help
right,
but
I'm
not
sure
if
anybody
has
implant
to
test
this
exact
test
case,
because
there
might
be
like
a
few
other
tweaks
needed
question.
C
C
We
are
that
we
can
fix
the
fit
as
long
as
is
looping
within
the
network
main
space
of
the
pot.
Then
there's
a
way
in
Hanoi
to
fix
that
then
in
Mattson
condition
that
says
that
if
the
traffic
is
originating
from
the
local
IP
address,
then
I
mean
or
if
the
traffic
is
origin,
anything
from
a
remote
IP
address.
C
There
is
a
matching
condition
in
nan
way
and
we
can
actually
argument
the
PR
that
you
Chen
had
by
adding
this
matching
condition
such
that
it
would
satisfy
your
use
case
where,
when
a
pod
calls
itself
using
his
IP
address,
we
can
ensure
that
it
does
not
go
through
the
MPLS
thing.
It
would
go
directly,
it
will
go,
it
will
just
be
a
pass
through.
In
that
sense,
I.
C
You
know
just
not
go
through
a
MPLS
filter.
Today
we
have
a
filter
chain
match
which
basically
says
for
all
traffic.
That's
entering
the
pod
subject
is
the
MPLS
with
some
sniffing
and
all
the
other
stuff,
but
we
can
actually
add
a
second
match
condition
that
says
for
all
traffic.
That's
entering
the
pod
and
if
this
traffic
is
coming
from,
an
external
IP
address
then
subjected
to
a
MPLS.
But
if
it's
coming
from
an
internal
basically
low
for
like
MD
lesson,
go
directly,
I
mean
skip
TMDLs
and
you
know
do
the
rest
of
it.
E
Think
that
that
that
is
compatible
with
this
use
case
for
sure,
if
I
think
about
it
as
a
like
a
from
a
like
outside
user
perspective,
what
I
want
to
feel
like
is
it's
as
if
it
went
through
the
outbound
and
then
the
inbound
for
all
policy.
Now,
if
internally,
you
can
short-circuit
it
by
not
actually
doing
em
TLS,
that's
cool
with
me,
but
from
like
the
perspective
of
all
policy,
you
know
virtual
services
telemetry
everything
I
want
it
to
feel
like.
C
No
thing
is
affecting
this,
and
only
if
that
traffic
loops
within
the
same
network
namespace,
because
the
moment
that
traffic
come
goes
out
of
the
network,
namespace
and
then
comes
back
into
envoy
me
I
think
it
loses
the
ability
to
distinguish
where
the
car
I
mean
and
at
that
point
could
creep.
That
quest
as
though
it's
coming
from
an
external
source.
Well,.
E
A
C
A
problem
that
saves
this
may
be
hard
part.
We
felt
more
again
be
less
than
the
team
breaks.
I
just
column
that
he
has
a
the
Kafka
problem
is
that
when
Kafka
calls
itself
using
his
IP
address
and
that
part
that
traffic
all
comes
back
in
to
unwind
on
way
like
expect
empty,
less
the
whole
pashka
thing
break,
because
you
know
it
should
not
be
subject
to
calculus,
because
I'm
to
me
calling
myself
using
IP
address
right.
E
C
E
E
A
So
under
I
had
a
look
at
the
what
the
issue
you
are
pointing
to
headless
services
both
face
and
ellas
handshake
with
itself.
So
if
we
want
to
solve
this,
we
should
have
an
issue-
that's
less
related
to
headless
services
right
because
it's
related
to
them.
You
know
apart
talking
to
itself,
so
maybe
you
want
to
open
a
more
like
general
issue
and
decoupled
it
from
the
whole
headless.
So
people
can
add
that
specific
to
the
issue
as
opposed
to
trying
to
get
this
to
work
with
headless.
E
I
J
E
It
sounds
like
I
am
going
to
open
an
issue
to
explore
what
how
we
should
implement
what
happens
when
a
pod,
any
pod
tries
to
talk
to
its
own
external,
like
pod,
IP,
address
and
I'll
talk
about
what
we
talking
about
here
and
people
can
chime
in
if
they
have
different.
You
know
different
ideas
by
the
way.
E
C
Thank
you,
I
know
is
that
the
inborn
listeners
that
needs
to
be
a
global
configuration
today.
It's
actually
a
third
odd
configuration
through
an
arbitrary
environment
variable,
and
it
does
not.
If
there's
no
consistency
with
the
fact
that
we
in
a
global
configuration,
we
actually
have
a
proxy
listener
port.
C
As
a
configurable
T
in
the
mesh
global
configuration
maintain
that
consistency,
we
should
have
a
similar
global
configuration
that
says
proxy
in
boundless
reports,
so
that
people
can
actually
enable
it
twelve
the
mesh
and
not
have
to
go
on
instrument
each
and
every
site
card
to
add
this
additional
environment
variable.
That
would
just
not
be
a
scalable
approach
so
and
we
decided
to
like
add
things
to
the
mesh
global
thing
because
they
are
gonna
move
the
new
installer.
C
Mean
if
this
new
case
for
cough
can
kind
of
things
might
have
to
go
global
config.
You
do
not
have
a
one-off
thing,
because
a
default
is
to
installation
will
immediately
break
for
headless
services.
Then
it
the
it's
not
nice
to
then
go
and
tell
like
make
people
come
and
file
an
issue,
and
then
we
tell
people
that,
please
add
this.
You
know
obscure
environment
variable
to
that
Casca
pod
and
then
they
go
out
and
it
fixes
it.
That
is
not
a
nice
user
experience
from
user
experience
monarch.
C
You
should
just
work
out
of
the
box
and
you
know
do
the
thing.
This
is
the
enable
as
a
proper
global
configuration.
Then
it
actually
makes
it
much
easier
with
the
context
of
the
Salukis
and
other
things.
The
dish
could
just
be
that
special,
not
rain,
41.3
night
no
on,
but
rather
thick,
like
you
said
now,
one
point
to
which
this
was
introduced
in
one
point
boots
or
by
one
by
the
next
release
or
the
top.
We
should
have
that
as
a
global
configuration.
C
F
C
More
I
mean
it's
one
to
listeners
instead
of
one
listener,
but
that
was
not
an
it's
to
virtual
is
nuts
instead
of
one
virtual
this
another.
It's
not
an
overhead
and
it
has
other
security
properties
as
well,
which
is
that
we
can
just
prevent
somebody
from
bouncing
via
envoy
to
a
different
IP,
because
you
can
just
guard
the
outbound
and
you
can
set
up
the
IP
table
rules
such
that
the
outbound
proxy
listen
abode
will
only
capture
traffic
for
outbound
traffic
and
not
inbound
traffic.
Similarly,
you
can
again
set
up
the
IP
table.
C
A
A
And
I
wanna
add
one
thing
gum,
so
there
was
this
mention
of
going
to
the
pod
IP
and
the
headless
services.
However,
if
I
have
a
service
and
I
have
a
single
pot
I'm
the
one
implementing
that
service
and
I
talk
to
the
service
I
should
be
able
to
have
that
traffic
sent
back
to
me
with
the
same
approach
right
so
yeah.
Yes,.
E
F
A
A
G
Okay,
all
right,
so
you
probably
saw
some
email
discussion
in
the
context
of
distress
that
there
was
attempt
to
replace
current
IP
tables
implementation
in
each
container,
with
a
gulang
equivalent
and
well.
There
was
a
solution
provided
and
I
mean
in
general.
It
would
work,
but
there
are
some
disadvantages
of
current
approach.
G
Basically,
what
what
was
what
was
done
is
they
replaced,
shall
IP
table
school
with
the
equivalent
of
golang
OS
execute
commands,
so
I
mean
it's
it's
better,
but
I
mean
it's
not
ideal
or
another
disadvantage
is
that
the
way
it's
proposed
is
that
it
cannot
be
shared.
Let's
say
it
could
work
in
a
in
each
container
context,
but
let's
say
it
won't
be
usable
for
us
Easter
CNI,
because
they
packaged
it
as
a
external
binary.
G
So,
based
on
that
team,
John
and
myself,
we
had
some
discussions
and
we
were
trying
to
come
up
with
the
we
try
to
come
up
with
the
library
approach.
So
basically
the
library
which
can
be
shared
by
East
EO
in
each
container
is
th,
CNI
and
etc.
We
checked
available
libraries
and
there
was
no
good
library
for
iptables.
All
of
them
use
the
same
approach.
They
wrap
binary
and
call
it
so
pretty
much
the
same
thing,
but
in
the
newer
version
of
the
core
kernel
there
is
a
by
the
full
support
for
netfilter
tables.
C
G
K
G
G
K
L
G
H
H
M
Slow
down
on
so
the
there's
an
effort.
You
know
people
want
to
put
an
effort
to
rewrite
this
into
golang.
I
think
what
we
can
do
is
have
a
multi
option
approach.
So
if
the
you
know
the
further
for
the
to
proxy
problem,
we
could
potentially
still
leave
the
wrapping
of
IP
tables.
Client
calls
in
there
just
have
a
go
Lang
interface
that
supports
any
made
of
both
methods.
M
So
if
you
serve
those
that
want
to
have
the
full
district
and
have
tables
approach,
we
could
we
wouldn't
be
able
to
support
the
T
proxy
right
away.
So
that
would
be
a
problem,
but
they
were
the
the
current
non
UDP
functionality
would
work
right.
So
I
think
this
is
what
we're
thinking
a
librarian.
Unless
somebody
wants
to
write
out,
IP
tables
library,
I.
J
So
that
there
is
a
version
of
IP
tables
which
does
the
translation,
2nf
tables,
we
found
out
about
this
the
hard
way
because,
within
the
open,
shipped
distribution,
there
recently
changed
to
having
antenna
tables
on
the
host
and
the
relic
version
of
IP
tables.
Does
the
mapping
so
weak?
We
hear
issues
with
that
specifically
because
we
had
some
posts
which
were
running
either
on
row
7
or
were
running
on
older
versions
of
Auckland
shift,
which
would
not
support
or
were
not
natively
running
nf
tables,
and
none
of
that
would
work.
J
We
ended
up
shipping
to
init
containers
and
at
the
moment
we
have
people
choosing
which
one
they
want,
but
they
plan
for
our
next
releases
to
actually
run
both
of
them.
The
siene
plugin
that
we
have,
which
is
based
on
malta
that
works
around
that
because
that
relies
on
the
IP
tables,
that's
on
the
host
system.
So
if
you
have
the
nf
tables
variant,
it
will
translate
to
any
of
tables
right
away.
O
G
J
G
O
M
E
L
J
N
J
B
J
Yeah
yeah,
nothing,
the
IP,
I,
think
iptables
performances
impacted
more
with
what
else
is
going
on
right
yeah.
It
may
not
necessarily
be
the
unit
proxy
and
sorry
the
Annette
container
itself,
which
is
taking
the
time
it
could
be
other
things
which
are
going
on
within
IP
tables
as
well,
whereas
nf
tables
doesn't
seem
to
suffer
from
the
same
issues
so
it
handles
it
handles
the
concurrency
a
lot
better.
M
L
N
L
L
P
L
P
G
G
J
Okay,
yeah,
it's
the
whole
side
of
the
masters
of
notes.
Yeah.
The
apt
was
approached
so
we're
doing
what
has
just
been
suggested,
we're
actually
deploying
to
init
containers.
We've
got
one
which
is
based
on
IP
tables
and
we've
got
one
which
does
the
IP
tables
translations
2nf
tables.
So
when
it's
running
on
an
NF
tables
it
able
to
host,
they
can
take
advantage
of
that
so
getting
if
we
can
come
up
with
something,
especially
if
it's
a
single
deployment
single
binary
which
handles
both.
Then
that's
the
ideal
situation.
G
A
Sorry
I
was
muted,
alright,
thank
you.
So
in
fact
there
was
an
item
that
somehow
got
deleted
from
from
the
agenda,
and
there
is
there
is
some
discussion
related
to
extensive
all
the
folders
and
the
Mirage
and
revamping
they
can
fall
bit
quick
in
this
manner
so
long
which
one
of
you
wants
to
start
sure,
I'm
sure.
C
I
can
I
can
give
a
no
you
don't
know
what
the
issue
is.
I
think
we
have
the
unalloyed
filter
for
quite
a
while,
and
you
know
a
lot
of
users
of
it
and
fortunately
that
has
shielded
like
a
whole.
Bunch
of,
like
you
know,
add
this
to
one
more
add
this
to
our
close
to
you
in
the
API
you've
been
able
to
keep
the
API
low
and
same
time.
If
you
have,
you
can
get
some
filters
and
I've
added
some
improvements
to
my
filter.
C
That
could
actually
enable
people
to
not
just
add
new
filter,
but
they
can
hire
new
settings.
I
mean
like
change
settings
on
the
listener
or
the
cluster
and
so
on
because,
for
example,
we've
had
a
whole
bunch
of
requests
to
enable
the
HTTP
to
option
on
the
cluster
or
a
specific
option
on
the
HTTP
connection
manager
for
Gateway
light
x-forwarded-for
things
or
you
know
this
could
be
setting
or
making
up
from
the
timeout
setting
and
so
on.
C
And
frankly,
that
is
an
API
burden,
because
for
every
feature
that
we
had,
we
have
to
find
a
way
to
accommodate
that
one
way
or
the
other.
And
then
the
API
surface
becomes
bigger
and
bigger,
and
you
know
and
we're
trying
to
keep
that
80's
face
small
in
the
interest
of
maintaining
complexity
low,
so
what's
going
on,
and
why
they're
behind
on?
Why
filter
increment
here
is
that
Google
active
patch
mechanical,
like
that
after
we
generate
all
the
config,
you
can
specify
a
bunch
of
additional
settings
that
you
want.
C
You'd
apply
your
slipping
on
the
generators
wanting
to
avoid
the
there's,
a
very,
very
big
cabbage,
fixed,
or
that
thing
under.
That
is
that,
if
you
use
the
Envoy
filter,
it
is
a
break
glass
integration
and
we
will
not
provide
any
form
of,
like
you
know,
improve
support.
Nor
do
we
guarantee
that,
like
things
would
work,
so
it
is
completely
up
to
the
end-user
to
make
sure
that
they
change
nothing.
For
that
changing
is
the
right
one,
and
that
pilot
does
not
going
to
be
responsible
since
they're
actually
directly
editing
the
Envoy
settings.
C
This
is
the
exact
same
guarantee
that
we
had
even
before
this
PR,
because
that,
if
you
add
a
filter
on
your
on
your
crashes
and
be
not
just
multiple,
no,
what
did
you
not
think
mean?
There
is
no
way
for
us
to
go
and
debug
what
you're
doing,
because
you
know
change
the
configuration
was
pilot
as
generator
so.
F
C
F
So
other
open
source
projects
with
an
API
surface
also
achieve
the
same
functionality.
You
have
a
core
functionality
that
you
know
that
you're
not
going
to
extend
and
then
you
can
have
extension
mechanisms,
but
those
extension
mechanism
should
be
reasonably
supported.
The
extension
mechanisms
that
we
are
providing
are
just
impossible
to
support
because
dynamically
at
runtime,
without
having
organizational
controls,
you
have
multiple
filters
which
might
be
trying
to
patch
the
same
thing
or
they
might
be
trying
to
update
the
same
thing.
That's
my
concern
here.
Yeah.
C
This
is
coming
from,
like
so
many
different
users,
not
just
big
companies
like
Salesforce,
but
actually
smaller,
smaller
into
the
users,
who
have
actually
been
waiting
for
two
flat
months,
who
had
people
who
the
we
provide
features
to
the
cluster
to
add
pictures
to
it,
and
that
is
called
among
everybody
with
your
community,
especially
us
who
are
actually
writing
code
and
actually
fixing
issues
on
these
to
you
and
like
I'm,
managing
this
not
at
the
company
level,
but
actually
in
the
open-source
thing
and
to
us.
This
is
more
like
okay.
C
Here
is
a
maybe
by
which
we
can
actually
enable
you.
And
yes,
this
is
master
day,
but
you
know
over
time
we
might
actually
figure
out
the
way
to
actually
support
it,
no
more
proper
bit,
but
till
then.
This
will
at
least
unblock
other
is
to
your
doctors
that
they
can
continue.
Using
this
clear
without
creating
their
own
control
planes
or
without
hacking
it
and
going
no
even
once.
C
F
In
the
incarnation
of
this
PR,
especially
because
previously
on
what
filters
were
used
to
just
add
new
filters
and
listeners
chains
now,
this
PR
enables
users
to
patch
or
modify
on
web
configuration,
which
was
generated
by
pilot.
So
so
for
me,
it
starts
to
feel
like
there
are
three
or
four
layers
of
transformations
that
can
happen
after
actually,
Co
control
client
is
giving
something
so
the
space
of
configuration
that
you
have
to
look
for
a
person
to
understand
what
is
actually
going
to
be
delivered
to
envoy
is
really
large.
C
That
has
been
a
thorn
because
people
have
burns
and
war
filters
and
like
in
a
dude
and
wrong-way
crash
on
voice
completely.
And
but
people
are
okay
with
it
saying
that
I
will,
you
know,
make
my
way
with
it
and
do
it
because
they
want
95
percent
of
configuration,
that
flows
and
from
pilot.
And
then
you
wanna,
tweak
one
or
two
different
things:
I.
A
Don't
see
a
problem
specifically
with
the
fact
that
we
are
the
extension
you
can
patch
or
like
modify
the
existing
of
things
right
and
if
there
are
use
cases
that
require
that
I
I
see
no
reason
for
saying
you
know
no.
No
to
this
behavior
I
mean
it
also
seems
limiting
to
allow
just
the
ability
to
add
stuff.
A
F
Think,
that's
that's
a
fair
point
for
me.
The
only
issue
that
has
been
happening
is
so
going
forward
whenever
we
have
to
augment
virtual
services
or
gateways,
because
we
haven't
defined
what
our
core
API
is.
Are
you
can
always
say:
okay,
let's
not
Ottoman,
tower
primary
API
but
use
the
Envoy
filter
patching
mechanism.
That's.
C
Not
the
case
at
the
first,
our
law
so
far
has
been
if
ten
people
actually
use,
devious,
additional
filter
to
add
a
custom
setting
or
ten
people
are
adding
a
special
merit.
Eight
at
every
sidecar
example
the
same
or
the
fashion
as
in
boundless
not,
then
that
has
become
a
global
configuration
or
that
has
to
become
a
part
of
the
core
API.
But
as
long
as
that
number
is
like
in
a
few
people
who
are
just
doing
it
here
and
there,
then
that
is
like
supposed
to
be.
C
Like
you
know
you
just
do
it
that's
a
one-off
thing,
but
don't
actually
becomes
much
more
widespread
and
well
used.
Then
it
should
not
be
in
the
annual
quantification
will
actually
like
it
have
a
proper
setting
on
the
API
to
do
it.
So
the
point
here
that
the
three
users
who
wanted
some
export
for
setting
and
one
one
person
wanted
to
change
all
the
default
path
for
all
these
certificates
at
while
it
was
configuring
and
whole
bunch
of
things,
and
all
of
these
things
can
actually
be
like
you
know.
C
This
is
one
person's
requirement
and
the
another
person's
requirement-
and
all
of
these
together,
we'll
just
add,
go
to
the
API
that
we
have
no
data
on
entire
world.
You
think
a
knowledge
of
one
person
that,
and
we
have
a
sequence
on
github
issue
at
least
I
want
this
I
want
this
I
want
this
and
they
are
always
gonna
go
and
add
new
setting.
This
is
how
we've
been
adding
settings
to
watch.
C
F
C
No
I
am
man
I
personally,
don't
have
that
thing
it.
This
is
more
like.
There
are
people
who
just
want
one
off
and
when
that
one
off
becomes
most
common
case,
they
will
push
it
into
the
main
configuration
absorb
it,
no
matter
what
changes
it
requires,
because
that
one
has
to
help
thing
to
do
in
terms
of
you
know,
keeping
the
amount
of
like
a
class
room
anymore.
A
Okay,
so
IIIi
think
that
makes
sense.
No
rush
to
you.
Would
you
agree?
Yes,
it
doesn't
I
just
wanted
to
get
a
consensus
on
that,
so
I'm,
good.
Okay,
thank
you.
Thank
you.
So
we're
all
out
of
time,
so
I
will
defer
to
next
in
the
locality.
Lbph
items
that
item
that's
John,
I
did
and
I
want
to
ask
something
on
July
the
course
or
not.