►
From YouTube: The Growing Need for Caching Container Images in Kubernetes - Senthil Raja Chermapandian, Ericsson
Description
Imagine your Containerized Application experiences a sudden surge in traffic, and it needs to immediately scale out horizontally (i.e., additional instances need to be created). Kubernetes creates additional replicas of Pods. However, these Pods won’t be available for handling the increased traffic, until the required images are pulled, the containers are started and become ready to serve requests. Or assume applications that run on IoT devices, where the network connectivity between the device and image registry would be intermittent. There are several such use cases that would benefit from caching the container images in your Kubernetes cluster. In this talk, I’ll present the benefits of caching images, use cases, how easy it is to create and manage the cache using an open-source Kubernetes add-on called kube-fledged. I’ll also present a list of similar image caching solutions.
Contacta a Senthil en:
- https://www.linkedin.com/in/senthil-raja-chermapandian
- https://twitter.com/senthilrch
A
B
B
So
I
am
going
to
talk
more
about
the
open
source
project.
In
this
talk,
I
spend
quite
a
bit
of
time
on
tech
blogging,
so
you
can
find
me
on
medium
and
I
post
a
lot
of
blogs
around
kubernetes
and
the
cloud
native
technologies,
and
you
can
find
me
on
twitter
as
well.
My
twitter
handlers
at
the
rate
of
central
r
c
h-
and
I
am
a
big
fan
of
the
netflix
series
money
heist
and
by
the
way
season.
5
volume
2
is
launching
on
3rd
of
december,
so
don't
miss.
It.
B
Let's
talk
about
the
use
cases
for
caching
container
images
in
kubernetes,
for
instance,
you
you
have
a
real-time
application.
For
instance,
it
is
processing
some
high-speed
data
which
is
streaming
data
right
and
such
applications
required
to
start
up
very
quickly
and
even
if
they
scale,
for
instance,
if
they
scale
horizontally
and
new
instances
of
the
pod
have
to
be
started
up
and
the
scaling
also
has
to
happen
in
a
rapid
rapid
fashion.
So
we
are
increasingly
increasingly
seeing
many
such
applications.
B
For
instance,
in
the
machine
learning
world,
there
are
lots
of
data
processing
applications
which
require
a
rapid,
startup
and
scaling,
and
second,
is
in
the
cloud
realm.
Serverless
is
gaining
more
traction
day
and
day
day
by
day
and
serverless
functions.
They
need
to
react
as
quickly
as
possible
to
the
incoming
events
right.
So
when
a
new
pod
has
to
be
started
up
to
serve
the
function,
the
pod
has
to
start
almost
instantaneously.
B
These
applications
should
be
able
to
tolerate
intermittent
network
connectivity,
so
there
will
be
some
fluctuations
in
the
network
connectivity
or
there
could
be
some
fluctuations
in
the
bandwidth
available
so
in,
in
which
cases
these
applications
will
not
be
able
to
reach
the
external
network,
or
they
will
not
be
able
to
reach
the
cloud.
So,
in
such
cases
also,
it
is
better
to
cache
the
container
images
on
these
edge
devices
or
very
close
to
those
edge
devices,
and
another
interesting
use
case
is
from
a
security
perspective.
B
So
if
you
have,
if
you
are
having
a
highly
secure
private
image
registry-
and
you
cannot
grant
access
to
pull
images
from
this
private
registry,
so
one
easy
solution
is
you
can
make
the
specific
container
images
available
on
the
kubernetes
worker
nodes
itself,
so
that
users
will
never
have
to
pull
the
images
from
the
container
registry
right.
So
these
are
some
of
the
typical
use
cases
wherein
it
is
always
desirable
to
have
some
sort
of
a
case.
B
Caching
solution,
so
that
you
can
make
use
of
the
container
images
that
are
directly
available
in
the
cache
rather
than
rather
than
pulling
the
images
every
time
from
the
centralized
image
registry
now
moving
on
to
cube
fleshed.
So
what
is
cube
fleshed?
So
let
me
give
you
an
overview
of
what
cubeflex
does
it's?
Basically,
a
kubernetes
operator
implemented
using
a
custom
resource
definition
as
well
as
a
controller,
and
the
main
purpose
of
kubeflow
just
is
to
cache
container
images
directly
on
the
worker.
B
Not
so
so
you
can
actually
define
an
image,
cache
custom
resource
and
you
can
specify
what
are
the
images
that
you
want
to
be
part
of
the
cache
and
onto
which
nodes?
Those
images
have
to
be
cached,
and
then
the
cubefledged
controller
will
take
care
of
the
necessary
steps
for
caching,
the
images
and
supported
runtimes.
It
supports
docker,
container
d
and
cryo.
B
It
supports
three
different
methods
of
installation,
so
you
can
make
use
of
plain
vanilla,
yaml
manifests
or
you
can
use
the
helm
chart
way
of
installing
and
for
advanced
users
who
rely
on
operators.
You
can
also
make
use
of
the
helm
operator
way
of
installing
cube
list
and
queue
fleshed
provides
you
with
pre-built
images
for
all
the
components
in
queue
fleshed
and
another
interesting
advantage
that
you
get
is
the
pre-built
images
which
are
hosted
in
docker
hub.
B
Now,
what
are
the
features
of
qblist
and,
as
I
said
earlier,
the
main
feature
of
cubeflex
is
to
cache
images
right
and
there
are
two
different
ways
of
caching
images
that
are
supported
in
cubeflex.
So
first
is
either
you
can
cage
images
to
all
the
nodes
in
the
cluster
right
or
you
can
define
a
subset
of
the
nodes,
and
you
can
specify
that
these
certain
images
have
to
be
caged
only
on
those
nodes.
B
So
you
can
use
label.
You
can
use
node
selectors
to
specify
the
subset
of
the
nodes
and
it
supports
refreshing
the
cache
as
well.
So
there
is
an
automatic
way
of
refreshing
the
cache
and
there
is
also
an
on-demand
way
of
refreshing
the
cache.
So
when
you
refresh
a
cache,
what
happens
is
cube
fledged
sees?
What
are
the
images
missing
in
the
case
and
it
will
go
and
pull
those
images
and
download
them
into
the
cache
and
whenever
a
new
node
is
added
to
the
kubernetes
cluster
and
if
you
had
enabled
automatic
cache
refresh.
B
So
when
the
next
cycle
of
cache
refresh
happens,
these
new
nodes
are
automatically
detected
and
the
images
are
cached
onto
these
new
nodes
and
not
only
caching
images.
Cubefledged
also
gives
you
the
ability
to
modify
the
cache.
So,
for
instance,
you
can
add
new
images
into
the
cache.
You
can
remove
images
from
the
cache
and
you
can
also
purge
the
image
cache.
B
For
instance,
if
you
decide
that
you
don't
want
to
cache
the
images
anymore,
so
you
can
use
the
purge
action
to
remove
all
the
images
in
the
case,
and
you
can
also
decide
to
remove
the
cache
completely
and
it
supports
both
public
and
private
registries
and
the
case
spec
that
you
specify
in
the
image
cache
custom
resource
that
is
validated
using
a
webhook
admission
controller.
So
it
has
two
main
components.
B
One
is
the
primary
controller,
which
does
all
the
job
of
pulling
the
images
and
deleting
the
images
and
things
like
that,
and
there
is
a
web
server
that
okay,
that
is
bundled
in
cube
fledged
as
well,
that
that
takes
care
of
validating
the
case
spec.
So
that's
about
the
features
of
q,
fletched
and
now
how
cubefledged
works.
So
so,
if
you
are
interested
to
know
more
details
on
how
exactly
cube
fledged
works-
and
this
is
the
slide
for
you,
so
as
I
said
earlier,
there
is
a
custom
resource.
B
B
The
next
action
that
takes
place
is
validation
of
the
case
spec
right
and
this
validation
is
performed
by
the
q
fledged
webhook
server.
You
can
see
it
there
in
the
diagram,
so
it
it
functions
as
an
admission
controller,
so
cube
api
server
will
trigger
a
a
http
api
call
to
the
cubefledge
webhook
server.
That
is
called
as
the
validating
webhook
event
and
then
the
webhook
server
performs
the
validation
and
returns
back.
The
validation
result,
and
once
the
validation
result
is
successful,
the
api
server
will
persist.
B
The
image
cache
cr
in
etcd
and
the
moment
the
persistence
is
done.
The
image
cache
worker,
so
you
see
a
worker
at
the
left
side
of
the
q,
flashed
controller
and
basically
the
q
fledged
controller
is
the
primary
component
in
queue
fleshed
that
has
various
worker
routines.
For
instance,
there
is
a
image
cache
worker.
There
is
a
refresh
worker
and
there
is
an
image
manager.
B
So
the
image
cache
worker
will
actually
respond
to
new
image,
cache
crs
or
modifications
to
those
image
kcrs,
and
then
it
will
pass
the
manifest
and
then
build
image,
pull
or
delete
request
and
it
place
those
requests
in
a
specific
queue,
and
these
requests
are
in
turn
watched
by
the
image
manager.
The
image
manager
will
be
polling
the
queue
and
then
image
manager
once
it
sees.
B
So
there
is
no
special
component
that
is
required
to
be
run
on
the
worker
nodes
for
cube
flesh
to
pull
the
image,
because
the
image
is
actually
pulled
by
the
cubelet
running
on
the
node
and
once
the
jobs
are
successful,
the
image
manager
puts
the
result
into
another
separate
queue.
The
results
are
then
read
by
the
image
cache
worker.
B
It's
then
aggregated
and
then
the
final
result
is
updated
as
a
status
and
then
evens
are
also
generated
so
that
you
can
have
a
complete
understanding
of
what
is
going
on
with
the
image
cache
request,
and
you
can
also
query
the
events
later
to
understand.
What
exactly
was
happening
with
your
request
and
there
is
a
separate
refresh
worker,
which
is
responsible
only
for
refreshing
the
case,
so
it
runs
on
a
periodic
basis
and
this
periodicity
can
be
configured
and
on
the
on
a
periodic
basis.
B
It
checks
whether
the
image
cache
is
up
to
date
and
if
at
all,
it
sees
that
some
images
are
missing.
For
instance,
if
those
images
have
been
garbage
collected
by
kubernetes
or
if
it
if
those
images
have
been
accidentally
deleted.
So
whatever
reasons
if
the
refresh
worker
feels
that
the
image
has
to
be
pulled
again,
so
it
will
trigger
another
request
back
to
the
queue
and
then
again,
image
manager
will
get
triggered
and
then
the
cycle
goes
down.
B
Okay,
so
that's
pretty
much
how
cube
fledged
works
and
it
primarily
consists
of
the
cube
fetched
controller
and
the
q
fledged
web
hook
server.
So,
let's
move
on
so
if
you
want
to
learn
further
about
queue
play.
So
if
you
are
interested
in
the
image
gauge
functionality
from
image
caching
functionality
and
if
you
want
to
implement
a
image.
Caching
solution,
so
you
can
head
on
to
the
readme
file
of
cubefledged
github
repository.
B
B
So
you
will
have
use
cases
prerequisites
and
I
have
documented
all
the
three
different
ways
of
installing
cube
fledged
and
if
you
want
to
understand
what
are
the
parameters
that
are
exposed
by
the
helm
chart,
you
can
take
a
look
at
it
and
if
you
are
interested
in
rebuilding
q
fledged
yourself
and
deploying
it,
you
can
head
on
to
these
sections
to
understand
how
to
build
it
and
how
to
deploy
it.
Use,
deploy
it
yourself
and
there
is
extensive
documentation
on
how
to
use
it.
B
What
are
the
various
image
cache
actions
supported
and
you
can
take
a
look
at
how
it
works
and
what
are
the
various
configuration
flags?
So
all
the
documentation
is
available
here
and
if
you
want
to
get
more
details
on
the
background
of
this
idea
and
what
was
the
initial
thoughts
and
what
was
the
initial
design
proposal,
you
can
take
a
look
at
the
design
proposal
document
and,
very
recently,
sorry,
I
shouldn't
say
very
recently:
it
was
almost
two
months
back
and
I
wrote
a
tech
blog
describing
in
detail
about
image.
B
B
B
So
we
wanted
to
have
the
ability
of
building
the
image
cache
spec
automatically
from
pod
annotations,
so
rather
than
users
having
to
specify
upfront
the
description
of
the
image
cache
spec.
So
we
are
planning
to
introduce
an
option
which
should
allow
the
users
to
automatically
build
an
image
case
spec,
for
instance,
for
instance.
If
the
cluster
already
has
a
set
of
images
cached
in
these
nodes.
B
So
this
so
you
can
have
the
ability
of
building
an
image,
cache
spec
out
of
the
existing
images
or,
for
instance,
if
you
don't
want
to
pick
it
pick
all
the
images
in
the
cluster.
You
can
also
use
annotations
to
specify
whether
the
image
for
that
pod
has
to
be
cased
or
not.
So
that's
a
very
interesting
use
case
and
hopefully
we
will
be
able
to
implement
it
in
the
near
future
and
another
feature
that
we
are
contemplating
is
how
we
can
optimize
or
bring
in
more
efficiency
in
pulling
images
to
the
cache.
B
So
rather
than
pulling
the
images
from
each
and
every
node.
So
we
are
thinking
how
we
can
optimize
it
by
pulling
it
once
from
the
image
registry
and
then
distributing
it
internally
to
the
rest
of
the
nodes,
and
we
have
plans
for
hosting
cubefledge
in
the
operator
hub.
So
operator
hub
is
a
centralized
repository
wherein
you
can
find
different
types
of
operators,
and
hopefully
we
will
be
able
to.
B
We
will
be
able
to
host
q
fletched
in
operator
hub,
so
that
users,
who
who
consume
kubernetes
native
applications
in
the
form
of
operators,
they
can
easily
discover
cube
flesh
and
they
can
very
easily
consume
q,
fledged
and
start
using
it
and
the
fourth
one
that
we
have
in
mind
is
image
adoption
and
I
briefly
touched
upon
image
adoption
when
I
spoke
about
the
very
first
point.
That
is
image
case
spec
from
for
annotations,
so
image
adopted.
B
Adoption
is
basically,
if
you
have
images
already
present
in
the
cluster
and
if
you
want
to
adopt
those
images
into
q,
fletch
image
cache.
So
we
are
planning
to
introduce
features
for
that
as
well,
so
that,
once
you
adopt
those
images
into
a
q
flats
image
cache,
you
can
perform
various
operations.
For
instance,
if
you
want
to
delete
a
certain
image
from
all
the
nodes
in
the
kubernetes
cluster
the
moment
these
images
are
adopted
into
image
cache.
B
B
So
that
could
be
another
interesting
feature
wherein
cubefledge
will
more
evolve
into
and
evolve
into
an
image
management
solution
so
which
for
from
which
you
can
view
using
which
you
can
view,
for
instance,
what
are
the
images
that
are
present
in
your
cluster?
What
is
the
size
of
that
image
when
it
was
downloaded
who
downloaded
it?
B
Adoption
is
a
key
feature
that
can
enable
cubefledge
to
do
it
to
evolve
into
one
complete
image
management
solution,
but
but
for
the
immediate
future
the
focus
will
be
more
on
image,
caching
and
how
we
can
make
it
more
robust
and
how
we
can
bring
in
more
user
friendly
features.
But
over
a
period
of
time
we
definitely
see
image
queue
flashed
be
getting
evolved
into
an
holistic
image
management
solution
for
images
in
kubernetes.
B
Now
now,
if
you
are
interested
to
explore
other
options
for
solving
the
same
problem
right
so
here,
I
have
listed
three
similar
open
source
projects,
so
these
are
projects
that
eventually
try
to
solve
the
same
problem
of
starting
up
and
scaling
containers
very
quickly,
but
using
a
different
approach.
Okay,
so
the
first
such
project
is
star,
jesuit
snapshotter
this
this
is
actually,
and
this
is
actually
a
an
application
that
enables
you
to
do
lazy,
pulling
on
images.
So
it's
an
image,
distribution
plugin,
which
supports
lazy
pulling.
So
what
is
lazy
pulling?
B
Is
you
have
a
container
image
and
we,
it
has
multiple
layers
right
and
lazy.
Pulling
is
essentially
make
it
make
sure
that
what
files
are
immediately
required
for
the
container
application.
Those
files
alone
will
be
pulled
first
and
then
the
container
will
be
started
up.
So
when
the
container
starts
up,
it
will
start
consuming
the
files
that
are
already
pulled
and
in
the
meanwhile,
in
parallel.
In
the
background,
the
other
files
of
the
container
images
will
be
pulled,
so
there
will
be
some
amount
of
parallelism
happening,
and
this
is
what
is
called
as
lazy
pulling.
B
So
if
you
are
interested
in
such
kind
of
solutions,
you
can
use
star
g
z,
snap
shorter.
Another
project
is
kraken
from
uber,
and
it's
actually,
it
actually
employs
p2p
protocol.
So
what
it
does
is
basically
it
it
actually
pulls
the
image
from
the
docker
registry
and
then
it
distributes
those
images
from
the
very
nearest
node.
B
B
It
uses
bittorrent
protocol
to
distribute
images
and
it's
not
very
active,
so
these
are
some
of
the
options
that
you
can
leverage
and-
and
there
is
also
a
very
recent
announcement
from
google
cloud,
which
is
called
as
gke
image
streaming
so
image
streaming.
The
approach
is
little
bit
different,
so
what
happens
in
gke
image
streaming
is
basically
when
the
container
starts
up,
the
initial
files
required
for
that
container
will
be
actually
streamed
over
the
network.
So
it
will.
It
will
be
streamed
over
the
network,
so
probably
like
a
network
share.
B
So
when
you,
when
you
mount
a
network
share
and
then
you
consume
the
files
from
the
network
share,
what
eventually
happens
is
the
files
will
be
streamed
from
the
network
server
from
the
nfs
server,
so
very
similar
to
that,
but
it
is
actually
a
very
complex
solution,
so
it
there
is
also.
There
is
also
a
caching
layer.
B
There
are
multiple
caching
layers
implemented
in
gke
image
streaming
and
those
and
such
features
are
actually
targeted
for
very,
very
highly
sophisticated
environments
and
complex
requirements,
but
for
most
of
the
use
case,
use
cases
for
caching
images
and
for
managing
the
images
in
the
cache.
Cubefledge
will
be
very
useful
and
it
is
a
very
lightweight
solution.
It
doesn't
runs
any
agent
on
the
worker
nodes
and
it
has
a
webhook
server
which
performs
the
validation
of
the
case
spec,
and
there
are
some
cool,
user-friendly
features
that
are
in
pipeline
for
cubeless.
B
So
with
that,
we
have
reached
the
end
of
the
presentation.
So
thank
you
so
much
for
watching
this
talk.
I
hope
you
enjoyed
the
talk
very
much
and
I
really
hope
the
q
flash
project
will
be
useful
to
you.
So
if
you
have
any
further
questions
feel
free
to
reach
out
to
me
over
email
or
I
can
be
easily
found
on
twitter
and
I
am
fairly
active
on
twitter.
B
A
C
C
Yeah,
the
cost
of
using
q
pledged
is
basically
you
don't
have
to
pay
for
any
license,
because
the
cube
fledged
is
an
open
source
project
that
is
available
for
usage
using
the
apache
2.0
license
it's
a
very
liberal
license,
so
you
can
asthma
as
well
use
it
in
whatever
way
you
want.
So
there
is
no
cost
involved
in
using
tubefledge
for
caching,
your
images
in
kubernetes.
A
Thank
you
so
much
chancellor.
For
about
time,
we
only
can
pass
you
this
question
and
in
this
moment
we
will
we.
We
will.
Thank
you
so
much
for
this
presentation.
It's
an
a
very
interesting
tool
and
thank
you
so
much
also
for
the
four
recommenders
the
order.
Three,
three
tools
or
open
source
projects.
A
A
C
You
so
much!
Thank
you.
Thank
you
so
much
to
everyone.
Thank
you
for
giving
me
this
opportunity
to
meet
you
all.
So,
hopefully,
you
had
enjoyed
the
talk
and
you
can
as
well
check
out
the
project
and
if
you
have
any
questions
post,
an
issue
in
github
or
reach
out
to
me
on
twitter
or
email,
and
if
you
are
interested
in
contributing
there
are
lots
of
cool
features,
helpful
things
that
you
can
do
so,
hopefully
this
will
be
able
to.
C
D
Yeah,
thank
you
sadie
for
your
presentation.
I
think
that
it's
really
awesome
to
share
with
people
with
that
is
living
in
india
and
everything
sharing
with
people
from
guatemala.
The
difference
on
time
is
really
awesome
how
the
technology
connect
you
with
the
people
in
the
other
side
of
the
world.
So
thank
you
very
much
for
that.