►
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
The Gotchas of Zero-Downtime Traffic /w Kubernetes - Leigh Capili, Weaveworks
Noticing your customers receive 503's every now-and-then? Do they spike when you're updating your app or rotating your k8s cluster nodes? Maybe you used to have this problem -- then you added some strange settings and it's mostly working now… What most people need from Kubernetes regarding web-traffic is a repeatable but under-documented combo of esoteric, non-default options. We'll walk through the basic needs of shaping traffic and apply that knowledge to the states of compute, rollout, and canonical networking we see with k8s. Expect tidbits about CRI, CNI, Ingress, and the design trade-offs present in Kubernetes and its API's. You’ll leave this session knowing how to keep your apps serving successful requests for a myriad of edge-cases.
https://sched.co/Uads
A
Preparations
in
the
legacy
days
got
it
right
pro
quo.
I'm
trying
to
get
paid
chillin
out
maxin,
then
deploying
I'll
cool
got
FTP
to
the
server
pool.
When
a
couple
configs,
they
were
drifting.
A
miss
trying
to
get
sleep
got
paged
on
this,
how
to
work
all
words
and
then
where's
Whistler
finally
sit
up
one
of
those
hot
Kate
clusters.
First-Class
declarative,
apps
drinking,
mounting
jus
out
of
a
champagne
glass.
Is
this
what
the
people
at
Google
a
living
like
hey?
A
A
Take
you
to
where
you
want
to
go,
but
before
we
get
too
deep
into
heavy
crazy
llamó
definitions
and
the
long
really
really
really
long
words
like
termination
grace
period,
I
just
want
to
talk
a
little
bit
about
what
it
means
to
deploy
with
zero
downtime,
because
we've
been
doing
this
for
a
long
time.
Kubernetes
is
not
a
new
thing.
It
captures
patterns
that
we've
been
sharing
with
each
other
in
the
community,
for
you
know
quite
a
while
years
and
years
and
years
on
several
platforms.
You
know
people
writing
deployment
scripts
on
ec2.
A
You
know
in
your
VMware
cloud
and
so
if
you've
got
two
verses
of
an
app
save
blue
and
green.
The
first
thing
that
you
should
be
very
aware
of,
especially
if
you
work
on
a
software
team
here,
is
that
as
you're
shifting
traffic
over
in
between
versions,
your
code
needs
to
be
able
to
serve
traffic
from
multiple
versions.
At
the
same
time,
the
second
thing
I
could
talk
about
is
screens
like
this
right.
A
So
normally,
when
you
deploy
an
app,
you
get
your
server's
up,
and
then
you
spin
up
that
second
set
of
servers
and
then
the
first
thing
you're
gonna
do
is
you're
going
to
look
at
the
HTTP
box
right.
So
we
got
SSH
we're
getting
in
we're
checking
engine
X
we're
seeing
our
users
they're
happy
they're,
looking
at
our
service
except
you're,
a
pro.
So
you
don't
just
look
at
like
one
log.
A
You've
got
like
six
terminals
open,
there's
the
empty
ones
right,
yeah,
yeah,
everyone
there's
some
people
here
have
done
this
and
you're
expecting
you're
gonna
shift
this
traffic
over
right
from
the
top
once
to
the
bottom.
Once
you
got
the
a
group
in
the
B
group,
so
all
of
your
applications
are
up
and
ready.
They
didn't
start
that
way.
A
You
had
to
wait
for
them
to
start
up
because
we're
using
Java
and
then
you're
shifting
the
traffic
over
right
you're
in
the
low
balancer
config
like
sending
a
cig
to
engine
X
and
now
you're
in
the
connection
draining
period
right,
because
you
know
it's
like
when
you
actually
update
that
config
there's
still
stuff
going
to
those
old
servers,
then
once
everything's
kind
of
done,
you
can
send
this
magical
signal
to
your
application.
Maybe
it's
a
sig
term.
A
Maybe
it's
a
huff
or
something,
and
then
you
tell
the
app
okay,
nothing
is
coming
anymore,
but
if
you're
still
working
on
any
Kress
requests,
like
maybe
there's
like
a
30
second
latency
on
some
crazy
service,
you
have
make
sure
to
finish
that
I'm
gonna,
send
you
a
graceful
signal,
give
you
a
chance
to
shut
yourself
down
and
if
something's
gone,
really
wrong.
You
know,
after
a
really
long
time,
it's
like
in
five
minutes.
You
just
got
to
go,
send
those
things
that
kill
now
you're
on
the
B
group
right
great.
A
So
we've
been
talking
about
kubernetes,
mostly
at
this
conference,
a
lot
of
other
great
technologies.
But
many
of
us
are
concerned
with
the
quality
of
the
platform
that
we
put
onto
these
servers
running
this
new
project.
Community
run
captures
really
great
patterns
and
kubernetes
has
a
couple
of
API
objects.
The
major
one
is
the
pod.
Each
pod
gets
an
IP,
you
also
have
services.
A
Additionally,
ingress
controllers
are
super
interested
in
endpoints
right,
so
the
service
controller
updates
to
the
endpoints
list
with
a
bunch
of
pot
IPS
and
the
ingress
is
responsible
for
configuring
that
load
balancer
right
in
the
previous
diagram.
We've
had
Engine
x
over
on
the
far
left,
and
then
we
have
like
other
load
balancers.
You
have
the
solo
I
you
go
glue.
You
have
envoy
a
all
of
these
things
right
and
the
load
balancers
job
is
to
distribute
all
of
the
requests
that
are
coming
in
in
some
kind
of
central
or
distributed
place
to
your
backends.
A
So
what
happens
then,
when
we
say
want
to
turn
one
of
those
old
backends
off
kuba
API
servers
receives
a
delete
from
something
pod
should
no
longer
exist,
and
it
goes
through.
The
state
machine,
I'm,
gonna,
mark
the
pot
as
terminating
and
as
a
async
consequence
of
the
pod
being
marked
terminating.
The
service
controller
will
remove
the
endpoint
from
the
list.
That
means
that,
at
some
point,
your
ingress
controller
is
gonna.
A
Stop
routing
things
there
right
at
that
same
time,
any
pre
stop
hooks
are
gonna
run,
you
might
not
know
about
life
cycle
and
priests
top
hooks
yet,
and
then
the
first
process
inside
of
the
container,
will
receive
a
sig
term.
You
cannot
really
change
this
much
in
kubernetes.
Officially,
then,
the
termination
grace
period
starts
so
your
application
now
has,
by
default
30
seconds
to
gracefully
shut
itself
down
in
the
polite
way
right.
A
It's
like
kubernetes,
hey
I'll,
give
you
some
time
and
then,
if
the
termination
grace
period
passes
and
the
app
hasn't
fully
exited
paid
ones
still
running
inside
of
the
container,
then
kubernetes
will
politely
rip
the
process
table
out
from
the
kernel.
So
all
right,
so
here's
the
gotcha
number
one.
A
Let's
just
talk
about
signal
handling
for
a
second
say,
you
write
a
docker
file
and
then
you
just
write
command
and,
like
some
random
string,
you
don't
use
the
array
syntax
well,
that
guy
rats
that
gets
wrapped
in
a
shell
and
shells
like
SH
and
bash-
they
don't
pass
signals
like
you
would
expect
them
to
so.
This
is
not
something
that
you
want
to
do
in
images.
You
kind
of
want
to
lint
your
docker
files
to
make
sure
that
you
are
using
these
array.
Syntax
such
as
this
entry
point
where
you
have
the
quoted
brackets.
A
If
you're
gonna
use
a
shell
I
would
do
it
explicitly.
You
know
an
invoke
a
script
like
a
docker
entry
point
SH
you
see
that
commonly
and
that
script
ax
can
then
pass
signals
and
do
traps
and
all
that
kind
of
stuff
if
you
need
to
do
scripting.
So
the
second
thing
is
I
talked
about
stop
signal
and
I
mentioned
that
you
can't
officially
override
this
thing
in
kubernetes.
Kubernetes
is
documented
and
will
always
kind
of
just
send
that
sig,
if
you're,
using
docker
and
container
D
and
I
believe
I,
don't
know.
A
Cryo
may
support
this
as
well.
You
can
override
in
your
image
a
stop
signal
and
this
will
be
respected.
So,
instead
of
sending
a
cig,
if
say
you're
running
engine
x4
serving
static
assets
inside
of
your
cluster,
you
may
need
to
override
the
image
to
be
stopped
with
sig
hub
right
for
a
formal,
graceful
shutdown
or
you.
Whiskey
does
some
other
really
insane
stuff.
When
you
send
it
a
sig
term-
and
there
are
some
ways
to
configure
around
that,
but
basically
not
all
apps
are
gonna
behave
in
the
same
kind
of
semantics.
A
Yeah?
It's
not
it's
not
clear
to
me
whether
this
directive
is
formally
supported
by
CRI,
like
if
I
put
a
stop
signal
inside
of
my
image.
If
anyone
knows
the
answer
to
that
and
whether
there's
like
a
OCI
standard
thing,
I'd
love
to
hear
so
it's
there's
no
documentation
so,
and
the
next
thing
is
we've
heard
sometimes
that
you
got
to
use
readiness,
probes,
liveness
probes
as
well.
A
Henning
Jacobs
has
a
great
post
about
liveness
probes,
I,
wouldn't
recommend
to
using
them
right
out
of
the
bat
they're
pretty
dangerous
and
I
can
talk
about
some
reasons.
Why?
But
the
readiness
probe,
if
you're,
using
an
HTTP
service
to
serve
your
customers,
is
very
important.
We
talked
a
little
bit
about
pod,
shut
down.
Readiness
probes,
I,
would
say,
are
more
important
for
pod
start-up,
sometimes
especially
again,
if
you're,
using
an
application
that
has
a
long
warmup
period
like
something
that
runs
on
the
JVM.
A
You
may
have
a
significant
period
of
time
where
your
applications
either
not
possible
to
serve
a
connection
or
it
may
not
be
appropriate
because
it's
not
warm
yet
and
so
having
a
readiness
probe
with
a
delay
period
initially
and
then
using
it
to
make
sure
that
the
application
is
responding.
The
couplet
will
run
the
readiness
probes
for
you
before
something
sends
traffic
to
it
before
it's
marked
as
ready
and
put
into
your
load.
Balancer
is
very
necessary
and
I've
marked
here
to
be
very
intentional,
with
timeouts
and
periods.
A
One
of
the
reasons
why
liveness
probes
are
so
dangerous
is
if
your
application
fails,
aliveness
probe
for
whatever
threshold
you
set.
It
kills
your
pod
and
when
your
pod
is
forcefully
terminated
like
that,
if
you
can
imagine
your
application
under
load,
then
you
may
get
some
interesting
behaviors.
It
can
cause
cause
cascading
failures.
The
other
thing
is
that
probe
defaults
are
a
little
bit
destructive
here.
A
A
The
overwhelming
majority
of
them
do,
but
it's
completely
separate
as
far
as
a
concern
is
going,
but
if
it's
no
important
to
us
when
we're
doing
a
zero
downtime
deploy
to
have
this
kind
of
orchestration
of
state
between
networking
and
compute,
it
might
strike
you
as
a
little
bit
weird
to
know
that
there's
really
not
any
synchronization
happening
between
services
and
points
and
pod
lifecycle
for
termination,
and
so
one
of
the
things
that
we
can
do
is
use
an
in-app
integration
or
a
pre.
Stop
like
a
life
cycle
hook.
A
Basically,
you
can
say
to
kubernetes
hey
before
you
actually
send
my
APIs
signal
telling
it
to
politely
shutdown.
Could
you
please
make
it
do
something
first
and
consider
that
as
part
of
the
shutdown
face-
and
you
can
do
things
here
like
sleep,
the
the
thing
to
understand
is
that
when
you're
pre
stop
hook
is
running
with
the
majority
of
network
topologies,
but
think
the
kinds
of
ways
that
we
route
traffic
to
services
in
kubernetes,
your
app
is
likely
still
receiving
connections,
and
those
connections
are
probably
either
by
proxy
or
directly
from
your
users.
A
And
so
this
means
that,
like
during
a
when
a
priest,
stopped
hook
would
run.
That
is
a
critical
point
in
your
business
you're
trying
to
deploy
new
functionality
because
you're
shutting
old
pods
down,
and
then
you
may
not
know,
maybe
you're,
not
at
a
point
where
you
have
a
serve
ability
and
metrics
and
what
kinds
of
response
codes
you're
receiving
you're,
not
tracking
those
things
on
deploy
and
you're,
deploying
15
times
a
day
now,
injecting
this
window
deterministically
into
your
pod
life
cycle,
where
they
are
receiving
connections
and
denying
them.
A
Basically
here's
a
diagram.
We've
got
an
active
pod.
The
service
and
end
points
are
feeding
your
node
routing
and
your
ingress
controller.
The
pot
is
alive
and
happy,
but
then
you
send
the
delete,
asynchronously
or
well.
The
pod
is
marked,
is
terminating
and
then
asynchronously.
The
endpoints
list
gets
updated.
It's
now
removed
from
endpoint
consideration,
but
it
might
take
a
little
bit
before
the
nodes
start,
realizing
that
that
endpoint
is
gone
because
they're
controlling
on
the
API
server
and
then
the
pod
decides
to
shut
down
and
the
ingress
controller.
A
A
When
you
initiate
termination
on
a
pod,
you
need
to
realize
that
you're,
not
you
don't
want
to
stop
receiving
connections,
and
this
is
the
way
that
a
large
majority
of
web
server
frameworks
and
applications
behave.
You
want
to
modify
your
deployments
so
that
it
starts
draining
the
connections
so
and
here's
some
examples
you
whiskey.
A
Basically,
when
you
send
it
a
turn,
a
sig
term,
it
actually
restarts
all
of
its
workers
and
it
it
does
so
in
what
it
calls
brutally
restarting
them
right
so
sig
term
from
kubernetes
restart
everything
and
drop
all
connections,
not
a
great
behavior,
there's
a
way
to
override
that
you
could
check
this
issue
comment.
All
these
slides
are
updated
on
the
talk
and
then
with
Engine
X
I
mentioned
that
you
would
want
to
override
the
stop
signal
in
your
docker
image
to
be
sig
hub.
A
When
receiving
a
signal,
you
can
program
your
app
to
be
this
way,
but
that
does
leak
the
platform
of
abstraction
that
kubernetes
has
in
its
kind
of
dissonance
of
API
synchronization
between
compute
and
networking
into
your
apps
details.
So
you
should
make
sure
that
it's
configurable,
if
you
decide
to
run
it
that
way.
One
issue
here
is
that
you're
saying
oh
well,
lis.
You
want
you're
telling
me
to
run
bin
sleep,
but
I
don't
have
that
in
my
application
container.
A
A
I
got
15
minutes.
Thank
you
all
right!
So
I
have
a
kind
cluster
here.
If
you
don't
know
about
kind,
it's
a
way
to
run
kubernetes
in
docker
and
I
prefer
this
for
both
development
of
kubernetes
and
playing
around
just
like
this.
So
it's
a
little
go
program
and
then
I
am
going
to
show
you
so
I
have
a
repo
that
was
the
repo
that
was
linked
in
the
slide.
It's
stealthy
box
slash
zero
downtime.
A
And
I'm
using
the
k
flag
here,
cube
CTL
supports
customize
inside
of
it
for
reasons
and
I'm
just
going
to
apply
the
kate's
directory.
So
here
we
can
see
that
kubernetes
is
now
inactive
and
deployment
I
have
for
engine
X
pods
running.
You
can
see
that
there's
an
end
points
list
in
the
bottom
right
corner
and
if
traffic
is
working,
I
can
go
ahead
and
start
sending
connections
to
those
four
pods.
It's
getting
load
balance
through
the
traffic
load
balancer
on
my
local
host.
A
So
what
happens
man
then?
If
I
go
in
and
I
just
changed
something
about
the
pods.
Let's
say:
I
want
to
go
to
back
to
version
a
let's
go
ahead
and
do
the
deploy
of
the
Kate's
directory.
And
here
you
can
see
this
is
the
default
behavior
that
kubernetes
does
so.
You
can
see
it's
doing
that
rolling
deployment
in
the
bottom.
A
Now.
If
we
just
like
wait
around
for
a
while
didn't
like
something
spooky,
you
will
happen
whoa
what
just
happened.
Well,
that
was
a
TCP
timeout.
So
the
key
here,
the
connections
timed
out
and
the
clients
were
saying
it
that
happens
in
a
user's
browser.
That's
not
a
good
thing!
You
got
a
check
for
this
stuff.
A
I
am
going
to
patch
in
using
customize
this
custom
probes
patch
right
here.
So
this
has
a
readiness
probe
and
aliveness
probe.
You
can
see
that
I've
commented
that
the
liveness
probe
is
kind
of
dangerous
and
I.
Have
an
initial
delay.
That's
much
more
significant
right!
I!
Don't
really
want
the
liveness
probe
running
a
lot.
I
want
it
to
run
in
a
larger
period
for
sure,
then
the
entire
failure
threshold
of
the
readiness
probe
right
so
three
times
three
is
nine.
A
My
period
seconds
for
the
liveness
probe
is
ten
just
kind
of
some
little
details
there.
These
are
both
just
hitting
the
main
endpoint,
but
ideally
you
would
have
a
liveness
and
reading
this
endpoint
here
you
can
send
headers
I'm
gonna
go
ahead
and
patch
that
in
so
instead
of
just
doing
the
Kate's
directory,
I
will
customize
them.
Let's
get
a
deployment
running,
so
this
is
just
probes.
A
A
Okay,
you
see
the
app
is
now
up
again
right,
but
that
was
obviously
not
a
zero
downtime
deployment.
So
the
final
bit
here
is
in
addition
to
the
probes
patch.
We
have
the
bin
sleep
twenty
seconds.
Pre
stop
life
cycle
hook
right
here.
This
is
production,
ready
right
here,
no
joke
I'm,
not
even
joking
yeah.
That
is
why
I
have
totally
deployed
that
imp
rod
before
you
should
write
a
open
policy
agent
policy
on
this
is
very
important
for
anything.
That's
too
user
facing
well
I.
A
Think
that,
like
the
only
more
complicated
thing
you
could
do
here
is
like
actually
query
the
endpoints
with
like
coops
ETL
or
something,
and
then
you
would
have
to
have
our
back
and
all
that
other
is
really
not
good.
Yeah
write
your
own
API
synchronization,
so
this
is
much
better
and
let's
just
go
ahead
and
make
sure
that
that
is
deployed
I'm,
always
making
sure
that
when
I'm
demoing
this
that
the
pods
are
deployed
beforehand
in
the
same
configuration
because
we're
changing
life
cycle
right,
and
so
we
want
that
shutdown
stuff
to
be
also
applied.
A
A
A
A
So
here
you
see
the
rolling
update
and
going
out
we
got
four
pods
in
terminating
state
they're
running
a
pre
stop
hook,
they're
inside
of
a
sleep
right
now,
they're
sleepy,
very
sleepy
traffic.
Our
ingress
controller
is
noticing
now
the
endpoints
of
a
synchronously
dropped
out
of
the
list.
The
load
balancer
back-end
gets
updated.
Now
that
now
the
pods
are
shutting
down,
they
became
unready.
Engine
X
gracefully
dropped
any
connections
that
it
was
currently
handling
still
running.
That's
good
check
that
out
to
hundreds
across
the
board,
I
didn't
see
any
red
zero
downtime
too.
A
A
Yeah
gotcha
five,
so
this
one
is
a
little
bit
less
of
a
problem
now.
Well,
you
should
audit
your
repos.
A
lot
of
people
are
still
on
my
kubernetes
113
114
in
production
you're
in
a
good
place
if
you're
running
coop
and
like
older
versions
of
kubernetes
still,
that
means
you
got
important
stuff
and
you
don't
know
how
to
upgrade.
That's
good
I
work
with
weave
works.
We
got
get
ups,
we'll
teach
you
how
to
do
that
so
yeah
all
right,
so
a
rolling
update,
there's
this
field
called
max
unavailable.
A
It
controls
basically
how
many
pods
can
be
unavailable
during
a
deployment
right.
So
you
can
speed
things
up
by
increasing
the
number
and
if
you
only
have
a
singleton
right
like
say
you
have
a
stateful
application
that
is
using
some
strange
patterns.
It's
like
from
some
legacy
architecture,
it's
probably
adding
value
to
your
business.
It's
important
that
that
thing
runs
correctly.
A
What
you
can
do
is
if
it's
zero
downtime
end
supports
like
kind
of
swapping
some
some
things
you
either
set
it
to
one
or
zero
and
yeah.
It's
a
bit
difficult
to
explain
like
why
this
is
necessary.
The
default
for
this
change
to
support
this
edge
case
in
apps
v1
beta
one,
but
you
may
be
using
an
older
version
of
an
API
I
know
because
this
bit
me
in
broad
a
year
ago,
so
go
audit.
Your
all
of
your
deployments
in
your
repos
make
sure
you're
using
the
most
up-to-date
apps
be
one.
A
A
You
have
you
understand
that
you
got
this
deployment,
ready
sleep,
pretty
stuff
productions,
workaround
solution
for
the
API
design
and
now
you're,
trying
to
control
how
many
users
are
sending
requests
to
your
apps
as
they
start
to
roll
out,
and
you
can
start
to
change
the
rollout
strategy
with
men,
ready
seconds
progress,
deadlines
seconds
and
the
rolling
update
field
for
max
surge.
So
max
surge.
A
If
you
have
the
capacity
in
your
cluster
and
Airbnb
had
a
story
about
this
two
days
ago,
where
they
make
sure
that
they
watch
the
surge,
because
a
lot
of
developers
like
things
to
happen
super
way
too
fast
and
your
capacity
team
doesn't
have
the
nodes
ready
for
all
of
the
extra
pods
that
your
deployment
wants.
You
may
want
a
very
conservative
surge.
The
defaults
are
very
conservative,
but
people
like
to
crank
that
number
up
you
watch
for
capacity.
A
If
you
have
it,
you
can
speed
it
up,
and
then
you
want
to
make
sure
that
your
application
rolls
out
appropriately
with
regard
to
their
in-memory
caches
or,
if
you're
rolling
your
cache,
then
you
need
to
keep
those
things
warm.
Hopefully
that
makes
sense.
It's
really
more
of
a
data
design,
performance
thing
and
then
the
other
bit
this
one's
a
really
gnarly
gotcha.
It's
a
signal.
Lifecycle
we've
been
talking
about
pods,
as
if
they
only
have
one
container
inside
of
them
and
the
documentation.
A
We
we
have
a
lot
of
work
to
do
in
the
kubernetes
project
in
finding
all
of
the
places
where
we
accidentally
assumed
this.
When
talking
about
pods,
the
lifecycle,
documentation
is
not
super
clear
about
how
signal
handling
and
readiness
like
works
and
we're
constantly
improving
those
if
you're
in
sigdoc.
A
Thank
you
so
much,
but
basically
here's
an
example:
you're
running
cloud
sequel,
proxy
you're
in
a
in
Google
Cloud,
you
have
this
database
proxy
as
a
sidecar
to
your
normal
application.
You
configured
your
application
with
the
pre
stop
hook,
but
the
cloud
sequel
proxy
doesn't
have
a
pre
stop
hook.
So
what
happens?
Is
the
cloud
sequel
proxy
receives
a
sig
term
way
before
your
application
receives
the
sig,
which
means
your
applications
up
its
receiving
requests,
and
it
can't
talk
to
its
database
because
the
pot
already
shut
the
sidecar
down.
A
So
you
got
to
make
sure
right,
I
even
like
to
add
a
little
bit
of
a
buffer
I
like
the
sidecar
to
shut
down
like
way
after
the
application
and
again
I
I'd
say
that
probably
the
easiest
way,
if
you
don't
want
to
write
crazy,
synchronization
logic
with
a
volume
mount
that's
shared
and
then
an
empty
derp.
That's
a
tempo
fest
between
multiple
containers
that
are
messaging
each
other
through
a
file
and
some
random
directory
that
you
configure
in
your
apps
and
the
proxy
is
wrapped
in
a
shell
script
and
anyway,
don't
do
that.
A
Just
you
sleep,
please
right
sleep
sleep
longer
on
the
sidecar,
where
she,
maybe
maybe
maybe
maybe
feature
shipping
a
feature
in
118
to
kind
of
help.
With
this
problem
but
yeah
I
gets
racy
and
there's
that
gotcha
and
we
end
up
with
what
I
call
like
the
seven
rules
of
uptime.
I,
don't
know
a
trademark.
A
So
your
entry
point,
you
got
to
watch
that
your
containers
are
configured
correctly
if
you're,
wrapping
things
and
scripts
pass.
The
signals
to
your
stop
signal
may
need
to
be
changed
and
in
a
way
that
is
unclear
whether
or
not
it's
compatible
with
CRI,
but
it
works.
Trust
me
three,
not
just
different
periods
but
use
a
greater
set
of
periods
and
latencies
and
delays
for
your
liveness
probes.
A
If
you
decide
to
use
liveness
probes,
which
are
very
dangerous
and
make
sure
that
your
readiness
probes
are
appropriately
configured
for
most
important
one,
if
there's
anything
that
anybody
can
take
away
from
this,
make
sure
all
of
your
user
facing
anything
that
you
don't
want
to
ship
of
500
to
another
front
end
unintentionally,
it's
gotta
have
a
pre
stop
hook
and
I
would
recommend
you
just
sleep
in
it.
5
update
to
apps.
If
you
want
on
your
deployments,
it's
got
a
nice
edge
case
thing.
That's
uses
a
percentage
now
for
the
replica
count.
A
A
The
repo
is
up
on
github
feel
free
to
clone
it.
It's
got
a
very
small
number
of
dependencies.
I
encourage
you
to
try
it
out
on
your
laptop,
so
that
you
understand
why
those
lifecycle
patches
are
important
for
all
of
your
user
facing
deployments,
they're
simple,
but
they're
not
default,
and
the
reasons
why
those
simple
patches
need
to
apply
themselves
to
all
of
your
deployments
in
order
to
keep
your
users
safe
and
it'll,
keep
delivering
value
to
your
business
with
a
high
SLA.
A
Those
reasons
are
not
simple:
they're
part
of
a
legacy
of
pragmatic
design
choices
that
separate
concerns
between
compute
and
networking,
and
we've
also
just
learned
a
lot
more
on
how
to
operate
kubernetes
in
a
production-ready
way
that
keeps
everything
working
correctly.
So
my
Twitter
and
my
github
are
here
feel
free
to
reach
out
to
me.
My
DMS
are
open
I'm
on
the
kubernetes
slack
and
I'd
love
to
be
your
friend
me
to
learn
about
you
of
what
you're
doing
Thanks.