►
Description
Knative, created originally by Google with contributions from over 50 different companies, delivers an essential set of components to build and run serverless applications on Kubernetes. Knative offers features like scale-to-zero, autoscaling, in-cluster builds, and eventing framework for cloud-native applications on Kubernetes. Whether on-premises, in the cloud, or in a third-party data center, Knative codifies the best practices shared by successful real-world Kubernetes-based frameworks. Most importantly, Knative enables developers to focus on writing code without the need to worry about the “boring but difficult” parts of building, deploying, and managing their application.
In this briefing, Red Hat’s Paul Morie and VMWare's Matt Moore will give a brief intro into Knative, a bit of demo of some of the latest features, walk us thru the road ahead and answer your questions.
A
All
right,
everybody
welcome
to
our
openshift
commons
ama.
Ask
them
anything,
not
me
for
k
native
and
today
we
have
paul
murray,
matt,
moore
scott
nichols
and
roland
huss.
All
participants
in
this
wonderful
project
who
are
going
to
give
us
an
introduction,
tell
us
a
little
bit
about
the
roadmap
and
hopefully
leave
a
little
bit
of
time
at
the
end
for
all
of
your
questions.
So
we
are
live
streaming
this.
A
So
if
you
are
in
any
one
of
the
multiple
live
streams
like
facebook,
youtube
or
twitch,
or
I
think
periscope
even
now,
throw
your
questions
in
that,
and
we
will
aggregate
them
here
and
force
these
people
to
answer
them.
So
without
any
further
ado,
paul
introduce
yourself
and
your
cohort
and
let's
find
out,
what's
going
on
in
k
native
land.
B
C
D
E
Hey
howdy,
I'm
scott
nichols.
I
work
on
k
native
at
red
hat,
formerly
google.
I
work
on
the
eventing
side,
mostly
focused
around
source
creation.
So
that's
that's
how
events
get
into
the
cluster
and
make
interesting
things
that
you
can
do
with
events,
and
I
also
contribute
to
the
cloud
events
cncf
project.
B
D
E
B
B
A
A
B
All
right
yeah-
I
guess
I'll
just
hold
this
if
you
want
to
see
my
face,
so
what
is
it?
One
of
the
one
of
the
things
that
that
is
sort
of
in
the
in
the
air
in
our
industry
is
a
confusion
between
two
related
but
different
things
and
those
two
things
are
serverless
and
faz,
or
functions
as
a
service
and
I've
I've
seen
k-native
referred
to
as
a
faz
a
few
times.
B
So
when
we
think
about
what
faz
is
it's
usually
a
lot
more
than
serverless?
I
think
to
me
personally,
my
own
opinion.
Faz
implies
serverless,
but
serverless
doesn't
necessarily
imply
faz.
So
when
we
talk
about
k-native,
we're
going
to
be
focused
on
serverless
elements
and
we're
not
going
to
be
focused
as
much
on
those
experiential
elements
that
are
the
difference
to
me
personally.
Between
serverless
and
faz,
where
faz
is
something
more
than
serverless,
it's
got
a
lot
of
connotations
of
developer.
B
So
let's
talk
a
little
bit
more
as
I'm
double
fisting
these
these
devices,
since
I've
got
my
phone
and
and
my
laptop
I'll
see
if
I
can
operate
them
both
correctly,
what
is
k-native
really
now
that
we've
kind
of
maybe
close
to
hit
bedrock
with?
Maybe
if
we
were
thinking
it
was
a
faz
we're
sort
of
recognizing
that
it's
not
exactly
faz
and
it's
more
serverless,
k
native
is
really
a
kubernetes
extension
that
is
focused
on
developer
productivity.
B
B
They
take
they
take
a
lot
of
engineering,
know
how
to
get
exactly
right
and,
in
my
own
personal
impression,
that's
sort
of
the
value
proposition
of
k-native.
Is
that
we're
doing
a
lot
of
these
things
that
you
would
have
to
worry
about
yourself,
because
kubernetes
doesn't
already
do
them
and
giving
you
the
tools
to
kind
of
really
just
focus
on
your
business
logic
and
what
you
want,
your
application
or
the
system
that
you're
building
to
do
so.
There's
two
key
pieces
here
and
actually
this
this
is
an
outdated
slide
and
roland.
B
I
don't
want
to
say
too
much
more
about
either
of
these
to
so
that
I
don't
steal
the
very
impressive
bolts
of
thunder
that
my
co-presenters
have
for
us
today,
but
that's
those
will
be
two
of
the
main
focuses
and
then
we're
also
going
to
hear
about
the
client
and
that's
that
is
those
are
the
high
notes.
So
co-presenters
do
you
want
to
just
add
anything
here
before
we
move
on,
or
is
that
sufficient
for.
A
B
C
Sure
so
this
is
this,
is
you
know,
there's
always
a
lot
going
on,
but
this
is
sort
of
a
highlight
reel
of
some
of
the
sort
of
major
events
throughout
the
course
of
the
project.
So
back
in
sort
of
fall
of
2017,
we
started
some
of
the
really
early
prototyping
of
you
know
what
paul
described,
trying
to
sort
of
look
at
what
higher
level
abstraction
on
top
of
kubernetes.
For
you
know,
developer
productivity,
serverless,
fast
sale
thing
would
look
like
it
launched
publicly.
C
The
serving
api
had
their
v1
revision
in
september
of
2019
and
one
of
the
one
of
the
big
things
that's
been
sort
of
a
recurring
theme
laced
through
some
of
the
more
technically
oriented
things
in
here
has
been
the
topic
of
sort
of
governance
and
paul's,
been.
You
know,
one
of
the
one
of
the
big
advocates
of
this
on
steering
and
in
may
of
last
year
we
had
our
first
toc
elections
and
marcus
nia
and
grant
joined
the
toc,
and
we
now
have
a
sort
of
vendor-neutral
representation.
C
C
This
past
year
we
had
our
first
steering
elections
where
paul
won,
one
of
the
elected
seats
and-
and
I
guess
who
is
one
of
the
other
folks
who
started
the
project
a
few
years
ago-
won
one
of
when
the
other
elected
seat.
So
we
now
have
both
a
steering
committee
and
a
technical
oversight
committee,
where
no
one,
no
single
vendor
you
know
has
all
the
say
right.
So
it's
very
exciting
times
for
the
project.
B
Yeah
one
thing
that
I'll
just
add
is
that,
when
matt
talks
about
the
technical
oversight
committee
and
steering
committee
is
that,
in
addition
to
the
vendor
neutrality
element
that
matt
described
the
folks
on
those
committees
are
serving
as
individuals
not
as
employees
of
their
vendors.
So
in
this,
in
the
sense
that
it's
vendor
neutral
in
the
sense
that,
like
you,
we
can't
have
more
than
two
people
employed
by
the
same
vendor.
B
B
B
One
of
them
is
the
one
that
you
see
the
other
one
said
cloud
events
I
wanted
to
put
scotty's
face
on
it,
but
I
didn't
have
enough
time
and
I
think
dan
pop
generously
offered
to
do
it,
and
then
I
forgot
about
it.
So
this
is
what
you
get
we'll,
maybe
make
one
that's
even
more
funny,
but
wanted
to
say
a
few
words
about
cloud
events.
B
I'm
not
sure
how
high
the
name
recognition
is
for
the
cloud
events
project,
but
the
cloud
event
format
is
a
vendor-independent
standard
for
event,
metadata
that
that
is
actually
a
cncf
project.
Scott
in
particular,
I
think
from
the
group
of
co-presenters
that
I
had
today
is
very
active
in
the
cloud
events
space.
B
The
message
format,
that
is
the
lingua
franca
of
k-native
project,
is
the
cloud
event
format
and
it
is
supposed
to
facilitate
interoperability
between
different
producers
and
consumers
and
be
a
vendor
neutral
format
that
can
be
adopted
and
it's
what
we.
What
we're
using
is
an
event
format
inc
in
in
k
native
scott.
Do
you
want
to
add
anything
to
that
anything
important
that
we
should
know
before
we?
We
continue
our
journey
through
this
introduction
to
k-native.
E
Yeah,
I
think
the
the
only
missing
important
bit
about
cloud
events
is
that
the
specification
describes
how
to
turn
the
that
the
core
nugget
of
your
event
between
protocols
and
back
to
this
protocol-less
version
of
that
event,
and
so
the
reason
this
is
important
is
I
can
go
and
write
my
faz
have
it
based
on
cloud
events
and
then
all
of
a
sudden,
I'm
not
locked
into
the
protocol.
I
choose
when
the
project
started
so
k
native
serving
is
really
about.
E
B
C
You
have
deployments,
you
have
services,
you
have
ingresses,
you
have
hpas,
you
have
all
of
these
things
right
that
you
know
you
need
to
do
when
you're,
adding
new
services
and,
as
folks
shift
from
sort
of
you
know,
big
monolithic
applications
to
you,
know
the
new
hotness
micro
services
or
even
functions
right.
You
end
up.
You
end
up
needing
to
do
that.
C
You
know
we
if
you've
configured
automatic
tls,
these
will
be
tls
terminated
endpoints
without
you
developers
having
to
do
anything
as
paul
mentioned
earlier,
as
you,
you
know,
create
changes
in
your
application.
Each
each
version
of
your
application
is
stamped
out
as
what
we
call
a
revision
over
time.
C
The
the
next
slide
sort
of
illustrates
a
little
bit.
What
makes
this
a
powerful
concept
is,
it
enables
you
to
reason
about
sort
of
versions
of
your
application
over
time,
and
this
is
most
useful
when
you
want
to
say
canary
sending
some
traffic
to
a
new
version
of
your
application
or
all
of
the
traffic
to
a
new
version
and
roll
forwards
and
backwards
in
time,
depending
on
your
production
needs.
C
You
go
back
for
just
one.
Second,
I
just
want
to
make
sure
I
yeah
okay,
and
I
think
the
two
other
really
interesting
things
are
request
based,
auto
scaling.
So
as
your
application
gets
more
or
less
traffic,
and
this
may
be
because
you
were
rolling
out
a
new
version
or
not
the.
We
will
basically
right
size,
your
application
and
you
know,
have
10
replicas,
20,
replicas
or
even
zero
replicas,
depending
on
sort
of
the
volume
of
traffic.
C
C
You
know
concurrency
control,
which
can
be
tough
to
get
right,
especially
when
you
start
to
blend
it
with
things
like
load,
balancing
and
auto
scaling
and
getting
really
good
performance
out
of
some
of
those
things
so
yeah
so
yeah.
So
the
next
slide
really
illustrates
the
resource
model
here.
So
I
mentioned
the
sort
of
one
resource
that
you
need
to
deal
with
for
launching
new
services.
This
is
the
service
resource
in
its
simplest
form,
you'll
pretty
much
just
give
it
a
container,
and
this
exposes
an
http
endpoint
under
the
hood.
C
It
creates
a
what
we
call
a
configuration
resource
which
tracks
the
sort
of
latest
state
of
configuration.
For
you
know
what
what
is
running
and
those
revisions
are,
that
history
of
changes
to
that
configuration
resource.
I
I
like
to
make
the
analogy
of
revisions-
are
sort
of
like
git
commits
and
configurations
are
sort
of
like
the
floating
head
of
your
git
branch,
and
so
you
know,
as
you
make
changes
to
your
branch
new
commits
happen,
but
the
old
commits
are
always
there,
and
so
you,
you
can
always
sort
of
reference.
C
C
C
I
think
it's
our
next
meme,
if
I'm
not
mistaken.
Okay,
yes,
so
this
is
this
is
my
favorite
bit
of
a
native
flood
right.
So
when
we
first
launched
this
was
actually
true.
We
did
actually
need
istio,
but
one
of
the
pieces
of
feedback
we
got
pretty
quickly
was
that
you
know
there
are
other
networking
layers
out
there.
You
know
some
folks
don't
want
sort
of
the
full
mesh
style,
networking
layer-
some
you
know
just
want
to
deal
with.
C
You
know
ingress
style,
networking,
and
so
one
of
the
things
that
we
did
was
we
built
an
abstraction
between
sort
of
that
sort
of
describing
what
we
need
from
the
networking
layer
where
you
know,
kubernetes
ingress
wasn't
quite
cutting
it,
and
I
think
everyone
has
sort
of
accepted
that
two
kubernetes
ingress
v.
You
know
now
v
one
it
was
v
one
beta
one
at
the
well
at
the
time
and
for
well,
it
seems
like
forever,
but
so
we
we
built
an
abstraction
that
you
know.
C
B
You
know
the
the
thing
that
I
wanted
to
add
before
we
move
on
is
just
that,
and
I
I
I
don't
think
we
touched
on
this,
but
it's
important.
The
the
service
api
and
configuration
apis
are
subsets
of
the
pod
spec,
and
so,
when
we
see
the
demo
later
in
our
talk,
let's,
let's
just
make
it
make
sure
that
we
highlight
that
so
that
people
can
see
it
in
action.
B
The
reason
I
mention
it
is
because
I
I
suspect
that
a
lot
of
a
lot
of
deployments
that
people
have
today
would
translate
directly
into
services
if
folks
wanted
to
try
that
out
and
see
how
their
existing
deployments
work
in
an
event-driven
mode,
where
they're
scaled
down
and
back
up
depending
on
load.
But
otherwise
I
think
you
covered
it
very
thoroughly
and
I
will
just
go
ahead
and
advance
the
slide
now
to
the
road
map.
C
C
E
E
C
Yes,
finally,
something
to
do
with
all
those
domains
you've
been
buying,
so
one
of
the
other
really
cool
things
that
I
like
that's
been.
This
has
been
in
the
works
for
a
few
releases.
Now
this
idea
of
gradual
roll
out,
so
we
we
support
very
fine
grain
traffic
control
where
you
can,
you
know,
take
revisions
directly
and
split
across
them
with
pretty
fine
grain,
but
one
of
the
most
common
modes.
C
C
C
B
B
F
I
saw
you
talking
about
the
way
that
the
you
can
you've
got
this
idea
of
a
canary
a
roll
out
and
a
roll
back,
and
I
kind
of
we've
been
expecting
to
use
helm
to
do
that,
and
I'm
just
wondering
is
this
an
alternative
or
because
we've
committed
quite
a
bit
to
to
model
our
applications
to
be
deployed
as
helm
charts,
and
I
just
wanted:
does
this
integrate
with
it?
Or
does
this
replace
it
as
a
mechanism
for
rolling
and
upgrading
between
versions
of
services.
C
So
that's
that's
a
good
question,
so
I
don't
think
we
do
anything
specifically
to
integrate
helm
sort
of
more
deeply
than
what
you
can
do
with
helm
and
our
yaml,
and
you
should
be
able
to
use
k
native
sorry,
helm
to
roll
out
k
native
services
and
much
the
way
you
can
roll
out.
You
know
other
resources.
C
But
I
think
we
haven't
done
anything
to
sort
of
integrate
with
home.
More
deeply
with
respect
to
you
know,
awareness
of
its
revision
model
and
but
there's,
I
think
in
principle,
nothing
stopping
you
from
leveraging
helm
to
manipulate
native.
You
know,
can
it
native
concept
of
traffic
control,
so
one
of
the
things
we
did
introduce
is
we
have
this
more
sort
of
sophisticated
way
of
sort
of
doing
fine
grain
control,
where
you
can,
rather
than
just
having
us,
generate
names
for
each
new
revision?
C
You
can
bring
your
own
name
for
the
revisions
which
allows
you
to
sort
of
predictably
stamp
out
new
names
for
revisions,
which
you
can
then
use
in
traffic
control,
and
so
that
allows
you
to
do.
I
I
think
it
allows
you
to
do
more
like
what
you
were
describing,
but
there's
no
deep
integration.
If
that's
the
question.
C
So
today,
today,
all
revisions
need
to
live
in
the
same
name,
space
and
most
of
the
resource
model
within
serving
expects
things
to
live
within.
You
know
a
single
namespace
and
for
some
extent
it's
designed
so
that,
if
you,
if,
if
you're,
leveraging
namespace
as
your
as
your
tenancy
model,
you
should
be
able
to
end
users
credentials
to
manipulate
native
serving
resources
within
that
namespace
and
they
should
be
able
to
operate
productively.
If
that
makes
sense,.
B
There's
one
other
question
that
I'll
call
out
for
now:
it's
not
the
only
question
in
there,
but
it's
the
one
that's
closest
to
serving,
and
the
question
is:
will
let's
see
when
is
there
an
eta
on
functions
coming
coming
to
k-native,
and
I
would
say
at
this
point:
there
really
is
not
an
eta
that
we
can
give
we
had
like
in
our
community.
We
had
maybe
a
couple
times.
B
The
subject
has
come
up,
but
we
so
far
haven't
and
I
think,
there's
a
very
great
interest
in
having
a
concept
of
functions.
That
is
that
that
is
on
top
of
k
native,
that's
community
based,
but
we
so
far
haven't
been
able
to
agree.
I
don't
think
on
an
approach,
so
I
can't
really
give
an
eta
now.
It's
definitely
on
our
radar,
and
I
appreciate
you
know
the
equip
the
question
being
asked.
B
I
think
I
think
what
would
what
would
be
great
from
the
if
the
the
person
who
asked
the
question
is
very
interested
in
it.
I'd
love
to
get
a
note
about
that,
to
the
k
native
dev
or
k
native
users,
mailing
list,
they're,
they're,
k,
native
dash,
dev
and
k
native
dash
users,
and
it's
homed
in
google
groups,
I'd
love
to
get
some
surfacing
of
that
in
there.
I
definitely.
B
I
will
definitely
surface
that
it
came
up,
but
so
far
we
we
can't
really
give
any
eta
on
it,
and
I
think,
in
the
interest
of
time
it's
probably
best
to
advance
the
slide
now
and
I
think
that
will
be
eventing
so
scott.
Why
don't
you?
Why
don't
you
take
this
section
as
the
the
eventing
rep
on
our
little
call.
E
Producers
generate
events
before
consumers
exist
things.
So
basically,
eventing
has
a
hard
problem
because,
there's
you
know,
20
30
years
of
eventing
history
in
compute,
right,
like
serverless,
is
fairly
new
and
there's
no
real,
like
cookbook
patterns
of
how
you
cook
up
a
serverless,
containerized
thingy,
but
eventing
patterns
and
messaging
patterns
have
been
around
forever.
E
E
One
thing,
the
slides,
don't
really
say,
is
eventing's
really
broken
up
into
a
few
different
big
major
chunks.
We
started
out
with
messaging,
we
have
a
messaging
api
group
and
it
kind
of
it.
It
puts
a
thin
abstraction,
on
top
of,
like
pub
sub
components,
turns
out,
that's
really
hard
to
build
with,
because
it's
very
imperative
on
how
you
would
assemble
your
your
cluster.
So
we
came
up
with
a
second
model
that
sits
on
top
of
that.
That
can
leverage
it,
but
it
doesn't
have
to.
E
E
You
pluck
events
out
of
that
mesh.
Using
a
trigger
trigger
points
to
a
broker
has
a
filter.
You
could
consider
it
like
a
query
once
that
query
matches
that
that
event
gets
copied
out
of
the
broker
and
delivered
to
a
subscriber,
and
we
have
a
bunch
of
magic
here
to
let
this
be
discoverable
and
late
bound
and
self-healing,
and
things
like
that.
B
E
Yeah,
okay,
so
the
as
we
were
developing
of
eventing
components.
We
we
kind
of
had
this
idea.
I
think
villa
and
I
were
talking
to
matt
and
we
hit
upon
this
idea
that
well
potentially
k
native
serving
we
don't.
We
don't
want
those
components
to
be
coupled
right.
So
eventing
knows
nothing
about
serving
it's
independent,
but
they
do
share
some
common
interfaces
that
we
call
duct
types,
but
basically
the
the
trigger
can
point
to
this
duct
type
that
we
call
addressable,
which
basically
says
in
your
status.
E
E
E
E
E
E
E
How
do
I
know
in
the
data
plane
that,
if
I'm
going
to
invoke
some
subscriber,
how
does
that
subscriber
understand
that
it
can
reply
to
the
broker
to
re-ingress
and
invent
back
in?
So
why
would
you
want
to
do
that?
Well,
we
had
this
interesting
thought.
What
if
the
broker
allowed
you
to
reply
to
events
and
then
those
new
events
that
you're
replied
with
gets
ingress
back
into
the
broker,
so
you
never
have
to
know
which
broker
invoked
you
right,
so
smaller
footprint,
smaller,
more
reuse
of
your
deployed
components,
things
like
this.
E
E
So
then,
in
the
next
six
months,
we're
still
catching
up
on
the
auto
scaling
of
the
eventing
components,
still
working
on
that
we're
partnering
with
projects
like
cada
to
to
look
at
well
pole
based
scale
models.
Maybe
cada
is
the
the
way
and
so
like
we'll
we're
we're
adding
hooks
and
plug
points
and
some
standards
on
how
you
get
your
eventing
components
to
scale
with
external
things
like
cada.
E
We're
looking
at
well,
so
you
know
we
make
cube
events
to
understand
what's
going
on
and
we
make
these
cloud
events
that
are
in
the
data
plane
that
your
application
is
making,
but
we're
kind
of
looking
at
well.
Maybe
there's
a
third
category
kind
of
in
the
middle
of
what
would
my
application
say
if
it
could
make
events
and
then
how
would
I
route
those
things
and
react
to
it
so
event
model
event,
driven
models
for
your
application
and
all
of
the
components
that
enable
your
application,
business
and
canadian
eventing
is
it's.
E
D
D
Actually,
of
course,
you
can
everything
you
can
do
everything
with
resource
files
as
well,
but
actually
I
see
a
dedicated
cli
for
kind
of
has
some
advantages,
so
you
can
distinguish
between
two
mode
over
running,
so
one
is
the
imperative
mode
so
that,
as
you
know,
from
cube
control
as
well
and
you
can
actually
manage
nearly-
I
think,
all
of
the
connective
core
entities
which
are
user
facing
directly
with
quad
operations.
So
you
can
create
them.
D
You
can
make
updates
and,
of
course,
list
them
in
various
details
in
a
human
consumable
format
and
of
course
you
can
delete
them
as
well,
so
that
you
can
group
them
also
into
different
areas
like
we
have
for
creative
serving
we.
We
know
how
to
manage
services,
we
can
create
manage
kinetic
computer
services
and
also
revisions,
and
also
for
eventing.
We
have
different
yeah
for
every
entity.
You
have
kind
of
a
noun,
so
it's
always
the
same
schema,
so
you
have
a
kn,
then
you
have
the
the
noun
and
then
the
verb.
D
D
Also
with
kn,
but
there's
also,
this
called
so-called
declarative
handling
of
creative
services,
which
allows
you
really
to
describe
your
target
state
that
you
want
to
have,
and
this
has
the
same
semantics
like
cubecontrol
apply,
which
means
you
have
get
a
three-way
merge
with
the
stuff
which
happens
in
the
meantime
between
two
runs
of
apply,
for
example.
So
it
includes
the
same
way
and
actually
it
even
reuses
the
way.
How
cube
control?
Does
this
merging
and
also
borrowed
from
the
cube
control
architecture
is
the
plugin
are
the
plugins
that
are
similar
to
crit
control?
D
There
is
one
thing
which
is,
I
think,
which
is
in
addition
to
the
way,
how
clip
control
handles
plugins,
so
plugins
and
cube
control,
just
external
programs
which
are
executed
by
like
actually
by
executing
it
from
from,
like,
like
a
type
like
a
comment.
So
it's
it's
a
separated
process
for
that,
but
you
can
also
create
a
inline
plugin,
so
which
means
if
your
plugin
is
written
in
golang,
then
you
could
also
make
a
separate
or
own
build
of
your
of
kn
and
then
inline
that.
So
this
is
quite
quite
nice.
D
If
you
want
to
have
kind
of
a
single
binary
which
includes
a
certain
amount
of
plugins-
and
we
are
currently
working
also
on
our
cube
on
the
kn
builder
project,
which
allows
you
to
declare
the
plugins
that
you
want
to
include
and
then
just
run
that-
and
you
get
just
one
blob
of
binary-
that
you
can
execute
with
all
the
plugins
included.
This,
of
course
only
works
for
golang,
but
the
the
regular
plugin
architecture
works
for
any
language.
D
Of
course,
then
we
also
added
recently
github
support,
as
we
call
it,
which
means
we
have
dedicated
text
on
task
that
you
can
reuse
in
the
tectum
pipelines
for
deploying
your
creative
services
and
brand
new
fresh
from
the
press
is
an
offline
generation
of
resource
files.
So
you
can
actually
operate
kn
against
your
local
file
system.
D
So
you
don't
do
not
need
to
have
a
direct
connection
to
your
cluster,
but
you
just
add
an
option:
minus
minus
target
and
you
provide
a
directory
or
file
name,
and
then
it
just
creates
the
resource
files
directly
from
the
arguments
that
you
provide
to
kn.
So
this
is
a
very
easy
way
how
you,
even
if
you
do
not
have
a
cluster
at
hand,
but
you
also
do
not
remember
the
schema
of
the
creative
services
of
the
creative
resources.
D
Then
you
can
just
re-use,
kn,
use
the
help,
messages
and
then
just
use
some
arguments,
and
this
will
build
up
for
you,
the
yaml
files.
This
is
very,
very
convenient
and
then,
of
course,
you
can
take
that
file,
commit
it
into
your
source,
control
management
system
and
go
on
go
ahead.
So
this
is
very,
very
nice,
so
we
just
have
the
support
for
k
and
service
create,
but
actually
we
are
also
continuing
this
theme
by
adding
it
to
update
and
to
yeah
into
list
and
so
on.
D
So
really,
this
is
really
a
very
nice
feature
which
I'm
pretty
excited
about.
Yeah.
This
is
a
nutshell,
is
what
can
do
for
use?
Actually
it's
really.
You
can
everything
you
can
do
resourceful
as
well,
but
it's
much
much
more
convenient
in
my
opinion
that
you
can
use
kn
on
the
command
line.
You
can
install
it
easily
with
broom
if
you're
on
mac
on
s
or
linux.
You
have
also
brew
for
linux
support.
D
D
D
D
So
a
regular
user
is
not
necessarily
able
to
read
crds
and
based
on
this
media
information,
we
want
to
support
different
command
line
arguments,
so
we
really
want
to
offer
dynamically
common
line,
arguments
that
are
based
on
the
type
that
you
are
managing,
so
this
is
kind
quite
challenging,
but
actually
this
will
give
you
a
nice
user
experience.
I'm
know
pretty
sure
then
another
thing
which
I'm
I'm
very
excited
about
kind
of
also
called
called
cameras.
Sorry,
so
if
you
don't
know,
camelette,
then
no
problem,
because
this
is
really
brand
new
technology.
D
D
And
finally-
and
we
are
always
trying
to
improve
here-
is
user
experience
so,
but
we
also
rely
on
your
feedback
for
that.
So
actually
we
have.
We
know
some
weak
points
in
the
user
experience,
for
example,
the
way
how
we
can
specify
traffic
splits,
which
you
can
definitely
do
with
kn,
but
we
feel
this
can
be
better
and
yeah.
So
we
are
going
to
improve
on
this
story
and
yeah.
So
this
is
the
roadmap
virtue
which
we
will
work
on
in
the
next
six
months.
I
would
say.
B
All
right,
thank
you
very
much
it.
You
know
listening
to
this
stuff
that
we're
all
talking
about
in
this
presentation.
I'm
like
this
sounds
pretty
cool,
but
will
it
blend
so
scott?
I
believe
you
got
a
demo
you're
going
to
show
us
to
establish
whether
or
not
it
will
blend.
Here's.
Where
I
will.
I
will
shut
down
the
screen,
sharing
and
scott
go
ahead
and
you
can
share
your
screen
and
we'll
come
back
to
this
deck
in
a
moment.
E
E
Cool
okay:
here
we
go
so
I
have
been
talking
to
my
friends
over
at
falco.
If
you
don't
know
what
falco
is
it's
a
a
thing
that
watches
this
events
that
are
interesting
and
turns
them
into
web
hooks?
There's
this
other
project
called
falco
sidekick,
which
turns
those
events
into
some
other
thing,
and
I
was
like
well,
you
guys
don't
really
have
cloud
events
there,
and
so
I
helped
them
at
it,
and
here's
a
demo
of
using
falco
and
sidekick
to
do
some
stuff
so
cube.
E
E
So,
let's
see
first
off,
let's
take
a
look
at
the
graph
here,
so
in
my
cluster
right
now
I
have
a
sync
binding
that
that
links
the
falco
sidekick
into
the
ingress
of
the
broker.
So
remember,
the
broker
only
consumes
cloud
events,
so
cloud
events
are
going
to
bounce
around
in
there
and
then
I
have
this
trigger
to
send
anything.
That's
from
falco.org
with
the
type
falco
rule
output
to
this
sockeye
service.
So
what
the
heck
is
sakai,
it's
another
fish
program.
E
E
E
E
B
E
B
E
E
E
E
E
So
now
we
can
see
the
event
stream
that's
coming
through
the
broker,
but
we
can
also
cherry
pick
that
the
this
terminal
and
shell
and
send
it
to
the
drop
service
which
goes
and
invokes
death
onto
my
my
interactive
shell,
that
I
maybe
I'm
trying
to
do
some
malicious
things.
So
I
whip
this
up.
Super
quick,
it's
not
a
ton
of
code.
I
got
to
show
you
code,
which
is
cool
any.
B
B
Okay,
will
it
blend
it
blended?
So
that
was
good.
Let's,
let's
talk
about
2021
girls,
real
quick
as
we're
we're
running
over,
and
I
thank
everybody.
That's
still
watching
so
number
one.
My
own
personal
opinion
here
is
that
we
we
have
the
candidate
of
apis
are
at
a
v1
level
and
v1,
meaning
you
know
good
expectation
of
backward
compatibility.
B
B
We
also,
I
think,
are
really
interested
inside
the
community
of
folks
that
develops
k
native
and
having
more
integrations
and
the
one
that
scott
has
just
showed
us
is
a
really
great
example
of
the
type
of
integration
that
I'd
like
to
see.
You
know
the
more
things
there
are
that
spit
out
cloud
events
and
can
consume
cloud
events.
The
the
more
utility
k
native
is
going
to
have
for
everybody.
B
C
B
Here.
I
think
that
in
general,
serverless
is
still
a
fairly
advanced
topic,
and
you
know
if
you
think
about
the
growth
of
the
the
kubernetes
community.
That
kind
of
looks
like
a
hockey
stick
right
and,
and
what
that
tells
me
is
that
if
we
think
about
the
appetite
for
advanced
topics
that
probably
there
are
still
a
lot
of
folks
that
are
beginning
their
kubernetes
journeys
right
now,
I
expect
the
demand
and
adoption
opportunities
will
grow
and
it's
it's.
B
You
know
coming
from
the
frame
of
mind
of
somebody
who's
serving
on,
steering
and
wants
to
help
grow
the
project.
I
think
there's
a
lot
more
adoption
out
there
to
get
us,
so
that's
definitely
something
that
I
think
that
we'll
work
a
lot
on
in
the
community
and
we
also
really
want
to
grow
the
pool
of
contributors.
B
So
I'll
just
take
this
opportunity
to
say
you
know
if
you're,
if
you're
watching,
and
you
think
that
this
project
sounds
interesting
to
you
and
and
it
might
be
something
that
you
would
be
interested
spending
your
time
on.
However,
how,
however,
much
time
you
had
to
give,
I
would
just
say
that,
like
I,
I
think
we
have
a
really
great
friendly
community
in
k
native
and
we're
also
really
interested
in
growing
the
pool
contributors.
B
So
I
would
just
say
like
if
you
have
any
thoughts
about
like
you
know,
you
want
to
contribute,
but
you're,
not
sure
what
you
could
do,
maybe
you're
not
as
focused
on
code.
I
will
just
say
that,
like
I
think
that
there
is
something
for
everybody
to
contribute
in
open
source
and
I'm
I'm
really
interested.
B
If
you
have
the
urge,
if
you
have
the
interest,
if
you
have
the
desire
to
contribute
but
you're,
not
sure
how
you
could
do
it,
I
I
would
love
for
you
to
to
ping
me
and
talk
to
me
about
it.
You
can
hit
me
on
on
twitter
at
cheddarmint,
and
you
can
also
get
me
p-m-o-r-I-e,
redhat.com
and
I'd
love
to
talk
to
you
about
how
you
could
contribute.
We
definitely
could
use
your
help
and
it's
a
lot
more.
B
You
know
when
I
think
that,
probably
in
this
audience
like
there's,
maybe
an
unconscious
bias
toward
thinking
of
like
open
source
contribution
as
being
all
code,
and
that's
just
simply
not
the
case.
So
if
you
can,
if
you
can
read
documentation
and
tell
us
what
did
or
didn't
work
for
you
from
that
documentation,
that's
contribution
that
would
be
very
valuable
for
us
writing.
A
B
B
A
E
C
D
A
And
correct
that
slide
and
I'll
upload
the
video
to
the
openshift
commons
playlist
shortly
and
tweet
that
out
with
the
slide.
So
with
that,
I
think
we
need
to
end
and
wrap
up
and
respect
everybody's
time
and
really
thank
you
all
for
for
coming
and
all
the
work
that
you
do
in
the
k-native
community.
It's
wonderful
to
see
your
faces.
I
think
each
one
of
you
probably
could
do
an
ama
on
your
individual
topics,
so
we
probably
will
have
you
all
back
in
the
coming
months.