►
From YouTube: PID 1, SIG Handling, Hooks & Probes: Managing Container Lifecycle Correctly - Anmol Krishan Sachdeva
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
PID 1, SIG Handling, Hooks & Probes: Managing Container Lifecycle Correctly - Anmol Krishan Sachdeva, OLX Group, Naspers
The lifecycle of an application should be tightly linked to the container hosting it. In an environment like Kubernetes where the Pods get created and deleted left, right, and centre, if an application hasn't implemented signal handling correctly, ungraceful termination of that application is most likely to happen and it could lead to disrupted services. For running the containers in a reliable fashion with proper signal handling and lifecycle management, there are a few strategies that should be followed which this talk would be covering: ~ Signal handling through `init` system - covers PID 1, orphans and zombie processes, Linux signals, `dumb-init` or `tini`. ~ Utilizing postStart and preStop lifecycle hooks for initialization and graceful termination. ~ Liveness, Readiness, and Startup probes. ~ Key differences between the postStart hook, initContainer, and Startup Probe.
https://sched.co/ekAC
A
Welcome
everyone,
my
name
is
annual
christian,
says
deva
hope
you
all
are
enjoying
kubecon
today
I'll
be
talking
about
managing
container
lifecycle
correctly
before
moving
forward.
Let
me
introduce
myself,
I
am
a
site,
reliability
engineer
and
currently
I
am
working
at
the
oilx
group.
I
am
an
international
tech
speaker,
a
distinguished
guest
lecturer
and
also
I
have
represented
india
at
reputed
international
hackathons.
A
I
love
doing
research
in
the
field
of
deep
learning
and
computational
neuroscience
and
have
eight
plus
publications.
To
my
account,
I
describe
myself
as
an
all-star
developer.
That
is
a
person
who
is
capable
of
designing
and
developing
solutions
for
platforms
like
web
mobile,
desktop
and
embedded
systems.
Apart
from
that,
I
also
like
mentoring
people.
Now,
let's
have
a
look
at
the
olex
group.
Olex
group
is
a
global
product
and
tech
group
consisting
of
20
plus
brands.
A
We
are
an
online
buying
selling
and
exchange
platform
serving
approximately
350
million
people
per
month
and
also
we
are
present
in
around
45
countries.
Across
the
five
continents
we
have
more
than
10
million
online
listings
every
single
month
and
we
have
billions
of
headshots
per
day.
Also,
we
have
hundreds
of
thousands
of
cache
sheets
per
second,
and
all
of
this
is
packed
by
hundreds
of
micro
services
that
we
run
in
our
kubernetes
clusters.
That's
fantastic!
A
Let's
have
a
look
at
the
infrastructure
landscape,
mostly
the
tools
and
platforms
that
we
use
at
olx
belong
to
the
cncf
landscape.
I
will
not
be
drilling
down
into
details
of
this.
Let's
have
a
look
at
the
agenda
of
today's
talk.
Today's
talk
is
divided
into
six
segments.
The
first
segment
is
about
unix
processes
and
init
systems,
we'll
be
talking
about
zombies
and
orphans.
Also,
in
this
section,
the
next
section
is
about
managed
lifecycle
here,
we'll
be
talking
about
pardon
container
lifecycle,
along
with
linux,
signal
handling.
A
The
third
section
talks
about
resiliency
and
high
availability
through
health
checks
and
probes.
Specifically,
we
will
be
talking
about
liveness,
probe,
readiness,
probe
and
startup
pro.
The
fourth
segment
is
about
life
cycle
hooks
and
graceful
termination
of
bot
we're
going
down
into
deep
detail
of
how
graceful
termination
happens.
A
A
A
A
A
Let's
have
a
look
at
zombies,
so
what
are
zombies
suppose
a
process?
Is
there
consider
pid4
in
our
case,
and
this
process
has
terminated
once
the
process
has
terminated.
It
is
referred
to
as
defunct
or
zombie
process.
What
a
zombie
process
basically
means
it's
a
process
which
has
terminated
but
has
not
been
waited
for
by
its
parent.
A
Now.
What
means
by
waited
for
waited
for
basically
means
that
the
parent
actually
waits
for
the
child
to
return
its
exit
code
or
the
exit
status,
so
that
the
parent
can
actually
release
the
resources
that
it
is
holding
and
this
process
is
often
called
as
reaping
so
basically
parent
triggers
weight,
pid
system
call
here.
A
A
Now
what
happens
if
a
process
loses
its
parent?
Consider
in
our
case,
pid4,
which
is
a
child
process
of
pid
2
but
pid
2,
has
somehow
got
terminated
from
now
onwards.
Pid
4
will
be
called
as
often
process
because
it
doesn't
have
any
parent
in
unix
systems.
Pid
1
is
responsible
for
reparenting
the
child
to
itself,
so
pid4
will
now
become
child
of
pid
1,
because
pid
1
will
re-parent
erd4.
A
A
If
the
number
of
zombie
processes
is
high,
then
the
creation
of
new
processes
may
not
be
possible
because
resource
starvation
may
be
there
having
zombies
inside
the
containers
also
poses
some
challenges.
Generally,
one
main
application
process
runs
per
container
and
it
is
treated
as
pid
1.
So
whatever
we
specify
in
the
entry
point
of
the
container
is
treated
as
pid
1.
now
say
we
have
coded
an
application
to
solve
a
specific
purpose.
A
A
A
There
comes
a
need
of
having
a
proper
unit
system
in
our
containers.
Now,
sometimes
people
use
bash,
but
the
thing
is
that
bash
is
able
to
perform
some
of
the
reaping
functions
but
is
not
able
to
handle.
The
signals
properly
is
not
able
to
pass
the
signals
which
it
receives
from
the
operating
system
to
the
child
processes.
A
A
A
So,
let's
not
wait
and
get
started
with
setting
up
tiny
setting
up
tiny
is
pretty
straight
forward.
On
the
left
hand
side
you
see
a
code
snippet.
This
is
the
docker
file.
The
first
four
lines
actually
are
the
contents
of
a
docker
file
which
contains
the
command
to
run
a
python
program
inside
the
top
container
lines.
7
to
13
are
relevant
for
us,
so
we
will
be
focusing
on
them.
We
just
need
to
specify
version
of
ine
and
the
remote
url
from
where
we
can
fetch
the
release.
A
Then
we
just
set
the
permission
of
this
binary,
and
then
we
provide
the
entry
point.
Entry
point
can
be
provided
as
tiny,
followed
by
two
hyphens.
Then
we
just
need
to
supply
a
regular
command
like
we
did
before
now.
This
defunct
dot
pi,
which
is
a
program
that
I
want
to
run
inside
the
container.
Its
content,
are,
on
the
right
hand,
side.
This
program
actually
shows
how
zombies
are
created
and
how
orphans
are
read,
so
we'll
be
having
a
quick
look
in
the
next
step.
A
A
A
The
first
one
actually
shows
the
process
as
defunct
process
and
it's
also
labeling
the
prd8
as
zombie
process.
The
second
one
also
shows
that
pid8
will
be
zombie
process,
but
it
actually
reaps
the
zombie
process,
so
we
are
not
having
any
defunct
label
like
we
had
in
the
first
case,
so
using
tiny
actually
reaps
the
zombie
processes.
This
is
a
simple
example,
which
shows
the
same.
So
let's
discuss
more
details
on
tiny
before
moving
forward.
This
is
a
script
which
I
used
for
creating
the
zombies.
A
A
So,
who
is
a
subreaper
subreaper
is
any
process
which
is
not
running
as
pid
1,
but
can
actually
perform
the
function
of
reaping
so
tiny
can
do
it
pretty
simply
just
need
to
pass
another
argument,
so
it
is
hyphen
s,
so
it
looks
like
tiny
hyphen
is
followed
by
double
hyphens,
and
the
special
thing
about
tiny
is
that
it
exists
with
the
child's
exit
code
and
remapping
is
also
possible.
So
if
you
want
to
remap
some
say
exit
code
to
something
else,
we
can
do
that
with
tiny.
A
Let's
move
on
with
the
managed
life
cycle
till
now.
We
have
understood
how
processes
work
in
containers
and
how
to
manage
them
through
init
systems.
Now
we'll
be
discussing
about
the
lifecycle
of
container
and
box,
there
are
five
distinct
phases
of
a
false
life
cycle.
These
are
pending,
running
unknown,
succeeded
and
failed.
A
Pending
state
means
that
the
part
has
been
created
through
the
api
and
is
waiting
for
some
node
to
get
your
rule
on
the
running.
State
means
that
the
pod
is
operational
and
is
running.
Fine
unknown
state
is
a
rare
reference
and
it
means
that
the
kubernetes
cluster
has
some
internal
problem
due
to
which
it
is
unable
to
communicate
with
the
pod.
Then
comes
the
last
two
states.
These
are
often
found
when
we
use
cron
jobs.
A
One
is
succeeded,
which
means
that
the
pot
has
finished
normally,
the
other
one
is
failed,
which
means
the
pot
has
crashed.
Kubernetes,
also
watches
the
state
of
all.
The
containers
and
containers
have
three
states
in
their
life
cycle.
The
first
one
is
waiting.
The
second
one
is
running.
The
third
one
is
terminated.
A
Waiting
state
means
that
the
container
is
performing
some
operations
which
are
required
before
the
startup.
It
may
be
pulling
images
or
applying
secrets
running
means
that
it
is
running
without
any
issues
and
terminated
means
it
may
have
suffered
some
failure,
or
it
may
have
succeeded
to
know
about
the
exact
reason
for
termination
of
the
container
one
may
use
the
queue
control
describe
port
command.
A
Now,
let's
talk
about
something
really
important.
The
graceful
termination
process
when
talking
about
an
application's
performance
and
behavior
one
thing
to
consider
is
that
whether
the
application
handles
the
termination
process
gracefully
or
not
handling
the
termination
process,
gracefully,
it
means
whether
any
cleanups
are
required
or
not
before
terminating
there
may
be
some
need
of
cleaning
up
files.
There
may
be
some
need
of
cleaning
up
the
resources,
maybe
releasing
some
connections
making
transactional
commits
and
if
not
done,
this
may
impact
the
performance
of
the
application,
and
this
may
impact
the
users.
A
A
A
A
Then
comes
the
sec
term
signal
which
is
sent
to
pid
1
of
each
container
there.
That
is
there
in
the
pot.
Here
comes
the
role
of
the
edit
system
and
signal
handling
that
we
talked
about
earlier
today.
If
one
is
using
an
image
system
and
then
it
can
be
ensured
that
proper
system
forwarding
is
happening.
However,
it
still
depends
on
the
application
whether
it
can
handle
the
signal
or
not.
We
will
discuss
about
this
and
how
to
deal
with
such
situations.
Shortly
then
comes
the
fourth
stage.
A
It
is
when
the
grace
period
ends
and
the
sick
kill
is
actually
issued.
Then
the
api
server
deletes
the
ports
api
object
and,
finally,
the
port
terminates:
let's
analyze
the
termination
lifecycle
through
a
time
series
graph.
Suppose
the
pot
enters
the
terminating
state
here
and
stops
receiving
any
sort
of
traffic
race
period
is
set
and
the
pre-stock
hook
starts
executing,
say
the
hook
got
executed.
By
this
point,
then
sec
turn
signal
is
issued
to
all
the
containers
in
the
pot.
Once
the
grace
period
ends,
sequel
is
issued
and
the
pod
forcibly
shuts
down.
A
This
is
the
complete
termination
lifecycle
all
right.
So
now
is
the
time
to
learn
about
achieving
resiliency
and
high
availability
through
the
use
of
health
checks
and
probes.
Let
us
understand
the
help
of
pattern.
First
and
its
need.
Kubernetes
should
know
the
state
of
the
fort
so
that
it
can
decide
whether
to
send
the
request
to
the
bot
or
not.
A
All
of
this
becomes
easy
if
the
container
exposes
some
apis
for
different
kinds
of
health
checks.
Kubernetes
containers
are
self-healing
entities.
There
is
a
component
called
the
cubelet
which
runs
on
each
node
and
is
responsible
for
bringing
up
the
containers
and
keeping
them
running.
The
cubelet
even
restarts
the
containers.
In
case,
if
there
is
any
crash,
this
is
done
by
doing
generic
health
checks
against
the
containers,
and
it
is
called
the
process.
Health
check.
A
A
It's
not
weird,
and
it's
common
deadlocks,
memory,
leaks,
infinite,
loops,
thrashing
and
many
other
reasons
may
be
true.
Applications
should
be
able
to
handle
some
of
the
mentioned
problems
by
using
some
complex
logic.
However,
there
needs
to
be
some
sophisticated,
reliable
and
an
easier
way
to
tackle
such
problems.
A
A
It
helps
in
achieving
resiliency
and
also
helps
in
better
load,
balancing
and
routing
of
traffic,
since
the
pods,
which
are
not
ready
to
receive
the
traffic
because
maybe
their
containers
are
unhealthy,
will
have
either
their
containers
restarted
or
the
traffic
will
not
be
sent
to
them.
This
will
also
ensure
timely
response
to
the
requests.
Now,
let's
look
at
some
technicalities
of
probes.
Probing
is
basically
possible
via
calling
handlers
implemented
by
the
containers,
and
there
are
three
types
of
handlers:
exec,
tcp
and
http.
A
A
The
resultant
states
can
be
success,
failure
or
unknown.
Now
coming
to
the
probes.
There
are
three
types
of
probes
that
we
will
be
covering:
one
is
liveness,
one
is
readiness
pro
and
other
one
is
startup
pro
talking
about
the
liveness
pro.
It
helps
in
identifying
whether
the
container
is
alive
or
dead.
In
case
a
failure
is
observed
in
the
liveness
pro.
The
cubelet
kills
the
container
and
then
restarts
it.
Whether
the
container
will
restart
actually
or
not
depends
on
the
restart
policy
of
the
container,
which
can
be
always
never
or
on
failure.
A
We
will
see
the
implementation
of
liveness
probe
shortly
before
moving
forward.
Let
me
give
you
some
tips.
First,
one
is
that
always
define
a
liveness
pro
for
bots
running
in
production.
It
is
really
important.
Second,
is:
have
the
application
expose
a
health
check
api
in
the
format
of
say,
slash,
health
or
something
like
that.
A
The
health
check
api
should
not
require
any
kind
of
authentication
else.
The
probe
will
always
fail.
This
is
a
point
that
should
be
noted,
then
keep
it
light
on
computational
resources,
don't
put
much
complex
logic
in
the
liveness
probe
section
probe.
Cpu
time
is
part
of
the
container
cpu
time
quota,
so
you
should
not
be
putting
any
kind
of
complex
logic
in
the
liveness
probe
before
moving
forward
with
the
demo.
I
would
first
like
to
cover
the
concept
of
readiness
group.
A
A
readiness
probe
signals
whether
a
container
is
ready
to
accept
new
connections
or
not
say
during
the
startup.
Some
warm-up
procedure
is
to
be
followed,
and
this
may
take
some
time,
so
the
container
can
actually
delay
sending
request
to
the
pod
using
the
readiness
proof.
Another
use
case
can
be
to
stop
sending
requests
to
the
port
when
the
container
is
actually
overloaded.
A
It
must
be
noted
that
until
all
the
containers
are
ready
for
a
pot,
the
pot
isn't
treated
to
be
ready,
unlike
liveness
pro
on
failure
and
readiness
probe
a
container
isn't
killed.
It
should
also
be
noted
that,
after
receiving
acetone
signal
sale,
even
though,
if
the
radiance
check
passes
kubernetes
tries
not
to
send
new
requests
to
the
container
now,
let
us
understand
how
to
use
liveness
and
readiness
probes
in
kubernetes,
using
the
code
for
demonstrating
the
usefulness
of
liveness
and
readiness
pro.
A
A
A
There
are
three
new
terms
which
you
can
see
initial
delay
seconds,
failure,
threshold
and
period
period
seconds,
so
initial
delay
seconds
is
basically
the
time
by
which
we
have
to
delay
the
probe,
so
the
probe
will
start
after
two
seconds
of
the
start
of
container.
In
this
case,
and
likewise
the
readiness
probe
will
start
after
two
seconds
of
the
container.
A
So
basically
there
will
be
a
delay
of
two
seconds
and
then
the
probes
will
start
working.
You
can
have
different
values,
liveness
and
regular
respect.
Then
we
have
failure.
Threshold
failure
threshold
specifies
how
many
times
the
probe
is
allowed
to
fail,
and
in
my
case
I
have
specified
as
two
and
two
in
both
then
period
seconds
basically
sets
the
periodicity
or
the
frequency,
after
which
the
probe
should
hit
again
the
application.
A
So
it's
two
seconds
in
our
case
now
coming
to
the
application
code.
This
is
just
a
snippet
and
the
application
code
is
a
bit
huge.
It
actually
has
different
routes,
so
health
ready
is
one
health
ready,
stop
ready.
Is
there
health
start
ready?
Is
there?
Health
ready
basically
tells
whether
the
pod
is
ready
or
not
just
it
prints
something
and
then
gives
200
as
the
code.
If
the
pod
is
ready,
it
prints,
the
pod
is
not
ready
and
gives
502
code
if
the
pod
is
actually
not
ready.
A
A
Likewise,
I
set
pod
ready
to
be
equal
to
0
here
in
health
start
ready
and
we
can
play
around
this
in
the
demo.
So
let's
have
a
look
at
the
demo,
so
just
for
quick
demo,
here's
the
file,
here's
the
port,
manifest
file
which
contains
the
liveness
proven
readiness
group
sections,
as
explained
in
the
slides.
So
let's
apply
this
yammer
and
see
how
the
parts
react
so
you'll
see
the
parts
are
coming
so
basically
there's
only
one
port,
so
python
health
is
the
name
of
the
part
so
I'll
just
start
tailing.
The
logs.
A
A
Now
I
have
started
the
port
forwarding,
let
me
hit
8989
and
I
should
see
some
response
hello
from
python
now.
Let
me
try
and
hit
here
health
life,
and
it
should
hopefully
give
me
the
pod.
Is
life
right,
I'll
hit
it
multiple
times
and
also
just
so
that
you
can
see
the
response
code?
Let
me
open
the
network
console,
so
it's
giving
me
200
again,
200,
okay,
now,
let's
try
with
ready
okay.
A
So
we
see
that
here
we
are
always
getting
200
as
a
response.
Now
let
me
do
one
thing:
let
me
stop
the
readiness
before
hitting
enter
just
see
that
here
we
are
having
one
one
as
the
ready
state.
So
one
one
running
here
as
a
ready
state,
and
here
we
are
having
200
as
the
response
for
ready
health
ready.
A
A
Now
let
me
resume
the
readiness
state
for
this
by
hitting
the
api
again,
so
start
ready
should
actually
do
and
then,
if
I
hit
ready
again,
I'm
able
to
see
the
cord
in
running
state
so
see
the
purple
lines
have
gone.
The
pod
has
again
become
ready.
So
basically,
what
I
did
was
I
failed
the
readiness
pro
so
that
the
traffic
doesn't
get
routed
to
my
pod.
A
So
you
see
you
were
getting
purple
lined
healthy
health
life
and
now
the
pot
must
be
the
container
must
be
serving
its
graceful
period
and
shortly
we
should
see
a
restart
happening
here
and
what
we
can
do
is
simultaneously.
We
can
see
the
describe
output
of
the
parts
here,
so
you
see
liveness
probe
field
with
502
and
then
you
can
see
the
restart
count,
also
bumped.
A
So
that's
all
for
the
demo
for
the
liveness
probe
and
readiness
pro,
let's
get
back
to
the
slides
and
start
with
the
next
section.
So
before
moving
forward
with
the
next
section,
we
need
to
discuss
about
startup
probe.
Also
so
startup
probe
is
basically
a
probe
which
indicates
whether
the
application
within
the
container
has
started
or
not.
All
the
other
probes
are
disabled
until
the
startup
process
succeeds
and
also
it
is
mainly
used
with
slow
starting
containers.
A
It
may
share
the
same
probing
mechanism
as
that
of
liveness
probe
and
readiness,
both
and
in
case
of
sttp
get
method
they
all
all
the
three
of
them
can
use
the
same
path
also,
but
the
behavior
of
the
three
probes
is
different.
Now,
let's
quickly
have
a
look
at
the
lifecycle,
hooks
lifecycle
hooks
are
actually
required
for
managing
the
container
lifecycle
in
a
better
manner,
since
only
signal
handling
is
not
the
thing
which
we
need
to
worry
about,
so
there
are
two
lifecycle
hooks
available.
One
is
postdot
and
one
is
pre-stock.
A
Postart
hook
is
actually
executed
just
after
the
container
starts
and
it
runs
parallely
with
the
main
container.
It
can
be
used
to
implement
some
warm-up
logic
or
maybe
a
signal
to
an
external
listener
about
the
application
getting
started.
Also,
it
can
be
used
to
do
some
pre-conditional
checks.
It
must
be
noted
that
there
are
no
guarantees
of
the
post
start
hook
running
and
also
it
makes
the
container
stay
in
the
waiting
state
till
it
has
executed
fully
and
keeps
the
pod
in
pending
state.
A
It
may
also
happen
that
the
hook
gets
executed
fully
even
before
the
main
process
has
started
fully
and
in
case
of
any
failure.
No
return
has
happened.
The
container
restarts,
depending
on
the
restart
policy
of
the
container,
now
talking
about
the
pre-stock,
it's
a
call
that
is
sent
to
the
container
before
it
is
terminated
and
it
triggers
the
graceful
termination
process.
A
So
basically,
it
is
used
to
execute
some
graceful
termination
logic,
either
outside
the
application
or
by
having
some
application
endpoint,
which
can
be
triggered
which
can
trigger
actually
the
graceful
termination
of
the
app
in
case
of
third-party
managed
containers.
Also,
this
comes
handy.
We
at
olx
are
using
pre-stock
book
heavily
and,
to
quote
an
example,
we
have
a
chat
server
powered
by
azure
bird
and
it
uses
the
pre-stock
hook
to
clean
up
the
redis
connections
and
entries
on
termination
of
the
azure
wordpod.
A
Let's
revisit
the
termination
lifecycle
graph
and
see
where
the
pre-stock
hook
fits
in.
So
as
you
can
see
here,
the
pre-stock
hook
is
actually
immediately
called
as
the
craze
period
starts
and
it
ends
before
the
sector
signal
actually
starts,
so
it
can
be
used
to
handle
graceful
termination
effectively
and
even
for
the
cases
where
the
application
don't
implicitly
support
graceful
termination.
This
can
be
used
to
have
the
graceful
termination
done
for
those
applications.
Now,
let's
quickly
see
how
these
books
can
be
implemented
in
kubernetes.
A
So
here
is
the
snippet
of
the
code.
I
am
actually
adding
a
line
in
both
the
hooks
to
index.html
of
engineering,
so
I
am
using
nginx
image
line,
9,
actually
states
the
life
cycle
section
and
inside
that
we
have
post
start
and
free
stock.
Then
we
have
a
command
here
specified
for
post
up
and
please
drop
respectively
in
playstore.
I
am
doing
additionally,
the
prenup
of
nginx
after
the
scope
actually
executes.
A
A
All
right
now
is
the
time
to
discuss
about
the
unit
containers
so
when
your
containers
are
specialized
containers
that
run
before
the
application
containers
room,
and
that
also
means
that
they
are
separate
from
the
application
containers
and
run
on
separate
images.
These
may
contain
some
setup,
which
is
not
present
in
the
main
application
image
and
multiple
unit
containers
can
run
inside
a
port
and
almost
run
successfully
and
sequentially
in
the
specified
order.
A
In
the
manifest,
also,
though,
any
unit
containers
don't
support
any
sort
of
hooks
or
probes
that
we
have
seen
so
far
in
case,
if
there
is
any
failure
which
unit
containers
encounters,
it
depends
on
the
parts
restart
policy
whether
to
restart
the
init
container
or
not.
If
it
is
set
to
always,
then
it
will
always
restart.
Also
init
containers
can
share
the
same
volumes
and
that
of
the
application,
containers
and
altering
any
kind
of
code
in
the
unit
container
leads
to
restarting
of
the
point.
Let
us
now
see
how
to
implement
init
containers
in
kubernetes.
A
Here
I
am
using
an
nginx
container,
which
is
an
application
container
and
a
busybox
container,
which
is
the
init
container.
Both
are
using
the
same
empty
directory
volume,
the
init
container
just
modifies
the
index
file
of
the
nginx
container
and
let's
see
how
it
happens.
So
let
me
apply
the
manifest.
A
A
Now
the
part
is
coming
to
the
start:
state
it's
initializing
basically,
and
this
it's
running,
let's
go
to
nginx
and
see
what
it
is
displaying
this
displaying
hello
world
from
internet
container.
So
this
shows
that
in
a
container
was
able
to
modify
in
the
nginx
index.html
file.
Now,
since
we
have
seen
how
the
inner
container
works,
let's
see
at
the
usage
of
internet
controllers
here,
containers
can
be
used
for
delaying
the
application
container
startup
or
can
be
used
to
perform
pre-condition
sets.
They
can
also
be
used
to
run
utility
support.
A
That
is
not
part
of
the
application
container.
They
can
be
used
to
see
data
in
database
before
the
application
start.
Even
it
can
be
run
to
it
can
be
run
to
configure
things
at
the
runtime
and
wait
for
something
to
become
available.
Maybe
a
db,
maybe
a
service
that
that
needs
to
be
available
before
our
application
starts.
It
can
also
perform
database,
schema,
migrations
and
preparation
and
also
prepare
the
schema,
and
it
can
also
be
used
to
create
user
accounts.
So
several
use
cases
are
there
wherein
we
can
use
the
in-depth
containers.
A
A
So
first,
let's
set
the
parameters
based
on
the
container,
so
yeah
post
start
hook
can
be
used
inside
the
same
container
as
well
as
startup
probe
can
be
used
inside
the
same
container,
but
init
container
requires
a
separate
container,
so
application
container
is
different
and
energy
container
is
different,
then
the
score,
so
scope
of
post
art
hook
is
limited
to
a
container.
Likewise,
scope
of
the
startup
rope
is
limited
to
a
container,
while
the
init
container
scope
is
not
restricted
to
a
container
but
to
the
whole
pot.
A
So
init
containers
are
bound
to
the
pot
and
not
some
particular
application
container
now
running
the
container
image.
So
init
container
has
the
freedom
to
run
the
same
or
separate
image,
but
the
post
art
hook
and
startup
probe.
Don't
have
this
privilege,
so
they
run
on
the
same
image
as
that
of
the
application
because
they
are
running
inside
the
same
container
and
the
run
guarantees
suppose
start
hook
has
no
guarantee
at
all
and
rest
of
the
two
must
run
successfully
in
order
to
proceed
forward.
A
Then
talking
about
the
failure,
thresholds
and
restarts
so
startup
probe
can
have
the
threshold
specified
and
those
should
be
decent
in
number
should
be
a
bit
higher
than
what
we
specify
for
lightness
program.
Readiness
for
for
post
start
hooks.
We
don't
have
any
threshold,
but
we
starts
happen
depending
on
the
pods
restart
policy
and
for
the
init
containers
restart
actually
happens
again
depending
on
the
parts
restart
policy
and
in
case
the
post
start
hook
actually
fails.
Then
the
container
fails
and
the
container
actually
restarts
and
requests
usage.
A
So
usage
is
almost
similar,
but
the
distinct
things
I'll
mention
here
so
post
art
is
generally
used
to
signal
the
external
listeners
that
my
application
is
going
to
start
now
or
maybe
it
can
be
used
for
preconditional
checks
and
may
be
introducing
some
delays,
specifically
init
containers.
I
have
covered
separately
so
this
can
be
used
for
various
initialization
purposes
and
for
startup
probes.
A
It
is
appropriate
for
slow
starting
containers
and
we
must
be
specifying
some
huge
number
in
the
failure
threshold
last
is
the
count,
so
init
containers
can
be
multiple
in
numbers,
so
we
can
have
10
unit
containers
depending
on
say
or
needs,
but
for
start
hook
can
be
one
and
we
can
choose
between
the
mechanisms
that
are
present
for
the
post
output.
Likewise,
there
can
be
only
one
startup
probe
and
we
can
choose
with
between
the
different
mechanisms
for
probing
thanks
a
lot
for
joining
this
talk.