►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
You Can't Have a Cluster [BLEEP] Without a Cluster - Kris Nova, Heptio
I've been running Kubernetes in production for 2 years, and have worked on enterprise Kubernetes service teams including the Azure managed Kubernetes team. This presentation is very special and will talk about the dangers in using Kubernetes incorrectly. This presentation is drawn on years of real experience reports of providing Kubernetes as a service. We learn about the surprising ways users have used/abused Kubernetes, and how their creative use cases ended up causing catastrophic problems for the rest of the system. A simple example of one of these experience reports is running a large Java application in a docker container in Kubernetes, and how the JVM consumed more memory than the container allocated and ultimately put the node into dead lock. The audience walks away knowing they are not alone in their journey to tackle the new complexities of cloud native application management.
To learn more: https://sched.co/GrYV
A
A
So
if
you
want
to
come
up
to
me
and
talk
it'll
be
a
great
time,
so
the
name
of
my
talk
is
you
can't
have
a
cluster
bleep,
but
it
we
all
know
what
it
really
means,
and
you
can't
do
that
without
a
cluster-
and
this
is
a
big
reflection
of
my
past
two
years
and
using
kubernetes
and,
more
importantly,
abusing
kubernetes.
So
the
subtitle
here,
everyone
has
screwed
up
a
kubernetes
cluster
and
no
one
is
talking
about
it.
A
So
today
we're
gonna
have
a
little
bit
of
kubernetes
therapy
and
we're
gonna
talk
about
this
together.
So
a
little
bit
about
me,
my
name
is
Chris
Nova
I
am
a
senior
developer
advocate,
as
of
Tuesday
I
work
for
VMware,
but
over
the
past
year
and
change
I've
been
at
a
company
here
in
Seattle
called
hep
T.
Oh,
this
is
me
on
top
of
Mount
Hood.
A
A
couple
of
weeks
ago,
with
a
upside
down
pride
flag,
all
the
pictures,
you're
gonna,
see
in
this
presentation
are
pictures
of
mountains,
which
are
the
best
thing
in
the
world,
so
show
of
hands.
Get
your
arms
ready.
Who
here
has
ever
has
never
struggled
with
kubernetes
got
it
right
the
first
time,
and
so
we
have
one
person
over
here.
A
Okay,
good!
So
yeah
I
would
like
to
talk
about
that
today
and
we're
gonna
go
pretty
deep,
but
we're
not
gonna
go
into
super
granular
technical
concepts,
but
we
will
explain
a
lot
of
Technology
along
the
way
and
hopefully
I'll
do
it
in
a
way
that
is
a
meaningful
to
folks
here
in
the
audience.
Okay,
so,
as
I've
been
talking
about
kubernetes
and
as
I've
been
learning
about,
kubernetes
I've
been
able
to
boil
it
down
to
a
couple
of
handful
of
things
that
I
think
really
describes
what
kubernetes
introduces
to
us.
A
Who
here
is
a
software
engineer,
alright
hands
down
and
you
can
be
more
than
one.
This
is
one
too
many
who
here
is
an
operator
or
administrator:
okay,
so
we're
about
half
and
half
so
this
will
be
in
the
perspective
of
both
engineers
and
administrators.
So
what
does
kubernetes
induce
or
introduce
it
introduces
resilience.
So
this
is
this
goal
seeking
behavior
that
we
see
in
the
controllers
and
the
operators
that
I
talked
about
a
lot
yesterday
when
we
did
the
TGI
K
on
an
A
to
D
watch,
we
declare
a
state
of
the
world.
A
Let's
pretend
that
you
know
I
said:
hey
somebody
bring
me
a
beer
and
I
drank
that
beer
and
I
had
to
clear
that
I
need
one
beer,
then.
Ideally,
there
should
be
some
controller.
That
comes
and
brings
me
another
beer
so
that
we
always
have
this
one
state
of
the
world
that
we're
working
towards,
and
we
don't
really
see
this
another
software,
but
this
is
a
fundamental
part
of
kubernetes
that
is
baked
into
the
database
layer.
A
So
we
get
this
level
of
resilience
in
our
applications
and
in
our
systems,
management
that
we
don't
see
with
other
management
systems.
Kubernetes
introduces
efficiency,
maybe
not
at
first,
but
it
does
ultimately
so
there's
this
concept
of
a
technical
investment.
When
you
see
when
you
go
and
you
decide
to
adopt
kubernetes,
that
is,
it
takes
a
little
bit
of
time
for
the
first
go-around,
but
after
you
get
through
the
first
one,
it
actually
is
quite
efficient
for
you
and
your
team
building
and
piecing
together.
Applications
is
now
relatively
easy.
A
You
can
do
trial
and
error,
you
can
iterate
on
them
and
you
can
analyze
them
later.
Kubernetes
introduces
repeatability.
This
is
a
fundamental
part
of
science
and
computer
science.
If
we
weren't
as
scientists,
able
to
repeat
our
experiments
across
the
world,
we
would
never
be
able
to
share
experiments.
Now
we
may
not
be
just
sharing
temperatures
across
the
world
that
we're
calibrating
based
off
of
boiling
water.
A
Contrary
to
all
of
this,
it
comes
at
a
cost.
This
cost
is
this
lovely
thing.
We
call
complexity,
software
engineers
love
to
talk
about
complexity.
They
talk
about
how
you
create
complexity,
for
the
sake
of
creating
complexity
or
if
you
write
a
good
abstraction
you're,
a
complexity
is
going
to
be
a
simpler
and
you're
going
to
simplify
a
problem,
but
regardless
we're
introducing
a
new
layer
of
software,
every
line
of
code
in
a
layer
of
software
is
complexity.
There's
a
support
burden.
You
have
to
care
about
it.
A
All
of
a
sudden
becomes
something
you
and
your
team
need
to
worry
about,
and
this
complexity
is
where
a
lot
of
people
getting
themselves
into
cluster
fogs
kubernetes
introduces
risk
because
of
this
complexity.
You
have
to
worry
about
what
your?
What
your
software
is
doing
and
all
of
this
comes
out
of
risk.
You
can
measure
this
in
various
ways,
which
is
the
time
it
takes
for
you
and
your
team
to
get
something
up
and
running.
A
How
much
effort
is
securing
your
team
to
get
something
up
and
running,
but
regardless
you're
doing
all
of
this
at
a
risk?
Okay,
so
that's
kubernetes!
It
helps
us.
It
gives
us
these
wonderful
primitives,
but
it
comes
at
a
cost.
The
whole
point
of
kubernetes
is
that
that
cost
is
outweighed
by
its
value.
In
other
words,
kubernetes
helps
you
more
that
it
introduces
complexity
and
risk,
and
that's
why
this
is
exciting.
That's
why
we're
all
here
today!
A
That's
why
both
operators,
software
engineers,
decision
makers,
project
managers
and
CEOs
are
all
pointing
their
fingers
at
kubernetes,
because
it's
worth
it.
So,
let's
talk
about
the
cloud
so
who
here
runs
something
anything
in
the
cloud
awesome
I
wish
I
had
another
picture
of
that
one
as
well.
So
let's
talk
about
what
exactly
is
the
cloud.
A
Take
your
pictures-
it's
okay,
I'll,
just
name
here
for
a
second!
So
if
we,
if
we
look
at
the
diagram
here
and
if
you
know
me,
you'll
know
that
I
used
to
be
a
data
center
technician,
that's
how
I
got
started
in
my
career
and
I.
Remember
looking
out
floor
plans
for
a
data
center
and
actually
looking
at
it
like
it
was
a
small
factory.
A
What
are
the
inputs
and
outputs
of
a
data
center
electricity
comes
in
money
comes
in
and
small
5-volt
signals
and
optical
lights
go
out
and
what
happens
in
this
data
center
is
sort
of
this
black
box.
It's
sort
of
black
magic-
and
this
is
what
we
call
cloud
today
and
whatever
you
have
running
on
this
120
and
220
volt
hardware
in
the
middle
can
create
some
sort
of
value
for
other
people
and
if
you
sell
that
as
a
service
you're
effectively
rebranding
electricity,
somebody's
tweeting
about
me
right
now,
I'm
going
to
turn
this
off.
A
So
anyway,
this
is
this
is
cloud
computing,
but
this
is
very
important,
because
this
is
more
complexity
that
we
have
to
worry
about
in
kubernetes.
That
kubernetes
is
several
layers
above
like
who
here
has
ever
wondered:
how
much
voltage
is
going
over
a
cat,
5e
cable,
why
it's
plugged
into
a
virtual
machine
or
a
computer?
That's
running
virtual
machines.
That's
running
kubernetes
Wow!
Ok,
we
should
talk
later
because
I
want
to
know
your
use
case
for
that.
A
Ok,
so
let's
look
at
the
stack
of
what
happens
in
a
data
center
and
this
data
center
could
be
from
a
major
cloud
provider
or
it
could
be
a
data
center
that
you
and
your
team
are
responsible
for.
So,
let's
start
in
the
bottom
left
electricity.
We
just
learned
about
that
above
this
electricity
is
Hardware
above
this
piece
of
hardware
which
of
course
could
be
servers:
network
infrastructure,
routers
lights.
A
If
we
look
at
what
kubernetes
is
this
really
solves
three
things
for
us?
It
breaks
down,
defining
our
applications
into
three
main
buckets:
compute
network
and
storage.
This
is
a
fantastic,
fantastic
diagram,
because
what
other
software
in
the
world
is
represented
by
three
physical
things?
What
other
piece
of
software
in
the
world
is
represented
by
three
things
that
are
found
at
the
bottom
of
the
OSI
reference
model?
A
A
So,
let's
look
at
the
things
kubernetes
is
capable
of
managing.
So
in
this
diagram
we
took
the
the
stack
as
it
was
defined
on
the
left
and
we're
gonna.
Look
at
all
of
the
different
things
kubernetes
could
potentially
manage.
Could
cou
permit
kubernetes
manage
electricity
right
now
on
the
cluster
api
project?
One
of
the
projects
I
co-founded
with
some
friends
from
open
source.
A
We
are
looking
at
creating
the
bare
metal
implementation
that
is
driven
by
the
controller
operator
CRD
model,
meaning
we
would
be
able
to
bootstrap
of
a
machine
in
a
data
center
using
a
controller
that
would
be
managed
by
kubernetes.
Furthermore,
we
can
mutate
and
control
hardware
who
here
has
created
a
load
balancer
with
kubernetes.
Before
that's
that's
Hardware
last
I
checked
we
can
create
OS
and
virtualization
layers
as
well.
There's
a
tool
called
Cubert
that
allows
you
to
literally
create
virtual
machines
with
kubernetes.
A
What
you
don't
see
here
is
an
arrow
coming
out
of
kubernetes
and
pointing
back
at
itself,
and
that's
what
kubernetes
is
doing
the
entire
time
as
its
managing
itself.
Furthermore,
and
manages
tools
and
addons
on
top
of
itself
to
keep
itself
health
healthy
and
last
but
not
least,
it
should
ideally
manage
your
application.
A
So,
let's
look
at
the
kubernetes
internals,
so
on
the
Left
we
have
the
control
plane
and
on
the
right
we
have
a
kubernetes
node.
This
is
relatively
simple
if
you've
ever
looked
at
a
kubernetes
diagram
before
we've
all
seen
this
before.
But
what
you
don't
see
in
a
lot
of
kubernetes
diagrams
is
everything
else
there
there
we
go.
Dns
is
a
great
example.
We
do
have
to
manage
that
in
kubernetes.
A
Your
clusters
really
not
going
to
work
without
it
C&I
who
here
has
ever
had
a
cluster
bleep
because
of
C&I
a
lot
of
people
just
who
here
knew
about
CNI
before
that
happened?
Hardly
anybody
put
their
hand
up.
Okay,
and
then
we
have
to
look
at
the
container
runtime
operating
docker
in
kubernetes
is
not
fun.
Furthermore,
there's
this
whole
TLS
configuration
management
system.
We
have
to
concern
ourselves
with
where's
TLS
going
to
come
from.
How
do
we
cycle
it?
How
do
we
know
it's
secure?
A
How
do
we
keep
it
out
of
the
hands
of
malicious
users,
and
all
of
that
goes
over
the
wire
and
talks
in
two
ways
to
the
cubelet
API
server,
which
most
people
don't
know?
We
have,
or
at
least
didn't
know
we
have
until
the
CS
CVE
last
week,
the
cubelet
running,
underneath
that
API
server
CNI
again
manifesting
itself
on
a
node,
the
container
runtime
also
relevant,
and
then
another
independent
set
of
TLS
on
the
node
side
as
well.
A
So
this
is
everything
I've
talked
about
so
far
lunged
into
one
slide,
and
you
can
see
at
the
top
there's
little
view
and
a
giant
API
surface
standing
in
the
way
of
all
this
complexity
that
we
just
got
done
talking
about
on
the
left
is
a
stack
in
the
middle
of
some
options
and
over
on
the
right
as
a
detailed
diagram
of
kubernetes
everybody
good.
So
far,
oh
also,
by
the
way,
containers
don't
really
exist.
If
that
previous
diagram
wasn't
complex
enough.
A
So
in
this
diagram
we
sort
of
break
down
a
container
into
its
fundamental
pieces,
and
you
concern
yourself
with
this-
not
very
often
kubernetes,
but
it
is
an
important
part
of
what
makes
kubernetes
so
repeatable.
So
really
it's
just
a
simple
process.
It
gives
up
it
like
every
other
process
and
because
of
these
new
kernel
features
seed
groups
and
namespaces
we're
able
to
sort
of
synthesize
a
machine
around
the
container
and
create
a
synthetic
file
system,
and
basically
all
we're
doing
is
it's
it's
very
similar
to
DNS
main
in
the
middle.
A
We're
just
pretending
to
be
something
we're
not
and
as
far
as
the
process
is
concerned,
that's
the
source
of
truth
and
because
of
these
new
features
in
the
kernel,
we
can
sort
of
spoof
that
if
you
love
so
that's
the
main
function
that
we've
been
talking
about
behind
the
scenes.
So
now,
let's
take
all
of
this
and
get
it
onto
one
slide.
So
this
you
have
to
keep
this
whole
diagram
in
your
head.
Whenever
somebody
says
kubernetes,
if
I
walked
up
to
you,
talk
to
this
and
said,
ok,
are
you
running
kubernetes?
A
You
should
be
like.
Oh
I
have
to
remember
all
these
things,
CNI
and
TLS
and
certs,
and
all
these
things
that
I
have
to
concern
myself
with
in
order
to
run
an
engine
kubernetes
and
then
at
the
top.
We
have
our
lovely
REST
API
and
then
at
the
very
tippy
tippy
top
you,
the
client,
the
user.
Whatever
is
interacting
with
kubernetes.
A
Ok.
So
who
asked
questions?
No
seriously?
That's
a
lot
there
and
you
know
it
takes
a
lot
of
folks
a
long
time
to
get
there,
and
you
know
I
just
summarized
it
here
in
a
couple
minutes,
but
it's
it's
probably
a
pretty
personal
journey
for
a
lot
of
people
to
go
through
and
one
of
these
lessons
and
to
kind
of
get
bitten
along
the
way
and
learn
that
they
need
to
care
about
what
a
Sikh
group
is
and
learn
that
they
need
to
care
about.
A
What
CNI
is
and
learned
that
they
need
to
care
about
about
which
cloud
provider
they're
using
so
we're
gonna.
Look
at
some
concrete
examples
of
times
where
this
complexity
has
gotten
folks
into
trouble
and
I
wish
I
had
more
time,
because
I
have
some
really
great
ones.
I
have
really
good
stories
of
people,
exposing
Jupiter,
no
bugs
and
getting
attacked
by
Bitcoin
miners
I
have
people
who
were
able
to
actually
use
a
kubernetes
cluster
against
itself
and
authenticate
and
then
actually
used.
A
The
québec
tool
CLI
tool
inside
of
the
cluster,
to
hurt
itself
so
there's
some
really
interesting
attack
vectors
inside
of
kubernetes,
but
we're
gonna
look
at
times
where
somebody
thought
they
did
something
innocent
and
then
it
later
turned
out
to
cause
catastrophic,
downstream
incidents.
Because
of
this
layer
of
complexity.
Who
here
would
merge
this
pull
request
without
thinking
twice
about
it?
A
Maybe
three
times
I
would
I
really
would
I
would
look
at
this
I
would
see
what
it
was
for.
I
would
say:
okay,
it's
for
a
deployment
and
I'm
sure
the
software
engineer
included
somewhere
in
here
a
reason
why
they
wanted
to
bump
these
limits
up
a
little
bit-
and
this
is
this-
is
a
really
great
pull
request
from
some
friends
of
mine
at
solando
who
here's
from
the
zalando
I
want
to
give
a
big
shout
out
to
them.
A
We
have
one
person
over
here,
so
yeah
I
jumped
on
the
phone
with
them
and
we
went
through
this
one,
and
this
is
the
one
that
I
picked
as
a
great
example
of
a
time
where
this
complexity
can
come
back
to
hurt
you
in
a
seemingly
innocent
way.
So
this
pull
request
is
for
well
technically
three
line
change
if
you
count
the
first
line
as
a
no
op
and
it
was
merged.
So
let's
look
at
what
happened
after
this
PR
was
merged,
so
the
PR
was
merged.
A
There
was
a
CI
CD
system
in
place
that
created
a
new
container
image
for
this
new
deployment.
This
is
this
piece:
that's
not
solved
by
kubernetes,
who
here
has
written
some
sort
of
tooling
that
will
go
and
update
a
deployment
after
you
merge
who
here
wishes,
they
didn't
have
to
write
that
Tulane.
Okay,
we
should
start
a
new
project
right,
okay,
so
that
was
merged.
A
new
container
image
was
created
and
then
based
on
some
tooling,
the
deployment
was,
this
seems
pretty
pretty
standard.
A
After
this
happened,
we
brought
some
containers
to
life,
they
started
being
scheduled
in
kubernetes
and
they
came
up
on
nodes
after
they
came
up
there.
Was
this
really
awkward
fundamental
incompatibility
with
the
go
standard
library?
This
wasn't
a
piece
of
software
or
somebody
downloaded
from
github
without
thinking
twice
about
it.
This
is
the
ghost
standard
library
the
same
one
that
we've
been
using
for
years.
That
has
a
ton
of
backwards
compatibility
guarantees
that
you
hear
all
of
these
Gophers
talked
about
how
wonderful
go
is
well,
here's
a
case
concretely.
I
have
the
PR.
A
A
So
all
of
a
sudden,
the
system
was
unable
to
authenticate
with
itself,
because
the
container
wouldn't
start
when
we
weren't
able
to
authenticate
with
ourselves
that
the
system
began
slowly
crashing
and
dying,
and
this
is
the
same
thing
that
happened
and
a
couple
of
other
really
notable
events
around
the
world
where
the
problem
prevented
you
from
accessing
the
system.
How
are
you
able
to
access
a
system
if
you
can't
authenticate
with
a
system
so
to
quote
Yanis
from
solando?
A
Let's
look
at
another
one:
what
happens
when
kubernetes
bleeps
up
itself?
What
happens
when
the
folks
who
write
code
in
kubernetes
make
a
mistake
and
do
something
wrong?
Oh
and
I
got
my
slides
backwards,
so
the
simple
solution
to
that
last
one
was
a
hardening
CI
CD
and
having
some
integration
testing
to
validate
that
the
the
container
actually
would
have
been
what
we
were
looking
for
and
it
would
have
ran
the
authentication
service.
So
now
what
happens
when
kubernetes
bleeps
up
kubernetes?
A
A
It's
a
way
of
measuring
to
see
the
the
impact
of
a
CV
II,
this
one
ranked
9.8,
which
is
extremely
high,
and
if
you
read
the
little
blurb
below
it
says
that,
with
a
specially
crafted
request,
users
can
authorize
and
establish
a
connection
through
the
API
server
and
then
send
arbitrary
requests
to
the
back-end
server.
So
remember
that
diagram
of
kubernetes
we
looked
at
earlier.
This
is
basically
what's
happening.
Is
a
client
could
send
a
very
special
type
of
request
to
the
API
server?
A
The
API
server
would
hang
because
of
the
switching
protocols
request
and
leave
it
a
vulnerable
socket
opened.
Then
a
malicious
user
was
able
to
escalate
through
that
connection
and
actually
form
arbitrary
requests
against
the
qiblah,
because
the
API
server
is
what
governs
our
back
in
all
security
policies.
The
cubelet
is
effectively
for
lack
of
a
better
term
dumb
to
what
the
api
server
tells
it
to
do.
In
this
case,
this
resulted
in
remote
command
execution
and
remote
command
injection
because
you
have
asically
had
root
on
the
cubelet,
which
is
the
power
horse
behind
kubernetes.
A
Now
this
complexity,
that
I've
been
talking
about
the
entire
time,
isn't
necessarily
what
caused
this.
We
could
have
solved
this
by
penetration
testing.
But
my
point
is:
is
now
software
engineers
when
we're
looking
at
problems,
they're
more
complex
problems,
we
don't
have
simple
issues
like
we
used
to
in
the
past,
where
somebody
like
missed
a
semicolon
in
a
config
file.
These
are
now
much
more
complex.
They
span
the
entire
stack
because
we're
managing
the
entire
stack
and
we
can
get
ourselves
into
trouble
along
the
way.
A
A
Some
of
these
probably
look
pretty
familiar
to
you.
I
see
people
pointing
like
oh
yeah,
I've
got
that
one
before
so
these
are
things
that
you
may
have
to
concern
yourself
with
are
questions
you
might
ask
yourself
with
along
the
way
as
you're
moving
to
kubernetes
and
it's
ok.
These
are
hard,
there's
a
lot
going
on
here,
but
just
being
aware
that
you
and
your
team
and
your
engineering
team
are
going
to
be
across
with
these.
A
A
I've
been
up
here
and
I've
been
saying
it
for
a
while,
but
it's
worth
it,
in
other
words
the
value
out
on
top
of
kubernetes,
which,
if
you
want
to
go
see
what
kubernetes
adds
in
value
there's
a
ton
of
other
talks
here
this
week
that
I'm
sure
I've
already
talked
about
it,
and
if
you
do
the
math
and
you
crunch
the
numbers
you
most
cases
find
out
that
kubernetes
is
worth
it.
But
how
do
you
prevent
these?
A
These
catastrophic
problems
in
the
sea
of
complication,
so
this
is
where
we
get
to
see
all
these
fun
fancy
buzzwords
like
oh
I,
guess
my
font
got
off
when
I
maximize
my
screen
here
or
whatever
fancy
buzzwords
like
observability
and
conformance
and
warnings
and
metrics,
and
really
what
we're
trying
to
say
here
is.
We
need
to
have
some
system
some
tool
in
place
that
helps
us
mitigate
hazards
and
observe
our
systems,
I'm,
a
mountaineer
and
basically
mountaineering.
A
Is
this
never-ending
a
process
of
mitigating
hazards
and
just
being
aware
of
the
hazards
around
you
awareness,
we
call
observability
in
computer
science
and
in
these
systems.
Furthermore,
we
need
to
learn
how
to
manage
our
systems.
We
need
to
learn
how
to
manage
and
measure
what
type
of
systems
we
have
if
I
go,
try
to
climb
a
mountain,
there's
gonna
be
some
metrics
I'm
gonna
care
about
how
much
of
it
is
glaciated.
How
tall
is
it?
Do
people
die
on
it?
Is
it
covered
in
ice?
A
Is
it
a
volcano
that's
about
to
erupt
in
kubernetes,
we
need
to
start
figuring
out
these
same
questions
and
asking
ourselves
this
about
our
systems
so
that
you
can
easily
and
reliably
translate
this
to
another
engineer.
Furthermore,
we
need
to
learn
how
to
build
tools
to
gain
confidence.
That's
all
we
want.
At
the
end
of
the
day,
it
doesn't
matter
how
many
observability
tools
you
have
how
many
Prometheus
clusters
you
have
all
you
really
care
about
is.
Are
you
confident
that
you
have
awareness
in
your
system?
How
you
do
that?
A
It's
a
personal
question,
it's
up
to
you
and
your
team,
but
there
are
a
lot
of
tools
and
things
in
place,
like
conformance
checkers,
like
observability,
like
compliance
checkers
like
reading
various
logs
from
kubernetes
that
can
introduce
that
confidence
and
it's
a
never-ending
journey
of
figuring
out
what
those
things
are
that
you
and
your
team
care
about
that.
Give
you
that
confidence,
a
bank
isn't
going
to
have
the
same
concerns
as
somebody
running
a
video
game
company
there's
just
going
to
be
fundamentally
some
differences
that
they
care
about.
A
So
it's
okay.
If
you
get
a
little
lost,
we
all
have
been
there
at
the
very
beginning.
Every
person
in
this
room
put
their
hand
up
and
said,
they've
struggled
with
kubernetes.
So
it's
okay,
if
you
get
a
little
off
in
the
weeds,
but
just
don't
get
too
lost.
If
you
need
help,
that's
why
we're
here?
That's
why
I'm
here?
That's
why
the
communities
here?
That's
why
all
these
open-source
projects
are
here.
A
It's
why
the
CNCs
is
here
so
we're
here
to
help
and
just
be
aware
that
we
can
work
together
as
a
team
to
solve
these
problems
so
that
we
don't
get
into
any
more
cluster
bleeps.
So
kubernetes
also
brings
hope.
This
hope
of
one
day
will
kind
of
put
an
end
to
all
of
these
concerns,
and
all
of
this
complexity
we
just
looked
at
by
working
together.
This
is
a
new
a
day
of
open
source.
A
We
have
companies
together
every
week
on
sync
calls
who,
in
a
previous
life,
would
have
been
competitors
with
each
other
working
together
to
to
solve
these
complicated
problems
that
we
now
see.
So
in
closing,
kubernetes
is
complex.
This
complex
complexity
can
be
chaos.
It
can
be
chaotic.
Chaos
can
cause
a
lot
of
the
problems
we
just
seen
being
able
to
conquer
this
chaos.
Chaos
is
freedom
and
conquering.
Kubernetes
is
worth
it
if
you
and
your
team
decide
to
make
that
journey,
and
last
but
not
least,
nobody
wants
another
cluster
bleep.
A
So,
let's
start
getting
the
stuff
out
there.
Let's
start
writing
blogs
about
how
you've,
maybe
goofed
up
a
lesson
you
learned
and
let's
start
sharing
and
learning
from
each
other's,
like
the
good
scientists
that
I
know
we
all
are
so.
Thank
you.
Everyone
I'll
do
Q&A
now,
but
if
you
want
to
snap
a
photo,
there's
a
link
there
in
case
you're
in
a
hurry.
There's
a
survey-
and
you
can
ask
me
any
question
in
the
world
and
I'll-
make
you
a
personal
guarantee
that
I'll
get
back
to
you.
A
B
A
A
A
B
A
I
built
a
system
when
I'm,
not
gonna,
say
the
company
I
worked
for
that
was
originally
designed
to
basically
treat
virtual
machines
in
the
same
way.
Kubernetes
treats
containers
about
halfway
through
building
the
system.
An
engineer
walked
up
to
our
team
one
day
and
said:
hey
have
you
all
heard
about
these
new
things
called
containers,
and
so
we
actually
wrote
an
interface.
A
We
were
ready,
Java
back,
then
we
wrote
an
interface
to
treat
VMs
in
containers
the
same
way,
and
none
of
us
have
any
idea
what
the
difference
was,
and
that
was
the
first
time
I
got
into
trouble
managing
containers
as
far
as
other
systems
that
are
a
little
more
well-known,
AIA
kubernetes
was
the
first
one
for
me
and
I
fell
in
love
with
how
complicated
it
was
on
day.
One
and
I've
been
here
ever
since.