►
Description
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects - Learn more at https://kubecon.io
A Safari into the KubeVerse - Dhananjay Sathe, Rapyuta Robotics
Kubernetes is for the most part is a whole new universe where the wonders of kubectl and friends enchant the amateur onlooker with the magical objects of pods, self healing deployments, networks all operating in the promised land of #webscale. The talk intends to demistify the basic workings of kubernetes by following the common kubectl command as it traverses the kubeverse by gently introducing a treasure trove of "shiny new things" like the API server, admission control, initializers, the GVK, objects, controllers, informers.
https://sched.co/YVxc
A
Okay,
good
afternoon,
everybody
how
you
doing.
Are
you
guys
awake
lovely?
So
today,
what
we're
gonna
do
is
take
a
little
Safari
with
flippy
captain
cuke
and
friends
through
the
Cooper's
first
up,
hello,
I'm
Don
enjoy
SOT
II
am
a
staff
engineer
at
reputa
robotics
for
the
last
five
years
have
been
working
on
the
intersection
of
cloud
computing
and
smart
connected
robots.
A
It
started
off
as
a
research
project
at
ETH
Zurich
and
has
today
evolved
into
the
world's
first
cloud
robotics
platform
as
a
service
called
reputed
IO
a
little
more
detail
about
what
we
do
at
reputed.
Robotics
is
a
start-up
based
out
of
Tokyo,
Japan
and
Bangalore
India
that
enables
machines
such
as
ground
vehicles,
forklifts
arms,
among
others,
to
harness
the
power
of
cloud
computing
to
navigate
complex,
dynamic
environments
alongside
human
beings.
On
the
other
side,
it
allows
you
to
use
machines
and
robots
as
commodity
hardware
to
build
truly
distributed.
A
Applications
that
achieve
business
objectives
such
as
increasing
crew
puts
in
warehouses,
sorting
stuff
where
labor
shortages
occur
in
our
market,
for
instance,
Japan
right.
So
that's
what
we're
doing
with
kubernetes
speaking
of
kubernetes
kubernetes
has
basically
come
to
define
a
new
era
of
cloud
computing
and
as
architects
and
designers,
we
see
kubernetes
as
a
distributed
system,
stool
kit,
a
substrate
of
sorts
to
build
the
next
generation
of
applications
and
to
demonstrate
why
we
feel
so
strongly
about
kubernetes.
A
A
Well,
seemingly
simple,
but
pretty
wicked
is
you
have
nginx
running
and
it's
not
just
a
simple
nginx:
it's
a
replicated,
fault-tolerant
self-healing
highly
available
nginx
deployment.
Thinking
that
one
command
could
have
such
a
crazy
impact
is
hard.
I
mean
it's
almost
unreal
and
magical
when
you
first
look
at
it
and
the
whole
point
of
this
talk
is
actually
to
go
on
an
adventure
and
figure
out
what
really
is
going
on.
A
How
did
that
seemingly
stupidly
simple
command
transform
into
something
so
amazing,
right
and
nginx
is
dumb
for
an
example,
but
that
could
be
a
web
app.
That
could
be
your
business
app.
It
could
be
anything
that
you
actually
care
about
right.
So
what
we
gonna
do
is
we're
gonna,
go
on
a
journey
and
follow
this.
The
coattails
of
this
command,
as
it
traverses
various
parts
of
the
ecosystem.
A
The
kubernetes
ecosystem
is
huge
and
intimidating,
and
the
idea
of
this
talk
is
to
get
you
accustomed
to
some
of
the
players,
some
of
the
parties
that
partake
in
this
Symphony
of
sorts
and
hopefully
give
you
guiding
lights
when
you
find
your
own
journeys
into
communities
and
its
ecosystem,
the
first
stop
on
this
journey
is
cube,
CTL
or
cube
cuttle.
That
debate
will
probably
never
end,
but
we're
gonna
call
it
CTL
for
consistency,
sake,
so
cube.
Ctl
is
a
command-line
utility
written
in
golang.
A
That
is
the
primary
tool
that
people
use
to
interact
with
a
communities
cluster
and
consequently
the
kubernetes
ecosystem.
So
let's
run
that
command
one
more
time
and
step
up
the
verbosity
and
see
what
it's
actually
doing
any
time
you
are
in
a
conundrum
of
what's
going
on
and
run
the
minus
V
flag,
it's
useful!
So
don't
worry
about
what
is
happening
here.
We
kind
of
get
into
each
step
of
it.
You
notice.
A
It
makes
a
particular
request
body
with
this
green
squiggly,
licking
bunch
of
JSON
to
it
makes
a
post
request
to
a
certain
end
point.
So
you
got
the
request.
We've
got
the
endpoint
and
we
have
some
authorization
tokens
which
you
obviously
need
right,
let's
dive
into
each
one
of
these
things.
So
what
is
cube
CTL
actually
doing
here?
So
it's
assembling
a
message
to
send
to
somewhere,
let's
not
get
ahead
of
ourselves,
so
first
things:
first,
any
CLR
utility.
You
want
to
run
some
sort
of
validation.
A
You
want
to
figure
out
that
absolute
rubbish
isn't
being
typed
onto
the
console.
The
next.
You
want
to
load
credentials
by
credentials,
I
mean
the
context
of
who
is
operating
on
it.
What
tokens
certificates
clusters
namespaces?
You
are
defaulted
to,
etc,
and
the
last
piece
is
the
most
interesting
piece.
It's
called
generators,
so
generators
are
something
like
reverse
marshalling
or
reverse
serialization,
so
that
statement
that
you
had
in
intent
is
converted
into
an
object.
A
The
green
squiggly
stuff-
and
it
has
modifiers
such
as,
where
do
I
want
to
share
you
this
workload
or
what
should
I
do
if
it
crashes,
which
is
restart
policies,
and
then
you
end
up
with
this,
so
what
it
does
is
it
generated
a
kind
called
develop
deployment
with
a
certain
API
version.
You
see
it
talking
about
nginx,
something
about
replicas
containers,
etc.
So
this
is
sort
of
defining
the
object.
A
It's
picked
up
the
tokens
and
it's
picked
up
the
API
endpoint
right
and
now
you
have
a
request,
but
I
want
to
slow
down
here
for
a
second
and
describe
what
objects
are
the
green
squiggly
stuff
which
we
call
the
deployment
is
the
common
pattern
of
how
you
actually
interact
with
kubernetes
you
do
not
tell
community
is
to
you
know,
procedurally
go
puller
image,
run
it
Network.
It
set
it
up.
All
of
that
kubernetes
works
on
declarative
state.
That
means
every
object
you
create
is
a
record
of
intention.
A
The
job
of
the
platform
and
all
the
minions
that
run
in
the
platform
is
to
primary
fulfill
this
intent
right.
So
you
declare
an
intent
and
forget
about
it,
and
what
we
going
to
look
into
today
is
actually
how
this
request
of
an
intent
is
fulfilled
into
something
more
concrete,
and
every
object
has
three
sections.
Typically,
if
you
look
at
any
kubernetes
object,
you
have
a
specification,
a
status
and
a
metadata
field.
A
We'll
talk
about
each
one
of
these,
but
I
highly
recommend
people
who
are
really
interested
to
check
out
that
link
on
API
conventions
in
cig
architecture.
There
is
a
detailed
description
as
to
why
they
chose
those
things
and
how
that
effects
design
within
communities
so
do
check
that
out.
So
the
specification
is
pretty
straightforward.
This
is
the
place
where
the
user
defines
the
state
he
wants
to
achieve.
For
example,
I
want
three
replicas
I
want
you
to
run
the
engine
X
or
whatever
X,
Y,
Z
container
and
so
on.
A
Right
or
you
want
a
template
this
in
the
case
of
a
deployment
you're
creating
a
pod
template.
So
you
can
nest
one
specification
inside
the
other
specification
and
these
change
over
time
and
there
are
different
API
versions.
The
current
one
is
1.17
and
they
have
minor
revolutions
across
versions
of
coupon
IDs.
So
look
out
for
those.
The
other
piece
is
the
status
since
I
just
submitted
this
object.
The
status
field
is
quite
empty,
but
this
is
essentially
the
section
that
the
system
will
fill
for.
You
is
the
pod
working.
Is
it
crashing?
Is
it
pulling?
A
It
will
tell
you
about
the
status,
and
this
is
really
important
to
introspect
the
state
of
the
system.
Once
you
submit
that
object,
you
can
fetch
it
and
get
to
know
what
is
going
on.
What
is
the
system
doing
about
it?
And
the
last
piece
which
is
found
in
every
coconut
is
object
and
is
fairly
consistent.
Is
resource
meta,
every
coconut
each
resource
has
resource
matter.
One
two
fields
here
are
pretty
interesting:
it's
called
the
API
version.
A
An
API
version
is
basically
a
grouping
of
resources
which
might
change
from
version
of
communities
to
another
version
of
communities,
the
kind
for
instance.
What
kind
of
object
you
have
so
we've
looked
at
deployments.
There
are
pods
nord
services
so
on
you
must
have
heard
these
words
throughout
the
day
and
metadata
is
typically
what
it
says.
It's
metadata.
It
helps
you
identify
the
object
label,
it
tag
it
all
that
sort
of
stuff.
A
A
You
will
find
in
batch
scheduling
the
core
would
be
the
core
things
like
pods
node
services,
the
base
level
infrastructure,
and
that
is
really
interesting,
because
it's
consistent
across
the
entire
component
is
universe,
whether
you
look
at
the
api's,
whether
you
look
at
specifications
documentation,
SDKs
client,
go
so
that
it
produces
the
guessing
that
the
developer
has
to
do
about.
Where
do
I
find
these
kind
of
objects?
Because
then
you
have
so
many
hundreds
of
objects
and
sub
objects
and
fields.
A
It
can
get
out
of
hand
really
quick,
and
it
follows
the
open
API
schema,
which
is
also
another
really
interesting
thing.
So
for
those
of
you
who've
written
to
rest
clients,
you
typically
have
to
hard
code
all
possible
combinations
of
requests
that
you
send
and
have
cases
for
all
of
them.
But
what
opening
API
allows
kubernetes
to
do
is
once
it
explores
a
new
cluster.
It
downloads
this
into
the
local
cache
file.
A
So
if
you
are
running
cube
CTL,
you
can
actually
go
into
this
directory
and
find
that
and
the
advantage
is
there
is
about
20
to
40
objects,
depending
on
who
you
ask
in
the
core
slash
the
main,
let's
just
say
the
main
component
least
repository
and
friends.
But
now
you
have
C
IDs
all
the
Fancy's
talks
about
operators.
They
typically
deal
with
custom
resources,
for
example
here
I'm
using
cilium
from
IC,
and
I
or
I
use
an
elastic
search
operator
to
manage
my
elastic
search
stuff.
But
the
beauty
of
having
this
specification
is
now
Qube.
A
Ctl
can
work
with
these
objects
like
it
was
native
and
you
can
actually
do
cube.
Ctl
get
so
and
so
object
described
so
and
so
object
and
all
of
that
and
what
it
does
under
the
hood.
When
you
actually
add
a
new
server,
is
actually
queries
these
endpoints
and
gets
them.
For
instance,
it
tells
you
there
is
a
name
called
deployment
status
or
deployment.
These
are
the
verbs
for
it.
These
are
the
operations
you
can
do
with
it
and
that
is
sort
of
unwrapped
into
what
client
features
will
be
offered
to
you.
A
This
is
a
little
segue
out,
but
we
as
command
line
junkies
like
to
write
aliases
or
bash
auctions
to
help
us
do
tiny
things.
For
instance,
I
want
to
have
a
convenient
function
that
says
if
the
pod
is
crashed,
looping
automatically
create
a
debug
container,
attach
my
P
trace
to
it
or
whatever
right
now,
there's
a
new
functionality
in
cube,
CT
and
I.
A
Think
after
1.13
that
allows
you
to
create
any
executable
that
is
prefixed
with
cube
CTL
whatever,
and
you
can
directly
ssh
into
pods
ssh
into
multiple
nodes,
that
sort
of
stuff
and
it
ships
with
crew
dot
dev,
which
is
itself
a
plugin,
but
think
of
it
as
a
homebrew
for
your
kubernetes
plugins.
So
you
can
update,
install
manage
I,
encourage
you
to
check
this
out.
It
really
helped
me
improve
my
quality
of
life
using
cube
CTL,
so
we're
done
with
creating
the
request.
The
next
stop
in
this
journey
is
the
API
server.
A
The
API
server
is
the
central
core
part
of
kubernetes.
This
is
the
nerve
center
of
where
everything
happens.
Almost
everything
in
kubernetes
happens
through
the
API
server
right.
So
now
that
your
request
makes
it
in
the
first
thing
that
we
all
do
like
any
other
web
application
is,
do
Otzi
a
North
End
kubernetes
gives
you
a
bunch
of
pluggable
modules,
standard
passwords,
tokens
of
all
sorts
certificates
to
do
author,
N
and
authorization
is.
The
idea
of
seeing
is
a
particular
entity
allowed
to
perform
a
particular
action.
A
A
So
what
you
do
is
you
take
a
bunch
of
these
permissions
and
associate
them
to
role,
and
then
you
can
bind
a
role
to
a
particular
user
or
a
service
account,
so
you
can
sort
of
reuse
these
groupings
of
roles
right
rather
than
individually
assigning
permissions
to
each
user.
The
other
interesting
thing
might
be
verbs.
So
if
you
already
have
something
like
an
LDAP
system
or
your
company's
corporate
internal
system-
and
you
want
to
assign
permissions
based
on
that,
you
can
plug
into
any
HTTP
service
again
I
encourage
you
to
check
out
all
the
links.
A
So
now
what
now
that
we're
done
with
Ozzy
northen,
you
should
probably
kick
in
and
standard
web
server
web
development
building
do
something
about
it,
but
not
quite
yet.
There's
an
interesting
thing:
kubernetes
is
kind
of
picky.
Are
you?
Are
you
ready
to
be
accepted?
Think
of
it
as
university
in
some
ways
right,
you
got
through
the
entrance
exam,
and
now
you
have
to
get
out.
Obviously
you
have
to
get
that
stamp.
Get
that
certificate.
That's
what
a
lot
of
us
strive
for
in
our
1112
grade
and
like
after
that.
A
So
particularly
there
is
something
called
admission
control.
What
that
does
is
it?
It
happens
in
two
phases:
there's
mutating
and
validating.
If
you
want
to
build
a
mental
map
of
it,
think
of
it.
When
you
enter
University,
you
have
these
friendly
professors
and
mentors
typically
or
seniors,
who
help
you,
learn
and
acquire
new
skills.
They
mutate
you.
A
So,
if
I
create
an
application
and
I
forget
to
mention
the
storage
class,
and
probably
the
user
of
the
application
might
be
a
different
team
who
doesn't
know
the
setup,
so
you
can
say
it
be
fault
him
into
an
SSD
or
an
HDD.
You
could
rate
limit
events
so
that
you
don't
flood
the
entire
control
plane,
that
sort
of
stuff,
so
basic
validations
and
like
making
sure
that
everything
is
good
to
go
for
the
object
to
be.
You
know,
of
some
use
in
the
communities,
worldview,
our
ecosystem
and
well.
Now
all
of
that
is
done.
A
We
can
finally
accept
the
right.
So
there
is
a
data
store
that
powers
all
of
communities.
It's
called
HCD.
It's
basically
like
a
hierarchical
tree,
key
value,
store
of
sorts,
it's
evented,
it
allows
watches
and
all
those
fancy
things
so
yeah.
That's
why
it's
sort
of
chosen
and
sort
of
evolved
with
kubernetes
as
it
evolved.
So
what
the
API
server
does
again
is
it
maintains
that
respect
for
the
object
for
each
object,
which
sets
up
a
handler
and
each
handler
manages
its
own
storage.
A
So
you
sort
of
have
this
D
couple
idea
of
how
to
serialize
Marshall
data
read
and
write
that
to
the
database
once
you're
done
with
all
of
that,
you
verify
if
it's
actually
accepted,
and
then
you
return
status,
code,
positive
or
negative
to
your
client,
which
was
cube
CTL
summing
it
up.
This
was
the
journey
of
the
object
from
when
it
hit
the
API
server
to
when
it
actually
hit
the
datastore.
A
So
what
you
can
do
is
create
an
initializer
configuration
and
tell
the
API
server
for
any
object
that
you
receive.
For
example,
in
this
place,
a
pod
give
it
a
little
tag,
give
it
a
little
key
that
says,
custom
pod
initializes
and
you
can
set
these
up
for
all
kinds
of
every
kind
of
object
that
the
API
server
accepts.
Now
what
you
do
is
you
run
your
own
logic
loop.
You
run
a
control
loop
that
watches
for
these
objects.
A
A
So
I
want
to
take
a
segue
out
of
this
story
too
one
of
the
basic
core
patterns
of
how
kubernetes
functions.
This
is
a
diagram
that
is
about
two
hundred
years
old
and
it's
very
commonly
used
for
a
person
like
myself
coming
from
the
electronics
or
robotics
background
where
you
have
a
process,
and
you
have
some
sort
of
perceptor
Zoar
sensors
that
see
how
the
process
is
evolving
and
you
have
some
control
knobs.
A
This
could
be
something,
as
you
know,
adjusting
your
break
speed,
this
that's
how
your
brakes
or
your
trains
or
any
any
of
most
of
your
electronics
actually
work,
and
you
have
actuators
to
actually
function.
Make
make
something
happen.
You
know
like
a
control
rod,
so
kubernetes
in
reality
is
basically
a
chain
reaction
of
control
loops
and
that's
the
primary
design
pattern
that
you
will
find
repeated
across.
A
A
The
advantage
of
having
independent
control
loops
and
distributed
systems
is
typically
everything
is
loosely
coupled
you
can
optimize
for
performance
on
what
you
need
for
that
particular
control
loop
and
it's
easy
to
customize
and
extend,
as
we
just
saw
in
one
prior
example,
and
as
we're
gonna
see
as
a
pattern
throughout
this
entire
presentation
going
ahead.
There's
something
really
interesting
to
know
that.
Yes,
events
can
trigger
stuff
in
communities,
but
it
is
not
edge
triggered,
and
this
is
really
vital,
because
networks
will
fail.
Nodes
will
fail.
A
You
have
to
assume
everything
always
fails,
at
which
point
what
you
want
to
do
is
just
use
that
as
a
trigger
state
and
then
look
at
the
current
state
of
the
system
actually
receive
the
object,
see
if
it
meets
your
criteria
and
then
make
changes.
If
you
want
to
make
changes,
it's
so
common
that
it's
sort
of
become
a
design.
Parallel,
what
you
really
want
to
do
in
almost
every
single
piece
in
kubernetes
is
list
and
watch
a
particular
resource.
For
example,
you
want
to
watch
parts
if
you
want
to
do
something
with
pots.
A
You
want
to
watch
nodes.
If
you
want
to
lose
something
with
nodes,
you
want
to
trigger
some
sort
of
a
worker,
receive
events
or
information
from
your
work
queue
and
then
use
the
very
same
clients
to
talk
back
to
the
API
server
right
and
that's
basically,
what
happens
and
that
fancy
stuff
kubernetes
has
done
something
really
cool
specifically
in
client,
go
to
make
your
life
easier.
A
Now,
if
you
apply
this
pattern
again
and
again
and
again,
you're
going
to
write
a
lot
of
boilerplate
code,
boilerplate
code
to
fetch
resources
and
get
triggered,
have
a
local
cache
of
some
sort
and
when
you're
running
hundreds
of
logic,
loops,
invariably
you're
going
to
have
concurrency
issues
like
someone
is
gonna
step
over
someone
else's
foot
right.
So
that's
where
informers
come
in
and
what
informers
do
is
they
may
they
are
responsible
for
synchronizing
local
state?
This
also
makes
your
store
much
more
efficient
and
it's
actually
harder
to
write.
A
A
Coming
back
to
our
story,
now
that
we
understand
this
paradigm,
let's
look
at
how
this
pattern
works.
So
when
I
declared
the
idea
to
create
a
deployment,
what
the
deployment
controller
does
is
he
notices
the
required
object,
called
a
deployment,
and
he
says
great
I
need
to
have
three
parts
of
nginx
or
whatever
running
so
I'm
gonna
do
only
one
lazy
thing:
I'm
going
to
create
something
called
a
replica
set
controller
and
pass
him
the
information
of
what
parts,
what
labels
etc
to
actually
have
out
there,
and
that's
it
I'm
done
right.
A
So
if
the
image
changes
I
create
a
new
replica
set
at
which
point
the
replica
set
controller
kicks
in
and
it
does
a
very,
very
simple
job,
it
queries
the
pod
state
and
says:
do
I
have
enough
pods
that
meet
this
specification,
if
not
create
more,
if
too
many
kill
them.
So,
whether
you're
deploying
or
whether
your
node
is
failing,
if
an
what
fails,
a
pot
disappears
and
that
criteria
has
not
met
since
the
loop
is
going
on.
He
notices-
oh
my
god,
I
need
one
more
point
and
that's
self
healing
for
you
right.
A
So
you
notice
how
the
core
of
communities
is
using
those
concepts
again
and
again
again.
The
same
is
true
for
scheduling
right,
so
you
have
a
part
in
our
journey.
We've
come
to
where
the
kubernetes
api
server
has
accepted
the
pod
initializes
a
complete.
It's
gone
through
admission,
it's
gone
through
all
of
those
things
now
it's
time
to
actually
put
that
nginx
on
a
physical
node.
How
does
that
happen?
So
there
is
another
control,
loop
that
watches
for
pods
that
do
not
have
a
node
name
assigned
to
them.
It
picks
up.
A
This
part
uses
whatever
logic.
It
really
wants
to
use.
That's
unimportant
or
important,
depending
on
who
you
are
to
be
very
honest,
a
few
of
the
guy
riding
the
said.
You
know
you
better
care
about
it,
so
you
pick
a
node
you
and
then
what
you
do
in
kubernetes
is
you
the
share.
Do
not
does
not
go
on
to
a
node
and
share
you
let
or
do
anything
itself.
A
The
cubelet
is
a
piece
of
code,
think
of
it
as
little
minions
doing
the
bidding
of
the
API
server
running
around
on
each
node.
They
are
the
pieces
that
are
responsible
for
interacting
with
the
operating
system,
interacting
with
the
network,
like
it's
sort
of
you
sitting
on
a
laptop
doing
stuff,
but
just
being
guided
by
control
loops
and
broadly
that's
what
a
cubelet
broadly
is.
So
what
does
a
cubelet?
Do?
It
runs
another
control
loop.
What
does
this
control
loop
do?
It
has
its
own
state.
A
It
knows
about
the
pods
that
it's
handled,
if
it
notices
a
new
pod,
which
it
does
not
know
about
it,
pulls
the
information
for
that
part
and
obviously
you
need
to
tell
the
master
that
you're
actually
doing
stuff.
Otherwise,
he's
not
gonna
appreciate
your
existence
right,
so
he'll
keep
updating
the
status
in
the
API
server,
but
he
also
runs
a
lot
of
other
loops.
A
He
basically
creates
the
cgroups
required
for
it
in
the
case
of
docker.
In
this
case,
creates
data
directories
decides
where
the
data
there
would
be
located
where
the
container
directory
would
be
located
attaches
any
volumes
that
you
might
have
out
there
and
retrieves
secrets
config
maps
and
actually
creates
these
little
objects
and
mounts
them
into
the
container,
and
at
this
point
it
hands
it
over
to
a
container
runtime
okay,
so
it
does
not
actually
spawn
the
container.
A
Couplet
does
not
do
any
of
that
and,
as
you
see,
if
you
look
at
this
I
think
I
pull
up
this
light
from
an
alley
cloud
presentation
which
sort
of
enforces
this
idea
of
control,
loops
and
more
controller
loops
and
more
control
loops.
So
you
have
a
sink
loop
as
we
talked
about,
and
you
have
one
for
node
statuses.
You
have
something
for
network
this.
Each
one
of
those
components
gets
their
own
control
loop,
which
is
trying
to
make
the
world
fit
its
world
view
they
all
care
about
what
they
need
to
do.
A
That's
it
so
now
that
we've
come
here,
communities
introduced
this
really
interesting
concept
of
container
runtime
interfaces.
Now
docker
is
just
one
container
runtime
and
the
fundamentals
remain
pretty
much
similar,
so
you
have
different
container
and
times
like,
say
kata
or
I,
don't
know
Fargate
or
any
of
these
other
orchestrators
that
may
use
hypervisors
or
microkernels
or
that
sort
of
stuff,
and
there
are
use
cases
for
each
one
of
them.
A
So
what
it
does
first
is
creates
a
sandbox
in
the
case
of
docker
that
translates
to
a
pause
container
and
to
this
pause
container
now
he
would
send
commands
about
starting
a
container
pulling
an
image
and
that's
where
you'll
actually
run
like
a
command
like
docker
pool,
we'll
talk,
a
run,
docker
and
then
listen
to
the
dock
event
stream
and
complete
the
control
loop.
Broadly
there
almost
there.
So
the
containers
running
the
only
little
missing
piece
is
the
networking.
A
A
Now
CNI
in
itself
could
probably
be
a
five
day
track
in
its
own
right,
but
broadly,
what
it
has
to
do
is
set
up
some
sort
of
a
network
plug
into
the
container
link
that
to
a
bridge
on
the
host
link
that
bridge
to
an
overlay
or
an
underlay
or
a
eb
PF
or
whatever
the
hell.
You
really
want
to
use,
doesn't
really
matter
and
link
that
to
the
host
fabric
or
the
cloud
fabric
and
the
idea
of
having
these
decoupled
loose
control
loops
is
it's
pluggable,
I,
think
I,
don't
think.
A
I
can
name
like
all
the
cni
implementations
that
exist.
There
are
new
ones
that
show
up
every
other
day.
So
now
it's
network,
it's
available.
There's
another
cool
link.
Please
check
out
all
the
links
in
the
thing
they
make
for
really
interesting
reads
and
that's
how
the
nginx
page
actually
showed
up
through
a
sequence
of
chain
reaction
of
control,
loops,
broadly
I
also
have
to
give
a
shout
out
to
Hammond
and
people
in
the
community.
I
think
two
things
that
make
abilities
really
special
is
one
the
architecture
of
second,
the
community.
A
There's
this
excellent
excellent
github
page.
So
when
I
was
coming
up
with
this
talk,
I
was
thinking.
How
do
I
actually
explain
something
as
complex
and
huge
as
kubernetes,
and
this
really
gave
me
an
idea
of
taking
a
linear
approach
to
visiting
some
of
the
spots
that
would
help
people.
You
know,
get
these
beacons
and
have
their
own
journey
as
they
proceed.
A
It
actually
links
you
into
code
of
communities
which
you
can
go
look
up
and
you
know
see
what
exactly
it's
doing
and
there
you
can
look
at
the
go
code
that
did
something
and
I
think
I
am
done.
That's
all!
So,
if
any
of
this
excites
you,
you
want
to
work
with
robots
and
cloud
computing
and
communities.
Look
for
people
in
these
t-shirts
come
talk
to
us,
have
a
chat
and
any
questions
I'd
be
glad
to
take.