►
From YouTube: The Road to More Usable Kubernetes - Joe Beda, Heptio
Description
The Road to More Usable Kubernetes - Joe Beda, Heptio
At KubeCon EU, in Berlin, I got up on stage and stated that "Kubernetes Sucks (but all software sucks)". While we still have work to do, in the past several months the community has done great work to solve a whole host of issues to make Kubernetes “suck less.” In this talk I will outline the ways that the community has made this happen both in the core project and in the wider ecosystem.
Things are still developing, but here are the areas that I want to highlight. Hopefully we'll have talks on many of these so that I can highlight where and when folks can find out more. I won't be able to cover everything happening in the ecosystem but I can hint at the diversity and commitment to solving these issues.
* *Simpler application description.* As a community we are continuing to build more tcapable and simpler tools for describing applications through projects like ksonnet, OpenCompose, Kompose, and Helm.
* *Serverless platforms.* Through “function as a service” like systems we can abstract much of the nitty gritty around getting code packaged and running. In addition, scaling can be easy and automatic as code is run only when needed.
* *Simpler cluster install and admin.* kubeadm and how it is becoming a common toolkit. Similar work is ongoing to explore the idea of standardizing the description of a cluster at the infrastructure level through projects like Kubicorn. In addition, new APIs, such as the certificates API, are key building blocks for getting secure clusters up and running.
* *Curated development experiences.* Systems like Draft help to automate the build/launch/update cycle for development workflows. Others are also exploring ways to connect developers to clusters.
* *Making Kubernetes boring.* Kubernetes is maturing as a platform. As that happens, things in the "nucleus" are slowing down. In the past 6 months we've seen a concerted effort to encourage new features to be built with extensibility mechanisms as much as possible. This allows those projects to move fast while enabling exploration of the problem space.
* *Conformance.* Another key enabler for widespread Kubernetes adoption is conformance. There has been a wide set of folks involved in describing what should get to be called "Kubernetes". Tools like Sonobuoy point the direction to making this be an automated process that anyone can run against any cluster.
* *Observability.* Prometheus continues to be the go-to OSS solution for monitoring in the Kubernetes world. In additions, systems like linkerd and Istio/envoy enable introspection at the microservice mesh level.
We still have many challenges. Many of these are going to take long concerted efforts to fix. We are trapped, in some ways, by our promise of backward compatibility. It is often better to live with something annoying than to force breaking changes on our user base.
*Call to action:* Great job community! But the job isn't done. Let's keep working hard to bring Kubernetes to a larger and larger set of users and environments.
About Joe Beda
Joe Beda is CTO of Heptio, a startup focused on unleashing the technology driven enterprise. We aim to realize the full potential of Kubernetes and transform IT into a business accelerator. Prior to Heptio, Joe was at Google for over 10 years. While there, Joe started Google Compute Engine and co-founded the Kubernetes project. In a previous life, Joe started his career at Microsoft working on Internet Explorer. Joe is slowly becoming a Seattle native with his wife, a physician, and two kids.
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
My
name
is
Joe
Beda
I'm,
the
CTO
and
co-founder
of
hefty
Oh.
If
you
were
at
the
morning
keynotes,
you
saw
my
my
my
other
co-founder
Craig,
give
a
little
bit
of
the
business
case
of
where
he
sees
kubernetes
going
I'm
gonna
dig
into
some
of
the
details
on
what
can
we
do?
How
can
we
approach
making
kubernetes
a
more
usable
system
and
I'm
also
one
of
the
folks,
along
with
Craig,
that
started
kubernetes
back
at
Google
three
years
ago?
All
right,
so
why
do
I
care?
Why
do
I
want
to
make
kubernetes
more
usable?
A
It
turns
out
that
there's
this
trap
in
open-source
communities
where,
if
the
product
is
hard
to
use,
that's
a
great
opportunities
for
vendors
I'm.
You
know,
I
have
a
company
I
want
to
sell
some
stuff,
I
make
money,
exchange,
goods
and
services
for
monetary.
You
know
game
all
right,
so
kubernetes
being
hard
to
use
to
some
degree
creates
opportunities
for
me,
but
I
think
my
my
view
of
it
goes
beyond
that.
One
of
the
special
things
I
think
about
the
kubernetes
community.
A
A
A
You
have
to
take
a
sober
look
at
something
to
really
improve
it,
and
and
that's
some
of
what
I
want
to
do
here
and
that's
some
of
what
I
was
trying
to
get
at.
When
I
talked
about
all
software
sucking
and
kubernetes
being
software,
we
can't
believe
our
own
hype.
It's
really
easy
to
sort
of
get
up
on
stage.
Four
thousand
people,
pat
ourselves
on
the
back,
that's
great.
We
should
celebrate
how
far
our
community
has
come,
but
we
also
have
to
be
very
sober
about
how
far
we
have
to
go
yet
I
started.
A
My
career
at
Microsoft
I
was
at
Microsoft
for
seven
and
a
half
years.
I
lived
through
the
long
horn
days,
so
I
don't
know.
Does
anybody
in
the
audience
know
what
long
horn
was?
Do
you
remember
this
right?
So
it's
not
Texas
it's
a
bar
between
Whistler
and
Blackcomb,
and
in
a
classic
software
development
style.
A
A
Microsoft
got
stuck
in
that
bar
and
and
Longhorn
turned
into
Windows
Vista
and
the
psychology
of
being
inside
of
a
company
like
that,
where
you
think
everything's
going
great
there's
a
lot
of
good
people
doing
good
work
that
went
into
that,
but
the
end
result
was
something
that
was
was
disappointing
to
the
general
public.
We
can't
fall
into
that
trap
and
it's
not
just
Microsoft
that
falls
into
that
trap.
A
A
I
also
want
to
recognize
that
there's
some
caveats
there's
some
warning
signs
and
some
things
that
we
have
to
be
careful
of
as
we
do
this.
So
the
first
thing
is
that
these
personas
are
fractal
the
more
you
start.
Looking
at
the
type
of
use
case,
the
more
you
realize
that
their
sub
use
cases
underneath
that
and
and
you
can
really
get
lost
in
the
weeds
when
you
start
doing
that.
The
next
thing
is
that
nobody
is
average
right.
A
We
can
have
this
idea
of
the
average
person,
but
everybody
is
actually
you
know
in
some
ways
outside
of
the
norm.
There's
actually
a
great
99%,
invisible
podcast
on
this
that
talks
about
Air,
Force,
pilots
and
seating,
but
that
applies
here
also,
and
so
these
personas
are
sort
of
some
sort
of
Platonic
ideal
of
a
user
and
nobody
fits
into
those
things
cleanly
and
nobody
fits
into
those
things
cleanly
all
the
time
right.
A
So
so,
depending
on
what
job
you
have
to
do
on
a
day
to
day
basis,
you
may
find
yourself
shifting
between
these
different
types
of
personas.
So
to
sum
this
up
view
these
personas
as
guidelines,
but
not
guardrails.
We
really
want
to
make
sure
that
that
we
build
empathy
with
users.
We
understand
the
different
places
that
they're
coming
from,
but
we
don't
want
to
build
siloed
experiences
for
these
different
personas,
all
right.
A
So
here's
my
breakdown,
please
excuse
my
bad
handwriting
of
one
way
that
I've
been
thinking
about
breaking
down,
personas
and
there's
two
different
axes
that
I've
been
looking
at
operator
versus
developer,
cluster
and
services
versus
application,
and
if
we
do
that,
we
end
up
with
different
types
of
users
in
each
of
those
things
and
again.
This
is
an
imperfect
way
to
break
this
down.
There's
ways
to
actually
pick
this
apart,
but
for
me
this
has
been
a
useful
way
to
think
about
it.
A
Now,
when
you
start
looking
at
it
in
this
case,
I
think
it
starts
to
become
obvious
that
sometimes
these
different
needs
for
these
different
users
conflict
with
each
other
right.
There
gonna
be
some
users
that
want
the
super,
easy
to
use.
Press
one
button,
make
it
work,
type
of
thing
right
and
then
there's
going
to
be
other
users
who
really
want
to
understand
the
details
and
they
want
the
flexibility
and
they
want
to
be
able
to
adapt
it
to.
A
You
know
something
that's
very,
very
different
from
what
a
lot
of
other
users
are
doing,
and
this
is
a
problem
that
faces
anytime,
you're,
building
a
product
or
a
platform
for
a
wide
set
of
users,
and
it's
something
that
we
struggle
with
in
the
kubernetes
community.
Again
and
again,
there's
no
silver
bullet
here,
it's
hard.
A
So
let's
break
down
the
break
down
a
bit
cluster
versus
service,
a
cluster
and
service
versus
application.
In
my
mind,
the
difference
between
these
things
is
who
is
your
customer
when
you're
building
stuff
and
working
on
things
that
are
at
the
cluster
level,
your
customer
is
other
developers,
other
people
who
are
actually
software
developers
and
one
of
the
big
traps
here
is
that
you
think
that
those
folks
are
always
like
you,
I'm
gonna
developer,
your
developer.
Obviously
we
understand
each
other.
Well,
our
world
is
big
enough.
A
Now
that
that
doesn't
work
and
and
then,
when
we
look
at
developers
versus
operators.
This
again
is
a
spectrum.
I,
don't
think,
there's
any
clean
lines
here.
I
think
you
know,
the
whole
idea
of
DevOps
is
actually
to
get
across
that
there
are
not
clean
lines
here
and
you
shouldn't
create
strong
process
and
structure
around
that.
But
the
way
I
break
this
down
is
that
on
the
operator
end
of
the
spectrum,
a
lot
of
the
value
that
being
delivered
is
not
visible
to
users.
A
You're
worried
about
stability,
you're
worried
about
uptime,
it's
only
visible
to
users
when
you
fail
I,
think
there's
this.
You
know
famous
idea
that,
like
when
an
when
folks
on
that
operator,
hat
wearing
that
operator,
hat
people
only
notice
they're
there
when
things
go
down,
application
folks
are
on
the
other
side
of
the
spectrum.
I
mean
I'm.
Sorry
developer
folks
are
on
the
other
side
of
the
spectrum.
Those
are
people
who
are
focused
on
very
visible
end-user
value
right
features.
I
want
to
actually
get
this
new
thing
out.
A
There
I
want
to
enable
new
types
of
scenarios,
and
so
these
things
are
oftentimes
attention
and
that's
really
at
the
core
of
building
better
understanding
across
these
things.
When
people
talk
about
DevOps
all
right,
so
there's
another
overlay
here,
I
think
around
security
I'm
not
quite
sure
where
it
fits
in
this
particular
grid.
But
it's
something
that
is
very
important.
It's
a
separate
discipline.
It
needs
to
be
bound
into
the
rest
of
this.
A
Unfortunately,
I
don't
have
a
ton
of
time
to
dig
into
that
right
now
today,
but
I
don't
want
to
pretend
that
this
represents
all
the
different
concerns
that
folks
have
all
right,
so
cluster
and
service
ops.
So
this
has
been
so
much
of
what
we've
been
focused
on
up
until
now,
as
how
do
I
get
a
cluster
up
and
running
it's
it's
been
a
distraction.
A
Honestly
I
think
you
know
some
of
the
stuff
that
we've
been
seeing
in
the
keynotes
so
far
at
cube,
con
has
assumed
that
you
have
a
cluster
nobody's
spending
a
ton
of
time,
thinking
about
how
do
I
get
a
cluster
up
and
running
now
that
doesn't
mean
that
we're
done
with
this.
It
just
means
that
folks
are
starting
to
look
past.
This
particular
role
but
I
think
we're
not
done
because
I
think
cluster
is
is
getting
kubernetes
up
and
running,
but
as
we
expand
the
ecosystem.
A
This
role
also
includes
all
the
different
ways
to
manage
clusters,
whether
you're
doing
multi-tenancy
or
not,
and
extend
clusters
with
things
like.
You
know,
operators
and
controllers
that
you
can
provide
added
value
so
problems
here.
There
are
still
too
many
ways
to
install
kubernetes.
This
is
obviously
a
huge
pain
point
for
folks
things
are
getting
better
we're,
starting
to
see
more
turnkey
solutions,
we're
starting
to
see
a
little
bit
of
consolidation,
but
this
is
still
incredibly
intimidating
for
new
folks
to
our
community.
A
One
of
the
things
that
we're
doing
here
is
that
we're
separating
concerns
between
like
provisioning
and
bootstrapping
and
management
and
observability
of
the
cluster
itself,
starting
to
separate
out
those
things
means
that
we
can
start
sharing
more
tools
and
that's
a
good
thing.
I
think
this
is
a
weakness
for
kubernetes,
but
it's
also
a
strength,
and
that
seems
a
little
bit
counterintuitive.
But
when
you
compare
kubernetes
to
the
Linux
kernel,
the
Linux
kernel
is
an
amazing
piece
of
technology.
It
runs
on
everything
from
a
phone
to
an
IBM
mainframe,
that's
actually
really
really
cool.
A
It's
it
really
pervades
every
part
of
computing
and
kubernetes.
You
know
follows
on
a
little
bit
to
that.
I
think
you
know
it's
not
exactly
the
same,
but
kubernetes
can
run
as
a
DevOps
tool
across
a
couple
of
machines.
All
the
way
up
to
you
know
huge
clusters
that
can
cover
large
enterprises,
there's
also
ideas
around.
Can
we
run
embedded
kubernetes
into
a
set
of
boxes
where
folks
don't
even
know
that
kubernetes?
A
Is
there
it's
a
hidden
detail,
so
there's
all
sorts
of
places
where
kubernetes
can
play
a
role
and
that's
reflected
in
the
ways
that
people
install
and
manage
kubernetes
one
of
the
interesting
sort
of
things
that's
happening
with
the
community.
Here
there
are
all
the
different
ways
to
manage
and
control
kubernetes
things
like
our
back
network
policies,
quota,
pod
security
policies,
taints
and
toleration,
audit
logs
all
that
stuff-
and
that's
that's
the
expanding
a
set
of
things
that
folks
who
are
managing
clusters
are
thinking
about
now.
A
You
know.
Obviously
these
are
the
folks
that
care
about
kubernetes
being
boring
right.
Their
job
is
reliability
on
the
operations
side,
you
want
boring
right,
and
so
that
message
of
kubernetes
is
boring,
really
appeals
to
folks
that
are
wearing
this
hat,
so
things
that
we
can
do
to
actually
make
this
better,
find
commonalities
right,
I
think
when
we
started
the
cube
ATM
project,
the
goal
there
was
to
build
a
tool
box,
not
necessarily
an
all-in-one
experience
and
we're
starting
to
see
some
uptake
across
the
different
installers.
A
As
we
leverage
that
toolbox
to
reduce
the
amount
of
duplication
and
then
as
we
build
these
pieces
as
kubernetes
developers
and
members
of
the
community,
let's
focus
on
not
just
individual
features,
but
how
all
these
features
fit
together,
we're
not
doing
a
great
job
right
now.
If
telling
that
story
all
right.
Let's
move
on
to
the
next
one
application
operations,
the
fact
that
cluster
and
service
operations
versus
application
operations
are
two
separate.
Things
is
actually
one
of
those
really
powerful
concepts
that
fall
out
of
both
cloud
and
cloud
native.
A
It's
this
idea
that
I,
don't
have
to
worry
about
the
whole
stack
I
can
offload
that
to
somebody
else,
whether
it
be
my
cloud
provider
or
whether
it
be
another
team
inside
of
my
organization.
So
with
that
in
mind,
the
main
concerns
of
folks
in
the
application,
ops,
a
profile
are
persona,
are
defining
and
deploying
applications.
The
application
lifecycle,
understanding
how
the
app
is
running
so
App
observability
from
cluster
observability
and
then
portability
across
kubernetes
implementations.
Again,
this
brings
up
the
theme
that
Craig
brought
up
in
the
keynote
around
conformance.
A
It's
a
really
important
piece
of
the
puzzle,
so
the
activities
here
include
like
packaging
like
docker
build.
This
is
the
type
of
thing
that
sometimes
hits
the
application
ops
side
of
the
house.
How
do
you
just
describe
what
you're
deploying
the
yam?
Well,
how
do
you
automate
it
testing
that
thing
and
deploying
it
ci
and
CD?
A
How
do
you,
you
know,
observe
that
and
then,
how
do
you
do
this
for
both
the
application
itself
and
how
the
application
interacts
with
the
underlying
platform,
kubernetes
and-
and
so
a
lot
of
the
stuff
that
folks
have
been
talking
about
have
been.
How
do
we
actually
find
ways
to
simplify
all
of
those
things?
A
But
again
I
don't
you
know,
I
don't
think,
there's
a
one-size-fits-all
solution,
understanding
that
these
separate
concerns
can
sometimes
be
solved
in
a
holistic
way,
but
sometimes
need
to
be
broken
out,
is
key
to
be
able
to
hit
all
the
different
sub
personas
of
this
particular
this
particular
scenario.
This
is
a
super
active
area
of
innovation.
I'm
really
excited
with
so
much
the
work
that's
going
on
here.
I
think
you
know,
there's
helm,
there's
json
and
case
on
it.
A
The
stuff
that
we've
been
working
at
at
hefty,
oh
and
I'mma,
give
a
demo
a
little
bit
later.
Qej
build
the
deepmind
Capitan
stuff.
That's
all
on
the
application
description.
This
cross
is
a
whole
bunch
of
cigs
in
kubernetes,
cig,
apps,
SIG's
CLI,
with
all
the
cube
control,
stuff
API
machinery.
How
do
those
tools
interact
with
the
API
itself?
Things
like
auto
scaling,
because
that's
actually
part
of
part
of
the
experience
for
applications
and
we're
starting
to
form
working
groups
like
the
application
definition
working
group
to
try
and
address
these
things
in
a
horizontal
way.
A
So
that's
an
exciting
area
of
innovation.
It's
also
a
very,
very
confusing
to
users.
So
one
of
the
things
we
can
do
here
to
actually
improve
this
is
understand
the
sub
personas.
What
are
their
different
ways
if
you're
installing
packaged
software
versus
you
know,
building
and
deploying
your
own
software?
There's
our
two
separate
personas
that
actually
come
into
play
here
and
then
recognize
that
we're
not
going
to
come
up
with
the
one
beautiful
systems
that
that's
actually
going
to
solve
everybody's
needs
in
this
thing.
A
So,
let's
find
ways
to
build
reusable
components
so
that
folks
can
actually
transition
from
one
type
of
system
to
another,
the
application
developers.
So
writing
apps
in
a
kubernetes
world
is
hard.
A
node
developer
expects
to
go
NPM
install
NPM
start,
that's
their
world,
that's
what
they
live
and
that's
how
they
develop.
That's
how
they
think
transitioning
that
to
docker,
build
and
cube
control
apply
is
a
painful
transition
and
the
experience
is
very
different.
A
I
think
one
of
the
big
things
that
we
get
with
kubernetes
and
with
docker
and
containers
in
general,
a
really
well-defined,
build
step
where
we
create
an
artifact
that
we
can
test,
not
all
languages,
not
all
developers
really
like
just
understanding
that
you
have
this
build
step
that
creates
an
artifact.
It's
actually
a
huge
leap
for
a
lot
of
developers
and
it
doesn't
work
with
their
application
flow.
So
there's
a
lot
of
challenges
ahead
for
us
about
how
we
actually
start
bridging
that
gap.
A
A
lot
of
that
bridging
will
have
to
be
in
a
language
and
environment
specific
way,
whether
you're
running
a
compiled
language
or
an
interpreted
language,
whether
you
rely
on
logging
or
debuggers
to
be
able
to
actually
understand
what's
going
on
in
your
application,
each
of
those
things
brings
different
constraints
and
then,
as
we
start,
building
out
a
micro-services
world,
what
happens
when
the
entire
set
of
micro
services
that
you
want
to
address
are
no
longer
on
your
laptop
right?
That's
a
very
hard
problem.
Now
how
do
I
actually
test?
How
I/o
a
valid
a
do?
A
I
mock
everything,
do
I,
create
some
network
connections,
do
I
D
bug
and
actually
run
all
my
development
workflow
on
the
on
the
cloud
inside
my
cluster
I.
Don't
think
anybody's
cracked
that
yet
so
there's
a
lot
of
work
to
be
done
there.
Also.
The
other
part
of
this
and
I
think
this
is
something
that
we
started
to
see
hints
of
in
in
Brendan's
sort
of
very
forward-looking
keynote.
A
Last
night,
I
don't
know
if
you
all
saw
that
was
how
do
we
get
applications
to
start
taking
advantage
of
the
special
context
of
running
kubernetes
when
you
write
a
Linux
application
right
now,
it
talks
to
the
Cisco
interface
right
Linux
through
through
you,
know,
Lipsy,
but
when
you're
running
on
a
cluster,
you
have
a
whole
new
set
of
toys
and
tools
that
you
can
actually
access,
which
is
the
kubernetes
cluster
itself.
So
how
do
we
move
applications
so
that
they
can
start
becoming
kubernetes
native?
A
We
can
do
this
and,
as
sort
of
you
know,
let's
move
everything
into
that
world
or
we
can
start
doing
it
in
a
more
incremental
way.
So
one
example
here
is
the
latest
versions
of
the
JVM
our
container
aware,
when
they're
running
in
a
container,
they
can
realize
how
much
RAM
that
container
has
and
by
looking
at
the
cgroups
hierarchy
and
automatically
setting
the
heap
size
of
the
JVM.
That's
a
really
nice
integration
and
it
reduces
the
amount
of
configuration.
A
You
need
to
make
sure
that
you
have
your
application
configured
well,
but
there's
more,
we
can
do
there.
Brendan
brought
up
ideas
around
using
standard
mechanisms
for
doing
locks,
shardene
right,
who
are
my
peers,
so
that
I
can
create
a
circular
cache
and
actually
assign
things
correctly
being
able
to
discover
that
as
a
primitive
that
folks
can
take
on
and
and
in
the
limit,
we
start
seeing
this
stuff
become
a
blend
of
application,
development,
application,
ops
as
applications
become
self
operable,
as
they
start
managing
themselves.
A
So
when
you
launch
a
MapReduce
job
inside
of
Google,
what
happens?
Is
you
launch
a
controller
and
that
controller
itself
goes
ahead
and
talks
to
Borg
launches
all
of
its
workers?
Does
the
computation
collects
all
the
results
and
then
returns
at
all,
so
that
thing
is
both
of
the
application
itself
and
a
controller
all
bundled
into
one,
and
so
we're
gonna
see
more
and
more
of
those
things
in
the
future.
So
what
can
we
do
to
help
users?
Here?
We
need
to
meet
application
developers
where
they
are.
A
We
have
to
start
finding
ways
to
bring
them
in
the
kubernetes
world
in
a
soft
way,
without
making
them
reevaluate
their
life
choices.
We
need
to
create
SDKs
right.
We
need
to
find
ways
to
make
it
easier
to
talk
to
kubernetes
without
necessarily
having
to
sync
the
like
I,
don't
know
like
terabyte,
that
is
kubernetes
/
kubernetes
right,
so
we
need
to
do
better.
There,
there's
progress
being
made,
but
but
there's
still
a
lot
more
to
go
all
right.
So
the
final
thing
here
is
the
cluster
and
service
developer.
A
So
the
canonical
example
of
this
are
the
folks
that
are
part
of
the
community
building
kubernetes
itself,
but
that's
not
where
this
ends
kubernetes
from
the
from
the
start,
was
really
thought
of.
As
an
extensible
system.
How
can
we
turn
kubernetes
to
be
a
platform
for
building
platforms,
and
so
not
only
all
the
folks
who
are
working
on
kubernetes
directly,
but
those
that
are
extending
and
integrating
with
kubernetes
in
a
way
to
provide
wide
value?
Those
are
folks
that
I
would
consider
part
of
this
persona.
A
This
is
an
incredibly
exciting
place
and
I
think
we
haven't
seen
anything
yet
in
terms
of
the
type
of
things
that
folks
can
build
on
top
of
kubernetes.
So
all
the
operators
and
controller
stuff
that
we're
talking
about
that
all
belongs
in
this
bucket
I'm,
particularly
excited
with
the
meta
controller
stuff
that
was
demoed
this
morning.
I
personally
haven't
had
a
chance
to
dig
into
that,
but
it's
been
on
my
radar
for
a
while
and
I
think
you
know.
After
a
cube,
comm
I'm
gonna
go
back
and
probably
do
that
on.
A
One
of
my
my
YouTube
streaming
shows
so
conformance
is
a
big
part
of
this.
Here.
We
want
to
make
sure
that
when
somebody
builds
in
integration
to
de
kubernetes
that
integration
can
be
leveraged
as
widely
as
possible,
we
want
to
be
able
to
create
communities
around
extending
and
building
new
capabilities
on
top
of
kubernetes.
So
we
need
to
continue
to
double
down
on
conformance,
not
just
from
the
application
point
of
view,
but
also
from
the
folks
extending
kubernetes.
A
So
when
I
say
extending
kubernetes
I
think
like
there's
a
lot
to
take
in,
but
there's
a
lot
to
be
done
here.
There's
like
controllers,
the
cloud
providers
see
RDS,
aggregated
API,
servers,
admission
controllers
and
initializers.
There
is
extensibility
around
how
you
store
secrets
and
then
custom
schedulers.
There's
all
sorts
of
interesting
ways
to
extend
kubernetes
all
right,
so
call
to
action
here.
What
can
we
do
as
a
community
to
make
this
better?
Well,
we
need
to
build
extension
points
over
extending
kubernetes
and
we've
been
doubling
down
on
this.
A
This
is
really
painful
because
a
lot
of
folks
come
to
the
kubernetes
community.
They're
like
hey
I,
just
want
to
extend
it
in
this
way,
can
I
check
in
code.
We
say
no,
we
really
like.
We
should
build
an
extension
point
before
we
do
that,
because
we
don't
want
to
put
more
stuff
into
the
nucleus
or
the
core
they're
like
well,
but
look
at
this
other
code.
It
already
did
it
like
yeah,
but
like
that
was
a
mistake.
We
should
try
and
get
that
out,
but
it's
unfair.
They
got
to
do
it.
A
I
don't
get
to
do
it.
It's
a
really
painful
conversation
to
be
able
to
do
this
stuff,
because
there's
a
lot
of
community
dynamics
that
come
into
play,
we
need
better
documentation
around
api's.
We
need
better
examples.
We
need
better
clients
that
are
easier
to
use
anybody.
Who's
tried
to
use
client
go,
has
felt
the
pain
of
the
fact
that
there's
no
documentation
on
how
to
use
the
thing
itself
installing
it
is
very,
very
difficult.
A
The
compatibility
matrix
across
clusters
is
is
really
difficult
to
understand
and
the
exam
examples
out
there
are
are
scattered
everywhere
and
sometimes
conflict
with
each
other.
So
again,
this
points
to
an
SDK.
This
is
an
SDK
really
it's
sort
of
like
a
kernel
level,
SDK
versus
a
sort
of
user
mode
SDK
to
draw
that
sort
of
Linux
kernel.
Extension
example.
A
So,
with
that
in
mind,
I
want
to
start
talking
about
a
project
that
we've
been
working
out
at
hep
TL
called
case
on
it.
This
is
an
open
source
project.
We
really
you
know,
we've
been
driving
it,
but
I
would
love
more
folks
to
get
involved.
You
can
go
to
a
case
on
it.
Do
if
you
want
to
check
more.
So
this
is
based
on
some
of
the
experiences
of
how
workloads
are
managed
on
top
of
board
and
just
fair
warning.
Those
experiences
are
controversial
right
there.
A
There
is
no
agreed
upon
way
to
solve
this
problem
and
so
even
inside
of
Google,
the
way
that
Google
has
like
probably
two
or
three
systems
to
actually
solve
this
problem.
So
so
I,
don't
think
anybody
has
found
the
right
way
to
do
this,
much
like
programming
languages
or
make
systems
or
apparently
according
to
Bitcoin
this
morning
money.
A
So
it's
like
twenty
thousand
I'm,
not
an
investor,
I've
glad
I
stayed
away
so
so
this
is
aimed
at
that
application
operations,
persona
and
the
reason
why
we
did
this
and
let
me
tell
you
a
story,
so
new
users
come
in,
they
read
a
tutorial.
They
call
cube,
control,
run
and
they're
like
hey.
This
is
pretty
easy.
What's
the
big
deal
about
kubernetes
I
use,
gke
I
brought
up
a
cluster,
I
ran,
cube
control,
run
I'm
up
and
running
in
five
minutes
right,
that's
awesome
and
then
a
little
bit
later.
A
They
realized
that
that
is
a
dead
end
right
because
they
want
to
be
able
to
manage
this
stuff
in
a
responsible
manner
and
so
now
or
they
want
to
get
access
to
some
of
the
more
advanced
features
that
aren't
exposed
through
that
very
limited
sort
of
keyhole,
that
is
cube,
control,
run
and
then
all
of
a
sudden.
It's
like
here's,
the
ammo
and
they're
like
oh
now,
I
understand
why
everybody
says
it's
so
complicated.
A
It's
like
you
know,
throwing
a
book
at
their
face,
it's
very,
very
difficult
that
transition
and
and
not
only
that,
a
lot
of
the
work
and
a
lot
of
the
learning
that
they've
done
for
coop
control
run
is
very
difficult
to
actually
translate
into
that
yamo
world
and
generally
what
they
do
is
they're
like
I'm,
gonna
copy
and
paste
some
stuff
from
the
docs
and
I'm
gonna
like
poke
at
it.
Until
I
can
do
a
control
apply
or
create
and
I
don't
get
an
error
like
oh
I
indented.
A
This
thing
the
wrong
amount
of
space
right.
So
it's
a
lot
of
trial
and
error.
Not
everybody
goes
and
looks
at
the
schema
for
these
things.
It's
mostly
based
on
examples,
a
quick
poll
how
many
folks
have
actually
gone
and
found
the
API
documentation
so
that
they
can
figure
out
what
to
put
in
there
yeah
moe
is
that
okay
I
do
think
it's
enough.
Do
you
think
that
API
documentation
is
good
enough
for
writing?
Amel!
No!
Okay!
That's
one
place
where
we
need
to
do
better
now,
so
so.
A
The
idea
here
is
that
I
think
folks.
They
start
getting
kubernetes.
This
idea
of
and
kind
of
I
roll
here,
but
get
ups
right,
I
want
to
take
the
the
source
of
truth
of
what
I
should
be
running
and
move
it
from
my
cluster
into
something
that
actually,
you
know,
integrates
with
the
rest
of
my
tool
chain.
That's
a
great
idea.
We
haven't
provided
great
tools
to
be
able
to
do
there
and
yeah.
A
Mille
is
really
an
assembly
level
primitive
when
we
need
higher-level
languages,
and
so
that's
really
where
K
sonic
comes
in
and
so
now
I'm
gonna
try
and
do
a
demo
here
and
unfortunately,
I
can't
see
the
screen
here
and
so
I'm
really
glad
that
I'm
using
this,
like
Auto
typing
thing
here,
can
you
all
see
that
yeah
I
was
really
typing
quietly
there
did
you
see
that
is
it
big?
Should
I
make
it
bigger,
yeah?
Okay,
here,
hopefully,
I
won't
break
stuff.
Oh
there
we
go
okay.
A
Well,
you
can
see
all
the
stuff
that
I've
done
before
there.
Okay,
so
one
of
the
things
is
that
you
can
install
this
with
brew
if
you're
running
on
the
Mac,
otherwise
there's
other
ways
to
do
it.
I'm
not
actually
installing
it
here,
because
because
Wi-Fi
in
a
in
a
conference
but
and
this
cable
is
not
working,
so
let's
cross
our
fingers
and
then
the
first
thing
we
do
is
we
actually
do
a
KS
in
it
and
you
name
your
application,
and
this
is
going
to
create
a
directory
structure
for
you.
A
So
we
can
see
the
end
of
that,
and
so
some
of
our
inspiration
here
is
there
that
there
looks
like
there's
more
there
than
should
be
there.
I
might
be
left
over
from
an
old,
oh
shoot.
Oh
man,
all
right!
Well,
the
demo
will
still
work,
but
now
you're
seeing
a
preview
of
what's
coming,
but
the
idea
here
is
that
we
are
inspired
in
some
ways
by
things
like
static
site,
generators
and
Ruby
on
Rails
right.
It's.
A
This
idea
that,
having
a
well-known
directory
structure
where
you
can
drop
in
some
files
is
a
good
way
to
eliminate
some
of
the
sort
of
fiddly
configuration
that
you
have
to
do,
and
so
that's
one
of
the
things
that
inspires
this
is
not
Ruby
specific.
If
we're
inspired
by
the
pattern
there
just
to
be
clear
all
right.
So
what
we
can
do
here,
let's
see,
is
this
going
to
give
us
an
error.
It
may
is
that
we
can
go
through.
We
can
do
a
KS
generates.
A
And
okay,
so
that
would
end
up
being
a
no
op.
There
should
be
some
output
there,
but
this
is
the.
This
is
half
of
cube
control
run.
This
is
creating
the
definition
of
what
we
want
to
run,
we're
specifying
the
image
and
we're
saying
that
we
want
to
expose
it
because
it's
an
exposed
service
and
we
want
to
expose
it
with
with
a
node
port.
A
A
All
right
there
we
go
okay,
much
less
there,
because
we
haven't
gone
ahead.
Okay,
so
now
I
can
go
through
and
I
do
the
KS
generate
and
that's
gonna.
Actually,
that's
half
of
cube
control
run
it's
just
creating
some
files
on
local
disk
and
then
the
next
thing
we
can
do
is
we
can
do
a
KS
apply
and
we're
applying
it
to
an
environment.
A
That's
a
target
cluster
plus
namespace,
and
these
are
all
things
that
you
can
check
in
to
get
and
you
can
track
and
you
can
do
code
reviews
all
that
good
stuff
applies
here
also
and
then
I
can
see
that
I'm
actually
really
running
the
thing.
So
I
can
go
through
and
see.
I
can
do
a
Q
control
get
on
this
and
then,
if
I
go
through
and
click
on
this
link
again
I
can't
see
the
screen.
Well,
so
let's
see
oh
man,
it
brought
it
up
in
the
wrong
window.
Let's.
A
Know?
Okay,
so
let's
oh
man,
okay,
there
we
go.
We
have
a
guestbook
here.
I
can
be
like
hello,
cube,
Khan
and
I,
probably
miss
type
stuff,
because
I
can't
see
but
whatever,
and
it's
not
saving,
because
we
don't
have
a
database
yet
all
right.
So
this
is
a
little
front
end,
so
our
apps
not
complete.
So
let's
go
ahead
and
go
back
and
create
our
database
all
right
turn
away
from
the
mic
to
here.
A
So
now
what
we
can
go
through
is
we
can
look
at
the
prototypes
that
we
have
and
prototypes
are
those
things
that
generate
uses.
So
you
generate
you
use
a
prototype
to
run
generate
it
produces
a
components.
A
component
is
a
set
of
kubernetes
resources
that
work
together
and
we
can
see
the
the
deployed
service
here
that
we
have
now.
A
We're
gonna
use
the
stateless
one
and
I
can
find
a
little
bit
more
about
it
by
doing
a
KS
prototype
described,
and
you
can
see
that
there's
some
parameters
here,
this
one's,
pretty
simple,
I'm
gonna
go
ahead
and
generate
from
that,
and
this
is
going
to
create
a
new
component
and
and
then
those
params,
that's
really
interesting
that
I
have
parameters.
One
of
the
things
we
can
do
is
we
can
go
ahead
and
we
can
edit
those
parameters
after
we
do
the
generate-
and
you
can
add
your
neun
parameters
as
you
go
through
this
stuff.
A
So
I
can
actually
list
the
set
of
parameters.
I
have
here
and
let's
go
back
and
upgrade
to
the
new
version
of
the
guestbook,
because
we
made
it
fancier
and
so
I
can
do
that
with
a
simple
one-line
parameter
set
to
0.2.
Now
I
can
do
this
across
environment,
so
I
can
say:
I
want
to
use
one
type
of
image
for
my
production.
A
Environment
I
can
use
another
type
of
image
for
my
staging
that
type
of
thing
I'm
not
going
to
be
demoing
the
multi
environment
stuff
right
here
right
now,
but
these
parameters
can
be
specialized
depending
on
where
you're
targeting
your
deployment
and
now
I
can
go
through
and
I
can
apply
that,
and
this
will
both
in
one
step
update
my
deployment
to
a
new
version
of
the
guestbook
and
deployed
the
Redis
database.
So
with
that
I
get
another
link
that
I
can
click
on
if
I
can
find
the
mouse.
Where
are
they
where
to
go?
A
A
I
have
to
click
the
button.
Yes,
and
you
can
see,
it's
actually
saving
it
now.
This
is
running
on
Mini
Cube,
on
my
on
my
laptop,
so
you
all
can't
hack
me.
That's
that's
my
that's
my
approach,
all
right,
so
that's
all
great,
and
so
you
can.
You
can
iterate
your
components.
You
can
check
this
in.
You
can
test
it.
You
can
share
it
with
other
folks,
and
this
really
provides
a
much
smoother
experience
from
that
sort
of
like
here's.
A
A
A
So
the
big
thing
I
want
to
end
out
here
is
that
we're
still
just
getting
started
with
kubernetes
right,
we're
still
in
the
opening
acts.
If
we're
successful
as
we
build
this
community,
the
interesting
thing
is
not
the
community,
the
kubernetes
itself,
but
the
stuff
that
we
build
on
top
of
it,
but
the
stuff
that
we
were
doing
before,
which
is
building
stuff.
That
would
work
for
for
folks,
who've
been
at
Google
for
a
long
time
or
folks
who
are
already
sort
of
familiar
with
these
cloud
native
ideas.
A
That's
not
going
to
get
us
to
where
we
need
to
go
to
really
really
get
the
ubiquity.
That
I
think
everybody
can
imagine
kubernetes
having.
We
need
to
start
thinking
outside
of
our
own
experiences
and
really
take
the
time
to
understand
how
other
users
are
viewing
and
approaching
what
we're
doing
here
with
with
kubernetes
and
the
larger
community.
So
with
that,
I
have
just
a
few
minutes.
I
was
running
a
little
late
because
of
the
demos
snafus
for
any
questions.
If
folks
want
to
come
up
to
the
microphones,
we
can
probably
take
a
few
minutes.
A
Right
so
so
that's
a
good
question.
The
question
is:
how
did
the
guestbook
actually
find
and
authenticate
to
the
Redis
instance?
So
there's
a
couple
things
going
on
there
number
one
is
that
the
guestbook
was
hard
coded
for
Redis
using
kubernetes
service
discovery,
so
that's
how
it
found
it
and
that
Redis
database
is
running
without
a
password.
The
the
bit
Namie
folks,
who
are
also
been
involved
with
us
with
with
case
on
it
a
little
bit
and
have
been
early
users
and
early
advisers
on
this
stuff.
A
A
Think
helm
in
my
mind
when
we
start
looking
at
the
sub
personas
around
application
operators
is
great
for
taking
widely
you
know,
community-generated
widely
shared
applications
and
being
able
to
install
those
right
and
one
of
the
the
places
where
helm
starts
to
struggle
is
when
you
have
a
large
degree
of
configurate
from
configurability.
If
you
look
at
the
nginx
ingress
controller
in
helm,
it
has
like
three
pages
worth
of
parameters
right.
A
So
that's
one
of
the
things
that
we
wanted
to
start
looking
at
here
is
that
can
we
actually
parameter
eyes
the
common
things,
but
then
also
give
you
easy
access
to
the
definitions
underneath
when
you
want
to
actually
customize
less
common
things
in
the
limit?
What
I
would
like
to
see
is
case
on
it'd,
be
a
great
way
to
author
helm,
charts
and
then
have
how
be
a
great
way
to
deploy
those
things
because
authoring,
helm,
charts
right
now
is
not
for
the
faint
of
heart
it's
gonna
take
a
while
to
get
there
helm.
A
3
planning
starts
in
February,
we're
gonna
be
looking
at
that
very
carefully,
and
then
development
starts
after
that.
So
it's
going
to
be
quite
a
while
before
we
can
actually
see
the
integration
or
the
possibility
of
integration
that
we
like.
So
with
that.
Thank
you
very
much.
Everybody
I
appreciate
you
taking
the
time
come
find
us
at
the
hefty
o
booth.
If
you
want
to
learn
more.