►
From YouTube: Kn, The One-Stop Shop for Knative - Navid Shaikh, VMware (WG lead) & David Simansky, Red Hat
Description
Kn, The One-Stop Shop for Knative - Navid Shaikh, VMware (WG lead) & David Simansky, Red Hat (WG lead)
Knative simplifies serverless application deployments of cloud-native workloads. Knative brings you flexible consumption-based autoscaling and provides the primitives for creating production-grade event-driven applications. In addition, the command-line tool "kn'' simplifies the Developer workflow with Knative greatly. This presentation takes you through the steps of a typical developer workflow with kn. From the initial, imperative, and iterative creation of services, over GitOps integration into a CI pipeline up to the final production rollout, kn supports all of these stages. Kn also supports kubectl-like plugins for supporting features like connecting to backends like Kafka or a rich Function experience for building Knative services from scratch. After introducing Knative itself, we will show how easy it is to run applications with Knative from the command line with a set of live demos. At the end of this session, we are sure that kn became your new Knative best friend.
A
Okay,
so
let's
get
started
as
a
reminder,
use
the
sketched
app
rate.
The
talks
to
select
who's,
which
of
the
speakers
will
be
the
winner
for
the
oculus
or
the
nintendo
switch
sponsored
by
ibm
and
also
that
will
give
you
a
entry
that
you'll
be
able
to
write
your
name,
I'm
going
to
the
raffle
for
one
of
the
two
we
haven't
decided,
which
one
is
for
the
speaker
and
participants
so
to
wait
for
the
noise.
A
B
C
Hello,
so
I
am
actually
david.
One
of
the
working
group
leads
in
native
client
working
with
redhead
currently
and
just
the
background
story.
We
used
to
work
with
navid
as
I
have
joined
the
serverless
team
in
redhead
and
unfortunately,
he
left
to
vmware.
But
we
were
colleagues
and
we
are
still
like
good
friends,
friends.
So.
C
C
So
I
think
the
teams
team
was
ongoing,
pretty
much
with
other
representations
from
from
functions
guys
and
like
the
developer.
Oriented
talks
that,
maybe
not
everybody
is
fan
of
yamu
and
yamos
at
all
and
and
all
the
declarative
stuff,
and
for
that
kn
is
trying
to
be
a
bit
different
with
imperative
style
of
commands
and
with
the
proposition
that
we
really
know
what
k
native
is
about,
and
we
know
the
resources.
C
B
Right
so
ykkn
is
one
stop
shop,
so
we
will
see
like
how
to
get
started
with
kane
and
k
native
in
like
a
few
minutes.
So
this
is
how
you
install
okay
n.
We
have
it
registers
on
brew
package
managers,
you
just
do
blue,
install
k,
n
and
it
gets
you
okay
installed.
As
you
do
k
n
version,
you
can
see
that
you'll
see
what
all
can
you
serving
and
eventing
version.
B
It
supports
note
that
this
is
showing
the
versions
of
serving
and
eventing
that
we
support,
not
the
ones
that
you
have
installed
all
right
and
let's
take
a
quick
look
at
how
you
can
get
started
with
a
kinetic
setup.
If
you
are
new
to
canadian,
you
have
a
working
docker
set
up
on
your
local
machine,
so
we
have.
You
know
I'm
going
to
give
a
sneak
peek
into
the
quick
start,
plugin
that
carlos
and
paula
has
been
working
so
this
this
can
get.
B
You
started
with
knit
in
five
minutes,
so
you
install
the
plugin
quick
start
and
you
just
do
k
and
quick
start
kind.
You
can
also
do
mini
cube.
So
this
is
how
you
know
it
takes.
So
just
take
a
look
at
the
last
second
last
line.
It
got
you
a
kinetic
cluster
on
kind
in
five
minutes
and
you
are,
you
are
ready
to
go.
B
This
is
just
a
quick
installation
of
like
how
does
the
serving
and
eventing
installation
looks
like.
So
we
are
passed
through
the
installation
and,
let's
take
a
look
at
you
know
how
you
know:
kn
interacts
with
canadians,
so
it
just
works
everywhere.
So
kane
strictly
works
with
the
api
contract
of
canadian.
So
whether
you
have
kubernetes
cluster
on
any
of
the
kubernetes
provider,
you
just
install
canadian
apis
serving
and
eventing
apis
on
top
and
you're.
D
B
Ready
to
go
apart
from
that,
as
david
mentioned,
like
we
have
rich
ecosystem
of
plugins,
so
we
do
have
special
use
case
plugins,
which
can
work
with
directly
with
generative
apis
or
it
can
work
work
with
the
kubernetes
cluster
that
you
have
so
any
specific
requirements
on
the
on
the
kubernetes
distribution
that
can
be
expanded
to
k
and
y
the
plugins.
But
okay,
and
if,
if
you
bring
up
a
installation
on
openshift
or
on
tanzu
or
on
aks,
can
just
strictly
work
all
right.
C
There
is
a
couple
dozens
of
them
and
it
might
be
pretty
hard
to
keep
with
all
the
annotation
formats
or
anything
you
you
would
like
to
do
with
your
services
with
regard
the
configurations
and
all
the
options
you
would
like
to
set
up.
So
we
are
trying
to
offer
the
convenient
way
for
the
developers
to
power
through
the
help,
messages
and
quickly
find
the
the
correct
flag
without
the
additional
knowledge
of
the
full
format,
and
so
on.
C
C
C
And
finally,
we
are
not
like
ditching
all
the
ammo
support
and
there
is
a
way
to
actually
generate
a
lot
of
or
actually
generate
those
outputs
that
we
would
normally
do
on
the
back
end
in
a
given
ops
mode.
So
you
would
you
could
store
that
get
the
yamls
edit
them
by
yourself
or
or
just
see
the
plainly
see
the
outputs
and
use
them
in
a
in
a
in
a
version
mode
that
you
would
just
keep
it
in
your
git
repository
and
work
from
there.
C
C
B
It
also
supports,
like
all
the
sources
that
kinitive
provides
the
epa
server,
source
container
source
and
ping
source
and
with
the
extensible
mechanism
of
plugins.
We
are
also
able
to
do
the
crud
operations
on
the
extended
sources,
for
example,
apache,
kafka
and
gamelets.
So
we'll
see
like
how
you
can
expand
genitive
with
plugins
to
also
support
these
extended
sources
in
the
ecosystem.
B
So,
as
you
can
see
for
channels
and
subscription,
we
have
complete
credit
operation
support,
decide
on
sources
like
we
have
list
and
list
types
commands
which
will
list
you
all
the
types
of
sources
available
in
your
cluster,
so
so
that
you
can
do
the
cred
operations
on
them
and
then,
since
we
have
like
one
more
layer
of
sub
commands
for
source,
so
you
can
work
with
specific
sources
in
your
cluster
like
eps,
source
and
binding,
and
for
all
of
them.
We
support
the
cred
operations.
B
B
That's
that's
sending
events
to
a
broker
and
then
then
we
have
a
couple
of
triggers
which
will
be
triggered
based
on
a
particular
filter
that
you
know
we
can
embed
in
the
cloud
events
in
itself
and
then
we
have
a
couple
of
interested
things
that
want
to
subscribe.
You
know
that
we
want
to
land
events
to
so,
as
you
can
see,
we'll
start
from
the
left,
we
will
create
a
couple
of
things
there,
so
the
green
boxes,
maps
to
the
green
commands.
B
So
you
you
create
a
couple
of
services,
s1
and
s2,
and
then
the
broker
create
is
simply
k
and
broker
create
it
will
use
whatever
you
have
configured
by
default
in
your
cluster.
If
it's
empty
channel
or
if
some
other
broker
implementation,
then
we
create
a
couple
of
triggers
here
where
we
say
that
we're
gonna
filter
on
cloud
events
that
are
of
type
say
ping
is
equal
to
two.
B
So
this
is
the
filter
that
we
are
using,
that
that
will
identify
the
cloud
events
that
we
are
interested
in
and
finally,
we
are
saying
here
the
sync:
with
the
sync
flag:
you
say
like
what
would
be
the
destination
of
these
cloud
events
and
with
broker.
We
are
mentioning
that
you
know
we
want
to
receive
the
event
from
this
broker.
B
Finally,
you
know
we
send
the
event.
We
are
sending
events
here
with
the
ping
source
default
source
and
we're
gonna
specify
like
we're.
Gonna
send
the
destination
of
these
events
to
the
broker,
and
here
this
c
override
stands
for
cloud
event
override
so
with
with
the
default
parameters
that
that
land
in
them.
B
You
know
that
has
in
the
cloud
event,
we
are
saying
that
also
add
ping
is
equal
to
one
additional
key
value
in
the
cloud
event,
so
that
you
know
trigger,
can
filter
on
it,
and
we
are
saying
this:
this
is
the
additional
data
that
you
want
to
send
to
it.
I
think
that's
all
once
once
this
is
in
place,
you
know
your
events
triggered
from
the
sources
are
then
received
in
sync.
B
B
B
B
B
As
as
you
can
see
here,
we
have
a
admin
plugin
that
gives
you,
you
know
all
the
utilities
to
work
with
kubernetes
cluster,
a
diagram
plug-in
a
function
plug-in
that
that
we
just
saw
the
presentation
earlier
and,
as
you
can
see,
the
the
last
two
ones
are
the
extended.
You
know
the
additional
ecosystem
sources
of
eventing
like
kafka
and
gambling,
so
you
would
be
able
to
invoke
the
plug-in
like
kn
source
kafka
and
all
the
commands
beneath.
B
All
right,
so
how
do
you
do
the
plug-in
inlining
so
on
the
plug-in
source?
You
mentioned
that
you
know
these
are
the
metadata
of
the
plugins
and
on
the
kn
side
you
need
to
specify
you
need
to
wire
this
plugin
in
your
k,
n
source
and
after
once,
that's
done.
You
just
do
go
mod
vendor,
so
it
pulls
in
your
plugin
source
code
and
builds
it
together.
B
B
C
Here
is
the
like
the
overview
of
what
we
will
see
on
a
pre-recorded
video,
it's
a
very
basic
like
a
processing
service
broker
and
even
display
service
just
to
display
the
the
services
eventually,
what
we
are
going
to
do
is
create
every
resource
with
kn
commands
create
triggers
to
to
define
the
relationships
to
define
filters.
And
finally,
we
will
try
to.
There
are
two
implementations
and
we
do
have
like
a
environment.
C
C
Afterwards,
we
are
creating
the
broker
here,
that's
not
synchronous,
so
it's
not
telling
us
too
much
just
describe
command
can
can
tell
us
that
it
is
ready
on
the
right
hand,
side.
I
am
setting
up
the
logging
monitoring
with
service
log
plugin
so
also
through
everything
is
done
through
k,
n
commands.
So,
as
you
can
see,
we
are
watching
the
process
service
log
up
here
and
on
the
bottom
left
bottom
right.
We
are
having
the
event
display.
C
There
is
the
event.
Plugin
is
one
of
the
plugins
that
are
released
with
with
kn
all
together
and
consumed
through
homebrew
tabs,
and
there
is
a
build
command
to
to
build
up
your
your
cloud
events.
If
you
would
like
to
have
a
bit
more
fields
right
now,
I
am
just
specifying
the
the
type
here
and
like
one
of
the
field
is
canadiacon,
and
hopefully
we
will
see
that
processed
on
the
right
side
and
it
took
about
five
seconds.
And
finally,
we
we
see
that
the
message
was
received
on
the
even
display
site.
C
So
then
we
are
going
to
the
traffic
split,
so
it
there
was
a
traffic
split
or
the
traffic
flag
refactoring
recently
that
allows
us
to
actually
mesh
everything
together
in
a
in
a
way
that
we
are
updating
the
service
with
a
new
environment
variable
that
will
create
a
new
revision,
but
we
are
also
specifying
that
for
that
new
revision
that
will
be
created,
the
it
should
receive
the
50
of
traffic.
So
in
one
command
you
are
getting
like
both
operations,
all
together.
C
So
through
describe,
we
should
see
that
we
have
now
a
50
50
split
in
for
the
two
replicas
and
finally,
the
script
is
going
to
create
10
event
or
sent
10
events
into
into
our
processing
services,
and
you
can
see
that
the
the
starting
is
the
name
of
revision
and
which
revision
is
like
processing
the
received
event.
So
there
is,
there
is
some
split
and
the
second
revision
is
actually
pretty
pretty
fast
compared
to
the
first
one
and
doing
more
work
on
it
yeah.
C
C
That
would
be
especially
helpful
for
something
like
functions,
because
functions
can
be
run
as
a
as
a
standalone
binary,
but
also
as
a
k
native
plugin,
and
the
idea
is
that
functions
and
kn
would
be
aware
of
each
other
to
share
the
common
things
like
service
name
and
so
on.
So
you
could
operate
on
if
you
are
in
the
functions.
Context
operate
on,
that
pre-creating
function,
functions
for
your
function
and
so
on
other
than
that
we
have
the
broker
spec
management.
C
That
is
going
to
be
implemented,
that
we
need
to
actually
really
think
about
how
to
approach,
because
every
every
broker
might
have
a
different
solution
for
the
configuration
either
from
configmap
to
custom
resource.
So
we
need
some
good
ux
how
to
actually
approach
it
and
from
other
things,
the
plugin
discovery
and
management
is
another
big
thing
and
I
think
max
is
working
on
on
the
plugin
to
actually
better
search
for
plugins,
so
that
would
be
nice
to
have
and
liveness
and
readiness
probe.
D
Thank
you,
gentlemen,
for
the
presentation.
So
last
year
I
had
to
develop
two
plugins
for
kn
and
maybe
some
feedback
for
you
or
things
have
changed
and
improved
since
then.
So
what
I
was
struggling
with
is
standard
patterns
like
listing
adjacent
formatted
output.
So,
basically
I
was
going
back
to
the
kn
code
base
and
copied
over
a
lot
of
like
libraries
and
some
internal
code
path
to
follow
the
same
like
k
in
broker
list
k
broker
describe,
I
think,
there's
a
lot
of
pattern
that
these
plugins
should
be
reusing.
C
So
we
do
have
we
we
do.
We
did
set
up
a
client
pkg
on
the
main
knit
organization,
but
we
haven't
been
doing
a
great
job
moving
a
lot
of
shared
code
there
so
like
our
approach,
would
be
that
anything
that
would
be
valuable,
sharing
with
plugins
would
be
consumed
from
client,
pkg
and
and
client
would
would
then
depend
on
client
pkg
as
well
for
all
those
common
toolings
or
common
utilities
that
would
that
could
be
shared
so
yeah.