►
From YouTube: Distributed Tracing Integration with OpenTelemetry and Knative - Daniel Oh & James Falkner, Red Hat
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Distributed Tracing Integration with OpenTelemetry and Knative - Daniel Oh & James Falkner, Red Hat
Scaling application platforms give site reliability engineers a significant burden on collecting telemetry data from a single cluster to multiple clouds. You’re probably handy to observe metrics with comprehensive dashboards by 3rd party application performance monitoring tools in the traditional environments. However, the application topologies are getting more complex due to distributing cloud-native microservices. Infrastructures have also been varying from Linux containers to IoT edge devices, public cloud, and Kubernetes. This is a new challenge for dev and ops to trace application chains. This talk guides you through the distributed tracing integration with OpenTelemetry for serverless functions. OpenTelemetry allows you to collect telemetry data such as metrics, logs, and traces then enables you to analyze applications’ performance and behavior. I’ll also showcase a live demo of how to trace metrics of reactive RESTful APIs with step-by-step instructions below: - Collect local telemetry data by OpenTelemtry collector and Quarkus Dev mode - Visualize the telemetry data through the Jaeger console locally - Deploy the reactive serverless functions to verify telemetry data using OpenTelemetry and Jaeger operators
A
Konnichiwa
everyone,
my
name,
is
James
Faulkner
I
work
at
Red,
Hat
I've,
been
at
red
hat
for
about
seven
years
and
I
focus
on
technical
products,
management
and
marketing
for
our
hybrid
platform,
products
like
openshift
and
JBoss,
our
application
development
platform
and
a
number
of
components
on
top
of
that.
So
with
me
today
is
Daniel.
Daniel
want
to
introduce
yourself
sure.
B
Thanks
James,
hello,
everybody,
my
name
is
Daniel
I'm
working
for
Redhead,
record,
James,
Faulkner
and
then
same
team
and
I'm
development,
Advocate
and
also
cncf
Ambassador,
so
pretty
much
focused
on
kubernetes
and
serverless
and
service
mesh,
as
well
as
a
container
runtime
and
like
a
cloud
and
runtime
like
a
Java,
JavaScript
and
so
on.
So
we
are
more
than
happy
to
be
here
today
and
then
we're
going
to
talk
a
little
bit
about
for
the
next
story.
A
Thank
you
Daniel,
so
I'll
speak
for
about
10
or
15
minutes,
and
then
Daniel
has
a
demo
to
Showcase
how
open
Telemetry
can
solve
a
very
important
problem
for
Java
developers
in
the
world
of
cloud
native
computing.
So
here's
pictures
of
Daniel
and
myself
and
our
Twitter
handles
that
picture
on
the
right.
Is
me,
a
few
pounds
lighter
a
few
more
hairs
in
in
kamakurda
south
of
here
in
2002.
That
was
my
first
time.
A
I
worked
at
Sun,
Microsystems
and
I
was
able
to
visit
the
the
countries
my
fourth
time
in
Japan
and
so
really
happy
to
be
here
today
to
speak
to
all
of
you.
Thank
you
all
for
coming.
I
know
I'm
competing
with
a
keynote
speaker
from
earlier
this
morning.
So
thank
you
for
that.
So
I
want
to
get
right
into
it
and
talk
about
observability
I.
Don't
want
to
step
off
the
edge
here.
So
what
is
observability?
You
know
from
the
from
the
English
word.
It
means
you
can
see
something
right.
A
You
can
observe
it,
but
it
also
means
that
you
can
understand
it
and
you
can
draw
conclusions
and
you
can
understand
what
you're,
what
you're,
seeing
and-
and
you
know,
kind
of
process
it
in
your
mind,
right.
It's
really
important
to
be
able
to
do
that
in
software
as
well.
Since
the
beginning
of
of
the
industry,
we
really
need
to
understand
the
systems
that
we
build
so
that
we
can
improve
them
and
make
them
safer
and
more.
You
know,
compliant
and
in
some
cases
and
and
better
and
more
efficient,
so
observability
is
super
critical.
A
One
of
the
challenges
in
observability
is
knowing
what
you
are
going
to
possibly
ask
in
the
future
before
the
time
comes
to
ask
that
question,
and
so
observability
is
really
more
about
capturing
as
much
as
possible
with
it
with
certain
constraints
and
not
limiting
yourself
to
one
specific
angle
or
one
specific
facet
of
your
system,
because
if
you
only
look
at
that,
one
facet
you're
only
going
to
going
to
be
able
to
draw
conclusions
based
on
limited
data
right
so
observability
is
not.
Is
trying
not
to
define
the
questions
up
front
but
more
important.
A
Defining
the
the
types
of
data
that
you
can
collect
effects
that
you
can
observe
and
doing
something
interesting
with
that,
so
this
challenge
also
exists
outside
of
the
world
of
software.
One
example
recently
is
this,
so
you
may
recognize
this.
So,
according
to
this
picture,
the
ball
was
clearly
out
and
Japan
should
not
have
scored
that
goal
right
because
you
got
like
I,
don't
know
a
good
few
centimeters
of
green
there
right.
A
If
you
only
look
at
this
one
angle,
there's
only
one
piece
of
signal:
you're
going
to
draw-
hopefully
well,
not
hopefully
but
you're,
going
to
draw
the
wrong
conclusion
right.
So
having
more
angles
and
being
able
to
observe
multiple
different
facets
of
your
system
can
help
you
infer
a
more
correct
or
more
accurate
conclusion,
so
in
this
case
they
were
able
to
conclude
that
the
ball
actually
was
in,
because
we
had
multiple
signals
that
we
could
draw
from
and
similarly
in
software,
the
same
exact
thing
applies
so
but
getting
down
into
details
as
a
developer.
A
The
kinds
of
questions
you
might
want
to
ask
yourself
is
my
software
running.
Is
my
program
starting,
but
not
actually
accepting
requests
if
something
goes
wrong?
How
do
I
get
to
the
root
cause
of
what
went
wrong
my
map?
If
my
application
is
running,
why
is
it
slow
right?
These
are
the
kinds
of
things
you
might
consider
as
a
software
developer,
but
having
those
multiple
angles
can
open
up
the
aperture
of
stakeholders
to
other
folks
right
in
the
soccer
example,
it
opens
the
aperture
up
to
the
fans
and
others,
and
not
just
the
officials.
A
So
it's
really
great
to
have
those
different
angles
in
your
Telemetry
solution,
so
the
industry
has
made
many
different
attempts
to
Define
what
observability
and
what
Telemetry
is
one
easy,
sometimes
controversial,
but
one
easy
way
for
someone
who's
new
to
observability
is
to
kind
of
put
the
different
types
of
signals
into
these
three
buckets
right,
metrics,
logs
and
traces,
so
metrics
are
you're.
Probably
familiar
with.
A
This
is
like
how
much
memory
is
my
is
my
program
using
logs
or
kind
of
a
a
immutable
list
of
things
that
occurred
in
the
past
and
then
traces
in
particular
distributed
traces
in
the
in
the
age
of
microservices
kind
of
traces.
The
path
of
a
single
invocation
or
single
request
through
the
different
services
that
it
visits
historically
in
the
world
of
you,
know
mainframes
and
monoliths.
A
These
signals
were
log
files
and
stack
traces
or
in
the
in
earlier
cases,
core
dumps
from
the
kernel,
and
then
you
know
an
SRE
would
take
that
and
try
and
try
and
figure
out.
Based
on
that
one
snapshot.
What
happened?
Imagine
if
they
had
you
know
a
full
set
of
of
distributed
traces
and
logs
and
a
set
of
metrics
leading
up
to
an
issue.
It
makes
it
a
lot
easier
to
figure
out
what
went
wrong
and
there's
in
fact,
tools
that
can
help
you
do
that
today.
A
So
one
interesting
aspect
here
is
of
logs
and
traces
grow
linearly
with
the
number
with
the
request
volume.
So,
as
you
get,
you
know
twice
the
number
of
requests
coming
into
a
system
generally
you're
going
to
get
twice
the
number
of
logs
and
traces,
because
you
know
twice
as
many
things
are
happening,
unlike
metrics,
which
are
kind
of
dependent
on
how
the
metric
is
actually
defined.
It
doesn't
always
scale
linearly,
but
that's
important,
to
understand
when
you're
designing
an
observability
system,
because
you
cannot
capture
every
single
possible
facet
of
every
single.
A
You
know
microsecond
in
the
world
of
your
system,
because
you
would
spend
your
time
recording
to
a
file
for
logs
and
not
actually
doing
real
work
in
the
system,
so
you
have
to
there's
some
trade-offs
there
and
open
Telemetry
kind
of
make.
Some
of
that.
In
fact,
a
lot
of
the
prior
art
in
the
world
of
observability
also
recognize
this
same
phenomenon.
A
So
how
do
you
get
these
metrics
logs
and
traces?
Well,
the
kind
of
the
typical
process
is
you
instrument
the
code.
You
collect
the
data,
put
it
somewhere,
you
process
that
data,
and
then
you
draw
conclusions
or
infer
conclusions
or
or
Draw
visualizations
to
help
humans
understand
this
mountain
of
data
right
and
traditional
vendors,
traditional
APM
vendors
kind
of
cropped
up.
You
know,
probably
many
decades
ago,
as
we
started
to
build
software.
As
you
know,
PCS
became
popular
and
a
lot
more
people
started
to
build
software.
A
A
lot
more
vendors
popped
up
to
try
and
attach
attack
this
problem,
which
is
fantastic
right.
You
love
to
see
advances
in
software,
but
the
problem
is
they
of
course,
had
their
solution
for
instrumentation
their
solution
for
data
processing,
their
solution
for
storage,
their
solution
for
visualization
sort
of
get
locked
in
right,
and
once
you
do
that,
it's
really
really
hard
and
very
costly
to
switch.
A
So
that's
sort
of
that
traditional
APM
vendor
offered
that
and
I
can
name
names,
but
I
won't
I'm
sure
you
can
think
of
several
in
this
space
and
the
reason
we're
here
today
is
talking
about
open
source.
So
as
the
state-of-the-art
advanced
in
software
development,
as
we
started
to
build
distributed
systems
more
more
and
more
distributed
systems,
the
cost
of
providing
and
keeping
up
with
the
state
of
the
Art
became
very
high
becomes
very
high.
It
continues
to
rise,
so
these
APM
vendors
decided.
We
don't
really
we
don't.
A
We
don't
really
want
to
spend
the
resources
competing
with
creating
apis.
We
want
to
spend
resources
competing
on
like
visualizations
and
AI
Ops,
and
you
know
sort
of
higher
level
concerns
in
the
world
of
software
and
observability
and
let's
collaborate
instead
of
instead
of
Silo
the
solutions
and
so
a
number
of
of
Open
Source
Solutions
became
known
and
started
to
become
developed
in
the
early
knots
and
so
early
instances.
A
So
as
a
developer
right,
how
do
you
get
started
if
you,
if
you're
a
new
developer,
you
you're
new
to
observability?
And
you
want
to
add
this
to
your
program
or
add
this
to
your
container
runtime
or
whatever
you
happen
to
be
working
on
right.
The
first
thing
you're
going
to
do,
go
to
CSF
and
cncf
website
and
do
a
search
for
monitoring
logging
and
tracing
and
you'll
get
something
like
this
right.
It's
a
little
bit
overwhelming,
there's
lots
of
different
solutions.
That's
the
good
and
the
bad
part
about
open
source
right.
A
Anyone
can
develop
a
solution,
they
can
get
it
listed
on
a
quote,
unquote,
Marketplace
and
now
you're
kind
of
faced
with
a
number
of
somewhat
competing,
somewhat
complementary
Solutions.
So
it's
really
challenging
as
a
developer
to
understand
how
to
get
started.
So
you
know
one
of
the
creators
of
the
Dapper
project,
recognized
this
same
issue
and
and
said
yeah.
We,
you
know,
there's
too
many
loggings,
there's
too
many
tracing
standards.
We
need
one
standard,
so
they
invented
open
tracing.
A
So
open
tracing
was
great
because
it
was
the
first
attempt
at
kind
of
defining
what
a
trace
is.
They
were
working
in
the
traces
area,
the
distributed
tracing
area,
so
they
defined
what
a
trace
is.
Right
a
trace
is
a
directed
acyclic
graph
of
spans
of
work
with
different
metadata
associated
with
each
of
those
spans
and
they
created
an
API
which
is
fantastic
for
tracing.
There's,
no
metrics,
there's
no
logging
just
tracing,
but
it
was.
It
was
a
fantastic
attempt.
A
You
may
recognize
this
cartoon
right.
The
this
is
exactly
what
happened
right,
they're
like
there's
14
different
standards.
That's
nonsense!
We
just
need
one.
So,
let's
create
one
and
then
soon
there's
now
15
new
standards
for
tracing.
So
you
know
it
was.
It
was
another
attempt
a
valiant
attempt
at
that.
At
the
same
time,
other
vendors,
like
Google
itself,
was
working
on
bringing
additional
functionality
above
and
beyond
just
tracing,
so
they
wanted
to
add
metrics.
A
They
wanted
to
not
only
provide
an
API
but
actually
provide
an
SDK
right.
A
binary
downloadable
thing
that
you
can
use
with
your
program.
They
wanted
to
also
provide
kind
of
full
stack
support,
so
not
just
instrumenting
your
code
and
emitting
traces
or
metrics,
but
also
collecting
those
metrics
and
storing
them
and
processing
them
and
providing
hooks
for
other
vendors
to
do
additional
work
on
that
data.
So
this
was
a
kind
of
the
next
evolution
of
a
observability
quote,
unquote,
standard
and
open
source,
which
is
awesome
but
again
right.
A
This
is
a
different
one
in
some
ways,
complementary
to
something
like
open
tracing
in
some
ways
it
competes
with
open
tracing.
So
they
had.
You
know
a
lot
of
overlap
there.
So
the
good
news
is,
they
kind
of
got
together
and
realized
this
together
and
the
two
projects
have
merged
and
actually
this
year,
the
result
the
result
was
released
this
year.
But
this
merge
happened
in
I.
Think
2019.
A
It's
full
stack,
meaning
there
is
a
way
for
you
to
instrument
your
code,
there's
a
way
for
you
to
collect
and
store
the
data,
there's
a
way
for
you
to
analyze
the
data
and
draw
some
basic
conclusions
about
that
data,
and
it
provides
the
ability
for
vendors
like
I,
don't
know
datadog
or
Snick,
or
a
number
of
other
ones
to
compete
in
that
higher
level
space.
So
it's
it's
kind
of
a
win-win
for
everyone.
In
fact,
there
are
I.
Think
there
was
last
count
800
different
contributors
from
150
different
companies.
A
If
you
go
to
the
open
Telemetry
website
and
look
at
the
list
of
companies
that
are
contributing,
you'll
see
all
those
APM
vendors
right,
they
all
want
to
get
out
of
the
business
of
of
trying
to
maintain
and
track
the
state
of
the
art
in
terms
of
how
you
collect
data
and
move
into
a
higher
level,
competition
with
each
other,
so
instead
they're,
basically
contributing
back
and-
and
you
know,
working
with
each
other
to
develop
and
move
the
standard
forward.
So
open
Telemetry
brings
both
metrics
and
logging
and
tracing.
A
So
all
three
of
those
observability
pillars
that
I
mentioned
earlier
are
are
represented
in
open
Telemetry.
Now
the
logging
part
is
not
quite
finished
yet
it
should
be,
hopefully
Goga
sometime
early
next
year,
but
it's
a
fantastic
way
for
you
to
instrument
your
code,
and
you
know
it
does,
as
I
said,
metrics
logging
and
tracing
and
all
that
data
can
be
correlated
with
unambiguous
correlation
but
like.
A
If
you
emit
a
log
file
as
part
of
a
method,
it
can
immediately
be
automatically
attached
to
a
span
and
then
a
trace,
and
then
the
visualization
tools
can
help
you.
You
know
deep
dive
into
a
problem
if
you're
looking
at
a
trace.
That
has
some
performance
issue
that
you
have.
You
can
kind
of
double
click
and
get
down
into
the
logs
and
get
down
into
the
metrics
associated
with
that
Trace.
A
So
it's
a
really
well
thought
through
solution
and
it's
really
powerful
for
again
providing
you
with
the
ability
to
not
Define
the
questions
up
front,
but
to
answer
many
many
many
different
types
of
questions
after
the
facts
when
something
goes
wrong
or
if
you
just
want
to
understand
the
state
of
your
system,
so
very
powerful
and
Daniel's
going
to
show
you
a
lot
about
how
it
works
in
a
moment.
I
just
wanted
to
point
this
out.
So
this
is
the
graph
of
of
contributions.
A
Pr's
commits
on
cncf
projects
and,
as
you
can
see
at
the
upper
right,
there
open
Telemetry,
almost
as
as
active
as
kubernetes
itself,
and
so
this
you
know
a
testament
to
the
power
of
Open
Source
and
the
power
of
communities
coming
together
and
vendors
coming
together
to
work
together
for
a
common
solution.
This
benefits
everyone
in
this
room,
I,
hope
so
yeah.
So
we
hope
to
see
that
continue
going
forward.
A
What
open
Telemetry
is,
as
I
said,
it's
a
library
with
metrics
logs
and
traces.
It
provides
not
only
the
specification
like
what
open
tracing
provided,
but
it
also
provides
sdks
for
in
various
languages
for
binding
to
your
language.
It
defines
what
a
binding
even
means,
meaning
the
different
Native
types
in
a
language,
how
those
map
to
Concepts
defined
by
open
Telemetry.
It
also
defines
an
binary
protocol
for
transmitting
that
data
and
collecting
it
and
massaging
it
and,
more
importantly,
it
provides
a
way
to
maintain
compatibility
with
existing
systems.
A
So
if
you're,
using
things
like
Jaeger
or
Zipkin
or
Dapper
or
any
of
the
other
common
Solutions,
then
you'll
be
able
to
use
open
Telemetry
with
that,
because
it
has
a
way
to
collect
that
data
in
that
native
format,
transform
it
to
the
open,
Telemetry
format
and
then
store
and
process
that
later
on,
so
very
powerful
collector
there.
The
the
thing
on
the
right,
The,
otel
Collector,
it's
sort
of
a
Swiss
army
knife
of
tools,
and
it's
provided
as
part
of
that
project.
A
So
you
can
not
only
use
the
standard
protocol
but
also
the
the
the
existing
protocols
they
may
be
using.
Okay,
so
I
think
that's
it
so
for
Java.
Java
has
a
particularly
challenging
point
in
time.
As
the
cloud
has
matured
Java
has
been,
you
know
traditionally
thought
of
as
heavy
weight
and
slow
and
so
and
not
compatible.
A
If
you
will
with
like
modern
microservices,
and
so
we
Red
Hat
are
doing
a
lot
of
work
and
the
space
and
Daniel
is
going
to
kind
of
show
you
a
solution
for
Java
in
the
context
of
serverless,
which
is
where
that
problem.
The
historical
traditional
Java
is
really
magnified.
So
I'll
pass
it
over
to
Dan.
Thank.
B
You
so
much
James,
so
it's
a
traditional
way.
You
can
open
Telemetry
or
the
other
tracing
tools.
So
you
already
figured
out.
Where
is
my
application?
The
target
environment
together
will
collect
your
Telemetry
data,
while
tracing
data
or
logo
Etc.
However,
the
serverless
application
is
up
and
down
anytime,
based
on
your
network
traffic,
so
it's
very
hard
to
find
out
and
then
collect
your
Telemetry
data.
B
That's
why
I
really
want
focus
on
how
to
how
to
dissolve
this
kind
of
problem
for
developer
and
then
in
the
end,
you
can
connect
that
insightful
Telemetry
data
and
logging
Etc
on
your
infrastructure
layer,
so
the
quarkus
is
new
Java
framework,
just
in
case
you
never
heard
about
that
before.
So
it's
a
lot
of
people
actually
moving
forward
to
JavaScript
or
go
to
use
the
serverless
application
on
tablet.
Amazon
random,
for
example,
because
the
Java
is
a
pretty
heavy
way.
He
was
born
almost
27
years
ago
and
then
it's
a
dynamic
Behavior.
B
You
can
run
Java
application
any
app
server
over
the
internet
technology,
which
is
super
awesome.
At
a
time.
However,
things
change
that
everybody
is
doing
kubernetes
just
like
you
and
then
your
application
container
up
and
down
anytime
and
they're
killed
and
then
scaled
out,
like
10
000,
even
million
containers
anytime
any
soon.
In
that
case,
Java
at
the
dynamic
behavior
is
a
pretty
much,
not
good
behavior
in
the
container
platform.
So
that's
a
lot
of
people
just
move
away
from
java
technology.
However,
we
cannot
ignore
the.
B
There
are
more
than
16.5
million
Java
developer
out
there
in
the
living
in
there
and
then
like
a
developing
these
application
Services
every
single
day,
so
corecus
actually
give
us
some
shiny
thing
for
them:
Java
developer
with
the
a
bunch
of
the
like
a
performance
tuning,
and
then
we
change
the
fundamental
architecture,
and
then
we
give
more
like
a
developer
productivity
Etc
here
so
I'm
going
to
get
right
into
the
demo.
I'll
give
you
such
a
more
like
an
interesting
stuff.
B
I
feel
you
got
a
little
bit
sleepy
after
good
lunch,
so
I'm
going
to
stop
a
boring,
slide
deck
and
then
here's
my
application.
I
already
created
my
application
this
morning.
It's
pretty
simple.
Just
let's
play
API.
You
can
see
that
just
a
recipe
API
I
could
return
and
pointer
hello.
Greeting
welcome
Cube
DJ,
Japan
2022
and
the
other
is
let's
endpoint.
I
could
just
Hotel
open,
Telemetry
and
then
my
session
title.
B
Let's
try
to
I'm
gonna,
run
my
local
environment
just
to
make
sure
my
application
running
and
then
working
on
my
local
environment
and
then
how
to
get
things
done
and
I'm
going
to
stop
it.
So
I'm
going
to
try
to
run
my
local
login
infrastructure,
which
is
the
Jaeger
and
open
Telemetry
in
order
that
I
most
likely
want
to
use
like
a
container
runtime
like
a
like
a
Docker.
B
B
Once
you
eat
around
this
application,
it
automatically
connect
to
open
Telemetry,
because
when
I
go
back
to
my
project
and
then
here's
my
key
and
value
properties,
as
you
can
see,
I'm
going
to
make
a
little
bit
zoomy
here
we
go
and
here's
my
application
name
Services,
which
is
identified
in
the
Jaeger
server.
Here's
my
open
Telemetry
exporter,
which
is
here
the
open
Telemetry
and
the
portal
name,
which
I
did
I
just
run
in
Docker
container,
and
this
is
all
I
I
need
to
do.
B
Let's
try
to
access
one
of
the
endpoint,
hello
greeting
and
now
you
can
see
the
welcome
Cube
day,
just
like
Japan
2020
on
my
people
named
Dan
and
I'm,
going
to
reload
the
web,
the
Jaeger
UI.
Now
you
can
see
the
new
service
came
out,
just
just
correct
your
data
and
then
it's
not
just
directly
Jago.
It's
open
Telemetry
actually
grab
the
data
and
collect
the
Telemetry
data
and
then
send
it
back
to
Jaeger.
And
then
now
you
can
see
check
it
out
your
Jaeger.
B
B
Also
again-
and
now
you
can
see
the
other
endpoint
here
so
hello
Hotel,
including
hotel
and
find
Trace.
Now
you
can
have
a
one
so
I,
just
I,
really
quick
verify
my
application,
how
to
connect
to
my
Java
application
into
Hotel,
open
Telemetry
and
then
back
to
the
Jaeger,
which
is
a
pretty
simple.
My
application,
pretty
simple
like
just
a
raspberry
API
I,
just
need
the
three
key
and
values
which
allows
me
to
use
open,
Telemetry
and
put
together
all
tracing
data
into
Diego
server.
B
Now
I'm
going
to
deploy
this
application
into
production,
which
is
equivalent
as
serverless
based
on
K
native,
because
sometimes
I,
don't
I,
don't
want
to
my
application
running
all
the
time
and
save
my
money
infrastructure
layer.
So
you
note
that
the
corkus
actually
provide
one
great
feature
here:
openshift
extension,
which
he
allows
me
scheme
a
lot
of
Step
manually.
So
once
my
let's
try
to
run
my
application
first,
so
I'm
going
to
start
my
local
runtime
and
then
just
to
view
my
application
and
then
behind
the
scene.
B
It
try
to
packaging
application
like
a
Java
art,
the
artifact
like
a
job
file
and
then
containerize
imagery,
and
then
then
try
to
push
that
image
into
like
a
container
registry.
In
this
case,
I'm
going
to
use
integrate
containeration
inside
the
kubernetes,
which
is
your
open
shift,
cluster
Reddit
and
then
finally,
it
will
deploy
to
K
network
service
on
top
of
the
kubernetes.
But
in
the
developer
standpoint
I
just
need
to
run
one
single
Command
right
and
the
other
stop
and
task
automatically
happening.
B
Excuse
me:
there
are
kubernetes
directory
and
confine
the
Evo
file
volcanic
services
and
then
kubernetes
and
not
push
to
stop,
and
then
it
once
it
deployed
and
then
when
I
go
to
my
open
ship,
the
cluster,
which
is
based
on
kubernetes,
so
I
already
installed
Jaeger
and
the
open
telemetry
using
our
operator.
So
when
you
click
on
the
web
UI,
this
is
not
local
anymore.
This
is
a
closed
Cloud
on
kubernetes
and
then
there's
no
Trace
at
this
moment.
B
So,
let's
give
some
moment
and
then
once
it
just
down
and
then
we're
gonna
just
invoke
the
rest
of
API
based
on
this
fully
defined
domain
name
and
then
and
then
we're
gonna
see
it
automatically
collect
alternate
data
from
our
open,
Telemetry
and
Jaeger
and
what
happened
in
there
I'm
going
to
Showcase
what
kind
of
combination
I
actually
set
it
up.
So,
for
example,
go
to.
Let
me
try
to
change
the
admin
cons
so
and
then
operator.
B
And
then
kind
of
serving-
and
here
is
the
K
Navy
serving
I-
already
created
the
CR
and
then
it
was
to
go
to
detail
yemo
file
and
then
I
already
set
it
up
I'm
going
to
make
it
bigger,
set
it
over
here,
the
backhand
or
GK,
which
is
actually
point
to
our
running
Jager
part.
And
then
this
is
the
keynap
serving
already
connected
to
my
backend
Jaeger
server
and
and
then
back
to
the
open
telemetry
by
the
namespace.
Here
it's
open,
Telemetry,
collector,
CR
and
then
go
to
here
hotel
in
the
yaml
file.
B
B
You
don't
need
to
worry
about
how
to
communicate
in
up
and
down
the
surprise
application
like
it's
an
Asian
based
because
the
summer
less
any
time
or
Panda
you
don't
know
when
actually
down
and
up
is
to
randomly
based
on
your
natural
traffic
and
let's
go
back
to
topology
bu
and
then
take
a
look
at
that
our
application
actually
scale
down
to
zero.
There's
no
part
anymore.
So
let's
go
back
to
my
local
environment
and
try
to
access
and
pulling
hello
and
greeting.
B
And
then
I
just
invoked
my
last
API
and
now
you
can
see
the
part
is
just
going
up
just
like
a
software
Lambda
like
an
Amazon
random,
just
like
a
serverless
behavior
and
in
the
meantime,
let's
go
to
Diego,
UI
and
I'm,
going
to
load
that
and
they,
when
you
load
the
Jaeger
UI
and
it
will
new
Services
pop
up
based
on
your
serverless
deployment
name.
So
here
is
our
serverless
name.
B
It's
already
detected
automatically
and
then,
when
you
created
to
find
traces
and
then
you
can
find
the
the
hello,
the
greeting
and
point,
if
you
want
to
invoke
several
more
time
and
then
you
combine
the
more
traces
here
and
you
can
also
call
different
or
the
last
API
and
reload
the
Jager
UI
and
you
can
find
a
new
operation
and
just
create
it
here
under
the
the
same
services.
And
then
when
you
go
down
on
your
sub,
rest
functions
go
down
and
it
just
go
up.
B
Based
on
the
new
network
trappy,
you
can
find
a
new
service
automatically
created
in
the
Jaeger
UI.
So
that's
the
pretty
easy
way
to
how
to
build
up
your
open
Telemetry,
as
well
as
the
serverless
application,
based
on
the
Java
running
on
your
Java,
Corpus
primo
and
then
I'm
going
to
use
the
backhand
the
Jaeger
server.
But
you
couldn't
have
added
more
like
a
polygonal
language,
long
time
like
maybe
the
lost
and
Python
and
whatever
you
know,
JavaScript,
but
always
the
challenge
for
developer,
to
figure
it
out.
Just
checks.
B
James
mentioned
the
audio,
so
SDK
API
and
then
what
kind
of
things
you
need
to
use
for
integrate
this
kind
of
stack
or
your
serverless
application
on
top
of
the
kubernetes?
Okay,
that's
all
I
have
today
James
and
I.
Here,
don't
want
my
like
a
YouTube
channel
yeah.
You
could
feel
free,
subscribe,
I
already
printed
the
similar
video
and
the
tutorial
and
a
bunch
of
stuff,
and
we
are
more
than
happy
to
address
question.
If
you
have
any
question
on
there,
there
we
go
yeah.
Can
you
pass.
C
C
A
Yeah
there's
so
there's
a
number
of
different
ways
to
do
it.
You
can
do
it
in
the
application.
Of
course,
if
you're
looking
at
like
a
health
Pro
from
kubernetes,
you
can
also
filter
those
out
through
the
open,
Telemetry
collector
configuration
yeah,
you
did,
you
probably
did
see
the
the
probe
service
there
in
the
trace
that
Daniel
showed
so
yeah.
A
You
can
filter
those
out
in
the
open,
Telemetry
collector
configuration
or,
if
you're,
using
something
like
service
mesh
like
you
can
also
eliminate
those
endpoints
from
being
emitted
as
a
Trace
remitted
as
part
of
a
Trace.
So
it's
a
number
of
different
configuration
layers.
You
can
eliminate
those.