►
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
Extending Knative for Fun and Profit - Matt Moore & Ville Aikas, Google
Come learn how the Knative building blocks work together with zero baked in knowledge of one another. We will cover a new model for loose coupling in Kubernetes, and show how it is used throughout Knative. We will demonstrate how this model can be used to read and manipulate whole classes of Kubernetes resources. We will also demonstrate how this model can be used with Knative, e.g. to create a new abstractions to receive Events.
https://sched.co/MPaK
A
B
B
A
So
we
got
back
the
whiteboard
spent
a
bunch
of
time,
thinking
about
this
and
we
decided
that
option
is
popping
out.
What
would
I
do
so
we
came
up
with
this
option
B,
which
is
what
we
call
what
the
duck
and,
in
particular,
what
we
wanted
to
do
was
really
boil
down
the
problem.
What
problem
are
we
really
trying
to
solve?
Not
necessarily
he's
sort
of
kind
of?
What
is
it
that
we
want
to
be
doing
with
those
types
in
particular?
A
But
what
is
the
thing
that
matters
to
us
about
those
particular
objects
and
the
pattern
that
we
had
seen
in
the
past
for
something
like
this
was
oh
by
the
way
and
our
esteemed
colleague
there
will
be
handing
out
stickers
later
thanks
God,
so
we
kind
of
went
back
and
started
looking
at
things
and
we're
like
well.
What
we
really
care
about
is
is,
what's,
on
the
other
end
of
that
reference
right.
A
We
don't
really
necessarily
have
to
know
exactly
what
is
in
there
as
long
as
it
can
fit
the
bill,
and
you
can
read
the
definition
for
duck
typing
there,
but
this
is
what
we
started
to
look
at
as
a
possible
solution.
So
if
you
look
at
these
objects
here,
so
this
is
just
handy-dandy
JSON.
It
/y
ammo
there
and
in
these
cases,
if
we
only
want
it
to
go
ahead
and
care
about
things
like
food,
whatever
is
underneath
the
food.
A
There
there's
three
different
kinds
of
objects
there,
and
even
though
they
all
look
a
little
bit
different,
they
have
the
small
section
that
that
we
care
about
in
for
our
cases,
so
we're
like
I'll
get
great.
Let's
go
in
to
find
a
partial
schema
for
that,
and
then
we
started
looking
a
little
bit
more
and
we
were
like
you
know
what
this
looks
really
familiar.
We
already
sort
of
kind
of
seen
this.
So
if
you
look
at
the
kubernetes
objects,
you
can
see
that
each
one
of
them
always
has
the
handy-dandy
type
meta.
A
So
it
basically
says
this
is
the
kind
of
an
object.
I
am
this.
Is
the
group
I
belong
to
and
I'm
that
type,
and
then
you
have
the
object
metadata
that
describes
the
actual
object.
What
is
what
is
it?
So
if
you
create
a
a
service,
you
give
it
a
name
and
a
name
space
and
few
other
things.
And
lastly,
where
we
see
this
often
is
in
status.
A
So
there's
there's
API
principles
document
each
one
of
these
Cuban,
ladies
objects
should
be
providing
a
status
in
a
well-defined
matter,
so
that
you,
then
you
can't
rule
them
better
yada
yada
yada,
and
then
we
start
looking
at
even
more
of
these
types,
where
we
see
this
on
the
spec
side
of
things,
so
those
were
the
the
common
wrappers.
So
if
you
look
at
the
apps
v1,
so
you
have
the
deployments
the
stateful
sets
and
the
daemon
sets
and
again
here
you
can
see
that
they
are
sharing
some
common
ways
of
selecting
things.
A
They
also
have.
This
thing
here
called
the
the
pot
spec
template
that
allows
you
to
go
ahead
and
reuse
that
thing
for
for
common
shape
and
so
forth.
So
we
kind
of
in
there
and
said:
do
you
think
it
would
be
bad
if
we
went
in
and
defined
this
like?
What?
What
could
we
do
with
this?
If
we
basically
said,
let's
go
and
give
it
the
two
kubernetes
type
meta
object,
meta
and
then
let's
define
our
own
little
pod
template
spec.
A
A
C
B
So
for
our
first
demo,
we're
gonna
use
a
little
prototype
that
we
were
a
few
months
ago
anymore,
now
called
cache
here.
So
in
K
native,
we
have
this
image
cache
resource
that
we
create
as
part
of
our
object
model
directly.
That
gives
a
hint
to
controllers
that
allow
you
to
potentially
cache
that
a
particular
container
image
across
the
cluster
and
for
fast
startups.
That
same
problem,
though,
afflicts
all
of
the
kubernetes
app
resources
we
just
saw.
B
So
the
question
is:
can
we
write
a
generalized
controller
that
uses
this
partial
schema
to
figure
out
what
the
compare
images
are
and
basically
bring
that
same
abstraction
to
all
of
is
good
Rene's
application
resources,
so,
okay,
so
with
duck
typing,
though
right,
oh
I,
don't
need
to
know
a
lot
about
the
type
I
just
need
to
know
what
set
of
group
version
resources
adhere
to
this
partial
schema.
So
in
here
the
entire
awareness
cashier
has
of
these
types
is
basically
these
strings
and
the
partial
schema
that
we
have
defined.
B
So
what
we're
going
to
show
in
this
demo
is
we
have
this
with
pod
partial
schema?
We're
gonna
create
a
deployment
with
an
a
boon
to
image
and
we're
going
to
see
the
controller
produce
an
image
resource
with
Ubuntu.
Then
we're
gonna
create
a
daemon
set
resource
with
two
images:
Debian
an
Alpine
and
it'll
produce
two
image
resources.
So
let's
see
that
in
action.
B
Alright,
so
if
I
switch
over
here,
just
make
sure
it
didn't
drop
okay,
so
you
can
see
on
the
left
here.
There's
a
deployment
gamal
with
the
abun
two
image,
and
if
we
scroll
a
little
bit,
you
can
see
a
demon
set
at
the
bottom
with
Debian
and
Alpine,
and
so,
if
we
apply
this
yamo
in
the
bottom
right,
I
have
watch
going
to
see
what
resources
exist.
So,
if
she
okay
so
when
I
apply,
this
you'll
see
the
deployment
and
the
daemon
set
up
here
immediately
and
the
the
controller
has
already
picked
up.
B
The
fact
that
these
with
pod
resources
are
there
and
create
these
image
resources
for
each
of
the
three
images
that
it
sees.
So
if
I
go
in
here
and
I
delete
the
deployment
you'll
see
that
one
of
the
image
cache
resources
for
the
Ubuntu
image
goes
away
right.
So
this
this
gives
us
a
way
to
hook
into
the
kubernetes
object
lifecycle
in
order
to
know
what
things
to
cache,
what
things
not
to
cache
and
if
I
go
in
here
and
I
delete
the
daemon
set
resource.
A
So
so
that
was
pretty
neat,
so
we
were
able
to
go
ahead
and
have
a
signal
controller.
That
is
no
knowledge
of
those
particular
objects
in
there.
We
were
able
to
go
ahead
and
just
say:
look
for
these
resources
and
do
something
nifty
with
them,
so
that
that
allows
us
to
go
and
we
use
the
very
same
controller
for
any
additional
resources
that
might
come.
A
So
if
somebody
else
builds
any
kind
of
a
thing
that
fits
that
using
the
pot
template
spec,
we
can
now
go
ahead
and
start
getting
the
pennies
of
the
of
the
the
cashier
and
the
other
nice
thing
about
this
one.
Is
that
just
like
in
go
when
you
have
the
when
you
use
in
interfaces,
you
don't
actually
have
to
do
things
like
in
Java,
where
you
say
like
it
that
the
resource
implementing
that
needs
to
know
what
it's
implementing.
A
A
A
The
tricky
bit
about
this
one
is
that
if
we
go
ahead
and
come
in
read
the
object,
modify
it
and
just
write
it
back
using
our
duct
ID,
then
some
of
those
things
wouldn't
be
carried
through
right,
so
we've
just
basically
bad
badness
wouldn't
happen.
So
we
didn't
want
that
so
you're
back
to
option
a
right,
guys,
remember
this,
so
it
didn't
solve
our
problem
at
all
for
the
Riding
cases,
and
that
made
us
sad,
but
we
were
like,
but
the
game
like
we
don't
need
to
know
what
the
type
really
is.
A
All
we
need
to
know
is
know
enough
about
it
to
understand
what
are
the
bits
and
pieces
we
need
to
change.
So,
let's
take
away
all
the
craft
from
the
previous
objects
that
we
had
and
we
were
like
what
what
the
wire
four
might
actually
look
like
for
these
things
right,
and
it
really
is
just
it's.
This
is
it.
It
looks
the
same
for
all
of
them.
So
if
we
just
go
ahead
and
actually
generate
a
patch
against
our
duck
type,
then
the
nice
thing
is
that
the
right
things
will
just
magically
happen.
A
A
B
B
This
was
a
prototype
that
we
put
together
that
attempts
to
help
alleviate
problems
with
config
map
rollouts,
where
you
know,
if
you
use
them
in
environment
variables,
you
know
old,
pub,
old
pods,
don't
change
anything
but
new
pods,
get
it
right
away,
and
if
you
use
it
via
volumes,
you
can't
control
how
quickly
that
is
rolled
out
to
all
of
the
pods
consuming
it.
So
what
the
boom
apps
do.
B
Is
you
have
this
mutable
map
in
this
immutable
map
and
as
you
change
the
mutable
map,
much
like
configurations
and
revisions
in
the
key
native
serving
model,
you
get
new
immutable
Maps
for
each
state
of
your
thing.
So
now,
if
you
want
to
deploy
something-
a
width
pod,
for
instance,
that
references
the
the
mutable
map,
because
typically
that's
what
you
want-
a
reference
when
you're
doing
development
but
freeze
it
so
that
it
doesn't
change
out
from
under
you
and
you
can
control
the
deployment
of
the
rollout
of
that
the
changes,
the
config
changes.
B
We
run
a
mutating
web
hook
that
basically
intercepts
with
pod
and
the
mutating
web
hook.
You
guessed
it
returns
a
patch
to
the
API
server
for
the
changes
that
wants
to
make,
and
so
we
can
use
this
to
basically
freeze
the
config
map
references
to
the
latest
generation
of
the
mutable
map,
and
then
it
won't
drift
as
you
continue
to
edit
your
mutable
map.
B
B
B
So
what
we're
gonna
do
next
is
we're
gonna
deploy
just
like
in
the
example,
a
deployment
that
references
the
mutable
map,
so
we
have
boom
app
deploy
here
and
you
can
see
this
reference
is
the
immutable
map
which
we
had
named.
Freeze
me,
oh,
wait,
sorry
got
distracted.
We
need
to
change
this
boom
app,
at
least
once
to
say,
cube
con
okay,
and
if,
if
I
apply
this,
it's
dropping
every
time
I
switch
to
this
frame.
That's
awesome!
Maybe
not
there.
B
We
go
I
hit
something
okay,
so
that
in
the
bottom
right
you
now
see
the
second
config
map
appear
right
away
and
now,
if
we
go
and
deploy
that
deployment,
but
we
will
see
we've
control,
applied
chef
map
deploy,
you'll
see
the
deployment
appear
in
that
bottom
frame,
right
away
and
I'm
gonna
zoom
in
because
this
gets
a
little
big.
So
we're
going
to
get
the
deployment
and
look
at
what
we
got.
So
if
we
scroll
down
here
a
little
bit,
you
can
see
that
the
mutant
mutating
webhook
was
able
to
change.
B
It
looked
through
find
that
blue
map
reference
and
replace
it
with
the
name
of
the
frozen
config
map.
So
that's
neat.
Now,
if
we
were
to
change
this,
it
wouldn't
change
from
hell
from
under
my
deployment,
but
we
haven't
shown
this
applying
to
duck
types
yet.
So
let's
look
at
another
type
that
actually
implements
with
pot.
In
this
case,
let's
look
at
a
game,
a
DIF
service,
so
you
can
see
this
similarly
references.
A
B
I
make
this
big.
What
you
will
see
is
here.
This
also
can
be
frozen
because
it
also
implements
with
pod
and
if
I
go
over
here
now-
and
I
refresh
this
hello
cute
Conn,
alright,
so
we
saw
in
action
so
one
of
the
nice
things
about
this
is
this
allows
us
to
control
the
roll
out
and
roll
back
in
config
Maps
right,
but
we
have
shown
that
we
can
take
this
partial
schema
that
allows
us
to
read
these
things,
but
also
use
it
to
synthesize
patches
for
changes.
B
We
want
to
make
to
these
things,
and
this
allowed
us
to
basically
write
a
web
hook
that
applied
to
any
with
pod
thing,
to
write
a
web
hook
that
could
freeze
these
config
maps
in
place
as
these
with
pod
things
get
deployed,
and
so
so
yeah.
So
this
this
lets
us
actually
control
the
roll
out
and
roll
back
of
config
map
changes.
So
right
you
work.
A
So
so,
where
don't
really
began
again,
just
kind
of
going
back
to
the
beginning
there,
where
we
said
we
basically
had
these
things
called
events,
event
sources
that
allow
you
to
go
ahead
and
come
in
and
saying
hey
start
sending
events
from
here
to
there
and
the
way
you
specified
there
is
by
putting
an
object
graph
that,
basically,
you
know
just
so
kay.
There's
your
version
API
group
and
enter
name
of
that
particular
object.
A
So
this
was
the
very
first
one
that
we
did
and
just
this
we
expected
when
we
used
these
duck
types
instead
of
bacon
in
any
kind
of
knowledge
about
about
the
object
on
the
other
end
by
just
using
those
at
type.
So
we
spend
some
time
thinking
about
what
those
duct
absol
and
then,
when
we
introduced
a
new
object
here
in
the
latest
0.5
release
of
K
native
for
a
broker.
A
We
didn't
have
to
change
any
of
the
any
of
those
codes
because
they
were
able
to
go
ahead
and
and
keep
on
working
and
just
resolve
those
references
and
do
what
they
wanted
to
in
the
first
place.
So
all
they
all
the
contract,
the
very
first
simple
contract
and
or
the
duct
tape
that
we
defined
was
this
addressable
we're
in
the
status
field.
You
just
needed
to
go
and
have
an
address
and
a
host
name
in
there.
That's
all
that
that
the
consumer
really
needs
to
know
we're
descent.
B
All
right
so
after
we
saw
that
this
could
be
used
in
eventing
to
allow
us
to
keep
to
decouple
eventing
and
serving
so
that
they
could
work
well
together,
but
not
without
baking
and
knowledge.
We
started
to
look
at
another
place
where
we
had
actually
gone
more
with
option
a,
and
we
revisited
that
and
we
looked
it.
You
know
how
we
were
doing
these.
B
This
also
enabled
us
to
you,
as
we
started
pipelines,
which
ultimately
became
tech
slot
those
in
on
day
one
so
that
you
could
use
a
you
know,
tasks
run
or
a
pipeline
run,
just
as
you
could
use
build
and
we
literally
change
zero
code
because
they
they
just
worked
so,
and
that
was
in
point
two
in
point
six.
We
started
to
really
embrace
the
duck
so
well.
One
of
the
changes
we've
made
as
part
of
our
new
API
shape
and
point
six.
B
Is
we
started
to
reshape
the
actual
serving
API
to
embed
a
pod
spec
in
the
same
way
as
the
the
Apps
resources?
So
this
is
what
we
saw
in
that
second
demo,
which
enabled
us
to
create
patches
that
work
equally
well
against
a
native
service
and
configuration
resources
that
work
against
kubernetes
application
resources.
B
The
pod
template
spec
is
a
notable
thing
that
isn't
in
the
scale
target
resource,
but
by
having
it
in
here,
we
can
potentially
start
to
do
things
like
mutate,
the
resources
block.
If
we
want
to
start
to
integrate
vertical
vertical
pod,
auto
scaling
in
the
future
or
read
out
pieces
of
information
to
do
more
sophisticated
scheduling,
I,
don't
think
we
had
an
animation
here.
Okay,.
A
All
right,
so,
hopefully
we
have
being
able
to
go
and
demonstrate
and
show
you
or
at
least
get
you
excited
about
how
cool
this
is,
and
maybe
you
can
see
some
uses
for
yourself
for
this.
So
this
is
not
just
limited.
The
K
Native
one
of
the
things
that
we
mentioned
earlier
on
is
having
several
kinds
of,
or
we
talked
about,
the
different
components
of
the
K
native.
A
So
those
of
you
that
have
written
a
controller
or
have
used
well,
typically,
you
use
use
Informers
of
their,
but
if
you
have
used
kubernetes
Informer's
before
this
code
looks
pretty
familiar,
but
it
basically
just
says
in
this
case.
What
we
do
is
we
say,
let's
bring
in
the
dynamic
client
from
from
the
go
client,
and
then
we
introduce
a
typed
in
former
factory,
so
notice
that
it's
typed
there
and
what
we
are
doing
is
in
this
example.
We
are
using
the
v1,
the
the
whit
pod
that
we
have
been
talking
about
the
partial
schema.
A
Then
you
tell
you,
trap
yourself,
an
informer
Lister,
and
then
you
are
off
the
races.
Then
you
say
went
that
in
formal
notices,
something
go
ahead
and
call
something
so,
for
example,
in
the
controller
land.
You
typically
have
something
like
this,
where
you
have
every
concealer,
so
the
happy
little
reconciler
is
there
and
it
is
now
using
the
list
or
just
like
you
would
do
if
you
were
to
go
and
grab
that
from
the
from
the
typed
clients
that
you
generate.
A
Typically-
and
now
you
have
this
there's
this
this
cast
here
that
basically
says
well
I
asked
for
with
part
objects.
I
know
they
are
vivant
objects
and
you
don't
have
to
go
into
the
tip,
because
you
could
do
this
also
by
running
unstructured
objects
and
everything
else,
and
you
would
have
all
the
fun
of
doing
your
little
adjacent,
marshaling
and
everything
else,
and
you
know.
C
A
Fun,
but
this
is
a
little
bit
nicer,
I
think
and
more
concise,
so
we
have
the
benefits
of
being
able
to
get
strong
typing
and
being
able
to
go
ahead
and
get
the
standard
in
Informer.
Caching
behavior
you
get
out
of
that.
So
so
it
should
be
very
easy
to
go
ahead
and
utilize.
These
things
and
strong
typing
until
soon.
B
B
So,
let's
look
at
patching,
so
this
example
is
actually
real
code
that
is
part
of
cane
native,
serving
in
point
six
I
mentioned
pod
scalable
before
and
how
we
actually
use
pod
scalable,
coming
from
an
informer
like
viel
I
mentioned
in
the
previous
example.
Here
we
have
a
pod
scalable.
It
comes
in
at
a
desired
scale
and
should
look
very
familiar
right.
B
B
So
yeah,
ok,
one
more
thing,
so
in
K
native
we
mentioned
earlier,
we
aim
to
be
loosely
coupled
at
the
top,
but
also
we
talked
about
being
pluggable
on
at
the
bottom,
so
loosely
coupled
at
the
top
right
is
via
the
duct
piping.
But
we
didn't
really
talk
that
much
today
about
being
pluggable
at
the
bottom,
so
there
was
actually
a
secret
cameo,
our
presentation,
our
demo,
that
last
serving
demo
where
we
loaded
up
the
service
that
said
hey,
coop
gun
was
actually
running
ambassador.
So
the
plug
ability
at
the
bottom
enables
us
to.
B
Last
december,
on
doing
this
with
the
autoscaler
networking
is
another
place.
We
can
do
it
and
we
have
a
number
of
places.
We
do
this
on
a
venting,
so
we've
really
just
scratched
the
surface
of
the
extensibility
within
a
native
but
yep
so
a
little
surprise
for
you,
okay.
So
at
this
point
we
are
ready
for
questions
and
we're
gonna
put
up
a
wall
of
links.
While
we
answer
questions.
C
B
Sorry,
the
Ambassador
integration
here
so
I
think
documented.
Today
we
have
sto
and
I
believe
we
have
glue
integration
yeah.
The
ambassador
integration
we
showed
here
is
a
POC
that
been
browning
put
together,
although
we
were
talking
to
them
earlier
on
the
floor
about
actually
getting
proper
integration
together.
B
But
okay,
I
didn't
link
to
Ben's
prototype,
but
it's
I
can
send
you
a
pointer
if
you're
interested
yeah,
also
for
all
the
things
we
don't
have
links
up
here,
for
we
were
very
active
on
slack.
So
if
you
get
a
slack
that
came
in
if
that
dev
I
believe
that
generates
an
invite
for
you
and
you
can
log
in
and
chat
with
us.