►
Description
In this video we focus on a Serverless workflow within Kubernetes, specifically Knative running within OpenShift 4. We begin the workflow by building our application with Knative's build component. utilizing a CICD pipeline and OpenShift's native build system. We then run our application using Knative Serving, which will dynamically scale our application based on current load. We then check out Knaitve eventing to capture emited message bus events through our subscription. Later in the video we find a bug within our application and we inspect how to best roll out the fix using a canary release which allows us to slowly validate the fix. Finally, we stop the traffic flow to our KService and show our application scaling down to zero, actively waiting for traffic to come to it.
A
Hi,
my
name
is
Brian
Tanis
and
I'm
with
a
Red
Hat
cloud
platforms.
Business
unit
in
this
video,
we'll
focus
on
K
native
running
within
OpenShift,
we'll
be
able
to
see
what
k
native
has
to
offer
like
building
our
application
through
K
NATO's,
build
component,
then
running
that
image
through
K
native
serving
and
then
finally,
we'll
use
K
native
eventing
to
be
able
to
emit
IOT
events
through
the
serving
service,
we'll
roll
out
canary
releases,
as
well
as
being
able
to
show
how
the
application
is
able
to
scale
down
to
zero.
A
Our
first
step
is
to
set
up
certain
rights
to
the
default
service
account
in
our
namespace.
We
have
a
llamo
file
that
has
three
roles
and
three
role
bindings
configure
these
configurations
allow
k
native
to
perform
the
actions
that
it
needs.
We'll
push.
This
configuration
to
the
cluster
next,
we'll
define
a
build
template
using
K
native
builds,
which
defines
a
blueprint
for
our
build.
The
build
component
and
K
native
is
not
so
much
utility
to
build
images
itself.
A
It
rather
provides
a
primitive
to
be
able
to
string
together
the
tools
that
we
want
to
be
able
to
do.
Our
own
build
in
our
case
the
most
prominent
example,
is
open
ships
own
build
capacity,
so
in
this
demo
we'll
implement
a
que
native,
build
by
the
means
of
an
open
shift
build
now
that
we
have
a
build
template,
we
could
run
our
own
build
using
the
amell's
shown.
Instead,
it's
more
interesting
to
see
how
the
build
is
string
together
using
the
serving
component
of
K
native.
A
Next,
we'll
build
in
deploy
our
application
using
the
K
native
serving
component.
As
you
can
see,
the
spec
run
latest
configuration
build
section
is
a
one-to-one
copy
of
the
build
manifest
that
we
could
have
deployed
earlier
once
we
apply
this
configuration,
K
native
will
go
ahead
and
deploy
a
revision
or
a
configuration
of
the
application.
At
a
specific
point.
In
time
now,
k
native
will
kick
off
the
build
for
our
app.
We
could
see
this
happening
by
heading
to
the
open
shift
console
going
to
our
project
and
clicking
on
builds.
A
Once
the
build
is
successful,
we
could
head
to
the
image
streams
in
the
open
shift
console
and
see
that
the
image
has
been
pushed
to
the
internal
registry.
We
then
could
go
to
deployments
and
see.
One
of
one
pod
is
available
running
our
application.
We
could
test
the
app
by
curling
the
route
in
openshift,
which
we
created
earlier
using
the
workaround.
A
So
far,
we
have
used
two
of
three
components
of
K
native
K
native
build
which
allows
us
to
build
our
application
and
then
K
native
serving
which
allows
us
to
run
those
applications
based
on
HTTP
requests.
The
third
component
of
K
native
is
K
native
eventing.
Eventing
allows
us
to
invoke
the
application
in
response
to
other
events
that
we've
received
from
something
like,
maybe
a
message
broker,
or
an
external
application
for
the
rest
of
the
video
we're
going
to
show
how
to
receive
kubernetes
platform
events
and
route.
A
Those
in
to
our
K
native,
serving
application
to
begin
with
K
native
eventing.
We
will
deploy
the
three
primitives
that
are
required.
The
first
is
a
channel
in
our
example
we're
just
going
to
use
an
in-memory
channel,
but
in
production
we
probably
would
want
to
use
something
like
Apache,
Kafka
or
another
message
platform.
The
second
component
is
called
the
event
source,
and
this
is
where
things
are
starting
to
get
a
bit
more
interesting.
In
our
example,
the
event
source
is
a
container
source
which
is
running
a
container
image.
A
A
A
We
are
able
to
visualize
exactly
what's
happening
using
key
Olli,
the
graph
visualizes,
how
the
app
we've
deployed
is
connected
with
various
components
of
K
native.
We
could
see
how
the
events
flow
through
each
component
of
K
native,
as
well
as
roughly
seeing
how
can
a
t'v
serving
works
underneath
one
of
the
other
things
that
we
notice
is
that
our
application
has
a
problem.
This
is
indicated
by
the
error
rate
being
100%
and
all
requests
being
a
500
type.
Http
error,
since
our
application
contains
a
bug,
we'll
need
to
fix
this
quickly
and
safely.
A
To
do
so,
we'll
rely
on
a
concept
called
a
canary
release.
A
canary
release
allows
us
to
deploy
a
new
version
of
our
application
and
gradually
shift
more
and
more
traffic
to
that
version.
This
allows
us
to
validate
the
fixes
in
place
in
our
case,
there's
already
a
fixed
version
of
our
application
available
as
v2.
A
One
of
the
interesting
things
that
were
able
to
see
in
key
ollie
is
the
activator,
which
is
a
component
of
K
native
serving
the
activator
allows
requests
to
come
in,
while
the
K
native
serving
service
is
scaled
to
zero
or
just
initially
coming
up.
The
activator
will
hold
those
requests,
while
the
K
native
serving
service
is
coming
up
and
send
them
to
the
service.
Once
it's
ready,
we're
able
to
see
that
50%
of
the
events
that
are
being
pushed
are
successful.
Our
canary
release
works.
A
A
We
could
see
that
all
the
traffic
now
goes
to
version
2
and
the
error
rate
is
now
zero.
A
promise
of
service
allows
the
application
to
scale
down
to
zero
in
the
event
of
no
traffic.
If,
for
some
reason,
traffic
came
back
to
the
service,
the
activator
would
hold
that
traffic
until
the
container
is
back
up.
We're
able
to
cease
traffic
from
getting
to
our
K
service
by
removing
our
subscription
traffic
will
slow
down
and
we're
able
to
see
this
in
ki
Olli.
Finally,
we
could
see
OpenShift
scaling
our
K
service
down
to
zero.