►
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
Emitting, Consuming, and Presenting: The Event Lifecycle - Jesse Dearing, VMware
You’re building a suite of operators and processes that will run in your cluster to make your job easier. You’ve written CRDs to manage cluster and out of cluster resources, you’ve set up your monitoring with Prometheus, and set up horizontal pod autoscaling. How do you know what’s happening in your cluster? In this talk we’ll cover different ways to emit events related to cluster objects using Kubernetes events, using metrics to drive events, different techniques for consuming events, and ways for folks to create events without touching a command line. After attending this talk, you should be able to take advantage of events and metrics occurring inside the cluster and be able to produce your own events relevant to your cluster.
https://sched.co/UaY1
A
A
We
couldn't
have
a
cook
on
so
my
name
is
Jesse
Dearing
I'm,
a
site,
reliability,
engineer
at
VMware,
I
work
on
the
tansu,
Mission
Control
product
and
I
love,
working
with
systems,
infrastructure,
building
the
tools
to
manage
systems
and
infrastructure,
and
so
I
get
to
work
with
a
lot
of
kubernetes
at
VMware,
which
is
really
exciting.
I've
been
working
with
kubernetes
since
1.6.
That's
when
I
first
kind
of
got
it
installed
and
and
was
using
it
in
production,
I
actually
changed
jobs
and
they
were
telling
me.
A
Cool,
what
is
that
and
I
looked
into
it?
I
was
like
oh,
this
is
this.
Is
nice
because,
previous
to
that,
I
had
been
running
docker
in
production,
I
was
running
docker
and
production.
It
I
was
0.11,
so
I've
seen
some
stuff.
It's
it
was
rough
so
and
I
guess
you
could
say
I've
been
doing
cloud
native
before
we
even
started
calling
it
cloud
native.
A
So
events,
the
thing
that
inspired
me
to
put
this
talk
together
was
I,
was
working
on
an
operator
and
I
had
a
piece
of
information
that
I
needed
to
somehow
emit
who
out
of
like
the,
but
it
didn't
make
sense
to
use
a
Prometheus
metric.
It
wasn't
really
a
metric
that
I
had
and
I
could
omit
it
as
a
logline,
but
I
needed
to
come
back
and
look
it
up
later
and
having
to
grep
through
logs
didn't
seem
like
an
adequate
solution
either,
and
so,
as
I
was
looking
around
and
reading
the
documentation.
A
I
came
across
the
events
API
in
kubernetes
now
I
was
already
kind
of
on
board
with
it.
Just
you
know,
reading
the
first
few
sentences,
because
I
already
liked
the
idea
of
streaming
and
evented
sort
of
constructs
and
things
like
event,
sourcing,
architectures
and
stuff,
like
that.
That
stuff
has
been
really
interesting
to
me,
and
so
by
coincidence,
I
found
that
one
of
my
colleagues
who
also
works
at
VMware,
Michael
gash,
wrote
events.
A
The
DNA
of
kubernetes
and
I
I
was
really
kind
of
getting
on
board
with
this
idea
of
emitting
and
consuming
events
about
the
cluster
inside
the
cluster.
But
before
we
get
into
that,
I
just
want
to
do
a
quick
rundown
of
what
events
are
now
can
I
see
just
by
a
show
of
hands
how
many
people
have
used
events
in
kubernetes
before
okay,
good,
a
lot
of
you
I'm
going
to
go
ahead
and
just
do
a
quick
recap
of
what
events
are
and
kind
of
what
they
look
like
inside
the
cluster.
A
So
whenever
you
run
coop
Caudill
describe,
you
can
run
it
on
any
any
sort
of
resource
that
is
in
the
cluster.
So
in
the
example
here,
I've
run
it
against
a
pod,
a
contour
pod
and
just
for
reference.
Contour
is
it's
a
open
source
project
that
we
have,
that
uses
ingress
objects
to
in
talks
to
envoy
and
envoys
the
web
server,
and
so
it
updates
envoy
using
ingress
objects
from
the
cluster,
so
basically
a
web
server.
It's
like
the
hello
world
for
kubernetes,
but
I
mean
envoys
a
little
bit
more
complicated
than
that.
A
So
this
is
this
particular
event
is
an
unhealthy
event
because
of
readiness
probe
failure,
as
you
can
see
from
the
output
of
the
message
up
here,
it's
failing
because
of
an
HTTP
503
code,
which
just
basically
means
the
web
server
is
unavailable.
I
did
this
on
purpose,
just
to
try
to
get
it
to
emit
an
event,
but
this
is
coop
con.
We
don't
do
things
in
tables.
We
do
them
in
yamo.
So
here
here
are
is
what
an
event
looks
like
in
Y
amel.
A
So
we
all
know
the
API
version
and
the
kind,
so
it's
B
1
and
event
respectively,
but
I
wanted
to
call
out
that
events
have
counts,
and
so,
whatever
you
see
the
output
here
in
the
the
column,
you
know
the
spreadsheet
type
form
you
can
see
that
it's
got
60
seconds
as
the
age
of
this
nine
times
over
84
seconds.
Well,
so
the
count
there
is
nine.
A
You
can
see
the
first
and
the
first
time
stamp
and
then
the
last
time
stamp
at
the
bottom
and
that's
where
it
gets
the
first
time
that
it
was
emitted
and
then
the
last
time
that
it
was
seen-
and
you
can
see
here
in
the
middle
two-
there
is
the
involved
object
and
I'm
gonna
get
more
into
that
in
just
a
second.
But
one
of
the
things
that
I
do
like
about
this
involved
object
is
even
though
this
is
the
colony.
A
A
So
one
problem
with
UML
is
that
it
takes
two
slides
for
me
to
show
you
everything.
So
this
is
the
second
part
of
the
event
and
I've
grayed
out
the
stuff.
That's
not
really
important,
just
the
metadata
of
the
event,
but
it
every
event
has
a
message
and
the
message
gives
a
lot
of
context
as
to
what
the
event
was
emitted
for.
So
in
this
case,
this
is
the
you
know,
503
error
code.
A
The
next
field
that
I'm
gonna
call
out
is
called
reason.
This
is
more
of
a
type
with
events.
The
problem
is
there's
already
a
type
field,
but
a
reason
is
just
a
short
sort
of
type
of
this
event,
so
you
could
think
of
this.
As
a
the
reason
here
says
unhealthy.
This
is
an
unhealthy
event.
It's
the
I
think
they
already
use
type
4.
What
type
of
so,
let
me
jump
to
type
real,
quick
type.
You
can
either
be
normal
or
warning,
so
it's
either.
A
You
know
a
good
event
or
something
has
gone
bad,
which
again
you
know,
that's
I
would
think
it
would
be
normal
or
error.
But
you
know
names
are
hard,
so
I
want
to
talk
a
few,
a
little
bit
about
some
of
the
conventions
and
the
defaults
for
events.
So
if
you
do
list
the
events
in
your
namespace
you'll
notice
that
most
of
them
have
the
name
of
the
object
with
a
period
and
then
some
sort
of
unique
ID
or
hash
at
the
end.
I
actually
don't
know
how
they
get
that
in
kubernetes.
A
It
does
always,
and
my
clusters
seem
to
start
with
15.
Oh
I,
don't
know
why
that
is,
but
an
event
could
be
named.
Anything
that
you
want,
but
this
is
the
convention
for
it.
All
events
have
a
time
to
live
of
one
hour
at
least
that's
the
default
that
is
set
in
the
coop
API
server.
You
can
always
change
this
with
the
event
TTL
flag,
but
one
hour
is
the
default
for
events,
and
then
events
are
a
namespaced
object.
A
So
while
they
can
still
refer
to
objects
that
are
at
the
cluster
level
or
maybe
even
in
different
namespaces,
the
events
themselves
have
to
live
in
a
namespace,
though
the
question
is,
then:
what
can
we
do
with
these
events?
Now
that
we
know
what
they
are
and
what
they
look
like
well,
we
can
omit.
We
can
omit
our
own
events
and
so
to
do
that,
we
need
to
build
an
event,
object
and
use
the
kubernetes
api.
A
So
I
write
a
lot
of
go.
I
love
go,
but
it's
been
a
long
time
since
I've
touched
Python.
So
when
I
tried
to
work
and
write
something
for
this
talk,
I
decided
I
was
going
to
use
the
Python
kubernetes
client.
Another
reason
for
that
is
I
think
that
Python
also
presents
better
go
is
a
little
hard
to
follow.
You
kind
of
have
to
really
look
at
the
snippet
in
full.
We're
with
Python
I
feel
you
can
kind
of.
You
can
leave
some
stuff
out
and
people
can
still
get
the
gist.
A
So
for
the
following
code.
Examples
I
use
the
Python,
kubernetes
clients
and
I'm
just
using
Cu
IDs.
At
the
end,
those
are
just
collision-resistant
you
unique
IDs,
but
what
I'm
gonna
show
right
now
is
doing
a
lookup
of
a
deployment
in
a
namespace
and
then
we're
going
to
take
that
and
we're
going
to
emit
an
event
that
references
that
deployment.
A
A
Alright,
it
seems
I'm
losing
my
voice,
the
load
end
cluster
config
would
be.
If
you
were
going
to
run
this
inside
of
a
pod
with
a
service
account,
you
would
just
use
that
to
load
its
access
to
the
cluster,
so
the
next
thing
I'm
doing
is
I,
go
and
I'm
finding
the
deployment
UI
server,
which
in
this
case
is
just
engine
X
in
the
TMC
Dearing
J
namespace.
A
So
the
first
thing
I'm
going
to
do
after
that
is
I
want
to
record
the
time
that
I
saw
the
event.
So
that's
what
this
is
doing.
It's
important
to
note
that
you
need
to
always
include
the
timezone.
The
kubernetes
api
will
not
accept
it
if
it
doesn't
have
a
timezone
in
the
string
and
to
do
that
in
Python.
You
have
to
use
date/time
now
and
pass
in
the
timezone
and
UTC
is
just
a
good
timezone
to
pass
in,
because
most
of
servers
that
we
run
are
on
UTC
anyway,
so
everything's
in
UTC.
A
Just
to
avoid
confusion.
Ok,
so
the
last
part
of
this
sample
is
building
the
involved
object
and
all
we're
doing
is
we're
taking
what
we
got.
All
the
information
about
the
deployment
and
so
we're
setting
API
version
kind,
name,
namespace
and
I-
want
to
call
out
something
really
important
in
order
to
get
this
to
show
up
and
coop
control
describe,
you
have
to
include
the
UID
and
the
resource
ID
as
well.
A
So
now
we're
ready
to
go
ahead
and
build
our
event
object
to
put
it
into
the
cluster.
So
again,
I
said
my
involved
object.
Everything
that
we've
setup
previously
and
I
set
the
first
and
last
time
stamp
and
then,
finally,
with
the
metadata
I
set
the
name
of
the
deployment
UI
period
cui
D
namespace.
All
that
the
other
thing
that
you
can
do
that's
interesting
with
events
is
that
you
can
declare
the
source
now
a
lot
of
what
we
see
when
running
clusters
is.
A
We
see
events
that
are
emitted
by
cubelet,
mostly
like
the
last
one
that
we
were
looking
at
was
the
readiness
failure
and
that
was
emitted
by
cubelet
with
a
host,
but
the
source
can
have
any
component
name,
and
so,
in
this
case
I'm
just
going
to
put
in
CI
approver
and
it's
a
normal
event.
So
you
know
it's
not
a
not
an
event
that
is
concerning,
and
the
reason
is.
This
is
an
approval
event.
A
A
So
this
looks
like
whenever
we
run
our
get
events.
We
see
the
last
scene
time
again,
that
comes
from
the
first
time
stamp
or
the
first
same
timestamp
type
normal.
We
see
now
our
reason
that
we
set
and
we
can
see
it's
correctly
tied
to
the
deployment
UI
server,
and
then
we
see
the
message,
but
this
is
what
it
looks
like
now
in
the
context
of
describing
the
deployment.
A
So
usually,
when
you
run
describe
you
get
a
ton
of
very
useful
information
and
then
at
the
very
bottom,
under
the
events
section,
you
see
all
the
events
that
are
tied
to
that
particular
object.
In
this
case,
we
have
everything
that
you
saw
in
the
previous
slide,
except
for
the
from
field.
This
is
where
it
is
using
our
component
that
we
set
up
in
the
source,
all
right,
so
that's
it.
That
is
how
we
emit
events.
So
the
next
step
is
once
we
were
emitting
events.
We
need
to
be
consuming
them.
A
So
let's
look
at
a
one
made
in
a
few
lines
of
Python.
I
want
to
quickly
say
that
there's
a
lot
of
server
list,
type
of
applications
and
frameworks
and
and
tools
coming
out
that
let
you
like
a
native
is
a
good
example
that
let
you
write
functions,
you
know
just
like
you
would
in
sort
of
a
lambda
type
environment
and
that
function
gets
executed
for
each
event
that
gets
created.
So
you
may
or
may
not
need
to
do
this
most
of
the
time
like
this
is
going
to
be
pretty
simple
to
do.
A
Maybe
you
don't
need
K
native
right
now,
but
if
you're
using
K
native,
you
already
have
this
ability.
So
this
is
it.
This
is,
you
know
seven
lines
of
Python
and
all
we're
doing.
That's
is
we're
again
loading
our
cube,
config
and
then
we're
establishing
a
watch
on
the
namespace
resources,
the
events
in
the
namespace
and
so
each
time
an
event
comes
in
the
code
in
this,
for
loop
gets
executed
right
now,
I'm,
just
printing
out
the
event,
but
this
is
where
you
would
say
act
on
whatever
the
events
is
doing.
A
There
are
also
third
party
event:
consumers
that
can
help
you,
one
of
the
things
that
we
did.
I
I
came
to
VMware
from
hefty,
oh,
but
we
still
have
our
hefty
o
labs
out
there.
One
of
the
things
that
we
put
into
the
hep
co.labs
repos
and
the
deal
labs
github
organization
was
event
router
and
event.
Router
has
a
number
of
what
they
call
syncs,
which
are
just
basically
places
to
send
events.
A
The
default
is
standard
out
and
it
standard
out
because
it
assumes
that
you're
running
fluent
D
get
those
logs
slurped
up
into
whatever
you're
logging
solution.
Maybe
your
elk
stack
log
Lee
logs
II
Amy,
oh,
and
what
didn't?
We
have
a
ton
of
tools
for
logging.
It's
really
great,
but
this
lets
lets
you
do
that.
It
also
will
emit
events
into
s3
and
Kafka
and
even
it'll
make
an
HTTP
call
to
a
service
that
you
have
running.
A
A
A
There's
hep
do
labs
event.
Router
that
creates
Prometheus
metrics,
but
there's
also
Kyle
out
has
an
event
exporter
that
will
do
basically
the
same
thing,
and
once
we
pull
these
into
Prometheus,
we
can
do
things
like
you
know.
We
can
sum
on
these
events
kind
of
get
an
idea
of
counts.
We
can
look
at
events
over
time
and
a
time
series
graph
it.
It
becomes
a
way
that
we
can
now
sort
of
manage
some
of
these
things.
That
we
see
going
on
in
our
cluster
I
wanted
to
call
out.
A
But
as
it
stands
right
now,
we
also
have
monitoring
providers
that
help.
You
see
these
events
as
well.
So
if
you're
running
on
Google
cloud
stack
driver
is
already
showing
you,
these
events,
data
dog,
the
data
dog
agent-
pulls
these
in
as
well
or,
if
you
know,
if
you
set
up
event
router,
you
can
pull
these
in
with
fluent
D.
These
are
just
the
three
where
I've
seen
it
and
I've
used
it.
A
This
is
by
no
means
an
exhaustive
list,
so
there's
quite
a
few
more
out
there,
but
the
types
of
events
and
I'm
not
going
to
go
into
this
too
much
because
I
feel,
like
the
the
other
talk
I,
think,
will
better
explain
the
type
of
events
in
the
cluster
that
you
can
look
for
and
monitor.
But
the
types
of
events
that
you
can
see
in
a
cluster
are
liveness
and
readiness
probes,
as
we've
already
seen
back
off
events.
A
So
whenever
you
see
those
pods
and
crash
loop
back
off,
if
you
check
the
events
you
can
always
see,
you
know
why
it
ended
up
in
crash
loop
back
off
job
creation
and
completion
for
your
cron
jobs
or
your.
You
know,
doc,
kubernetes
jobs,
and
then
you
can
see
scheduling,
problems
or
maybe
not
even
problems,
just
what's
happening
with
the
scheduler.
So
this
is
a
way
where
you
can
find
things
like.
Do
you
have
enough
capacity
in
your
cluster
or
when
it
tried
to
schedule
that
pod?
Did
it
fail
to
schedule?
A
So
the
kind
of
use
case
that
I
was
thinking
of
that
I've
put
into
the
code
that
I'm
going
to
share
at
the
end
was
an
automated
deployment
for
environments
that
need
approvals.
Maybe
you
have
an
environment
that
requires
like
every
manager
has
to
approve.
You
know
it's!
It's
typical
for
a
lot
of
compliance,
things
that
you
need
to
maybe
have
someone
else
approve
a
deployment
or
maybe
you
have
to
have.
A
Make
sure
that
if
we
don't
have
that
approval
that
we
will
not
allow
the
new
pods
to
come
online,
so
I'm
gonna
take
some
excerpts
from
the
webhook,
but
basically,
what
it's
doing
is
it's
when
you
establish
it
and
you
configure
it
using
the
admission.
The
omission
webhook
object
is
it's
going
to
listen
for
operations
on
replica
set
resources.
A
A
If
this
is,
if
this
event
exists,
then
we
return
to
true
and
will
allow
the
replica
set
to
be
created,
otherwise
we'll
return
false,
which
should
deny
the
replica
set
from
being
created,
and
this
is
what
that
response
looks
like
it's
a
simple
bit
of
JSON
that
we
send
back
where
we
say
in
our
emission
review.
Is
it
allowed
or
not?
And
if
it's
not
allowed,
we
set
a
status
to
say:
okay,
the
code
is
403
using
the
HTTP
forbidden
code
and
the
messages
your
deployment
needs
to
be
approved.
A
So
let's
see
this
in
action
when
we
try
to
edit
our
deployment
to
change
the
image
or
something
this
is
what
you'll
see
it
gets
emitted
as
an
event,
so
again,
Turtles
all
the
way
down,
because
you
know
you
got
an
event
now
that's
getting
admitted,
and
so,
but
you
can
see
that
it
was
denied
the
request
to
create
the
replica
said.
This
is
the
deployment
itself,
so
the
deployment
was
changed.
A
Kubernetes
said:
okay,
I'm
gonna
make
a
call
to
the
api
to
go,
create
a
new
replica
set,
but
then
it
got
to
nine
because
we
didn't
find
that
and
we
denied
it
in
our
admission
controller.
So
in
this
case
I
would
go,
I
would
get
the
I
would
run
the
intend
test,
it
would
pass
and
then
I
would
generate
that
approval
event
and
then
I
would
try
to
deploy
again,
which
case
you
see
now.
A
The
first
event
that
I
have
is
the
approval
event
and
then
I
can
get
the
deployment
goes
ahead
and
creates
the
replica
set
scales
down
the
old
one
other
use
cases.
I,
think
that
we
can
think
of
using
events
for
is
relating
any
sort
of
external
state
to
kubernetes
objects.
The
one
thing
and
this
doesn't
exist,
but
I
would
love
to
see.
It
is
if
you
have
some
sort
of
pain
test
like
similar
to
what
you
get
with
say,
like
Pingdom,
where,
whenever
it
fails,
it
creates
an
event
on
your
ingress
objects.
A
Maybe
you're
pinging
certain
URLs
that
you
know
go
to
certain
services,
wouldn't
it
be
cool
to
put
an
event
on
those
ingress
objects
to
help
you
debug
a
little
bit
faster,
so
you
can
say:
okay,
pink
gums.
Failing
for
this
one
particular
area
of
our
application,
let's
look
a
look
at
the
ingress
object,
okay
and
we
can
see
what
service
its
related
to
and
assuming
that
its
liveness
checks
and
readiness
checks
are
passing.
A
You
maybe
have
deployed
a
bug,
and
you
know
faster
to
rollback
and
again
the
use
case
that
started
this
all
for
me
was
logging
operator
changes
to
cluster
objects.
So,
if
you
are
writing
your
own
operators,
logging,
these
things
you're
already
creating
kubernetes
objects
with
your
operator,
using
events
to
be
able
to
log.
Maybe
if
it's
changing,
if
it's
pulled
a
certain
image
down
or
if
it
you
know,
has
updated,
you
know
some
sort
of
configuration
being
able
to
log.
A
So
in
conclusion,
in
summation
events,
they
are
deleted
after
an
hour.
They
don't
stick
around
very
long.
Every
event
can't
exist
without
some
sort
of
involved
events
as
it's
called,
but
it
has
to
refer
to
some
other
events
or,
as
sorry,
some
other
object,
and
to
get
them
to
show
up
and
described.
You
have
to
be
very
careful
about
making
sure
that
you
relates
all
of
the
pieces,
including
UID
and
resource
version,
and
events
themselves
are
very
easy
to
consume
in
both
client
go
and
the
kubernetes
Python
client
using
watches
and
then.
A
A
And
on,
like
I,
said
I
wanted
to
post
here.
If
you
have
any
questions,
you
want
to
hit
me
up
on
Twitter
I
blog,
maybe
once
a
year
at
Jesse,
dev
like
I
need
to
get
back
into
it,
but
then
I
said
that
last
year,
and
here
we
are
again
and
then
the
source
for
this
is
all
up
on
github.
So
thank
you
om
and
if
you
have
any
questions,
the
mic
is
going
around
I.
C
Thank
you
for
a
great
introduction
to
events.
So
whenever
I
upgrade
my
kubernetes
cluster
to
next
version,
I
see
if
some
new
events
related
to
a
pod
like
it
was
initially,
it
was
three
or
four
of
them
like
continually
need
and
stuff
like
that,
and
I
knew
all
of
them,
and
now
they're
like
20
of
them,
or
something
like
that,
so
they
keep
adding
various
events.
Is
there
is
centralized
event
catalog
or
as
like
a
state
machine
driving
where
everyone
is
where
I
can
see?
C
A
Best
that
you
can
do
with
that
is
maybe
I
know
that
if
you
just
try
to
say
look
at
the
events
across
all
of
your
namespaces,
you
maybe
don't
get
the
full
context
for
what's
happening,
and
so
a
lot
of
times.
What
I
found
is
the
event
will
kind
of
set
me
in
the
right
direction.
Like
maybe
it'll
say
a
pod
was
terminated.
You
know,
because
of
you
know
something
it's
not
very
specific
as
to
what,
but
if
I
could
find
that
pod
I
could
go
and
I
could
describe
the
pod
and
look
and
see.
A
A
D
Just
see
like
so
I'm
part
of
the
VDP
team,
so
we
have
a
developer
platform
part
of
CPS
view.
So
we
have
a
use
case
where
we
have
a
similar
tool
event
which
creates
JIRA
tickets
in
an
air-gap
environment,
from
the
alerts
which
are
coming
in
from
prometheus
alert
manager
or
any
other
source
like
wavefront
as
well.
So
just
one
thing
I
want
to
ask
if
we
have
multiple
tenants
on
the
same
cluster
and
we
are
kind
of
creating
a
config
map,
reloader
like
tenants
have
access
to
their
namespaces,
they
can
upload
their
conflict.
D
Configs
here
I
would
mean
like
JIRA
credentials
and
the
queue
names
like
if
I
want
tenant
a
alerts
to
be
routed
to
that
specific
endpoint,
then
it'll
be
alert,
so
we
rather
do
a
different
endpoint
as
per
the
configs
that
they
are
adding.
So
is
that
capability
also
there
in
the
event
router
as
of
now
or
I,
think.
A
A
Think
what
you
could
probably
do
this
you
could
centralize.
The
events
in
some
sort
of
a
particular
namespace
doesn't
have
to
have
anything
else
other
than
just
the
events
that
you
care
about,
and
so
you
could
log
those
events
into
that
namespace
and
reference
events
from
others
like
I
think
that's,
probably
probably
the
best
that
you
could
do.
Does
that?
Does
that
answer
your
question?
A
D
So
you're
saying
that
we
can
kind
of
create
a
new
name
space
where
we
can
add
logs,
but
the
question
that
I
wanted
to
ask
was
so
we
can
put
the
logs
in
one
namespace
or
events
that
come
in.
But
if
you
have
to
write
some
events
on
to
a
different
endpoint
router,
some
even
show
different
endpoints
and
some
to
another
endpoint.
So
can
we
do
that?
Like?
Do
we
have
that
capability?
As
of
now
on
this.
A
E
B
Yeah
I
just
had
a
quick
question
about
the
usage
of
reason
versus
like
the
type
is
there
any
guidelines
or
ideas
on
what
to
put
there
cuz
like
one,
you
had
approval
and
another
one
you
just
like
had
like
replica
set
arrow
or
something
like
that.
Like
yeah,
that's
have
you
seen
any
patterns
in
that
yeah.
A
So
just
keeping
it
short
also,
so
you
can
kind
of
look
at
it
at
a
glance,
and
you
know
the
coop
cut
a
list
and
describing
things
and
then
also
making
sure
that
it
really
kind
of
describes
what
the
event
is
like.
What's
kind
of,
basically,
what
reason
is
kind
of
a
good
name,
because
it's?
Why
does
the
event
have
their
like?
What's
the
reason
for
the
event
to
exist?
So
if
it's
the
case
of
a
failure
for
a
readiness
check,
you
know
it's
a
the
readiness
failure
or
whatever,
whatever
it's
called,
and
thanks.
F
A
Yeah,
that's
a
good
question,
because
I
I
just
recently
started
hearing
about
all
of
what's
happening
with
cloud
events,
and
so
cloud
events
are
meant
to
be
external
to
the
cluster.
It's
all
sort
of
a
part
of
this.
You
know
a
venting
and
streaming
sort
of
infrastructure
that
we
can
build.
So
you
can
have
your
producers
and
consumers.
A
Events
are
meant
to
live
inside
of
a
kubernetes
cluster
and
reference
kubernetes
objects
where
cloud
events
could
be
more
seen
as
a
general
purpose
API
for
sending
events
to
other
consumers,
so
kind
of
you
could
think
of
it
as
like,
using
Kafka
or
Nats
to
be
able
to
send
kind
of
general-purpose
data.
At
least
that's
what
I
understand
from
cloud
events:
hey.
G
A
Yes,
you
could
you
could
I
was
just
using
the
Python
example
as
a
as
what's
going
on
hide
in
the
scenes.
So
really
that's
what
event
router
is
doing.
Is
it's
establishing
a
watcher
on
events
and
then,
when
it
receives
them,
its
routing
it
to
whatever
sinks
you
have
configured
and
so
yeah
you're
right
like
it
it's
you
could
set
it
up,
there's
a
number
of
different
ways
that
you
can
handle
events
you
could
use
the
HTTP
call
to
have
it
talk
to
you
know
your
own
application.
A
You
could
set
up
an
admission
controller
that
always
returns
true
that
listens
for
events,
the
creation
of
events,
so
you
get
this
sort
of
like
are
editing
of
events
you
could
have
it
make
a
web
hook
call
from
the
kubernetes
api
there's.
Obviously,
a
lot
of
there's
a
lot
of
potential
for
like
drawbacks
to
consider
with
all
these
different
approaches,
but
yeah,
there's,
there's
many
different
ways
to.
H
Hey
Jesse,
thank
you
for
you.
Talk
just
wanted
to
ask.
Yes,
all
the
example
or
Kennedy
talked
about
two
sets
of
examples
of
using
events.
One
of
them,
you
know,
they're,
going
to
sinks
and
something
happens
usually
kind
of
a
almost
a
log
type
recording
of
it.
The
other
example
that
you
had
was
again
like
they
work.
H
A
A
triggering
processes
from
certain
events
that
get
created
exactly
yeah
yeah.
No,
that
that
sounds
like
a
really
cool
use
case.
You
could,
you
could
kind
of
think
of
that
being
used
for
something
like
a
you
know,
Auto
remedial,
auto
remediation
type
task.
So
you
know,
if
you're
not
able
to
capture
some
of
this
stuff
with
a
liveness
check
that
kills
a
pod.
Maybe
you
know
you
there's
some
sort
of
event
that
you
admit
that
you
want
to
kick
off,
something
that
you
know
I.
Maybe
it's
a
known,
problematic
query
against
her
database.
A
You
could
omit
an
event
that
would
then
kick
off
a
job
that
goes
and
finds
those
queries
and
stops
them
or
or
something
of
that
nature.
So,
although
that
does
kind
of
that,
I
think
is
a
more
is
a
good
use
case
for,
like
a
general
purpose,
type
of
events,
but
you
know
you
could
think
of
something
similar
inside
of
the
cluster.
A
I
Hey
Jesse
so
emitting
events
does
it
have
any
impact
on
the
performance
of
the
cluster
I
attended,
a
talk
in
which
Ober
shared
that
migration
strategy
and
they
were
trying
to
create
a
cluster
with
I
think
more
than
five
thousand
nodes
with
like
forty
thousand
power
and
just
the
pod
creation
events
were
causing
a
lot
of
delays
in
parts
coming
up
because
it
was
overloading
the
cluster.
So
I
just
wanted
to
know
your
thoughts
about
it
impacting
performance.
Yes,.
A
Events,
if,
if
you
use
too
many
events,
they
can
potentially
impact
performance.
This
was
a
problem,
particularly
back
in
the
sc2
td2
protocol,
so
it
would
a
lot
of
times
the
scaling
solution
was
to
separate
out
your
events
into
a
separate
like
in
events
at
CD,
but
since
they've
made,
since
that's
maybe
the
upgrade
from
2
to
3,
it's
improved
a
lot.
It's
a
the
API
is
a
lot
faster.
A
It's
a
lot
more
terse
instead
because
it
before
it
was
all
HTTP
and
I
think
I
think
it's
all
gr
PC,
but
it
it
improved
the
scalability
of
events
and
and
the
performance
of
them
when
they
did
that.
But
it
is
still
a
performance
consideration.
So
you
don't
want
to
go
too
crazy,
omitting
events,
because,
yes,
it
could
potentially
cause
things
to
back
up.
Okay,.
E
A
No,
that
is
a
good
question,
and
it
is.
It
is
something
that,
if
anyone
anyone
who's
ridden,
an
operator
has
had
to
consider
or
at
least
understand
how
the
framework
deals
with
that,
because,
yes,
you
know
events
and
have
and
be
repeated.
You
know
there
there's
certain
things
that
do
there
are
like
trying
to
keep
it
unique,
like
the
name
unique.
A
So
if
you
were,
if
you're,
storing
the
state
of
the
events
and
you're
hashing,
instead
of
doing
what
I
was
doing
in
my
example,
which
is
just
like
a
random
collision-resistant,
ID
fear
hashing
based
off
something
that
should
hopefully
prevent
you
from
creating
multiple
events
but
yeah.
It's
still
just
as
any
distributed
system,
a
real
possibility
that
you
could
have
something
that
executes
based
on
receiving
the
event
more
than
once,
I.
E
A
You're
still
messing
if,
if
you're
still
using
things
related
to
objects
in
your
cluster,
I
think
it
still
makes
sense
to
use
an
event
but
yeah
you're
right.
Maybe
there's
one
of
the
tricks
that
I've
seen
used
here
is
adding
a
if
you're
modifying,
say
another
object.
Putting
it
was
in
I
think
Airbnb
stock.
They
were
looking
at
an
observed
generation.
So
when
they're
script
was
going
to
do
something
or
there,
their
programs
would
do
something.
They
wouldn't
note
the
generation
that
they
last
observed
and
compare
that
to
the
automatically
generated
like
monotonic
counter.