►
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
Bringing Kubernetes To Bare-Metal With A Focus On Users - Nicolas Trangez, Scality
When the team at Scality looked for options to deploy Kubernetes on-prem, we found no option focusing on ease of operations and local storage provisioning. We released MetalK8s, an “opinionated” K8s distribution with a focus on users: easy long-term, on-prem deployments. The project is open source and in production at customers, used as a foundation to deploy Scality’s products. MetalK8s is based on the Kubespray project to reliably install a base Kubernetes cluster, including all dependencies (like etcd), using Ansible. V1.0 ships with operational tools for monitoring and metering, including Prometheus, Grafana, Elasticsearch and Kibana. Furthermore, an "ingress controller" is deployed by default, based on Nginx. All managed as Helm packages. Unlike hosted Kubernetes solutions, We focus on managing node-local storage and exposing these volumes to containers managed in the cluster.
To learn more: https://sched.co/GrYG
A
Welcome
everyone
to
this
session
about
metal
kubernetes.
My
name
is
iniquitous
male
I
work
as
an
architect
at
skeleton.
For
a
couple
of
years
now,
and
today
we
will
present
a
solution
we
built
partially
in-house
for
some
of
the
needs
we
had
and
I'll
go
into
that
in
a
bit
first
of
all
about
scale
to
the
company.
So
some
of
you
may
know
it
it's
basically
a
storage
company.
So
all
we
do
is
storage
both
objects
as
well
as
file
for
several
purposes,
mostly
in
the
enterprise
and
service
provider
markets.
A
We
have
one
purpose,
which
is
giving
freedom
and
control
to
people
who
create
value
out
of
data.
So
mostly
people
who
have
a
lot
of
data.
We
have
a
global
presence.
We
have
eight
offices
around
the
world.
We
have
lots
of
customers
again,
mainly
enterprises,
which
will
come
back
later
as
well,
globally
and
roughly
200
employees,
our
journey
towards
kubernetes,
I'll,
sketch
a
bit
the
history
of
the
company
and
the
various
products
we
have
and
how
we
ended
up
with
kubernetes
today
or
about
a
year
ago.
A
Actually,
everything
started
with
our
product
called
alt
ring,
which
is
an
on-premise
large-scale,
multiplayer,
byte
storage
solution
for
both
objects,
as
well
as
file
where
the
file
port
is
basically
built.
On
top
of
the
object
storage,
it's
made
for
physical
machines,
it's
storage,
so
you
have
directly
attached
disks.
Some
of
the
components
can
run
in
VMs.
It
really
depends
on
the
the
deployment
architecture
what
we
do
and
we
only
require
an
operating
system
to
be
available
on
those
servers,
including
some
legacy
operating
systems
like
central
6.
A
Nowadays,
this
resource
pools,
as
in
the
number
of
servers
you
have,
is
fairly
static.
You
don't
just
change
this.
You
don't
go
into
your
data
center
to
remove
it
machine
and
add
a
machine
every
single
day,
so
this
is
very
static.
The
roles
of
the
various
servers
is
also
pretty
static.
Once
everything
is
configured,
it
basically
works
and
you
leave
it.
A
The
way
it
is
is
it
being
built
using
RPM
packages
distributed
as
search
installed
as
such
and
deployed
using
a
solution
we
have
built
on
saltstack,
which
is
something
like
an
subbu
I,
don't
know
whether
anyone
in
the
audience
is
familiar
with
it
and
it
is
defector
taking
ownership
of
the
host.
So
when
you
install
this,
you
cannot
just
install
a
second
instance
of
it
on
the
same
system
unless
you
will
be
using
virtual
machines,
but
then
it
comes
where
the
performance
impact,
etc
and
post
installation
everything
is
fairly
static.
A
You
don't
change
your
configuration,
the
role
of
machines,
whatever
else
also
you
don't
just
scale
up
the
number
of
instances
of
sort
of
certain
of
the
services
we
have.
Second
came
so
called
scale
of
ps3
connector,
which
is
a
way
to
access.
This
object.
Storage
using
the
standard,
defector
standards
as
three
protocol
by
Amazon
there's
also
runs
on
physical
servers
or
on
VMs,
because
it's
not
doing
storage
itself.
It's
simpler
to
run
this
on
VMs.
A
But
again,
the
resource
pools
are
fairly
aesthetic
because
even
those
VMs
they
run
on
physical
machines,
it's
sort
of
a
microservices
architecture
and
we
decided
to
build
this
and
distribute
it
has
docker
containers
where
there
is
docker
containers
or
then
put
on
systems
on
servers
using
some
ansible
playbooks
again
there
is
no
runtime
orchestration.
So
if
a
load
goes
up,
no,
we
will
not
spawn
up
more
instances
of
the
various
services
etc
and
things
like
log
management
monitoring,
monitoring
of
the
services.
It
all
comes
with
the
solution.
A
So
if
you
deploy
this-
and
it
will
also
install
something
like
elastic
search
or
whatever
else
to
do
the
log
ingestion
which
basically
puts
the
load
of
providing
these
services
on
the
people
implementing
the
storage
solution,
which
is
kind
of
a
different
skill
set
than
deploying
the
elastic
circuit
or
whatever
else,
then.
Finally,
we
started
building
something
called
Zenko,
which
is
a
multi
cloud
data
controller.
A
It
allows
you
to
move
data
from
one
cloud
bit
on
prem
in
ring
or
in
Azure,
to
AWS
or
to
AWS,
mgcp
or
whatever
else,
and
apply
certain
rules
and
workflows
to
those
those
object.
It
can
be
the
intent
is
for
it,
not
the
intent
it
can
be
deployed
in
the
cloud
or
on-premise,
for
us
is
a
major
paradigm
shift,
because
before
all
we
did
was
in
the
data
center
of
a
customer.
A
So
the
way
we
build
this
was
again
using
containers.
Some
of
these
are
shared
with
the
s3
connector
solution.
In
the
end,
there's
various
similarities
in
Zenko
all
the
object
access
happens
through
the
s3
protocol
for
cloud
deployments
or
cloud
style
deployments.
We
started
by
deploying
on
top
of
docker
swarm,
but
we
ran
into
quite
some
issues
with
the
ability
with
performance
etc.
So
we
decided
there
was
another
way
to
go.
A
No
way
the
right
way
to
go
forward
and
put
this
on
our
customers
premises
so
about
a
year
ago,
I
believe
it
was
December
26.
In
2017,
we
decided
to
move
to
two
kubernetes,
both
using
the
managed
kubernetes
offerings
which
already
existed
back
then
on
Google
and
Ezer,
then
later
on,
Amazon
UK,
even
though
it
was
announced
back
then
became
actually
available
and
on
Prem
for
our
customers,
who
want
to
deploy
the
solution
on
in
their
data
centers.
A
The
benefits
we
wanted
and
did
reap
from
kubernetes
were
primarily
the
homogeneous
deployment
between
in
the
cloud
or
on-premise
kubernetes
becomes
kind
of
the
platform,
the
operating
system.
So
you
want
of
everything
it
can
bring
a
lot
of
services
to
your
final
solution
like
networking
and
network
policies
can
be
applied.
There's
service
start
service,
monitoring,
rolling
upgrades
which
is
built-in
which
otherwise
you
have
to
build
yourself
in
your
ansible,
playbook
or
whatever,
or
whatever
else
which
is
possible.
But
here
the
cluster
just
does
for
you.
A
We,
the
cluster,
can
take
care
of
logs
of
metering
and
monitoring
of
your
services
load,
balancing
TLS
termination.
We
all
know
what
it
brings
and
there's
more
flexible
resource
management.
So
if
there
are
spikes
and
loads,
for
example,
you
can
spawn
up
a
couple
of
more
instances
of
your
various
parts
using
the
HPA
or
you
can
just
add
some
more
VMS
to
to
your
cluster
and
have
more
resources
available.
A
A
So
if
you
want
to
try
your
application
against
s3
without
actually
paying
Amazon,
you
can
just
helm,
install
cloud
server
and
all
of
a
sudden,
you
have
a
fully
functional
s3
implementation
running
in
your
cluster
and
another
one
called
cos
bench,
which
is
a
tool
initially
built
I,
believe
by
Intel,
which
is
used
to
benchmark
various
object
storage
offerings,
including
ours.
So
we
use
this
in
our
CI
to
figure
out
whether
there
are
regressions
and
performance
or
benchmark
ourselves
against
other
offerings
and
then
better
ourselves
on
the
back.
A
Currently,
there
is
no
real
need,
as
in
helm,
can
sustain
everything
we
need,
but
once
we
want
to
be
more
flexible
when
it
comes
to
deploying
and
taking
care
of
the
existing
cluster,
a
good
number
of
nodes
in
the
cluster
and
then
figuring
out
how
many
replicas
of
MongoDB
we
want
or
ii-if
at
some
point
in
time,
upgrades
become
more
orchestrated,
then
having
an
operator
definitely
makes
sense.
This
whole
solution
today,
you
can
try
for
yourself.
It
is
fully
open
source,
not
just
a
chart,
also.
A
Obviously
the
images
and
the
source
code
that
runs
inside
those
images
it's
available
on
get
up
under
the
scale
of
the
organization
called
Zenko.
If
you
don't
want
to
take
the
effort
to
you,
know
clone
days
and
then
set
up
a
cluster
and
install
it
at
cetera,
we
have
hosted
offering
for
testing
purposes
called
orbit,
and
if
you
go
to
that
URL
you
can
simply
create
an
account
using
a
gmail
address
or
whatever
and
then
play
around
with
everything
that
all
the
functionality
that's
available.
A
We
cannot
expect
a
kubernetes
cluster
to
be
available
on
our
customers
premises.
They
may
not
have
one
they
may
and
have
never
heard
of
kubernetes
whatsoever.
So
we
started
looking
into
the
various
offerings
that
existed
back.
Then
there
are
a
couple
of
new
ones
more
recently,
but
things
are
the
way
they
are,
but
most
of
those,
basically
all
of
the
open
ones
which
we
could
find
again
did
not
really
satisfy
our
need,
which
again
given
enterprise
customers
fortune
100
customers
are
rather
specific.
I'll
go
into
some
of
the
details
later
so
back.
A
A
We
call
it
opinionated
because,
unlike
some
of
the
existing
offerings,
we
make
choices
for
the
user
or
customer,
and
we
aim
to
go
for
a
very
for
an
out-of-the-box
experience
which
just
works
rather
and
telling
you
hey.
Do
you
want
to
use
Coleco
or
psyllium
or
this
or
that?
And
do
you
want
to
deploy?
Elasticsearch
or
no
deploy
elasticsearch
and
that
kind
of
stuff,
so
we
make
those
choices
to
have
a
more
of
an
integrative
experience.
It
is
a
long
term
solution.
A
What
I
mean
by
that
is
we
come
just
deploy
cluster,
deploy
an
application
on
it
and
then,
if
we
want
to
upgrade
the
cluster
actually
deploy
a
second
one
and
then
using
ELB
or
whatever
move
over
the
workloads
for
one
instance
to
the
other.
We
only
have,
for
example,
three
servers:
three
physical
machines,
five
physical
machines,
whatever
at
the
customer
side-
that
is
all
we
can
use,
so
it
must
be
possible
to
upgrade
this
solution
over
a
very
long
term.
A
A
So
the
scope
of
this
project
is
roughly
three
to
20
same
machines.
It
may
work
it
likely
works
with
more
machines
as
well
because
in
the
entities
just
stock
up
in
Eddie's,
but
it's
not
something.
We
aim
for
it's
not
something
we
test,
because
it's
out
of
the
scope
for
for
the
product.
As
far
as
we
are
concerned,
it
is
built
on
top
of
the
cube
spray,
ansible
playbook
and
we
use
cube
spray
to
lay
out
a
basic
cluster.
A
So
we
excuse
tray
to
install
a
CD
to
install
the
control
plane
to
install
a
cni
which
in
this
case
is
calico
and
that's
basically
where
it
excuse
me
where
the
role
of
cubes
for
ends,
we
do
add
various
features
like
some
static
and
dynamic
inventory
checks,
pre
checks.
As
an
example,
we
found
out
that
if
you
try
to
install
calico
on
a
server
is
a
cluster,
but
you
use
capitals
in
the
host
names,
then
things
go
really
wrong.
So
we
added
some
pretext
which
validate
that
you
are
not
using
capitals
in
your
host
names.
A
We
do
some
operating
system
tuning
for
performance,
etc.
We
do
operating
system
security
stuff.
We
actually
integrate
it
and
OpenStack
project
for
this,
and
then
we
augment
all
of
this
with
various
services
which
we
think
should
come
with
a
cluster
solution
when
it
comes
to
operations,
an
ingress
controller
of
course,
and
other
services,
and
then
one
of
the
important
things
is
we
take
care
of
local
storage
on
Prem
storage
and
I'll
go
into
that
later
as
well.
A
So
the
cluster
services
we
deploy,
there's
really
no
magic
there.
It's
based
on
existing
open
source
offerings.
Some
of
those
are
really
great.
We
deploy
heap
serve
for
the
dashboard,
Crofts
and
cube
CTL
top
and
whatever
else
we
are
aware
that
heap
sir
is
being
phased
out,
so
that
will
change
metric
server
for
horizontal
policy
scaling.
A
We
are
looking
in
from
each
is
integration,
their
ingress
TLS
termination
using
the
standard,
nginx,
ingress
controller,
cluster
monitoring
through
parameters,
the
parameters
operator
and
everything
that
comes
with
it
being
Q
primitives
and
all
the
dashboards
graphs
and
the
alerts
host
and
container
logs
through
elasticsearch,
including
curator,
to
clean
up
all
in
dishes.
Otherwise,
it
just
keeps
growing
fluently
fluent
bits
and
keep
on
up
as
a
user
interface
and
all
of
this
again
to
give
a
great
out-of-the-box
experience
for
operators
after
deploying
a
cluster.
A
There
is
a
couple
of
screenshots
of
things
everyone
has
seen
before
this
is
Kiba
for
the
elastic
search
logs.
There
is
only
one
example
of
the
graphs
we
get
in
graph
on
out
through
Prometheus
there's
a
whole
load
of
those.
There
are
the
ones
from
queue
Prometheus,
so
very
kubernetes
specific,
but
then
we
also
deploy
others
to
monitor
primitives
itself,
monitor,
HDD,
monitoring
or
elastic
search,
etc.
A
Excuse
me,
I,
had
it
called
a
couple
of
days
ago:
storage,
unlike
kubernetes
cluster,
which
being
deployed
on
the
cloud
environments.
We
cannot
have
something
like
ELP
or
persistent
disks
or
store
or
block
storage
from
Azure
available,
and
also
we
cannot
rely
on
network
attached
storage
to
be
available
because
it
may
simply
not
be
there
at
the
customer
site.
Next
to
that
many
of
the
services
we
deploy
as
part
of
zancor.
A
So
this
is
someone's
anchor
specific,
are
tuned
for
directly
attached
storage,
MongoDB
works
with
a
local
disk
or
can
be
attached
six
discs
as
wellbut
and
those
services
do
an
application,
replication
or
failover
and
recovery
etc.
So
there's
really
no
need
for
us
to
use
network
attached
storage.
We
went
for
what
is
basically
the
lowest
common
denominator
between
all
kinds
of
deployments,
which
is
local
disks,
we're
in
a
cloud.
Okay,
those
are
potentially
not
local,
but
we
treat
them
as
if
they
are
local.
A
We
do
not
use
the
local
volume
provisioner,
but
have
a
more
static
approach
where,
as
part
of
the
playbook,
you
can
specify
in
your
inventory,
which
volumes
you
want
to
be
available,
which
file
system
should
be
on
them.
How
big?
They
should
be,
of
course,
which
file
system
options
which
mount
options
as
well
as
mkfs
option
should
be
used.
We
create
all
these
volumes
in
the
various
LVM
physical
volumes
and
volume
group
you
defined,
and
then
we
create
the
PV
objects
in
the
kubernetes
cluster.
A
We
are
looking
forward
to
CSI
based
dynamic
volume,
provisioning
using
LVM,
but
currently
that's
not
done
yet
and
then
at
a
later
point
in
time.
Who
knows,
we
may
get
volume,
encryption
etc
the
deployment
this
is
really
based
on.
On
years
of
experience,
we
have
with
deploying
ring
at
customer
site
in
various
architectures
various
environments,
the
constraints
we
have
customer
data
centers
are
somewhat
different
and
you
know
running
a
couple
of
years
on
you
see.
A
A
We
would
be
very
willing
to
accept
any
PRS
which
add
kubernetes.
Sorry,
you
went
to
support
or
whatever
else,
but
it
will
not
be
part
of
the
testing
efforts.
We
do
we
and
we
worked
a
bit
on
ease
of
deployment
to
make
it
like
really
easy
to
set
up
a
cluster.
All
you
have
to
do
is
create
an
inventory
file
which
can
be
like
two
files
of
five
lines.
A
Each
we
added
a
make
target
which
will
create
a
Python
virtual
amp,
which
has
everything
you
need
pre-installed
at
specific
versions
we
have
tested,
which
includes
ansible,
all
the
ansible
dependencies,
the
cube
spray
or
our
playbook
specific
dependencies.
You
have
to
add
as
well,
then
you
just
run
the
PlayBook.
A
That's
it
some
non-technical
things
we
added
as
well
is
we
spent
quite
some
work
or
are
still
spending
quite
work
with
our
technical
publications
team
documentation,
so
installation
guide
operations
guide
reference
guide,
the
lot
all
of
that
is
available
on
read
the
docs
and
the
link
is
in
there
as
well,
and
we
spend
a
lot
of
effort
on
testing
up,
create
the
installation
testing.
Of
course,
a
great
testing
testing,
whether
the
services
which
we
deploy
are
actually
properly
deployed
and
work.
What
happens
when
there's
failures
in
the
in
the
network
layer
in
the
storage
layer?
A
Not
that
long
ago
we
considered
the
future
of
metal
kubernetes,
and
we
decided
to
so
much
shift
its
focus
where
today,
it's
a
general
purpose
deployment
tool
for
a
kubernetes
cluster.
Where
then
some
extras
being
deployed
as
well,
where
that
cluster
is
a
prerequisite
of
a
product
or
an
application,
you
want
to
deploy.
A
Excuse
me
in
the
future.
We
are
thinking
of
targeting
it
more
as
something
you
can
embed
in
your
solution
as
a
vendor,
where
your
solution
is
supposed
to
be
installed
on
Prem
at
econo
cost
at
a
customer
premise
and
happens
to
be
developed
using
kubernetes
or
using
container
native
architectures
and
can
be
deployed
on
kubernetes.
Now.
The
reasons
why
we
decided
to
roll
around
are
still
present.
A
They
want
black
box
solutions
so
again
their
white
box,
where
a
customer
has
actually
access
to
the
cluster
and
sees
it
as
our
first
deploy
a
cluster.
And
then
your
application
put
some
constraints
again
as
well.
In
the
future.
We
think
metal
will
no
longer.
It's
not
meant
to
be
a
multi
purpose,
shared
cluster,
but
rather
something
on
which
you
as
a
vendor
you
as
a
vendor,
deployed
as
part
of
your
bigger
installer.
You
deploy
your
application
on
it.
Maybe
you
could
run
multiple
instances
for
you
of
your
application
on
it.
A
A
A
We
did
consider
to
remove
cube
spray
because
it's
a
bit
too
big
for
our
usage
now
earlier
today,
I
was
in
the
session
by
the
cube
spray
maintainer,
and
this
may
change
again
because
it
turns
out
that
their
vision
for
that
projects
is
very
much
aligned
with
ours.
So
there's
lots
of
room
for
collaboration
there.
A
We
are
looking
at
like
netboot
integration
of
various
other
CN
CF
services
like
Jager
or
SiO,
but
all
of
those
optionally
and
depending
on
what
your
solution,
which
you
want
to
build
on
top
of
this
or
where
you
want
to
integrate
this
into,
requires
there's
a
lot
of
work.
We
can
do
on
the
security
front,
be
it
with
the
update
framework,
naturally
OPA
as
demoed
this
morning.
During
the
keynote,
then
there's
things
like
color
containers,
firecracker
cube
fur
that
are
coming
up.
A
They
can
be
useful
to
integrate
as
well,
but
most
of
those
should
be
optional
for
it
as
an
example,
we
could
opt
to
integrate
something
like
keep
alive
D
to
do
high
viability
and
failover
of
various
services.
Now,
if
a
customer
already
has
an
f5
or
whatever
load
balancer
of
abled
and
there's
no
need
to
put
it
in
here
as
well,
we
do
believe
there
is
a
quite
some
room
for
a
project
like
this
in
the
community.
A
A
Right
now,
we
are
not
because
in
the
deployments
we
have
they're,
mostly
like
five
servers,
where
we
don't
need
BGP,
we
just
have
a
mesh
for
the
ingress.
We
deploy
it
on
all
the
nodes
which
are
tagged
as
being
a
cube
node
and
there
we
use
a
host
port
to
expose
80
and
443
on
those
specific
service
servers,
and
then
it's
up
to
our
DNS
or
have
your
application
talk
to
those
IDs.
A
Yes,
we
actually
use
the
ingress
for
NFS
and
that
works
by
basically
setting
it
up
correctly
in
your
ansible
inventory.
So
all
the
services
which
we
deploy
as
a
help
chart
you
have
the
ability
into
in
your
inventory,
put
some
general
snippets
and
those
then
become
helm
values.
They
are
then
used
to
deploy
the
chart
and,
as
an
example,
the
nginx
ingress
controller
allows
you
to
in
the
chart
setup
open
up
other
ports
and
then
set
them
up
towards
the
right
services.
Oh.
B
A
B
C
A
Totally
understand
if
you're
looking
for
a
solution-
maybe
that's
the
one
I
should
look
it
up.
We
have
the
do
due
diligence
of
various
solutions,
including
ranch
or
I.
Remember
a
year
ago,
I
have
a
spreadsheet
somewhere
in
my
Google
Drive,
but
I
can't
remember
hard,
and
even
that
information
will
most
likely
not
be
accurate
today,
because
rancher
has
moved
on
as
well.
Sorry.
B
A
D
A
E
E
E
It
to
make
which
did
you
guys
have
a
chance
to
try
deploying
a
special
BCI
like
vga
nvidia
GPU,
to
be
consumed
by
capabilities
in
parameter
environment.
Sorry,
I
didn't
get
example.
If
you
have
some
board
or
service
deployed
experience
that
need
a
NVIDIA
GPU
to
do
some
kind
of
machine
learning
or
data.
So
do
you
guys
have
a
chance
to
try
that
to
be
deployed
in
we.
A
D
A
Now
no,
but
we
have
a
project
on
get
up
tracking.
All
of
this.
It's
basically
integrating
already
see
where
the
investigating
birds
Dex
as
well
as
I,
forgot
the
name
of
the
other
project
because
some
of
our
customers,
they
don't
necessarily
have
an
OID
C
endpoint.
They
may
have
an
LDAP
server.
So,
yes,
we
have
to
improve
the
the
story.
We
have
around
authentication
and
authorization,
but
today,
yes,
you
could
set
up.
The
OID
see
end
points
as
far
as
cube
space
supports
them.
That
will
work,
but
it
doesn't
necessarily
satisfy
our
needs.
So.
A
F
You
mentioned
that
you
were
running
in
public
clouds.
You
were
running
things
like
eks
and
standard
public
cloud
services
for
kubernetes.
Are
you
finding
any
challenges,
managing
metal,
Cades
and
those
public
cloud
kubernetes
offerings
together
as
one
offering
to
a
customer
in
a
hybrid
scenario
or
I?
Guess
I'm,
trying
to
figure
out
why
you
would
choose
multiple
cluster
deployment
mechanisms?
If
you
could
choose
one
and
whirl
your
own
and
run
it
everywhere,.
A
A
Why
not
always
deploying
metal,
even
if
you
want
it
in
the
cloud
and
then
use
ec2
or
whatever
to
deploy
a
metal
on
top
of
it?
Honestly,
that's
a
very
good
question.
I
think
part
of
it
will
be
related
to
operations.
We're
operating
metal
is
more
complicated
than
operating
any
KS.
Cluster
I
would
assume
at
least
I
never
used
a
guess
myself,
and
there
may
be
your
pricing
or
total
cost
of
the
solution
involved
as
well.
G
A
Now,
I'll
be
very
honest
if
you
were
upgraded
from
version
1.0
to
1.2,
which
is
in
a
branch,
it's
not
released
one
or
two,
but
assume
you
take
that
branch
you
will
or
you
may
have
a
bit
of
downtime
for
some
services.
We
are
working
on
a
solution
to
enhance
that
and
not
have
any
downtime
as
observable
from
the
end
user
of
your
application.
Of
course,
pods
will
restart,
etc,
but
there
should
be
no
downtime
if
you
use
the
application
running
on
top
of
metal.