►
From YouTube: Serverless Platform for Large Scale Mini-Apps: From Knative to Production - Yitao Dong & Ke Wang
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
Serverless Platform for Large Scale Mini-Apps: From Knative to Production - Yitao Dong & Ke Wang, Ant Financial
Serverless architecture is getting increasingly popular. However, developers are still experiencing pain points that hold them back from using it in production, like portability, interoperability and debugging. At Ant, Ke and Yitao are committed to building a mission-critical serverless platform that reduces those frictions, which is now supporting large scale mini-apps. Ke and Yitao will share the key workloads they are building with serverless and how they address pain points in production by expanding Knative. They will introduce technical details of adopting Knative with secure container runtime and reinventing Knative control/data plane, which largely saves deployment and operation efforts to enable serverless in Kubernetes clusters. The chat will also cover a quick demo to illustrate improved serverless app lifecycle management, 0-M-N-0 autoscaling performance and operation workflow.
https://sched.co/Uad9
B
A
A
Before
we
get
started,
I
like
to
ask
two
quick
questions:
first,
how
many
of
you
have
used
illness
for
a
POC
or
demo
in
cloud?
Please
raise
your
hands
quite
a
lot,
so
how
how
many
of
you
have
given
that
in
production,
please
raise
your
hands.
I
saw
fewer
hands
so
foolís
involving
very
very
fast.
If
you
take
a
look
at
projects
listed
in
the
CN
CF
landscape
for
service,
you
will
be
surprised
as
its
progress.
A
Why
is
so
blur
so
attractive?
We
already
have
containers,
kubinashi
and
so
many
cool
features.
What
makes
a
difference,
in
my
opinion,
surplused
attracts
me
for
the
three
reasons.
The
first
is
that
I
take
care
of
the
infrastructure,
so
we
no
longer
need
to
worry
about
only
focus
on
business.
Logic,
second,
is
that
it
supports
key
r20
when
there's
no
workload
and
the
coast.
Our
time
is
really
fast
when
the
new
traffic
comin
comes
in
again.
A
A
Because
of
these
advantages,
serverless
is
useful
in
some
use
cases
in
real
world
first
full
public
cloud.
It
is
suitable
for
developer,
individual
developers
and
small
teams
because
they
want
to
get
things
started
as
fast
as
possible,
and
they
won't
the
workload
just
scare
to
zero
to
save
the
cost.
It
also
suitable
for
some
industry
cloud.
An
industry
cloud
is
some
company
or
organizations
that
builds
its
platform
to
share
the
infrastructures
and
resources
to
other
partners,
so
they
won't
have
to
build
infrastructure
again.
A
Instead,
they
can
collaborate
and
build
a
player
applications
servers
can
help
to
reduce
the
cost
to
the
minimize
own
premised.
Customers
also
find
serve
less
useful
first,
you
can
imagine
that
company
is
doing
some
marketing
campaigns
set
a
time
critical
before
that
the
operation
teams
will
have
to
pre,
buy
some
machines
and
say
who
has
made
the
number.
But
if
the
consumptions
goes
beyond
that
number,
they
will
cause
some
online
problems.
If
that
goes
down
lower
than
the
number,
it
means
that
there'll
be
some
waste
of
the
results.
A
A
Also,
it
provides
a
new
way
to
transform
our
monolithic
applications
to
elastic
applications
for
those
legacy.
Apps
it's
difficult
to
take
it
into
micro
service,
auto
cries:
we
can.
We
can
gradually
divide
them
and
select
those
functionalities
view
them
review
them
with
functions.
Api's
workflows,
gradually
turn
them
into
elastic
application.
A
A
The
first
concern
is
a
performance
so
far
as
I
know,
running
tentative
on
kubernetes
takes
a
lot
of
long
time
for
the
code
start
and
it
even
get
worse
when
the
cluster
scales.
Second,
there's
a
cost.
As
a
maintainer
of
the
platform,
you
still
have
to
take
care
of
each
layer
of
settlers
and
its
dependencies
for
mesh
and
kubernetes.
A
B
Yes,
thank
you
so
in
this
session
today
we're
going
to
share
with
you
how
we
tackle
of
some
of
the
above-mentioned
problems
as
and
financial,
and
some
of
our
heart
and
experiences.
When
we
are
trying
to
build
a
service
platform,
we
are
going
to
elaborate
on
how
to
boost
the
performance
of
cane
native,
drastically
cut
the
code,
start
latency
and
then
we're
going
to
talk
about
how
to
reduce
the
cost
of
running
a
service
platform.
B
Finally,
we
will
take
a
look
at
how
to
scale
the
service
platform
horizontally
and
solve
the
problems
that
arise
when
we
run
a
service
platform
at
scale.
First,
let's
talk
about
performance,
as
some
of
you
may
already
know.
When
the
kubernetes
cluster
gets
larger
and
larger
is
performance,
deteriorates
I
have
done
some
tests
so
with
a
kubernetes
cluster
of
about
1,000
node,
it
actually
takes
a
long
for
the
scheduling
process
to
finish
our
average.
It
would
take
about
10
seconds
to
schedule
a
pod
to
a
note,
and
then
there
is
like
docker
image.
B
A
Seconds
is
totally
unacceptable
for
individuals
website,
as
mentioned
just
now.
The
key
value
will
be
the
the
code
start.
Time
is
very
fast,
but
if
a
part
takes
like
20
20
seconds
to
start
most
of
the
times,
users
will
find
his
service
is
cannot
be
visited
so
that
user
experience
must
be
very
bad.
Yes,.
B
Just
imagine
if
a
user
was
for
20
seconds
before
the
website
even
starts
loading.
That
is
unacceptable
right
and
the
programmer.
Not
wanting
this
to
happen.
Maybe
we
will
configure
this
service
have
formed
to
to
always
keep
at
least
one
replica
and
that
you
never
scale
to
zero.
By
doing
so,
they
actually
defy
the
purpose
of
server
lists,
because
now
they
cannot
get
the
benefit
of
scaling
to
zero
and
they
will
still
be
charged
even
if
nobody
is
going
to
use
their
service.
B
So
that
is
going
to
be
a
deal-breaker
and
our
engineer
team
must
solve
this
problem,
so
we
actually
came
up
with
a
very
creative
idea
to
solve
this
problem
and
as
far
as
I
know,
this
is
an
original
idea.
How
do
we
do
that?
We
use
something
called
a
port
full.
What
is
potful?
It's
like.
We
just
start
up,
20
to
100
pots
or
another
number
yeah.
We
just
start
having
some
thoughts
and
let
them
sit
there
without
doing
anything,
and
when
the
service
platform
demands
the
creation
of
a
new
pot.
B
Instead
of
starting
up
a
pot
from
scratch,
we
look
into
the
pot
pool
and
find
one
of
the
pots
that
that
is
in
the
ready
state
that
is
in
a
standby
state
and
ready
to
be
used,
and
we
then
adopt
that
pod
and
the
injection
the
user
code
into
that
pod,
so
as
to
run
the
user
code.
By
doing
is
this,
where
you
can
effectively
skip
the
the
cost
of
like
scheduling
a
pod
or
registering
a
polity,
real
service
measure,
etcetera.
We
can
save
a
lot
of
time.
It's
actually
blazing
fast.
You.
A
Pools
we
have
used
in
daily
life,
like
polls
of
four
database
connections,
thread
pools,
so
they
have
been
proven
to
enhance
the
performance.
So
basically
what
Paul
works
in
the
same
way.
So
so
far
as
we
know
that
there
is
no
like
community
project
on
this
part,
so
we
started
idea
and
implement
for
scratch.
Yes,.
B
We
had
to
implement
this
idea
from
scratch,
using
mixing
the
object
for
pattern
and
kubernetes
pots.
How
do
we
implement
it?
I'm
going
to
give
the
details
here.
So
the
first
thing
that
you're
gonna
do
is
that
you
define
your
CR
DS.
You
create
two
to
see
our
DS
for
this
task.
What
we
are
actually
doing
here
is
trying
to
add
a
new
type
of
workload
to
kubernetes,
so
I
think
that's
the
name
of
our
CR.
They
should
conform
to
what
kubernetes
already
has
to
provide.
B
So
everybody
knows
that
kubernetes
has
got
deployment
and
the
replica
set.
Let's
just
call
our
customer
resource
server,
less
deployment
and
the
server
less
terrific
asset.
Not
only
should
the
name
be
Simula,
the
specs
should
also
be
very
similar
to
the
original
kubernetes
workloads,
because
what
we
are
actually
trying
to
do
is
to
fork
their
code
and
only
modify
some
of
the
behaviors.
So
after
we
are
done
with
defining
the
CR
DS.
The
next
step
is
to
do
some
coding.
We
can
just
afford
the
controller
manager
from
kubernetes.
B
For
those
of
you
who
do
not
know
control,
the
manager
is
a
kubernetes
component
control
plan
component
that
we
consult
or
handles
the
the
deployment
or
replica
says
resource
in
kubernetes
and,
for
example,
we
have
creates
pods
when
it
finds
out
that
the
rick
has
the
wanted.
Replicas
in
horrific
acid
is
less
than
the
actual
replica.
So
we
just
for
his
code
and
we
changed
one
of
his
behavior.
B
The
the
behavior
that
we
change
is
that,
instead
of
sending
a
poster
request
to
the
API
server
to
create
a
pole
from
scratch,
we
now
let
us
send
a
get
request
to
the
API
server,
with
a
label
selector
to
find
out
about
other
standby
ports
and
pick
one
of
the
port
in
that
list
according
to
our
policy
and
adopt
that
port
to
run
the
user
code.
Basically,
if
you
inject
the
user
code
into
that,
the
run
import
well,
the
last
part,
the
the
injecting
the
user
code
into
the
running
part,
is
the
interesting
one.
B
How
are
we
going
to
do
that?
There
are
some
possible
ways.
Well,
the
first
one
is
the
easiest
one.
We
can
use
something
called
a
code
loader,
so
so
what
is
a
code?
Loader?
A
coal
loader
is
a
program
whose
sole
purpose
is
to
like
sit
in
the
container
and
the
wait
for
instructions
from
the
outside.
It
can
get
instructors
from
the
outside
and
know
where
to
download
the
code,
and
after
it's
done
downloading
the
code,
it
will
execute
the
code.
B
So
when
the
controller
wants
to
inject,
for
example,
a
Java
file
into
a
running
container,
you
can
just
send
an
HTTP
request
for
likes
and
jrkz
request
to
the
code
loader
to
inform
the
code
loader
about
the
URL
of
the
user
code
package.
Then
the
cold
water
will
just
download
the
image
and
execute
it.
Then
the
user
program
will
be
up
and
running.
Well.
Some
of
you
may
say
that
this
is
not
a
native
way
to
do
things,
because
we
are
using
HTTP
requests
and
our
pcs.
B
We
should
be
using
declarative
ways
to
do
things
right,
I
agree.
So
maybe
we
can
leverage
another
feature
from
kubernetes
that
has
the
downward
api
one
of
the
future.
One
of
the
future
of
downward
api
is
that
it
can
map
the
annotations
of
a
pod
to
a
file
that
sits
that
stays
in
a
container.
So
when
the
controller
wants
to
notify
the
code
loader
of
the
URL,
it
just
updates
the
port
and
notation.
It
just
writes
the
URL
into
that
pause,
annotation
and
then
the
file
in
the
container
will
change
the
Ko'olau.
B
They
will
watch
for
changes
of
that
file
in
The
Contender,
using
mechanisms
like
I
notified
and
when
it
has
found
out
that
the
the
content
has
changed.
It
will
read
the
content
against
the
URL
and
do
things
just
like
the
old
way.
Okay
sounds
good,
but
actually
there's
a
limitation
to
this
method.
Is
that
now
we
limit
the
users
to
running
called
packages
such
as
those
jar
files.
What
if
the
user
doesn't
want
to
run
called
packages,
but
instead
they
want
to
run
the
images.
B
So
we
got
to
figure
out
some
other
ways.
Well,
one
possible
way
and
the
one
easy
way
is
to
use
maybe
a
fumarole
container.
If
humoral
containers
is
a
quite
new
group,
an
athiest
feature
that
allows
the
pod
to
run
a
new
contender
without
restarting
the
pod
or
without
recreating
a
pod,
so
basically
you're.
The
controller
can
just
inject
a
new
container
into
a
running
pod
and
the
container
will
start.
However,
this
is
actually
not
a
recommended
way
to
use
a
funeral
containers
and
there
are
many
side
effects,
so
this
solution
is
no
good.
B
What
we
do
here
at
and
financial
is
that
we
forked
and
we
modified
the
code
of
cubelets,
which
has
the
no
the
demon
that
runs
on
every
kubernetes
worker
to
allow
the
dynamic
substitution
of
containers
at
runtime.
So
after
we
modify
this
code,
the
herbalist
will
get
informed
of
the
spec
change
of
the
container
and
when
he
sees
that
the
container
spec
has
changed
it
will
it
will
just
cure
the
old
container
and
start
a
new
contender
and
add
the
container
back
to
that
pod.
B
Again,
some
of
you
may
consider
is
this
a
bad
practice,
because
the
community
edition
of
kubernetes
cannot
do
this
right,
but
as
far
as
I
am
concerned,
I
think
we
are
not
directly
providing
a
crepinette
service
to
the
end-user.
We
are
just
trying
to
build
a
service
platform
on
top
of
kubernetes,
so
I
think
that
may
be
a
good
solution,
because
this
is
a
solution
with
the
least
the
side
effect.
Your
mileage
may
vary
again.
A
Okay,
another
important
aspect
of
pole
pool
is
the
size
of
the
pool
why
it
is
so
important.
You
can
imagine
that
if
the
size
goes
to
large,
it
means
that
its
large
be
on
the
consumption
step.
It
costs
the
waste
and,
if
nice,
girls
too
small,
it
will
function
like
cache
miss.
It
means
that
most
of
the
time,
the
controller
will
not
be
able
to
schedule
the
workload
into
a
ready
part.
So
the
societies
are
really
important.
How
we
achieve
this,
we
design
an
algorithm
that
automatically
adjust
the
size.
A
According
to
the
usage,
this
usage
is
calculated
from
the
parsed
windows,
so
in
English
first
time
windows
will
get
the
average
number
of
the
estimated
number
for
the
pod
in
each
past
time.
Windows
and
for
this
moment,
will
get
the
average
of
the
past
time
windows.
So
a
good
algorithm
will
turn
out
the
results
shown
as
shown
in
this
picture.
As
you
can
see,
there
are
two
lines.
The
green
one
shows
the
size
of
the
container
pool.
While
the
blue
one
shows
the
consumptions.
A
You
can
see
that
these
two
lines
are
very
close,
meaning
that
the
size
of
the
pool
is
like
of
like
all
the
time
its
covers
consumptions
but
at
the
same
time
minimize
the
waste
okay.
So
after
all
these
optimizations
performance,
we
like
show
the
results
we
have
achieved
here
for
a
simple
Java,
HTTP
server
application,
so
co-star
time
from
goes
down
from
20
minutes
to
1.8
20
1.8
seconds.
It's
a
surprisingly
90%
improvement.
A
B
I
was
also
very
pleased
with
the
result
that
we
were
able
to
achieve
and,
let's
think
about
some
other
applications.
Some
other
use
cases
about
this
thoughtful
thing.
I
have
listed
a
few
here
like
service
mesh
micro
services
or
frameworks
that
takes
a
long
time
to
start
or
services
that
requires
to
download
a
lot
of
data
before
you
can
be
started.
I
think,
that's,
generally
speaking,
any
system
that
requires
a
long
time
to
pre-warm
can
benefit
from
such
an
approach,
and
that
is
why
I
do
think
that
this
port
for
pattern
can
be
very
useful.
B
I
believe
that,
with
this
thing,
kubernetes
the
applications
running
on
kubernetes,
they
can
not
only
be
reliable
and
observable,
but
they
can
also
be
very
performant.
That
is
why
I
think
maybe
someday
we
should
set
up
like
especially
especially
interest
groups
to
to
formalize
things
and
to
push
this
idea
further.
I
believe
it
is
going
to
be
beneficial
to
the
community
and
to
everyone
yeah.
A
Ok,
next,
we
are
going
to
talk
the
problem
about
cost
reduction.
As
you
know,
Canadia
is
a
collection
of
deployments
running
on
kubernetes.
It
contains
a
lot
of
components
like,
as
shown
here,
like
cognitive
controllers,
activator
autoscaler.
It
also
has
a
dependencies
for
a
full
mesh,
see
steel
and
ingress
gateway
for
kubernetes,
like
Kublai,
this
control
manager.
Something
like
that.
The
problem
here
is
that
all
both
the
cumin,
a
competitive
component
and
the
dependencies
are
very
costly.
A
B
B
Now
there
is
a
shared
kubernetes
cluster
and
there
is
going
to
be
a
shared
set
of
connected
components,
running
on
that
shared
kubernetes
cluster,
and
then
there
are
going
to
be
many
many
many
tenants
and
now
the
only
thing
that
attendance
does
is
to
create
his
or
her
own
cognitive,
app
and
then
the
share.
The
key
native
controller
will
get
notified
of
that
new
app
and
the
reconcile
that
new
app
in
the
do
everything
just
the
all
the
way.
B
So
how
do
we
achieve
multi-tenancy?
Or
how
do
we
allow
multiple
users
to
share
one
single
kubernetes
cluster?
Without
interfering
each
other,
there
are
again
two
ways
to
do
this,
so
the
first
way
is
the
easiest
and
the
most
practiced
way
it
is
named,
based
either
on
a
Sorak
name,
space
based
isolation
to
very
simply,
we
just
create
one
name
space
for
one
tenant
and
set
up
the
our
bags
so
that
the
tenant
will
only
have
access
to
his
or
her
own
namespace
and
no
privilege
to
access
the
namespaces
of
other
tenants,
Wow
I.
B
We
do
this
by
adding
an
extra
layer
of
directory
to
the
eg
CD,
which
is
a
storage
engine
that
is
behind
the
kubernetes,
and
we
just
store
the
data
of
each
tenant
to
that
extra
directory
to
innovation,
their
own
directory
right,
and
by
doing
this
we
can
achieve,
we
can
make
a
fully
multi
tenant
kubernetes
so
that
everything
can
be
isolated
and
supports
multi
tenant.
There
are
a
lot
of
technical
details
here
which
I'm
not
going
to
cover
in
this
talk.
Ok,
that's
about
the
next
stage.
You
will.
A
Also
have
other
ways
to
reduce
the
cost.
You
can
choose
to
use
a
class
autoscaler
provided
by
communities
and
to
set
the
scaling
rules.
It
will
do
the
release
and
provision
notes
by
itself,
and
you
can
also
choose
for
equivalent,
along
with
cloud
services
that
is,
provides
home
demand
container,
like
Alibaba
elastic
container
instance.
Yes,.
B
Yes,
so
whether
you
are
using
a
container
on
the
mount
service
or
whether
you
are
just
using
elastic
computing
service,
you
can
save
the
costs,
because
when
you
are
using
their
service,
you
are
actually
sharing
a
very,
very
big
resource
pool
with
all
the
other
customers.
So
the
more
you
share,
the
less
the
waste
and
so
the
lower
the
costs
right.
A
But
there
is
catch
here,
things
continuous
are
easy
to
use
and
fast
can
easily
be
integrated
into
our
systems.
But
security
is
a
potential
problem
here,
since
they
share
the
same
Linux
kernel
and
it
may
cost
some
security
issues
like
if
one
malicious
container
take
over
the
host
that
it
will
damage
caused
damage
to
other
containers
contain
turn-ins
containers.
So
you
know
what
we
are
going
to
approach
this
problem
is
that
we
are
going
to
use
cut-up
containers.
A
Cut.
Containers
takes
a
different
way
of
addresses.
Is
that
behind
each
pot
it
is
not
actually
continuous,
it's
lightweight
vm's.
It
looks
like
and
feels
like
containers,
but
provide
strong
isolations
so
with
cata
containers,
since
it's
not
sharing
the
Linux
kernel,
so
it
makes
it
difficult
for
any
escapes
and
attacks.
B
Okay,
so
with
the
security
issues
issues
addressed,
we
are
going
to
move
on
to
the
last
part
of
our
presentation
today,
which
is
cluster
at
skill.
So,
as
we
are
serving
more
and
more
service
applications,
the
workload
the
load,
our
control
plan
gets
higher
and
higher
right
at
first,
we
can
try
to
just
add
more
CPU
cores
and
more
gigabytes
of
memory
to
address
this
problem,
and
finally,
one
day
we
will
hit
the
ceiling
where
we
can
no
more
add
more
course
to
a
single
machine.
B
B
Well-Sharpened,
basically
means
is
that
you
divide
the
whole
workload
into
many
many
many
small
partitions
and
you
assign
each
partition
to
a
set
of
control
plan
and
the
less
that
control
can
take
charge
of
that
partition,
so
that
control
fan
will
only
like
take
charge
of
like
1
percent
of
the
total
workload.
That
should
be
fine
right
and
if
the
workload
continues
growing,
we
can
always
add
more
partitions
and
more
control
plan
sets.
That's
how
basically
shouting
that's
basically
how
sharding
works
to
to
implement
is
increment,
isn't
a
native.
B
We
have
to
do
many
things
well.
The
first
thing
is
that
we
got
have
an
upstream
system
upstream
system
needs
to
assign
a
short
ID
to
the
kid
native
applications.
After
the
user
has
created
how
to
choose
the
child
ID,
it
actually
doesn't
matter
it
can
be
based
on
the
user
ID
or
on
the
application.
I
did
Hannah
and
Heidi.
It
doesn't
matter
as
long
as
the
child.
Id
stays
like
as
long
as
it
is
even
across
all
the
Canadian
applications.
B
That
should
be
fine,
and
the
second
step
is
that
we
must
modify
the
controller
to
to
allow
the
petitioning
of
controllers,
that
is
to
say,
the
controller
in
each
control.
Plan
set,
must
only
acknowledge
and
the
process
the
workflows
or
the
resources
with
the
same
pad,
Haitian
ID.
It
should
not
be
able
to
know
about
the
Worr
closing
other
positions,
otherwise,
when
we
are
running
them
at
the
same
time,
one
set
of
control
plan
will
affect
the
other
sets
of
control
fails.
We
cannot
do
that.
B
Okay
and
the
third
thing
that
we
are
going
to
do
is
to
take
care
of
the
data
plan
problems
so,
as
some
of
you
may
know,
Kenny
who
has
got
some
data
plan
components.
For
example,
there
is
cube
proxy
and
there
is
activator
those
data
plan
components
they
send
to
the
metrics
to
the
control
plan,
which
is
like
autoscaler,
and
how
is
the
data
plan
component
supposed
to
know
to
which
control
plan
component
should
they
send
the
HTTP
request?
Here
we
are
going
to
use
the
DNS
to
solve
this
problem.
B
We
are
going
to
set
up
multiple
DNS
domains,
each
with
suffix.
You
know
the
surface
can
just
be
the
partition
ID
and
we
are
going
to
add
a
names
to
that
das
so
that
that
domain
is
going
to
point
to
the
controlling
component
of
that
partition,
and
now
the
data
plan
components
you
do
a
DNS
resolution
to
find
out
which
I
feel
address.
B
It
should
visit
that
takes
care
of
the
problems
that
arises
in
that
they
top
ten
and
finally,
we're
going
to
talk
about
service
mesh
in
service
mesh
to
prevent
data
from
growing
exponentially
we're
going
to
use
a
feature
called
the
service
group.
So
a
service
group
basically
device
the
whole
service
mesh
into
many
sub
meshes
and
the
applications
in
a
sub
mesh
can
only
see
applications
see
the
other
applications
in
the
sublimation.
You
cannot
see
the
applications
from
another
sub
a
mesh.
B
This
way,
the
the
sidecar
proxy,
that
is
a
part
of
the
service
mash
only
needs
to
manage
a
very
limited
amount
of
data,
and
the
performance
can
also
be
better
too.
So
that's
about
concludes
how
we
are
going
to
make
the
service
platform
able
to
scale
out
horizontally,
but
I'm,
sorry
yeah.
Let's
take
a
closer
look
at
how
we
can
implement
like
controller
sharding.
So
how
do
we
do
controller
starting
and
the
make
controller
only
see
the
resources,
the
workflows
that
are
off
the
same
position?
Id?
Actually,
this
is
very,
very
easy.
B
Thanks
to
the
magic
of
kubernetes
labels
lecture.
The
only
thing
that
we
need
to
do
is
that
we
add
a
labels
letter
to
the
informer
of
that
container
to
the
informant
that
the
container
the
controller
uses
and
automatically
the
controller
will
only
see
the
resources
that
matches
that
label
and
ignore
any
other
resource
that
doesn't
match
the
label.
So
maybe
there's
just
the
5
lines
of
code
and
controller
partitioning
is
done.
So
that's
basically
that
basically
explains
how
we
are
going
to
make
the
service
platform
able
to
scale
out
horizontally.
B
If
we
go
out
a
lot
of
the
control
and
components
then
someday,
maybe
kubernetes
itself
is
going
to
be
the
bottleneck.
When
that
happens,
we
don't
we
do
not
need
to
panic.
We
just
need
to
deploy
it,
yes,
being
up
some
more
kubernetes
clusters
and
assign
some
of
the
partitions
to
the
new
kubernetes
cluster
right
it
it
just
acts
as
a
higher
level
of
petitioning.
Yes,
yes,.
A
So,
generally
speaking,
like
scaling,
a
selfless
cluster
will
be
easy
if
the
upstream
system
takes
well
takes
so
partition
and
sharding.
So
that's
a
key.
Take
Oh
key
key
takeaways
from
our
talk
today,
so
first
pre-warm
and
what
Putin
techniques
can
largely
enhance
the
performance
wrong
cuckoo
native
cool
wrong
Canadian
communities
and
its
standardization
may
be
benefit
to
the
ecosystem.
Second,
is
that
so
lewis
about
sharing
the
infrastructures?
B
A
B
A
B
Yeah,
yes,
quite
similar
concepts
actually,
but
we
are
actually
working
on
K
native,
so
we
are
building
our
service
platform
on
top
of
creative
and
trying
to
do
the
optimizations
there
I'm
sure
that
there
are
going
to
be
some
similarities
between
all
the
implementations.
That's
you
know,
Canada
is
like
a
new
service
platform
or
new
standards
for
so
less
so
so
yeah.
We
just
try
to
adopt
that
as
our
like
a
baseline
and
build
our
products
on
Canadian,
yeah
and
the
open.
Whiskey
is
a
very
great
product,
but
it's
only
integrates
with
kubernetes.
B
It
is
not
really
like
kubernetes
native,
and
I
think
a
native
mainly
deals
with
like
functional
workload
right
so
so
maybe
they
cannot
do
is
like
customer
images.
So
I
I
do
believe
that
there
are
similarities,
but
there
are
also
many
differences
between
these
two
technologies.
Yeah.
Does
that
answer
your
question
or.
B
Know
but
to
my
knowledge,
correct
me
if
I'm
wrong,
maybe
Obon
whisk
only
allows
the
injection
of
like
her
cold
packages,
which
is
the
like
the
first
kind
of
workload
that
we
mentioned
about
right.
So
when
we
are
trying
to
build
our
product
a
negative,
we
try
to
support
more
kinds
of
workloads
like
custom
images
and
test
the
efforts
that
we're
making,
and
maybe
that
has
some
difference
that
yeah,
maybe
that's
the
difference
from
the
Obon
whisk
yeah.
Thank
you.
B
C
B
B
Supposedly
smash,
actually,
they
are
all
positioning
techniques,
but
they
are
not
the
same
thing
name.
Space
isolation
is
basically
like
multi-tenancy
or
isolation
that
is
done
at
the
crew
Panetta's
level,
kubernetes
control
valve
level,
while
silver
smash
sub
meshing
is
like
multi-tenancy
that
has
done
on
the
surface
mesh
level,
so
they
are
happening
at
the
different
levels,
but
there
are
all
concepts
of
like
dividing
the
whole
thing
into
many
small
groups
and
just
partitioning
the
world
holes.