►
From YouTube: Keynote: Scaling Kubernetes: How do we grow the *Kubernetes* user base by 10x? - Joe Beda
Description
Keynote: Scaling Kubernetes: How do we grow the *Kubernetes* user base by 10x? - Joe Beda, CTO, Heptio
Kubernetes is great. We wouldn't be here otherwise. But Kubernetes also requires too much cognitive overhead for many users that just want to get things done.
In this talk we lay out a roadmap and start a discussion about fundamentally expanding the appeal and user base of Kubernetes. How can we grow the number of users by 10x over the next year?
We look at this from multiple angles: cluster operators vs cluster users, large cluster and small clusters, enterprise developers and small independent people, experienced vs new technologists, fundamental simplifications vs sanding rough edges.
About Joe Beda
CTO, Heptio Inc
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
Hello
I'm
excited
to
be
talking
today
about
scaling
kubernetes
most
of
the
time
when
we
talk
about
scaling,
kubernetes
we're
talking
about
going
to
5,000
nodes
or
auto-scaling
or
that
type
of
thing,
but
I'm
talking
about
something
different.
How
can
we
scale
our
user
base?
How
can
we
bring
kubernetes
not
just
to
everybody
in
this
room,
but
all
the
people
who
aren't
in
this
room?
A
We
have
to
actually
take
a
really
hard
look
at
the
places
where
we
can
do
better
now.
Qube
Khan
is
a
place
to
celebrate
kubernetes,
it's
a
place
to
celebrate
all
the
progress
that
we
made
and
it's
a
place
to
really
be
re-energized.
Come
away
with
new
ideas
and
meet
folks
that
you
know,
perhaps
we've
only
met
online,
and
so
that's
all
wonderful
I
don't
want
to
take
away
from
that.
A
But
again
we
have
to
take
a
really
hard
look
at
where
we're
at
if
we're
gonna
improve
and
continue
on
the
trajectory
that
we're
on
so
this
throughout
this
presentation,
we'll
be
making
really
bad
physics.
Analogies.
The
last
physics
class
that
I
took
was
about
20
years
ago,
so
I'm
sure
I'm
gonna
get
stuff
wrong.
Please
bear
with
me.
A
This
is
about
vacuum
because
see
sucking
and
vacuum
tubes,
and
so
this
is
an
animation
of
this
computer
in
the
British
National
Museum
of
computing
in
Bletchley
Park
outside
of
London,
it's
a
thing
called
the
which-
and
these
things
are
a
special
type
of
vacuum-
tube
called
a
Decca
Tron.
That
knows
how
to
count
to
10.
So
it's
a
really
cool
place.
I
recommend
you
go
there
if
you
ever
get
the
chance.
A
A
So
this
is
a
humpback
whale
and
they
have
this
thing
called
a
baleen
which
is
a
filter,
so
they
suck
in
a
whole
bunch
of
water
with
krill,
and
then
they
push
the
water
out
and
and
that
thing
acts
as
a
sieve
to
actually
keep
the
yummy
bits
inside
so
that
they
can
swallow
it.
And
so
we
can't
be
like
the
whale
here
and
we
have
to
actually
recognize
that
we
have
to
look
beyond
our
our
immediate
peers
and
and
what
we
need
out
of
kubernetes.
A
Now,
let's
talk
about
refraction
so
refraction
is,
is
the
interface
between
materials
that
causes
light
to
bend,
and
the
analogy
here
is
really
one
of
you
points.
There
are
different
people
bring
different
viewpoints
and
look
at
kubernetes
through
different
lenses.
I
could
put
a
picture
of
an
elephant
up
here,
also
and
touching
different
parts
of
an
elephant
that
type
of
thing
and
I
think
there's
two
main
users
or
hats
that
people
wear
when
they're,
actually
using
kubernetes
and
you'll,
see
this
reflected
in
the
talks
here
today.
A
The
there's
the
cluster
operator,
the
folks
who
are
really
interested
in
getting
a
cluster
up
and
running
and
making
sure
that
it
runs
well
and
that's
a
hat
that
folks
wear
and
then
there's
the
cluster
user
and
the
cluster
user
is
interested
in
okay.
Now
that
I
have
a
cluster,
how
do
I
get
the
most
out
of
it
and
it's
easy
when
you're
working
with
these
things
day
in
and
day
out,
to
really
blur
the
lines
between
those
things.
A
But
we
have
to
make
sure
that
we
can
build
the
right
experiences
when
people
are
wearing
those
different
hats
and
that
we
can
create
a
world
where
people
who
have
no
idea
how
kubernetes
works
under
the
covers
can
be
successful.
I,
don't
think
we're
quite
there
yet,
but
I
think
we
have
where
we're
on
our
way
for
sure
now
we
can't
over
fit
to
that.
A
There's
this
idea
in
UX
design
called
personas
where
you
sort
of
make
up
a
person,
you
give
them
a
name,
you
give
them
a
backstory
and
it
really
helps
to
create
user
empathy.
One
of
the
failure
modes
in
my
mind
for
that
type
of
model,
is
that
you
tend
to
create
siloed
experior
that
are
so
separates
that
learnings
in
one
space
don't
transfer
over
to
the
other.
So
we
really
need
to
balance
this
stuff
out.
A
So
this
image
here
is
on
the
cover
of
my
error
analysis
book
when
I
was
in
college
about
20
years
ago,
and
still,
if
you
do
error,
if
you
type
error
analysis
book
into
Google,
you'll
still
see
this
photo.
This
is
an
accident
that
happened
in
1895
in
Paris,
where
a
train
was
coming
into
a
station
over
and
the
station
and
fell
onto
the
street
below
it
turned
out
that
the
station
was
on
the
second
floor
and
for
me
this
represents
the
spectrum
from
mathematics
to
physics
and
even
within
physics.
A
There's
Theory
there
there's
a
lot
of
really
interesting
problems
in
terms
of
how
do
we
actually
scale
to
five
thousand
machines?
How
do
we
actually
do
control
loops
and
control
theory
lot
of
really
interesting
stuff
there
and
then
there's
folks
who
just
want
to
get
some
stuff
done
right,
and
we
have
to
recognize
that
not
everybody
wants
to
or
needs
to
care
about
those
core
distributed
systems,
because
they're
really
focused
on
accomplishing
some
sort
of
task,
and
a
flip
side
of
this
is
recognizing
that,
just
because
somebody
doesn't
care
about
these
hard
core
distributed
systems.
A
Problems
doesn't
mean
that
they're
not
as
smart
as
the
people
who
are
working
on
those
types
of
things.
It
just
means
that
they're
concerned
with
other
stuff
right
and-
and
this
is
part
of
that
view,
points
of
different
people
are
bringing
different
viewpoints
to
the
game
and
we
have
to.
We
have
to
build
empathy
and
respect
the
fact
that
not
everybody
is
system
geeks
like
us,
so
the
the
physical
world
naturally
over
time
tends
towards
disorder.
A
This
is
the
second
law
of
thermodynamics
and
the
same
thing
happens
with
open
source
projects
given
time
they
sort
of
grow
and
and
end
up
swallowing
more
and
more
and
more
and
more,
and
it's
something
that
we
have
to
keep
an
eye
out
for
with
kubernetes.
The
truth
of
the
matter
is:
is
that
for
most
users,
the
primitives
that
we
had
two
or
three
versions
ago
are
probably
good
enough.
A
It
doesn't
mean
that
we
shouldn't
be
doing
that
stuff,
but
we
should
also
recognize
that
every
new
object
that
we
add
to
the
system,
every
new
concept,
creates
barriers
for
new
users
and
creates
confusion,
and
so
we
need
to
find
a
way
to
segment
this
so
that
we
actually
can
present
a
more
approachable
face
to
the
world
and
folks
can
actually
start
recognizing
and
using
those
features
as
they
need
them.
Instead
of
being
forced
to
confront
all
that
complexity.
Out
of
the
gate.
A
A
I
think
you
know
there's
some
warts
and
some
stuff
that
I
would
change.
But
if
you
look
at
the
kubernetes
api
the
way
we
do
labels
the
way
that
we
handle
metadata
the
the
spec
versus
status
bifurcation,
the
way
we
do
controller
loops,
all
that
stuff
I
think
really
resonates
and
really
helps
people
to
understand.
One
part
of
the
system
then
apply
it
elsewhere,
there's
also
places
where
we're
not
doing
quite
as
well.
A
If
you
look
at
cube
control,
you
can
run
it
in
two
modes,
sort
of
this
declarative
mode
versus
this
imperative
mode
and
there's
a
sort
of
Venn
diagram
set
of
features
that
are
available
to
each
of
those
things.
So
we
really
put
users
and
in
a
inconvenient
position
of
having
to
choose
between
one
model
and
the
next,
for
example.
A
Cube
control
run
supports
this
way
of
essentially
attaching
to
it
like
you
feel
like
your
SSH
into
the
into
the
container,
and
it
supports
an
auto
remove
feature
so
that
when
the
the
process
ends
will
automatically
delete
it
and
clean
up
after
itself,
you
can't
get
that
when
you're
actually
doing
a
cube,
control
create
and
there's
no
way
to
actually
get
that
behavior
elsewise.
Meanwhile,
with
cube
control,
run
it's
very
difficult
to
be
able
to
do
a
cube
control
run
and
attach
a
volume
to
it
right.
A
So
there
are
times
when
you
have
to
go
the
opposite
direction
from
this
sort
of
like
simple
fundamental
beauty
of
physics
and
in
my
mind
the
opposite
of
physics
is
really
biology
right.
There's
this
amazing
amount
of
diversity.
These
are
our
Mendel's
peas,
the
father
of
genetics
and
and
what
I'm
trying
to
get
across
here
is
that
we
have
to
recognize
that
as
we
try
and
reach
these
new
audiences
of
developers
and
users
of
kubernetes,
we
have
to
build
experience
that
resonate
with
them.
So
let's
take
front-end
developers,
for
example.
A
The
typical
front-end
developer
flow
is
that
you
have
your
browser
in
one
window.
You
have
your
editor
in
one
window
you
hit
save
and
the
browser
automatically
updates.
You
don't
even
have
to
reload
it
right.
This
is
sort
of
state
of
the
art
how
folks
use
and
work
with
this
stuff.
How
does
that
translate
into
a
world
where
maybe
your
back-end
is
written
in
kubernetes?
A
Maybe
you
want
to
start
working
that
way,
but
you
want
to
easily
transition
from
that
mode
to
being
able
to
deploy
things
right
now,
there's
a
very,
very
abrupt
translation
as
you
move
from
that
development
experience
to
that
deployment
experience.
So
let's
get
a
you
know
creative
about
thinking
about
how
we
can
solve
some
of
those
problems
and
start
blurring
those
lines,
so
the
we
can
create
an
experience
that
feels
more
natural
to
that
type
of
user.
A
Now
this
is
where
the
rubber
meets
the
road.
Okay,
that's
a
really
bad
joke.
I'm,
sorry,
so
a
big
part
about
getting
new
users
on
board
is
removing
friction
and-
and
so
there's
two-
you
know
at
least
two
types
of
friction
that
I
think
relate
here:
there's
static,
friction
and
kinetic,
friction
and
so
static.
A
Friction
is
the
amount
of
force
that
it
takes
to
start
something
moving
kinetic
friction
is
the
amount
of
force
that
it
takes
to
keep
it
moving,
and
so
the
analogy
here
for
kubernetes
is
really
that
there
is
a
certain
amount
of
mental
friction.
This
is
you
know.
It
just
feels
like
work
to
get
started
with
kubernetes
for
the
closer
administrators.
A
There's
a
gazillion
different
ways
to
actually
bring
up
kubernetes
picking
one
of
those
in
and
of
itself
creates
a
ton
of
friction
for
users
like
I
mentioned
earlier,
there's
just
so
many
concepts
to
wrap
your
head
around
and
we
really
don't
do
a
good
job
of
actually
providing
a
simpler
way
to
get
in
and
then
there's
a
lot
of
rough
edges
that
we
need
to
sand
off.
There's
and
you
know,
and
I'm
just
gonna
give
you
a
couple
examples
here
and
I'm.
A
Looking
at
my
notes
here,
so
okay,
so
the
first
thing
here
is:
let's
take
talk,
events
write
events
are
only
available
when
you
do
like
a
Q
control
describe
and
they
give
you
some
of
the
recent
things
that
happen
to
a
particular
object.
They're
incomplete
they
get
G
seed
and
it's
almost
impossible
to
actually
get
events
for
objects
that
have
been
deleted.
Right
I
mean
they're
there,
but
it's
very
difficult
to
filter
for
that,
not
the
end
of
the
world
right,
but
it's
just
a
piece
of
friction.
A
Okay,
so
let's
say
that
you
launch
a
pod
and
it
fails
to
launch
and
you
do
a
describe
and
you
get
an
error
that
says:
failed
sync:
error
sinking
pod,
so
this
is
an
actual
error.
I
haven't
I,
haven't
hit
it
in
1.5
I
mean
I
tested
in
1.5.
I
haven't
tried
this
yet
in
1.6.
Does
anybody
know
what
this
error
means?
No,
this
means
that
you
forgot
to
actually
specify
a
command
on
your
container
image.
Yeah.
That's
that's!
Not
a
great
experience.
A
Cube
control
logs.
It
turns
out
that
when
you
do
a
run
and
we
encourage
everybody
to
think
in
terms
of
replica
sets
and
deployments,
but
when
you
want
to
go
ahead
and
get
logs
logs
only
work
on
pods,
and
so
you
have
to
do
this
dance
where
you
have
to
actually
go
through
and
list
the
pods
and,
like
you
know,
look
at
the
name
and
actually
say
I.
A
Think
that's
the
one
that
maps
to
this
deployment
copy
and
paste
that
in
the
command
line
to
cube
control
logs
and
then
you
can
actually
see
what
the
hell's
going
on.
None
of
these
things
are
awful.
None
of
them
are
gonna
block.
You
there's
just
gonna
slow
you
down,
and
it
makes
the
fist
system
feel
sort
of
slow
and
rough
around
the
edges
and
I
believe
there's
issues
for
all
of
these.
A
So
you
know
Help
Wanted,
let's,
let's
solve
some
of
this
I
want
to
take
a
step
back
also,
and
a
lot
of
folks
build
businesses
around
removing
friction.
In
fact,
that
is
sort
of
the
the
one
of
the
things
that
startups
do
is
that
you
find
something
that
that
just
causes
this
friction
that
people
have
gotten
attune
to,
and
it
makes
it
easy
to
ignore
and
you
remove
that
in
exchange
for
money,
that's
great,
but
there's
also
a
danger
for
us
as
a
community.
With
respect
to
this.
A
If
people
solve
these
issues
from
the
outside,
instead
of
fixing
fundamental
issues
and
the
issues
in
the
product,
then
they're
essentially
building
businesses
that
are
predicated
on
kubernetes,
sucking
and
over
the
long
term.
That
means
that
nobody
is
going
to
be
incentivizing
to
actually
move
the
project
itself
forward.
So
we
need
to
balance
this
idea
of
solving
problems
on
top
and
of
and
above
kubernetes,
but
not
at
the
cost
of
inhibiting
ourselves
from
solving
core
problems
upstream.
A
A
So
accelerations
is
the
change
of
velocity
over
time
and
for
hundreds
of
years
this
stood.
It
was
wonderful.
It
meets
our
intuition
with
how
the
way
the
world
works,
but
it
turns
out
that
in
special
cases,
in
more
advanced
cases,
as
you
get
close
to
the
speed
of
light,
this
breaks
down
right.
And
so,
if
you
look
at
the
second
equation,
this
is
this:
is
the
Einsteinian
special
relativity
version
of
this
equation
and
what
you'll
notice
is
that
there's
that
that
square
root
of
1
minus
V,
squared
over
C
squared
that's
the
Lorentz
factor?
A
The
interesting
thing
about
that
is
that,
as
velocity
tends
towards
zero
compared
to
the
speed
of
light
that
whole
thing
reduces
down
to
one
and
disappears
right,
and
so
it's
not
like.
There's
this
code
over
point
where
you
move
from
the
the
Newton
view
of
the
world
to
the
Einstein
view
of
the
world.
It
just
means
that
gradually,
that
thing
becomes
more
important
important
as
you
actually
start
dealing
with
more
and
more
advanced
situations.
So
we
need
to
find
a
way.
So
that's
that
for
most
users
we
can
present
that
intuitional
view
of
the
world.
A
A
I
didn't
expect
to
see
see
that
in
the
box
when
I
opened
it-
and
you
know
like,
like
anything
else,
you
know
you
don't
know
your
if
your
clusters
alive
or
dead
until
you
look
at
it
and
an
observability
is
one
of
those
things
that
we
just
always
need
to
be
doing
better
with
I
mean
by
observability
and
really
I.
Think
this
is
a
term
that's
evolving.
To
encapsulate
logging
events
tracing
monitoring.
All
this
stuff
really
adds
together
in
terms
of
having
the
tools
to
see
what's
going
on
now.
A
So
much
of
the
thinking
and
the
efforts
has
been
going
into
application,
observability
right,
what's
happening
with
my
application,
that's
running
on
top
of
it,
and
you
know
great
projects
like
like
Prometheus
and
fluent
D
are
really
helping
out
there,
but
those
things
work
best
when
there
actually
work
with
the
application
right.
If
you
make
your
application
observable,
then
you
can
observe
it.
We
need
to
do
a
better
job
of
both
helping
to
bring
users
along
there,
and
you
know,
as
a
community,
but
also
in
terms
of
making
kubernetes
itself
more
observable.
A
We
could
easily
have
10
times
as
many
prometheus
metrics
thrown
off
by
the
system
to
be
able
to
figure
out
what
the
heck's
going
on.
If
you
look
at
our
event,
stream
I
mentioned
that
earlier,
it's
incomplete
we're
not
treating
it
as
a
real
API,
we're
not
providing
the
right
ways
to
be
able
to
capture
that
over
time
and
examine.
What's
going
on.
A
So
we
need
to
be
able
to
find
tools
such
that
when
users
do
need
to
look
under
the
covers
and
figure
out
what's
going
on,
which
is
something
that
I
think
users
and
I.
Think
a
lot
of
folks
in
this
room
do
appreciate
is
that
you
can
tear
a
cluster
apart
and
understand
what's
going
on,
but
when
you
do
that,
we
need
to
provide
you
the
right
tools
so
that
not
only
do
you
have
the
data
that
you
need,
but
you
actually
can
extract
signal
out
of
that
and
actually
figure
out
what's
going
on.
A
So
that's
a
bunch
of
ideas,
some
things
to
think
about
as
we
look
towards
what
is
it
going
to
take
to
take
kubernetes
to
the
next
level,
grow
our
user
base
by
10
times
and
and
really
inject
a
whole
new
level
of
energy
into
this
community
and
and
continue
on
the
velocity
that
we're
at
right
now.
So
thank
you
very
much
I
appreciate
your
time
and
feel
free
to
tweet
at
me.
If
you
have
any
questions
or
want
to
talk
about
this,
some
more.
Thank
you.