►
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
Front-end Application Deployment Patterns - Ross Kukulinski, Heptio
Kubernetes is a powerful deployment platform that allows complex workflows like rolling, blue-green, and canary deployments of software. Safely managing these complex deployment patterns for frontend browser applications where HTML references multiple CSS, JavaScript, or image assets is fraught with challenges. Doing this poorly results in broken page loads or inconsistent UI behavior. In this session, Ross Kukulinski, will cover: - Common deployment patterns for applications on Kubernetes - How web-applications make these patterns more complex - Solutions and associated live-demos showing how to resolve these problems Attendees will leave this presentation with a variety of strategies to manage blue-green, canary, and A/B deployments of front-end applications using of Kubernetes.
To Learn More: https://sched.co/GrR3
A
There
we
go
so
I'm
a
product
manager
and
product
managers
like
to
create
customer
personas.
These
are
the
fictional
characters
we
use
to
represent
different
people
or
attributes
of
people
they
might
be
using
a
product
or
project.
Now.
Kubernetes
is
infrastructure
software
created
by
infrastructure
engineers
for
infrastructure
engineers,
how
the
project
started
and
looking
across
the
cribben
ideas
ecosystem.
This
is
code,
examples
documentation,
so
much
effort
is
focused
on
the
platform
engineers,
our
back-end
architects
and
like
executive
leadership,.
A
Dozens
of
consulting
engagements
I
found
that
web
developers
are
often
left
to
fend
for
themselves
and
figure
out
how
to
best
deploy
their
applications
to
CRO.
Nettie's
and
kubernetes
is
a
powerful
deployment
platform.
It
allows
complex
workflows
for
shipping
software,
one
of
the
reasons
that
I
love
it
but
safely.
Managing
these
complex
deployment
patterns
for
front-end
applications
can
be
fraught
with
challenges.
A
So,
if
you're
working
with
things
like
HTML,
CSS
and
JavaScript,
if
you
have
streaming
API
to
your
back-end
applications
that
can
get
complex
very
quickly
and
one
of
the
common
issues
that
I've
seen
with
web
developers
when
they're
trying
to
run
their
applications,
is
they'll
start
to
do
a
deployment
and
deployments
running
and
all
of
a
sudden,
they
start
seeing
a
whole
bunch
of
four
or
four
arrows
or
their
get
user.
Reports
saying
that
they're
having
a
bad
experience,
I
want
to
go
click
on
a
button
and
the
button
stopped
working.
A
So
my
goal
today
is
that
when
you
leave
this
presentation,
I'm
hoping
that
you're
equipped
with
a
variety
of
strategies
to
deploy
your
front-end
applications
to
kubernetes.
So
first,
let's
look
at
some
common
criminals
deployment
patterns.
These
are
things
that
are
built
in
or
capable
all
through
the
communities
API.
So
when
you're
looking
to
deploy
the
the
sort
of
for
common
ways
that
I
see
people
deploy,
software
number
one
editing
files
in
production.
This
is
cloud
native.
We're
not
doing
that.
A
So
version
two
needs
to
look
like
version
one,
and
that
means
you
have
to
do
extra
work
for
your
applications,
blue,
green
or
sometimes
notice.
Red
black
allows
you
to
do
an
instantaneous
switch
from
one
version
to
another.
This
minimizes
those
version
compatibility
issues,
but
it
does
require
that
you
have
double
your
compute
resources
to
have
two
versions
of
your
software
running
at
any
given
time.
So
if
you
have
a
very,
very
large-scale
application,
you're
going
to
require
a
whole
lot
of
extra
compute
to
have
two
versions
running.
A
At
the
same
time,
you
can
switch
between
for
more
advanced
users
once
you've
sort
of
master
those
first
two,
you
may
also
look-
and
you
may
have
heard-
of
canary
based
deployments
and
Canaries,
allow
you
to
evaluate
a
new
version
of
your
application
for
a
small
subset
of
your
end-users.
So
rather
than
doing
rolling
deployment
or
blue/green,
you
pick
5%
or
1%
of
your
users
and
you
send
them
to
the
new
version.
When
that
new
version
with
you're.
Looking
at
your
metrics
you're
looking
at
Google
Analytics,
the
data
looks
good.
A
Then
you
can
complete
your
rollout
now,
let's
take
a
look
at
what
these
look
like
in
Trinities.
So
here's
an
example:
rolling
update
I
have
a
cloud
load
balancer
that
is
pointing
to
a
kerbin
any
service.
The
server
is
using
a
label.
Selector
app
equals
my
app,
so
any
ponds
that
have
that
label
app
equals.
My
app
will
receive
traffic
through
this
service.
I
have
one
large
deployment
called
my
app,
and
it's
currently
managing
a
replica
set.
A
replica
set
has
three
pods
you'll
notice
in
red.
A
There's
a
pod
template
hash,
so
replica
sets
and
deployments
as
they
manage.
The
different
versions
apply
a
hash
to
each
replica
set
in
those
pods.
The
blue
part
equals
my
app
tells
me
that
this
service
will
send
traffic
to
all
of
those
pods.
So
when
it
comes
time
to
a
do,
a
deployment
I
can
edit
my
deployment
gamal.
So
I
can
change
my
container
image
or
change
some
other
property
of
that
pod.
A
Template
in
that
deployment,
kubernetes
will
start
a
new
replica
set
you'll
notice
that
it
still
has
a
people's
my
app,
but
the
pod
hash
is
different,
so
I've
got
different
versions
of
my
deployment.
Template
kubernetes
then
scales
up
this
new
replica
set
once
this
new
pod
is
up
and
running
it
takes
down
one,
no
one
and
it
does
brings
up
a
new
one,
raise
that
a
little
one.
A
This
is
a
rolling
to
deployment.
Eventually,
kubernetes
will
remove
that
old
replica
set
great
and
there's
a
couple
of
different
ways.
You
can
change
the
behavior,
so
that's
the
default
kubernetes
role
in
deployment
that
I
just
showed
you.
You
have
some
controls
that
you
can
modify.
So
if
you're,
using
coop
control,
you
can
use
the
coop
control,
explain
command.
To
give
you
information
about
the
deployment
spec
strategy,
rolling
update.
You
also
can
go
find
the
nice
pretty
criminais
stocks,
there's
two
knobs
that
you
can
tune.
The
first
is
max
search
so
max
search
changes.
A
The
it
sets
the
maximum
number
of
pods
that
can
be
scheduled
when
you
are
scaling
up
or
scaling
a
new
version,
so
max
surge.
If
you
have
max
surge
3
in
our
example
before,
instead
of
doing
bringing
up
one
at
a
time
of
the
new
versions,
it'll
bring
up
all
three
of
my
new
replica
set
as
those
pods
become
ready,
then
my
old
ones
will
get
curated.
This
can
be
a
number
of
percentage.
I
often
set
it
to
100%.
A
If
my
applications
are
not
too
large
like
go
ahead
and
burst,
I've
got
capacity,
but
if
you
have
a
large
deployment,
you'll
want
to
set
it
to
a
more
reasonable
number.
The
other
knob
you
can
tune
is
max
unavailable.
So
this
changes
the
maximum
number
of
pods
that
can
be
unavailable
during
the
update
again,
a
number
or
percentage
I
often
set
this
to
something
around
70%,
because
I
usually
have
overhead
spare
capacity.
A
A
A
So
the
browser
connects
the
cloud
load,
balancer
forwards,
the
traffic
to
the
service
and
the
service
in
our
round
robin
fashion
picks
a
pod
to
send
traffic
to
so
it's
gonna.
Get
this
end.
Users
gonna
get
the
contents
from
pod
one
index
that
HTML
from
pod
one
great
here's,
my
index.html
I'm
referencing,
two
external
files,
main
dot,
CSS
and
main
dot
JavaScript.
The
browser
now
needs
to
it
reads
through
the
Dom.
It
recognizes
it
needs
to
download
these
external
assets.
It
goes
back
to
the
cloud
load
balancer,
so
it
gets
the
main
dot.
A
A
This
turns
out
to
be
a
pretty
big
deal,
and
so
this
is
the
common
scenario
that
I
see
over
and
over
again
where
people
are
first
deploying
applications
web-based
applications.
They
do
the
deployment
and,
if
it's
just
them
testing,
they
see
that
problem
sometimes,
but
not
always,
as
you
scale
out,
if
you
have
lots
and
lots
and
lots
of
users
requesting
there's
going
to
be
some
percentage
of
users
that
are
gonna
get
broken.
Pagelet
may
not
be
all
of
them,
but
it
may
be
enough
to
cause
problems.
A
Let's
look
at
the
next
strategy:
blue
green.
So
here
I
have
again
my
cloud
load.
Balancer
I
have
my
service.
My
service
now
has
to
label.
Selectors
first
is
app.
My
app
and
also
version
blue,
so
any
pods
that
have
both
of
those
sets
of
labels
will
then
match.
So
in
this
case,
on
my
left
hand,
side
I
have
my
deployment
blue
at
my
amp
version,
blue.
So
all
traffic
through
the
service
is
going
to
go
flow
to
those
pods.
A
My
green
pods
have
version
green,
so
even
though
they
match
a
people's
myapp,
the
version
Green
does
not
so
they're,
not
gonna
receive
traffic.
So
if
I
want
to
do
a
Bluegreen
deployments,
all
I'm
going
to
be
doing
is
changing
my
service
label.
Selectors
change
the
version
to
green.
Now.
All
traffic
is
instantaneously
switched
over
to
my
green
base
deployment.
Now
inside
of
each
blue
and
green
deployments,
you're
probably
still
doing
a
Trinity's
rolling
deployment
you
don't
have
to,
but
that's
the
default.
A
You
can
pick
and
choose
how
you
want
to
roll
out
those
applications,
but
your
end-users
are
just
experiencing
their
Bluegreen
switch
so
from
a
web
development
perspective.
This
is
great
I'll
request
either
get
version
1
or
version
2,
maybe
there's
a
very
small
percentage
of
people
that
just
happen
to
be
in
the
middle
of
that
switch,
but
because
it's
such
an
insane
eosin
sent
aeneas
switch.
It's
gonna
be
much
much
smaller
than
our
rolling
deployment
which
might
take
minutes
or
hours
depending
on
how
long
your
web
apps
take
to
boot
up.
A
A
So,
let's
look
at
can
a
canary
base
deployment
again
I've
got
my
deployments
table
and
you'll
notice
that
my
service
reference
is
just
at
my
app
when
I
want
to
start
my
canary
based
deployment,
I'm
gonna
have
another
longer
live
deployment.
The
same
app
equals
my
app
label
applied,
so
traffic
from
our
service
is
going
to
go
to
both
sets
of
deployment
pods,
but
you'll
notice
that
the
versions
are
slightly
different.
So
what
this
means
is
that
1/4
of
my
requests
are
going
to
go
to
version
2
and
the
other
3
Foursquare
version
1.
A
So
this
is
good.
If
I'm
wanting
to
do
an
I
want
to
try
out
a
new
version.
Maybe
I've
made
changes
to
my
application
to
add
caching
of
my
CSS
and
JavaScript
contents
inside
my
process.
Instead
of
having
to
go
to
disk
every
time,
I
could
test
this
by
rolling
out
version
to
see
the
performance,
hopefully
I'm,
seeing
less
CPU
or
maybe
less
disk
I/o
or
the
latency
requests
are
going
down
and
if
I'm
happy
with
it,
if
version
2
looks
good,
then
I
can
trigger
a
rolling
deployment
of
my
stable
deployment.
A
Now
the
ratio
here
between
the
amount
of
traffic
that
goes
to
version
1
and
version
2
is
tied
to
the
number
of
pods
that
I
have
running
in
each
category.
So
if
I
want
to
have
10
to
1,
I
have
to
have
9
pods,
with
1
1
9
pods
running
of
the
new
version
in
one
of
the
old
that
I
want
that
type
of
ratio,
and
that's
what
this
looks
like.
A
If
we
go
back
to
our
web
development
world,
this
isn't
good
either
on
a
consistent
basis.
All
of
my
users
are
gonna,
be
getting
some
mix
of
version,
1
version
2
and
you
can
even
stagger
you
can
have
multiple
Canary
versions.
You
can
have
stable
beta
and
alpha.
Now
your
users
are
gonna,
see
all
sorts
of
craziness
when
it
comes
down
time
to
page
loads.
A
So
quick
deployment
recap
rolling
updates.
They
require
fewer
computing
resources.
It's
the
default
for
a
kubernetes
deployment
object,
but
it
does
can
lead
to
broken
page
loads
and
missing
static
assets,
blue/green
near-instantaneous,
which,
which
is
good.
That's
we
want
from
a
web
development
perspective,
but
it
does
require
a
lot
more
compute
resources.
A
Finally,
canary
it's
great
for
validating
changes
but
again
from
a
web
development
perspective
broken
page
loads,
and
we
don't
have
a
whole
lot
of
flexibility
on
how
we
shift
traffic
between
those
two
all
right.
So,
let's
work
through
some
possible
workarounds
how
to
get
around
these
things.
Well,
number
one!
You
can
just
ignore
your
problems
if,
if
your
application
is
not
used
very
often
if
it's
an
internal
app
or
it's
something
that
people
use
on
a
periodic
basis,
you
can
just
roll
it
out,
and
you
know
some
users
have
some
broken
page
loads.
A
Maybe
that's
okay,
look
at
your
business
requirements
and
see
if
this
is
something
you
need
more,
you
can
also
have
scheduled
maintenance
windows.
It's
not
very
cloud
native
of
us.
We
can
do
it.
My
local
bank
does
this
every
Sunday
night
from
6:00
until
10:00
I
can't
make
any
changes
to
my
financial
can
see
how
much
money
I
have,
but
this
is
definitely
an
option.
So
look
at
your
business
requirements
look
to
see
how
much
availability
you
need
to
have.
A
How
many
deployments
do
you
want
to
have
if
you
all
as
a
web
developer
and
like
is
we're
moving
towards
this
cloud
native
world,
we
want
to
be
able
to
deploy
continuously.
We
want
to
make
sure
that
we
can
roll
out
new
versions
as
quickly
as
possible.
That's
both
to
increase
our
product
development
speed,
but
also
it
allows
us
to
make
to
fix
things
quicker.
We
roll
something
out,
that's
wrong.
We
can
fix
it
quickly.
A
We
also
can
leverage
content,
delivery
networks,
so
a
CDN
for
those
of
you
don't
know
we
have
there's
companies
like
a
company
or
all
the
cloud
providers
have
compute
and
network
at
the
edge
near
regional
network
connections,
and
they
basically
can
store
your
static
assets
for
you.
So
we
go
back
to
my
index
at
HTML.
I
can
reference
my
CSS
and
JavaScript,
using
in
this
case
I'm
using
s3
as
a
bucket
store
to
hold
this
what's
nice
about.
This
is
that
my
abuser
is
still
going
to
make
a
request
for
index.html.
A
Their
browser
is
going
to
download
this
and
then
go
to
s3
to
get
the
additional
static
contents.
You
also
note
that
I'm
versioning,
so
my
index
that
HTML
references
the
appropriate
versions
of
my
static
assets
if
I
want
to
roll
out
a
new
version
of
my
software
I'm
gonna
bump
the
version
to
version
3
version,
4,
probably
more
likely
a
better
way
of
doing
that,
instead
of
having
static
versions,
have
it
tied
to
a
get
shop.
A
A
Another
thing
we
can
do
with
kubernetes
services
is:
we
can
leverage
session
affinity
or
sticky
sessions
in
the
service
object.
You
can
add
the
session
affinity
flag,
there's
there's
two
options:
none,
which
means
just
round-robin,
send
it
to
the
next
one
or
client
IP.
But
what
client
IP
is
that
my
end
user
has
this
128
to
my
cloud
load
balancer
has
got
a
10.1.1.1.
A
Just
client
IP
in
this
case
mean
it
actually
means
that
client
that
cloud
load
balancer,
not
my
end
user
and
as
it
turns
out,
not
all
cloud
pilot
load,
balancers
support
passing
through
that
client
IP.
So
there
are
ways
to
do
that.
Google,
for
example,
a
Google
cloud
load.
Balancer
does
work
with
session
affinity
to
pass
through
their
layer,
4
load,
balancers,
yell
B
does
not
so
just
something
to
be
aware
of.
A
We
also
go
leverage,
something
like
HTTP
2,
so
HTTP
1.1
is
usually
the
current
standard.
Http
2
has
been
out
for
a
while
for
many
years
and
all
the
major
browsers
support
this
what's
nice
about
this
is
the
browser
creates
a
single
multiplexed
connection,
so
it
opens
one
TCP
connection
through
that
cloud:
load
balancer
through
the
service
to
a
pod
and
all
additional
requests
for
CSS
HTML
Javascript
images,
everything
flows
through
that
pipe,
which
means
we
don't
have
to
worry
about
the
sticky
session
problem
anymore.
A
B
A
Good
too,
especially
for
mobile
mobile
apps
or
mobile
web
websites,
but
one
thing
to
be
in
mind:
keep
in
mind
is
every
time
you
want
to
deploy
a
new
application.
You're
gonna
have
to
create
a
new
service
and
that
services
can
have
a
cloud
load
balancer
and
it
turns
out
the
load.
Balancers
are
expensive,
especially
if
you
have
lots
and
lots
and
lots
of
applications.
A
A
This
is
layer,
seven
load
balancing,
so
kubernetes
services
operate
at
layer,
4,
layer,
seven
or
HTTP
HTTP
load
balancing
what
ingress
provides.
So
what
does
this
look
like
so
inside
our
criminales
cluster?
We
deploy
this
ingress
controller,
there's
two
pieces.
One
is
the
thing:
that's
doing
the
load
balancing,
so
this
might
be
nginx
rh8
proxy.
The
other
is
the
controller.
What
the
controller
is
doing
is
talking
to
the
criminate
api
server
and
it's
monitoring
all
of
your
services.
A
It's
monitoring
all
of
your
pods
and
endpoints,
and
it's
also
monitoring
the
ingress
objects
that
describe
this
configuration.
So
we
now
can
route
traffic
to
many
services,
all
through
a
single
cloud
load,
balancer
and
there's.
A
lot
of
ingress
controllers
are
just
great,
so
nginx
by
far
I
think
is
the
most
popular
kept.
Eo
contour
is
one
that
we've
built
and
there's
also
traffic.
A
lot
of
the
cloud
providers
have
their
own
there's,
also
ones
for
for
on
Prem
installation
as
well.
A
I
want
talk
quickly
about
hep
to
you
contour,
so
we
built
this
in
partnership
with
Yahoo
Japan
corporation
subsidiary,
ectopy,
o
so
they're.
The
group
that's
responsible
for
the
cloud
native
vacation
of
Yahoo
Japan
contour
uses
envoy
as
the
data
plane.
So
envoy
is
the
load
balancing
service
proxy
that
was
built
by
lift
so
lift
the
ride.
A
Hail,
ride,
hailing
app
all
over
their
traffic
runs
through
envoy
and
the
hep
to
contour
dynamically
updates
envoy
without
dropping
any
connections
which
is,
can
be
a
problem
with
some
controllers,
and
we've
also
done
extensive
performance
testing
to
to
millions
of
concurrent
connections
and
actually
there's
two
other
talks.
This
week
on
contour
and
gimbal,
which
is
its
sister
project.
A
Yahoo
Japan
is
doing
a
talk
on
Thursday
morning
on
their
production
use
cases
of
gimbal
ink
on
and
then
my
coworker
Alex
brand
is
doing
a
talk
on
the
performance
testing
that
we've
done
in
partnership
with
them,
and
that
is
also
on
Thursday
afternoon.
You'll
find
me
there,
but
there
are
some
downsides
of
the
ingress
API.
So
there's
you're
only
allowed
to
have
one
service
per
path,
so
heftier
comm,
slash
blog,
can
only
go
to
one
service.
A
I
can't
have
multiple
service
to
send
traffic
to
I,
can't
do
weight
shifting,
so
I
can't
send
10%
of
traffic
here
and
80%
of
here.
I
can't
do
HTTP
HTTP
redirect
it's
also
really
not
safe
for
multi
team
use
and
there's
some
other
problems,
and
this
is
a
long-standing
issue
in
the
Korean
community.
I
know
that
it
was
discussed
yesterday
and
a
contributor
summit.
It's
talked
about
in
the
sig
network,
which
is
the
group
that
oversees
networking
and
ingress
it
communities
and
we're
trying
to
figure
out
how
to
best
solve
this.
A
In
the
meantime,
what
we
did
with
hefty
o
contour
is
recruited
a
new
custom
resource
definition.
This
allows
us
to
describe
routing
rules
in
a
multi
team
world
and
we're
able
to
provide
some
of
these
native
extensions.
The
complete
Doc's
can
be
found
in
the
contour
repo,
but
I
want
to
quickly
through
talk
through
what
this
yamo
looks
like
so
the
first
piece
is,
we
have
our
API
version,
so
it's
a
custom
resource
contoured
at
Hefner,
comm,
/v,
1,
beta
1,
is
a
beta
API.
We
are
looking
to
roll
this
out
to
stable.
A
Soon
ingress
route
is
the
kind
and,
as
with
all
criminals
objects,
we
have
to
have
a
metadata
dot
name.
We
also
define
the
virtual
host.
So
this
is
the
domain
or
subdomain
that
I'm
gonna
get
except
traffic
for
I'm,
going
to
configure
envoy
to
listen
for
this
traffic
and
then
I'm
gonna
match
based
on
a
path,
so
in
this
case
I'm
just
using
a
forward
slash.
So
that
means
all
requests
with
any
path.
A
It's
going
to
be
sent
to
the
service
called
hefty
a
website
on
port
80,
and
so
this
means
from
a
crewmen
eyes,
deployment
perspective.
If
the
deployment
that
is
backing
this
service
called
hep
Tia
website
does
a
role
in
deployment.
We've
got
a
rolling
deployment.
We
still
have
all
the
same
problems
that
we
talked
about
earlier
for
web
apps,
but
we
get
rolling
deployments
for
free
through
communities.
A
We
also
can
do
blue
green
deploys
at
this
layer.
So
I
can,
instead
of
switching
between
two
different
services
through
a
higher
level.
I
can
do
it
through
the
ingress
API
any
grocer
out
so
here
I
have
my
service
called
hep
Tia
website
green.
If
I
update
that
to
hep
to
our
website,
blue
all
traffic
is
gonna
immediately
switch
over
to
this
other
service.
A
We
also
can
define
multiple
up
streams.
So
if
I
want
to
have
two
versions
of
my
application,
I
can
have
two
terms
in
two
different
services,
but
it
really
gets
interesting
when
we
start
applying
weights.
So
we
can
apply
a
weight
for
hemp,
tea,
a
website
version,
one
where
ninety
percent
of
my
traffic
goes
to
version.
1
10
percent
goes
to
version
2.
You
can
adjust
those
dynamically
and
it's
regardless
of
how
many
pods
you
have
physically
running.
A
So
it
gives
us
much
more
flexibility
on
quickly
shifting
the
amount
of
traffic
between
one
service
or
another
and
within
gross.
We
also
can
do
things
like
version
routes.
So
if
I
configure
my
application
to
serve
traffic
on
version,
1
versus
version,
2
I
configure
my
ingress,
so
any
requests
come
to
static.
/V
one
are
going
to
go
to
my
app
version,
one.
If
I
configure
version
two,
all
traffic
is
going
to
go
there
and
there's
also
ingress
session
affinity.
So
we
still
have
to
worry
about
the
session
affinity
aspect.
A
There's
a
couple
of
different
ways
that
you
can
do
session
if
any
with
layer
7
the
first
is
using
cookies.
So
what
the
load
of
a
proxy
in
this
case
on
Boyd
can
do
or
nginx
is,
every
time
a
request
comes
in
as
it's
going
on
its
way
back
out,
it
injects
a
header
and
that
header
is
then
gonna,
be
reused
by
the
browser
and
that
header
is
going
to
identify
which
location
to
send
that
pod
send
that
traffic
to
which
pod
to
send
to
on
subsequent
requests.
A
Similarly,
this
can
be
done
with
a
header,
and
then
we
also
can
look
at
the
source
IP
hash.
So,
depending
on
how
your
cloud
load
balancer
is
configured
if
you
have
access
to
the
end
client
IP.
This
is
something
else
that
we
can
use
to
shift
that
traffic.
Now
we
don't
support
this
yet
in
ingress
route.
It's
on
the
roadmap.
It's
something
that
I'm
hoping
we're
going
to
have
in
the
first
quarter
of
next
year.
If
you
are
using
the
rest
controller,
they
can
do
this
through
an
annotation.
A
They
have
a
whole
lot
of
annotations
that
do
crazy
things,
but
the
nginx
ingress
that
kerbin
ideas
at
I/o,
slash
affinity
believe
there's
one
option
which
is
cookie
based
routing,
okay,
so
pulling
it
all
together.
So
you
need
to
choose
your
rolling.
Your
strategy
for
getting
the
software
out
rolling
versus
blue
green
versus
canary
rolling
comes
for
free.
You
get
that
with
the
kubernetes
deployment
object,
it's
probably
a
great
way
to
roll
our
software
out
with
the
deployments.
A
Blue
green
is
great
from
a
web
development
perspective,
but
it
does
require
additional
compute
resources,
so
be
thinking
about
how
much
CPU
memory
opportunities
you
need.
How
many
incoming
requests
do
you
have?
Maybe
you
can
schedule
that
rolling
deployment
at
times
or
smaller
windows?
You
can
leverage
HTTP,
2
and/or
session
affinity
to
help
make
sure
that
you
are
end-users
consistently.
Have
a
great
web
experience,
it's
important
to
make
sure
that
you
know
what
your
cloud
providers
support,
read
the
docs
and
unfortunately,
sometimes
you
will
also
have
to
read
the
kubernetes
code.
Sorry
about
that.
A
A
C
We
had
a
canary
deployment
and
we
had
a
discussion
about
what
happens
at
the
end
of
the
appointment
during
the
deployment.
10%
goes
to
canary
92
all
production,
and
then
there
were
two
options:
either
can
IRA
get
0%
and
production
with
the
new
version
gets
all
the
traffic
and
second
option
was
that
split
is
still
there.
The
traffic
is
still
split
into
Canadian
production,
but
both
of
them
would
have
the
option
to
at
the
end.
So
what
is
the
advantages?
Disadvantages
of
the
recommendations?
It's
a
good
question.
A
Probably
depends
on
how
you're
calculating
the
amount
of
workload
you
you
need,
so
the
sort
of
gets
into
the
talk
just
you
know
before
me
about
performance
testing.
So
if
you
know
your
production
workload
is
scaled
based
on
known
constraints,
then
you'll
want
to
make
sure
that
then
you
don't
need
the
canary
alright.
A
So
if
you,
if
you
know
that
you
need
to
have
10
pods
running
in
order
to
handle
all
of
your
potential
workload,
then
at
some
point
the
sum
of
the
two
needs
to
make
sure
you
always
count
the
ten
in
terms
of
ease
of
use.
It's
probably
pretty
similar.
I
I
think
I,
don't
think.
There's
gonna
be
a
huge
impact
between
those
two
things.
Good
question,
other
questions,
yeah
great.
D
D
A
No
sticky
sessions,
but
you
want
to
use
canary
yeah.
My
recommendation
would
be
to
leverage
if
you
can
HTTP
to
will
help
with
a
lot
of
that.
I
had
that
in
here
somewhere,
so
HTTP
2
is
the
something
you'll
your
load
balancer
and
your
ingress
controller
will
need
to
be
configured.
But
basically
what
happens
is
when
the
browser
makes
a
request.
It
opens
up
an
HTTP,
2
connection
and
all
requests
go
through
that
same
connection.
A
A
I
haven't
actually
played
with
spinnaker,
yet
it's
on
my
like
holiday
to
play
with
list
I.
If
someone
else
in
the
audience
so
I
believe
most
of
the
skies
TV
systems
are
focused
on
just
getting
our
software
out
and
not
necessarily
worrying
about
shifting
traffic.
But
maybe
spinnaker
does
make
modifications.
Somehow
do
you
know?
Does
anybody
know
to
spinnaker
make
modification?
It
does.
C
E
A
What
is
it
flaca,
Oh
a
flag
and
then
probably
something
like
flag?
Is
a
project
called
flag
that
maybe
does
that?
I
also
know
that
in
Stannah,
which
is
a
monitoring
company
just
made
an
announcement
with
top
U
and
Yahoo
Japan
that
they're
looking
on
building
on
top
of
contour
and
gimbal
to
add
to
build
things
like
that,
I,
don't
know
any
other
ones
off
the
top
of
my
head
and
I
think
most
the
time
people
are
building
their
own
things.