►
From YouTube: Istio Environments Meeting 2021-09-01
Description
Istio Environments Meeting 2021-09-01
A
A
So
as
some
background,
basically,
we
have
a
bunch
of
controllers
that
only
one
sdod
revision
or
actually
not
not
even
revision.
Only
one
sqo
d
replica
should
run,
for
example
like
when
we
patch
web
hooks
updating,
ingress
status
and
other
stuff.
We
actually
only
want
one
instance
to
be
doing
those
things,
so
the
idea
is
we
just
added
this
idea
of
the
default
revision,
which
is
like
the
user,
designating
a
revision
as
kind
of
the
primary
revision
in
use.
A
A
The
designs
so
john
has
actually
added,
I
think,
in
anticipation
of
needing
something
like
this
some
work
into
kubernetes
to
so
right
now
in
kubernetes,
the
leader
election
is
kind
of
it.
Wouldn't
let
us
do
this
prioritized
it.
Wouldn't.
Let
us
do
this
thing
where
we
need
to
kick
out
an
old
leader
and
you
know
usurp
them
based
on
our
priority.
A
So
there's
some
changes
that
john
has
opened
into
kubernetes
that
make
it
so
that
you
can
have
different
leader
election
clients
have
a
different
priority,
so
they
can
boot
out
existing
leaders.
It's
looking
unlikely
that
that
logic
will
get
merged
soon.
I
don't
necessarily
know
when
that
would
make
it
in,
but
the
idea
here
is
that
we
could
just
fork
the
the
altered
leader
election
library
into
istio
temporarily
yeah,
so
go.
B
A
D
Go
ahead,
yeah
with
stamp
set,
and
also
we
don't
want
the
logic
to
be
as
simple
as
if
I'm
not
the
default,
one
don't
take
the
leader
election
lock,
because
if
you
end
up
with
no
default
or
all
the
default
pods
are
down,
then
you
may
have
an
outage
right.
I
think
we
want
the
default
to
be
priority,
but
not
only
if
that
makes
sense.
Well,.
B
B
And,
and
and
and
again
knowing
if
you
are
default
or
not,
is
important
for
other
reasons
I
mean
having
the
functionality
to
know
you
are
default
or
not
that
that's
useful
in
general,
and
once
you
know
you
know
you
just
reading
question
and
we
have.
I
think
there
is
an
api
to
to
stop
being
the
master
I
mean
to
to
to
drop
the
master
ship.
B
B
A
A
B
Why
complicate
things
when
we
can
say
just
you?
You
always
have
a
default
revision
that
is
responsible
for
patching
web
hooks
and
doing
status
and
all
the
other
stuff,
because
otherwise
it's
it's
again
very
complicated
know,
which
one
is
I
mean
by
by
the
one
who
owns
who
who
wins
the
mastership
election
is
that
is
becoming
the
default
so
because
it's
the
one
updating,
status
and
and
configs
and
other
stuff.
So
what's.
B
What's
the
benefit
of
making,
this
is
more
complicated
than
just
saying
that
there
is
always
one
default.
That
is,
you
know
responsible
for
the
for
the
controllers
for
some
and
its
master,
and
that's
it
I
mean
no
more
hard
to
debug
figure
out,
which
one
is
that
now
the
master
revision,
one
revision,
two
division,
three,
because
then
you
have
priorities,
you
need.
You
have
a
very
complicated
system
in
place.
When
you
can,
you
already
have
default,
which
solves
this
problem.
A
A
B
So,
to
be
clear,
I
mean
my
concern
is
the
primary
concern
is
that
the
intent
for
default
is
to
have
you
know
almost
all
production
workloads
to
use
default,
because
that's
really
what
production
is
using
and
that's,
and
for
the
other
revisions
to
be
used
for
upgrade
or
for
you
know,
experiments
or
whatever
else,
but
we
want
users
to
have
a
deterministic
behavior.
I
mean
to
know
always
that
the
stable
versions
are
the
default.
One
is
used
consistently
in
order
to
debug.
If
there
is
a
problem,
they
know
where
to
look.
A
Okay,
no,
that
makes
sense
that
makes
sense
I'll,
also
look
in
so
to
make
sure
that
what
we're
even
describing
now
with
only
having
the
default
able
to
claim
it,
I
think,
that's
possible
with
the
current
implementation,
but
it
might
be
cleaner,
it'd
pretty
much
definitely
be
cleaner
still
in
terms
of
like
how
it's
implemented
to
fork
that
code
over,
but
that
obviously
has
a
pretty
tremendous
cost.
So,
okay
I'll
look
back
into
that
yeah!
That's
everything
for
that
proposal.
B
Or
we
can,
we
can
separate
the
feature
definition
when
and
then
the
requirements
which
are
you
know
you
need
to
have.
You
know,
prioritized
leader
election
from
implementation,
which
may
change
is
not
necessarily
that
way
we
have
both.
All
the
you
know,
implementation
details
in
in
the
same
document
I
mean
okay,
the
feature
which
is
leader
election
to
be
to
be
done
by
default,
but.
D
Yeah,
I
definitely
agree.
The
high
level
idea
is
something
that
we
have
to
do.
I
find
with
either
implementation
as
long
as
we
can
convince
ourselves
that
we'll
always
have
a
default
revision
and
we
won't
somehow
end
up
with
no
leader
or
something
that
would
not
be
good.
But
if
we
can
do
that,
then
we
should
be
fine.
D
B
A
Yeah,
I
think
I
think
one
risk
that
maybe
I
haven't
discussed
is
this
is
pretty
core
logic,
so
it's
really
important
that
we
have
some
revision
doing
it
and
it
requires
us
to
have
a
really
good
way
of
knowing
which
revision
is
the
default
revision
right
now.
That's
the
web
hook
and
john
brought
this
up
as
a
comment
in
the
dock.
I
do
wonder
if
this
makes
it
so
that
we
need
a
better
way
like
a
better
way
to
canonicalize,
like.
B
Oh
yes,
oh
yes,
absolutely,
and
I
have
this
problem
myself
in
some
other
project,
so
relying
on
webhooks,
it's
a
very
messy
business
because
you
may
have
clusters
where
you
don't
even
have
permissions
to
create
webhook
and
you
use
you
know,
manual,
injection
or
other
mechanism.
So
I
would
really
really
like
to
have
a
config
map
that
you
know
when,
when
when
we
we
write
the
configma
for
tags,
we
can
write
a
configmap
in
htr
systems
that
that
can
have
the
default
and
the
current
status.
A
B
A
E
B
B
A
That's
a
that's
a
good
point
that
we
could
maybe
merge
two
different
config
maps,
it's
complicated
but
yeah
that
could
work
yeah,
okay,
yeah,
actually
another
thing
I
wanted
to
bring
up
well.
Actually
I
can
bring
that
up
later
because
there
are
other
items
on
the
agenda
and
I
don't
want
to
go
too
far
off
topic
so.
B
One
more
thought
on
this
configmap
subject,
since
this
is
an
internal
configmap,
we
don't
need
to
have
a
wonderful
api
for
it,
but
we
should,
you
know,
learn
what
we,
what
they
did
wrong
with
the
old
config
maps
and
and
and
flag
and
start
it
flat.
Basically,
because
patching
config
maps
is
difficult
if
it's
not
flat.
B
So,
basically,
something
that
is,
you
know,
key
value
per
that
can
be
used
as
environment
variables,
loaded
and
so
so
very
easy
to
parse,
very
easy
to
to
patch
and
intended
for
tools,
basically
that
internet
that
integrate
with
with
this
geo
to
you
know,
if
you
have,
if
someone
writes
a
ui
to
to
select
you
know,
I
want
to
deploy
this
csgo
with
this
version
or
whatever
you
get.
What
I
mean
right,
yeah.
D
I
think
you
can
just
share
it.
That's
fine,
okay,
cool,
it's
not
very
long
yeah.
So
every
week
I'm
gonna
come
back
with
the
new
proposal
on
how
to
install
gateways.
So
this
is
the
deployment
of
the
week
just
kidding.
Hopefully
so,
we've
been
talking
a
bit
in
the
past
about
automatically
deploying
gateways
based
on
gateway
resources,
but
we
never
really
had
a
dock
to
discuss
this.
D
D
So
basically,
the
high
level
idea
is
that
a
user
would
create
a
gateway
like
on
the
left,
and
this
is
a
kubernetes
gateway
resource.
It's
just
a
standard
one
in
this
case
they're
exposing
port
one,
two,
three
four
and
port
80.,
and
today
they
would
then
need
to
go,
create
a
deployment
and
service
for
the
gateway.
Make
sure
that
the
service
has
those
same
ports
exposed,
and
you
know
if
they
ever
try
to
add
a
port.
They
have
to
make
sure
it's
kept
in
sync
et
cetera.
D
D
D
D
D
We've
all
heard
we
ran
about
this
before
probably
the
reason
why
it
doesn't
suck
for
us,
I
think,
is
because
we
already
have
a
mechanism
to
configure
arbitrary
pod
things,
which
is
the
injection,
and
so
in
the
above
example.
I
showed
just
like
the
bare
bones
deployment,
which
is
like
the
minimum
we
need.
D
The
one
thing
that's
left,
then,
is
the
service
so
about
half
the
service
is
the
ports
which
we're
managing
for
them.
That's
kind
of
one
of
the
benefits.
There's
a
few
other
customizations
that
people
want
in
service.
One
is
the
type
and
then
there's
like
the
load,
balancer
ip,
so
load
balancer,
ip's
already
fueled
in
gateway.
So
we
can
keep
that
and
then
the
other
thing
is
a
bunch
of
annotations
like
because
different
implementations
of
different
things
like
this.
B
B
D
B
So
as
a
gator,
it
doesn't
have
hostname
basically,
so
so
because
the
use
case
you
would
be,
you
have
five
host
names.
It's
a
common
use
case.
You
have
example.com,
for
example,
booking
for
the
example.com.
You
create
a
gateway
for
each
each
gateway
delegate
to
different
namespace
and
it's
a
separate
resource
but
they're.
All
port
eight
is.
D
D
D
D
D
We
could
make
the
controller
smarter
and
do
more
advanced
upgrades
and
safer
upgrades-
that's
probably
outside
the
mvp
though,
but
we
could
explore
that
in
the
future
and
kind
of
going
back
to
what
koston
said
in
terms
of
where
we
put
this.
It's
not
like
this
would
not
be
that
hard
to
implement,
but
it
does
have
like
very
high
rbac
privileges,
creating
services
and
deployments
in
any
name
space,
so
we
could
consider
making
it
a
separate
controller
and
or
in
easter
d.
D
D
B
Yeah,
you
know
you
know
my
my
thoughts
on
the
idea,
I'm
100
for
it.
On
the
on
on
using
a
separate
controller,
I
can
see
a
lot
of
benefits
because
study
is
becoming
very
complicated
and
having
smaller
repositories
that
are
focused
on
on
you
know
what
task
and
can
be
deployed
independently
and
also
eventually
linked
into
east
geod.
That
will
give
us
a
bit
more
velocity
and
avoid
polluting
history
with
stuff
that
may
or
may
not
work.
So
we
can
get
feedback
and
so
yeah.
It's
it's
not
micros.
B
A
D
A
D
A
B
D
Yeah
my
vision
for
how
the
user
experience
for
install
would
be.
Is
you
actually
just
do
like
helm,
install
easter
ode
and
then
that's
it?
You
never
have
to
do
anything
else.
I
mean
you
installed
cds,
too,
but
then
you
can
just
create
gateways
like
you
normally
would
like
if
you're,
using
a
cloud
ingress
or
a
gateway
provider,
it's
kind
of
the
same
thing
like
I
just
for
like
gke,
I
just
grade
ingress
and
it
goes
provision
some
cloud
load
balancer
for
me.
I
never
have
to
do
any
deployment
steps
beforehand.
B
And
the
nice
thing
is
that
istio
d1
is
upgraded,
it
can,
you
know,
check
hey,
my
version
is
1,
10,
5
and,
and
the
deployment
for
gateway
is
one.
This
one
is
the
previous
version
and
start
restarting
it.
Basically.
So
when
you
upgrade
this,
you
can
take
care
of
of
making
sure
the
categories
are
up.
The
same
version.
D
Yeah,
oh
one
thing
I
should
mention
is
that
if
we
have
multi
or
not
multi-primary
the
opposite,
one,
where
there's
a
shared
control
plane
with
a
config
cluster
like
we'll,
have
to
figure
out,
you
know
the
gateway
will
live
in
one
place,
but
the
actual
deployments
may
live
in
many
clusters.
So
we'll
have
to
figure
that
out
as
well.
B
Yes,
absolutely,
and,
and
and
also
we
have
the
option
in
in
this
case,
to
have
user
designate
where
they
want
to
keep
the
gateways
because
gateways
you're
making
workloads
in
cluster
workload
cluster,
where
you
run
all
kind
of
unprivileged
stuff.
But
you
may
want
to
consolidate
all
the
gateways
in
a
you
know:
super
secure
cluster
or
you
have
secrets,
certificates
and
other
things.
So
you
don't
have
the
secrets
leaking
basically
and
that's
an
important
use
case
for
security,
conscious
users.
Basically.
D
B
D
I
would
generally
say
yes,
but
we
need
to
be
a
bit
careful,
because
I
did
do
like
a
proof
of
concept
of
this
and
I
was
making
sure
that
the
service
was
exactly
as
we
specified.
But
then
there
was
some
other
controller
that
was
always
adding
its
own
annotations
to
the
service,
and
so
it
was
like
in
a
loop
basically.
D
B
Yeah
yeah
have
a
long
practice
of
doing
this.
John
one
one
comment
I
have
about
the
this
thought
injection
and
injection
template.
It's
probably
segue
to
what
I
want
to
discuss
next
week
about
the
injection
less.
But
if
you
have
this
controller
and
this
controller
can
read
config
maps
and
everything
else,
there
is
no
need
to
actually
create
the
port.
Have
the
port
called
a
web
hook
where
hook
patch?
Is
a
pod
and
create
support?
Really
you
can
just
you
know,
have
this
controller
read.
B
B
D
Yeah
it
does
it
changes
how
upgrades
work,
maybe
in
a
good
way,
because
if
we
do
that,
then
it
means
that
the
the
gateway
controller
is
in
complete
control
of
the
upgrade
because
they
like
the
pods,
will
not
upgrade
until
it
decides
that
it's
going
to
kind
of
rerun
the
injection
template
and
set
the
image
to
whatever
the
the
active
one
is.
If
we
do
it
the
way
it's
proposed
here,
then
it's
actually
the
injection
template,
which
is
largely
driven
by
the
control
plane.
D
Admin
like
the
easterd
admin
that
does
it
like
a
restart
of
a
pod.
They
get
the
new
image
right,
both
have
pros
and
cons.
I
think
I'm
not
sure
that
one's
inherently
better
than
the
other
one,
but
it
is
a
it's
a
it's,
a
bigger
change
than
just
saying
that
we're
avoiding
a
round
trip
to
the
web
hook.
I
think.
B
It
I
agree
with
you:
it's
it's
basically
saying
that
the
gateway
controller,
that
is
you
know,
creating
port,
is
responsible
for
the
ports
and
all
the
lifecycle
of
the
port.
So
so,
if
it
thinks
that
the
template
has
changed,
you
know
it
will
reapply
that
the
temperature
redeploys
the
pods
in
a
controlled
manner.
B
B
B
Yeah,
in
particular,
if
you,
if
we
go
with
the
advanced
solution,
where
you
actually
deploy
the
gateways
in
a
separate
cluster
in
the
first
place,
because
again
you
want
to
to
keep
certificates
separate
and
separation
of
whatever.
Then
you
cannot
even
do
like
rolling
upgrades,
because
you
do
not
have
permissions
in
that
cluster
also
managed.
D
B
D
B
D
B
E
E
E
D
D
D
So
then,
who
is
our
audience
for
using
this?
Automated
thing
seems
like
it
should
be,
probably
the
hopefully
large
percentage
of
not
super
bespoke
custom
users
and
then
how
big
is
that
group
right
if
that's
80
90
of
users
and
that's
that's
awesome,
and
I
think
this
makes
a
lot
of
sense
if
only
five
percent
of
users
think
this
is
is
useful,
then
it's
probably
not
really
worth
it
right.
B
John,
I
I
don't
necessarily
agree
with
this
statement.
I
think
this
should
be
the
default.
This
should
be
what
we
recommend
people
and
if
they
want
to
do
something
different,
they
can
do
it
by
themselves.
I
mean
it's
it's
too
difficult
to
support,
helm,
chart
histocatly,
install
and
20
other
ways
to
forget.
D
B
B
B
What
I'm
saying
here
is
that
for
the
new
kubernetes
api,
you
should
not
repeat
the
mistake
of
having
two
helm
charts
and
is
your
cattle
and
swells,
but
use
only
this.
This
new
model
that
doesn't
mean
we
should
not
have
the
simplified
gateway
for
the
existing
users
for
the
existing
histo
gateway.
It's
a
bit
more
refined.
D
And
that
means
that
we
either
need
to
support
existing
deployments.
So
they
can
just
change
the
api
and
not
the
deployment
or
it
would
need
to
like
take
over
an
existing
helm
or
easter
cuddle
controlled
deployment
right,
because
we
can't
tell
people
in
order
to
adopt
a
new
api.
You
have
to
go,
create
a
new
service
and
get
a
new
ip.
That's
probably
not
going
to
add.
B
B
No,
but
but
you
cannot
migrate
the
ipad
transformation
system
to
ingress.
That's
a
problem.
So
right
you,
if
you
migrate,
you
need
to
keep
it
in
your
system,
so
we
don't
have
the
problem
with
migration
if
we
put
it
into
your
system
because
it
cannot
be
migrated
as
far
as
you
know.
Well,
it
can,
but
it's
complicated.
E
Yeah
and
as
far
as
the
mvp
is
concerned,
though,
I
don't
think
you
have
to
worry
about
migration.
I
think
we
should
try
and
understand
how
people
like
how
we
wish
to
do
migration,
but
I
I
don't
think
that
that
needs
to
be
done
as
part
of
the
mvp.
I
think
this
is
more
just
like
pushing
new
greenfield.
E
You
know
and,
like
you
know,
large
customers
that
are
doing
crazy
things
with
ingress
like
like
we'll
be
able
to,
hopefully
solicit
more,
but
at
least
for
like
new
onboarding
users
of
istio,
which
you
know
there
always
are
like
this
is
something
we
should
kind
of
strongly
be
pushing
them
kind
of
towards,
but
yeah.
Let's
just
give
some
consideration
at
least
to
migration,
but
I
don't
think
it
has
to
be
implemented.
At
least
not.
You
know,
anytime
soon,.