►
From YouTube: Optimize Kubernetes on vSphere with Event-Driven Automation - Steven Wong & Michael Gasch, VMware
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Optimize Kubernetes on vSphere with Event-Driven Automation - Steven Wong & Michael Gasch, VMware
Kubernetes abstracts out differences across hosting infrastructure, but there are cases when integrated monitoring across the layers of storage, compute, etc, are essential. When faults or reconfiguration happen, manual monitoring, diagnosis and remediation can be slow, costly, and error prone. The VMware Event Broker Appliance is an open-source project, usable with Cloud Events and Knative to optimize availability, auditing, compliance, etc. based on vSphere events. We'll cover popular use cases and how to get started. The K8s VMware User Group shares best practices for hosting K8s on VMware infrastructure, and we will close the session with details on how you can participate in the group.
A
Okay,
we're
going
to
get
started,
hi
welcome
to
the
kubecon
2022
event
in
valencia,
I'm
steve
wong
and
I'm
joined
by
michael
gash,
you're
about
to
learn
about
some
cool
new
tech
that
lets
you
enable
better
integration
of
kubernetes
workloads
with
vsphere,
and
this
is
brought
to
you
by
the
vmware
user
group
a
word
about
this
user
group,
we're
inclusive
of
all
users
running
all
kubernetes
on
vmware
infrastructure.
So
I
don't
want
you
to
be
mistaken.
A
Thinking,
thinking
that,
since
the
two
of
us
happen
to
be
with
vmware
that
we're
only
talking
vmware,
kubernetes
distributions,
if
you're
running
red
hat,
open
shift
or
rancher
or
whatever
what
we're
going
to
talk
about
here
still
applies.
This
is
completely
generic.
It
should
work
with
any
compliant
kubernetes
running
on
the
vsphere
hypervisor
and
this
group
itself,
if
you
elect
to
join
the
community,
all
the
stuff
we
cover
is
like
that.
A
A
A
So
these
abstraction
layers
can
simplify
the
job
of
the
components
above
them,
but
they
do
need
to
make
some
choices
as
to
how
to
support
what
runs
on
top
in
relation
to
the
layers
that
are
below
vsphere
is
designed
to
allow
vms
to
opt
in
to
a
high
availability
model
that
rigorously
attempts
to
defend
workloads
from
going
down.
The
kubernetes
model
is
more
tuned
to
an
expectation
that
a
workload
has
an
architecture
that
allows
for
individual
components
and
individual
containers
to
go
down
while
still
maintaining
an
acceptable
level
of
service.
A
There
are
classes
of
applications
better
suited
to
the
vsphere
model,
others
better
suited
to
the
kubernetes
model
and
if
you're
running
an
on-prem
installation
you
likely
have
both
operating
and
they
might
need
to
interoperate
a
lot
of
on-prem
installations
host
legacy.
Vm-Based
services,
which
interact
with
the
kubernetes
workloads,
the
kubernetes
zone,
abstraction
mapping
to
cloud
fault
domains,
is
pretty
comparable
across
all
the
public
clouds,
but
vsphere
and
thus
kubernetes
running
on
vsphere
is
actually
a
lot
less
opinionated.
A
It
has
a
lot
configuration
options
that
leave
it
to
the
user
to
implement
failure,
domains
based
on
budget
constraints,
resource
constraints
other
and
you.
It
is
possible
to
configure
your
vsphere
installation
so
that
the
storage,
compute
and
network
service
fault
domains
may
not
be
aligned
with
each
other,
and
there
are
ways
to
take
this
into
account
with
kubernetes
best
practices
etc.
A
B
A
B
B
Okay,
so
while
this
is
adjusting
who
runs
vsphere
good
you're
in
the
right
room,
who
runs
kubernetes
on
vsphere
or
plans
to
okay,
perfect
awesome,
nice
nice,
who
runs,
let
me
advance
a
bit
k
native
eventing
sort
of
on
vsphere
yeah.
I
know
I
know
cool
okay,
very
good,
so
the
session
is
set
up
in
a
way
that,
hopefully,
everyone
can
take
something
out
of
this,
like
even
if
you've
never
heard
about
the
appliance.
B
B
So
what
is
event
driven
architecture?
So,
in
this
talk
we
talk
a
lot
about
events,
asynchronous
operations,
event-driven
whatever,
and
so
we
looked
at
wikipedia
as
kind
of
the
source
of
truth
for
event,
driven
architecture
if
you've
never
heard
about
that
before
so
event,
driven
architecture
is
a
software
architecture
paradigm,
it's
not
new
at
all,
like
it's
been
around
for
like
decades,
promoting
the
production,
protection,
consumption
and
reaction
to
events,
and
the
most
important
part
here
is
the
reaction.
You
do
something
right,
yes,
something
happens
and
you
react
to
it.
So
what
is
an
event?
B
An
event
is
an
immutable
fact.
It's
kind
of
an
information,
it's
different
from
a
message
or
a
command
in
in
the
case
that
an
event
is
something
that
you
cannot
change
it
is
there
you
get
a
notification
for
that.
Also.
The
center
of
the
event,
for
example,
vsphere
and
vcenter
as
we'll
see
in
a
bit,
is
not
aware
of
the
recipients
potential
recipients
of
that
event,
there's
no
expectation
if
I
send
an
event
out
there
that
I
know
who's
listening
and
reacting
to
that.
B
That
kind
of
kind
of
no
coupling
between
that
and
since
those
facts
are
immutable,
you
cannot
rely
on
this
information.
There's
a
difference
between
saying
I
want
to
power
on
a
vm
versus
the
fact
that
the
vm
was
powered
on,
because
the
first
is
a
command,
meaning
it
can
fail.
It
can
can
fail
for
various
reasons.
You
don't
have
host
resources,
you
don't
have
the
permissions
for
that,
so
commands
in
general
can
fail
and
you
need
to
account
for
that
versus.
If
you
receive
an
event
that
the
vm
was
powered
on.
B
You
can
be
sure
that
this
has
happened.
It's
a
fact
from
the
past
right.
It's
something
that
has
happened
or
in
in
a
nutshell.
Just
think
about,
like
is
if
this
then
that
if
you
know
that
cloud
service
ifttt,
that's
basically
the
whole
idea
that,
if
something
happens,
you
do
something
with
it,
and
so
did
you
know
that
vsphere
or
vmware
vcenter
and
again
we're
talking
very
much
around
vsphere
today.
But
events
in
general
are
also
very
useful.
So
a
lot
of
events
produce
events.
B
I'm
sorry,
a
lot
of
products
and
services
produce
events,
but
vsphere
happens
to
be
the
core
one
that
our
administrators
and
and
core
personas
happen
to
use
a
lot.
So
did
you
know
that
vsphere
and
vcenter
alone,
in
a
standard
setup,
so
no
plugins,
no
extensions
installed,
comes
with
already
1800
plus
events.
Did
you
know
that,
like
I
didn't
know
that
you
did,
I
know
so,
which
is
which
is
great,
because
if,
if
we
could
only
send
you
three
events,
that's
probably
not
going
to
be
useful.
B
1800
is
a
lot
starting
from
like
these
power
on
power
off
events,
trs
related
events,
because
drs
is
a
little
bit
different
when
it
comes
to
these
operations.
Configuration
events,
login
events,
backup
events,
you
name
it.
This
list
is
huge.
My
colleague,
william
lam,
he
has
a
github
page
where
he
tracks
all
these
different
events
that
are
available
for
like
for
use
in
different
vsphere
and
vcenter
versions,
and
the
beauty
of
this
is
that
you
can
do
something
with
them
right
now.
B
What
are
some
use
cases
for
event,
driven
systems
in
general,
how
they
are
applied
and
then
specific
to
the
context
of
a
vsphere
environment
and
a
kubernetes
environment?
First
of
all,
the
most
like
commonly
used
is
notification.
I
want
to
get
a
notification
when
a
vm
is
deleted
or
powered
on
in
slack
now.
The
challenge
with
vsphere
and
vcenter
is
that
it
doesn't
give
you
this
integration,
there's
no
slack
integration,
even
if
there
would
be
you
would
come
and
say.
Can
you
give
me
slack
integration?
B
Well,
so
we
would
have
to
I'm
sorry
a
teams,
integration.
We
would
have
to
build
teams
integration.
Can
you
give
me
discord
integration?
Well,
we
would
have
to
you
know
the
pattern
right.
So
what
we're
trying
to
do
here
is
to
not
have
vcenter
become
a
thing
where
we
have
to
attach
all
these
like
notification,
things
and
say:
look
these
sensors
just
sending
the
event.
There's
then
some
magic
and
then
we'll
send
it
somewhere
to
select
pagerduty
or
whatever
the
other
one
is
automation
and
scott.
B
B
Right
and
so
automation
is
a
key
one,
because
notification
is
nice,
but
what
you
also
can
do
with
these
events,
or
this
information
is
to
reset
the
vm,
for
example,
or
to
re-power
it
on
or
to
put
it
in
a
dns
database
or
in
cmdb,
or
do
something
with
the
fact
that
that
you
received
another
one.
Is
integration
big
one
in
the
cloud
provider?
So
we
have
vmware
cloud
on
aws.
B
We
have
vmware
on
google,
we
have
vmware
on
azure
and
on
service
providers,
and
we
see
right
now
a
lot
of
integra
interest
in
these
use
cases.
Where
you
have
vsphere
events,
you
might
have
some
events
in
aws
and
you
want
to
send
them
and
aggregate
them
and
correlate
them,
maybe
together,
and
so
we
also
have
some
aws
folks
there,
which
use
dv
sensor
events
and
do
do
automation
in
aws
remediation.
I
already
spoke
about
that.
B
That's
an
important
one,
so
we
have
common
use
cases,
you
have
vsphere
and
you
have
nsxt,
which
is
our
network
stack
and
both
happen
to
be
like
kind
of
their
own
islands.
But
if
you
want
to
make
sure
that
a
virtual
machine
is
secured
on
the
network,
then
you
need
to
have
kind
of
the
settings
and
the
awareness
of
both
of
these
control
planes,
knowing
about
each
other
and
so
with
event,
driven
systems
and
automation.
Here
we
can
send
this
information
to
another
control
plane
like
nsxt
and
say
look.
This
is
a
vm.
B
B
B
Especially,
if
you
don't
have
a
software
engineering
background,
and
so
what
we
wanted
to
do
is
to
make
it
easy
for
anyone,
even
without
coding
or
software
development
background,
to
leverage
these
events,
and
so
we
built
the
vmware
event
broker
appliance,
which
started
as
a
very
much
vcenter
vsphere
centric
appliance
that
you
can
download
open
source.
It's
a
it's
a
fling.
I
don't
know
if
you
can
read
it,
but
there's
a
there's,
a
link
down
there
as
well,
but
you
can
also
use
the
individual
components
to
this
runs
kubernetes.
B
B
And
one
of
the
core
feedback
was
also
it's
nice
to
have
vsphere
events,
but
vmware
alone
has
a
lot
of
more
products
like
horizon
and
the
vdi
space,
nsxt
and
so
on,
and
if
you
expand
it
further
in
the
cloud,
you
will
also
see
systems
that
generate
events.
So
the
goal
here
is
to
be,
like
you
know,
like
an
aggregator
like
a
router.
If
you
will
that
connects
to
different
event,
sources
from
of
different
kind
and
then
sends
these
somewhere
and
whether
that's
the
slack
integration
or
that's
another
kafka
or
aws.
B
What
have
you?
That's?
That's
the
goal
there
and
we
heavily
rely-
and
this
is
a
shout
out
to
the
k
native
and
the
cloud
events
community,
because
most
of
the
time
we
want
you
to
run
little
code
or
little
actions
to
react
to
it,
and
so
a
common
pattern.
There
is
to
use
functions
like
an
aws
lambda
or
with
k
native,
where
you
just
write
the
middle
minimal
enough
amount
of
code
to
do
something
with
the
event.
So
you
don't
have
to
connect
to
vcenter.
B
You
don't
have
to
be
aware
of
vcenter
where,
like
whatever
you
do,
and
we
use
the
standard
for
these
events,
which
is
called
the
cloud
events,
because
if
you
have
different
sources,
sending
events,
these
events
don't
look
like
each
other.
They
have
different
schemas
and
shapes
and
payloads,
etc.
So
we
use
the
the
cncf
cloud
event
standard
to
put
a
common
shape
around
it,
so
that
for
the
code
for
the
function
that
you
write,
you
know
there
are
always
these
kind
of
fields
like
a
type,
a
subject:
a
timestamp,
a
source
etc.
For
that.
B
So
he
can
tell
you
more
about
that
which
is
mind-blowing
what
they
did
with
weaver,
and
this
is
also
a
learning
that
william
I
and
the
viper
community
had
is.
When
we
put
this
out,
we
had
common
use
cases
like
slack
integration,
but
then
users
were
adopting
it
in
a
way
that
we
didn't,
even
like
think
about
when
when
we
released
viva
okay.
So
let's
talk
about
use
cases
now
that
we
have
kind
of
the
baseline
of
what
we
does.
B
So
I
have
two
scenarios
here
and
two
demos
of
how
we
think
viba
can
help
and
they
are
mostly
driven
actually
by
by
community
and
customer
requests.
So
steve
spoke
in
his
introduction.
He
spoke
about
the
concept
of
fault
domains,
zones
that
you
might
know
from
cloud
providers
like
aws
es123,
for
example,
but
also
vsphere
has
a
concept
of
zones
or
awareness
or
affinity.
If
you
will,
if
you're
aware
with
drs,
so
what
we
typically
see
in
larger
environments
or
more
resilient
deployments
is
that
we
have
a
host
a
cluster,
a
rack.
B
Vsphere
drs
resource
management
101,
and
this
is
all
fine
and
we
use
it
now.
Kubernetes
itself
has
the
same
concept,
but
at
a
different
layer,
because
the
kubernetes
scheduler
is
also
aware
of
zones
and
affinity
and
or
distribution
of
workloads
in
this
case
parts
not
virtual
machines,
but
parts,
and
so
if
you
do
things
right
between
those
two
layers
in
this
case
here,
then
you
will
have
a
direct
mapping
between
a
part,
a
workload
that
runs
on
a
kubernetes
worker,
which
maps
to
a
virtual
machine
which
maps
to
the
same
site.
B
If
you
will
or
zone
this
is
all
good,
especially
for
developers
when
they
say.
Oh,
I
want
to
run
my
stateful
workload
and
I
want
to
distribute
it.
It's
really
important
to
have
this
mapping,
because
it
could
easily
happen
that
the
virtual
machine
actually
runs
somewhere
else.
So
it's
important
to
arbitrate.
This
stack-
and
this
is
also
like
common
practice-
nothing
new
here.
B
The
trouble
begins
if
you
have
drs
or
vsphere
starting
to
migrate
those
virtual
machines,
the
vsphere
has
the
concept
of
vmotion
live
migration,
where
we
can
non-disruptively
move
workloads
between
different
domains
or
like
hosts
or
clusters.
This
is
good
for
maintenance
availability
concerns
right,
so
there's
a
lot
of
benefit
in
there
now.
The
problem
is
that,
because
this
happens
at
the
vsphere
layer,
kubernetes
is
not
aware
of
this.
B
Kubernetes
does
not
update
its
knowledge
of
the
worker
that
actually
now
it's
running
on
zone
b
and
even
if
it
would
be
it
would
have
actually
to
take
the
part
off
that
worker
and
put
it
somewhere
else.
In
this
case,
it
couldn't
even
put
it
somewhere
else,
because
the
zone
there's
no
virtual
machine
there.
B
But
even
in
the
case
of
just
the
normal
vm
migration
from
a
host
to
another
host,
sometimes
business
application
teams
say:
oh,
there
was
a
latency
and
my
app
was
slow
and
I
think
it's
the
emotion
that
you
guys
do
down
there
and
then
the
vi
admin
needs
to
look
in
the
logs.
It's
like
okay.
No,
there
was
no
emotion,
I
disliked
timestamp.
B
B
This
is
good
and
bad
because
for
the
others
in
the
room,
you
might
not
even
be
aware
of
this
problem
or
how
to
mitigate
it
right.
So
let
me
show
you
how
this
this
would
work
with
biba.
So
I
think
no
I'm
good.
So
I
have
a
on
my
laptop.
I
have
a
setup
of
a
kubernetes
environment.
V-Bar
runs
locally
there,
but
I
have
a
remote.
B
I
have
a
remote
environment
in
palo
alto,
where
my
whole
vcenter
environment
is
for
this
demo
and
all
the
like
the
code
and
the
tutorial.
I
we
have
a.
We
have
a
github
page
it's.
This
is
a.
This
is
also
in
the
appendix
of
the
presentation.
So
you
have
all
the
links
there
if
you
want
to
follow
along.
So
what
I'm
going
to
show
you
now
is
the
first
scenario
of
detecting
and
sending
something
to
slack
so
here's
my
slack
instance.
B
You
see
it's
currently
empty
and
now
I'm
going
to
go
to
my
vsphere
environment,
and
I
was
told
that
it's
hard
to
read
in
the
back.
So
I'm
going
to
explain
what's
going
on
here
so
here
on
the
left
and
let
me
try
to
increase
a
little
bit
on
the
left.
We
have
a
cluster
of
four
hosts.
Vsphere
hosts
one
is
already
in
maintenance
mode,
because
that
helps
me
to
enforce
to
show
what
I
want
to
show
here
and
the
three
other
ones
are
like
vsphere
hosts,
and
then
I
have
two
virtual
machines.
B
Those
are
here
those
those
two
and
one
of
the
virtual
machine
is
pinned
to
the
upper
set
of
host
or,
like
has
a
drs
rule
to
say
you
should
run
on
this
host
group
and
the
lower
one
is
running
on
the
on
the
on
these
other
two
hosts,
and
this
is
a
should
rule,
it's
a
soft
rule,
meaning
it
can
be
violated.
For
example,
if
I'm
doing
maintenance,
then
the
upper
one
would
also
migrate
down
there.
B
So
idly
they
are
distributed,
but
sometimes,
if
you
lose
the
one
rack,
if
you
want
then
quick
question
any
question
or
no
okay
am
I
good
still
audible
cool,
but
ideally
you
also
want
to
have
like
a
failover
or
like
a
pre-active
failover
to
the
other
group.
So
what
I'm
going
to
do
now
is
to
enforce
this,
but
I
first
need
to
deploy
the
code
and
what
I'm
doing
here
is.
B
B
Let
me
just
quickly
run
the
command
here,
so
it
sets.
It
creates
a
a
function,
that's
the
first
one
and
then
it
creates
two
triggers
which
is
basically
just
the
way
hey
if
this
happens
called
the
call
the
function-
and
this
is
all
k
native
based.
So
we
had
a
couple
of
canadian
talks
at
at
kubecon
here,
so
I'm
not
going
to
cover
the
canadian
bits,
because
that
is
also
out
of
scope.
B
What
is
more
important
is
the
code.
You
get
an
event,
you
look
at
the
event.
You
do
something
you
don't
need
to
know
about
canadia,
if
you
don't
need
to
know
about
vsphere
at
all
like
this
could
also
be
used
by
business
applications
and
developers,
because
they
don't
need
even
access
to
vcenter.
So
you
don't
need
to
give
them
accounts
you.
They
don't
have
scripts,
calling
your
vcenter
taking
them
down,
network
policies
etc,
basically
shielding
them
from
all
the
stuff
and
just
telling
them
when
something
has
happened.
B
So
it
looks
like
this
is
all
deployed
now
and
what
I'm
going
to
do
is
I
have
a
little
thingy
here.
This
is
the
sockeye
application
which
gives
me
the
stream
of
events
was
built
by
some
of
the
cool
canada
founders,
and
it
will
basically
show
all
the
events
that
are
going
on
right
now.
There's
no
traffic
in
my
environment,
so
we
don't
see
anything,
and
I
just
hope
that
this
virtual
machine-
yes,
I
need
to
authenticate
just
a
second
of
course,
demo.
B
B
B
I
call
this
the
kubernetes
control
plane,
because,
typically
you
would
distribute
these
kind
of
control
planes
of
kubernetes
on
different
hosts
in
vsphere,
and
currently
it
runs
on
host
51,
which
is
that
guy
and
that
guy
I'm
going
to
put
in
maintenance
mode
now
enter
maintenance
mode
and
what
it
does.
It
basically
tells
me:
hey,
there's
already,
there's
still
a
virtual
machine
on
that
host,
I'm
going
to
migrate
that
virtual
machine
of
this
host
onto
another
group,
because
I
forced
the
other
one
also
to
be
maintenance
mode.
B
There's
only
two
hosts
left
which
are
on
the
other
group
right
and
now,
because
I'm
running
non-compliant
right.
The
worker
is
now
in
a
not
preferred
zone.
If
you
will
from
a
kubernetes
perspective
now,
I
actually
should
be
alerted,
and
so
you,
you
saw
there's
a
lot
of
events
you
see
like
when
the
host
enters
maintenance
mode,
etc.
So
there
are
also
some
good
events
that
you
will
also
get
out
of
this,
and
everything
worked,
and
this
is
not
a
screenshot
see
I
can
scroll
here,
you
get.
B
The
preferred
zone
for
the
vm
is
eu1
and
the
host
where
it's
currently
running
is
eu2,
and
so
now
someone
can
at
least
like
take
a
look
or
extend
the
function
right,
there's
also
a
little
bit
of
info
in
there
and
the
template
code
of
the
function.
Where
it
says
hey,
you
can
actually
try
to
revert
it
back
like
remediate
right,
but
for
the
simplicity
of
the
demo.
I
just
kept
it
simple.
I
just
sent
a
slack
notification
here,
so
that
was
the
first
one.
B
Let's
jump
back,
wizarding
was
still
good
on
time,
so
this
is
very
typically
like
sending
to
slack
or
teams
or
pagerduty
or
whatever.
Now
the
next
one
is
a
little
bit
more
advanced,
because
I
wanted
to
show
some
advanced
concepts.
I
think
we
have
10
minutes
left
right,
yep
cool
I'll,
get
there.
So
if
you're
not
familiar
with
vsphere
alarms
and
again,
this
is
hard
to
read.
B
Basically,
you
can
set
alarms
in
in
your
vsphere
environment
that,
for
example,
if
a
data
store
gets
full
or
cluster
is
too
utilized
or
you
have
lost
network
connection
or
bandwidth,
etc.
You
can
set
up
alarms
and
thresholds
and
all
the
stuff-
and
these
are
great
because
they
help
administrators
and
teams
to
observe
the
system.
The
trouble
with
alarms
and
vsphere
is
that
there's
just
a
limited
number
of
integrations
that
they
have
so
you
can
send
an
email.
You
can
send
an
snmp
trap
or
you
can
run
a
script
on
the
on
the
control
plane.
B
Now
an
email
is
probably
fine.
Snmp
traps
was
fine
20
years
ago,
but
maybe
not
this
day
anymore
and
running.
A
script
is
also
not
good
because
you
might
be
in
control
of
the
of
the
control
plane,
but
what
if
someone
else
wants
to
run
a
script?
Well
now
you're,
basically
using
arbitrary
code
running
it
on
your
vcenter
appliance,
which
is
not
a
good
idea,
also
from
a
security
perspective.
B
Next
one
is
still
you
need
someone
to
have
access
to
vcenter,
which
we
want
to
get
f
off
from
right.
Why
would
we
give
everyone
vcenter
access
just
for
configuring
and
extending
alarms
next
one,
if,
if
you
are
starting
to
write
like
external
scripts,
whatever
you
have
this
issue
with
polling
like
they
need
to
call
for
hey,
has
this
alarm
change?
Has
it
changed
and
does
the
trouble
with
pulling
if
you're
too,
pulling
too
frequent,
then
this
is
obviously
troublesome
for
vcenter
if
you're
pulling
too
slow?
B
Well,
then
you
might
miss
the
alarm
or
you
react
too
late
right
and
again
it's
coupling.
You
need
to
know
the
apis,
the
vcenter
apis
for
that
which
you
might
know,
but
not
everyone
like
in
different
teams.
Also,
and
now
you
might
be
smart,
okay.
Well,
I
heard
michael
talking
about
event
driven.
I
know
I
can
do
something
with
these
alarms.
Let
me
build
my
own
custom
integration.
B
Let
me
build
my
python,
my
power
cli,
whatever
this
works,
but
the
problem
with
the
alarm
event
that
you
get
it's
it's
very
generic
and
it
misses
a
lot
of
data.
So
what
we've
done
with
some
of
the
viber
examples
is
we?
We
use
some
k
native
concepts
here,
which
are
basically
the
runtime
that
we
use
to
do
some
a
bit
a
bit
more
magic
on
the
events.
So
vcenter
sends
us
an
alarm
event
say:
oh
host
memory
usage
is
way
too
high.
You
need
to
do
something.
B
Well,
then
viva
obviously
gets
it,
and
then
we
transform
it
into
a
cloud
event.
So
this
is
all
the
like:
the
boilerplate
internals
that
you
don't
need
to
care
about,
but
now
for
the
example,
what
we
do
is
we
use
something
called
a
sequence
in
vibra
or
in
canadia.
If
you
will,
which
gives
you
steps,
you
can
say,
call
this
one
first
and
that
that
function
or
and
that
one
and
that
one
so
what
we
want
to
do
here
is
we
have
a
a
service,
not
a
function,
a
service
which
receives
that
event.
B
B
It
caches
these
details
because
we
don't
want
to
always
go
back
to
vcenter
and
do
all
these
calls,
because
you
could
have
a
lot
of
alarm
events
right
and
then
it
produces
a
new
event
like
an
enriched
alarm
event,
if
you
will,
with
all
the
details
of
the
alarm
like
the
name,
the
triggers
the
the
criticality
like
how
it's
set
up
and
all
the
stuff,
and
it
sends
it
downstream
to
another
set
of
parallel
receivers
and
in
this
case
parallel.
Why?
Parallel?
B
Because
we
want
to
send
it
to
a
dashboard,
in
this
case
my
sockeye
event
viewer,
which
you
will
see,
but
we
also
want
to
send
it
to
slack.
So
the
beauty
of
this
is
that
one
event
can
expand
into
multiple,
like
receivers
or
endpoints.
If
you
will-
and
you
can
do
this
in
parallel
or
you
can
have
like
these
steps
before-
where
you
intercept
and
inject
and
even
create
your
own
new
events,
which
a
lot
of
viva
users,
they
use
the
vsphere
alarms.
But
when
we
tell
them
look,
you
can
even
create
your
own
events.
B
B
B
So
I'm
going
to
deploy
a
function,
this
one
just
one
cube
ctl
command,
but
I
need
to
go
into
a
specific
folder
here
for
for
that
code,
and
I
hope
I
did
that
right,
yeah,
okay,
so
what
it
did
here.
It
created
a
function
for
sending
to
slack
and
then
has
a
couple
of
triggers
and
sequences
and
parallels
that
the
stuff
that
you
saw
before
to
wire
wire.
This
dissolve
up,
and
I
think
this
is
there's
a
dispatcher
or
it's
way
too
big
too.
Oh
yeah
trigger
here.
B
B
So
this
is
my
alarm
here
and
it's
like
host
memory
above
five
percent.
Obviously
I
set
it
low
to
trigger
it
right,
so
I'm
gonna
enable
it
now
because
it
was
disabled
so
that
you
know
I
can
show
the
example
and
after
some
time
you
will
see
some
of
these
hoes
getting
flagged
as
alarms
because
it
takes
vcenter
a
while
to
figure
out
or
the
utilization
and
alarm.
I
think
30
seconds
here
by
default,
so
that
takes
a
bit.
B
B
It
has
some
boilerplate
blah
blah
blah
blah
blah,
but
it
misses
important
information
which
we
then
with
the
pipeline,
that
you
saw
interject
into
the
event,
and
so
we
patch
it
in
and
now
once
it's
patched
in
with
all
the
more
detailed
information
it's
hard
to
read.
But
again
it's
more
detailed
information
for
the
alarm.
Now
we
send
it
to
our
select
function
so
that
our
slack
function-
and
it's
already
doing
stuff
here-
can
can
print
us
a
nice
hey.
B
This
is
an
alarm
and
the
ala,
the
type
was
an
error,
and
you
know
the
object
was
a
host.
This
is
a
select
symbol,
not
recognized
here,
and
we
also
have
the
threshold
without
patching
that
event,
we
wouldn't
be
able
to
send
this
create
the
slack
message,
because
all
this
information
is
missing.
This
is
not
available
in
the
original
event.
That's
why
we're
doing
this
patching
on
the
chain
of
events
there,
and
this
is
all
possible.
So
I
always
joke
it's
like
the
elastic
sky.
B
Is
the
limit
elastic
sky
used
to
be
the
first
name
of
esxi?
So
when
you
start
thinking
about
these
events
and
integrations
and
possibilities
that
you
have
there,
literally,
your
own
imagination
is
the
limit
there.
So
I'm
gonna
pause
here
that
was
the
last
demo
that
I
had
and
steve's
gonna
wrap
it
up.
A
There
this
session
is
hosted
by
the
kubernetes
vmware
users
group,
and,
if
you
like
these
kinds
of
con,
this
kind
of
content,
we
are
having
meetings
every
month
on
zoom
and
we
also
have
a
slack
channel
where
you
don't
have
to
wait
to
the
next
meeting
if
you've
got
questions
or
things
you
want
to
share.
The
whole
point
of
this
is
to
allow
users
to
ask
questions,
share
best
practices,
experiences
and
interact
even
with
developers
who
are
working
on
this.
So
where
do
you
find
this?
Well,
it's
it's
online.
A
A
A
But
if
you
want
to
give
us
homework
to
try
to
recruit
a
speaker
on
a
topic,
this
agenda
document
is
open
to
users
and
you're
free
to
just
go
in
there
and
edit
the
agenda
for
next
month.
Just
please
put
your
name
a
topic
you'd
like
to
discuss
or
have
discussed
an
estimated
number
of
minutes
and
we'll
try
to
make
it
happen
and
here's
the
slack
channel
it
isn't
on
this
screen.
A
A
Also,
both
of
these
groups
publish
the
meetings
up
on
youtube.
Sometimes
they
don't
come
out
the
day
after,
but
they
come
out
eventually.
So
you
can
go.
Look
at
the
historical
meetings.
If
that
interests
you
so,
unfortunately
I
guess
the
qr
code
over
wrote
the
link.
Sorry
about
that,
but
the
link,
that's
the
link
to
the
deck,
that's
the
kubernetes
channel
that
will
find
you,
michael
and
now
I
think
we're
ready
for
q
a
if
there
aren't
any
I'd.
A
Ask
that
raise
your
hand
and
we'll
bring
you
a
microphone
so
that
the
people
online
or
watching
the
recording
can
hear
any
questions
you
have
and
if
you'd
rather
have
your
questions
one-on-one,
I
think
we
can
hang
around
a
little
bit
out
in
the
hall
and
we've
also,
I
noticed
in
the
audience
in
terms
of
user
group
members
and
actual
people
with
vib
experience.
I
see
a
number
of
them
in
the
audience
too.
So
go
ahead.
If
you've
got
any
questions
raise
your
hand,
please.
A
Actually,
I
have
a
more
of
a
question
about
the
scalability,
so
actually,
when
you
actually
really
start
acting
on
a
larger
environment,
let's
say
with
a
couple
of
thousand
virtual
machines:
we
really
have
a
lot
of
alerts
triggered.
Is
there
some
kind
of
a
sizing
guide,
or
is
it
some
kind
of
way
you
also
see
analytics?
Maybe
some
of
the
functions
take
very
long
time
so
when
they
are
triggered
over
and
over
that
they
actually
start
to
stack
up.
B
So
we
for
vib,
we
don't
publish
sizing
guidelines
because
we're
also
a
little
bit
doubling
right
now
in
terms
of
deployments.
We
often
we
also
don't
hear
back
from
the
users
because
it
just
works,
so
we
have
a
little
bit
of
telemetry
in
the
system
of
how
many
events
per
second
we
have
throughput,
because
we
see
that
the
good
thing
with
the
viva
appliance
is
that
it's
a
one-to-one
model,
meaning
it
connects
to
one
vcenter
and
then
it
has
like
one
processing
engine
behind
that.
B
Obviously
that
doesn't
scale
if
from
a
management
perspective,
but
it
helps
with
like
the
scaling
from
a
vcenter
to
the
actual
execution
and
for
viba
itself.
Couple
hundred
events
triggering
per
second
is
not
a
big
deal
like
we've
seen
that,
but
if
you're
thinking
like
thousands,
then
the
appliance
itself
becomes
an
easy
bottleneck,
also
from
an
availability
perspective
and
we
recommend
doing
the
distribution
model
on
kubernetes.
B
So
question
is:
what's
the
security
role
model
for
like
viba,
and
I
think
this
is
like
almost
two
questions.
One
is
for
connecting
to
the
sources,
but
there's
a
security
implication
and
the
other
one
is
with
the
data
inside
these
events
right
personal
information,
for
example.
So
on
the
one
hand
the
good
thing
is
viba
is
we
only
require
read
only
access,
so
it's
not
a
write
account
that
you
need
for,
in
this
case
vcenter
as
one
particular
source,
and
you
can
even
scope
it
down
to
say
just
the
host
just
the
clusters.
B
It
literally
just
sees
then,
whatever
this
object,
resource
and
hierarchy
sends
over
for
the
pii
personal
information
kind
of
case.
We
don't
rip
strip
them
off
right
now,
meaning
you
would
have
to
write
an
additional
function
like
a
blinder
or
an
extractor
like
in
the
alarm
example
that
I
gave
you
we
injected.
In
this
case
you
would
write
a
function
or
an
interceptor.
B
That
does
this
because
we
initially
started
thinking
about
enriching
v
by
itself
with
this
kind
of
functionality,
but
we
saw
ourselves
as
becoming
like
a
bottleneck
of
these
features,
and
so
we
kind
of
deferred
it
to
like
the
examples
that
you
saw
like
the
sequence
and
then
doing
the
other
stuff
for
person
like
admin,
admin
usernames,
for
example,
passwords
are
not
in
there
right.
We
don't
send
passwords,
but
host
names.
Usernames
log
in
this
could
be
personal
information.
Yes,.
A
I
think
another
thing
that
I've
heard
in
one
of
your
community
meetings
that
william
lamb
pointed
out
with
regard
to
the
auditing
use
cases.
Many
times,
auditors
want
to
have
information
about
specific
workloads,
but
it
might
be
a
violation
to
give
them
everything,
yes
and
kind
of
the
legacy
way
of
doing
that
would
be
open-ended
where
they
get
free
access
to
more
information
that
they
would
need,
or
maybe,
depending
on
the
rules
that
apply
to
you,
should
be
able
to
see
and
through
filtering.
A
B
You
see
multi-staged,
like
you,
take
the
event,
and
then
you
process
it
in
a
way
that
it's
secure
has
the
information
that
you
want,
and
then
you
give
it
for
consumption
that
that's
also
possible
right
depend
and
the
latency
by
the
way
some
people
ask
like
how
fast
is
it.
This
is
like
sub.
Second,
like
it's
almost
real
time.
B
A
B
So,
what's
the
question,
the
question
was
around
seeing
multiple
events
for
the
same
operation
that
was
performed
correct.
Yes,
so
yes
or
no,
you
saw
like
the
whole
thing
scrolling
like
crazy,
and
the
reason
is
not
that
you
get
like
10
times
the
same
event.
But
you
see
this
staged
like
vm
created,
vm
being
created,
vm
like
deployed
right,
there's,
always
a
pipeline
of
events
that
we
send
the
ships
and
that's
only
for
one
kind
of
operation.
B
B
Yes,
and
no
so
because
the
functions
in
the
default
model
the
functions
themselves,
they
are
stateless,
meaning
you
send
them
something
they
do
something,
and
then
they
turn
down
or
they
forget
right.
So
they
don't
know
that
there
was
a
sequence
or
that
they
should
wait
or
there's
like
this
means,
like
you
would
go
into
stateful
processing
right.
This
is
a
little
bit
more
stateful
where
you
retain
state,
and
in
that
case
the
solution
typically
would
be
to
put
it
in
a
like
a
database
or
a
log
or
a
kafka.
A
Like
I
say,
join,
join
the
community
meetings
too.
If
this
topic
interests
you,
I
suspect
we
put
on
other
topics
that
will
be
of
interest
too
well.
One
last
word:
I
want
to
point
out.
There
has
been
a
proposal
in
the
cncf.
This
group
is
operating
under
the
kubernetes
project
and
there's
a
proposal
to
move
it
out
of
the
kubernetes
project
and
start
hosting
user
groups
under
the
cncf.
One
reason
is
that,
in
reality,
frequent
topics
that
come
up
in
this
group
are
essentially,
how
do
you
run
kubernetes
on-prem,
as
opposed
to
vsphere.
A
They
encompass
other
cncf
projects
like
load,
balancers
and
other
things.
That
technically
are
not
kubernetes,
but
they
are
cncf
projects.
So
it's
entirely
possible
that
by
the
end
of
the
year,
this
group
might
have
a
slightly
different
identity.
Where
you
find
it,
I
don't
think
it's
going
away,
because
you
know
there's
a
community
of
people
who
found
value
in
it
and
show
up,
but
that
proposal
is
on
the
table
to
change
the
way
user
groups
are
done.
I
suspect
the
earliest
it
would
happen
would
be
at
kubecon
north
america
in
october.