►
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
Inside Knative Serving - Dominik Tornow, SAP & Andrew Chen, Google
Knative is a Kubernetes Extension that brings Functions as a Service to your Kubernetes Cluster. Knative provides components to build, serve, and auto-scale your apps. Do you want to know how Knative Serving turns your Docker image into a function as a service? Do you want to know how Knative Serving scales your functions to meet demand? How Knative Serving scales to zero without ever dropping a single request? How does it work? Using a systems modeling approach, this talk will explore Knative Serving, connect the dots between workload management and traffic management. You will leave with a concise and accurate understanding how Knative turns your source code into scalable, reliable applications. Along the way, this talk highlights how Kubernetes Extensions enable brand new use cases, adding custom functionality and custom processes as first class citizens to your cluster.
https://sched.co/NrlT
A
A
So,
for
the
past
year,
we've
been
working
together
to
try
to
figure
out
why
kubernetes
is
so
hard
to
understand
when
I
started
as
a
Technical
Writer.
Over
two
years
ago,
I
was
bombarded
with
terms
such
as
control,
plane,
data,
plane,
kubernetes,
object,
controller
ingress,
you
know,
and
the
list
goes
on
and
on
all
right.
I
had
at
my
disposal
all
of
the
committee's
documentation,
yet
I
still
lacked
a
big
picture.
Understanding
of
how
everything
worked
together.
A
Was
it
because
I
didn't
read
all
the
source
code?
Who
even
has
the
time
to
do
that,
and
do
you
even
believe
that
it's
possible
to
understand
a
software
system
without
examining
its
source
code?
Well,
Dominic
showed
me
that
there
is
another
way.
It's
called
systems
modeling.
So
for
the
past
year
we've
been
writing
blog
posts
using
formal
and
conceptual
models
to
help
people
better
understand
how
kubernetes
works
so
that
they
may
reason
about
its
behavior.
A
With
confidence
so
we're
applying
this
methodology
now
to
K
native
serving
so
that
you
may
understand
K
native
better,
and
what
makes
this
presentation
a
little
different
than
others
you
may
see.
Is
that
we're
not
going
to
show
you
source
code,
we're
not
going
to
show
you
a
console,
we're
not
going
to
do
a
demo,
we're
just
going
to
be
showing
you
systems
models,
and
yet
you
should
still
be
able
to
walk
away
today
with
the
crystal
clear
understanding
of
how
cane
ativ
serving
works
and
without
further
delay.
B
B
Thank
you.
If
you
heard
of
K
native
before
you
probably
heard
that
K
native
is
a
kubernetes
extension
designed
to
manage
service
applications,
this
statement
about
K
native
is
correct.
However,
this
statement
does
not
describe
K
native
well.
K
native
is
a
kubernetes
extension.
A
kubernetes
extension
is
a
collection
of
custom
controllers
and
custom
resource
definitions
that
an
ember
that
enable
new
use
cases
on
top
of
kubernetes.
If
you
hear
members
of
the
kubernetes
community,
safe
kubernetes,
is
a
platform
to
build
a
platform.
B
They're
talking
about
kubernetes
extensions,
Kay
native,
is
in
fact
a
collection
of
three
kubernetes
extensions
candidate,
build
k,
native
serving
and
k
native
eventing
in
combination.
K
native
is
not
just
a
server
list
extension,
but
it
is
a
zero
operations.
Extension
for
reactive
micro
service
applications
hosted
on
kubernetes
zero
ops,
also
called
no
ops
or
more
formally
operation.
Automation
refers
to
the
fact
that
most
or
all,
tasks
which
are
required
to
operate
an
application
are
performed
by
the
system
not
performed
by
the
developer.
B
Today
we
will
discuss
K
native
serving
in
particular.
We
will
discuss
two
aspects,
canada,
serving
as
a
zero
operations,
extension
for
the
lifecycle,
management
of
reactive
micro
services
and
k
native,
serving
as
a
server
list
extension
to
understand
the
benefits
of
canada
serving
we
need
to
shift
our
point
of
view
from
an
architectural
perspective
to
an
operational
perspective
from
an
architectural
perspective.
A
reactive
micro
service
is
an
individual,
stateless
component.
The
processes
individual
requests
micro
services
are
located
behind
the
Gateway.
The
Gateway
is
responsible
for
traffic
management.
B
In
order
to
release
the
initial
revision
of
a
service,
you
have
to
perform
two
steps.
First,
you
have
to
deploy
the
revision
to
deploy
a
revision.
You
have
to
create
a
workload
specification.
A
workload
specification
is
a
set
of
resources
that
specify
how
to
process
requests
and
by
the
way,
if
you
are
thinking
workload
specification,
that
sounds
like
pod
specification.
In
essence,
you
are
correct.
B
To
roll
out
a
revision,
you
have
to
create
a
traffic
split
specification.
A
traffic
split
specification
is
a
set
of
resources
that
specify
how
to
route
requests.
And
now,
if
you
are
thinking
traffic
split
specification,
that
sounds
like
ingress
specification
again
in
essence,
you
are
correct
here:
all
traffic
splits
are
probabilistic
traffic
splits.
B
In
order
to
release
the
next
revision
of
a
service.
You
have
to
repeat
these
steps.
First,
you
have
to
deploy
the
new
revision.
Second,
you
have
to
roll
out
the
revision
with
a
probabilistic
traffic
split.
You
have
two
options
to
do
a
rollout.
You
may
choose
an
immediate
rollout
or
you
may
choose
a
gradual
rollout
to
perform
an
immediate
rollout.
You
have
to
update
the
traffic
split
specification
only
once
shifting
all
requests
from
the
current
to
the
next
revision
in
an
instant.
B
B
Kubernetes
provides
an
extensive
set
of
very
rounded
abstractions
to
compose
a
micro
service.
However,
kubernetes
does
not
provide
a
dedicated
abstraction
for
a
micro
service.
Simply
put
kubernetes
gives
us
everything
we
need,
but
we
have
to
piece
everything
together
ourselves
and
there
are
many
options
to
choose
from
turns
out.
The
most
prominent
is
also
the
most
basic
pattern
here.
One
micro
service
is
represented
by
composing
four
kinds
of
objects:
a
kubernetes
deployment,
a
kubernetes,
horizontal
pod,
autoscaler,
a
kubernetes
service
and
o
kubernetes
ingress
deployment
and
HP
a
represent.
B
B
In
order
to
release
the
initial
revision
of
a
micro
service,
the
developer
has
to
create
a
deployment
object,
a
horizontal
port
order,
scalar
object,
an
ingress
object
and
a
service
object.
In
order
to
release
a
subsequent
vision.
The
developer
has
to
update
the
deployment
object.
This
pattern
is
simple:
to
implement
and
simple
to
operate.
However,
the
developer
has
limited
control
over
the
rollout.
That
is
limited
control
over
the
traffic
split
specification.
B
This
diagram
illustrates
in
mechanics
of
the
traffic
split
specification
of
the
basic
pattern.
Here
we
have
one
microservice
that
is
currently
in
rollout,
that
is,
traffic
is
shifted
from
deployment
number
one
replica
set
number
one
to
deployment
number
one
replica
set
number
two
kubernetes
ingress
directs
all
requests
that
are
bound
to
one
micro
service
to
one
kubernetes
service.
In
turn,
the
kubernetes
service
directs
request
to
matching
parts
with
equal
probability.
B
B
To
grant
the
developer
full
control
over
the
traffic
split
specification,
a
more
advanced
pattern
emerged
here
again.
One
micro
service
is
represented
by
composing
four
different
kinds
of
objects:
a
kubernetes
deployment,
a
kubernetes,
horizontal
pod,
autoscaler,
a
kubernetes
service
and
an
sto
virtual
service
deployment
and
HP
a
represent
the
workload
specification
service
and
virtual
service
represent
the
traffic
split
specification.
B
In
order
to
release
the
initial
revision,
the
developer
has
to
create
a
deployment
object.
A
horizontal
port
autoscaler
object,
a
service
object
and
an
easier
virtual
service
object.
In
order
to
release
a
subsequent
revision.
The
developer
has
to
create
a
new
deployment
object,
a
new
horizontal
pod
or
a
scalar
object,
and
a
new
service
object
and
has
to
update
the
existing
sto
virtual
service
object
again
the
advance
pattern
from
an
actions
point
of
view.
B
In
order
to
release
the
initial
revision
of
a
micro
service,
the
developer
has
to
create
a
deployment
object,
a
horizontal
port
or
a
scalar
object,
a
service
object
and
an
sto
virtual
service
object.
In
order
to
release
a
subsequent
revision,
the
developer
has
to
create
a
new
deployment
object,
a
new
horizontal
port
or
the
scalar
object.
A
new
service
object
and
has
to
update
the
existing.
Is
your
virtual
service
object
in
case
of
an
immediate
rollout?
B
The
developer
has
to
update
the
ISTE
of
virtual
service
only
once
in
case
of
a
gradual
rollout,
the
developer
has
to
update
the
ischial
virtual
service
multiple
times.
This
pattern
is
still
simple
to
implement
but
way
more
involved
to
operate.
However,
the
developer
has
full
control
over
the
rollout
that
is
full
control
over
the
traffic
split
specification.
B
This
diagram
illustrates
the
mechanics
of
the
traffic
split
specification
of
the
advanced
pattern.
Here
we
have
one
micro
service
that
is
currently
in
rollout,
that
is,
traffic
is
split
from
I'm.
Sorry,
traffic
is
shifted
from
deployment
number
one
replica
set
number
one
to
deployment
number
two
replica
set
number
one
is
to
virtual
service
directs
all
requests
that
are
bound
to
one
micro
service
to
a
configurable
set
of
kubernetes
services.
In
turn,
the
kubernetes
service
directs
request
to
matching
parts
with
equal
probability.
B
In
summary,
traffic
split
is
explicit,
in
fact
determined
solely
by
the
ISTE
of
virtual
service.
So
far,
we
had
good
news
and
we
have
bad
news.
The
good
news
kubernetes
is
a
convenient
choice
to
implement
micro
service
applications.
The
bad
news
kubernetes
is
not
a
convenient
choice
to
operate
micro
service
applications.
You
have
to
perform
an
involved
with
edit
of
sequence
of
steps
for
the
initial
release
in
every
subsequent
release.
B
Well
meet
K
native
serving
finally
K
native
serving
automates,
the
sequence
of
steps
for
the
initial
release
and
every
subsequent
release
of
your
microservice
K
native,
provides
a
custom
resource
definition.
The
K
native
service
object
that
implements
the
advanced
pattern
and
automates
its
operations.
B
When
you
create
a
K
native
service
object,
K
native
automatically
creates
an
initial
deployment,
the
initial
autoscaler,
the
initial
service
and
the
sto
virtual
service.
For
you,
please
note
that
K
native
replaces
the
horizontal
part
autoscaler
with
a
K
native
pod
autoscaler,
the
kubernetes
horizontal
pod
autoscaler
scales,
instances
based
on
metrics,
like
CPU
utilization
or
memory
utilization,
the
K
native
pod
autoscaler
scales.
Instances
based
on
in-flight
request
count.
In
addition,
the
k
p8
can
scale
from
n
to
0.
B
We
will
go
into
more
detail
in
the
next
section
of
the
presentation
when
you
update
a
K
native
service
object.
K
native
automatically
creates
the
next
deployment
the
next
autoscaler
and
the
next
service
and
updates
is
to
virtual
service
for
you.
In
conclusion,
from
an
actions
point
of
view,
K
native
reduces
the
operational
burden
on
the
developer.
In
order
to
release
the
initial
revision
of
a
micro
service,
the
developer
simply
has
to
create
a
K
native
serving
object.
In
turn,
can
ativ
automatically
creates
a
required
set
of
objects.
B
In
order
to
release
this
subsequent
revision,
the
developer
simply
has
to
update
the
tentative
serving
object
and,
in
turn,
Canada
automatically,
creates
and
updates
a
required
set
of
objects.
Still
in
case
traffic
is
shifted
immediately.
The
developer
updates
the
key
native
service
once
in
case
traffic
is
shifted
gradually.
The
developer
updates
the
key
native
service
multiple
times.
B
B
When
the
workload
specification
of
the
service
object
is
updated,
the
configuration
will
be
updated
with
the
services
new
workload
specification
for
each
K
native
configuration.
There
exists
at
least
one
K
native
revision.
When
the
configuration
object
is
created,
a
revision
object
is
created
with
the
configurations
initial
workload
specification
when
the
configuration
object
is
updated.
A
new
revision
object
will
be
created
with
the
configurations
new
workload
specification.
B
In
addition,
for
each
K
native
service,
there
exists
a
K
native
route
when
the
service
object
is
created,
a
route
object
will
be
created
with
the
services
traffic
split
specification.
When
the
traffic
split
specification
of
the
service
object
is
updated,
the
route
object
will
be
updated
with
services,
new
traffic
split
specification
and,
ultimately,
a
route
results
in
an
sto
virtual
service.
B
B
Kay
native
injects
another
image
into
the
pot
specification
on
creation
of
the
deployment
called
the
cue
container
image.
The
cue
container
is
a
reverse
proxy
to
the
user
container.
The
cue
container
intercepts
all
requests
to
the
user
container
and
is
responsible
for
collecting
and
reporting
statistics,
namely
the
in-flight
request
count
to
the
autoscaler.
Again.
We
will
go
into
more
detail
in
the
next
section
of
the
presentation
so
to
release
the
initial
revision
of
a
micro
service.
The
developer
creates
a
que
native
service
object
with
an
initial
workload
and
an
initial
traffic
split
specification
in
turn.
B
Can
aid
of
creates
a
Canadian
configuration
object
with
the
workload
specification
in
turn?
Can
ativ
creates
a
candidate
revision
object
with
the
workload
specification
in
turn,
que
native
creates
a
deployment
object
with
the
workload
specification,
a
service
and
make
a
native
autoscaler
additionally
que
native,
creates
a
Canada
Froude
object
with
the
initial
traffic
split
specification.
B
In
turn.
Can
aid
of
creates
an
SEO
virtual
service
with
the
traffic
split
specification?
At
this
point,
the
initial
revision
is
released
and
receiving
100%
of
requests
to
release
the
next
revision
of
a
micro
service.
The
developer
updates
the
kinetic
service
object
here
with
an
updated
workload
and
an
updated
traffic
split
specification.
B
Canada
updates
a
configuration
object
and,
in
turn,
creates
a
new
revision
object.
Additionally,
que
native
updates
a
route
object
and,
in
turn,
updates
a
virtual
service.
At
this
point,
the
next
revision
is
deployed
and
receiving
100%
of
requests.
So
we
could
stop
here
and
enjoy
the
sweet
benefits
of
operation
automation.
However,
Canada
has
one
more
trick
up.
Its
sleeve
que
native
serving
is
able
to
scale
a
revision
from
n
to
zero.
An
approach
that
is
frequently
called
serve
as
computing
in
a
traditional
environment.
B
B
B
B
Meet
the
key
native
serving
activator
for
this
walkthrough
I
assume
one
key
native
service
service
number
one
to
revisions,
revision
number
one
in
revision
number
two
and
that
the
service
is
currently
in
roll
out.
That
is,
traffic
is
split
between
revisions.
Currently,
both
revision
number
one
and
revision
number
two
are
scale
it
to
zero.
B
Now
this
is
a
fun
part.
When
a
request
enters
the
system.
The
Gateway
inspects,
a
request,
determines
the
service
and
selects
a
revision
to
process
the
request
here.
I
assume
the
Gateway
selects
revision
number
one.
Since
no
instance
of
revision.
Number
one
is
running.
Requests
to
revision
number
one
are
on
a
code
path.
The
Gateway
is
configured
to
forward
the
request
to
the
activator,
the
activator
buffers
the
original
request
and
sends
a
request
to
the
autoscaler
to
scale
revision
number
one.
B
B
In
addition,
the
queue
container
sends
a
request
to
the
autoscaler
to
increase
the
in-flight
request.
Count
omitted
in
this
animation
when
the
response
of
the
user
container
is
returned
to
the
caller.
The
queue
container
sends
another
request
to
the
autoscaler
to
decrease
the
in-flight
request,
count.
B
Now,
to
do
this
all
over
again
when
a
new
request
enters
the
system,
the
Gateway
inspects,
a
request,
determines
the
service
and
selects
a
revision
to
process
the
request
here.
I
assume
the
gateway
selects
revision
number
one
again
since
an
instance
of
revision
number
is
running,
requests
to
revision
number
one
are
on
a
hot
path.
The
Gateway
is
configured
to
forward
requests
for
revision
number
one
directly
to
a
part
of
that
revision,
bypassing
the
activator
again,
the
queue
container
forwards
to
originally
request
to
the
user
container
for
processing.
B
Ultimately,
the
same
process
takes
place
for
revision.
Number
two
in
summary,
que
native,
is
a
zero
operations.
Extension
for
reactive
micro
service
applications
on
kubernetes
within
canada.
'the
que
native
serving
is
a
zero
operations
extension
for
the
lifecycle,
management
of
reactive
micro
service
applications
on
kubernetes
k
native
serving
provides
a
dedicated
abstraction
for
a
micro
service
and
automates
its
operation,
that
is
it
automates
deployment
and
rollout
additionally
k
native
serving
is
a
service
extension
k
native
serving
is
able
to
scale
a
micro
service
from
n
to
zero
instances
in
response
to
service
requests.
A
C
Won't
ask
if
I
run
application
in
cognitive
service
and
which
component
to
ensures
that
my
applications
is
a
high
available,
because
my
application,
perhaps
you
know,
has
some
trouble
and
it
can
be
broke
down
in
the
Canadian
Canadian
service
container.
So
I
should
I
develop
another
application
to
fix
these
to
fix
this
problem
or
the
Canadian.
Who
has
a
internal
mechanism
to
have
me
to
do
that?
Canada.
B
Actually
does
not
address
this
problem,
can
it
it
falls
back
on
to
kubernetes,
because
a
que
native
service
or
more
specifically,
a
revision
of
ack
a
native
service,
ultimately
translates
into
a
deployment
so
from
there
on.
It
inherits
all
the
properties
that
the
deployment
exposes
and
since
kubernetes
deployment
controller,
makes
sure,
or
at
least
tries
as
much
as
you
can,
to
bring
up
as
many
pots
as
specified
in
the
replicas
count.
K
native
falls
back
on
to
the
availability
guarantees
of
kubernetes,
but
the
problem,
the
the
point
stands
and
is
correct.
B
C
Yep,
because
you
know
our
applications
always
was
deployed
deployed
in
our
production
environment
through
deployment
workload
and
the
stiff
side
workload,
but
our
application
is
a
database
system.
So
there
are
so
many
unstable
problems
will
be
happened
in
the
container,
so
the
Canadian
stories
is
very
convenient
for
us
if
we
want
to
provide
as
a
database
service
to
our
customers,
yeah
actually.
B
D
B
D
D
B
See
so
actually,
the
cue
container
is
not
involved
in
cold
path
or
hot
path.
The
only
component
that
is
involved
in
cold
path
or
hot
path
is
the
gateway
and
the
activator
the
ingress
gateway
is
if
there
is
no
no
pod
running,
the
ingress
gateway
is
configured
to
forward
a
request
to
the
activator,
and
then
the
activator
will
talk
to
the
autoscaler
to
scale
up
in
the
future.
B
In
the
future,
after
a
pot
has
been
acquired,
the
gateway
is
reconfigured.
We
are
the
ISTE
of
virtual
service
to
then
direct
requests
directly
to
the
pot.
So
this
situation
now
or
actually
the
blue
line
you
can
think
of
the
blue
line
as
the
hot
path
and
the
queue
container
within
the
pot.
Its
sole
responsibility
is
to
count
statistics,
so
it
every
time
it
receives
the
requests
it
increases
in
flight
requests
count
and
every
time
it
returns
a
response.
It
decreases
in
flight
requests,
come
in.
E
Hi,
the
Gateway
is
configured
to
route
certain
requests
to
service,
one
revision,
one
and
certain
to
say
revision
2,
while
the
rollout
is
happening
right
so
now
in
the
cold
path
we
had
the
first
request
come
to
revision,
one
and
your
user
container
came
up,
and
now
it's
directly
going
to
the
queue
container
off.
So
this
one
revision,
one
now
say
a
request
comes
where
the
Gateway
has
to
route
it
to
revision
2,
but
the
cold
path
is
still
enable
there.
So
to
reduce
the
response
time.
Does
it
route
it
to
so
revision
1?