►
From YouTube: Extending Deployment for Internet Financial Mission-Critical Scenarios - Mengyi Zhou & Ke Wu
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
Extending Deployment for Internet Financial Mission-Critical Scenarios - Mengyi Zhou & Ke Wu
The default deployment provides a good solution to perform a general version upgrade. However, deploying highly available and reliable services of large-scale as Internet financial applications is a different thing, not to mention the compatibility problems this workload is faced with the existing operation and maintenance systems. The new workload introduced by Ant Financial solves these problems. It extends the ability of Deployment with the commitment of a reliable and flexible distribution, risk controlled deployment strategy, and high-performance in-place update. It removes tech barriers, specifically from financial service industry, enables developers and operators to focus on what truly matters to their businesses.
https://sched.co/Nrlr
A
A
So
how
many
of
you
have
Anna
tried
deployment
anymore,
so
we
still
have
for
people
who
haven't
put
up
their
hands
in
the
two
rounds
of
a
survey
and
I
will
be
very
quickly
in
the
first
part,
and
I
will
save
more
time
for
the
demo.
The
kubernetes
deployment
is
the
replication
controller
and
there
are
two
important
tasks
completed
that
is
at
the
replication
and
the
rolling
updated
as
too
important
has.
Since
then.
A
Kubernetes
are
solving
the
problem
of
availability
and
the
consistency
when
we
move
to
deployment
the
deployment
and
the
repla
replica
set
has
a
structure
of
the
two
layers.
So
we
have
the
capability
of
a
version
control,
so
we
can
do
the
rolling
back
after
the
release.
We
can
return
back
to
the
historical
vision,
so
that
is
the
current
status
of
a
deployment.
A
So
when
we
evaluate
the
deployment
for
the
cloud
native
release,
what
are
their
challenges?
The
first
challenge
is
that
the
deployment
strategy,
as
the
R&D
team
I,
think
you
have
one
thing
in
common.
We
have
the
application,
it
doesn't
mean
our
application
is
available,
especially
during
the
deployment
process.
If
we
want
to
check
whether
it
is
available,
what
we
do
first,
we
will
check
whether
there
is
an
abnormality
from
a
monitoring.
We
will
refer
back
to
the
main
link,
whether
the
major
features
are
normal
and
the.
A
Thirdly,
whether
the
changes
are
effective
after
we
do
this
confirmation
or
verification
we
can
make
sure
the
service
is
available
when
we
use
a
deployment
of
a
rolling
update,
we
didn't
have
the
time
for
verification
and
there
is
a
pass
mechanism
in
deployment,
but
when
we
really
ran
the
pass,
it's
highly
possible,
the
rolling
update
is
continued,
so
we
cannot
have
accurate
the
process
control
during
the
deployment
process,
and
the
second
challenge
is
at
the
pod
scheduling
strategy.
We
found
that
under
one
deployment
that
the
positive
scheduling
strategy
is
the
same.
What
is
the
problem?
A
We
can
have
look
at
this
scenario.
Imagine
we
have
the
aircraft,
the
clusters
are
distributed
in
two
data.
Centers
and
I
want
to
release
four
poles,
and
the
scheduling
strategy
is
exactly
the
same.
So
it's
possible
that
my
four
poles
will
be
scheduled
to
only
one
server
and
surely
is
okay
and
it
will
all
be
routed
to
the
same
server,
but
in
case
of
disaster,
for
example,
there
is
a
road
construction
outside
of
the
server
and
I.
B
A
Is
why
we
say
if
you
want
to
have
a
high
availability?
We
need
to
have
these
backup
in
one
city
or
in
multiple
cities,
and
if
there's
a
disaster
happening
to
our
machine
room
or
the
computer
room,
we
might
not
have
enough
resources
so
whether
my
application
can
be
recovered
in
another
Center.
That
is
a
very
big
question
mark.
So
these
consistent
all
the
same
Carolyn
strategy
to
not
allow
us
to
have
the
tolerance
of
disasters
or
the
catastrophe,
tolerance,
and
the
third
challenge
is
that
the
IP
address
restrictions.
A
We
have
some
users,
they
have
a
very
complete
maintenance
and
operation
system,
but
it
is
a
based
on
the
VM
reads:
deployment
under
VM.
What
are
the
features
of
all
the
deployment,
the
physical
resources,
the
easy,
as
my
IP
will
not
change
with
the
iteration
of
application.
The
application
process
kill
and
start
again
decay.
My
VM
I
keep
maintained
the
same.
So
in
the
classical
scenario
we
take
IP
as
at
a
standard,
and
it
is
a
widely
adopted.
They
monitoring
the
link
analysis,
the
Gateway
and
the
security
wireless.
A
The
strategy
all
have
a
taken
IP
as
the
standard.
If
it
is
related,
relocated
from
the
empty
container
model,
the
IP
addresses
are
still
maintained,
the
same
and
in
the
process
we
found
that
we
can
not
take
a
deployment
to
satisfy
the
needs
of
our
customers,
so
we
have
developed
our
own
CR
and
recorded
a
cafe
deployment.
A
Our
cafe
deployment
supported
the
in
place,
upgrade
emissivity
release
scenarios.
We
can
make
sure
the
pod
and
the
pot
is
a
stable
IP
is
the
same,
and
we
have
considered
the
high
availability
in
the
financial
scenarios
and
a
supposed
active/active
replication
or
multi
active
replication,
and
our
poll
has
the
graceful
shutdown
feature.
A
The
official
kubernetes
also
has
a
niqab
ability
of
a
graceful
shutdown,
but
if
the
concurrency
accumulated
to
a
certain
amount,
the
Porter
cannot
achieve
a
fully
graceful
shutdown
and
the
cafe
deployment
supports
a
safe
and
a
flexible
deployment
strategy
and
there's
a
beta
or
the
rolling
update
in
patches
so
that
they
can
have
accurate
control
over
the
deployment
process
and
they
have
enough
time
of
for
verification.
So
these
are
the
three
features
of
the
cafe
deployment
max.
A
Is
that
the
structure
of
a
cafe
deployment-
and
it
is
the
same
as
a
kubernetes
deployment
in
Hydra
three
layers?
The
middle
air-
is
in
place
that
in
place.
That
is
something
which
it
is
a
replica
set
which
support
in-place
upgrade
and
a
maintenance,
and
the
number
of
reporters
and
cafe
deployment
will
not
have
a
direct
interaction
with
the
port,
and
we
have
in
place
that
it
is
amazing
for
the
in-place
upgrade
either
listed
in
place,
upgrade
configuration
we
can
support.
A
If
the
changes
that
happen
in
these
areas,
we
can
maintain
stable
port
and
IP,
and
the
cafe
deployment
naturally
support
active,
active
replication
or
multi
active
replication
and
in
the
spec
we
have
a
clear
definition
of
the
topology
of
the
application.
On
the
left
side,
you
can
see
the
output
and
the
cluster
has
covered
two
data
centers
in
each
data
center
I
have
denote
when
the
node
is
a
created.
A
wall
labeled
with
the
data
center
under
this
label
helps
during
the
calling
of
the
note
that
it
can
satisfy
the
set
of
requirements
and
industry.
A
According
to
the
topology
in
tasks
in
the
spec,
it
was
created
the
unique
in
place
at
and
in
the
in
place.
That
is
a
unique
to
the
data
center
and
in
place
that
is
responsible
for
the
maintenance
of
the
life
cycle
of
the
pas-de-calais
deployment.
It
takes
that
the
code
view
and
a
decides
in
each
data
center
how
how
many
replicas
I
need
under
the
cafe
deployment
as
the
in-place
upgrade
and
the
photo
tolerance
or
disaster
tolerance.
The
feature
next
I
want
to
introduce
how
tend
to
share
with
you
that
deployment
strategy
of
a
cafe.
A
Next
I
would
like
to
present
the
features
of
a
cafe
deployment.
Number
one
is
the
deployment
strategy.
I
will
give
you
a
simple
example:
there
is
a
cafe
deployment
and
they're
about
two
datacenters
connected
and
we
have
in
place
at
a
and
the
employees
at
B,
and
the
left
bottom
is
part
of
the
specs
of
the
cafe
deployment
and
we
have
a
ten
replicas
by
default
it
they
are
divided
them
equally
to
the
two
data
centers
and
the
employees
at
a
has.
A
fight
pose
and
increase.
A
Fp
also
have
a
fight
pause
and
we
also
have
the
beta
of
upgraded
type
and
that
the
tempest
will
be
divided
into
three
groups.
The
first
is
a
beta
group
and
the
other
two
groups
are
the
standard
patches
and
the
beta
group.
Let
me
explain:
we
take
one
random
part
from
each
data
center
for
a
new
version.
If
the
customers
say
no
problem
that
we
can
move
to
the
standard,
every
our
deployment
and
client
and
need
to
click
and
to
confirm.
A
When
we
first
have
a
cafe
deployment,
the
part
growth
of
our
material,
if
the
deployment
has
a
100
replicas
and
if
we
create
directly
it
is
a
100
parts
and
the
one
part
has
a
problem
with
the
image
and
then
it
will
cause
waste
of
resources.
Because
your
deployment,
affairs
and
the
creation
of
the
pause
is
a
bad
batch.
A
We
will
first
create
the
pass
in
the
beta
group
and
one
in
each
data
center,
and
if
the
customer
confirms
and
no
problem,
then
we
will
have
the
following
patches
and
each
batch.
We
have
a
4-4-2
in
each
data
center
and
one
in
place
that
will
have
a
two
poles
and
then
customer
confirm
and
then
the
last
batch
of
the
four
poles
will
be
created
in
total
temples.
During
the
upgrade
of
a
part,
we
will
follow
the
same
deployment
strategy.
A
Facilitator
group
with
the
customer
confirms
and
no
problem,
and
we
move
to
the
batch
upgrade
and
every
batch
is
a
four-poster
and
confirmed
again,
and
then
we
have
got
a
second
batch
during
the
deployment
process.
Cafe,
diploma
controller
well
not
directly
apply
on
the
part.
The
part
of
creation
and
the
upgrade
is
of
vampire
in
place.
That
controller
and
the
cafe
deployment
controller
is
only
to
abstract
the
strategy
during
the
deployment
process.
A
If
the
part
version
has
a
problem
and
the
customer
can
abort
and
undo
the
upgrade
during
the
deployment
process,
we
might
find
that
in
place
that
a
do
not
have
enough
resources
and
then
maybe
one
port
cannot
be
created.
So
we
have
a
rescheduling
mechanism
and
it
will
be
automatically
rescheduled
to
the
other
in
place
at
some
customers
can
close
the
circle
figuration
if
they
don't
need
it.
A
A
The
scheduling
or
the
schedule
between
different
groups
or
different
centers
can
not
be
realized
and
they
can
also
use
the
interface
and
the
native
work.
Loader
can
be
reinforced
and
we
didn't
change
the
code
of
the
controllers.
So
the
roughly
said
all
stateful
set
can
be
maintained
at
the
previous
data.
A
So
the
customers
can
maintain
the
previous
and
we
will
not
have
any
attractor
any
innovation
to
the
original
code
and
we
have
a
connected
the
replica
set
and
we
will
also
connect
to
stiva
set,
and
this
is
after
connecting
to
the
replica
set,
and
it
is
the
same
as
in
place
that
in
different
center
we
will
have
the
replica
set.
It
is
to
make
sure
the
version
of
the
pod
will
do
the
deployment
we
will
create
new
replica
set
and
the
new
replica
set
will
maintain.
A
The
part
of
the
version
and
the
cafe
deployment
strategy
or
logic
can
also
be
used
as
a
the
replica
set,
and
we
will
create
this
part
and
customer
confirms,
and
then
we
will
move
to
the
second
batch
for
Porter
and
the
customer
confirm
again
and
the
last
batch
of
opposed
will
be
created.
So
when
we
use
in
place
at
afford
appointment,
we
might
encounter
the
challenges.
A
For
example,
the
shutdown
is
not
graceful
and
there
might
be
feather
of
a
request,
because
IP
shutdown
is
the
reverse
inverse
incident
trigger
and
that
part
is
not
ready
and
then
a
was
inform
and
it
will
shut
down.
The
IP
from
the
list
and
Ava
have
impact
on
the
IP
label,
and
then
it
was
shut
down
their
routing
if
the
customers.
A
Can
have
the
right
to
kill
to
the
signals
it
can
realize
that
the
graceful
shutdown,
but
it
is
not
guaranteed
that
you
have
the
degrees
for
shelter
every
time.
So
the
implicit
controller
is
selecting
the
folder
graceful
shutdown.
We
have
a
routing
principle
shut
down
first,
and
then
we
reach
to
the
pardon
for
the
crystal
shadow
and
we
use
the
replicas
gala.
A
If
we
use
a
cluster
a
p2
exposure,
these
parties
in
place
that
controller
can
notice,
realize
whether
these
traffic
or
this
router
is
offline,
and
we
here
have
wait
30
seconds
of
logic.
We
wait
for
3
seconds
and
we
assumed
that
it
was
processed.
They
request
all
the
traffic
in
3
seconds
and
then
we
were
started
the
upgrade.
If
the
upgrade
is
a
successful,
we
will
start
at
the
readiness
Gaeta
and
then
the
router
information
will
be
generated.
Of
course,.
B
Three
seconds
cannot
be
a
full
guarantee
for
all
the
traffic
from
the
oldest
process,
so
a
true
quartz
watch
at
them.
You
need
the
involvement
of
a
load
balancer.
We
have
a
sop
controller
who
will
work
together
with
a
Magneto
and
when
support
will
be
on
the
load,
balancer
SLP,
they
will
have
a
finaliter
on
the
pod
used
to
guarantee
support
will
not
be
revised
or
changed
easily,
but
we're
truly
upwards
approach.
Whoever
takes
the
retinas
gate
as
first
and
then
the
routing
room
will
be
recognized
and
there
will
be
a
true
shutdown
cause.
B
B
B
B
The
current
cap,
a
deployment
configuration
we
will
give
you,
readiness
and
the
stress
feedback
sent
for
that
will
be.
Each
faction
was
before
caught
up
great
the
tide
waits
better
after
you
do
that
we
will
have
a
time
to
wait
and
confirm,
and
over
here
is
a
button
right.
I
will
be
watch
how
they
thought
was
created.
B
B
B
B
B
B
B
B
A
B
B
B
B
Annotation
using
metaphors
that
it's
the
logic
control
of
the
release,
so
it
is
actually
in
traffic
deployment
and
controlled
by
the
committee
for
me,
controller
in
place
that
cafe
deployment
would
watch
this
status
and
once
it
changed
to
waiting
and
then
it
will
be
much
less
that's
to
false
right.
No,
no,
it's
not
important.
Now
you're
kinda
priorities
working,
they
would
use
the
interface.
They
do
not
care
in
the
entry
set
of
replicator
structures.
B
They
would
love
to
see
it's
partition
the
president's
a
little
bit
strange.
It's
a
need
for
beta
release,
there
will
be
too
hot
and
when
these
two
poles
are
ready-
and
they
were
coaches,
it'll
fit
bling
controller
I
also
like
to
say
implicit
itself
would
not
judge
whether
my
cell
is
in
whatever
vision.
They
were
just
reported
to
face,
employ
it.
How
many
of
the
pods
are
ready?
B
How
many
are
not
don't
have
a
deployment
based
on
to
report
of
in
place
that
they
will
make
a
decision
that
is
it
up
from
waiting
or
executing
or
whatever
another
question?
If
it's
a
player
deployment,
will
that
configuration
also
change
from
bottom
to
implicit?
It's
just
like
a
quality
formant,
you
have
the
Apple
deployment
and
they
will
upgrade
to
replace
that
right.
Yes,
yes,
okay!
These
are
the
time
we
cannot
have
QA.