►
From YouTube: Ready to Serve! Speeding-Up Startup Time of Istio-Powered Workloads - Michal Malka & Etai Lev-Ran
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
Ready to Serve! Speeding-Up Startup Time of Istio-Powered Workloads - Michal Malka & Etai Lev-Ran, IBM
Pod startup time has long been a focus area for cloud-native platforms. Optimizing startup time is critical to support use cases such as autoscaling, upgrades, and failure recovery. The recent rise of the serverless model, along with its key value proposition of scale-to-zero of idle workloads, has made pod startup time important than ever: The platform must be able to start the pod fairly quick, such that the latency of request-triggered scale-from-zero is acceptable. In this talk, we'll analyze the latency contributed by Istio service mesh to pod startup time, right from pod creation and up to the pod becoming ready to service requests. We'll also examine various techniques to reduce it, including using Istio CNI to bootstrap the pod's network, launching the sidecar proxy with an initial routing configuration, and using manual sidecar injection.
https://sched.co/UacN
A
All
right,
everyone
we'll
get
started
hello,
I'm
Caslon
fields
and
I'm
a
CNC
F,
ambassador
and
I.
Am
your
track
host
today.
We're
introducing
track
hosts
at
this
cube
con.
Hopefully,
you've
seen
us
around
I'm
going
to
introduce
your
talk,
real,
quick
and
then
at
the
end,
I
will
be
passing
around
the
mic
for
Q&A
and
I
am
here
to
remind
you
to
please
do
your
feedback
forms
at
the
end
of
the
session.
We
really
appreciate
it
and
your
presenters
can
learn
a
lot
from
the
feedback
that
you
give.
A
C
B
Today,
Ty
and
I
are
going
to
talk
about
startup
time
of
kubernetes
pods
and
more
specifically,
pods
that
are
installed
with
east
your
east
IAM
on
them.
After
we
will
be
clear
on
what
does
it
mean
East
you're
inside
this
pod?
We
will
continue
and
introduce
you
to
a
few
techniques
on
how
to
speed
up
pods,
which
are
issue
enabled
so
before
we
will
start,
let's
further
define
what
we
mean,
but
by
startup
time.
B
So
startup
time
is
from
the
point
that
the
user
is
requesting
kubernetes
for
a
new
pod,
which
is
creating
and
descending
a
new
request
till
the
time
that
the
status
of
the
pod
is
ready
by
the
kubernetes
api.
And
why
is
it
important?
It
is
important,
because
a
lot
of
serve
various
components
are
waiting
for
these
status
to
be
ready,
so
they
will
be
able
to
start
and
use
this
spot.
For
example,
Easton
is
one
of
the
example
and
we
will
see
how
it
will
work
kay
native.
B
A
lot
of
time
is
waiting
also
for
the
pod,
startup
time
and
kubernetes,
of
course,
and
why
do
we
care
about
startup
time
and
which
use
cases?
Is
it
really
important?
So
we
have
few
examples
here.
The
first
one
is,
for
example,
service
and
specific,
more
specifically
scale
to
zero
girl
from
zero
in
server
less.
The
pod
is
starting
only
after
your
requests
are
coming
and
then
it
is
very
important
the
time
that
the
pod
is
ready,
because
only
after
it
is
ready,
the
request
can
be
served.
B
More
use.
Cases
are
auto
scaling
in
auto
scaling
when
we
have
a
load
on
the
system,
and
we
would
like
to
move
request
to
new
pod.
We
need
to
wait
to
the
pod
to
be
ready
and
last
example
is
for
recovering
from
failures
when
it
is
also
very
important,
because
all
the
requests
are
waiting,
basically
not
getting
any
response
till
the
pod
is
ready.
B
B
It
is
calling
to
the
admission
web
hook
to
validate
or
mutate
pod,
and
we
will
see
later
how
exactly
easter
is
coming
inside
it
using
another
admission
web
hooks
that
is
coming
in
and
how
it
we
will
see.
Example
of
how
exactly
it's
in
the
startup
time,
etcd
is
one
of
the
it's
a
persistent
sort
that
kubernetes
is
using
to
hold
all
the
information
about
the
object,
and
here
api
server
is
saving
all
the
object
information
inside
dtc.
B
B
C
If
we
keep
the
control
plane
on
the
Left,
all
of
that
happened
on
the
control
plane.
Now
we're
going
to
shift
our
focus
into
the
worker
nodes.
So
there's
an
agent
and
I'm
pretty
sure
everybody
knows
called
the
Kubler
that
interacts
with,
and
then
the
coolest
is
the
one
that
is
responsible
to
now
create
a
sandbox
and
get
all
the
containers
running
on
that
specific
node.
C
There's
a
bunch
of
interfaces
that
the
kulit
uses
in
order
to
set
up
a
sandbox,
a
control
environment,
to
run
the
image
and
run
the
container
in
runtime
interfaces.
Network
interfaces,
storage
interfaces
all
of
these
get
set
up
by
the
couplet.
And
then
it's
going
to
create
the
containers
inside
that.
Okay.
C
So
we
have
the
sandbox
ready
and
we
start
to
create
the
containers
and
we
get
the
containers
in
them.
And
ultimately,
after
all
of
the
containers
in
the
pod
are
there,
the
couplet
is
going
to
ping
it
on
the
next
slide
and
the
couplet
checks
that
the
pods
and
the
containers
are
all
ready.
And
then
it's
going
to
go
and
update
at
CD
and
you'll.
Keep
on
seeing
more
and
more
updates
that
go
into
at
CD,
so
basically,
it's
a
very
complex
multi.
Their
process
starts
on
the
control.
C
C
For
example,
within
this
time,
the
couplet
needs
to
download
images
from
a
remote
registry
right.
So
if
it's
a
large
image
or
the
connectivity
is
constrained
or
there's
a
bandwidth
issue
connected
to
the
registry,
it's
going
to
take
much
longer.
So
in
order
to
actually
validate
this
SLO,
they
define
it
with
locally
cached
images.
Right
I
mean
they're,
going
to
try
and
limit
the
variants
and
get
a
result.
So
official
SLO
five
seconds
for
the
p99,
in
other
words
99%
of
the
pod
creations,
are
going
to
complete
in
under
five
seconds.
C
This
matches
up
pretty
well
with
experiments
that
we
did.
What
we
saw
was
that
the
median
was
about
two
and
a
half
seconds
on
our
clusters,
and
these
were
clusters
that
weren't
doing
really
a
lot
of
work
and
the
p99
goes
up.
You
know
by
half
a
second
or
so
you
might
get
different
numbers
on
your
clusters,
depending
on
the
whole
bunch
of
other
stuff.
C
B
So,
let's
see
what
happened
when
East
yo
is
coming
into
the
picture,
so
does
anyone
know
what
is
easier
here?
Okay,
I
think
I
will
skip
the
intro
about
estas.
We
will
have
time
to
talk
about
the
real
stuff
here.
So
just
short,
really
information
about
Easter.
So,
as
you
know,
Easter
is
being
is
be
a
lit
to
the
control
plan
and
data
plan.
The
data
plan
is
composed
of
a
set
of
intelligent
proxies
that
are
being
deployed
as
a
side,
cars
and
those
side.
Cars
are
controlling
the
communication
between
the
microservices,
a
controlled
plan.
B
Concei
content
consists
of
yo
components
which
are
the
patent.
We
will
see
later
how
it
influenced
the
startup
time
the
pilot
that
is
responsible
for
the
configuration
of
the
sidecars,
the
mixer,
that
is
responsible
for
the
policy
in
the
telemetry
and
citadel
that
is
responsible
for
the
strongest
ant,
occasional
authorization
and
the
identity
management
of
the
service
mesh.
So,
let's
see
how
SEO
is
coming
into
the
picture.
This
is
a
let's
go
back
to
the
diagram
that
we
saw
before.
So
what
is?
Is
adding
east
your
heading?
B
B
This
is
a
yeast
unit
in
this
is
an
init
container
that
is
being
added
as
part
of
the
pod.
It
is
coming
before
all
the
containers
are
coming
and
it
is
responsible
for
the
to
configure
the
pod
network
by
two
interest
intercept
the
network,
so
the
network
top
traffic
to
go
through
the
end
void
proxy.
It
is
doing
it
by
configuring,
the
IP
table
inside
the
pod,
Network
and
east
your
proxy.
This
is
a
container
that
is
being
added
to
the
pod
and
is
running
actually
the
L
values
a
sidecar
proxy.
The
pod.
B
This
is
your
proxy,
is
getting
all
the
configuration
from
the
pilot.
So
it's
communicating
with
the
pilot
using
XDS
interface
and
it's
whenever
it's
getting
all
the
configuration
it's
using.
The
readiness
probe
it's
it's
informing,
the
kubernetes,
the
couplets,
that
the
pot
is
ready
and
it
can
start
getting
requests.
B
C
So,
just
to
explain
a
little
bit
about
the
tooling
involved
in
what
you're
seeing
in
front
of
you.
So
we
have
a
watcher,
that's
running
inside
the
cluster,
looking
at
the
pods,
that's
but
they're
being
created
and
looking
at
the
Tanner's,
and
it
actually
goes
ahead
and
creates
distributed
tracing
spans.
C
So
things
like
Jager,
if
you
know
it
or
Zipkin,
we
actually
based
on
those
events,
those
status
changes
that
we
see
we
create
spans,
and
then
we
can
visualize
that
in
a
very
easy
way,
you'll
see
that
you
have
for
each
one
of
the
containers,
one
or
more
spans.
It's
basically
from
the
time
that
they
were
first
created.
C
The
container
was
first
created,
first
appeared
until
it's
transitioned
in
its
state
to
being
either
complete,
if
it's
in
in
each
container
that
needed
to
do
some
setup
and
then
over
or
it's
switching
into
ready,
running
or
whatever.
Okay.
What
we
do
is
when
we
see
it.
We
start
the
span
whenever
the
container
changes
status
from
starting
downloading
image,
whatever
whenever
it
changes,
we
start
and
close
the
spans
and
therefore
we
can
actually
see
where
is
the
time
being
spent
inside
the
different
containers.
C
The
reason
that
we
attribute
it
to
the
overhead
of
the
couplet
and
kubernetes
is
when
you
will
see
in
a
second:
we
remove
the
init
containers.
Suddenly,
all
of
a
sudden,
the
other
containers
are
going
to
be
extended
by
the
two
seconds
that
are
currently
attributed
to
into
containers.
So
there's
like
a
two
second
overhead
that
we
can't
really
do
anything
about
it.
We
don't
know
what
component
inside
qubit
is
actually
responsible
for
that,
but
it's
not
something
that
has
to
do
with
a
steal
or
your
own
workloads.
Okay,.
C
Okay,
so
we
just
gave
you
a
steal
which
gives
you
benefit
or
service
mesh
that
gave
you
benefits,
but
we
also
gave
you
an
extra
five
seconds
which
I'm
sure
everybody
who
just
wants
to
get
rid
of
right.
It's
not
a
good
thing
to
have
so.
Can
we
improve
I?
Think
the
short
answer
is
yes,
we
can,
and
there
are
several
techniques
that
you
can
do
and
you
can
combine
them
to
get
most
of
the
added
time
back.
C
What
can
you
do?
The
first
option
is
to
run
the
East
EOC
and
I
and
we'll
go
into
detail
about
each
one
of
those
okay.
So
if
T
of
C
and
I
is
a
different
way
to
do
the
redirection,
not
using
the
East
unit
component,
you
saw
a
second
ago,
but
instead
of
it
using
an
e
steel
provided
CNI,
a
kubernetes
network
interface,
container
network
interface,
implementation,
which
doesn't
alter
whatever
C
and
I
you
already
have.
It
runs
in
addition
to
it.
So
if
you're
running
calico
flannel
cilium,
whatever
it
runs.
C
In
addition,
the
only
purpose
of
our
Sienna
is
to
reprogram
a
steel
that
gives
you
back
three
seconds.
Nice
improvement.
Next,
we'll
take
a
look
at
playing
around
with
the
readiness
probe.
So,
as
we
said,
the
qubit
is
going
to
test
whether
pods
are
ready
to
serve
traffic
and
it
checks
it
on
a
schedule.
If
you
shorten
that
schedule,
you're
not
increasing
the
load
by
match,
but
you
are
saving
time
because
they
become
ready
sooner.
C
We
can
talk
about
static
proxy
configurations,
as
you
remember.
As
soon
as
n,
we
starts
up
it's
going
to
call
into
the
control
plane
and
get
its
configuration,
that
configuration
is
dynamic
and
if
your
use
case
warrants
a
static
configuration
or
it
makes
sense
to
have
a
static
configuration
in
your
case,
then
you
can
program
it
and
there
are
ways
to
ride
to
override
the
dynamic
nature
of
the
configuration
just
have
a
static
configuration.
C
We'll
show
how
to
do
that
as
well
gives
you
back
up
to
two
seconds
and
if
you
are
really
really
really,
you
know
down
to
the
last
millisecond
and
you
absolutely
need
to
have
that.
Instead
of
having
dynamic
injections
through
the
admission
web
hook,
you
can
do
that
statically
in
your
CI
CD,
by
running
easty
or
control
inject
and
getting
all
of
the
setup
done
ahead
of
time.
C
So
eesti
of
c
ni.
As
we
said,
it's
not
a
real
c
ni.
It's
not
as
the
United
is
responsible
for
the
networking
in
the
cluster.
It's
also
it's
only
a
c
ni
that
are
responsible
for
running
the
same
iptables
magic
setup.
That's
needed
to
redirect
traffic
from
the
workload
into
the
east
EO
proxy
inside
the
pod.
There
are
benefits
to
it.
We
just
talked
about
getting
those
two
three
seconds
back,
that's
one
benefit.
C
The
other
benefit
is
because
all
of
the
set
up
work,
all
of
the
networking
privileged
operations
happens
ahead
of
time
outside
of
your
pod.
The
pod
doesn't
need
special
privileges.
It
doesn't
need
to
run
with
capabilities
that
are
typically
reserved
for
administrations
of
network
functionality.
This
all
happens
under
the
CNI
as
part
of
the
couplet,
so
no
need
to
leak
extra
privileges
into
your
pod.
C
Another
plus,
the
downside
is
that
because
the
CNI
programs,
all
of
the
redirection
to
envoi
before
NY,
actually
starts,
if
you
have
any
init
containers
that
need
to
run
and
they
need
to
have
access
to
the
network,
basically,
that
traffic
could
get
black
hole
because
it
will
be
redirected
to
n
void
and
there's
nothing
there.
Okay,
so
that's
the
downside.
There
are
ways
to
mitigate
that
downside
if
you
have
any
containers
that
don't
need
any
kind
of
network
access.
C
Obviously
it's
not
a
problem
if
you
have
in
it,
containers
that
need
ports
or
IP
addresses
which
are
not
shared
or
do
not
overlap
with
what
is
being
used
by
your
actual
workload.
You
can
tell
east
EO
as
part
of
the
configuration
to
skip
those
basically
say:
don't
trap
those
traffic
flows
and
therefore
they
will
go
to
where
they
should
be
going.
C
So
if
we
apply
a
steal
in
it,
you'll
see
that
we
saved
all
the
way-
and
you
will
see
here
those
two
seconds
that
we
told
you
about
before
now
are
attributed
to
the
workload
and
the
East
EO
proxy.
So
the
the
workload
container,
which
is
a
very
simple,
no
op
container
in
our
test
because
we
didn't
want
to
get
you
know:
noise
instability
into
our
system.
It
was
extended
from
about
1.9
to
3.7.
Similarly,
the
East
EO
proxy
startup
time
expanded
as
well,
so
that
was
the
sto
CNI.
It
is
currently
in
development.
C
It's
available.
You
can
try
it
it's
not
a
stable
API.
Yet
so,
if
it's
a
production
workload
recommend
playing
with
it
but
holding
off
on
actual
usage
for
a
little
while
next,
as
we
said,
there
is
a
readiness,
basically
kulit
is
going
to
probe
the
workload
and
the
East
your
proxy.
That
was
added
to
see.
Are
you
ready
to
accept
traffic
and
there
is
an
initial
delay
and
there's
also
a
period
of
how
quickly
it's
going
to
test
it
right?
Now,
it's
a
two-second
delay
and
you
can
configure
it
to
lower.
C
What
we
see
in
practice
is
usually
the
first
probe,
the
one
that
happens
after
the
grace
period
does
not
succeed,
but
the
next
one
which
happens
after
3
seconds
succeeds.
So
if
you
change
the
period,
which
is
a
very
harmless
change
in
our
view,
because
you're
only
heading
like
one
ping
every
now
and
then
to
test
instead
of
doing
this
on
a
two-second
schedule,
you're
adding
one
network
all
on
a
one-second
schedule.
C
The
same
configuration
that
we
talked
about
here
is
going
to
be
applicable
to
all
of
the
other
methods
that
we
talked
about.
You
can
either
change
this
when
you
install
through
helm
and
you
can
override
the
values,
as
you
can
see,
and
on
the
slide.
You
can
also
add
it.
The
sidecar
injection
template
to
set
the
readiness
probe
to
one
second,
and
it's
also
up
there
and
in
the
case
of
the
readiness
probe,
there's
also
an
HDL
annotation,
which
means
that
you
can
apply
it
on
a
port
by
pod
basis.
C
You
don't
need
to
do
it
for
all
of
your
pods.
You
can
actually
get
it
done
on
a
specific
pod.
The
first
two
methods
are
going
to
do
it
globally
right.
So
if
you
do
it
on
helm
from
the
installation
onwards,
it's
all
going
to
change.
If
you
do
it
from
the
sidecar
container,
template
injection
every
new
container
they're
going
to
get
deployed
will
get
the
new
readiness
value.
So
from
this
point
on,
and
if
you
do
it
on
our
one
by
one
cases,
then
you
have
it
that
way.
C
Next
option
that
we
played
around
with
was
to
instead
of
waiting
for
the
East
EO
proxy
readiness
there's
another
component
that
sits
next
to
the
proxy
and
basically
makes
the
decision
whether
or
not
it's
ready
or
not,
these
steel
proxy,
the
product.
The
pilot
agent,
is
going
to
see
if
the
configuration
was
already
download
did
nyu
reconfigure
itself.
Can
we
start
serving
traffic
instead
of
doing
that,
you
can
redirect
readiness
probe
at
envoi,
directly
and
basically
say
to
envoi.
Are
you
ready
instead
of
asking
is:
do
is
envoi
ready?
C
This
can
save
you
a
little
bit
more
and
it
is
worthwhile
in
some
cases.
The
problem
with
this
method
is
that
if
envoi
is
ready
because
it
had
its
startup
config
parsed
and
the
configuration
is
correct,
but
it
didn't
get
all
the
cluster
information.
Yet
that
means
that
any
kind
of
connectivity
into
it
might
be
a
problem
or
any
kind
of
connectivity
out
of
the
workload
is
going
to
be
a
problem.
C
C
If
I
wanted
to
say
anything
else
on
this
yeah,
so
so
the
last
thing
you
can
do
is
you
can
decide
to
disable
the
readiness
probe
completely,
and
this
is
certainly
not
something
that
we
would
recommend
doing
about.
What
we
did
do
is
we
wanted
to
see
if
there
was
what-if
envoi
or
the
co
proxy
was
ready
immediate.
How
much
could
we
save
right?
So
it's
only
to
motivate
the
fact
that
we
wanted
to
try
a
static
configuration
right
now.
C
It
takes
time
because
envoi
needs
to
connect
into
the
control
plane,
download,
stuff
process
stuff,
combine
it
manipulate
it
load.
It
reconfigure
itself
what
if
we
gave
invoice
all
the
configuration
that
it
needed,
so
it
was
immediately
ready
right,
so
the
amount
that
you
can
save.
We
simulated
that
by
actually
disabling
the
readiness,
which
means
it's
ready
when
it's
started
right,
so
there's
no
need
to
ping
it
and
see
if
it's
ready
or
not
so
another
one.
Second,
that
you
can
actually
cut
down.
C
What
do
we
need
by
the?
What
do
we
mean
by
the
static
the
static
configuration?
Anybody
has
a
bunch
of
XDS
interfaces.
Cluster
discovery,
endpoint
discovery,
secret
discovery,
listen
so
a
whole
bunch
of
dynamic
stuff
that
it
can
get
it's
a
programmable
proxy
and
you
don't
necessarily
need
all
of
that.
Dynamis
'ti
in
a
real
system,
for
example,
if
you're
using
something
like
a
native
everything,
goes
from
the
services
through
the
ingress
gateway.
C
So
if
your
topology
is
known
in
advance,
if
you
know
your
dependencies
well
in
advance,
as
we
said,
K
native
is
being
one
example.
It's
not
easy
to
configure.
It
is
something
you
can
actually
configure
today
if
you
wanted
to,
but
it's
not
friendly.
It
is
something
that
we
need
to
take
a
look
at
as
the
co
team
and
figure
out.
C
If
we
want
to
expose
that
at
least
for
the
use
cases
where
it
makes
sense
because,
as
we
said,
it
can
cut
down
another
two
seconds
of
startup
time
and
you
can
actually
have
a
combination
of
a
static
and
dynamic
config
you
could
have.
Let's
say
all
of
the
clusters
are
known
in
advance:
I'm
going
to
have
a
static
CD
s,
but
endpoints
I
want
to
populate
at
runtime,
so
I'll
have
a
dynamic,
EBS
and
then
kind
of
combinations.
C
All
of
these
require
more
programming,
and
we
have
some
ideas
on
what
we
can
do,
for
example,
start
with
a
static
config
and
then
overlay
it
with
the
dynamic
properties
as
they
become
known
asynchronously
in
the
background,
as
opposed
to
having
envoi
actually
block
and
wait
until
it
gets
the
full
config
two
methods
for
doing
this.
If
you
wanted
to
override
the
default
configuration
or
have
additional
properties
that
go
into
the
default
startup
config,
you
basically
create
an
invoice
configuration
file,
which
means
you
need
to
understand
invoice
configuration
in
detail.
C
It
can
be
complicated,
but
if
you
are
adventurous
and
you
can
grok
the
entire
configuration
create,
it
create
a
file
store
that
file
in
the
config
map
and
then
annotate
the
pods
to
use
the
startup
config
that
you
created
instead
of
the
default
startup.
Config
second
method
is
to
completely
replace
the
startup
configuration,
so
previous
one
was
gave
you
the
ability
to
merge
additional
properties
or
override
properties
if
they
were
defined
in
your
configuration
as
well.
If
you
want
to
do
this
instead
by
completely
overwriting,
then
again
you
create
a
full
configuration
file.
C
In
that
way,
you
don't
need
the
admission
web
builder
mutating
webhook
inside.
So
in
summary,
we
saw
that
we
added
five
seconds
or
so
to
the
startup
time,
and
if
you
use
these
TOC
ni
three
seconds,
the
majority
of
that
is
already
coming
back
at
you,
another
half,
a
second
by
shortening
the
probe,
the
readiness
probe.
C
If
you're,
okay,
with
actually
retrying
communications,
you
can
cut
down
another
half
a
second
by
changing
it
from
the
pilot
agent,
startup
probe
to
the
redness
probe
and
for
itself
study
configuration
again
helpful,
very
helpful,
but
it
does.
It
is
a
complicated
thing,
so
proceed
with
caution
and
the
last
one
I
think
is
mostly
for
fun.
D
C
D
D
B
C
E
C
D
Sure,
I'll
probably
add
get
added
to
the
channel
right
now,
I'm
still
getting
some
things
ready,
yeah.
This
is
awesome,
I
really
liked
it,
but
specs
I
mean
devil
is
in
the
details.
I
mean
it
is
nice
that
you
also
spelled
out
what
could
help
with
each
of
the
microsecond
you
know
cut
down
and
where
it
could
help
I
like
that
as
well.
Yeah
awesome.
Thank
you.
C
F
C
So
the
problem
with
downloading
and
counting
that
time
is
really
it
is
out
of
our
control
right
and
if
you
have
a
one
gig
to
Gig,
image
obviously
is
going
to
take
much
longer
than
a
20
Meg
image
and
when
we
do
a
performance
comparison
or
we
try
to
optimize
it.
If
the
numbers
are
going
to
be
skewed
towards
the
large
download
time,
everything
else
would
be
noise
right.
So
that's
why
we
we
try
to
eliminate
that
from
the
picture,
and
it's
also
what
kubernetes
tries
to
do
with
the
SLO.
C
It's
saying
all
the
images
are
cached,
because
if
you
have
too
much
variance
it's
outside
of
our
control,
nothing,
we
can
do
about
your
image
size.
Your
transfer
rates,
whatever
I
know
that
there
are
some
projects
not
related
to
East
you
in
any
way,
I
think
it's
a
generic
kubernetes
question
that
try
to
optimize
the
download
by
doing
some
kind
of
a
peer-to-peer
transfer.
So,
instead
of
going
to
the
registry
taking
it
from
nearby
hosts,
if
they
have
it,
cached
I,
don't
remember
the
names
of
the
projects,
but
they
are
some
out
there.
C
I
think
startup
time
makes
sense
to
worry
about,
and
it's
important,
especially
if
there's
somebody
waiting
for
that
response
time.
So
it's
it's
important
if
you
can
cut
down
on
your
image
transfer
by
all
means,
try
and
do
that.
You
know
it
depends
on
your
runtime
environment,
go
statically,
compiled
executables,
much
smaller
than
doing
from
Lubuntu
and
then
getting
the
entire
JVM
in
there
and
whatever
right.
So,
if
you
can
do
anything
about
it,
it
helps
more
questions.
Yes,.
E
C
So,
as
I
said,
we
are
looking
at
the
start
up
performance.
It's
a
limited
view.
I
think
that
it's
not
that
we
decided
that
it's
a
bad
idea
to
have
a
service
mission.
It's
obviously
a
trade-off
you're
getting
benefits
out
of
it,
and
if
you
need
it,
then
you
want
to
use
it
and
I
think
our
focus
is
actually
trying
to
optimize
up
to
the
point
that
it's
not
painful
anymore.