►
From YouTube: TGI Kubernetes 152: Cluster Testing with Sonobuoy
Description
Evan Anderson and Gustavo Franco discuss using Sonobuoy to run your own cluster-level acceptance tests.
A
Hello,
everyone
we're
probably
going
to
give
a
couple
minutes
for
people
to
trickle
in,
but
I
wanted
to
sort
of
get
faces
on
screen
rather
than
just
leave
you
sitting
at
the
title
card,
so
I'm
evan
anderson,
I'm
a
software
engineer.
Who's
been
working
on
the
k-native
project
for
the
last
couple
years,
but
today
I'm
going
to
be
exploring
solo
boy,
a
project
I
know
almost
nothing
about
and
with
me,
is
gustavo
franco
and
go
for
it.
B
Hey
folks,
yeah,
so
gusav
franco,
senior
manager
for
situ
level,
engineering
at
vmware
and
yeah
happy
to
be
here
to
explore.
Sono
boy
talk
a
little
bit
about
some
of
the
the
plug
is
important
plugins
in
particular
reliability
scanner,
they'll
be
working
on
and
yeah
like
interested
in
use
cases
and
things
that
we've
been
doing
and
also
ready
to
explore.
B
A
A
A
A
And
for
those
of
you
who
don't
who
aren't
familiar
with
this,
we
have
shared
notes,
there's
a
little
banner.
I
do
this
ta-ha
even
with
mirror
mode,
so
you
can
add
to
the
notes
as
we're
going
along
I'll,
be
going
through
and
cleaning
them
up
at
the
end.
But
if
you
all
want
to
put
comment
in
there
in
the
meantime,
it's
gonna,
be,
you
know,
it'll
be
a
help,
any
links
and
so
forth
that
you
want
to
add.
A
D
A
Yeah
we
are,
we
are
light
in
the
kubernetes
and
cloud
native
ecosystem
news
for
the
week
right
now.
To
be
honest,
I
was
on
vacation
for
the
first
half
of
the
week,
so
I
just
kind
of
ignored
almost
all
the
news
going
on,
but
I'm
sure
that
people
out
there
have
been
doing
interesting
and
exciting
things.
The
only
reason
I
know
there
was
a
canadian
release
actually
last
week
was
that
I
was
doing
it
before.
I
took
some
time
off.
C
A
A
On
the
other
hand,
it
can
be
really
yeah.
It
can
be
really
tiring
to
say
hey.
I
just
rolled
out
this
really
since,
like
you're
already
out
of
date
time
to
go
back
again.
You
know
it's
a
little
harder
to
update
a
cluster
than
it
is
to
update
your
web
browser.
So
there's
also
a
container
vulnera
container
d
vulnerability
out
there.
If
you
haven't
seen
this
cde,
the
summary
is
that
you
can
deadlock
container
d.
A
A
A
And
yeah
so
there's
the
upgrades
that
you're
that
you
get
because
we
ship
new
feature
because
kubernetes
is
shipping
new
features
and
there's
the
upgrades
you
get
because
there's
a
vulnerability
and
yeah
for
those
of
you
who
aren't
already
registered
there's
a
virtual
cube
kind
of
you
in
a
couple
weeks,
there's
still
time
to
register
and
the
the
if
you
are
on
a
budget
and
you're.
Like
I
don't
know.
A
A
And
then
I
mentioned
in
the
kubernetes
and
cloud
native
ecosystem
k-native
is
out,
you
know,
has
a
new
release
every
six
weeks.
We
do
a
release
and
yeah
it's
it's
like
clockwork
a
little
faster
than
the
kubernetes
frequency,
but
I
don't
have
any
other
news.
I
didn't
see
any
news
in
chat,
but
if
anyone
wants
to
throw
news
in
there.
B
A
Yeah,
it's
always
nice
to
have
someone
here:
who's
actually
familiar
with
the
software
as
we
go
bumbling
through
it.
So
for
those
of
you
who
aren't
familiar
sonoboy
is
the
tool
that
you
that
kubernetes
uses
to
run
conformance
tests
and
it's
not
just
a
tool
for
running
kubernetes
conformance
tests,
but
that's
where
most
people
probably
know
it
from,
and
so
the
basic
model
of
sono
boy
is
that
it
will.
A
A
B
Yeah
and
while
you
do
that
yeah,
let
me
call
for
folks
like
sonoboy,
is
interesting,
so
there's
a
both
a
plug-in
framework,
so
it's
extensible
and
also
different
modes
right
there.
You
can
run
sonoboy
even
without
leveraging
the
plug-in
architecture,
so
the
end-to-end
mode
has,
if
you're
not
mistaken,
what
we
can
correct
me
for
wrong.
B
A
A
C
B
C
C
C
A
C
A
Moaning
suggesting
using
a
kind
cluster
in
order,
I
think
willie-
was
suggesting
using
a
kind
cluster
in
order
to
just
be
able
to
blow
away
the
cluster
and
create
a
new
one,
which
is
great
for
testing.
But
it's
really
easy.
I
definitely
get
into
this
habit
of
oh
just
blow
away
the
cluster
and
create
a
new
one
which
is
great
until
you're,
using
it
in
production,
and
then
it's
like.
I
can't
do
that
anymore.
A
A
A
A
A
B
A
A
B
B
A
A
A
B
Clever,
okay,
cool,
so
pretty
simple,
but
just
to
kind
of
show
the
url
right
so
yeah,
it's
on
github
vmware
tends
to
use
sonobot
plugins
reliability
scan
is
one
of
the
plugins,
so
you
just
download
you
can
just
clone
off
them.
So
that's
you
know
through
here
you
clone
them
and
let
me
show
you
and
kind
of
get
you
through
the
config.
So
within
the
reliability
scanner
we
have
the
concept
of
reliability
checks,
so
basically
the
risks,
the
things
we're
checking
for
and
that's
an
ever-growing
list,
so
one
is
backup
freshness.
B
So
is
this
closer
being
backed
up
using
valero?
So
that's
something
that
sono
boy,
the
reliability
scanner
once
you
run
it
will
check
across.
You
know
this
cluster,
but
if
you
run
across
multiple
cluster
right,
it's
a
cool
report
to
get
like
okay,
which
backups
are
fresh
and
by
fresh,
it's
both
looking
for
expire
backups.
If
you
have
the
ttl
set
on
valero
and
we're
also
about
to
implement
a
max
age,
so
you
can
override
you
know
here.
B
So
we're
gonna
have
a
so
right
now:
spack,
backup,
name,
space,
we're
gonna,
add
a
max
age.
So
if
you're
like
yeah,
I
really
want
to
check
all
the
backups
are
older
than
I
don't
know
a
day
a
week,
no
matter
the
ttl
and
valero.
So
that's
something
that
sono
boy
can
do
for
you
with
the
reliability
scanner
plugin,
so
backup
freshness
is
one
thing
that
we
are
implementing
pod
disruption.
So,
basically,
do
you
have
all
of
your
pods
cover
under
a
disruption
budget
right,
so
people
generally
ask
include
detail.
B
What
does
that
mean
so
include
detail
equals
through
is
for
the
report.
You
don't
just
get
a
pass
or
fail.
You
got
a
list
of
pods
that
are
included
or
not
in
a
pod
disruption
budget.
We
haven't
implemented
a
filter
yet,
but
it's
probably
a
good
idea
right.
You
can
filter
out
or
just
you
know,
include
or
exclude
in
scope
there,
and
the
qos
check
is
basically
a
minimal
desire.
B
Kos,
like
you
can
run
against
one
or
multiple
clusters,
like
I
wanna,
have
a
minimal
qrs
of
guaranteed
and
same
thing
include
detail.
It's
not
just
through
pass
and
phase
we're
going
to
include
in
the
log
in
the
output
will
show
you
the
the
pods
that
are
say:
failure
not
passing
the
check
right.
Other
thing
that
you
know
could
be
a
considerable
reliability
risk
is
that
you
may
have
name
spaces
with
our
owner,
so
then
checking
for
an
honor
label.
So
this
is
more
like
a
matter
of
policy
right.
B
So
if
you
want
to
have
a
policy
and
kind
of
scan
for
who's,
conforming
to
that
policy
and
probes,
so
do
we
have
probes,
liveness
readiness,
probes
so
back
to
all
those
things
are
not
super
difficult
to
do
manually
to
check
manually,
but
I
think
it's
cool
that
in
aggregate
you
got
this
like
yellow
config
and
then
you
can
kind
of
you
know
you
get
a
reasonable
default
and
you
can
rust
on
a
boy
with
a
reliability
scanner
and
then
boom.
It's
gonna
do
kind
of
off
this
at
once.
B
For
you,
you
don't
have
to
kind
of
the
sre
approach
of
you
know
eliminating
toy
right,
so
this
eliminate
a
lot
of
toy
of
checking
for
configuration
mistakes.
Of
course.
Ideally,
it
will
be
impossible
to
make
such
mistakes
because
you
will
be
creating
the
cluster
or
creating
your
clusters
in
a
way
that
prevents
this,
but
we
know
in
reality
right
you
kind
of
need,
checks
and
balances
right.
So,
ideally,
you
create
the
clusters
to
avoid
this,
and
then
you
have
the
tool
to
kind
of
scan
for
all
of
your
production
clusters.
A
My
experience
has
also
been
that
over
time
you
add
checks
here
based
on
hard-won
experience
of
you
know:
oh
gosh,
maybe
that
thing
was
important.
We
should
check
for
that,
and
you
know
once
you've
discovered
that
you
know.
Oh
hey
qos
is
important.
We
should
make
sure
that
everything
that
is,
you
know
a
serving
namespace
or
something
like
that
has
qos
set.
Then
you
need
to
go
back
over
and
actually
go
and
check
that
and
you
can
set
a
policy
to
protect
things
going
forward,
but
that
doesn't
help
all
the
stuff.
B
Exactly
yeah
100,
and
so
how
do
we
run
this
thing
right?
So
then
we
have
basically
a
basic
javascript.
We
we
have
three
clusters.
We're
gonna,
do
like
a
backup
example
thing
so,
like
imagine,
if
you
just
had
in
your
config
the
the
backup
freshness
check
on
top,
and
so
we
have
kind
clusters
here.
The
plugin
uses
ytt,
which
is
part
of
carvel
right
so
for
a
template,
so
think
of,
like
you
know,
template
adding
template
template
to.
B
B
B
A
B
Yeah
that'll
be
cool
yeah.
I
I
love
ideas
for
checks.
We
have
a
list.
I
think,
on
the
repository
of
things
that
we
want
to
implement.
The
backup
is
super.
Recent
peter
grant
was
also
on
chat,
implemented
this
yesterday.
I
think
so
then
yeah
we
do
run
and
it's
like
it's
gonna,
basically
refresh
the
so
it's
the
leading
zone,
boy
and
switching
the
contacts
to
the
cluster.
So
we
have
three
kind
clusters,
so
let
that
run.
B
B
B
B
At
the
bottom,
I
have
it
running
right
now:
oh,
it's
not
gonna
yeah!
So
it's
it's
not
overwriting!
This
file,
it's
overriding
one
directory
up,
but
we're
gonna
have
more
so
we're
gonna
have
fresh
results
but
yeah.
I
think
this.
This
shows
that
if
you
don't
have
backups
running
this
log,
then
it's
going
to
show
no
backups
defined.
It
shows
you
the
name
it's
valero,
and
so
that's
what
we
want
to
see
right,
no
backups
backups
are
failing.
B
D
D
B
B
B
B
Okay,
we
had
two
backups
nickelodeon,
I
see
yeah,
so
no
backups.
We
don't
have
any
backups
to
find
yeah
thanks
peter
peter
put
the
demo
together
for
us,
so
yeah
no
backups,
as
you
can
see
in
the
logs.
It
fails
because
there
are
no
backups
to
find,
and
this
is
exactly
what
we
want
and
then
we
got
the
name
of
the
backup
which
is
valero
and
when
we're
looking
to
expire
backup,
we
can
see
that
it's
also
fail
because
it
is
expired.
A
C
B
A
A
B
A
B
And,
let's
see,
let
me
cover
a
question
from
the
chat,
real,
quick,
yeah.
Well
yeah.
Someone
was
asking
about
like
why
not
set
this
as
a
policy
yeah.
We
have
both
so
we're
looking
to
open,
gatekeeper
as
well
and
to
so
kind
of
the
sibling
project
right.
So
this
is
the
scanner
we
have
the
reliability
policies
project.
That
is
simply
of
this
one.
So
to
cover
kind
of
cover
on
both
sides,
right
kind
of
like
evan
was
explaining.
C
C
A
A
A
A
A
B
C
B
There
is
an
editor
here,
the
question
about
visualization
and
logs
for
reliability:
scanner.
It's
like
yeah,
it's
now
purely
logged,
so
we
don't
have
anything
that
is
easier
to
make
it
visualize
elsewhere,
like
for
me
to
use
or
anything
like
that,
yeah
happy
to
to
look
into
the
suggestions
here
on
how
to
like
how
I
guess
how
folks
in
the
community
would
like
to
consume
that
kind
of
report.
B
A
A
C
C
C
A
A
A
D
D
D
C
A
C
C
C
C
C
B
C
C
C
A
A
C
C
C
A
A
B
B
B
B
B
To
talk
about,
but
we
have
bot
probes.
If
pros
are
you
know
available
or
not,
and
the
name
spaces,
if
you
name
space,
has
an
understat
and
kiosk.
If
there's
a
minimal,
desirable,
kos
disruption
and
backup
freshness,
we
can
run
all
the
checks
at
once
against
you
know
the
cluster,
but
just
you
know,
for
the
sake
of
this
exercise,
we're
just
focusing
on
backup
freshness
in
this
one.
A
A
B
C
C
B
A
A
C
C
C
C
C
C
C
A
A
A
C
D
A
A
A
So
we've
built
a
new
image
here.
You
can
see
that
co
will
print
out
the
name
of
the
image
with
a
shell
one
digest,
and
then
it
looks
like
that.
This
is
going
to
do
basically
the
same
thing
that
this
that
this
docker
file
does,
except
it's
going
to
use
my
environment's
golang,
and
so
it's
going
to
build
this
reliability
scanner
binary
and
then
from
distro
list
base.
It's
going
to
do
the
same
copy
instead
of
copying
it
from
this
build.
A
C
C
C
C
A
C
C
A
A
C
C
A
A
A
A
B
B
A
B
Anyway,
I
took
for
folks,
you
know
in
the
audience
to
to
simplify
the
reliability
scanner
plug-in
and
the
make
file
we
have
like
the
shortcuts.
So
if
you
make
results,
we
kind
of
run
that,
for
you,
you're
gonna
see
what
evan's
running
now
to
kind
of
get
to
the
detail.
Results
for
the
reliability
scanner
run.
C
A
A
A
B
A
C
C
C
C
A
A
C
C
C
C
C
C
C
A
C
D
C
C
C
A
C
C
D
C
C
C
A
B
C
B
A
A
B
A
A
B
A
A
B
A
C
A
B
Just
do
not
need
to
buy
some
boy
at
all,
just
the
way
we
we
because
it's
you
can
think
of
the
reliability
scanner
as
a
plug-in
of
plug-ins
right,
because
each
jack
is
sort
of
you
know
like
a
plug-in
on
its
own,
so
we
had
a
way
to
really
configure
that
within
the
reliability
it's
going
to
plug
in
so
no
summer.
Boy
does
not
require
this
at
all.
B
A
C
B
And
you
have
to
clarify
for
the
audience
like
we're
saying
right:
this
is
just
needed
if
you're
trying
to
develop
a
new
check,
so
the
reliability
is
going
to
plug
in
if
you're
just
trying
to
run.
You
don't
need
to
do
any
of
this.
It's
just
that
that
demo,
that
I
did
it's
like.
Basically,
three
commands
and
you're
done.
A
B
A
A
Yeah,
I'm
not
sure
how
the
best
way
to
parameterize
this
is,
but
it's
super
surprising.
The
image
is
hard-coded
here,
but
that
you
also
have
parameters
for
it
in
the
make
file
which
I'm
guessing
get
used
for
docker
build
and
docker
push,
but
you
could
probably
pass
them
in
as
as
arguments
to
ytt
here
as
well.
A
C
A
C
A
A
A
C
C
B
C
A
A
B
C
B
A
A
C
A
C
D
A
D
A
A
C
C
A
It
looked
like
90
minutes
if
we
were
actually
going
to
do.
This
we'd
want
to
go
in
here
and
add
a
duration
that
you
could
parse
out
to
add
duration
for
age
and
then
we'd
use
that
down
here
with
the
spec
instead
of
saying
one
time
negative
one
times
our
you
would
put
something
reasonable
in
there
instead
and
then
you'd
be
done
so.
A
It
would
be
really
nice
if
you
could
auto
generate
a
stub
from
here
or
have
some
way
to
automatically
figure
out.
Oh
hey
here
was
a
check
that
was
added.
You
know,
maybe
you
want
to
hook
it
into
this
other
config
file,
that's
in
a
different
place.
If
you
look
there's
actually
three
places,
so
I
needed
to
put
my
check
here.
I
needed
to
put
my
check
in
config.go,
and
I
needed
to
put
my
check
over
here
and
thinking
about
the
code
in
config.go.
B
A
A
A
Yeah,
but
we
we
found
all
of
the
old
pods
and
we
can
actually
double
check
that
because
you
can
run
just
a
cube,
control
get
pod
dash
a
for
all
name
spaces
and
other
than
discovering
that
a
few
of
these
pod
names
are
really
long.
You
can
see
that
yeah,
almost
all
of
them,
are
three
hours
old
at
this
point,
and
if
we
really
wanted
to
check,
we
could
put
the
barrier
at
like
four
hours
and
then
see
which
ones
fall
out
here.