►
Description
Powering Public Infrastructure with Kubernetes [B] - Jan Willies, Accenture
Deutsche Bahn Station & Service has a network of thousands of railway stations in Germany, and each has up to dozens of displays to help traveler information. Managing and distributing information to each one has historically grown into a complex process. In this talk we will dive into how Deutsche Bahn overcomes these obstacles with a modern CI-CD pipeline on top of Kubernetes and their use of containers in production.
About Jan Willies
Jan Willies has a background of linux and opensource software where he likes to tinker with embedded systems. Currently he is leading the Kubernetes practice at Accenture.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Okay,
hello:
everybody
welcome
to
welcome
to
kuchen
welcome
to
powering
public
infrastructure
with
kubernetes.
It's
my
voice
level.
Good!
Actually,
can
everybody
understand
me,
okay,
perfect,
so
I'll
be
talking
today
about
powering
public
infrastructure
with
kubernetes
and
will
will
have
a
smaller
agenda.
First
I'll
do
a
project
introduction,
so
what
what
we
are
doing
exactly
for
a
from
a
business
point
of
view
with
kubernetes?
A
So
I'm
a
Technical
Architect
working
for
extension,
I'm
working
in
the
containers
platform
groups
and
my
work
is
mostly
focused
around
kubernetes,
so
everything
containers
and
container
orchestration
and
in
terms
of
kubernetes
is
where
I,
where
my
work
is
done:
I'm
based
in
Berlin,
so
I'll
actually
could
cycle
here.
This
was
interesting
experience
and
so
for
this
talk,
I
made
a
couple
of
assumptions,
so
everybody
who's
here
I
think
falls
more
or
less
hopefully,
in
this
categories.
I
think
everybody
here
should
have
a
basic
understanding
of
kubernetes
and
have
heard
of
containers
already.
A
The
next
thing
you
you
might
be
here
is
because
you're
interested
in
implementations
of
emerging
technologies
in
enterprises,
because
kubernetes
is
still
majoring
platform
and
delivering
project
with
kubernetes
might
be,
might
be
of
interest
to
some
of
you
or
you're.
Just
plainly
interested
in
what
doe,
Chubin
or
german
rail
is
doing,
because
and
in
germany,
public
transport
is
actually
quite
important.
So
there
are
many
people
who
are
just
interested
in
what
German
rail
is
doing.
A
So
what's
this
about
Deutsche
Bahn
consists
of
several
divisions.
So
in
this
talk,
I'll
focus
on
one
we're
at
station
and
service.
It's
called
and
basically
what
station
and
service
does
is
they
they
manage
the
stations
in
Germany,
so
every
station
there
are
about
5,000
over
5,000
s
in
Germany
they
are
managed
by
station
and
service
and
that's
mostly
real
estate,
but
also
the
operations
of
the
stations
itself.
The
escalators,
the
elevators,
the
information
flow
to
these
stations
from
the
stations
and.
A
A
It
roughly
translates
in
English
to
the
train
is
approaching,
and
this
leads
us
to
the
question:
when
is
the
train
approaching,
usually
or
especially
in
Germany,
when
the
Train
is
not
on
time?
This
might
be
a
major
incident
for
you,
because
your
your
routines
right,
you
want
to
go
somewhere
and
we
add
station
in
service.
We
are
concerned
about
how
this
information
reaches
you.
So
how
can
you
consume
this
information?
A
When
do
you
consume
it,
and
also
where
so,
a1
consumption
point
is
the
the
display
here,
which
is
on
every
station
on
every
platform
in
Germany,
and
this
is
the
visual
consumption,
so
we
have
also
audio
and
one
or
two
other
ways
to
consume
information,
and
actually
this
is
called.
This
system
consists
of
of
quite
a
lot
so
to
deliver
you
this
simple
information.
A
A
A
So
what
exactly
are
we
doing
with
kubernetes?
How
does
kubernetes
come
into
play
here?
Well,
somebody
has
to
deliver
the
information
and
process
the
information,
so
our
our
system
is
basically
running
on
top
of
kubernetes
delivering
this
processing.
This
information,
this
scheduling
information
when
your
train
arrives
and
when
you're
playing
when
your
train,
maybe
is
late
or
it
comes
in
in
the
wrong
direction.
A
So
what
you
might
expect
from
emerging
platform
like
kubernetes,
is
powering
well
new
technology
right,
the
the
the
better
stuff,
something
really
exciting,
and
actually
we
we
kind
of
have
very,
very
much
legacy
systems.
We
need
to
power.
We
need
to
deliver
this
information
so,
for
example,
one
or
actually
two
you
see
on
this
picture.
We
have
the
the
displays
of
several
generations,
and
this
is
actually.
A
A
On
top
of
this
displays-
and
they
were
quite
some
challenges,
because
historically
there
were
many
vendors
involved
over
the
last
couple
of
15
years,
maybe
and
always
process
of
talking
to
the
venules
of
doing
the
API
contract
between
the
the
platform
and
the
and
the
actual
system
running
all
these
well
difficulties
talking
to
different
vendors.
This
was
kind
of
a
challenging
situation
and
also
the
back
end
was
kind
of
historically
grown.
A
So
there
were
many
systems
while
doing
doing
more
or
less
the
same,
but
each
one
has
its
its
its
benefits
and
the
new
well,
the
new
system
will
basically
unite
all
the
other
systems,
succeed
all
the
other
systems,
and
it
will
also
be
directly
involved
with
the
free
hardware,
because
we
deliver
now
this
software
to
run
on
these
displays.
So
we've
actually
with
a
nice
package.
We
have
also
also
the
client
on
our
side,
and
we
can.
A
A
So
how
does
this
fit
with
with
kubernetes
when
we
started
the
project
about
almost
two
years
ago,
the
container
landscape
was
was
quite
new.
In
fact,
many
of
these
systems
are
where
non-existence
two
years
ago,
and
this
this
this
list
is
not
exhaustive,
so
don't
take
it
for
as
a
Bible
here,
but
these
are
kind
of
some
some
technologies
we
looked
into
and
I
want
to
focus
here.
Well,
funnily
enough,
all
the
speakers
in
prior
to
to
the
queue
con.
A
A
So
obviously
kubernetes-
that's
not
so
not
such
a
surprise,
because
I'm
here
obviously
docker,
because
it's
the
simply
the
most
loyal
test
at
runtime
for
containers
it
well.
It
was
back
then
and
I
think
it's
still
quite
now
it
it
has
his
bugs,
but
all
the
all,
the
other
implementations
which
were
out
there
were
kind
of
even
more
in
nature,
and
you
had
to
do
even
more
yourself.
A
So
we
just
we
just
went
with
docker
and
the
the
story
of
the
upper
layers,
for
example
with
the
the
infrastructure
on
the
bottom
and
the
multi
workflow
approach
on
on
top
and
the
story
for
the
workflow.
It
was
actually
was
a
bit
blurry
for
us
back
then,
because
we
we
didn't
know
there
was
no
experience
delivering
containers
as
as
as
an
on
Google
and
Enterprise
I
would
say,
or
non
AWS
enterprise.
So
I
refer
to
these
consumer
containers
as
as
kubernetes,
and
there
was
no
clear
story
to
manage
containers.
A
Well,
there
was
a
story
to
manage
VMs
applications
on
the
end
on
top
of
cloud
providers
and
for
us
it
was
pretty
clear.
We
didn't
want
to
have
the
ansible
or
chef
in
the
for
describing
the
actual
software
so
for
the
infrastructure
sure
it
might
make
sense,
you
need
something
to
roll
out
or
to
to
provision
your
infrastructure.
A
You
will
need
something
like
that,
but
for
the
actual
application
deployments
we
didn't
want
to
go
the
route
to
to
do
chef
or
Ndebele
or
puppet
or
souls
like
whatever
varies,
because
that's
usually
some
some
description,
language,
not
everybody's
familiars
and
in
the
end
it
would
end
up
doing
in
the
in
the
ops
department.
So
the
infrastructure
guys
they
have
to
like
help
all
the
time
with
application
deployments
and
was
pretty
clear.
We
we
didn't
want
to
do
that
and
do
the
throughout.
So
why?
Why
do
you?
A
So
your
press
room
might
be
there's
AWS
on
the
bottom,
so
we're
running
on
AWS?
Why
not
just
use
the
AWS
primitives
you're
on
your
own
in
AWS?
Anyway,
that's
that's
a
fair
question,
but
we
weren't
always
on
AWS
right.
So
when
we
started
at
an
enterprise,
there
was
getting
compute.
Resources
was
actually
quite
a
long
and
daunting
process.
A
We
didn't
we
couldn't
just
go,
go
somewhere
and
say:
okay,
give
me,
give
me
16
instances
of
this
of
the
software
and
give
me
the
IP
address
and
give
me
an
IP,
I-44
DNS
and
give
me
in
in
10
minutes.
So
this
wasn't
possible.
There
was
lots
of
bureaucracy
involved,
we
had
to
fill
out
forms
and
the
provisioning
process
took
well
weeks
or
months.
I
would
say
so
and
as
a
as
a
as
a
product
or
as
a
project,
you
you
don't
have
this
time
to
wait.
A
A
They
are
so,
but
they
had
I,
think
of
four
or
eight
core
i7,
eight
or
16
gigabytes
of
RAM,
and
we
had
three
of
them,
because
you
need
kind
of
three
four
kubernetes
and
we
actually,
we
run
the
the
good
portion
of
the
first
year
on
these
on
these
small
systems,
and
they
work
quite
well
actually
and
one
of
the
main
points
for
that
was
because
the
the
final
destination
for
our
for
our
software-
it
wasn't.
Quite
it
wasn't
quite
ready
yet
so
we
it
was,
it
was
uncertain.
A
We
didn't
know
where
to
where
we
would
run
on
the
AWS
frame.
Contact
was
still
a
negotiation,
so
we
couldn't
just
bet
on
on
AWS
and
using
some
some
nice
AWS
projects,
products
to
deliver
this
wasn't
possible
and
from
from
a
project
perspective,
this
was
challenging,
but
it
was
a
huge
benefit
in
the
end
that
we
were
flexible
with
our
infrastructure,
because
we
evaluated
the
system
we
chose
for
what
the
platform
we
chose
as
a
foundation
based
on
these
constraints
also
yeah.
A
The
next
move
was
to
well
what
I
blatantly
called
private
cloud
here,
because
nobody
knows
what
a
private
cloud
really
is
right.
We
had
some
Dell
servers
there,
where
we
have
extant
system
running
and
we
kind
of
had
a
more
serious
system
for
testing
and
developing
the
software
product
on
top
of
kubernetes,
and
there
was
actually
pretty
good.
A
There's
no
managed
product,
so
you
have
to
more
or
less
you
have
to
do
everything
yourself.
There
are
some
some
help
from
companies
now
like
heo
and
Korres.
They
are
delivering
products
who
are
focused
on
AWS,
so
can
use
them
actually
and
make
the
the
experience
a
bit
more
convenient.
But
if
you're,
if
we
had
the
option
of
AWS
two
years
ago,
I'm
pretty
sure
we
would
have
go
for
for
AWS.
A
So
that
brings
us
to
the
next
question
is
how
do
we
do
DevOps
with
well
with
all
those
micro
services
I'm,
not
sure
if
I
mentioned,
but
we
have
right
now
we
have
around
35
micro
services
running
on
top
of
kubernetes
or
as
a
as
a
single
application
stack
full
end-to-end
stack
and
these
35
micro
services.
We
are
still
in
developing
mode,
so
we're
just
adding
features
to
the
platform.
We
are
still
collecting
requirements
from
the
business
owners.
What
what
do
we
have
to
do
next?
And
so
this
we're
still
growing
with
the
micro
services.
A
So
there's
well
not
an
end
in
sight.
Maybe
we
end
up
at
40
or
45,
and
yes
actually
so
for
a
single
environment,
that's
that
might
be
easy
to
manage,
but
we
have
we've
kind
of
Lots
environments.
We
have
not
only
depth
environment,
but
you
also
have
the
testing
environment,
the
customer
integration,
environment,
performance
testing,
all
those
sprints
you
do
and
all
those
releases
you
do
so
all
those
stuff
has
to
go
somewhere
and
it's
not
only
the
single
application
stack
because
it's
not
always
all
your
applications
at
once.
A
You
also
have
these
continuous
delivery
of
each
and
every
software
in
this
deck.
So
there
comes
this
version
complexity
also
towards
it,
the
dimension.
How
do
we
manage
these
version
complexities?
How
do
we
deal
with
the
environments
and
there's
just
one
answer
to
that
right
now,
if
you're
focused
on
the
integration
perspective
and
that's
Cube
CDL,
so
all
of
our
developers
have
cluster
XS,
obviously
for
for
for
the
namespaces
and
actually
they're
so
need
for
for
AWS
success.
A
We
don't
have
any
of
our
actually
there's
only
a
very
small
group
managing
AWS
and
since
we're
a
custom,
def
project,
so
we
don't
use
too
much
of
the
the
other
software
products
AWS
has
to
offer
like.
There
are
many
we're
more
or
less
just
delivering
custom
software
you
so
we
we
get
away
with
just
delivering
or
handing
out
chips,
Edel
access
to
our
developers
and
that's
actually
pretty
cool,
because
we
can
manage
these
these
credentials
and
the
permissions
natively
in
kubernetes.
In
the
platform
itself
we
are
running
on.
A
We
don't
have
to
manage
many
things
on
AWS.
In
fact,
lots
of
things
kubernetes
manages
for
us
like
persistent
volumes
or
load
balancers
for
route
53
entries.
So
all
these
many
other
things
are
a
thing
of
the
past
and
whenever
we
have
the
option
to
go
by
our
too
generous
something
through
kubernetes
through
the
underlying
platform,
then
we
we
go.
The
throat
and
for
developers
is
actually
pretty
easy
because
there
is
well
they
care
about
the
application
right.
So
they're
focused
on
the
application
they
want
to
know.
Is
it
running?
How
long
is
it
running?
A
A
So
now
that
I
run
not
that
I
can
run
containers
and
and
manage
them,
that's
nice!
But
what
about
the
code?
How
do
we?
How
do
we
manage
getting
there
and
that's
also
not
so
easy,
because
there
are
many
many
many
options.
I've
listed
a
couple
of
them
here
so
I'm
sure
everybody
knows
Jenkins,
because
lots
of
people
use
Jenkins.
There
are
some
some
other
things
you
might.
You
might
like
as
a
developer
experience
on
top
of
kubernetes,
which
is
fabricate.
A
This
is
another
one,
which
is
it's
pretty
good
and
we
we
evaluated
it,
but
it's
all
kind
of
opinionated
and
in
the
end
we
we
chose
katrana
get
LeBron,
oh
because
it
gives
us
the
most
flexibility.
We
were
kind
of
fence
of
of
:
conquer,
so
spinnaker.
We
we
evaluated
those
tools
in
depth
when
spinnaker
went
native
with
their
kubernetes
integration.
A
If,
if
you're
familiar
with
that,
but
that's
everything
is
available
on
premise
of
we're,
maybe
that's
another
mentioning
worth
of
another
thing
worth
mentioning
everything
we
had
to
run
was
on
premise,
so
there
was
no
option
for
us
to
use
any
of
the
of
the
nice
software
as-a-service
products
they're
out
there.
So
that
means
no
slack.
No
no
CI
in
the
cloud
will
know.
A
No
other
nice
integrations
you,
you
might
use
from
the
the
cloud.
So
we
had
to
run
everything
ourselves
and
we
still
have
our
and
the
actually
they
gave
LeBron
a--
was
was
one
project
which
which
evolved
with
us
basically
and
in
the
end
there
was
no
need
to
switch
it
out
to
a
different
CI,
CD
approach.
A
So
next
I
want
to
talk
about
the
auto
scaling
of
the
CI.
It's
a
bit
of
a
technical
feature.
I
hope
you
don't
mind
because
I
pretty
much
I
like
the
approach
when
we
started
at
the
beginning
of
the
project
we
we
were
well.
Everybody
was
excited
about
daca
and
we
were
pretty
excited
about
that.
You
can,
as
as
a
CIA
you
can.
The
project
can
deliver
talk
up
containers
as
they're
build
containers
as
they're
testing
containers
right.
A
So
no,
no
more
of
going
to
to
the
infra
department
and
and
clearing
to
just
install
this
version
of
Ruby,
or
this
is
this
version
of
Java
or
into
your
into
your
site
CI.
So
you
just
like
deliver
the
docker
container
and
the
docker
image
and
you're
you.
You
run
your
own
code
or
your
own
testing
code
in
the
CI.
So
that's
your
yeah!
You
have
to
you,
you
can
do
it
yourself,
you
have
to
do
it.
You
can
do
it
yourself
and
that
was
pretty
nice,
but
I.
A
Think
the
the
better
thing
now
is
that
we
actually,
we
cannot
only
hand
out
these
responsibilities
to
to
the
application
developers
because
they
know
best
how
their
application
should
should
be
tested
and
should
be
run
the
environment.
But
we
can
also
run
the
CIA
itself
as
a
container
as
a
button
in
our
cluster,
so
that
wasn't
possible.
Two
years
ago
we
had
a
kind
of
static
builders
and
then
you
have
either
you
have
to
come
up
with
your
own
flow
of
outer
scaling.
A
The
builders
in
AWS,
but
that
would
be
custom
development
or
looking
at
all
other
integrations.
So
obviously
the
right
approach
would
be
to
to
just
well
don't
build
on
your
cluster.
You
have
abstraction
of
compute
resources,
so
might
as
well
use
them,
and
this
is
what
we
can
do
with
get
lip
now.
There's
the
kubernetes
executors,
which
just
spawns
it's
just
bonds
as
a
pot
for
your
OS
testing
stage
and
it
executes
the
code
which
is
in
the
indicate,
lab
CI
Yama
file,
and
it
will
just
do
that.
A
A
That's
that's
a
very
valid
question
and
the
thing
is
that
currently
kubernetes
provides
very
good
or
is
in
the
process
of
providing
soft
isolation
between
environments
or
between
runtimes
and
containers,
but
for
a
CI.
You
well
you're
not
really
sure
what
you
execute
right.
So
there's
the
the
danger
of
hogging
all
these
resources
anyway
by
are
some
kind
of
bottleneck
by
a
disk
memory
or
unknown
buxton
docker
or
so
the
the
risk
of
running
this
as
part
of
your
application
workload.
So
we
are
not
running
prod
and
F
on
the
same
class.
A
So
that's
that's
for
sure,
but
even
if
you're
you
have
kind
of
its
kind
of
prot
like
if
you're
developers
are
dependent
on
it,
so
you
can't
just
really
play
around
with
it.
So
we
I
think
the
the
more
clean
approach
is
to
have
heterogeneous
classes
right
now,
but
maybe
in
in
a
year
or
two
when
KVM
CI,
maybe
is
an
option,
then
the
this
could
run
be
very
well
run
on
the
same
cluster.
A
Okay,
so
with
this
nice,
kubernetes,
executors
and
auto
scalars.
So
how
can
we
deploy
the
software?
We
are
using
namespaces
as
isolated
environments.
This
gives
us
a
nice
separations
of
of
concerns,
so
actually
we
have.
We
have
lots
and
lots
of
namespaces
because
they're
cheap.
We
can
just
create
and
consume
them.
How
we
want,
and
the
other
thing
why
we're
doing
isolated
environments
in
namespaces
we
can
do.
A
A
I
use
comment
service
I,
just
put
in
the
the
name
of
the
actual
of
the
actual
software
I
want
to
use
if
I'm
in
the
same
environment,
I'll
just
consume
that
there's
nothing,
nothing
special
needed
and
if
I
have,
if
I
want
to
have
another
environment,
I
just
spin
up
a
new,
a
new
kubernetes
namespace,
and
also
the
thing
that
you
can
do.
Permissions
roles
and
permissions
in
kubernetes
right
now
is
focused
on
on
a
namespace
as
as
an
object
or
as
an
entity.
So
yes,
I,
would
I
would
advise
you
to
look
into
namespaces.
A
If
you,
if
you
don't
know
them,
so
how
do
we
manage
deployments?
I've
I've
talked
about
helm
a
bit
and
with
well
a
templating
engine,
maybe
for
for
kubernetes
it
abstracts
the
kubernetes
internals
away,
so
the
ideas
as
an
application
developer.
You
you
care
about
your
applications
and
only
about
your
application
right.
You
get
the
name.
You
have
the
number
of
instances
you
want
to
run
your
the
the
capacity
you
have,
maybe
your
requirements
or
dependencies,
but
that's
it
I,
don't
want
to
know
whether
they
contain
our
image
or
all
those
container
details.
A
I,
don't
bother
with
them.
They
they
should
be
abstracted
away
from
me
and
that's
exactly
what
what
helm
is
doing.
If
you,
if
you
haven't,
checked
out
helm,
it's
basically
I
think
it's
the
future
of
application
deployment
for
for
companies,
and
if
you
describe
your
application
in
helm,
chart
it's
pretty
much
a
guarantee
that
you
can
run
it
on
any
kubernetes
or
kubernetes
space
distribution
cluster
in
installation,
wherever
you
have
so
I'm
almost
at
the
end,
all
want
to
quickly
talk
about
a
few
challenges
so
who
has
brought
up
a
kubernetes
cluster
yourself?
Oh
wow.
A
That's
quite
a
lot,
so
I
I'm,
not
sure.
If
you
have
done
it
will
have
Bayern,
installer
or
Virant.
So
we've
tried
some
installers
but
they're
on
right
now,
so
it's
getting
better,
definitely
with
queue
pedion.
But
when
we
started
there
was
maybe
Cuba,
but
but
nothing
else.
So
we
we
had
to
do
this
bootstrapping
process
ourselves
which
well
you
learn
a
lot
about
kubernetes,
which
is
nice,
but
you
want
to
do
it
only
once
and
not
every
time
and
the
class
upgrade
procedures.
A
Even
now,
it's
kind
of
challenging
doing
in
place
zero,
downtime,
kubernetes
cluster
upgrades
it's
kind
of
a
challenge
today,
but
it
gets
manageable.
There
are
approaches
with
self-hosted
and
cube
EDM,
which
are
which
are
very
really
about
the
administrator
perspective
of
bootstrapping
a
cluster.
So
that's
that's
a
huge,
plus
and
I'm
really
looking
forward
to
these
benefits.
A
So
in
the
future,
for
for
our
project
the
kubernetes
set
of
things
we
we
want
to
go
the
build
on
the
Elm
improvements
and
was
majoring
every
or
every
port
on
release.
I
think
we
want
to
build
an
episode,
so
other
divisions
of
the
enterprise
can
consume
simply
easily
consume
our
applications.
There
are
talks
of
running
OpenShift
and
all
other
communities
distributions
and
the
company,
so
people
can
just
consume
these
our
apps
on
their
clusters.
A
So
what's
in
the
future
for
for
German,
rail
I,
think
civilization,
roll
out
into
more
stations,
so
I
didn't
mention
that,
but
we
are
not
kubernetes
right
now,
it's
not
powering
all
all
the
these
stations
in
Germany
is
spiraling
selected
stations
where
we
have
a
rollout
of
these
new
displays,
but
over
time
we
were
all
out
to
to
even
more
stations
in
Germany.
So
that's
that's
a
go-to
to
go
more
into
production
and
kubernetes.
Our
containers
as
all
have
to
become
boring.
A
A
A
A
All
right,
so
we
have
we're
running
right
now
on
AWS
and
that's
the
the
network
difference
between
from
from
the
from
here
to
there
is
all
this
is
obviously
running
on
public
and
AWS.
The
data
center
is
is
where
our
beckons
runs
and
as
a
first
milestone,
I
would
say
we
were
running
the
same
application,
stick
in
a
different
cloud
or
even
on
premise,
because
there
what
we
have
the
data
centers
and
the
next
thing
would
be
to
have
a
federated
cloud.
So
to
do
this
failover
automatically.
A
A
All
right,
so
yes,
the
question
was:
how
do
we
use
deployments
as
part
of
the
CI?
That's
a
that's
a
good
question,
so
we
have
a
ham
repository
right
now,
where
we
push
all
our
chart
updates
and
the
CIA
is
currently
moving
to
ahem
upgrade
approach.
So
in
this
github
CI
Rana
there's
the
stage
which
is
called
deployment,
it's
it's
more
or
less.
A
At
the
end,
it
depends,
though,
to
which
environment
we
want
to
deploy
automatic
deployment
is,
is
going
to
death,
so
we
take
each
commit
or
each
docker
container
with
the
commit
hash,
a
digital
commit
hash.
We
built
the
image
and
we
deploy
it.
Why
are
right
now?
We
are
currently
transitioning
to
helm
upgrade,
but,
prior
to
that,
we
are
using
a
cube.
Cdl
set
image,
just
plain
set
image,
but
yeah
upgrade
is
the
way
we
want
to
go
because
we
have
well
huge
stakes
in
the
helm,
approach
of
managing
applications
on
queries.
A
A
A
A
Yeah,
that's
a
good
question,
the
the
secrets
in
kubernetes
how
we?
How
do
we
do
that?
So
there
are
a
couple
of
choices
to
do
that,
because
in
the
end,
it's
hard
to
automate
this
process
right
because
secrets
are
kind
of
you
have
to
be
responsible
for
them.
You
can
just
check
them
in
or
somewhere,
so
you
could
use
the
github
CI
for
that
as
well.
A
You
can
define
secrets
there
as
an
administrator
and
inject
it
in
your
your
every
time,
I
run
I
execute
a
support
for
the
for
the
real
secrets
for
the
application
secrets.
Actually
we're
not
so
much
concerned
about
that,
because
we're
running
not
in
not
in
the
we're
running
in
a
in
a
very
constrained
Internet
in
a
in
an
AWS
V
PC.
So
we
trust
basically,
the
applications
which
are
running
there.
So
we
have
most
of
the
secrets
are
right
now
in
the
indeed
just
in
the
repository,
because
we
wanted
these
abstractions
from
secrets.
A
So
in
case
we
need
to
move
them
out.
We
can
just
take
the
secrets
and
they
are
not
hard-coded
but
I.
Think
the
the
whole
secret
story
in
kubernetes
is
kind
of
developing
right
now.
So
there's
lots
of
demand
on
how
to
do
that,
and
there
are
people
have
different
ideas
and
feeling
how
to
solve
these
problems
and
I
think
it
will
be
very
interesting
to
fast
forward
to
the
end
of
the
year
and
see
you
what's
well.
What's
there
at
the
end
of
the
year,
what
kind
of
stuff
can
I
look
at?
A
A
I
thought,
yes,
a
very
good
question
for
the
gate
lab.
How
do
we
install
get
lab
basically
and
on
the
cluster
when
there
was
a
question?
So
when
we
started
there
was
a
community
maintained,
get
lab
chart?
We
we
started
with
the
community
maintained,
get
lab
chart
and
we're
well,
because
the
application
deployment
is
kind
of
fast
right
now
with
kubernetes.
We
we
just
deployed
the
end
charge
over
and
over
and
more
or
less
moved
every
every
dot
release
to
to
the
nougat
lab
release.
A
We
haven't
moved
to
29.0
yet
because
we
we
are
in
the
transitioning
face
to
the
official
get
lab
chart
of
of
get
lab
from
get
lab,
and
so
we
have
a
PLC.
We
are
currently
testing
it.
The
the
official
chart
and
I
think
it
works
more
or
less
now,
and
we
just
have
to
do
the
transitioning.
It
was
a
bit
challenging
dolla
last
a
couple
of
weeks.
That's
why
we
haven't
made
it
yet,
but
I
think
it's
it's
very
much
usable
now.