►
From YouTube: Imperative, Declarative, and Kubernetes
Description
Kubernetes Community Days Bengaluru'21
The key to understanding a lot of the "why's" of Kubernetes is to understand the concept of what imperative systems are, what declarative systems are, how they differ and how Kubernetes enables a declarative and extensible model through something known as the controller pattern. You will gain an intuitive, yet deep understanding of what these concepts of 'Imperative Systems' and 'Declarative Systems' are, followed by how Kubernetes employs some of these concepts to enable extensibility and self-healing capabilities.
Slides: https://drive.google.com/file/d/1-eSW_mLpcD9azY9PSDILC73EUyf_2I8F/view?usp=sharing
A
A
So
we'll
start
off
by
asking
the
question:
what
even
is
kubernetes
then
we'll
get,
and
we
look
at
some
intuitive
way
of
looking
at
what
imperative
and
dictator
systems
are
we
formalizing
just
a
little
bit
to
try
and
build
a
mental
model
of
things.
Then
we'll
have
we'll
do
a
small
demo
to
try
and
understand
the
differences
between
imperative
and
declarative,
which
is
better.
A
A
So
if
you
click
on
that,
this
is
what
you
get,
and
I
realized
that
I
wasn't
sure
I
understood
what
the
sentence
meant.
I
understood
parts
of
it
in
terms
of
I
understood
what
extensible
meant,
what
managing
meant,
what
containerized
workloads
meant,
but
I
wasn't
sure
why
what
this
whole
thing
together
meant
entirely.
So
I
thought:
okay,
let's
break
it
down
into
smaller
bits
and
try
and
understand
some
of
these
smaller
parts.
So
if
you
were
to
break
it
down,
it
would
look
something
like
this,
so
why
is
kubernetes
extensible?
A
A
Today's
talk
on
a
high
level
is
structured.
Something
like
this
we'll
talk
about
what
imperative
and
declarative
apis
are.
What
the
differences
is.
We'll
talk
about.
What
the
controller
pattern
of
doing
things
is
we'll
talk
about
what
self-healing
means
and
then
finally,
we'll
talk
about
how
kubernetes
fits
into
all
of
this,
meaning
that
why
does?
Why?
Did
it
take
the
controller
pattern?
Why
did
it
take
the
decorative
api
and
how
does
it
do
cell
feeling?
A
So
imperative
systems,
let's
try
to
get
an
intuitive
understanding
of
these
things.
Imperative
systems
describe
how
you
want
to
achieve
something.
So
let's
say
our
goal
is
to
go
on
a
vacation,
so
you,
as
a
person,
know
what
your
what
your
goal
should
be,
meaning
that
you
do
some
initial
research
in
terms
of
what
your
budget
is,
where
you
want
to
go,
what
you
want
your
living
arrangements
to
be
like
and
what
you
want
cuisine
if
you
have
any
question
preferences.
A
So,
having
known
your
goal,
you
describe
how
you
want
to
get
that,
meaning
that
you
do
you
do
step
a
first
then
do
step
b
then
do
step
c
to
finally
reach
your
goal,
but
on
the
other
hand,
a
declarative
system
would
work.
Something
like
this
again.
You
know
what
your
goal
is
as
a
person
or
as
a
user.
A
Rather,
you
know
what
your
goal
is
you
describe
that
goal
you
describe
what
you
want
to
achieve
to
something
like
a
travel
agent
and
the
travel
agent
will
try
to
make
sure
that
whatever
you
have
described
to
them,
it
works
towards
making
sure
that
what
it
delivers
is
as
close
to
what
you
described
as
possible.
It
might
not
be
exactly
what
your
expectations
were,
but
it
tries
to
make
sure
that
you
reach
what
you
reach.
A
You
reach
your
goal,
which
is
to
go
on
a
vacation,
so
is
it
really
an
either
or
type
of
situation
here,
meaning
that
if
you
are
using
a
dedicated
system,
are
you
not
dealing
with
an
imperative
one
at
all?
The
answer
is
no,
because
usually
what
happens
is
a
declinative
system
usually
has
some
form
of
an
underlying
imperative,
one
meaning
that
let's
say
our
goal
is
to
go
on
a
vacation
to
describe
what
you
want
to
something
like
a
travel
agent.
A
So,
let's
try
and
understand
this
mental
model
with
the
help
of
an
example.
By
keeping
in
mind
an
example
of
a
thermostat
using
a
thermostat,
you
can
either
increase
the
room's
temperature.
You
can
decrease
the
room's
temperature
based
on
if
you
want
it
hotter
or
cooler.
So
let's
say
that
the
system
state,
which
is
what
your
room
temperature
currently
is,
let's
say
that
the
room
temperature
currently
is
23
degrees
inches.
A
That's
your
system
state,
but
you
also
have
a
desired
step,
meaning
that
I
want
my
room
to
be
25
degree
celsius
at
all
times,
and
the
ultimate
goal
is
to
try
and
get
the
system
state
and
the
desired
state
as
close
as
possible.
Ideally
it
should
be
the
same
now.
You
also
have
a
machine
which
takes
a
command
and
acts
on
that
command
and
tries
to
change
the
system
state.
A
So
this
this
this
command
can
be
something
like
increasing
the
temperature
of
the
room
by
2
degrees
celsius
to
make
sure
that
the
current
temperature,
which
is
23,
increases
by
some
amount
to
make
to
get
to
where
you
want
it
to
be,
which
is
25
degree
celsius
and
who
issues
these
commands.
It's
the
agent
and
the
agent
issues
these
commands
by
knowing
what
the
desired
state
is.
A
Now,
apart
from
all
of
this,
you
also
have
the
environment
factor
of
things,
meaning
that
there
can
be
changes
to
your
system
state
which
you,
which
are
unintended,
which
aren't
caused
by
a
command
that
the
agent
issues.
So
these
changes
aren't
accounted
for
because
they
can't
be
predicted
well
in
advance,
or
they
can
be
of
such
variety
that
you
can't
that
you
can't
possibly
think
of
all
of
them
exhaustively.
A
So
the
goal
would
be
to
build
a
system
that,
even
if
having
such
environment
changes
and
such
unintended
changes,
the
system
should
still
be
able
to
recover
and
drive
itself
towards
the
desired
state.
Even
if
it
doesn't
do
it
immediately.
It
should
still
move
in
the
right
direction,
and
the
agent
also
gets
some
form
of
feedback
from
the
system.
A
Saying
that
this
is
my
state
currently
and
the
agent
issues
commands
knowing
both
the
system
state
and
the
desired
state,
meaning
that,
if
I
only
if
I
know
that
my
desire
set
is
25,
and
only
if
I
know
whether
my
system
set
is
23,
can
I
issue
a
command
saying
that
I
want
2
degrees
more
of
temperature,
because
you
won't
really
have
a
frame
of
reference?
If
you
don't
know
both
of
these
things-
and
this
sort
of
loop
is
known-
is
known
as
the
control
loop
pattern,
meaning
that
you
get
some
form
of
feedback.
A
You
know
where
you
want
to
go
and
based
on
that,
you
are
just
your
trajectory
of
actions
and
in
an
imperative
way
of
doing
things.
The
agent
is
the
is
the
user
themselves.
So
something
like
me
manually,
going
and
increasing
the
temperature
or
decreasing
the
temperature
to
make
sure
that
the
temperature
in
the
room
is
ideal,
but
in
a
declarative
way
of
doing
things.
The
agent
is.
A
The
controller
is
something
known
as
a
controller,
meaning
that
the
user
still
exists
and
the
user
still
knows
what
the
desired
state
is,
but
the
user
gives
the
desired
state
to
something
known
as
the
controller
which
sees
what
the
current
state
of
the
system
is,
which
sees
what
the
desired
state
is,
and
it
takes.
It
calculates
some
action
to
make
sure
that
you
drive
the
machine
executes
a
command
that
drives
the
system
state
as
close
to
the
desired
set
as
possible.
A
A
So,
for
the
purposes
of
the
demo,
I
wrote
a
tool
called
kcd
cartel,
which
would
should
help
us
understand
these
differences
a
little
better.
So
what
I
want
to
do
is
I
want
to
say
that
okay,
I
want
two
containers
running
at
all
times
and
I
want
this
image
to
be
run
by
the
container.
I
also
want
to
load
balance
in
front
of
my
containers
and
the
load.
Balancer
should
use
this
image,
and
these
are
the
ports
that
I
want.
The
load
balancer
to
use
so
that
would
look
something
like
this.
A
A
A
So
if
I
do
a
declarative
mode
of
doing
things,
the
first
step
is
something
known
as
bootstrapping,
which
is
just
to
create
the
load
balancer,
and
it
also
creates
a
docker
network.
What
the
docker
network
does
is
it?
It
attaches
all
of
the
containers
to
the
docker
network
so
that
they
can
communicate
with
each
other.
And
here,
as
you
can
see,
it
starts
the
controller
as
soon
as
the
controller
starts
it
see,
it
gets
feedback
saying
that
I
don't
have
anything
running
right
now.
I
have
zero
containers
running.
A
A
So
now,
if
I
do
docker
ps,
I
should
sure
enough
get
two
containers
running
and
one
load
balancer
and
if
I
do
curl
I
should
get
hello
from
that
host
name
and
if
I,
let's,
let's
take
the
environment
factor
into
consideration,
so
let's
say
a
container
dies
right.
So
if
I
were
to
kill
a
container,
this
is
something
that
I
obviously
don't
want.
This
is
unintended.
A
So
if
I
kill
a
container,
it
gets
feedback
saying
that
oh
a
container
was
a
container
is
down
and
I
currently
have
just
one.
I
need
one
more,
so
it
issues
a
command
saying
that
spawn
one
more
container
which
it
does
and
this
one
is
successful
and
the
state
is
right
hand
side.
So,
if
I
do
docker
ps,
I
should
get
those
containers
back.
A
A
So
if
I
do
talk
up
yes
oops,
I
don't
have
anything
running.
So
if
I
do
kcd
cartel
apply,
but
let's
do
it
imperatively
this
time.
So
again,
first
step
is
bootstrapping.
I
could
have
made
the
bootstrapping
step
also
imperative,
but
let's
assume
that
bootstrapping
also
happens
now.
It
says
that
my
desired
state
is
true,
but
I
am
the
agent
currently,
which
means
I
haven't,
issued
a
command,
so
it
won't
do
anything
on
its
own.
So
it
says
it's
awaiting
reconciliation.
A
So
to
make
sure
that
I
get
to
where
I
want
to
be,
I
can
issue
a
certain
number
of.
I
can
spawn
a
certain
number
of
containers,
so
I
am
seeing
that
the
desired
side
is
two.
I
am
seeing
that
the
current
state
is
zero.
So
now
I
am
calculating
a
diff
of
two,
so
I
spawn
two
containers
and
once
I
spawned,
I
can
see
that
this
it
says
state
is
reconciled.
A
A
If
I
kill
a
container,
it
gets
feedback
saying
that
one
container
is
down.
These
events
occurred.
My
current
is
one.
My
desired
is
two:
I'm
awaiting
reconciliation.
Please
do
something,
so
I
am
the
user.
I
am
supposed
to
spawn
the
command.
I
am
supposed
to
issue
a
spawn
command,
so
I
know
what
the
state
should
be.
So
I
know
one
more
is
required,
so
I
have
control
over
how
many
I
should
spawn.
So
in
this.
You
have
more
control
here,
and
this
is
a
very
small
example,
but
in
something
like
kubernetes.
A
A
So
that's
how
things
work
in
an
imperative
and
a
declarative
way.
The
differences
are
in
a
declarative
system.
The
agent
is
the
controller
and
an
imperative
system.
The
agent
is
the
user,
and
if
you
have
a
lot
of
unintended
statements
that
can
happen,
a
definitive
system
might
might
be
a
better
choice
of
design.
A
So
the
machine
is
the
api
server,
something
known
as
the
api
server
the
desired
state
which,
from
a
user's
perspective,
is
is
usually
described
in
terms
of
yaml
files.
Does
the
desire
from
the
system's
perspective
is
usually
described,
is
usually
stored
in
xcd,
which
is
the
keyword
backing
key
value
store
of
kubernetes.
A
The
system
state
can
also
be
thought
of
as
stored
in
at
ct
and
feedback
in
kubernetes
is
received
in
terms
of
is
received
using
something
known
as
informers,
and
so
whenever
something
is
created
or
deleted
or
updated,
that
particular
feedback
event
is
received
through
informals,
and
the
controller
has
logic
to
make
to
react
to
some
of
these
events.
So
if
something
is
created
or
what
what
should
I
perform
to
make
sure
that
I'm
doing
my
job
current
correctly?
A
So
before
we
start
just
a
quick
interlude,
so
pods
and
kubernetes
can
be
thought
of
as
the
fundamental
unit
of
work.
If
you
want
to
run
something
in
communities
you
create
a
part,
a
pod
is,
is
a
concept
in
kubernetes
which
is,
and
added
score
is
just
a
it's
a
set
of
containers.
Basically,
a
replica
set,
on
the
other
hand,
is
something
that
ensures
that
a
certain
number
of
pod,
a
certain
number
of
copies
of
those
spots,
are
running
at
all
times.
A
A
So
the
kubernetes
machine
you
have
the
api
server.
First,
the
user
comes
and
says
that
I
want
to
create
this
deployment.
Now.
It's
okay,
if
you
don't
understand
what
xaml
means
and
what
this
command
means.
What
is
important
to
note
here
is
that
the
user
is
saying.
I
want
three
replicas
of
my
pods
at
all
times
now
the
user
gives
their
desired
state
to
kubernetes.
A
The
api
server
puts
this
desired
state
into
lcd,
so
it's
created
the
deployment
object
inside
hcd
now
there
are
also
a
bunch
of
controllers
that
come
in
kubernetes
that
ship
out
of
the
box.
For
you
and
for
the
purposes
of
this
example,
we'll
look
at
three
controllers,
which
is
the
scheduler
the
deployment
controller
and
the
replica
set
controller.
A
The
scheduler
job
is
to
see
that
a
node
is
assigned
to
a
port,
meaning
that
if
you
have
pods
in
fcd,
which
don't
have
a
node
assigned
to
them,
the
scheduler
will
go
ahead
and
assign
those
nodes.
Basically,
it
will
schedule
those
pods
onto
those
nodes
and
we'll
see
how
that
actually
gets
scheduled
and
how
it
works.
A
The
deployment
controller's
job
is
to
watch
deployment
objects
in
hcd,
meaning
that
it
will
watch
for
changes
and
creations
and
updations
and
deletions
of
these
deployment
objects
and
the
replicas
that
controllers
job
is
towards
replica
set
objects
and
make
sure
that
a
certain
number
of
those
copies
are
always
running
at
all
times,
and
each
of
these
controllers
are
responsible
for
their
own
objects.
None
of
them
are,
none
of
them
will
create
an
object
which
or
change
an
object
which
is
which
it
isn't
responsible
for.
A
So
there
is
a
clear
isolation
and
a
clear
separation
of
concerns
for
all
of
these
controllers,
and
this
is
important
because,
let's
say
a
certain
part
goes
it's
a
certain
controller
crashes.
It
shouldn't
affect
the
working
of
the
rest
of
the
remaining
controllers,
and
then
you
also
have
these
nodes,
which
are
the
worker
machines
and
kubernetes,
and
each
node
has
a
node
agent
called
the
cubelet
which
is
running
on
them.
A
So
the
cubelet
manages
things
on
its
node.
So
now
the
general
control
workflow
looks
something
like
this
general
communication.
Workflow
looks
something
like
this.
Now
a
deployment
is
created.
Now
the
deployment
controller
sees
that
a
deployment
is
created.
The
deployment
says
that
I
want
three
raptors
running
at
all
times,
but
there
is
nothing
there,
so
it
create.
It
creates
a
replica
set
object
which
is
responsible
for
making
sure
three
replicas
are
running
at
all
times.
It
creates
a
replica
set
object.
A
A
So
once
these
three
pods
are
created,
its
job
is
done
and
if,
if
you
notice
the
deployment
controller
does
not
touch
pods
at
all,
its
job
is
to
create
the
replica
set
object
which
it
does
and
then
the
replica
controller
goes
ahead
and
does
its
thing
now
the
scheduler
sees
that
three
parts
are
created,
but
none
of
them
are
scheduled.
So
by
using
some
criteria
and
some
algorithm,
it
will
assign
nodes
to
these
pods
and,
let's
say
the
nodes
are
assigned
in
this
manner.
A
A
A
The
cubelet
makes
makes
these
points
part
of
its
desired
state.
So
if
you
notice
kubernetes
is
not
only
distributing
computation,
but
it's
also
distributing
responsibility
and
the
desired
state,
and
this
is
very
important,
because
if
something
were
to
go
down
or
something
were
to
go
wrong
between
the
nodes
and
the
api
server,
let's
say
the
network
connection
breaks
or
there's
a
network
partition
that
occurs.
It's
okay,
because
the
q,
the
cubelet,
has
a
local
desired
state.
A
Now,
so,
if
something
were
to
go
wrong
on
its
node,
it
will
make
the
changes
to
make
sure
that
things
are
backed
and
running
up
again,
which
we'll
see
now
now
the
cube
that
sees
that
my
local
desired
state
has
pod
zero
and
these
parts.
But
nothing
is
running,
so
what
it
will
do
is
it
will
go
ahead
and
start
those
points,
meaning
that
okay,
now
my
local
desired
state
is
matching
my
current
state,
so
things
are
working
good
for
the
cubelet.
A
Now,
let's
say
that
network
partition,
which
I
was
talking
about,
occurs
that's
and
also
pause,
zero.
Something
goes
wrong,
a
container
in
port,
zero
crashes
or
something
in
port.
Zero
doesn't
match
how
it's
supposed
to
be.
What
and
that's
okay,
because
the
cubelet
doesn't
need
to
see,
what's
in
lcd,
to
make
sure
that
it's
getting
its
it's
getting,
what
the
design
state
is
supposed
to
be
because
kubernetes
has
distributed
the
responsibility
and
the
desired
state
as
well.
A
So
now
it
sees
that
my
desire
is
zero
and
one
it
doesn't
need
to
know
it
doesn't
need
to
immediately
see
what
it
doesn't
need
to
immediately
contact
the
api
server.
It's
able
to
manage
what
is
there
locally
so
what
whatever
the
latest
local
desired
state
is.
It
will
maintain
that
so
now
that
it
sees
that
part
0
is
supposed
to
be
running,
but
it's
not
so
the
cubelet
can
go
ahead
and
restart
that
and
it
does-
and
this
is
what
self-healing
is
so
whenever
these
unintended
changes
happen
to
your
system.
A
A
Now
the
deployment
controller
will
see
that
the
deployment
has
been
edited
and
the
new
desired
state
is
not
matching
my
current
system
state,
so
you
can
go
ahead
and
edit
the
replica
set
object.
It
will
not
create
another
part
because
that's
not
its
responsibility,
so
it
will
edit
the
replica
set
object.
Now
the
replica
set
controller
will
see
that
okay,
the
replicas
of
it
has
has
been
edited.
A
But
currently
my
current
state
is
not
equal
to
the
new
desired
state,
which
is
four
parts,
so
I'm
gonna
create
another
part
and
its
job
is
done.
The
scheduler
sees
that
there
is
a
new
pod,
but
let's
say
that
the
scheduler
doesn't
have
anything
in
its
cache
right
now,
so
it's
not
able
to
get
the
nodes
information,
and
so
let's
say
that
in
this
cycle
nothing
happens,
it
can
happen,
but
for
the
sake
of
simplicity,
let's
say
nothing
happens.
A
Now
the
connection
comes
back
online.
The
scheduler
again
sees
that
there
is
an
unassigned
pod.
It
goes
ahead
by
its
algorithm
and
assigns
spot
3
to
node
1,
and
now
the
kubrick
says
that
there
is
a
new
part
which
is
supposed
to
be
running
on
its
node,
but
it
doesn't
have
it
so
it
gets
that
new
part
puts
it
in
its
local
desired
state,
and
now
it
says
that
okay,
my
current
state,
which
is
this
spot
2,
is
not
matching
my
desired
state,
which
is
spot
2
and
part
3.
A
Fine,
for
is
what
kubernetes
will
tell
you,
and
so,
through
this
example,
we
saw
what
self-healing
meant
and
how
it
automates
some
of
these
things
in
terms
of
the
user
not
having
to
intervene
when
these
sort
of
unintended
changes
take
place.
So
let's
ask
ourselves
again
right:
what
even
is
this
thing
called
kubernetes?
A
So
if
we
look
at
this
definition
again
and
if
we
highlight
those
broken
down
points,
it
would
look
something
like
this.
We
know
why
it's
good
at
managing
work
roles.
Now,
as
we
saw
in
the
example,
we
know
what
a
declarative
configuration
means
and
why
did
it
have
to
go
with
the
declarative?
One
should
have
an
imperative
one
because
of
all
of
these
unintended
states.
That
can
happen
because
kubernetes
is
a
distributed
system
and
things
are
bound
to
go
wrong
somewhere
or
the
other.
A
Why
is
it?
Extensible
is
the
questions
remaining
kubernetes
is
extensible,
because
the
api
is
pretty
much
constant
throughout
what
I
mean
by
that.
Is
you
can
have
your
own
resources
called
custom
resources,
so
you
can
create
a
resource
called
foo.
You
can
have
a
controller
for
foo
and
you
can
design
you
can
you
can
you
can
tell
it
what
you
want
the
desired
set
of
food
to
be
and
the
controller
will
still
work
in
the
same
way.
All
of
these
controllers
work,
which
is
the
scheduler
the
replicas
that
control
the
the
deployment
controller.
A
A
So
these
are
the
references
and
resources
that
I
found
very
helpful.
The
kubernetes
example
of
how
things
work
was
taken
was
mainly
inspired
by
this
talk
deep
dive
into
kubernetes
internals.
I
changed
a
few
things
to
try
and
make
sure
that
it
aligns
with
whatever
we
learned
before
and
also
added
a
few
things
to
make
sure
the
concept
of
self-healing
is
as
clearly
depicted
as
possible,
but
these
are
some
of
the
resources
that
I
found
really
helpful.
So
I
would
highly
recommend
checking
those
out
and
the
slides
and
source
code
for
this.