►
From YouTube: Kubernetes UG VMware 20210506
Description
May 6 2021 meeting of the Kubernetes VMware User Group. Presentation on the VMware Event Broker Appliance (VEBA) by Michael Gasch and William Lam follwed by a demo by Scott Rosenberg.
VEBA can be deployed on Kubernetes using a Helm chart or as a VM appliance. use cases include: notification, to slack, text message, etc; automation - example apply a tag as something is deployed, can be event driven by Knative; integration - use public cloud services of your choice triggered by vSphere events/data; remediation - example react to a host down event; audit - example pick out events like a failed logon
A
A
Michael
and
william,
have
been
working
on
an
appliance
that
publishes
event
streams
related
to
what's
going
on
in
the
vsphere
infrastructure
and
can
be
really
useful
when
you're
running
kubernetes
workloads.
Frankly,
it's
useful
even
for
other
types
of
you
know,
legacy
vm
workloads
as
well
with
that
said,
I'll
turn.
It
over
to
michael
and
william
and
pick
who,
which
of
you,
goes
first.
B
B
B
Yeah,
it
was,
but
I
see
a
couple
of
family
names,
so
that's
good
and
I
think
you
and
miles
you're,
probably
wonderful
hosts
for
for
these
people.
I'm
actually
surprised
to
see
that
many
people
in
one
of
the
user
groups
here.
So
that's
that's
great.
So
I'm
I'm
michael.
I
I'm
based
out
of
germany.
I
work
for
the.
B
B
B
Okay,
weird
might
have
just
been
a
shot,
but
so
what
I
wanted
to
say
is
that
I'm
based
out
of
germany
working
for
vmware
and
office
of
the
cto
as
an
engineer
there-
and
I
have
a
pleasure
of
like
to
work
on
innovative
technologies
and
prototypes
like
the
vibe
lights.
But
before
that
before
I
continue,
I
want
to
quickly
let
volumetric
solve.
D
B
Good
thanks,
so
let
me
know
if
audio
is
good.
Interrupt
me
if
I'm
breaking
up
again
so
quick
agenda
for
today
and
I'm
excited
to
have
actually
scott
on
the
call
as
well.
He
he
like
sent
us
over
his
demos
that
he
wanted
to
share
later.
So
I'm
really
excited
about
that,
because
it
couldn't
be
better
to
have
like
an
actual
user
demoing
of
of
the
viva
appliance.
So
we'll
start
with
a
simple
example,
so
we'll
basically
throw
you
right
in
into
one
of
the
use
cases
that
we
want
to
that.
B
We
are
tackling.
We
do
a
quick
demo
and
then
I'm
handing
it
over
to
william
he's
going
to
give
you
a
little
bit
more
detail
on
the
about
the
appliance
itself.
A
couple
of
demos
as
well
have
a
quick,
wrap-up
and
then
headed
over
to
scott.
If
there's
questions
just
drop
them
in
we,
we
can
answer
them
as
we
go
right.
So
we
usually
start
with
this
slide.
B
That's
kind
of
our
canonical
example
of
a
simple
example
that
most
of
you
probably
have
seen,
especially
when
you
work
with
the
vmware
platform
and
to
be
fair.
Viva
itself
is
not
really
like
specific
to
vmware
technology.
It
just
happens
to
have
like
a
connector,
for
example,
to
vcenter,
and
so
typically
viva
users
have
backing
of
e-center
appliance
environments,
but
not
necessarily.
This
is
a
requirement
and
william
we'll
talk
about
that
as
well.
B
But
I
thought
for
this
audience
today,
we'll
make
it
about
the
different
example,
which
is
vp
motion,
vm,
migrated
kind
of
use
cases,
especially
because
you
might
have
environments
where
you
stretch
kubernetes
environments
across
fault,
domains
or
zones,
and
in
vsphere
we
have
the
concept
of
fault
domains
using
the
arrest
rules,
for
example
in
host
groups,
affinity
groups,
but
they
can
be
soft
and
hard.
And
if
you
have
a
soft
rule,
it
is
not
guaranteed
that
ibm
kind
of
stays
in
that
group
of
hosts
or
rack
or.
B
However,
you
have
defined
this
and
we
have
seen
customers
facing
challenges
with
actually
detecting
that
vms
are
kind
of
displaced,
not
working
on
the
preferred
host
group
and
then
second,
even
after
detecting
this,
it's
kind
of
a
little
bit
too
tedious
to
move
the
vms
back
manually
and
having
someone
watching
and
observing
this.
So
this
is
the
use
case
that
we
want
to
go
through
and
with
the
common
approach,
like
we
call
the
imperative
style.
Think
of
you
write
a
script
to
fix
that.
There's
a
couple
of
steps
involved
here.
B
If
this
happens,
if
this
event
happens
in
the
infrastructure,
I
want
to
get
notified
to
this,
and
I
want
to
have
my
slack
event
handler
or
function
called
here,
and
this
might
be
a
little
bit
hard
to
read
because
there's
a
lot
of
information.
But
this
is
the
event
payload
that
a
vm
migrated
event
contains
and
you'll
see
like
the
sources.
B
The
destination
knows
a
lot
of
information
that
is
relevant
to
then
immediately
verify
whether
this
vm
is
part
of
the
right
host
group
or
running
on
the
right
host
here,
but
notice
that
it's
it's
not
just
shorter,
there's
actually
no
notion
of
vcenter
here,
so
that
your
user,
which
might
not
actually
be
via
admin,
could
even
be
like
a
different
organizational
unit
or
a
different
vu
in
your
enterprise.
They
don't
really
have
to
know
about
vcenter
at
all
here
they
don't
have
to
know
about
secret,
like
security
roles
etc,
and
how
to
connect
to
vcenter.
B
B
So
this
is
actually
the
kind
of
key
selling
point
quote
quote
that
viva
is
pretty
popular,
for
it
is
like
reducing
a
lot
of
boilerplate
code
noise
that
you
would
otherwise
have
to
write,
and
it
also
abstracts
a
lot
of
the
complexities
around
resource
efficiency,
security,
availability,
etc.
So
that
literally,
you
just
write
your
logic.
Whatever
you
want
to
do,
there.
A
A
B
So
here
you
see
my
configuration
file,
which
is
just
a
overwrite
file
for
him.
So
if
you're
not
familiar
with
home,
helm
is
like
a
templating
language
and
deployment
tool
where
a
lot
of
deployment
steps
for
kubernetes
applications
are
abstracted
for
you
and
if
you're,
if
the
defaults,
don't
work
for
you
or
you
have
to
customize
them,
there's
an
override
file,
which
is
a
yaml
file,
and
you
just
specify
some
of
the
properties
here.
In
this
case,
we
are
saying
we
want
a
debug
output
for
vr
when
it
runs.
B
This
is
the
vcenter
that
I
want
to
connect
to
and
I'm
using
insecure
ssl
connection,
because
it's
a
self
science
certificate,
then
I'm
saying
oh,
I
actually
want
to
run
this
against
the
canadian
environment.
So
we
in
my
kubernetes
setup
here
I
run
k
native,
which
is
a
serverless
eventing
platform,
and
then
I
give
it
a
couple
of
details
around
k
native
in
my
environment.
It's
basically
just
telling
that
here
is
a
message
broker
so
viva.
B
Whenever
you
get
an
event
from
vcenter,
send
it
to
that
broker
and
from
there
functions
or
other
services
can
can
pick
it
up.
That's
all.
I
need
to
enter
basically
here
in
order
to
kick
me
off
and
there's
a
quick
command.
You
should
see
here
on
the
left,
how
to
install
this
via
helm
and
we
just
say,
help
install
in
the
vmware
namespace
called
vivac
native,
and
then
we
give
it
the
event
router,
which
is
the
head
chart
in
this
case
and
my
overwrite
file
and
then
here
on
the
right.
B
Let
me
just
zoom
it
out
a
little
bit
because
I
assume
too
much
in
a
second.
You
will
see
ebay
actually
coming
up
and
here's
the
logging
trace
that
I'm
running,
so
the
container
is
being
created
right
now
the
lock
kicks
off,
so
it
actually
looks
pretty
good
and
let
me
quickly
jump
into
a
live
environment.
So
this
is
my
vcenter
here
and
I
have
an
app
installed
called
sockeye
and
sockeye
gives
you
the
event,
output
in
a
human,
readable
format.
B
D
Okay.
So
this
is
a
project
that
michael
and
myself
started,
probably
in
early
2018,
and
took
a
look
at
this
project
and
our
first
release
came
out
in
2019.
This
project
is
completely
open
source
and
we
really
wanted
to
rethink
about
how
customers
can
do
event
driven
automation
using
vcenter
events.
Event
driven
is
not
a
new
concept
by
any
means.
D
You
know
the
product
itself
is
probably
two
decades
old
now
in
terms
of
our
management
platform,
and
customers
have
been
doing
this
many
many
years,
but
it
hasn't
been
the
most
easiest
thing
to
do,
and
let
me
talk
a
little
bit
about
why
that
is
today.
When
you
look
at
vcenter
server
out
of
the
box,
it
ships
about
1800,
plus
events.
These
are
different
things
like
events
and
alarms
that
really
represent
state
changes
in
our
system.
So,
for
example,
a
virtual
machine
gets
created,
a
host
gets
added.
D
Maybe
a
vm
gets
migrated
right,
and
these
are
just
out
of
the
box
events.
Now,
if
you
deploy
additional
second
and
third
party
solutions,
they
have
the
ability
to
actually
augment
those
events
and
add
additional
functionality
and
make
the
system
even
more
richer
for
you
right
so
for
most
customers.
It's
probably
several
thousand
events
that
you
can
basically
consume
from
and
out
of
the
box.
Vcenter
allows
you
to
perform
these
things
called
actions
so
for
given
events,
it
has
the
ability
today
to
send
an
email,
probably
not
the
most
friendly
thing.
D
It's
limited
in
terms
of
the
types
of
emails
it
can
send,
and
most
of
us
are
probably
generally
backed
up
on
email
right.
So
probably
not
that
useful,
but
it's
there.
You
also
have
the
ability
to
send
an
snmp
trap.
This
might
be
useful
for
maybe
monitoring
purposes,
so
specific
events
that
are
related
to
monitoring
and
troubleshooting.
D
That
might
be
useful,
but
again
snmp
is
probably
not
the
thing
that
most
people
are
deriving
automation,
tasks
from
and
can
get
tricky
to
kind
of
consume,
and
then
the
last
one
is
around
being
able
to
run
a
command.
You
might
say
that
this
is
quite
interesting,
but
in
reality
this
is
actually
the
most
restrictive
for
a
number
of
reasons
right.
This
command
is
actually
running
a
piece
of
code
that
runs
on
your
vcenter
server
appliance
and
for
any
one
of
you
that
manage
a
v4
based
environment.
D
That's
a
big
no-no
right
for
a
number
of
reasons,
a
you're,
exposing
a
piece
of
script
that
could
have
a
vulnerability
in
it.
Maybe
if
it's
not
written
correctly,
you
might
actually
be
taking
resources
away
from
your
vcenter
server
and
ultimately
you're
limited
by
the
types
of
scripts
you
can
run.
You
know,
generally,
it's
probably
going
to
be
a
basic
shell
script.
You're
not
going
to
be
able
to
use
the
language
of
your
choice,
I'm
really
not
ideal
and
we
took
a
step
back.
D
You
know
this
is
the
type
of
automation,
that's
available
out
of
the
box
and
b
center,
and
it
hasn't
really
changed
for
the
past
two
decades
and
we
really
wanted
to
take
a
look
at
this
and
say
you
know:
could
we
modernize
this
and
make
this
easier
to
consume?
So
michael
and
I
start
to
kind
of
think
about
some
of
the
challenges
that
we've
seen
as
well
as
talking
a
lot
of
customers
over
the
years.
D
I
wanted
to
drive
into
some
of
the
use
cases
that
we
see.
You
know,
first
and
foremost,
notifications
being
able
to
inform
when
something
happens
right.
It
could
be
something
as
simple
as
slack
microsoft
teams.
Maybe
you
want
to
receive
a
a
text
message
right.
Wouldn't
it
be
awesome
if
vcenter
can
actually
send
you
a
text
message?
You
just
can't
do
that
today,
but
notification
is
a
very
common
popular
use
case
right
next,
we
look
at
things
like
automation
and
integration
right.
D
This
is
now
you
being
able
to
write
a
piece
of
code
in
scripts
right
that
might
make
change
to
the
to
your
infrastructure.
For
example,
maybe
a
vm
gets
powered
on.
You
want
to
automatically
apply
a
particular
vsphere
tag
based
on
where
the
vm
should
be
deployed
to
maybe
you
might
want
to
integrate
with
internal
I.t
services
that
you
have
within
your
organization.
D
Remediation
is
another
big
use
case
for
our
audience,
especially
around
sre
and
operations.
Right
now
that
you
can
react
to
these
events,
a
host
goes
down
instead
of
paging
something
in
the
middle
of
night.
Maybe
it
can
automatically
provision
an
additional
host.
If
you
have
that
automation
capability,
maybe
it's
actually
setting
up
a
pager
duty
or
service
servicenow
ticket
right
or
maybe
adding
additional
storage
depending
on
the
type
of
use
case.
So,
instead
of
having
somebody
to
do
something
manually,
you
can
actually
write
that
automation
and
react
and
automatically
release
some
of
those
scenarios.
D
So
we
have
customers
doing
that
as
well.
The
last
one
is
around
audit
analytics.
This
is
actually
quite
interesting.
You
know
we
have
a
number
of
customers
that
have
been
trying
to
do
this
and-
and
it
is
really
difficult
to
do-
you
know,
prior
to
using
something
like
viva
right,
where
you
want
to
be
able
to
selectively
pick
out
certain
events
that
you
care
about.
Classic
example
is
around
the
security
and
audit
auditing
compliance
teams,
where
you
want
to
maybe
pick
out
specific
events
like
a
failed
login,
for
example.
D
That's
the
event
that
vcenter
publishes
today
and
actually
gives
you
the
source
ip
of
where
that
failed,
login
attempts
right,
so
you
might
want
to
over
time,
monitor
your
infrastructure
and
see
it.
Are
you
having
any
particular
attacks
and
using
something
like
viva?
You
can
actually
selectively
pick
these
types
of
events.
Maybe
vms
get
deleted
so
destructive
operations.
Maybe
you
have
teams
that
want
to
analyze
the
types
of
operations
that
you're
performing
in
your
visual
infrastructure
to
gain
additional
analytics
details
or
maybe
optimizations
right.
So
lots
of
really
interesting
use
cases
around
audit
and
analytics.
D
D
For
example,
you
know
being
able
to
select
an
event
that
happens
right
and
say
I
want
this
event
like
vm
gets
deleted,
and
then
I
want
to
be
able
to
focus
in
just
writing
just
enough
code
to
deliver
that
functionality
and
doing
it
in
a
very
consumer
friendly,
easy
way,
not
having
to
know
about
the
vcenter
apis.
How
does
the
inventory
work?
How
do
I
get
all
the
different
managed
object
reference
right?
We
want
to
really
decouple
that
and
ultimately
our
challenge
to
ourselves
was
like.
Can
we
do
this?
D
I'll
talk
a
little
about
when
we
dive
into
the
architecture
as
a
source
of
events
right,
but
we
can
actually
have
other
systems
come
in,
publish
the
set
of
events,
and
you
would
actually
have
the
same
set
of
capabilities
and
really
what
I
want
to
draw
here
is
really
the
possibilities
are
endless
right.
We
kind
of
start
out
with
the
canonical
slack
example
right,
a
vm
gets
powered
off.
D
Maybe
I
want
to
be
able
to
see
you
know
the
vm
that
was
powered
off,
who
did
it
when
they
occurred,
and
maybe
I
want
to
create
a
quick
url
that
allows
me
to
click
on
that,
and
that
will
actually
take
me
back
to
my
visual
ui.
That
could
be
a
very
possible
use
case
now.
We
can
also
optimize
on
that
and
say
well
what,
if
I
have
a
different
form
factor
of
my
notifications,
for
example.
So
maybe
I
want
it
as
a
text
message.
D
Well,
I
have
a
little
bit
amount
of
space
for
a
text
message.
So
maybe
I
just
want
to
know
you
know
who
powered
off
the
vm,
the
name
of
the
vm
and
then
I'll
generate
a
url
and
then
from
my
mobile
device.
Actually,
click
on
that
link
and
I
can
be
logged
into
the
vsphere
ui
right,
so
really
customizable.
Now
we
can
actually
take
this
step
further.
D
I
wanted
the
powered
off
event
right
and
you
just
identify
that
in
viba
and
then
you
just
write
just
enough
code
and
in
all
three
of
these
cases
you
know
it's
a
simple
curl
or
invoke
web
request.
Example
right
to
that
endpoint
with
your
authentication
and
the
payload
that
you
want
to
generate
right.
D
Endpoints.
That's
quite
interesting.
For
those
users,
we
have
a
lot
of
customers
who
have
automation,
teams
who
are
really
focused
and
dedicated
on
building
automation
right.
They
want
to
solve
these
business
specific
challenges
and
they
don't
want
to
learn
how
to
use
the
vsphere
api.
They
may
not
even
have
access
to
the
infrastructure
right,
so
we
actually
have
this
decoupling
between
how
the
events
are
generated
and
who
the
consumers
of
it
are
right.
D
So
when
you
saw
the
example
which
what
you're
really
getting
is
just
the
results
of
the
event,
you
don't
need
to
know
which
vcenter
it's
connected
to
and
you
don't
even
need
access
to
account
right.
So
this
decoupling
was
something
that
michael
kind
of
highlighted
it's
really
powerful
for
these
automation
engineers
to
actually
write
that
automation
and
then
other
teams
can
then
go
ahead
and
consume
that
automation
and,
lastly,
there's
a
huge
opportunity
for
our
vmware
third
party.
D
Like
I
mentioned
our
second
and
third
party
solution,
come
in,
imagine
like
a
backup
or
a
monitoring
solution
right.
You
can
now
react
to
very
specific
vm
lifecycle,
operation
right,
a
vm
gets
created.
You
can
automatically
take
this
second
or
third
party
solution
automatically
apply
things
like
backup
solutions,
security,
hardening
profiles,
monitoring
profiles
automatically
right,
and
so
it
really
gives
you
more
value
to
these
third-party
solutions
and
there's
a
number
of
different
systems
that
you
can
tap
into
right.
So
really
the
possibilities
are
endless,
even
from
our
third-party
ecosystem.
D
So
I'm
going
to
dive
into
the
architecture
a
little
bit
and
then
we'll
kind
of
jump
into
an
example
and
show
you
what
this
looks
like
right
inside
this
box.
Right
today,
like
I
mentioned
the
vcenter,
the
vmware
event
broker
is
provided
as
both
as
an
appliance
form
factor,
but
you
can
also
deploy
it
as
a
kubernetes
based
application.
The
appliance
form
factors
makes
it
very
easy
to
get
started,
especially
for
those
that
are
familiar
with
the
vista
based
infrastructure.
You
just
download
it
set
up.
Networking
connect
it
to
your
vcenter
server.
D
We
only
need
a
read-only
account.
That's
all
you
need
to
get
started
in
our
latest
release.
We
also
have
a
ui
component
and
I'll
actually
demo,
that,
for
you
just
to
show
you
how
easy
it
is
to
deploy
the
the
functions
that
you're
interested
in,
but
we
run
on
a
linux
optimized
operating
system.
This
is
vmware's
open
source
photon
os.
D
On
top
of
that,
we
run
a
kubernetes
onenote
to
be
able
to
host
this
infrastructure.
We
use
contour
for
ingress
connectivity
and
then,
on
the
upper
left,
hand
corner
the
vmware
event
router.
This
is
really
the
heart
of
the
solution
right,
it's
responsible
for
talking
to
vcenter,
using
that
read-only
account
that
you
provided
and
as
an
event
comes
in
it,
takes
that
event
and
turns
out
into
a
standardized
consumable
cloud
event
right
and
at
that
point
it's
available
for
different
consumers
to
consume.
A
I'm
a
little
curious
about
the
security
I
heard
you
say
that
it
uses
one
account.
That's
read
only
for
vsphere.
It
strikes
me,
maybe
that's
a
serious
attribute,
but
I
assume
that
once
it
gets
up
to
the
cloud
events
which,
by
the
way
is
a
cncf
sponsored
project
unto
itself
that
there
is
security
there,
so
that
random
people
off
the
internet
can't
just
subscribe
to
that
stuff
and
get
the
information
right.
D
Absolutely
yeah
so,
like
I
said,
the
the
event
router
just
needs
a
read-only
account
right,
so
you
won't
be
able
to
do
any
operations
and
that's
responsible
for
basically
talking
to
your
event
source
in
this
case
we're
talking
about
vcenter,
but
you
can
replace
that
v600
box
with
almost
any
arbitrary
system.
If
you
want
to
publish
custom
events
right
now,
depending
on
what
your
your
functions
is
going
to,
do,
you
have
the
ability
for
that
function
to
also
deploy
secrets,
that's
unique
to
that
particular
function.
D
So,
for
example,
if
I
wanted
the
ability
to
send
a
slack
we
have,
you
can
create
a
slack
secret
that
basically
has
your
web
hook
right
and
that
is
responsible
for
the
connectivity.
If
you
wanted
to
have
a
function
that
may
go
back
and
make
changes
to
your
vcenter
server,
you
would
provide
those
secrets
as
part
of
your
function
deployment.
So
each
of
the
functions
themselves
are
isolated.
D
We
also
take
advantage
of
kubernetes
name
spaces
and
our
back
from
from
that
point
of
view
right,
so
it's
executing
its
own
space,
and
so
there
is
no
direct
correlation
between
the
account.
That's
reading.
The
events
to
the
thing
that's
actually
executing
the
function,
because
you
can
actually
have
different
user
accounts.
They
might
actually
talk
to
different
systems
altogether
and
all
that.
So
there
is
that
clear
separation.
A
So
that
sounds
potentially
pretty
cool
because
you
know
there
are
going
to
be
a
lot
of
situations
where
you
might
be
running
geographically
distributed
vcenters,
maybe
even
multi-tenant.
You
know
where
you
deal
with
a
vendor.
You
don't
fully
trust,
but
you
should
am
I
correct
in
surmising
that
you
should
be
able
to
cobble
together
something
that's
still
secure,
yet
you
don't
have
to
be
handing
keys
back
and
forth
between
different
organizations.
D
That's
absolutely
right,
yeah
and
because
we
just
require
the
minimum
amount
to
read
the
events,
really
that's
the
baseline
to
start
with
right
and
depending
on
what
you're
trying
to
accomplish
in
terms
of
the
actual
function
or
the
the
outcome.
You
know
that
may
require
additional
privileges,
and
all
that-
and-
and
one
thing
I
do
want
to
note-
is
that
the
appliance
today
it's
a
one-to-one
mapping.
D
But
if
you
were
to
deploy
this
in
a
if
you
have
a
kubernetes-based
cluster,
you
can
deploy
multiple
instances
of
the
event
router,
and
so
we
have
customers
doing
that
today,
where
they
have
multiple
vcenters
spread
across
different
regions
and
all
that
and
they
actually
have
one
large
cluster
that
manages
it.
So
there's
definitely
a
lot
of
different
ways
of
deploying
this
operationally,
but
for
my
appliance
form
factor,
you
know
it's
very
simple:
deploy
and
connect
to
your
vcenter
server.
D
Awesome:
okay,
so
I'm
going
to
jump
into
a
a
slack
demo,
just
to
kind
of
show
you
what
that
looks
like.
So
I'm
going
to
start
out
with
my
v-string
at
least
for
environment.
I
have
a
vm,
that's
powered
on.
I
want
this
vm
to
not
be
powered
off,
and
so,
if
it
does
power
off,
I
want
to
do
something.
So
what
this
is
going
to
do
is
that
when
the
vm
gets
powered
off,
the
center
is
going
to
generate
a
power
off
effect.
D
I'm
gonna
have
a
function
specifically,
and
this
one
happens
to
be
written
in
powershell
and
it's
one
of
our
first
key
native
powershell
functions
and
what
it's
going
to
do
is
basically
send
me
a
slack
notification
right,
really
really
basic,
but
I
want
to
at
least
highlight
how
this
works
and
using
the
new
vsphere
ui
integration
with
the
viva
solution.
So
let
me
jump
into
that
real
quick.
D
Let
me
know
if
you
guys
are
still
able
to
see
my
screen:
okay
and
if
it's
bigger,
okay,
so
here's
my
vm
right
here,
it's
already
powered
on
it's
called
kubernetes
user
group
test
right
and
I
really
don't
want
that
vm
to
get
powered
off.
So
one
of
the
new
things
in
our
latest
six
0.6
release
is
integration
natively
into
vsphere
ui.
Now
you
can
certainly
deploy
these
functions
using
standard
kubernetes
manifest,
and
we
have
a
number
of
examples
to
show
you
how
to
do
that.
D
But
if
you
want
to
do
it
from
a
ui
standpoint,
especially
for
those
that
are
more
familiar
with
the
ui
or
aren't
comfortable
with
coding,
for
example,
or
you're,
just
a
consumer
of
these
events
and
functions,
we
now
have
a
nice
integration
into
the
ui.
One
of
the
big
questions
that
we
always
get
asked
about
is
like
well,
what
are
all
the
events
you
talked
about,
there's
1800
events.
What
exactly
are
they,
and
so
one
of
the
things
that
we
wanted
to
make
easily
available
to
our
administrators?
D
Is
that
now
we
have
this
events
tab.
So
when
you
click
onto
this
plugin,
we
have
three
tabs
here.
The
first
one
is
called
events
and
you
can
see
for
this
particular
vcenter
server.
I
have
about
1862
events
right,
so
your
vcenter
may
vary,
and
so
this
will
be
specifically
to
your
vcenter
server
and
you
can
quickly
filter
through
the
number
of
events.
You
know
other
consider
error
info
some
details
about
it
and
the
really
cool
things
I
can
actually
filter
so
earlier.
D
I
said
I
want
to
do
a
powered
off
event,
so
just
like
that,
just
by
quick
search,
I
can
quickly
find
the
event
that
I'm
interested
in
this
is
really
difficult
today,
if
you
don't
have
this
kind
of
table
mapping,
and
so
we
felt
that
this
was
very
easy
for
you
to
discover
what
events
are
available
to
you
and
then
from
here.
I
want
to
be
able
to
deploy
an
event
now
before
we
do
that.
This
particular
example.
I
want
to
send
to
slack
right,
so
I've
got
some
secrets.
D
D
So
give
it
a
secret
name-
and
this
is
just
the
name
of
the
kubernetes
secret
and
then
ultimately,
the
secret
key
is
what
your
environment
variable,
that
you're
gonna
basically
process
right
and
then
you're
gonna
have
a
secret.
I'm
gonna
pause
my
screen
really
quickly
and
then
let
me
copy
in
my
secure
web
hook.
D
Okay,
so
I've
gone
and
created
my
secret
right
and
now,
if
I
go
back
to
my
events,
I'm
gonna
go
ahead
and
look
for
that
powered
off
example
that
I'm
interested
in,
and
I
just
click
on
deploy
now,
if
I'd.
If
I
had
a
function,
deploy
what
it
showed
me
here
and
then
what
we're
going
to
do
is
give
this
give
this
function
a
name,
here's
my
container
image.
So
we
just
call
this
one
k
native
powershell
slack.
D
I've
got
my
container
image
right
and
inside
this
container
image.
All
it
has
is
basically
the
powershell
runtime
right
and
just
enough
code
to
basically
send
a
a
quick
web
hook
right,
really
really
basic
right.
If
I
had
environmental
variables,
I
could
actually
append
them
in
here.
In
this
particular
example,
I
don't
have
any
environmental
variables
that
my
function
can
consume.
So
you
can
imagine
some
debugging,
so
you
can
add
that
in
here
and
turn
them
turn
them
on
and
turn
them
off,
and
then
the
secret
that
I
had
created
earlier
right.
D
So
I'm
just
going
to
reference
that
and
just
like
that
I've
created
a
function
written
in
powershell.
That's
going
to
talk
to
slack
I've
been
able
to
identify
the
events,
so
I
don't
need
to
look
up
any
documentation
or
understand
how
the
vcr
api
works
and
I've
been
able
to
attach
my
secret
and
the
nice
thing
about.
The
secrets
is
that
I
can
reuse
it
right,
so
you
can
imagine
having
different
types
of
secrets
saved
in
the
system
and
they
can
be
reused
throughout
different
types
of
function
you
might
deploy.
D
D
The
second
part
of
that
is
the
trigger
which
is
given
the
event
in
this
case.
It's
a
powered
off
event.
That
is
the
thing
I
want
to
trigger
off
of
right,
and
so
the
function
is
really
a
composite
of
our
keynative
service
container
image.
I
want
to
call
and
the
trigger,
which
is
the
event
in
vcenter
that
I
want
to
basically
trigger
on
when
this
occurs.
So
now,
if
we
come
back
over
here,
we've
got
it
deployed
and
if
I
go
into
my
functions
tab,
this
is
a
quick
way
to
basically
glance
at
all.
D
So
let's
go
back
to
our
use
for
infrastructure.
I've
got
this
vm.
So
now
I'm
going
to
power
this
vm
off
and
hopefully
what
we
should
see
in
a
second
is
that
the
vm
gets
powered
off
and
hopefully
we'll
get
an
event
that
occurs,
and
it
should
call
into
our
powershell
function,
stating
that
yep
so
there
it
is
so
pretty
pretty
fast,
and
so
we
get
this
notification
in
this
particular
slack
channel
right.
D
It
gives
me
the
name
of
my
vm,
the
user,
that
actually
power
it
off
and
some
date
right.
So
a
really
really
basic
example,
just
to
kind
of
highlight
how
quickly
you
can
actually
build
functions
and
also
deploy
them
using
the
new
vsphere
ui
integration
with
the
viba
solution.
You
can
also
do
this
from
a
cli
point
of
view,
but
we
just
wanted
to
kind
of
highlight
how
easy
that
is
to
do
from
from
a
ui.
A
B
D
Yeah,
so
the
the
other
thing
too,
another
example
that
we
wanted
to
highlight
also
is
like
kind
of
these
four
alarms.
They
themselves
also
generate
a
lot,
an
event
itself
right,
but
it
only
generates
one
singular
event
that
gets
really
difficult
to
trap,
and
so
an
example
here
is,
like
you
know,
just
basically
filling
up.
You
get
an
alarm
really
interesting
and
you
can
also
derive
some
automation
right,
but
it
gets
really
tricky
to
be
able
to
take
this
and
kind
of
advance
it
and
do
more
advanced
capabilities
with
it.
D
It's
very
limited,
as
I
mentioned
earlier,
there's
also
security
concerns
around
access
to
scripts
and
then
there's
that
resource
concern
that
we
kind
of
mentioned
earlier
and
again,
it's
missing
information
about
the
alarm
details
itself,
right,
which
we'll
kind
of
try
to
show
you
highlight
really
quickly,
and
so
in
this
particular
example.
What
we
want
to
do
is
exact
same
thing:
alarm
happens
within
vcenter.
D
We
transform
that
into
a
cloud
event
and
what
we're
going
to
do
is
now
we're
going
to
use
a
a
technique
within
k,
native
called
a
sequence
and
a
parallel
right
be
able
to
have
a
service
called
the
alarm
server.
It
takes
that
exact
same
event.
What
it's
going
to
do
is
automatically
go
and
pull
more
information
about
that
particular
event
and
basically
create
a
cache
of
that
information.
So
it
doesn't
need
to
constantly
go
back
to
vcenter
right,
so
do
it
in
a
very
intelligent
manner.
D
So
you
can
see
what
that
looks
like
so
here
I
have
my
vcenter
event
again
and
I'm
going
to
go
back
to
my
storage
and
let's
say
I
have
an
alarm
here
right
and
typically,
when
you
get
this
alarm,
you
know
you're
acknowledging
with
the
visa
ui.
You
know
what,
if
we
can
actually
take,
that
information
get
a
little
bit
more
information
about
that
alarm
and
then
send
a
notification
to
it.
So,
right
now
I
have
an
alarm
definition
here:
called
data
store,
warn
and
I'll.
D
You
can
easily
create
some
of
these
more
advanced
workflows
and
a
lot
of
customers
want
to
be
able
to
take
these
alarms
and
derive
more
advanced
functionality
right,
maybe
some
into
slack
maybe
creating
a
servicenow
ticket
and
again
we
didn't
have
a
whole
lot
of
time
to
kind
of
go
into
the
deep
dive
of
this.
But
we
did
do
a
session
on
vmware
code
happy
to
provide
a
link
that
kind
of
gives
you
a
little
bit
more
details
from
there.
So
I'll
go
ahead
and
stop
sharing
just
an
interest
of
time.
E
E
I
have
a
few
examples
in
just
a
few
quick
slides
just
to
go
over
a
bit
of
the
use
cases
that
we
have
found
viva
top
within
kubernetes,
specifically,
so
so
in
general,
we're
running
viva
purely
on
kubernetes,
not
in
the
appliance,
so
we're
running
it
on
some
of
our
regular
highly
available
clusters
and
the
main
issues
that
we
have
with
running
kubernetes
on
vsphere.
That
viba
has
helped
us
with
is
one
is
drs
anti-affinity
rules.
E
Cluster
api
is
how
we're
provisioning
most
of
our
clusters
today
and
cluster
api
for
vsphere
does
not
whether
it's
the
vmware
solutions
based
off
that
or
the
open
source
does
not
have
any
way
to
create
drs
anti-affinity
rules
and
masternodes
or
control
plane.
Nodes
should
be
separated
by
all
best
practices
in
order
to
make
sure
that
we
have
a
resilient
control
plane
and
once
we
get
into
the
world
of
immutable
infrastructure
in
kubernetes.
E
Doing
this
manually
is
not
something
that
is
feasible
anymore,
because
control,
plane
nodes
can
come
up
every
few
minutes
or
whenever
they
do.
Whenever
there's
an
issue
and
that's
a
serious
issue,
another
one
is
dns
record
management
once
we're
not
creating
things
in
a
once.
Our
vms
are
immutable
and
they're
up
and
down.
E
We
still
do
have
systems
that
care
about
dns
records
and
not
ips,
so
managing
the
dns
management
for
our
kubernetes
clusters,
as
they
come
up,
I'm
not
just
creating
them
but
doing
the
entire
life
cycle,
including
updates
when
we're
using
dhcp
for
networking.
We
really
want
that
to
be
updated
and
we
don't
have
ddns
currently
set
up.
E
So
we
need
some
solution
to
do
basic
dns
for
us
for
our
kubernetes
clusters,
exclusion
from
backup
we
have
some,
we
have
backup
of
our
systems
and
it's
an
opt
out
policy
based
off
of
tags.
So
how
do
we
deal
with
tagging
vms
and
cap
v?
Cluster
api
does
not
have
a
way
of
tagging
vms
automatically.
Almost
none
of
the
kubernetes
solutions
on
vsphere
today
have
a
tagging
of
vm's
mechanism,
and
so
we
wanted
to
build
that
in
as
well
as
tagging
our
clusters.
E
E
Being
created
in
the
meantime,
we
can
see
that
all
of
our
kubernetes
nodes
that
we
create
will
automatically
get
tagged
for
us.
Sorry,
that's
what
I've
created
before
I
actually
updated
this,
but
if
we
go
down
here
all
of
these
clusters-
and
I
don't
have
permissions
with
this
user
one
second,
let
me
log
in
with
the
actual
user.
Sorry
about
that
and
permission
issues
in
a
lab,
but
all
of
our
clusters
are
basically
going
to
be
tagged
with
which
cluster
they
belong
to
so
automatically.
E
We
have
this
for
all
of
our
different
types
of
clusters.
We're
tagging
with
a
category
and
the
name,
and
also
what
we'll
see
in
a
moment
once
it
creates.
Is
that
automatically
we
are
going
to
have
here,
drs
groups
that
are
going
to
be
created
for
us
here
with
the
control
planes,
basically
very
simple,
the
cluster
name
and
then
separation
by
the
control
plane.
So
what
that
is
going
to
give
us
is
the
ability
to
automatically
create
this
now.
E
E
I
think
I
have
about
200
of
them
running
right
now
doing
different
pre-filters
based
off
of
naming
conventions,
we're
very
much
based
off
of
naming
conventions
here,
and
it's
a
really
easy
way
to
chain
your
functions
and
just
give
it
a
regex
based
off
of
what
field
of
the
data
and
then
let
it
run
a
function
accordingly.
So
here
we're
just
running
this
very
simply,
and
this
is
what
allows
us
to
create
our
dns
rules
or
anything
of
that
sort.
E
We
can
see
here
that
this
is
creating
a
new
vm
for
us
and
automatically
when
this
vm
was
created.
What
we'll
see
is
the
tag
will
come
up
in
a
moment
and
if
I
refresh
my
screen
here
on
the
dns,
we'll
see
that
a
dns
record
should
be
created
once
this
gets
an
ip
address,
which
it
did
so
that
should
be
219,
and
if
the
demo
gods
are
with
me
right
now,
which
I
don't
know
if
they
are,
but
I
hope
they
are
and
there
we
go.
E
We
have
our
219
dns
record,
which
is
automatically
created.
Same
thing
goes
when
we
delete
our
clusters
just
in
terms
of
again
where
viva
has
helped
us
in
the
past.
Overall,
we
have
three
different
v
centers,
each
with
a
dedicated
vibe
installation.
Each
one
is
on
its
own
vsan
on
its
own
kubernetes
cluster.
We
have
anywhere
between
90
to
130
functions
in
each
environment,
and
that's
just
growing.
E
Most
things,
I
would
say,
are
written
in
powershell,
but
we
do
have
quite
a
lot
in
go
in
python
and
a
few
and
node.js
and
one
of
the
nice
things
we've
been
able
to
do
is.
We
do
have
a
lot
of
vro
workflows
internally,
and
there
was
another
great
community
contribution
of
a
viba
action
or
function
that
can
actually
trigger
a
vro
workflow
for
us.
E
We
use
the
same
platform
to
run
our
event-driven
automations,
as
well
as
to
run
our
non-event-driven
automations
certain
tasks
that
we
want
to
run
in
the
system.
It's
really
nice
to
have
one
tool
that
can
do
them
all
and
we
can
write
our
code
very
easily.
Just
write
a
powershell
script
or
whatever
it
is
and
have
it
run
either
way.
A
D
A
D
B
A
Slide
here-
and
I
heard
you
mentioned-
that
there
was
a
viba
community.
So
maybe
if
you
can
talk
a
little
bit
about
where
someone
would
go
to
learn
more-
and
maybe
it
sounds
like-
we've
got
the
ability
for
grassroots
contributions
to
this,
at
least
in
the
form
of
examples
like
scott,
and
it
would
be
a
shame
if
everyone
keeps
that
to
themselves
rather
than
you
know,
being
a
force
multiplier,
so
that
people
don't
have
to
reinvent
wheels.
D
You
see
some
resources
available
to
you,
so
we
do
have
a
dedicated
code
slack
session
that
you
can
join
the
entire
viva
team's
there.
So
if
you
have
trouble
shooting
getting
going,
have
some
questions,
some
ideas
happy
to
hack
around
with
you
guys
on
that
front,
you
can
also
visit
the
fling
site,
that's
where
you
can
go
and
download
the
appliance.
If
you
want
to
build
it
yourself,
this
is
also
fully
open
source,
and
so,
if
you
go
to
bmw
eventbroker.io,
it
points
you
to
the
github
repo.
D
You
can
build
the
source
from
scratch.
If
you
want
to
do
that
and
there,
you
also
find
a
lot
of
the
function
examples
and
we
try
to
do
across
different
languages,
so
you
have
a
good
feel
for
it,
and
so,
if
there's
something
that
you're
interested
in
feel
free
to
drop
by
drop
us
the
use
case-
and
you
know-
maybe
one
of
us
might
create
it
or
you
might
even
go
to
start
it
and
we
can
kind
of
help
you
get
going
on
that.
D
A
A
C
E
D
Yeah
and
and
to
add
to
that
the
viva
solution
itself,
you
know
there's
kind
of
two
form
factors
right
if
you're,
a
typical
vmware
customer
and
you're
more
comfortable
with
deploying
kind
of
virtual
appliances
right,
that's
kind
of
the
first
form
factor
super
easy.
You
download
it.
You
set
up
networking
and
then
you
point
it
to
the
vcenter
that
you
want
to
start
to
receive
events
right.
That's
one
option
the
other
option
for
customers
who
already
have
existing
kubernetes
infrastructure.
D
This
could
be
vmware,
kubernetes
or
just
kind
of
any
upstream
kubernetes,
and
we
actually
have
customers
deploying
across
different
other
offerings,
viba
itself.
The
components
of
it
are
actually
kubernetes
kubernetes-based
application,
and
so
you
saw
michael
demonstrate
using
helm
to
deploy
the
event
router.
D
Take
a
look
at
the
latest
version
of
the
solution,
and
that's
just
if
you
want
to
use
the
ui
to
deploy
your
functions
if
you
prefer
to
go
through
automated
through
yaml
manifest
and
all
that
you
can
also
opt
out
of
the
ui
functionality
itself.
But
the
latest
version
supports
both
of
these
deployment
methodologies.
A
So
I
guess
beyond
the
poc,
if
you're
using
this
as
part
of
a
high
availability
solution
and
you've
got
multiple
points
of
redundancy,
it
seems
like
you'd
want
to
cross-host
this
so
that
you
know
the
pull
the
part
monitoring.
One
vcenter
isn't
hosted
on
that
same
vcenter
because
there's
an
obvious
problem
there,
but
once
you
reach
the
point
where
you've
got
two
or
more
you've
got
this
opportunity
to
cross
host
the
components
here
to
make
this
thing
highly
available
and
resilient.
A
I
think
the
other
thing
I
noticed
scott
was
that
for
consuming
the
events
you
were
using
open
fast
williams
example
used
k-native,
but
that's
the
magic
of
these
cloud.
Events
in
that
you
know
it's
an
open
ecosystem.
So
if
there's
something
you're
more
comfortable,
if
they're
familiar
with
just
go
for
it,
this,
there
should
be
a
broad
variety
of
things
that
you
could
consume
with
consume
this
with
including
some
that
can
run
on
pretty
minimal
resource.
B
B
The
so
there's
a
little
bit
of
difference.
What
promises
is
typically
used
for,
like
metrics
versus
what
events
are
versus
what
locks
are,
or
even
commands
like
there's
these
different
semantical,
like
differences,
so
to
say
between
these,
like
traces,
logs
and
events
and
premises
is
typically
used
for
metrics
metrics,
aggregation
and
analytics
on
metrics,
which
you
could
say
if
you
have
an
iit
device,
and
it
sends
sensor
data
that
is
actually
metrics
right
and
you
could.
B
You
could
make
it
an
event
and
then
send
it
to
kafka
or
let
it
ingest
it
into
prometheus.
Typically,
you
don't
see
events
being
consumed
by
prometheus,
because
there's
a
often
like
a
push
model
in
these
streaming
or
inventing
pipelines
versus
produces
goes
out
and
scripts
from
endpoints.
It
could
technically
be
done
to
build
like
an
integration
where
producers
pulls
out
events
from,
say,
a
promises,
exporter
or
a
gateway
right
which
which
does
exist,
but
I
would
say
that
the
events
are
probably
not
a
good
fit.
D
C
D
Yeah,
you
will
basically
want
to
track
everything.
That's
happened.
Yeah
I
mean
this
is
something
that
a
lot
of
customers
have
been
doing
and
and
more
so
specifically
with
fiba.
It's
been
a
lot
easier.
As
you
may
know,
you
know
vcenter
itself,
you
know
it
stores
all
these
different
events
right
and
to
be
able
to
go
back
to
certain
amount
of
time.
You
know
your
your
control
of
that
is
basically
at
a
global
level.
Right.
Do
you
want
to
start
one
month
of
data
or
one
year
of
data?
D
You
know
I've
worked
in
large
enterprises
where
we
had
to
have
all
of
these
events
stored
for
a
year.
That
means
your
vcenter
gets
really
bloated
in
reality.
Ninety
percent
of
that
data-
you
really
don't
need,
and
you
really
want
to
be
selective
of
it.
Maybe
it's
destructive
operations.
Maybe
it's
just
all
your
vm
operations.
D
We
have
a
number
of
customers
that
are
sending
this
to
like
cloud
watches
example
right,
so
that
becomes
our
archival
store,
then
go
back
in
time
and
look
at
literally
the
history
of
a
vm
it
got
created
by
this
particular
user.
It's
got
updated.
It's
moved
from
host
a
to
host
b.
You
can
actually
track
all
those
events
and,
from
viva's
point
of
view,
you
can
selectively
pick
all
the
events
that
you
care
about
right
and
then
for
that
off
kafka.
We,
you
know
we
actually
did
a
prototype
with
kafka
ages
ago.
D
Maybe
we
need
to
revive
that,
but
that
becomes
kind
of
like
a
data
warehouse
of
sorts
where
you
can
go
in
and
actually
look
at
the
history
build
analytics,
build
the
tooling
you
can
maybe
send
it
to
logging
there's
a
number
of
data
stores
that
you
can
send
it
to
and
so
yeah.
We
definitely
have
some
customers
doing
that
today.
So
it
really
just
depends
on
what
your
use
case
is
and
what
you
want
to
do
with
the
data.
D
But
this
allows
you
to
actually
keep
your
vcenter
event
database
fairly
small
generally,
like
a
month
or
two
months
of
real
time
where
you
can
go
in
and
take
a
look
at
it
and
for
everything
else:
historical
purposes.
You
can
actually
forward
it
off
very
easily
into
your
data
source
of
your
choice
and
then
from
there.
You
can
start
working
with
that
data.
C
You
can
identify
our
situation,
it's
not
so
much
so
I
mean
we're
all
kubernetes
people.
So
if,
if
I'm
working
with
some
of
the
people
on
my
team
like
they
were
like,
I've
never
touched
vmware
before
so,
if
there's
an
issue
in
vmware
or
vmware
has
an
issue
on
that
their
side,
I'm
having
to
teach
them
how
to
go.
C
Look
at
the
vcenter
or
look
through
the
events
look
through
what's
all
going
on
there
on
the
v
center,
whereas
if
we
were
able
to
just
take
those
events
and
and
put
them
in
like
prometheus,
then
they
they
would
they're
like.
Oh,
I
understand
this.
I
did
it
yeah,
that's
kind
of
my
thought.
There
I
mean.
A
B
No,
it
really
depends
on
the
type
of
the
data
right,
for
example,
if
you
get
alerts
that
is
more
like
telemetry
related,
and
so
you
could
write
a
sync
or
like
a
processor
that
then
takes
these
events
and
exposes
them
as
promises
metrics
like
because
promises
pulls
right
unless
you
use
the
prometheus
push
gateway
as
miles
points
out
elasticsearch.
These
kind
of
logging
based
systems
are
probably
better
for
it
in
terms
of
figuring
out
what
the
system
was
doing
like
when
a
vm
moved
from
a
to
b.
B
That's
not
really
telemetry,
it's
more
like
a
behavior
right
that
you're
investigating
and
what
we
haven't
shown
is
that
you
can
actually
aggregate
sources
be,
for
example,
typically,
your
kubernetes
runs
on
the
vcr
infrastructure
right
because
it
needs
infrastructure.
What
you
could
do
you
have.
We
have
a
kubernetes
source
which
pulls
the
kubernetes
apis
over,
and
then
we
have
the
vsphere
source,
which
pulls
the
vsphere
infrastructure,
and
then
you
can
correlate
right.
You
can
see
if
the
pod
comes
up
and
you
have
the
the
node
for
this.
B
A
A
Also,
if
anybody
any
users
have
suggestions
for
what
you
want
to
hear
about
in
the
meeting
next
month,
please
let
miles
and
us
I
know
we're
happy
to
accept
homework
we'd
like
it
in
advance,
so
we
can
go
recruit
speakers,
but
the
agenda
of
this
group
is
driven
by
you.
So
please
take
the
next
60
seconds
to
throw
out
ideas
there
to
help
us
out.
We
want
this
group
to
serve
the
community
and
get
huge.
So
please
help
us
build
that
community.
By
doing
that,.
A
Okay,
I
put
you
on
the
spot
by
call
calling
for
it
in
60
seconds.
If
your
idea
takes
longer
to
compose,
please
just
leave
us
notes
in
the
slack
channel
on
the
kubernetes
slack
because,
like
I
say,
we're
trying
to
grow
this
and
make
this
serve
the
community
of
people
running
kubernetes
on
top
of
vmware
infrastructure
thanks
for
attending
it
usually
takes
a
day
or
two,
but
the
recording
of
this
will
end
up
published
on
youtube.
If
you
want
to
share
with
your
friends
so
bye,
everybody
thanks.