►
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
Kubernetes Design Principles: Understand the Why - Saad Ali, Google
Kubernetes is quickly becoming indispensable for managing and deploying workloads on distributed systems across both cloud and on-prem environments. While most people are now familiar with how to use Kubernetes, few are aware of the “why” behind it? Why does the Kubernetes API look the way it does? Why do Kubernetes components only interact with each other through the Kubernetes API? Why is there a PersistentVolumeClaim object when you could easily reference a volume directly from a pod? To answer these questions and help you develop a deeper understanding of Kubernetes, this talk exposes the principles underpinning the design of Kubernetes.
To learn more: https://sched.co/IrkE
A
So
my
name
is
Sally
I'm,
a
software
engineer
at
Google
I
started
on
the
Google
kubernetes
team,
pretty
early
on
way
back
in
December
of
2014,
when
the
team
was
pretty
small
and
it
was
before
kubernetes
1.0
I
was
a
young
engineer.
There
was
a
lot
that
I
didn't
know
and
I'm,
not
very
smart.
So
you
know
I
didn't
really
pick
up
on
the
kubernetes
ideas
very
quickly.
A
For
me,
when
I
start
to
learn
things
learning
all
the
little
things
how
to
do
them
doesn't
really
work
for
me,
what
I
need
to
do
is
try
to
understand
why
things
work,
the
way
that
they
do
and
that
kind
of
sticks
better
in
my
head
and
so
I
recognized
some
patterns
that
I've
seen
in
kubernetes
and
that
kind
of
helped
me
understand
the
API
and
understand
how
kubernetes
works
a
lot
better,
at
least
for
me.
So
I
was
hoping
to
share
some
of
that
with
you
today
for
a
lot
of
you.
A
So,
what's
in
it
for
me,
a
deeper
understanding
of
kubernetes
again,
an
important
tool
for
learning
is
to
understand
the
problem,
the.
Why
not
just
the
what,
if
you
get
a
large
collection
of,
what's
it's
impossible
to
memorize
everything?
But
if
you
understand
the
fundamentals
of
how
things
work,
then
it's
easy
to
extrapolate
and,
under
you
know,
come
up
with
your
own
understanding
of
how
things
should
work
and
that
can
lead
you
pretty
far.
A
A
Well,
just
to
recap
and
set
the
stage
I
want
to
introduce
what
the
problem
space
was
that
we
were
working
with.
You
know
before
kubernetes
was
a
thing
before
docker
was
a
thing
folks
were
running
distributed
systems
largely
either
on
bare
metal
or
in
virtual
machines.
When
containerization
started
to
take
off
it,
provided
a
way
to
be
able
to
do
consistent,
repeatable,
reliable
deployments,
you
could
have
multiple
applications
coexist
on
the
same
machines
and
not
have
to
worry
about
their
dependencies
colliding,
for
example.
A
But
you
know,
containers
are
great,
but
you
have
to
figure
out
how
to
actually
deploy
those
containers
at
scale
and
that's
where
kubernetes
came
in.
You
didn't
want
to
get
into
the
business
of
actually
writing
your
own
system
to
be
able
to.
You
know
SSH
into
every
machine
and
start
a
docker
container
and
write
some
monitoring
service
to
monitor
those
containers.
So
kubernetes
really
filled
that
niche.
Well,
let's
take
a
step
back
and
talk
about
the
very
fundamental
operations
in
kubernetes.
So
how
do
you
deploy
a
workload
on
kubernetes
when
I
first
came
to
kubernetes?
A
My
understanding
was
kind
of
based
on
my
previous
knowledge,
which
was
very
much
a
you
know.
There
is
two
entities
and
there's
a
master
and
a
slave,
and
the
master
tells
the
slave.
What
to
do
in
this
case?
You
know
you
have
a
user,
a
user
wants
to
start
a
container.
The
model
in
my
head
traditionally.
Would
be
they
pick
a
machine
and
they
say
start.
You
know
this
container
on
that
machine.
A
Of
course,
there's
a
set
of
problems
with
this
approach.
What
happens
if
that
container
crashes?
So
this
was
the
model
that
I
was
talking
about
before
kubernetes,
where,
if
you
were
SSH
into
machines
and
starting
your
container,
that
container
died
or
that
node
died,
or
you
know
for
some
reason
that
SSH
connection
dropped
for
a
second
and
you
weren't
able
to
actually
get
that
container
started.
What
happens?
You
have
to
write
a
lot
of
custom
recovery
logic
to
monitor
your
service,
monitor
your
application,
and
then
you
have
to
take
recovery
action.
A
So
this
is
where
the
first
principle
of
kubernetes
comes
in,
and
that
is
that
the
kubernetes
api
is
declarative
rather
than
imperative.
So
in
kubernetes
you
do
not
tell
the
system
start
this
container
on
this
machine
instead
used
to
define
the
desired
state.
You
say
that
I
want
to
have
a
container
running.
A
Please
make
it
so
this
is
the
difference
between,
for
example,
a
pilot
flying
a
an
airplane
themselves
versus
setting
an
autopilot
when
they're
flying
the
plane
themselves,
they're
constantly
providing
input,
they're
monitoring
their
trying
to
figure
out
where
it
should
go
when
they
set
an
autopilot.
The
computer
takes
over
and
there's
control
systems
that
monitor
and
make
sure
that
whatever
the
requested
altitude
is
maintained,
so
you
can
think
of
the
declarative
API
in
a
similar
way.
It's
a
way
to
say
this
is
what
I
want
my
intended
state
to
look
like.
A
A
So,
let's
get
a
little
bit
more
concrete.
The
way
that
you
create
or
do
anything
in
the
kubernetes
api
is
that
you
create
an
API
object
that
is
persisted
on
the
cube
api
server
until
you
delete
it
and
all
the
components
within
kubernetes
will
work
in
parallel
to
drive
towards
that
state.
So,
for
example,
when
you
want
to
get
a
workload
running,
you
can
use
one
of
the
basic
primitives,
the
replica
set,
which
many
of
you
are
probably
familiar
with
that
says:
I
want
to
create
a
container.
A
Maybe
an
engine
X
container
and
I
want
one
replica
that
running
across
my
system
once
that
object
is
created,
the
system
kind
of
figures
out
what
needs
to
be
done
next
and
schedules
the
workload
appropriately
and
gets
it
started
you're
pretty
much
hands-off.
At
that
point,
you
don't
need
to
go
in
and
monitor
the
status
of
your
workloads
that
all
kubernetes
will
take
care
of
it
and
what
is
the
benefit
of
this
approach?
A
This
declarative
approach
and
the
primary
benefit
is
automatic
recovery,
meaning
if
something
happens
to
your
application,
if
the
application
crashes,
if
the
node
crashes
kubernetes,
will
automatically
take
care
of
recovering
that
application
for
you
moving
it
around
so
now,
let's
revisit
this
or
deep
dive
into
this
a
little
bit
more.
So
what
act
Tooley
happens
when
you
create
a
replica
object
on
the
kubernetes
api
server.
A
You
say:
I
want
a
pod
of
you
know
a
certain
definition
created
on
my
cluster.
How
does
the
node
figure
out
that
it's
supposed
to
be
running
this?
Does
the
master
tell
it
like?
How
does
all
of
that
work?
My
natural
inclination
would
be
that
since
you
have
a
master,
the
master
would
figure
out
which
node
this
particular
workload
would
be
scheduled
on,
and
then
it
would
just
call
out
to
that
node
to
say.
Please
start
this
container
and
that's
if
you
look
at
a
lot
of
traditional,
you
know
server,
client
setups.
A
A
A
The
master
would
have
to
begin
to
store
the
state
of
every
single
component
that
it
was
responsible
for
it
would
have
to
play
catch-up
every
time
it
discovered
that
these
components
weren't
doing
what
they
were
expected
to.
So
first,
it's
figuring
out
what
they're
supposed
to
do
understand
that
they're
not
doing
what
they're
supposed
to
do
and
then
issue
follow-up
commands
to
fix
that.
So
that
means
that
every
time
uber
Nettie's
is
extended
every
time
a
new
component
is
added.
A
This
master
control
plane
grows
larger
and
larger
and
larger,
and
if
kubernetes
had
been
built
that
way,
honestly
I,
don't
think
it
would
have
been
very
successful.
It
would
have
made
the
master
very
complex,
brittle
difficult
to
extend.
So
this
is
where
the
second
principle
of
kubernetes
comes
in,
and
that
is
that
the
kubernetes
control
plane
is
transparent
and
that
there
are
no
hidden
internal
api's.
A
This
is
extremely
powerful
for
multiple
reasons.
What
does
it
mean?
Actually,
what
it
means
is
that
that
same
declarative,
API,
that
we
exposed
to
the
end
users
is
the
same
API
that
all
the
internal
kubernetes
components
use
to
interact
with
each
other,
and
so
the
benefits
of
that
declarative
API
then
apply
to
the
components
themselves.
A
So,
whereas,
before
the,
if
we
had
followed
the
model,
that
I
was
suggesting
earlier,
where
the
master
would
call
out
to
individual
nodes
to
tell
them
what
to
do,
if
we
follow
that
model,
you
would
imagine
a
master
would
have
to
provide
a
exact
set
of
instructions
to
say
the
node
should
do
something.
The
node
would
execute
those
instructions
and
return
a
response,
and
then
the
master
would
have
to
have
some
sort
of
way
to
monitor
those
nodes
and
then
issue
you
know,
commands
to
rectify
anything
that
went
wrong.
A
Instead,
what
happens
is
that
the
master
basically
defines
a
desired
state
for
a
node
to
be
in
once
the
master
figures
out
that
a
workload
should
be
scheduled
on
a
particular
node.
It
will
essentially
state
that
in
the
API
server,
so
the
master
just
talks
to
the
API
server
and
then
all
the
components,
including
the
node
work
independently
to
drive
themselves
towards
that
state.
So,
let's
take
a
look
at
what
that
looks
like
more
concretely.
A
So
the
way
to
think
about
it
is
that
the
kubernetes
api
server
is
the
center
of
everything
in
the
kubernetes
world.
This
is
what
you
interact
with,
but
it's
also
what
every
other
component
in
kubernetes
interacts
with.
So
basically,
what
happens
is
that
all
the
nodes
when
they
first
come
up
will
monitor
the
kubernetes
api
server
to
try
and
figure
out
what
are
they
supposed
to
be
doing
so,
instead
of
having
the
decision
being
centralized
and
being
sent
out,
every
component
is
responsible
for
its
own
health
and
keeping
itself
running.
A
So
whenever
a
component
comes
up,
it
goes
to
the
API
server,
to
figure
out
what
it
should
be
doing.
The
benefits
of
this
approach
are
that,
if
a
component
crashes
for
some
reason-
and
it
comes
back
up,
it
can
easily
recover
just
by
looking
at
the
API
server
and
figuring
out
what
it's
supposed
to
be
doing.
This
pattern
is
called
level
triggered
instead
of
edge
triggered.
A
So
this
is
the
way
that
the
kubernetes
API
works
again
and
let's
just
walk
through
that.
So
you
as
a
end
user,
operate
against
the
same
kubernetes
api.
You
declare
that
you
want
a
workload
running,
you
define
what
that
should
look
like
and
then
your
hands
off
now
there's
a
object
that
exists
in
the
API
server.
That
defines
what
should
be
happening
and
all
the
other
components
are
watching
the
kubernetes
api
server
going.
Oh
something
needs
to
happen
here.
I
need
to
make
sure
that
I
do
something.
A
The
scheduler
is
just
another
component
in
kubernetes
that
all
it
does
is
monitor
the
kubernetes
api
server.
Looking
for
unscheduled
pods,
unscheduled
pods
are
just
API
objects
that
are
of
type
pod
and
don't
have
the
node
field
filled
in.
So
if
it
finds
one
of
those,
it
starts
executing
its
logic
to
figure
out
what
the
best
placement
for
this
particular
pot
is
going
to
be
once
it
makes
that
determination.
Instead
of
calling
out
to
that
node,
it
just
updates
the
API
object
to
say
hey.
A
This
object
has
now
officially
been
scheduled
to
a
particular
node
and
then
the
node
that
it
gets
scheduled
to
is
also
watching
for
pod
objects.
But
it's
filtering
those
pod
objects
too
pods
that
match
the
same
name
as
itself.
So
it's
a
very
simple
concept
but
very
powerful,
and
once
a
node
recognizes
that
there
is
a
pod
that
should
be
scheduled
to
itself.
A
It
can
look
locally
and
see
if
that
the
containers
for
that
pot
are
running
or
not
and
start
the
process
of
getting
those
things
running
and
as
long
as
that,
as
that
API
object
exists,
the
the
node
agent,
the
cubelet,
can
basically
ensure
that
it's
remains
in
that
state.
So
if
that
application
crashes
for
some
reason
and
the
pod
indicates
that
it
should
be
restarted,
the
the
the
node
the
cubelet
agent
can
automatically
do
that.
A
So
then,
when
you're,
when
you
decide
that
you
don't
want
that
workload,
you
simply
remove
the
API
object
from
the
master
and
then
the
components
see
that
there's
a
difference,
there's
something
running
in
the
system
and
that
doesn't
correspond
to
the
desired
state
set
by
the
user.
So
all
the
components
will
work
to
drive
towards
the
desired
state
which
in
this
case
is
please
stop
work
running
this
workload.
It
should
not
be
running.
A
So
what
are
the
benefits
of
this?
No
hidden
internal
API
principle,
I?
Think
I
talked
a
little
bit
about
this.
Already
components
that
are
level
triggered
instead
of
edge
trigger,
tend
to
be
more
robust,
especially
for
distributed
systems
where
you
have
to
expect
that
you're
gonna
have
so
many
components
that
make
up
your
system.
Something
is
always
going
to
be
failing,
and
so
you
have
to
design
your
system
for
reliability
and
tolerate
be
able
to
tolerate
failure
if
any
one
of
those
components.
A
So
if
your
system
did
was
edge
triggered,
it
would
have
to
be
much
more
complicated
in
order
to
have
one
component
constantly
figure
out
what
the
state
of
everything
should
be
and
figure
out
where
what
it
should
be
doing.
Instead,
if
you
distribute
that
responsibility
to
every
single
component
to
figure
out
what
that
component
itself
should
be
doing,
it
makes
the
system
more
reliable,
but
also
more
extensible,
and
there
is
also
no
more
single
point
of
failure.
A
If
the
kubernetes
api
server
goes
down,
all
the
components
continue
to
operate
on
whatever
the
last
date
was
that
they
saw,
and
when
the
kubernetes
api
server
comes
up
again,
they
can
start
operating
on
whatever
the
new
state
is
and
if
any
one
of
those
components
goes
down,
the
other
components
can
continue
to
function
independently
of
that.
So
the
there
is
no
single
point
of
failure,
and
the
system
overall
is
more
robust.
A
You
could
swap
out
any
one
of
these
components
with
your
own
implementation,
so,
for
example,
if
you
wanted
to
write
your
own
scheduler,
all
you
need
to
do
is
write
a
binary
that
is
able
to
interact
with
the
kubernetes
api
server
and
fill
in
the
node
field
of
a
pod
object.
That
is
what
a
scheduler
does
it.
It
looks
at
pod
objects.
It
runs
some
algorithm
to
figure
out
where
it
should
be
run
and
it
updates
the
API
server.
So
you
could
write
a
custom
schedule
or
for
kubernetes
pretty
easily.
Of
course
writing
a
custom.
A
Ok
now,
let's
talk
about
some
of
the
interesting
information
that
exists
on
the
kubernetes
api
server.
We
have
the
idea
of
secrets,
you
know
if
you
have
some
sensitive
information,
you
should
not
be
putting
those
inside
a
few
containers.
Obviously
that
information
should
somehow
be
injected
inside
your
container
at
runtime,
so
that
these
sensitive
things
aren't
going
to
be
leaked
along
with
your
container
and
the
facility
that
kubernetes
provides
to
do
this.
Is
the
secret
API
object
in
kubernetes?
A
Similarly,
there
is
a
way
to
be
able
to
provide
configuration
information
to
your
application,
so,
for
example,
your
application
may
have
some
set
of
startup
parameters
for
a
particular
configuration
or
whatever
other
configuration
information
you
may
have,
and
downward
api
is
another
kubernetes
api
that
allows
you
to
fetch,
basically
name
namespace,
UID
pod
information
about
the
pod
that
this
workload
is
running
in
all
of
this
information
can
be
very
valuable
to
the
application
itself.
So
how
does
a
kubernetes
application
get
access
to
this
information?
A
We
talked
about
the
fact
that
this
kubernetes
api
is,
you
know
it's
the
same
api,
that's
used
by
the
internal
components,
which
means
that
if
you
write
an
application
that
needs
to
use
a
secret,
you
could
basically
have
that
application
call
out
to
the
kubernetes
api
server
to
fetch
that
secret
and
use
it
within
your
application.
You
can
also
have
a
call
out
to
the
kubernetes
api
server
to
fetch
information
about
the
pod
that
it's
running
in
or
any
configuration
information
from
the
config
map.
Api
objects.
A
A
A
So
what
we
did
was,
in
addition
to
being
able
to
call
out
to
the
kubernetes
api
server.
There
is
the
ability
for
you
to
consume
secrets,
config
maps
and
downward
api
objects
as
files
within
the
container
or
as
environment
variables.
So
as
part
of
your
pod
definition,
you
can
specify
please
expose
to
my
containers.
A
This
set
of
secrets
or
config
map
information
and
kubernetes
will
automatically
make
sure
that
that
information
is
either
mounted
in
as
a
file
into
that
container
or
as
an
environment
variable,
and
so
your
application
doesn't
have
to
be
modified
as
long
as
it
knows
how
to
read
a
file
or
read
from
an
environment.
Variable.
A
So
why
did
we
do
this
and,
of
course
the
reason
is
to
minimize
the
hurdles
for
developing
applications
to
deploy
on
kubernetes?
We
want
to
make
it
as
seamless
and
easy
to
transition
to
kubernetes
as
possible
again
I.
Keep
mentioning
that
you
know
there
are.
These
are
the
reasons
why
kubernetes
has
been
successful
and
I.
Think
one
of
the
reasons
is
because
it
made
it
easy
to
transition
some
of
the
existing
applications
to
kubernetes.
A
Ok,
next
up,
let's
talk
about
remote
storage.
This
is
an
area
that
I
am
very
familiar
with
I'm.
The
storage
stake
lead,
and
the
idea
here
is
that
you
know
you.
Containers
alone
are
not
sufficient
because
they
are
ephemeral.
If
you
start
a
container
and
you
write
anything
inside
of
that
container,
that
file
system
gets
basically
deleted.
As
soon
as
that
container
is
terminated.
A
If
you're
running
any
sort
of
stateful
application,
you
need
some
way
to
be
able
to
persist
state
beyond
the
life
of
an
individual
pod
and
the
facility
that
kubernetes
provides
to
do
this.
Our
kubernetes
volume
plugins.
We
have
a
number
of
volume
plugins
that
allow
you
to
plug
into
remote
storage
systems.
So,
if
you're
running
in
a
cloud
environment
you
could
be
using,
for
example,
GC,
persistent
disks
or
Amazon
EBS
block
volumes,
you
could
use
an
NFS
share
of
different
options
exist.
A
One
way
to
be
able
to
use
them
is
in
your
pod
definition
to
directly
reference
the
type
of
volume
plug-in
that
you
want.
This,
of
course,
isn't
the
exact
gamal
that
you're
going
to
use,
but
the
idea
is
that
inside
your
pod
configuration
file,
you
specify
the
volume
that
you're
going
to
use.
So
in
this
case,
I
would
say
that
I
want
to
use
a
GC,
persistent
disk
named
PD
one.
So
as
soon
as
I
define
that
on
the
API
server,
kubernetes
now
needs
to
figure
out
how
to
make
that
volume
available
to
the
container.
A
And
how
does
it
do
that?
So?
First
up
we
have
our
lovely
scheduler
that'll
kick
in
and
try
to
figure
out
where
this
volume
of
this
workload
should
be
scheduled.
It
realizes
that
node
one
has
availability,
so
it's
going
to
schedule
Tod
a
to
node
one
simply
by
updating
the
pod
configuration
API
to
add
a
field
that
says
it's
been
scheduled
to
node
one
now
there's
a
second
component.
This
is
the
attached
detached
controller.
A
The
attached
detached
controller,
like
every
other
component
in
kubernetes,
is
monitoring
the
kubernetes
api
and
acting
on
a
set
of
API
objects.
In
this
case,
it
is
looking
for
pods
that
have
been
scheduled
to
a
node
and
are
also
referencing
a
remote
volume.
When
it
finds
one
of
these
pods,
what
it
does
is
figure
out,
if
that,
if
that
volume
is
available
on
this
on
the
node
that
it
has
been
scheduled
to
so,
for
example,
in
this
case
pod
a
has
been
scheduled
to
node
one,
but
GCE
PD
one
is
not
available
on
node
one.
A
It
didn't
use
to
do
that,
but
with
the
current
iteration
with
CSI
one
point
and
which
is
coming
out
in
kubernetes
1.13,
there's
a
new
object
called
the
volume
attachment
object,
which
represents
the
state
of
a
volume
attachment
and
that's
used
to
communicate
back
and
forth,
and
that's
through
the
the
kubernetes
api
server.
So
once
a
volume
is
attached
to
the
node,
the
cubelet
basically
is
just
operating
on
API
objects
and
it
notices
that
there
should
be
a
pod
running
and
this
pod
is
referencing
a
GC
persistent
disk.
A
So
it
will
monitor
the
node
object
to
figure
out
whether
that
volume
has
been
attached
to
that
node
or
not
once
it
has
been
attached,
it'll
go
ahead
and
proceed
with
making
that
volume
available
inside
the
container.
So
when
your
container
starts
on
this
machine
that
remote
volume
is
now
available
inside
your
container
and
anything
that
you
write
to,
that
directory
will
be
persisted
to
that
disk
if
your
volume
dies
for
any
reason,
it
gets
rescheduled
to
a
different
machine.
The
attached,
detached
controller
will
move
that
volume
to
the
other
machine
and
your
persist.
A
Your
storage
is
available.
Anything
that
you
wrote
is
persisted
whenever
that
container
comes
up
on
any
other
machine,
so
this
pattern
is
very
powerful
and
it
uses
a
lot
of
what
we've
been
talking
about.
But
it's
not
something
that
you
should
be
doing.
You
should
never
reference
a
particular
type
of
storage
directly
inside
your
pod,
and
let
me
talk
about
why
that
is
the
case.
A
The
problem
is
that
when
you
reference
a
particular
type
of
storage
inside
your
pod,
your
pod
definition
is
no
longer
no
longer
portable.
So
if
I
reference
a
GC,
persistent
disk
directly
inline
in
my
pod
definition,
if
I
were
to
take
that
pod
definition
and
move
it
to
AWS
or
on-prem,
where
that
GC
persistent
disk
storage
just
doesn't
exist,
my
pod
is
not
going
to
be
able
to
start
running.
So
in
order
to
fix
this
problem,
we
created
an
interface
called
the
PVC
and
the
PV,
a
persistent
volume
claim
and
a
persistent
volume.
A
The
purpose
of
these
objects
is
to
decouple
the
request
for
storage
from
the
actual
implementation
of
storage.
So
now,
in
your
pod
definition,
instead
of
referencing
a
GC
persistent
disk,
what
you
would
reference
is
a
claim.
A
persistent
volume
claim
and
a
persistent
volume
claim
is
simply
another
kubernetes
api
object.
This
kubernetes
api
object
contains
generic
information
about
the
type
of
storage
that
you
want.
It
could
include
things
like
the
capacity
of
the
storage.
You
want
the
access
mode,
whether
it's
readwrite
read-only
information
like
that.
A
One
is
that,
as
a
cluster
administrator,
you
could
create
PV
objects
ahead
of
time
that
represent
the
storage
that's
available
on
your
cluster
and
then
the
persistent
volume
controller
will
bind
any
PVCs
that
it
sees
with
an
available
piece
of
storage
whenever
the
pvc
object
is
created.
So
what
this
means
is
that,
if
you
were
to
transition
into
another
environment,
your
pod
and
PVC
objects,
the
objects
that
are
user-facing
are
now
portable.
So
as
soon
as
you
drop
it
onto
a
new
cluster.
A
As
long
as
there
are
some
PV
available
on
that
machine
that
can
fulfill
your
PV
C
they'll
get
bound
and
you'll
have
persistent
storage
available
to
you.
This
goes
a
step
further
with
the
storage
class,
which
allows
automatic
provisioning
of
storage.
So
if
the
PVS
have
don't
pre
exist
and
there's
a
storage
class
defined
on
your
system,
when
a
PV
C
is
created,
the
storage
class
defines
how
to
create
new
storage
from
scratch
and
that
storage
class
is
specific
to
that
cluster
environment.
A
And
so,
as
long
as
a
storage
class
with
the
same
name
exists
in
both
environments,
some
sort
of
storage
will
be
able
to
be
created
for
you,
work
load
to
be
able
to
for,
for
you
to
use
and
the
application
specific
API
objects
that
you
have
remained
portable
across
environments,
and
this
is
basically
the
fourth
principle
of
kubernetes.
It's
about
workload,
portability
and
I
think
this
is
the
most
critical
piece
of
kubernetes
the
way
that
I
think
about
it
is
like
an
operating
system.
A
If
you
went
back
before
operating
systems
or
a
thing
folks
were
writing
applications
directly
for
specific
hardware
and
those
applications
were
not
portable
across
different
machines
and
an
operating
systems
basically
said.
Don't
worry
about
the
underlying
hardware.
That's
available
on
this
particular
machine
right
to
this
interface
that
I
provide
you
and
as
long
as
this
operating
system
is
running
on
one
of
these
environments,
your
application
will
work
and
that
allowed
application
ecosystems
to
thrive
in
the
distributed
systems.
Space
we
haven't
really
had
anything
equivalent
for
a
very
very
long
time.
Basically,
everybody
was
writing.
A
Custom
applications
for
custom
cluster
implementations
and
what
kubernetes
has
done
is
it's
acting
like
an
operating
system
for
distributed
systems.
It
basically
has
southward
facing
API.
Is
that
it'll
hook
into
different
clusters,
and
it
has
the
kubernetes
api
that
it
exposes
to
end
users
and
as
long
as
application
developers
deploy
against
that
kubernetes
api.
As
long
as
kubernetes
exists
on
that
cluster,
their
application
just
works,
it
doesn't
need
to
be
modified.
It
can
be
moved
around
from
cluster
to
cluster
to
cluster.
A
It
basically
excuse
me
a
decouples
distributed
system
application
development
from
cluster
implementation.
It
acts
like
a
true
abstraction
layer,
so
in
review,
the
four
principles
that
I
talked
about
were
the
cube
API
server
being
declarative
rather
than
imperative.
I
want
to
get
some
audience
participation.
Can
someone
tell
me
why
that
is
important?
A
That
is
an
excellent
point,
so
act
should
include
that
in
the
presentation
as
well.
His
point
was
that
it's
immutable,
regardless
of
the
the
great
thing
about
this
kind
of
configuration
that
kubernetes
has
is
you
can
actually
check
it
in
two
source
code
and
it's
repeatable
you
can
deploy
you?
Can
you
know
how
to
create
a
application
from
scratch?
As
long
as
you
deployed
this
set
of
llamó
files
on
any
cluster
that
has
kubernetes
you're
going
to
have
your
application
running,
so
it
is
immutable.
A
A
That's
right:
it's
a
it's,
a
portability
layer.
It's
an
abstraction
layer.
There
is
a
principle
of
being
able
to
separation
of
concerns.
Basically,
if
you
design
your
system
with
a
separation
of
concerns
and
you
isolate
different
components
with
very
distinct
of
basically
contracts
between
them,
it
becomes
much
more
easier
to
test
much
easier
to
upgrade
and
maintain
overall
and
kubernetes
basically
acts
as
a
separation
of
concern,
abstraction
layer
that
says,
don't
worry
about
anything
below
this
layer.
I'll
take
care
of
that.
You
worry
about
the
application
layer.
That
is
all
that
I
have.
A
Good
question,
so
the
question
is
about
CR
DS,
custom
resource
definitions
and
how
they
relate
to
pot
objects
or
any
other
API
object
that
currently
exists
as
a
built-in
type
in
the
kubernetes
api.
So
for
those
of
you
who
aren't
familiar
with
what
CR,
DS
r
CR
DS
are
a
way
to
be
able
to
write
your
own
custom,
kubernetes
api
object
type.
So,
for
example,
you
are
probably
familiar
with
the
node
API
object
or
the
pod
API
object.
A
But
if
you
wanted
to
create
your
own
API
object,
the
CRD
allows
you
a
very
easy
way
to
do
that.
You
define
a
new
CRD
of
your
type
and
you
define
the
schema
for
what
that
looks
like
and
then
you
can
create
your
own
objects.
You
could
call
it.
You
know
foo
or
blah
or
whatever
you
want
against
the
kubernetes
api
server,
and
then
you
could
write
your
own
custom
controllers
that
use
those
CRS
and
C
RDS
to
basically
act
extend
kubernetes,
and
so
the
question
is
how
they
relate
to
these
built-in
types.
A
I
like
to
repeat
what
Tim
Hawkins
said
about
this,
which
is
that
if
we
had
C
or
D
Zonday
0
for
kubernetes,
there
would
be
no
built-in
types.
The
idea
is
that
the
kubernetes
api
machinery
should
be
distilled
down
such
that
it
can
be
used
as
just
API
machinery
for
any
project,
not
just
kubernetes,
so
we're
starting
to
see
it
be
used
for
things
like
Sto
and
other
higher-level
projects,
and
there
should
be
no
built
in
API
types,
meaning
that
if
we
started
from
day
0
pods
nodes,
everything
else
would
also
be
a
CR
D.
A
Yes,
well,
persistent
volume
claim
is
similar
to
a
pod
when
we
first
came
up
with
a
persistent
volume
claim
and
PV.
It
was
kind
of
modeled
after
a
pod
in
a
node
where
a
node
represents
the
cluster
resource.
That's
available
and
a
pod
represents
kind
of
a
request
for
using
that
resource.
So
a
PV
represents
the
resource.
The
storage
resource,
that's
available
on
that
cluster
and
a
PV
C
represents
a
user's
desire
to
use
that
resource
and
they
kind
of
bind
together.
A
Right,
yes,
so
so
the
comment
is
that
one
of
the
drawbacks
of
a
declarative
system
is
that
you
can't
offer
consistency
guarantees,
and
this
is
absolutely
true,
which
is
why
kubernetes
is
an
eventually
consistent
system.
It
will
try
essentially
forever
to
drive
towards
the
state
that
you
specify-
and
this
works
well
for
a
lot
of
the
use
cases
that
we
have
in
kubernetes,
especially
in
terms
of
getting
workloads,
running
and
keeping
them
running.
But
it
is
definitely
a
challenge
when
we
have
patterns
that
don't
necessarily
fit
into
this
model.
A
Well,
so,
for
example,
on
the
storage
side
of
things,
we're
looking
at
the
ability
to
take
a
snapshot,
a
snapshot
is
a
very
point
in
time,
time
constrained
operation
and
when
you
have
something
like
that,
it
is
a
little
bit
difficult
to
model
in
a
declarative
API.
If
you're
interested
you
can
come
to
the
storage
sake,
and
we
can
talk
about
how
we're
trying
to
make
that
work.
There
are
issues
with
it,
but
we
have
been
able
to
get
something
working.