►
From YouTube: In-place Upgrade Noway! Blue/Green Your Way to a New Kubernetes Version - Ricardo Aravena, Rakuten
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
In-place Upgrade Noway! Blue/Green Your Way to a New Kubernetes Version - Ricardo Aravena, Rakuten
Since its introduction, Kubernetes has had a relentless pace of innovation and a significant release every three months. For an organization, it may be challenging to keep pace with new features and their Kubernetes clusters up to date. Furthermore, the constant change of the Kubernetes API + CRDs may be a barrier to minimizing downtime. This session will showcase using different tools with automation to update the major version of your cluster using a blue/green approach. Can we take advantage of a GitOps approach using open-source tools like Flux and Keiko? How do we change manifests to support the new API? How can we verify and add more security to the upgrades? The audience will come away with a pragmatic understanding of how to make use of different open-source tools and processes to make Kubernetes upgrades seamless with minimal to no downtime in production.
https://sched.co/Zek9
A
Thank
you
for
attending
this
session.
I'm
very
excited
to
be
here
at
kubecon
cloudnativecon,
virtually
and
today,
I'm
going
to
tell
you
about
a
different
approach
to
upgrade
your
kubernetes
clusters.
Maybe
it's
different.
Maybe
it's
new,
a
blue
and
green
approach,
as
opposed
to
having
an
in-place
upgrade.
A
A
A
A
As
far
as
these
upgrades
are
concerned,
and
finally
I'll
provide
some
takeaways,
so
the
kubernetes
control
plane.
So
typically,
you
have
either
a
three
main
node
setup
or
a
five
main
node
setup.
I
change
the
terminology
here
from
main
or
from
master
domain,
so
in
every
main
node
you
have
all
these
different
components.
You
have
an
api
server.
You
have
a
scheduler,
you
have
the
cloud
controller,
controller
manager,
so
several
different
components.
A
Now,
when
you
have
a
kubernetes
version,
let's
say
you
have
117:
all
of
these
components
typically
have
that
same
version:
api
servers,
117
schedule,
schedulers,
117
and
so
forth.
So
that's
a
recommended
way
of
running
kubernetes.
It
doesn't
mean
everybody.
Does
it
that
way,
but
that's
what
you
typically
have.
A
Similarly,
the
data
plane
also
has
its
components
with
its
own
unique
versions.
So
the
data
plane
consists
of
your
kubernetes
nodes
in
each
node.
You
have
your
cube,
led
you
have
a
cube
proxy.
You
may
have
other
components
like
your
container
runtime
or
some
other
specific
things,
and
if
you
have
a
version
there,
kubernetes
version
117.
A
A
A
A
So
the
the
problems
are
related
to
several
things.
You
have
different
kubernetes
api
versions
that
change
between
different
major
kubernetes
or
versions.
So
you
have
the
alpha,
then
you
have
beta
and
finally,
once
a
release
where
a
resource
is
promoted,
it
becomes
stable.
So
it
goes
from
b1
beta
1
to
b1,
for
example,.
A
Then
the
cycle
goes
like
this:
you
have
an
api
group,
it
goes
from
b1
alpha
1
and
then
it
keeps
upgrading
until
d1,
alpha
2
and
alpha
n,
and
then,
when
the
community
decides
that
it's
beta-like,
then
it
gets
promoted
to
beta
and
that
becomes
beta1
until
beta
n.
And
finally,
when
the
community
decides
that
it's
stable,
it
decides
to
promote
it
to
v1,
and
then
the
cycle
continues
for
v2,
so
v2,
alpha,
1
and
v2,
beta
and
so
forth.
A
So
another
problem
here
describing
the
release
notes
for
kubernetes
117.,
so
you
have
the
r
back
v1
alpha,
1
and
b1
beta1
are
deprecated
and
they
will
be
completely
removed
in
120,
so
in
favor
of
v1.
So
that
means,
if
you
have
api
definitions,
resources
are
back
resources
with
d1
beta
1
of
v1
alpha
1.
A
A
A
So
you
have
maybe
kubernetes
api
117
and
it
also
supports
certain
versions
cues,
so
the
cubelet,
116
and
117
will
be
able
to
connect
to
117.
with
no
problems
or
the
way
it's
supported.
But
if
you
have
something
like
a
cube
like
114
or
115,
you'll
also
have
these
problems,
so
you
mean
it's
more
on
unpredictability.
A
So
that's
why
it's
recommended
to
have
these
versions
all
together,
but
some
people
decide
not
to
do
it.
But
if
you
do,
you
have
to
be
careful
of
watching
for
these
versions
cues.
Similarly,
with
cube
ctl,
if
you
have
an
older
version,
say
you're
running
kubernetes
117,
but
your
cube.
Ctl
is
115
and
maybe
you're
using
cube
ctl
in
your
ci
cd
system
to
do
tasks
to
do
deployments
and
then
maybe
things
will
not
work
because
there's
it
it's
not
compatible
right.
A
A
A
So
the
leader
is
still
there.
So
potentially
you
can
still
make
decisions.
If
you
have
a
four
or
five
node
kubernetes
control
plane,
then
you
start
with
the
nodes
that
are
not
deleted.
You
identify
which
one
the
leader
is,
and
then
you
upgrade
that
leader,
but
when
you
upgrade
that
leader,
these
components
have
to
be
restarted.
A
A
So
when
this
happens
and
you're
doing
the
upgrade,
you
have
workloads
running
and
maybe
things
being
scheduled,
so
you
might
run
into
something
like
this,
so
you
have
crash
loop
back
off
in
some
pots
you
have
some
containers
or
pots
running
in
pending
state.
Some
of
them
run
in
with
no
problems,
but
then
some
things
are
not
going
to
work.
The
way
you
want
to
so
another
solution
having
blue
and
green
clusters.
A
So
in
this
reply,
kelsey
hightower
last
year
said
that
for
this
type
of
issues,
when
you
upgrade
it's
better
to
have
more
than
just
one
production
cluster
than
your
actual,
only
cluster
so
solution
is
to
have
a
blue
and
green
cluster
ability
to
switch
between
different
clusters.
But
you
can
also
do
use
that
for
kubernetes
upgrades.
A
A
A
A
A
and
then,
when
you're
done,
you
also
get
rid
of
the
117
nodes
and
you're
done,
and
maybe
you
can
start
up
a
new
kubernetes
cluster.
If
119
is
out
there,
you
can
start
a
new
one
to
be
ready
and
to
for
the
next
upgrade.
Of
course
you
need
to
keep
up
to
date
with
the
different
patches
of
that
119
version.
A
So
you
have
federation
and
then
using
these
tools
to
help
you
out
migrate,
some
of
the
workloads
and
do
the
switch
over
also
link
rd
has
cluster
mirroring.
That
allows
you
to
have
a
kubernetes
cluster
service
on
one
region
and
then
make
it
think
that
that
service
is
local
when
it
actually
is
in
a
remote
place.
A
So
you
have
cluster
in
new
york
and
has
a
service
there,
but
the
service
actually
maybe
lives
in
us
in
a
cluster
in
chicago
and
obviously
trust
for
api
widely
used
project
from
the
kubernetes
community.
That
allows
you
to
manage
kubernetes
clusters
using
a
kubernetes
cluster.
So
you
can
manage
your
whole
fleet
using
kubernetes
itself.
A
A
Flux
is
another
tool
that
allows
you
to
have
this
kind
of
getups
approach
for
applications,
but
you
can
also
use
it
for
kubernetes
components,
and
so
you
can
use
it
for
your
cluster,
auto
scaler,
your
core
dns,
your
network
overlay.
If
you
want
to
keep
up
to
date
and
maybe
there's
a
feature
or
maybe
you're,
watching
a
container
registry,
and
then
you
want
this
to
get
updated
automatically,
you
can
use
something
like
flux.
A
A
A
It's
still
a
project
in
the
works,
so
you
can
do
your
state
and
kubernetes
cluster
state
in
a
yaml
file
and
it
supports
multiple
kubernetes
versions.
So
cluster
versions,
for
example,
supports
fire
cube,
which
is
running
kubernetes
in
firecracker
vms
vagrant,
running
kubernetes,
locally
footloose,
allowing
allowing
you
to
run
kubernetes
in
containers.
A
A
A
A
You
can
do
that
orchestration
of
upgrades
using
the
add-on
manager
upgrade
manager,
in
instance,
manager.
So
all
these
different
components
to
help
you
out
other
tools
that
are
really
popular
to
manage
kubernetes
clusters
or
cops
written
in
golang
has
been
around
for
a
while.
Has
a
very
large
community
supports
multiple
clouds.
A
A
A
A
So
you
can
tell
when
you
want
to
change
your
resources
or
how
how
far
ahead
you
want
to
change
your
resources,
prevents
you
from
saying,
like
you're,
moving
from
115
to
116,
say
if
you
have
an
api
definition
for
deployment
that
says
d1
beta
1
and
then
you
upgrade
then
that
resource
may
not
work
because
the
replacement
is
apps
v1.
So
so
the
deployments
may
not
work.
A
A
This
is
where
you
want
to
get
to
and
when
what
you
want
to
strive
for,
so
you
want
to
have
the
full
automation
of
your
control
plane
provision,
all
your
notes,
all
your
main
nodes
with
all
the
different
components,
your
data
plane,
you,
your
worker
groups,
ahead
of
time,
fully
automated
verifying
them,
then
also
your
add-ons,
your
cluster,
auto
scaler,
your
networking
add-ons
all
these
different
things
you
want
to
have
them
fully.
Automated,
maybe
have
the
blue
and
green
switch
over.
A
A
A
A
So
we
talked
about
automatic
automatically,
switching
over
your
dns
provider
when
you're
running
a
website,
type
of
application
or
web
services,
so
tools
that
allow
you
to
talk
to
these
dns
providers,
maybe
talk
to
the
load
balancers
and
then
do
that
switch
over
tools
that
help
you
do
stay
full
application
switch
over.
You
know
we
talked
about
the
data,
you
know,
maybe
tools
that
will
back
up
your
data
automatically
make
sure
that
data
is
correct.
A
A
Also,
maybe,
tools
that
fill
in
monitoring
for
these
upgrades.
You
know
making
sure
you,
you,
hitting
your
200
status
codes
on
your
http
services,
also
making
sure
that
your
security
policies
are
correct.
You
know,
like
your
network
policies,
are
not
allowing
certain
ip
addresses
or
certain
parts
can
talk
to
each
other,
and
some
of
them
cannot.
So
all
those
type
of
things
so
fill
in
those
gaps
so
from
the
cloud
providers
we'll
also
see
baby
board
tools.
In
this
example,
we
see
eks
on
the
roadmap.
A
Of
course,
you
still
want
to
test
it
and
want
to
make
sure
that
everything
is
okay,
but
then
that's
where
the
direction
is
going
with
some
of
these
cloud
providers
so
more
ways
to
manage
those
two
like
if
you
want
to
you
know,
upgrade
a
patch
on
your
node.
That
type
of
thing
you
know
of
the
tools
will
make
it
easier.