►
From YouTube: Building Applications to Increase Kubernetes Adoption, and Make Life Easier - Kate Kuchin, Heptio
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Building Applications to Increase Kubernetes Adoption, and Make Life Easier Once You've Adopted It - Kate Kuchin, Heptio (Any Skill Level)
Web UIs have the potential to both make experienced cluster administrators' jobs easier and help drive adoption of cloud-native technologies. So how do we build these interfaces? Kate will share what is needed to design and build user interfaces to make Kubernetes concepts more accessible to all experience levels. She will talk about how frontend engineers and designers can first ramp up on Kubernetes, so they understand the problem space. Once a product team is equipped with the knowledge to build tools, their next task is to define the problems that can be solved with a UI, and the ones that cannot. She will highlight the work her team at Heptio has done on Sonobuoy Scanner, a UI for running CNCF conformance tests, and other Heptio tools in the making. Lastly, she will speak to what problems (with potential UI solutions) still exist, and how we can work together to solve them.
About Kate
Kate is a Software Engineer at Heptio, where she works on the UX team to build tools to make Kubernetes easier to adopt and use. She started her career at Google, where she worked on the Consumer Operations team of (the now sadly defunct) orkut. She has since worked at startups throughout the country, but is now settled in Oakland, where she spends her days working from home alongside her officemate, Helen the dog. This is her first time proposing a talk.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
Good
afternoon
my
name
is
Kate
Kucha
and
I
am
a
software
engineer
at
hep,
tio
and
today,
I'll
be
talking
about
making
new
eyes
to
make
kubernetes
more
accessible
and
easier
to
use.
If
you'd
like
to
find
me
on
the
internet,
I
have
a
pretty
disjointed
online
presence,
but
you
can
find
me
on
twitter
at
excuse
me
on
github,
at
kate
k,
which
I
did
not
know
about
Kate's
when
I
made
that
and
on
instagram
at
kate
couch,
in
which
I
only
mentioned,
because
that
is
where
the
pictures
of
my
dog
are
in
previous
lives.
A
I
worked
on
Google's
now-defunct
social
network
Orkut.
May
she
rest
in
peace
writing.
Documentation
conducted
conducting
user
research
and
coordinating
localization
I've
also
worked
on
several
political
campaigns,
including
one
that
resulted
in
the
world's
largest
earth
pressure,
tunnel-boring
machine
bertha,
getting
stuck
under
seattle
for
over
a
year,
so
you're
welcome
seattle.
For
some
reason
I
have
a
master's
in
public
administration.
A
I've
been
it
have
to
go
for
just
under
a
year,
which
makes
me
sort
of
old
and
hefty
o
years.
Hep
to
you,
for
those
of
you
don't
know,
was
founded
by
Joe
betta
and
Craig
McCaw.
He
two
of
the
founders
of
hep
do
in
2016,
and
our
mission
is
to
grow
the
kubernetes
community
by
10x
by
making
the
technology
more
accessible
and
usable
I
work
with
a
great
group
of
humans.
A
Hep
do
we're
called
the
snow
squad
for
no
real
reason,
but
it
sounds
cool
and
our
team
works
to
build
products
that
make
kubernetes
easier
to
adopt
and
easier
to
use.
Our
upcoming
project
is
super
super
exciting,
but
unfortunately
it
is
not
launched
yet,
and
I
am
NOT
here
to
launch
it.
So
I
will
not
be
talking
about
it
in
too
much
detail
for
what
I
presume
are
obvious
reasons,
paramount
of
which
is
that
I
don't
really
want
to
get
fired.
A
A
These
really
are
two
distinct
problems,
but
if
we
build
the
right
products,
we
can
hopefully
tackle
them
both
together,
all
right,
so
we
already
went
over
who
I
am
and
what
I
do,
and
as
much
as
I'd
love
to
talk
to
y'all
about
Orkut
for
30
minutes.
You'll
have
to
find
me
after
and
making
dazzle
you
with
some
Brazilian
Portuguese,
but
next
up
I'm
going
to
talk
about
how
UI
engineers,
designers,
product
people
in
just
general
non
systems.
A
Engineers
can
get
ramped
up
on
kubernetes
and
also
has
systems
engineers
and
other
kubernetes
experts
can
help
with
this
onboarding.
There
are
a
lot
of
problems
left
to
solve
with
kubernetes,
and
many
of
them
could
be
addressed
with
the
UI,
but
if
people
who
are
experts
in
UI
and
design
can't
understand
the
problem
space,
we
can't
really
build
solutions
that
are
much
of
use
to
anyone.
So
after
I
have
waxed
poetic
about
onboarding
ramping
up
being
kind
to
one
another
in
the
process,
we'll
move
on
to
more.
A
Generally
speaking
about
what
kind
of
value
you
guys
can
add,
there
are
the
traditional
benefits
of
UI's
and
there
are
also
some
unique
benefits
that
you
guys
can
offer
in
making
kubernetes
more
accessible
all
right.
So
before
we
get
started
talking
about
those
kind
of
problems
we
can
solve
the
first,
we
to
understand
the
problem
space,
but
there's
one
catch.
A
Kubernetes
was
designed
by
systems
engineers
for
systems
engineers,
which
is
great
if
you're
a
systems
engineer
for
the
rest
of
us
kubernetes
is
really
really
intimidating,
with
the
exception
of
those
people
who
created
kubernetes,
who
were
there
at
the
very
beginning,
everyone
in
this
room
was
probably
a
new
kubernetes
user
at
some
point,
or
is
it
new
kubernetes
user
now
or
will
be
a
new
kubernetes
user
next
week?
So
you
all
probably
know
that
it
can
be
pretty
daunting.
A
So
my
first
real
introduction
to
kubernetes
came
my
first.
We
could
have
to
you
I
spent
the
week
in
the
Seattle
office
learning
as
much
as
I
could
and
trying
to
not
fully
panic
it.
What
I've,
gotten
myself
into
I
had
the
luxury
of
having
Joe
betta,
one
of
the
creators
of
kubernetes,
get
in
front
of
the
whiteboard
and
spend
two
hours
or
more
with
me
and
a
couple
of
our
couple
other
new
hires
and
just
go
over
the
basic
concepts
of
kubernetes.
A
It
was
incredible,
but
it's
not
exactly
scalable
and
also
listening
to
someone
who
created
technology
is
incredibly
inspiring
interesting
and,
if
done
well
can
make
you
feel
like
you
can
be
an
expert
in
a
space
and
you
want
to
be,
but
it's
also
not
immediately
useful
on
day.
One
I
knew
that
the
kubernetes
scheduler
could
be
optimized
for
resource
allocation
or
latency,
but
I
didn't
want
to
set
up
a
class.
I,
probably
don't
even
know
what
the
kubernetes
scheduler
was
and
I
definitely
didn't
know
how
to
use
cube
kettle.
A
So
you
kind
of
can
come
into
this
space
feeling
a
little
bit
adrift
and
there
are
a
lot
of
resources
out
there
and
that's
great,
but
it
can
be
a
little
bit
intimidating
to
find
out
where
to
start,
especially
if
you're,
not
a
systems
engineer.
This
deluge
of
resources
can
just
increase
the
intimidation.
So
here's
where
I
recommend
you
start
I
know
this
seems
like
obvious
advice,
but
it
bears
repeating.
Read
the
docs,
the
folks
who
work
on
kubernetes,
docks
left
and
a
lot
of
really
really
awesome
work,
especially
in
this
past
year.
A
If
you're
brand
new
to
kubernetes
I'd
recommend
starting
out
at
the
foundational
app
developer
journey,
the
kubernetes
documentation
quite
helpfully
is
differentiates
between
app
developers
and
cluster
operators
and
the
documentation
targeted
towards
app
developers,
isn't
a
comprehensive
overview
of
kubernetes
itself,
but
instead
focuses
on
using
kubernetes
rather
than
the
underlying
infrastructure
for
non
systems.
Engineer
I
recommend
starting
there,
because
it's
more
approachable
and
when
you
move
into
the
more
complex
information
you'll
have
some
context.
A
So
the
foundational
user
journey
does
a
great
job
of
breaking
down
what
you
need
to
know
and
breaking
into
small
enough
pieces
that
it's
not
overwhelming
it
walks
you
through
setting
up
a
cluster
either
through
a
web-based
environment
or
mini
cube,
which
we'll
talk
about
in
a
second
and
then
deploying
your
first
application
to
that
cluster.
It
also
provides
some
really
digestible
information
about
the
basic
kubernetes
architecture.
A
One
of
the
best
introductory
texts-
I've
also
seen
it's
been
around
for
a
couple
years-
is
written
by
matt
fletcher
of
deus
a
couple
years
ago.
It's
super
accessible
and
it's
called
the
Illustrated
guide
to
cooper
Nettie's,
it's
an
article
in
the
form
of
a
children's
book.
It's
about
a
ten-minute
read,
but
if
you
don't
like
reading,
there's
also
a
youtube
version
version
for
those
of
you
who
don't
hate,
reading
and
like
it
enough
to
read
a
whole
book
kubernetes
up
and
running
by
Kelsey,
Hightower,
Brendan,
Burns
and
Joe.
A
Betta
is
a
really
comprehensive
and
mostly
accessible
resource.
Personally
I
would
start
with
other
resources
first,
but
when
you're
ready
for
a
deeper
dive.
This
is
the
book
I'd
recommend
we
do
have
a
few
of
them
over
at
the
buthe,
so
stop
by
and
grab
one
we'd
be
more
than
happy
to
give
you
a
the
first
few
chapters-
and
this
is
a
slight
tangent.
This
is
an
actually
documentation,
but
Joe
also
does
TGI
K
every
Friday,
which
is
sort
of
like
a
Reading
Rainbow
for
kubernetes.
A
It's
pretty
awesome
and
he's
done
over
30
of
them,
they're,
not
exactly
sequential,
but
the
first
five
or
so
are
really
really
good.
Introductory
overviews
of
a
lot
of
kubernetes
concepts,
so
another
great
I'll
be
a
more
expensive
route,
is
to
do
a
formal
training,
or
course,
generally
speaking,
if
your
company
pays
for
conferences
like
this
or
continuing
education,
they'll
pay
for
training
and
you'll
get
a
lot
of
value
out
of
it.
So
the
price
tag
might
be
shocking
to
an
individual,
but
it's
less
shocking
to
a
company.
A
The
Linux
Foundation
itself
offers
a
kubernetes
fundamental
training
course
that's
online
and
self-paced,
and
you
can
also
take
the
certified
kubernetes
administrator
exam.
Afterwards
you
buy
them
both
for
500
bucks.
You
save
$100
a
few
of
my
colleagues
have
done
both
of
them
and
they
say
the
courses
per
to
the
exam
is
pretty
tough.
So
if
it's
available,
I
would
take
the
course
first
self-paced,
but
they
say
it
takes
about
15
to
20
hours.
Another
option
is
hep
TOS,
hands-on
workshop.
A
So
if
you're
feeling
inspired
after
this
conference,
you
should
sign
up
the
course
is
two
days
long,
one
four
hour
session
each
day
and
normally
it's
900
bucks,
but
the
education
team
has
generally
offered
a
coupon
code
which
brings
the
cost
down
to
four
hundred
dollars
and
it's
good
for
the
next
60
days.
This
is
the
code.
It's
on
the
slides.
If
you
are
all
at
all
interested,
this
is
a
great
deal.
A
I
would
take
it
so
once
you've
kind
of
gotten
your
head
straight
and
you're
ready
to
get
dirty,
you
really
do
need
to
set
up
a
cluster
I
think
it's
the
easiest
way
to
get
a
sense
of
what's
actually
going
on.
There
are
a
lot
of
options
for
this
and
I'll.
Just
talk
about
a
few
of
them,
but
for
your
first
cluster
I
would
recommend
mini
cube.
Mini
cube
is
a
super
cool
tool
and
it
runs
kubernetes
locally.
A
It
runs
a
single
node
kubernetes
cluster
inside
a
VM
on
your
machine
and
it's
ideal
for
getting
started.
A
lot
of
developers
use
it
long
for
development
environments
as
well.
There
also
are
some
web-based
environments
which
are
great
for
just
kicking
the
tires.
I,
don't
recommend
using
them
long
term,
once
you're
ready
to
do
more
than
kick
the
tires.
I
would
switch
to
mini
cube.
A
You
quite
literally
just
click,
create
cluster
in
the
cloud
console
and
then
there's
a
lot
of
documentation
about
getting
your
cluster
set
up,
getting
your
application
deployed
and
exposing
the
application,
the
Internet
via
service.
Second,
to
that,
I
would
recommend
hate
have
to
use
AWS
QuickStart
cluster.
It's
also
super
simple
to
setup
and
if
you're
familiar
with
AWS
more
than
G
cloud-
or
you
already
have
an
AWS
account,
you
might
find
it
easier
than
a
GK
cluster.
A
Whichever
you
choose
just
remember
that
cloud
providers
are
not
free,
but
the
other
two
options
are
so
my
final
piece
of
advice
for
both
people
who
are
new
to
kubernetes
and
also
the
more
seasoned
experts
in
the
house,
one
of
the
most
valuable
learning
tools,
someone
who
is
new
to
kubernetes
and
new
to
distributed
systems
in
general,
has
are
your
war
stories.
People
new
to
the
industry
have
not
necessarily
experienced
these
large
production
grade
deployment
debacles
and
if
we
don't
know
those
pains,
it's
really
hard
to
appreciate
how
kubernetes
eases
them.
A
So
if
you
find,
if
you're
a
systems
engineer
or
just
generally,
a
human
who
knows
a
bit
about
kubernetes
and
you
find
yourself
in
a
position
to
help
out
or
mentor
someone
new
to
kubernetes,
these
are
a
few
things
that
keep
in
mind.
First,
don't
assume
core,
not
knowledge
of
core
CS
principles.
More
people
are
entering
the
field
from
diverse
backgrounds,
myself
included,
and
they
don't
teach
me
much
about
hardware
and
networking
in
the
poly
SCI
department.
Meeting
people
where
they're
at
is
super
important.
A
If
we're
going
to
continue
to
grow
the
size
of
the
community,
expanding
them
out
a
little
bit.
One
thing
that
may
not
be
clear
to
people
who
just
got
started
are
the
differences
between
patterns
and
systems,
but
standard
patterns
and
distributed
systems
and
what
is
unique
to
kubernetes
some
of
the
core
principles
and
kubernetes
might
be
old
hat
to
people
who
have
been
in
distributed
systems
forever,
but
to
those
of
us
just
entering
the
space
they're
brand-new,
so
being
able
to
distinguish
between
the
two
is
super
super
helpful.
A
A
So
this
quote
was
referencing
the
nodejs
community,
but
I
think
the
same
holds
true
for
any
growing
community
explosive
growth
means
a
huge
portion
of
the
community
is
new,
so
education,
onboarding
and
culture
welcoming
of
newcomers
is
essential
to
doing
the
work.
Kubernetes
is
growing
explosively.
There's
no
doubt
about
that.
There
are
over
4,000
of
us
in
Denmark
right
now
talking
about
it
and
because
of
that
we
have
to
prioritize
welcoming
onboarding
and
welcoming
and
onboarding
new
members
of
the
community.
A
So
if
we're
going
to
grow
this
community
10x,
we
just
have
to
diligently
support
new
kubernetes
users
and
operators.
All
right
so
I
could
go
on
forever
about
all
of
the
resources.
I
found
helpful
when
I
was
starting
out
and
if
you
are
in
that
same
position
right
now,
please
come
tap
me
on
the
shoulder
later.
I'm
more
than
happy
to
go
more
in
depth,
but
now
that
we've
gone
over
how
product
team
can
get
equipped
with
the
new,
with
enough
kubernetes
knowledge
to
understand
a
problem
space.
A
A
We
just
talked
a
lot
about
all
of
the
reasons.
Kubernetes
can
be
unapproachable
and
we
have
the
potential
to
build
apps
that
ameliorate
a
lot
of
that,
for
instance,
a
UI
could
guide
you
through
spitting
up
a
class
creating
your
first
pods,
creating
a
deployment.
So
you
can
focus
on
understanding
what
these
resources
are,
rather
than
trying
to
figure
out
why
what
cute
config
file
are
using
or
where
the
yanil
indentation
is
off
or
oh
wait,
I
needed
to
create
the
namespace
first.
A
A
So
when
you're
brand
new
to
a
system
or
an
application,
a
CLI
or
a
config
file
can
be
a
pretty
intimidating
entry
point.
If
you
don't
yet
have
a
handle
on
how
a
system
works
or
what
it
does.
It's
helpful
to
have
graphical
clues
as
to
what
is
going
on.
This
is
especially
true
with
systems
engineering
and
kubernetes.
When
you
have
an
enormous
and
enormous
leaf,
flexible
API,
like
kubernetes,
everything
becomes
configurable,
which
means
there
are
lots
and
lots
of
knobs.
A
You
could
tweak,
but
that
doesn't
necessarily
mean
you
should
or
you
would
want
to,
and
you
guys
can
provide
a
way
to
surface
those
knobs
in
a
way
they
can
surface
the
knobs
that
need
to
be
exposed
right
off
the
bat
and
only
those
knobs
and
display
them
in
a
such
a
way
that
they're
possible
by
more
naive
operators.
If
we
provide
sensible
defaults,
we
can
obfuscate
some
of
the
complexity
initially
and
expose
these
knobs
further
down
the
line.
A
A
So
speaking
of
providing
sensible
defaults,
I
just
wanted
to
tell
a
story
about
when
I
first
started
hep
to
you,
I
asked
him
st.
Claire
who's
in
the
room
and
what
he
thought
we
should
be
building
and
God
blessed
him.
He
has
helped
me
so
much
in
the
past
year
and
he's
taught
me
a
lot,
including
to
not
listen
to
him
on
what
he
thinks.
A
We
should
build
for
UI
what
he
described
as
a
dashboard
that
exposed
every
possible
configuration
option
and
just
to
put
that
in
perspective,
the
cube,
API
server,
CLI
alone
has
a
hundred
and
nine
flags
cube.
Controller
manager
has
80,
cubelet
has
126
building
a
UI
with
that
kind
of
customization,
isn't
gonna
help
anyone
even
the
Tim
st.
Clair's
of
the
world.
However,
building
a
UI
that
surfaces,
those
knobs
that
need
to
be
exposed
off
the
bat
and
only
those
knobs
is
actually
really
useful.
A
So
to
that
end,
I
think
it's
important
to
point
out
that,
just
because
you
guys
can
be
helpful
doesn't
mean
that
they
are
the
solution
for
everything.
There
are
a
lot
of
things
they
do
well,
but
there
are
a
lot
of
things
see.
Allies
do
well
and
a
lot
of
things.
Config
files
do
well
so,
if
you're
familiar
with
the
system-
and
you
want
to
quickly
go
and
do
something-
a
CLI
is
likely
the
tool
you're
gonna
reach
for,
for
instance,
using
a
TOS
or
G
cloud,
they're
good
examples
of
that
hybrid
experience.
A
Most
people
use
both
aedui
and
the
CLI,
for
instance,
if
I
want
to
quickly
check
with
the
most
recent
image
tag.
I
pushed
up
to
my
google
container
registry
is
I'm.
Just
gonna
go
look
at
the
UI
and
check
the
tag
at
the
top
of
the
list,
but
I
didn't
push
that
image
to
the
registry
using
the
UI
and
the
same
principle
holds
truth:
config
files.
There
are
things
they
just
do
better
with
you
than
you
eyes.
A
If
you
have
people
constantly
fiddling
with
settings
in
a
UI,
there's
no
centralized
place
to
see
what
configure
what
configurations
exist,
what's
changed
or
when
something
broke,
but
for
initial
configurations,
especially
for
new
users,
you
guys
can
be
really
helpful.
Ultimately,
you
probably
want
your
config
file
in
version
control,
though,
because
I
might
set
up
my
initial
Jenkins
configuration
in
the
UI
to
make
sure
everything
works,
the
long
term
I'd
much
much
rather
rely
on
a
jenkins
file.
A
A
So
this
is
a
super
super
simple
visualization
I
built
when
I
was
starting
hep-2
about
a
year
ago,
I
originally
forked
it
from
a
kubernetes
UI
project,
topology
graph
and
changed
the
data
structure
a
bit
and
added
on.
So
this
is
directly
data
from
my
cluster
when
I
was
first
learning
kubernetes
last
year.
So
it's
simple
and
small
and
easy
enough
to
grok.
A
What's
going
on
and
I
was
also
already
familiar
with
the
resources
that
existed
because
I
created
them
and
I'm
not
saying
this
is
a
perfect
groundbreaking
visualization,
but
having
something
like
this
made,
Kate's
feel
more
tangible
to
me
being
able
to
see
the
relationship
between
services
and
pods
between
pods
and
containers
between
pods
and
nodes.
Help
me
start
putting
the
pieces
together
in
a
way
that
I
could
make
sense
of
in
the
same
visualization.
I
also
built
just
this
little
slider,
which
had
additional
information
about
each
resource.
A
Being
able
to
see
this
information
in
a
format
other
than
a
mole
is
what,
when
you're
starting
out
is
immensely
helpful
when
you're
first
starting
out
using
kate's,
you
don't
even
really
know
what
to
look
for
so
surfacing
the
data.
Even
if
it's
just
a
table.
This
is
nothing
fancy.
It
makes
it
more
clear
what
attributes
different
resources
have
and
which
ones
are
immediately
important,
and
one
thing
in
particular
liked
Cod
here
is
the
CLI
box
in
the
bottom
right
like
we
were
talking
about
earlier,
C
lies
and
you
guys
can
work
together.
A
I
wouldn't
expect
someone
to
visit
this
visualization
every
single
day.
I,
probably
wouldn't
expect
them
to
go
back
to
it
after
they
understood
what
was
going
on,
but
I
would
expect
them
to
use
the
cube
petal
CLI
every
day,
once
they
were
an
operator
or
using
kubernetes
and
so
giving
them
little
hints
on
what
that's
going
to
look
like
I
think
is
a
really
useful
tool.
That
was
a
really
useful
way.
A
You
can
use
you
eyes,
so
not
all
data
needs
fancy,
visualizations,
most
probably
doesn't,
but
the
data
formats
we
use
whether
they're,
gamal
or
JSON
or
XML,
or
any
other
number
of
formats
or
designed
for
computers
not
for
humans.
So
providing
a
simple
way
to
make
this
data
easier.
To
understand
and
take
action
is
one
of
the
core
benefits
of
a
UI
which
brings
us
to
our
work
on
sana
buoy
scanner.
A
For
a
little
background
to
the
CNC
F
defined
a
suite
of
conformance
tests
to
ensure
no
matter
how
you
set
up
your
cluster
it's
configured
properly
and
supports
the
required
kubernetes
api.
There
are
many
many
ways
to
spin
up
a
cluster.
It
could
be
installed
by
one
of
a
dozen
vendors
delivered
by
a
containers
as
a
service
offering
or
simply
created
from
the
upstream
binaries,
regardless
of
how
the
cluster
is
created.
The
obvious
questions
come
to
mind.
A
Does
this
cluster
work
as
it
should
like
did
I
mess
this
thing
up
so
hefty
asana
bui
is
an
open
source
diagnostic
tool
that
answers
that
question.
But
after
we
launched
it,
we
had
two
really
helpful
pieces
of
feedback
from
the
community.
People
weren't
sure
how
to
run
this
thing
and
they
weren't
sure
how
to
make
sense
of
the
output.
A
So
just
for
reference,
let's
run
through
the
first,
you,
the
sauna
boys
CLI.
When
you
first
start,
you
have
to
make
sure
you
have
golang
installed.
You
have
to
then
configure
your
go
path.
You
have
to
download
Sona
books
lot
away
with
a
go,
get
you
have
to
run
sauna
blue
run,
wait
for
the
tests,
wait
for
the
tests
to
finish
and
then
do
a
sauna
boy
retrieve,
which
downloads
a
tarball
snapshot
in
your
local
directory.
A
Then
you
extract
the
contents
into
a
dot
results
folder
with
this
command,
and
only
then
do
you
get
to
this
results
directory.
Where,
when
you
poke
around
through
several
nested
directories,
you
find
you're
conformance
test
results
which
live
in
a
file
called
J
unit,
underscore
zero
one
XML,
and
when
you
open
that
file
you'll
find
two
thousand
lines
of
XML,
and
please
don't
get
me
wrong
here.
This
is
an
enormous
lis,
valuable
tool
and
enormous
ly.
A
A
Scanner
is
a
really
really
simple
web
UI
and
it
makes
running
sana,
be
easy
and
viewing
its
results
more
understandable
and
more
actionable
to
run
scanner.
You
just
go
to
scanner,
dot,
hefty
or
com
copy
and
paste
the
generated,
cube,
cuddle
command
and
your
terminal
and
apply
the
yellow.
This
will
install
sauna
buoy
and
run
the
conformance
test
and
when
it's
all
done,
it'll
clean
up
after
itself.
A
Once
the
tests
have
finished
running,
you
can
easily
see
if
any
of
the
tests
have
failed
and
then
drill
down
into
the
logs
troubleshoot
and
rerun
scanner
to
make
sure
your
cluster
is
now
properly
configured.
Overall,
it's
just
a
much
cleaner
experience
than
the
sauna
Bui
CLI,
especially
for
new
users.
A
We
also
built
scanner
because
we
wanted
something
that
quickly
and
clearly
demonstrated
sonobuoys
value.
If
you
go
immediately
to
the
sauna
Bui
repo,
it's
not
necessarily
immediate,
clear,
immediately
clear
what
you're
going
to
get
with
scanner.
We
wanted
to
be
dead,
simple,
to
run
and
super
obvious
what
you
would
get
when
you
ran
these
tests.
So
we
may
not
rely
on
you
eyes
for
our
day-to-day
use
or
operations
of
kubernetes,
but
they
are
an
excellent
way
to
immediately
show
the
value
of
a
product.
A
If
you
build
an
intuitive
and
useful
UI,
it
can
function
as
an
entry
point
for
a
product.
That's
comprised
of
more
than
just
a
webapp
scanner
is
a
great
example
of
that
people
who
have
never
tested
their
cluster
for
conformance
before
and
maybe
didn't
know
what
the
see
ins
conformance
test
suite
was,
can
quickly,
learn
about
it
and
then
run
them
and
do
and
have
actual
insights
to
fix
their
cluster
if
they
need
to
with
very
little
overhead,
so
to
wrap
up.
A
I
just
have
an
anecdote
from
earlier
this
week
on
Tuesday
I
sat
in
on
the
hefty
Oh
hands-on
workshop
that
we
had
here.
It's
the
same
one.
We
offer
online
and
helped
kept
us
VP
of
Finance
Janice
throughout
the
course
Janice
has
never
written
a
line
of
code
in
her
life,
but
throughout
the
process
of
docker
izing,
an
app
spinning
up
a
cluster
on
gke,
deploying
a
couple
of
containers
to
the
cluster
and
exposing
a
service.
The
issue
she
ran
into
didn't
have
anything
to
do
with
the
lack
of
understanding.
A
She
really
did
a
great
job,
almost
every
single
issue
she
ran
into
had
to
do
with
the
yeah
mold
being
indented
incorrectly
or
a
resource
having
the
wrong
capitalization
or
her
docker
file
being
ever
so
slightly
off.
These
shouldn't
be
problems,
beginners
have
to
deal
with,
but
they
are.
These
are
things
we
constantly
see
new
users
running
into
in
the
field.
This
is
a
wall.
They
almost
always
always
hit.
A
Imagine
if,
instead
of
having
to
spend
time
explaining
that
yeah
mole
is
a
super
set
of
job
of
a
sauna
and
here's
a
list
inside
of
a
map
and
oh
yeah-
don't
worry
about
the
just
use
it
you
have
to
you
have
all
of
that
for
free.
This
frees
up
not
an
insignificant
amount
of
time
to
actually
understand,
what's
going
on
with
kubernetes,
rather
than
fighting
with
the
config
files
and
to
be
clear
here,
I'm
not
advocating
for
a
complete
obfuscation
of
complexity.
It's
important
to
understand.
A
What's
going
on
beneath
the
hood
of
a
tool
we
use,
but
it's
much
easier
to
grok.
If
we
can
peel
an
onion
layer
by
layer
which
is
something
we
can
lean
on
you
eyes
to
do
rather
than
just
hand
the
thing
to
someone
and
say
go
so
at
the
end
of
the
day,
kubernetes
itself
should
be
pretty
boring,
and
it's
just
not
yet
we
can
add.
We
can
and
should
be
building
products
that
make
that
a
reality.
So
we
can
focus
on
more
interesting
problems.
A
A
A
B
I'm
I
really
enjoyed
your
talk
and
I.
Think
I
found
myself
wondering
when
you
started
learning
about
kubernetes.
Did
you
did
you
go
down
some
rabbit
holes
of
stuff
that
ended
up
not
being
as
important
to
you?
Can
you
address
a
little
bit
like
when
people
are
learning?
What
direction
should
you
if
you're
guiding
them?
Should
you
direct
them
away
from
because
it
isn't
going
to
be
as
useful
yeah.
A
One
of
the
things
are,
one
of
the
traps
I
fell
into
was
trying
to
just
read
the
documentation
straight
through,
which
was
not
very
useful.
Uh-Huh
I
was
like:
where
can
I
find
the
most
central
eyes,
information
about
everything,
kubernetes
and
the
kubernetes
documentation
is
really
really
useful
as
an
aggregate
when
you're
actually
interacting
with
kubernetes,
but
to
just
read
it
straight
through
it's
just
information
overload.