►
From YouTube: Hoot: What's New in Istio 1.7
Description
Christian Posta (Solo.io) and Dan Berg (IBM and Istio Project) are going live in this next Hoot episode to talk about the latest Istio 1.7 release.
A
This
hoot,
where
we're
going
to
talk
about
istio
1.7,
which
was
recently
released,
and
if
you're
unsure
what
a
hoot
is.
It
is
a
sort
of
a
live
stream
and
we
do
record
it
of
of
engineers
digging
into
interesting
technology
and
we've
had
a
few
different
series
about
digging
into
service
mesh
digging
into
gateways
and
proxy
technology,
and
we
have
a
current
series
running
where
we
were
helping
to
educate
and
deep
dive
on
envoy
proxy,
and
this
is
sort
of
an
off
series.
A
A
Very
good
and
I'm
christian
post,
I
work
at
solo
and
I
work
on
service
mesh
technology
and
I
want
to
keep
this
informal
right.
We
don't
have
slides
we're
not
going
to
powerpoint
you
to
death
here,
but
we
do
want
to
talk
about
a
few
things
in
the
istio
community
and
the
you
know
some
of
the
the
features
and
and
changes
that
have
come
in
istio
1.7.
B
B
B
So
a
key
aspect
here
is
under
normal
voting
situations.
If
an
item
comes
up
for
vote,
we
wanted
to
make
sure
that
no
one
organization
had
the
ability
to
vote
and
pass
any
item
by
themselves.
So
there
has
to
be
some
collaboration.
There
has
to
be
community
support
for
the
item
before
it
would
pass.
We
also
wanted
to
make
it
very
difficult
to
make
a
change
to
the
charter
itself,
so
we
increased
the
voting
requirement.
So
a
simple
majority
isn't
good
enough.
B
You
need,
like
80
percent
voting
approval
to
pass
a
change
to
the
actual
charter.
So
that's
what
we
focused
on
and
the
outcome-
and
this
wasn't
easy
by
the
way.
So
we
we've
been
spending.
We've
been
doing
this
for
months
now,
trying
to
agree
on
the
charter
trying
to
agree
on
what
it
the
language
around
what
it
means
to
be
a
contributor
and
contribution
what
the
percentages
would
be
to
vote,
what
the
percentages
of
the
mat
or
max
seats
would
be,
and
even
down
to
the
wire.
B
We
didn't
agree
on
everything,
but
we
agreed
on
the
process
and
and
and
approved
the
current
charter.
As
you
see
it,
and
ultimately
it's
it's
far
better
than
what
we
have
today
right.
Is
it
perfect?
Probably
not
nothing
ever
is
like,
like.
I
said
it's
taken
us
months
to
get
to
this
point,
but
what
it
does
is
it.
B
It's
it's
actually
right
now,
it's
the
top
three
would
get
seats,
but
we
made
it
flexible
enough
that
the
way
in
which
we
count
contributions
is
decided
on
the
year
in
which
you're
gonna
do
the
election.
So
we
can
adjust
how
to
contribute,
because
that's
one
of
the
sticking
points
that
we
were
really
struggling
with.
Well,
how
do
you
count
contribution
right,
and
we
wanted
to
give
some
control
over
to
the
steering
committee
itself
to
make
a
determination
as
things
change,
how
you
count
contribution
could
evolve.
B
B
One
particular
company
it
will,
it
can't
go
beyond
five
and
five
is
not
enough
to
pass
a
60
vote
right.
So
even
with
those
five,
you
can't
pass
a
vote
and
with
that
it
introduces
a
third
organization
into
the
group
of
two
that
we
have
today.
So
it'll
be
ibm,
google
and
and
a
third
and
that
and
that
can
change
over
time
as
as
contrib
contributions
take
place
and
then.
B
Third
right
now,
I
believe,
is
salesforce.
It's
salesforce
that
is
correct.
Salesforce
has
garnished
based
on
our
current
accounting.
They
have
won
the
third
seat,
so
they
they
get
a
contribution
seat
now.
The
other
key
aspect
of
this
is
that
an
organization
that
holds
a
contributor
seat
cannot
then
go
obtain
community
seats
right.
So
that's
the
other
aspect
of
this,
so
you
can't
change
the
balance
because
you
hit
your
max
and
then
you
go
get
some
of
the
community
seats.
That's
that's
not
how
this
works.
B
A
B
Really
is
yeah,
so
I
mean
if,
if
all
works
out
well,
at
least
according
to
plan,
we
should
have
represent
representation
from
at
least
seven
different
organizations
right
into
the
new
committee
this
year,
which
I
think
is
phenomenal
right,
given
where
we
are
today,
that'd,
be
a
massive
change.
Yeah.
A
Yeah
absolutely,
as
you
said,
you
know
the
corporate
diversification
that's
important
having
a
minimum
or
you
know,
target
of
seven
different
organizations,
part
of
the
istio
steering
committee-
maybe
it'll,
let's
see
where
we
are
on
time.
Maybe
if
you
could
take
two
seconds
and
just
because
there
is
a
steering
committee,
there's
also
the
technical
oversight
committee
experience.
B
Yeah,
so
the
way
that
this
works
is
the
steering
committee
is
made
up
of
organizations
and
voting
rights
of
those
organizations,
as
dictated
by
this
charter,
to
help
steer
the
project
forward.
That's
why
it's
called
the
steering
committee.
They
make
decisions
about
how
to
promote
the
project,
marketing
communications,
engaging
with
the
community,
really
the
use
of
the
project
itself
and
staring
it
forward.
B
The
technical
direction
of
the
project
is
led
by
the
technical
oversight
committee
right
and
that
is
made
up
of
contributors
to
istio
itself,
and
that
is
based
on
pure
contribution
to
the
project
and
technical
contribution
to
the
project,
and
we
use
that
committee
to
help
drive
the
technical
strategy
and
implementation
for
the
project
in
as
a
whole.
Now
we
do
have,
we
do
have
a
strategy
to
go
through
and
revise
the
toc
charter
as
well.
B
We
wanted
to
start
with
the
steering
and
then
once
we
got
that
now
we're
going
to
go
back
and
we're
going
to
look
at
the
toc
and
readjust
that.
Arguably,
though,
the
toc
is
already
fairly
diverse
and
we
hold
open
open
meetings
on
the
toc,
so
we
generally
have
a
large
group
of
participants
come
in
and
participate
in
the
toc
meetings,
because
it's
not
a
closed
set
of
meetings.
B
A
Yep
yep
awesome,
okay,
and
so
I
guess
the
last
point
to
make,
I
think,
is
that
this
is
obviously,
as
you
can
see,
a
an
open
community.
The
governance
that's
being
established
here
is
is
very
open
and
you
know
not
favoring
any
one
particular
organization,
and
I
think
that
has
been
a
you
know.
Various
folks
in
the
istio
community,
as
well
as
the
ecosystem
outside,
have
been
calling
for.
You
know
open
governance
of
the
of
the
istio
project,
and
I
think
this
is
you
know
these
are
these?
Are
steps
in
that
direction?
B
A
Cool,
well,
that's
that's
exciting.
So
on
that
note,
I
definitely
for
the
folks
that
are
watching
or
will
watch
at
some
point.
You
know
istio
is
a
very
exciting,
open
source
project.
The
problems
that
istio
is
solving
is
is
very
exciting,
so
get
involved
in
the
community
and
that
involvement
can
be
things
like
obviously,
code
involvement
and
contributions,
but
it's
not
just
code
right
getting
on
and
being
active
opening
issues
identifying
areas
where
you
can
jump
in
and
answer
questions
contributing
to
documentation
to
demos
and
samples
and
so
forth.
A
B
I
mean
some
of
the
things
and
then
what's
nice
about
1.7.
Is
it
it
really
aligns
with
the
the
overall
strategy
that
we
publish
several
months
back
around
the
direction
we
want
to
take
the
istio
project
really
focus
in
on
hardening
improvements
and
usability
and
and
improvements
around
security
are
key
aspects
that
we
had
in
our
our
strategy.
Roadmap
and.
B
On
where
we're
going
to
go,
what's
the
guiding
light
for
the
project
and
I'm
excited
about
1.7,
because
1.7
really
hits
hits
all
of
those
marks
on
how
we're
going
to
improve
the
security
aspects
of
istio,
how
we're
going
to
make
it
simpler,
easier
to
use
so
there's
a
number
of
security
enhancements
that
I'm
I'm
pretty
excited
about.
We've
we've
made
some
improvements
with
some
of
the
componentry.
B
B
Yeah,
the
gateway
was
was
a
big
one
there.
Some
of
the
other
ones
is
that
we
now
going
along
with
the
gateway
we
apply,
some
of
the
egress
gateway,
tls
and
mtls
origination
support
to
the
egress
gateway
in
the
past.
It
was
only
applied
to
the
ingress,
but
that's
now
possible
to
do
egress
as
well,
so
you
can
have
secure
outbound
traffic
from
from
your
mesh
as
you
do
for
inbound
some
of
the
other
things
that
were
in
there
I'm
trying
to
remember.
B
To
debug
these
service
meshes
they're,
it's
a
complex
problem
space,
a
lot
of
layers,
yep
yeah,
there's
lots
of
layers,
and
I
mean
that's
not
a
statement
of
istio
by
itself.
It's
just
you're
building
these
distributed
cloud
services
and
systems
they're,
just
inherently
complex,
so
having
more
tools
to
analyze.
These
problems
is
incredibly
helpful
and
more
we've
done
it
in
the
in
previous
releases,
and
we
continue
to
do
it
in
istio
1.7.
You
can
see
here
additional
istio,
ctl,
analyze
capabilities,
the
one
on
the
insecure
destination
rules
that
one's
actually
pretty
nice.
B
A
B
B
B
A
At
least
it's
a
what
is
it
alpha
or
it's
experimental
like
we're
looking
for
feedback
on
this
approach,
but
I
think
it's
a
pretty
damn
good
approach.
Folks
at
ibm,
red
hat
came
up
with.
I
think
that
allow
you
to
start,
you
know,
add
a
it
was
a
pre-start
hook
that
waits
for
your
application
to
to,
or
rather
waits
for
the
proxy
to
start
up
before
the
application
actually
starts
up.
B
A
B
Yes,
that's
that's
definitely
one!
That's
probably
my
favorite
operational
improvement
there,
some
of
the
others
are
we
just
fix
problems,
so
it's
just
improvements,
the
still
endpoints,
that's
a
nice
one.
That
pilot
would
become
unhealthy
because
of
those
stale
endpoints,
so
that
that
was
just
good
good
etiquette
and
good
maintenance
and
of
the
system
as
a
whole,
just
keeping
it
healthy,
ensuring
that
everything
is
cleaned
up
there
and
obviously
more
things
around
metrics.
In
this
case,
especially
some
of
the
improvements
around
prometheus
metrics
in
the
pipeline.
That's.
A
A
B
Planes,
yeah
and-
and
you
know
what
and
I
don't
know
if
they
actually,
we
might
have
to
go,
dig
it
out
of
the
docks.
I
don't
know
if
it's
actually
called
out
here,
but
I
I
will
change
in
the
changes
so,
while
you're
looking
at
it,
I
will
I
will
discuss
this
a
little
bit.
So
one
of
the
areas
that
we've
been
looking
at
is
this
notion
of
central.
A
B
Is
what
we've
been
calling
it
it's
experimental
right
now,
but
it's
an
area
that
we've
been
driving
fundamentally
to
help
us
do
a
couple
different
things.
One
of
them
is
just
to
scale
our
ability
to
manage
more
istio
meshes
more
control
planes
and,
fundamentally
what
this
allows
us
to
do.
Some
people
might
look
at
this,
as
this
is
just
part
of
the
multi-cluster
support.
B
So
it's
always
disconnected
in
this
case
we
would,
we
would
run
sdod
pretty
much
standalone,
independent
of
of
the
actual
cluster
or
clusters
that
are
being
managed.
So
that's
really
the
the
crux
of
central
sdod
and
it's
got
a
number
of
changes
in
it
that
are
experiment
experimental,
as
you
pointed
out,
but
it
allows
us
to
do
that.
Decoupling
of
the
control
plane
from
the
data
plane
or
the
the
remote
plane
is
what
we
call
it
here.
The
remote
data
plane.
A
B
A
lot
of
this
architectural
style
is
based
on
learning
and
experience
that
we've
had
in
ibm
around
managing
large
numbers
of
kubernetes
clusters,
because
we
run
kubernetes
in
a
very
similar
manner,
where
we
decouple
the
control
plane
from
the
data
plane,
and
we
we've
been
looking
at
istio
going.
Can
we
run
istio
the
same
way
because
there's
a
lot
of
advantages
in
both
scale
and
security
for
doing
that,
and
that's
where
central
seod
is
our
experimentation
to
do
exactly
that?.
B
Yeah,
and
actually
our
our
initial
idea
here,
is
to
keep
it
extremely
simple,
not
to
have
an
uber
right
http
that
manages
a
large
number
but
really
keep
it
constrained
and
have
lots
of
little
sdods
small
service
meshes
that
control
a
very
localized
group
of
services
and
then
build
into
the
whole
mesh
federation.
As
we
progress
here
exactly
is
really
the
approach
that
we're
looking
at.
A
A
B
The
interesting
thing
is
from
day
one:
we
always
said
that
istio
wasn't
just
about
containers
and
kubernetes
right.
We
indicated
that
it
was
valid
for
vms
applications,
running
on
bare
metal
systems,
cloud,
foundry
applications
and
so
on
and
so
forth.
Well,
we
started
with
kubernetes
because,
obviously
that's
where
the
popularity
was
and
that's
where
we
had
the
most
traction
and
that's
where
the
vendors
obviously
ibm
and
google
wanted
to
pursue,
and
then
we
let
feedback
just
decide
where
else
we
go.
B
You
notice
there's
no
cloud
foundry
support
because
we
haven't
had
much
request
for
it,
but
vms
we've
had
lots
of
requests,
and
I
think
it
goes
back
to
one
of
the
statements
you
were
making
earlier
chris
about
the
notion
that
many
of
the
applications
that
are
being
used
for
enabling
service
meshes
or
the
value
of
service
mesh
to
them
are
brownfield
right
right
and
how
many
brownfield
applications
out.
There
are
all
containerized,
not
a
lot.
B
B
A
B
Adding
more
and
more
vm
support,
as
as
we
go,
and
this
I
think
in
1.7.
1.7
is
very
interesting
because
of
where,
where
we've
gone
with
the
vm
support,
because
in
the
previous
releases,
there's
enough
there
to
really
bootstrap
vms
and
get
them
integrated
into
the
mesh
they're
part
of
the
mesh,
but
they're
really
not
secure
right
they're,
not
they
don't
have
the
same
levels
of
security
that
you
would
in
a
containerized
environment.
Up
until
now
and
1.7
makes
drastic
changes
or,
I
shouldn't
say,
drastic
changes.
B
B
A
Yep
yep
exactly
so
on
that
note,
why
don't?
I
just
show
a
quick
demo:
let's
do
it,
everyone
crossing
their
fingers
for
me
and
that
it
works.
So,
let's
see
the
first
thing
that
we
do
want
to
do.
Is
we
want
to
take
a
look
at
the
the
the
the
directory
that
I'm
looking
at
all
of
these
all
of
these
components
of
the
demo
and
the
script.
Are
I
publish
them
on
github
and
I
can
show
you
a
link
to
them
at
the
at
the
end
here.
A
So
basically,
what
we're
going
to
do
here
and
let's
come
to
the
the
docs
right,
because
I
want
to
point
you
to
how
you
can
do
this
yourself
either
using
the
oh.
This
is
one
one
last
thing
I
want
to
point
out
about
what's
in
1.7
and
it
does
apply
directly
to
the
docs,
which
is
the
the
docs
team
added
this
thing
that
allows
them
to
automatically
grab
the
steps
that
are
outlined
in
a
particular
dock.
Let's
say
mirroring
right,
so
what
are
the?
A
You
know
things
can
get
outdated
pretty
quickly,
but
if
you
can
build
automated
tests
around
that,
so
that
it
still
works
on
the
version
of
istio
that
you're
expecting,
then
you
know
you
have
a
little
more
confidence
in
that
doc
and
up
next
to
the
documentation
title
you
can
see
if
there's
a
reg,
a
check
mark
green
check
mark
here.
It
means
that
this
does
have
an
automated
test.
If
you
come
on
to
maybe
something
else
like
install,
maybe
the
install
stuff
is
still
coming
coming
along.
A
Maybe
this
one
doesn't
have
a
test,
but
most
of
the
tasks
I
believe
do
have
have
automated
tests
and
I
think
that's
from
a
you
know.
How
do
we
maintain-
and
you
know,
build
a
good
experience
around
the
project
itself,
knowing
what
knowing
that
we
have
tests
that
validate?
What
is
in
what's
written
down
is
is
awesome.
A
A
A
A
So
if
we
look
in
our
namespace
here
and
we
look
at
our
service
accounts,
we
can
see
that
I
created
a
my
vm
service
account,
so
the
identity
of
the
vm
that
we
create
will
be
tied
to
at
least
in
terms
of
what
the
mesh
knows
about
this.
This
service
account.
So
when
I
run
this
command
here,
I'm
basically
saying
give
me
a
give
me
a
token
that
represents
this
service
account
for
a
limited
amount
of
time
right
and
so
when
we
set
up.
A
So
if
I
run
this
the
script
there
too,
it's
going
to
do
all
the
run
run
through
all
those
lists
of
steps
create
the
token.
So
if
we
do
find
in
here,
we
can
see
that
it'll
create
things
like
the
istio
token.
So
that's
that
short-lived
token
that
I
mentioned
it'll
grab
the
root
ca
so
that
we
can
bring
that.
So
that's
the
that's
the
public
facing
certificate
that
we
can
bring
to
the
vm,
so
we
know
and
say
hey
we
can.
We
can
trust,
connections
and
and
certificates
that
are
rooted
in
this
certificate.
A
A
A
That's
all
good.
If
I
come
back
here
to
canines
looking
at
my
namespaces,
we
do
have
istio
installed,
istio
1.7
right.
We
have
some
sample
surfaces
running
in
the
default
name,
space,
http
bin
and
sleep,
and
so
so
we
have.
We
have
workloads
running
here
and,
like
I
said,
we
created
this
bm
services
namespace,
where
we're
going
to
host
the
resources
necessary
to
connect
up
to
our
vm.
A
We
see
some
of
the
files
we
see,
and
here
we
see
the
you
know
the
the
seo
token,
which
we're
going
to
use
to
bootstrap
and
some
environment
variables
and
some
other
dns
stuff.
But
so
what
we're
going
to
do
here
is
we're
going
to
pre
prepare
this
vm,
which
actually,
if
we
just
take
a
look
at
the
the
script,
is
simple:
it
just
copies
those
files
into
the
correct
location
and
by
correct
location.
A
What
this
means
is
the
locations
where
the
istio
sidecar
so
istio
proxy,
when
it
starts
up
that
it
will
look
in
these
location
in
these
locations
for
these
these
files.
For
the
token
for
the
ca-
and
you
know,
it'll
slip
up
the
environment,
variables
and
so
forth,
so
it's
just
big
things
in
the
right
spot.
A
So
if
we
do
that
prep
the
vm
we'll
give
that
a
second
it
does
some
updates.
It
actually
pulls
down
the
seo
sidecar
as
a
debian
package.
There's
also
an
rpm
package
that
was
released
as
part
of
istio
1.7,
actually
so
running
on,
centos
or
red
hat
should
be
possible
as
well,
so
it
installs
it
as
a
service
running
on
the
vm.
A
So
if
I
do
sudo,
let's
start
our
istio
and
that's
a
very
simple
command.
I'll
show
that
to
you,
I
guess
all
right:
it's
just
system
ctl
star,
istio,
that's
the
that's!
The
service
that's
been
installed.
If
we
do
that,
don't
mind
this,
so
the
logs
might
not
be
there
yet.
But
now,
if
we
come
back
and
list
our
services
in
systemd,
we
should
see
istio
here
and
we
do
so.
That's
all
good
loaded,
that's
good!
A
If
we
do,
let's
do
let's
check
out
whether
envoy's
running,
we
should
see
envoy
running
and
we
do
so.
We
have
our
envoy
proxy
running.
It's
managed
by
a
system.unit
file,
and
now,
if
we
tell
the
logs
var
log
is
cos,
you
know
log.
We
should
see
that
you
know
we.
We
are
getting
some
some
logging
statements
here.
A
The
last
thing
that
I
will
also
point
out
is
that
as
part
of
the
istio
sidecar
bootstrap,
it
does
the
iptables
rewrites
so
that
the
traffic
coming
into
the
vm
for
will
go
to
envoy
and
then
the
traffic
leaving
the
vm
will
also
go
to
envoy
so
envoy.
The
sidecar
here
can
make
the
decision
about
routing
and
so
forth
right.
So
if
we
do.
A
Exactly
so
in
in
this
case,
you
can
see
the
ip
tables,
not
the
not
entries
were
created,
we're
going
to
redirect
any
of
the
kubernetes
services
stuff
to
envoy
and
we're
going
to
redirect
anything
coming
in
on
port
99
to
envoy,
and
then
let
onboard
make
the
decision
about
how
to
how
to
deal
with
that.
So,
if
all
that
stuff
is
in
place,
theoretically,
we
should
be
able
to
call
our
our
services
running
in
the
mesh.
A
A
A
So
this
part
is
still
the
the
same,
but
if
we
come
in
here
to
docs
and
reference
and
traffic
management,
we
see
that
there's
a
a
workload
entry
which
is
used
to
describe
the
vm,
it's
addresses
and
so
forth,
as
though
it
was
a
pod
running.
You
know
in
the
kubernetes
cluster
so
to
the
service
mesh.
It
seems
like
it's
just
another
entry
you
in
in
the
list
of
entries
that
you
can
call
when
you
call
a
service.
A
A
Workload,
entry
create
the
workload
entry
and
that's
all
good
come
back
here.
We
should
see
our
workload
entry
here
in
the
vm
services
and
we
do
if
we
look
at
it
this.
This
is
fairly
simple.
We
give
it
the
address
of
the
vm
and
some
labels
to
associate
it
with
a
particular
service
in
in
the
cluster.
A
A
A
Now
the
problem
is
so.
Can
everybody
else
right?
So
I
did
this
from.
I
did
this
call
from
mac.
What
we
want
to
do
is
turn
on
strict
mtls
for
the
cluster,
so
that
the
connection
from
the
surface
mesh
to
the
vm
is
encrypted
end
to
end
and
vice
versa,
from
the
vm
to
the
surface
mesh.
You
know
the
workload's
running
in
the
mesh.
A
So
now,
if
I
try
call
this,
it
should
fail
and
it
does
I'll
get
a
connection
reset,
because
I'm
trying
to
do
it
over
plain
text
but
from
within
a
workload
in
the
service
mesh.
If
I
call
it,
it
should
work
and
it
does
and
that's
because
it
you
know,
tls
and
mutual
tls
is
enabled
for
both
the
client
and
the
server
for
all
the
workloads
in
the
service
mesh.
A
So
that's
that's
what
I
have
to
show
just
that
the
vm
support
in
istio
is
continuing
to
evolve
and
continuing
to
come
along.
It's
still
alpha
right
now,
but
we
want
folks
to
try
it
out
and
give
feedback
and
continue
to
help
improve
it.
We
expect
more
more
improvements
for
1.8
and
check
out
this.
You
know
being
able
to
bootstrap
the
identity
from
a
short-lived
token,
which.
B
B
But
now
you've
got
an
encrypted
data
flows
between
the
pod
and
another
vm,
and
you
didn't
have
to
turn
on
or
configure
or
set
up
any
crazy
ipsec
tunnels
or
anything
like
that
from
worker
nodes
in
a
kubernetes
cluster
to
vms
running
outside
the
cluster
and
establish
a
very
complicated
network
tunneling
system
to
do
that,
encryption,
which
is
not
very
it's
not
the
most
efficient
way.
Obviously,
it
has
performance
problems
and
it
doesn't
capture
all
the
traffic.
A
B
Captures
all
the
traffic
it's
a
higher
degree
of
security
with
mutual
tls,
and
now
you
can
incorporate
your
vms.
Just
like
you
would
any
other
service
running
in
your
kubernetes
cluster.
I
mean
it.
It
looked
no
different
if
you
wouldn't
have
said
that
that
was
on
a
vm,
you
couldn't
even
tell
right,
you're.
A
B
A
Yeah
yeah
absolutely
very
excited
about
that.
Just
in
in
my
experience
and
working
with
folks
in
trying
to
adopt
a
service
mesh,
you
know
of
the
concerns
or
challenges
that
they
have
is
they
have
a
brownfield
environment?
And
you
know
kubernetes
makes
up
a
very
small
percentage
of
those
workloads
growing,
but
you
know
they
they
need
to
account
for
their
existing
services
that
they
either
won't
be
able
to
right
now
or
cannot
shift
and
and
re-platform
to
kubernetes.
So
I
think
you
know
I've
said
this
many
times.