►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Understanding Kubernetes Through Real-World Phenomena and Analogies - Lucas Käldström
How is the Kubernetes controller model similar to a taxi driver? Why is Kubernetes so differently designed compared to similar systems? How has the second law of thermodynamics and randomness theory shaped Kubernetes design? How the shift from traditionally managing servers to using Kubernetes operators similar to the Industrial Revolution? This talk offers the audience a unique perspective into why Kubernetes is designed the way it is. Kubernetes is often described as designed from “decades of experience”, but it is not as often mentioned what that means in practice. Quite conversely, many newcomers to Kubernetes find it “too complex”. Why is it, or why is that the impression? After this talk, the audience can make sense out of why Kubernetes does what it does. This by learning the fundamental design philosophies of Kubernetes and cloud native through well-known phenomena and real-world analogies. With the right mental model, hopefully it doesn’t seem overwhelmingly complex anymore.
A
Hi
yeah,
can
you
hear
me
perfect?
Well,
thanks
for
the
introduction,
thanks
for
attending
this,
this
talk.
I'm
really
excited
to
share
these
kind
of
ideas
with
you
today.
We're
gonna
walk
through
really
the.
Why
of
what
we're
doing
so,
it's
going
to
be
a
little
bit
philosophical,
a
little
bit
kind
of,
hopefully,
maybe
even
new
ideas
and
kind
of
get
your
head
spinning
after
this.
That's
that's
the
kind
of
idea.
A
So
no
it's
a
little
bit
delay.
I'm
lucas
trustrum,
studying
at
alto
university
at
the
moment,
but
I've
already
been
doing
some
quite
some
different
things
in
in
the
kubernetes
community,
starting
from
kubernetes
and
arm,
which
is
also
my
my
twitter
username.
If
you
want
to
tweet
tweet
at
me
and
give
feedback,
I'm
definitely
looking
for
feedback
for
this.
A
But
yes,
let's
take
a
look
at
the
y
and
when
we're
coming
to
this
kubecon
conference,
we
get
a
lot
of
the
watts.
So
we
get
a
lot
of
the
yaml
a
lot
of
the
kind
of
run
this
command.
You
know
in
this
order
and
then
write
this
script
here
and
it's
going
to
do
its
thing
or
like
click
this
button,
but
then
we
might
ask
how
so
so.
How
does
it
work?
A
Well,
when
you
submit
a
port,
when
you
submit
some
application
to
kubernetes,
it's
going
to
schedule
the
different
things
to
the
different
nodes
in
a
certain
order
that
we
also
have
a
lot
of
talks
about.
But
now
I
want
to
go
even
more
to
the
core
and
wonder:
why
did
we
choose
different
certain
patterns
that
we
now
have
kind
of
as
de
facto
standards
in
the
kubernetes
community?
A
So
this
is
kind
of
what
I
don't
want
to
happen.
So
if
we,
if
we
don't
look
at,
why
we're
doing
things,
we
might
end
up
missing
the
kind
of
problem
we're
solving.
So
there's
two
kinds
of
of
complexities-
and
I
thank
joe
bida
for
this.
This
analogy
so
there's
necessary
complexity
and
that's
the
one
we're
going
to
look
into
today
and
there's
also
kind
of
accidental
complexity
and
and
the
accidental
complexity.
A
We
hope
to
remove
over
time
so
that
users
aren't
annoyed
in
just
vain,
but
the
necessary
complexity
is
actually
there
because
of
reason
and
we're
going
to
go
into
the
reason.
What
is
the
reason?
What
is
the
necessary
complexity?
We
might
not
even
know
that
we
had
and,
as
you
might
know,
kubernetes
stems
from
development
in
the
in
inside
of
google
at
first
now,
it's
a
community
project
as
you've
seen
in
this
conference.
A
But
then
some
new
users
of
kubernetes
ask
is
this
too
complex?
Why
is
it
so
complex
and
that's
exactly
what
we're
going
to
distill
down?
What
is
the
necessary
complexity?
What
is
accidental
complexity,
and
how
can
we
find
out
when
we're
doing
new
things
on
top
of
kubernetes
kind
of
what
is
the
necessary
complexity?
We
need
to
take
into
account
and
what
can
we
kind
of
then
figure
out
in
other
ways.
A
So
here
is
an
example
as
a
small-scale
user,
you
might
say
that,
oh,
this
is
too
much
for
me
and
I
don't
have
any
problems
with
a
easier
system
that
I
was
using
before,
but
that
might
be
because
you
haven't
run
it
a
long
long
enough
time
to
be
kind
of
experience.
All
of
the
the
randomness
all
of
the
problems
that
come
over
time
that
come
with
time
and
kubernetes
is
designed
to
mitigate
these
problems
that
you
see
over
time
and
and
it's
this
is
done
by
google
running-
well
a
lot
of
servers.
A
This
way,
then
it
takes
just
a
couple
of
days
before
they
have
kind
of
growing
pains.
They
have
all
kinds
of
things
that
affect
their
service
systems
and
I
need
to
fix,
but
it's
for
a
small
scale
user.
It
might
not
be
apparent
before
after
a
year
or
two
that
oh,
these
are
real
hard
problems
that
we
we
weren't
thinking
about
before.
A
So
well
we
want
to
play
some
piece
of
music
and
we
have
some
composer.
You
know
writing
the
music,
but
if
we
have
no
conductor,
maybe
we
don't
find
out
who
is
playing?
What
and
in
what
arrangements
and
and
what
kind
of
ways
do
we
split
this
up
and
who
is
actually
making
sure
that
every
everything
goes
in
the
right
order?
A
A
The
one
orchestrating
making
sure
everything
is
in
goes
in
the
right
place,
but
also
the
musicians
themselves
are
good
right
and
say
that
there
would
be
some
some
noise
from
the
outside.
Then
they
they
kind
of
improvise
and
they
bring
the
noise
into
the
music
they
kind
of
make
it
improvised
such
that
it
adapts
well
to
the
environment
and
kubernetes
is
extensive,
accessible
and
also
adaptive
to
all
kinds
of
certain
conditions
that
it's
operating
in.
So
we
need.
A
We
need
a
conductor,
but
we
also
need
to
be
able
to
improvise
so
we're
going
to
go
through
four
principles
today
and
this
being
the
first
one.
So
we
have
the
kind
of
a
control
plane.
Api
server,
this
kind
of
stuff
at
the
really
heart
of
the
system,
then
orchestrating
the
nodes
in
the
system,
but
they
can
also
improvise
themselves
and
adapt
their
environment
when
they
see
that
things
are
kind
of
going
sideways
and
and
then
we
we
have
some
kind
of
claim.
So
what
is
the
music
that
we
want
to
play?
A
A
We
have
some
some
kind
of
description
of
what
is
the
music
we
want
to
play,
and
then
the
the
conductor
or
the
one
doing
the
arrangement
then
hands
out
different
kinds
of
specialized
notes
to
the
whatever
piano
guitar
violin,
whatever
we
have
in
the
orchestra-
and
there
is
a
difference
here,
because
the
the
declarative
claim
can
be
kind
of
more
general,
more
kind
of
okay.
This
is
something
along
the
lines
of
what
it
should
sound,
but
then
there
can
be
many
different
kind
of
fulfillments
to
that
claim.
A
Many
kind
of
arrangements
of
the
same
piece
of
music
depending
on
who
is
doing
it
and
depending
on
what
environment,
depending
on
all
kinds
of
things.
So
that
is
then
the
imperative
kind
of
the
exact
commands.
The
exact
notes
you
should
be
playing
them,
so
we'll
get
back
to
that
in
a
moment
as
well.
But
this
is
kind
of
one
of
the
key
ideas
that
we
have
the
declarative
thing
specifying
claims
and
then
the
imperative
kind
of
more
specifying
actions
or
sequences
of
operations.
A
So
this
is
exactly
this
declarative
means
making
a
declaration
of
something,
and
then
there
is
some
kind
of
actuator
some
kind
of
person
process
some
full
that
fulfills
the
claim
by
doing
some
some
operations,
so
the
the
declarative
model
focus
on
the
the.
What?
What
is
it
that
we
should
be
doing,
whereas
the
opposite,
the
imperative
focus
on
on
the
the,
how
the
exact
sequences
of
things
and
that's
why
we
kubernetes
is
essentially
all
declarative.
So
when
we
submit
something
to
the
kubernetes
api.
A
So
when
we
tell
some
kubernetes
to
do
something,
then
that's
declarative
in
the
same
way
as,
for
example,
these
opposites
so
same
way
as
you
make
an
svg
file,
you
don't
encode
specific
pixels
in
that
you
can
zoom
forever
and
it
still
has
the
same
resolution,
whereas
in
a
png
file
that
gets
pixelated
fast
same
way.
You
if
you
talk
to
a
normal
database
today,
you
actually
say
that
select
something
from
some
data
from
from
some
table,
and
then
you
get
it
back.
A
A
A
I
at
least
had
these
as
a
child,
so
maybe
that
taught
me
something
about
apis
already
as
three-year-old,
but
but
this
is
actually
how
the
whole
of
cloud
native
community
all
of
the
ecosystem
is
built
up.
So
we
start
by
by
defining
these
interfaces.
We
start
by
defining
these
ways
of
doing
things
without
specifying
exactly
how
we
do
things.
A
So
just
these
are
some
logos
of
some
cncf
projects
that
our
linux
foundation,
projects
that
actually
have
just
a
specification
just
a
description:
how
to
do
something
without
telling
you
exactly
how
to
do
it,
which
means
that
you
can
swap
out
the
the
the
process
that
is
actually
doing
it.
So
is
it
docker
or
is
it
crio
that
is
doing
containers?
A
It
doesn't
directly
matter
from
the
purpose
from
the
the
point
of
the
one
that
just
wants
to
have
a
container
or
metrics
or
storage
or
updating
software
it
goes
on
and
on
and
on.
So
this
is
really
the
the
the
second.
Why
of?
Why
is
kubernetes
doing
these
things?
Why
is
kubernetes
having
yaml,
for
example,
at
all
like
why
don't
we
just
run
commands
that
would
be
sshing
to
other
machines
directly?
A
This
is
why
we
want
to
tell
kubernetes
what
is
the
end
state.
What
is
the
logically
the
the
thing
we
want
to
see
in
an
optimal
world
and
then
kubernetes
will
try
to
make
that
happen
and
we'll
go
into
how
kubernetes
makes
that
happen
as
the
next
thing,
so
we
we
through
these
apis,
we
can
swap
different
implementations
from
each
other.
Achieving
portability,
so
kubernetes
runs,
for
example,
from
the
smallest
of
raspberry
pi's
on
arm.
It
runs
on
or
from
that
to
the
largest
cloud
servers
or
on
premise,
servers
or
whatever.
A
A
So
we
have
we
start
from
something
that
is
orderly
and
then
with
time
it
just
gets
messier,
messier,
messier,
messier,
more
chaotic
and
entropy
is
kind
of
a
meter
of
chaoticness
right.
So
anyone
that's
been
making
lunch
at
home
see
the
same
thing.
So
you
start
with
a
clean
kitchen,
then
you
make
lunch
after
you've
made
lunch.
It's
your
kitchen
is
messy
again,
that's
how
it
is
for
me,
but
then
I
need
to
do
my
dishes
to
actually
kind
of
fight
the
added
chaos
chaoticness.
A
It's
not
that
it's,
although
it's
inevitable
that
it
spontaneously
becomes
more
messy.
We
can
do
things
about
it
and
kind
of
make
our
system
orderly,
such
as
we
want,
but
my
sense
of
orderliness
in
my
house
might
not
be
the
same
as
orderlness
in
your
house
so
that
the
kind
of
the
definition
is
very
subjective
there
as
well.
So
I
de
this
declare
a
desired
state.
I
want
my
kitchen
to
look
like
this
and
when
it
looks
like
this,
I
call
it
orderly
right.
A
A
So
you
could
talk
about
kubernetes
being
the
dishwasher
of
servers
right.
So
in
you
put
in
messy
things
and
well
out
in
a
couple
of
minutes
or
even
seconds,
sometimes
you
get
out
a
clean
server.
Of
course
this
doesn't
hold
on
a
physical
level.
Kubernetes
software,
but
still
it
holds
on
a
conceptual
level
so
and
the
server
that's
coming
out
will
be
whatever
you
declared
to
be
the
desired
state.
A
So
one
more
kind
of
fun
just
side
note
on
entropy
is:
do
you
know
why
turning
it
on
and
off
again?
Actually
works,
it
works
because
it
minimizes
entropy.
So
when
you
are
working
on
your
computer,
for
example,
when
you
start
it
up,
you
have
a
clean
ram.
You
have
clean
everything
kind
of
the
state,
but
then
over
time
it
gets
messier.
It
has
like
a
lot
of
files
open
a
lot
of
ram.
You
know
things
like
that
in
use.
A
Programs
can't
take
everything
into
account,
so
this
won't
at
some
point,
have
some
some
messiness.
So
but
then,
when
you
start
it,
we
shut
it
down,
turn
it
back
up,
then
it's
more
likely
that
it's
actually
working
now
we
have
clean
entropy,
so
it's
kind
of
an
infinite
game
between
the
universe
and
our
sense
of
order
and
our
sense
of
order
also
changes
with
time,
but
we
always
periodically
need
to
to
fight
against
this
entropy
fight
against
the
chaos
nest.
A
A
The
revolves,
but
actually
the
blue
blue
arrow
is
where
the
system
actually
is.
Although
we
it's
not
matching
the
green
one
that
we
want
to
be,
so
that's
why
we
always
need
to
keep
nugging
the
system
up
and
down
make
things
the
way
we
we
want
it
to
be,
and
the
infinite
game
is
a
it's
a
good
book
about
these
kinds
of
ways.
It's
not.
A
Then
there's
more
to
it.
That's
randomness
the
from
physics.
This
is
heisenberg,
uncertain
principle,
which
says
that
we
can
we
we
have
an
upper
bound.
We
have
a
maximum,
we
can
know
about
what
an
atom
is
going
to
do,
which
means
we
can't
fully
predict
how
it's
going
to
evolve,
which
means,
by
extension,
that
there
is
no
way
that
we
can.
We
can't
even
look
at
the
single
atom
and
say
this
is
going
to
you
know:
do
this
in
the
future.
How
are
we
supposed
to
predict
large
systems
there's
no
way?
A
We
can't
at
all
predict
anything
in
the
future
and
I
really
recommend
the
black
swan
book
kind
of
really
ingraining,
that
when
you
read
it,
it's
a
really
good
book.
So
we
can't
predict
anything
for
the
future.
We
don't
know
how
how
things
will
evolve
and
google
has
in
their
work
paper.
As
I
said
where
some
of
the
theory
of
kubernetes
is
coming
from.
A
A
Load.
Spikes
machine
failures,
hardware
upgrades
whatever,
so
you
really
need
to
be
prepared
for
what
you
don't
know
will
happen,
and
that
is
really
hard.
There's
no
still
a
bullet
to
this,
but
just
designing
for
failure
is
the
first
step
which
needs
to
be
taken.
If
you
believe
that,
okay,
if
I
add
one
plus
one
in
a
computer
program,
it's
always
going
to
be
two:
no
it
won't.
A
A
There
is
all
kinds
of
randomness
that
we
can't
control
and
we
need
to
just
assume
that
failure
is
going
to
happen
and
then
kind
of
deal
with
it
from
another
perspective,
and
it's
really
hard.
It's
here
is
one
example
why
it's
so
unintuitive
to
us
as
well,
so
say
that
we
have
a
failure
that
happens
once
we
have
measured
it.
It
happens
once
in
every
10
000
times.
A
A
A
Interacting
that
they
are
seeing
the
randomness
that
affect
the
kind
of
effects
of
this
instantly
and
they
need
to
design
for
that
as
a
consequence
in
the
software
that
they're
doing,
but
as
a
small
scale
user,
it
will
take
a
long
time
before
you
see
the
effects
of
randomness
such
that
you
believe
at
some
point.
You
will
believe
that,
oh,
it's
not
there
and
then
crash
next
day,
and
then
you
have
an
outage
right.
A
So
so
it's
all
about
mental
model,
and
that
is
one
of
the
mental
models
which
is
key
to
how
kubernetes
has
been
designed.
Why
it
also
looks
overly
complex
at
first
glance,
but
it's
actually
necessary
complexity.
Of
course
there
is
kind
of
accidental
complexity
in
kubernetes
as
well.
I'm
not
saying
that
that
will
be
fixed
over
time,
and
you
can.
A
So
if
you
call
a
taxi,
you
will
say
that
I
am
here
and
I
so
the
the
in
valencia
at
the
conference
center
and
now
I
want
to
go
to
the
city
center
in
the
evening,
then
I
will
say
two
states,
I
will
say
my
actual
state
and
my
desired
state,
and
what
the
like
this,
what
the
taxi
driver
will
do
is
to
well
get
my
desired
state,
get
my
actual
state
and
then
do
an
action
plan.
So
take
the
difference
between
these.
So
I'm
here
I
want
to
go
here
now.
A
A
A
But
then,
when
we
have
some
kind
of
result,
we
will
need
to
or
kind
of
what
we
want
might
want
to
do
is
to
update
and
say
to
say
I'm
meeting
a
friend
in
the
city
and
then
the
taxi
driver
accidentally
gets
a
floor
like
that
taxi
gets
a
flat
tire
and
we
only
get
halfway
there.
Then
I
probably
will
need
to
call
my
friend
and
say
sorry
I'll
be
half
an
hour
late,
because
we
got
a
flat
tire
right.
So
then
I
do
kind
of
this
actual
state
update
again.
A
A
So
now
I'm
halfway
there
between
the
conference
center
and
the
city
center,
and
but
I
still
want
to
get
into
the
city
center.
Now
we
compute
a
new
action
plan,
do
all
of
that
and
inspect
the
system
again.
So
this
is
actually
the
way
kubernetes
all
of
kubernetes
controllers
work.
Kubernetes
has
probably
between
30
and
50
controllers
in
the
controller
manager
that
are
doing
this
constantly
all
the
time,
24
7.
A
looking
at
easy
state
what
the
user
said
it
should
be.
If,
yes,
then,
okay
I'll
check
back
in
30
seconds
again,
if
not,
then
take
action,
so
this
is
kubernetes
way
of
dealing
with
randomness
dealing
with
failures,
making
sure
that
although
we
weren't
successful
at
the
first
try,
maybe
there
were
rate
limits.
Maybe
there
were
just
outages
or
maybe
it
just
didn't
work
for
some
other
reasons,
but
then
trying
again
and
again
and
again,
eventually
we'll
we'll
get
there.
So
that's
the
notion
also
eventual
consistency
which
has
been
popularized
in
the
recent
years.
A
A
We
just
tell
that
what
is
the
end
state?
What
is
the
key
goal
of
the
system?
This
will
change
over
time
as
new
security
vulnerabilities
come
out
and
new
business
requirements,
but
we
tell
it
that
okay,
what
is
where
do
we
want
to
get,
and
then
we
have
some
something
like
kubernetes
to
fulfill
fulfill,
that
for
us,
and
that
is
the
industrial
revolution
of
server
computing.
A
So
to
end
with,
there
are
some
some
kind
of
further
reading
you
might
want
to
do
so.
This
is
a
brief
introduction
kind
of
just
to
get
started
with
this.
A
lot
more
things
to
unpack
for
this,
the
the
work
that
I'm
now
presenting
is
based
on
my
my
bachelor
thesis.
So
I
encourage
you
to
check
that
out.
It
has
loads
of
more
reading
load.
A
Some
more
context
and
my
my
idea
with
this
with
this
work
is
to
be
able
to
onboard
a
new
set
of
contributors
and
a
new
set
of
users
in
the
cloud
native
communities.
We
can
scale
our
communities
such
that
you're,
not
lacking
the
context.
You
need
to
make
the
decisions
that
have
to
be
made
and
and
this
thesis
is
made
as
kind
of
cloud
native
educational
material.
A
A
These
are
the
fundamental
principles,
but
it's
it's
just
scratching
on
the
surface,
there's
loads
more
to
unpack
and
over
time.
I
also
hope
that
we
can
kind
of
make
this
kind
of
summarized
version
or
on
some
web
page
or
something
similar
like
that
in
an
ideal
case
and
there's
also
loads
of
more
interviewing.
That
needs
to
be
done
from
from
the
the
founder
from
the
people
early
on
in
the
project
such
that
we
don't
lose
that
context
for
the
next
generations.
That
will
build
cloud
native
further
for
the
years
to
come.
A
In
fact,
the
controller
model
that
I
was
just
saying
is
exactly
the
same
as
a
closed
loop
control
system,
which
you
have
what
you're
using,
for
example,
when
you
have
the
cruise
control
in
your
car,
that's
exactly
the
same
thing
exactly
the
same
model,
so
I
recommend
control
theory.
Looking
up
that
a
bit
more
here
is
a
good
walkthrough
from
kubernetes
contributor,
valerie
lancer,
that
from
qcon,
and
then
we
have
even
mentioned
in
the
kubernetes
documentary
promise.
A
A
A
Then
we
find
the
entropy
the
inevitable
chaos,
the
inevitable,
spontaneous
chaos
by
periodically
doing
corrective
action.
And
finally,
we
have
designed
the
controller
model
according
to
control
theory
in
order
to
kind
of
mitigate
the
effects
of
randomness
over
a
long
time.
So
that's
it,
and
if
you
have
questions
you
can
ask
them.
B
One
question:
hi
lucas
great
great
talk.
I
can't
help
but
think
okay.
Well,
it's
like
we.
Everyone
wanted
to
sort
of
contribute.
You
know
and
there's
this
like
really
beneficial
patterns
that
are
producing
the
kubernetes
project
and
also
the
cloud
native
ecosystem
around
it
and
think
like
is
there?
Is
there
anything
that
you
can
say
about
how
these
values
in
our
software
kind
of
also
affect
the
way
that
our
community
works
together?.
A
One
good
thing
about
the
extensibility,
for
example,
focusing
on
the
apis
and
that
the
kind
of
desired
state
first
allows
us
to
kind
of
find
in
the
community
different
kind
of
good
patterns
of
implementing
the
same
kind
of
problem
space,
and
it
allows
us
to
kind
of
not
have
just
one
kind
of
winner
or
one
kind
of
solution
that
has
monopoly
of
everything,
but
instead
see
that.
Okay,
maybe
this
actual
implementation
is
better
for
this
case.
A
If
you
optimize
for
this
and
then
but
then
this
other
way
is
better
for
some
other
use
cases.
So
that
is
one
one
concrete
way
of
the
declarativeness
kind
of
being
a
good
way
for
a
community,
and
then
it
also
lets
people
build
on
top
of
each
other.
So,
like
kubernetes,
is
a
foundational
piece
of
software
for
distributed
systems,
but
a
normal
user
might
want
to
use
a
platform
which
is
built
on
top.
But
then
we
still
share.