►
Description
Taking the Helm: Delivering Kubernetes-Native Applications - Michelle Noorali and Matt Butcher, Deis & Adnan Abdulhussein, Bitnami
"The typical workflow for delivering an application on top of Kubernetes involves managing a bunch of manifest files in your Git repositories, and writing new manifests usually means copying lots of boilerplate. There are no standard ways to share and manage what’s running in your cluster. Enter Helm, a tool that streamlines the creation, deployment and management of Kubernetes-native applications. In this demo-led session, members of the CNCF Helm team show you how you can use Helm to improve your deployment workflows.
This presentation will cover:
- The history of Helm
- Deploying your first Chart
- Making your application Kubernetes-native with Helm
- Best practices for creating and configuring Kubernetes Charts
- Guidelines for contributing official Kubernetes Charts
- Setting up a Chart Repository to share your own Charts"
About Adnan Abdulhussein
Core contributor and Chart maintainer on the Kubernetes Helm project
About Matt Butcher
Deis
About Michelle Noorali
Core Maintainer on the Kubernetes Helm project
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.
C
I'm
Matt
butcher
I'm
also
with
dais
and
together
we're
about
half
of
the
core
contributors
group
from
helm.
Most
of
the
other
half
is
also
sitting
in
the
audience,
and
so
we
wanted
to
talk
to
you
for
a
little
while
today
about
what
helm
is
how
you
can
use
it,
the
problems
it
solves
and,
ultimately
why
it's
a
good
tool
for
teams
to
use
when
we're
working
collectively
on
kubernetes.
So
speaking
of
kubernetes,
this
is
sort
of
like
my
mental
picture
of
what
kubernetes
is.
C
This
is
beautiful
workshop
right
and
you
have
all
these
tools
each
tool
designed
to
build
beautiful
things
right
and
you
can
build
all
kinds
of
different
furniture.
Once
you
have
these
tools,
you
know
you
can
sculpt
these
intricate
little
details.
You
can
make
a
basic
table.
I
feel
like
kubernetes
is
kind
of
like
that.
We
have
all
these
different
resource
types
and
with
these
different
resource
types,
we
can
build
all
kinds
of
things.
Some
of
them
are
very
basic
applications
that
just
get
a
single
job
done.
Some
of
them
are
highly
sophisticated.
C
You
know
multi
tier
aggregates
of
we
know
with
databases
and
caching
layers
and
vertical,
auto
scalars
and
things
like
that,
but
we've
got
those
tools
that
can
build
stuff,
okay,
so
furniture
making.
How
many
of
you
by
show
of
hands,
make
your
own
furniture.
Yet
we've
always
got
a
couple
in
the
audience.
Oh
yeah,
the
thing
is
most
of
us
don't
want
to
build
our
own
furniture.
We
it's
not
that
we
don't
value
craftsmanship
right,
it's
not
that
we
don't
value
value,
beauty
or
value
utility.
C
It's
that
we
don't
want
to
build
our
own
furniture.
We
want
to
leave
it
in
the
hands
of
the
experts,
and
so
most
of
us
choose
this
route
right.
We
want
to
get
furniture
that
somebody
else
designed
that
somebody
else
figured
out
how
it
can
fit
into
my
living
environment
and
we
want
to
just
go
with
it
right.
C
So
there
are
furniture
builders
and
there
are
people
like
us,
we're
really
more
furniture,
assemblers
right,
and
so,
when
we
as
the
helm
team,
looked
at
kubernetes,
we
said
they're
all
these
tools
but
to
be
totally
honest,
I,
don't
know
how
to
use
some
of
them
and
a
lot
of
them
I
can
use,
but
maybe
not
to
maximal
efficiency
right
and
so
with
helm.
We
wanted
to
build
the
kind
of
tool
that
would
let
the
expert
furniture
builders
create
us,
something
like
IKEA
furniture
and
that's
what
helm
is
so.
B
Let's
take
mats
IKEA
metaphor
to
the
next
level
say
you
walk
into
the
Wonderland
that
is
IKEA
and
you
shop
around
for
things
that
you
need
and
sometimes
for
things
that
you
don't
actually
need,
but
really
really
want,
and
what
you
walk
out
with.
Are
these
packages
of
pre-built
furniture
that
gets
you
that
much
closer
to
the
living
room
of
your
dreams.
B
So,
in
that
same
vein,
helm
gives
you
packages
of
pre-built
applications
or
application
components
which
you
can
then
easily
install
and
manage
in
your
kubernetes
cluster,
and
that
is
really
powerful,
because
if
you
want
WordPress
running
on
kubernetes,
you
don't
have
to
build
that
yourself.
If
you're
trying
to
get
up
and
up
and
running
with
my
sequel,
you
don't
have
to
start
from
scratch,
you
don't
even
have
to
figure
out
how
to
run
Jenkins
and
kubernetes
yourself.
Someone
has
already
solved
that
problem
for
you.
They
built
a
chart
for
it,
they're
willing
to
share
it.
B
They've
even
embedded
their
own
knowledge
of
kubernetes
best
practices
into
that
chart
itself,
and
that
gives
us
more
time
for
two
things:
one
there's
more
time
to
get
production
ready
with
less
effort
and
two
there's
more
time
to
go
to
all
those
hipster
coffee
shops
that
we
know
and
love
so
I
mentioned
charts
and
packages
in
home
world
are
called
charts,
so
chart
is
a
way
to
define
an
application.
It
consists
of
mainly
three
things.
The
first
is
metadata.
B
This
is
who
authored
the
chart
information
like
what
version
its
add,
a
little
description
where
your
docker
images
live.
The
second
piece,
the
biggest
component,
are
the
actual
kubernetes
resource
definitions
themselves.
These
can
be
templated
or
not,
and
then
there's
also
documentation.
So
here's
a
chart.
This
is
what
it
means.
This
is
how
you
run
it.
These
are
some
instructions
provided
by
the
kubernetes.
Excuse
me,
the
chart
author
and
charts
live
in
these
things
called
chart.
Repositories
and
adenine
will
give
us
a
deep
dive
in
that
a
little
bit
later.
B
B
A
B
B
So
say
you
want
to
search
for
WordPress,
you
get
one
result.
This
is
you've
gotten
a
WordPress
chart
back
in
a
stable
repository.
Charts
are
always
named
spaced
by
the
repository
that
they
live
in
and
you
can
also
search
for
what
other
charts
are
in
the
repository
that
you
have
access
to
so
we'll
install
the
WordPress
chart
here
using
the
install
command
and
a
few
things
happen.
So,
let's
dissect
that
first,
we
fetch
the
WordPress
chart
from
the
stable
repository
until
er
created
a
release
for
you
with
a
randomly
generated
name.
B
This
one
is
wobbling
mule.
If
you
want
to
have
less
fun
in
life,
then
you
can
also
pass
in
the
n
flag,
but
I
I
recommend
this
way,
and
you
also
get
some
metadata
back
information
on
the
actual
kubernetes
resources
that
were
created
and
at
the
very
bottom
you
get
some
notes
or
post
installation
instructions
that
the
chart
author
has
provided
for
you.
So
here
we
see
that
we
can
get
the
WordPress
URL
by
running
this
command,
and
then
we
also
have
some
information
on
the
default
credentials
that
you
can
use
in
your
blog.
B
B
B
We
have
an
upgraded
version
and
if
we
just
watch
that
we'll
see
the
container
getting
created,
we'll
see
it's
now
running
and
now
it's
ready,
which
means
we
can
go
back
to
our
WordPress
site
and
make
sure
that
everything
didn't
blow
up.
I
have
a
feeling
it
didn't,
but
you
never
know
what
these
recorded
dismiss
so
we're
at
4.6.1
and
we
still
have
all
of
our
data.
B
B
A
Maximum,
so
so
michelle
walked
you
through
how
you
can
manage
the
releases
of
your
chart
and
upgrade
and
delete,
but
you're
probably
wondering
how
do
you
package
your
own
application
as
a
chart?
Well
home
has
a
really
easy
command
to
get
you
started.
All
you
need
to
run
is
helm
krei,
my
app,
and
this
is
what
you'll
get
some
Yama
files
a
couple
directories
not
to
be
punting.
How
do
I
navigate
this
thing?.
A
So
the
first
place
you
want
to
look
is
in
the
templates
directory.
So
if
you're
already
deploying
your
application
to
kubernetes,
you
probably
already
have
some
point
files
or
services
or
any
kubernetes
resource.
So
if,
if
you
dumped
all
those
files
in
this
directory,
you
dog,
you
would
already
be
ready
to
go,
but
as
an
added
bonus,
tiller
will
also
run
through
each
of
these
files
and
run
them
through
the
template
rendering
engine.
A
A
A
So,
as
you're
building
out
your
chart,
you
may
realize
that
you
need
to
bring
in
some
dependencies
so,
for
example,
for
WordPress,
you
may
find
that
you
need
to
bring
in
a
database
chart.
So
this
is
where
the
charts
directory
comes
in
and
inside
the
charts
directory
you
can
essentially
vendor
in
a
normal
chart.
A
It
would
have
the
same
structure
as
the
outer
chart
and
when
you're
going
to
do
helm,
install
he'll
also
deploy
that
chart
with
the
outer
chart.
If
you
find
yourself
using
a
dependent
chart
in
multiple
places,
then
you
can
make
use
of
Helms
requirements
or
yamo
file
which
similar
to
a
gem
file
or
requirements
of
txt
in
Python.
It
allows
you
to
specify
the
name
of
the
chart,
the
version
you
want
and
a
repository
it
it
can
be
found
in
and
then
then
you
can
run
helm
dependencies
update
and
it
will
pull
in
that
chart.
A
Documentation,
so
there
are
two
ways
to
document
your
chart:
there's
a
readme
which
is
generally
the
first
place
that
people
will
look.
So
this
is
you
know
if
your
if
your
chart
is
on
github
somewhere
and
people
browsing
your
github
repository
they'll,
be
able
to
see
you'll
read
me,
so
this
is
where
you'd
want
to
document
what
the
chart
actually
is
and
maybe
even
talk
about
some
prerequisites,
so
you
may
need
a
specific
version
of
proven
at
ease,
for
example,
and
other
practices
we've
seen.
A
A
A
As
Michelle
mentioned
on
a
previous
slide,
the
other
part
of
your
chart
is
the
metadata,
and
this
pretty
much
all
exists
in
the
chart:
dot
Yama
file.
So
you
have
a
description
of
the
chart.
Keywords
the
sources
for
the
doctor,
images
and
who's
maintaining
that
chart,
but
you
also
have
a
version
field,
and
this
doesn't
necessarily
have
to
be
the
same
version
of
a
thing
that
you're
packaging
and
the
reason
for
that
is.
A
A
A
A
So,
whilst
maintaining
this
chart
repository,
a
couple
of
us
have
been
thinking
about
what
best
practices
we
want
to
form
for
both
charts
and
kubernetes
resources
themselves.
And
although
these
are
you
know,
constantly
evolving
as
kubernetes
and
helm
themselves
of
all
I
wanted
to
share
some
common
patterns
that
we've
seen
so
the
first
one
is
pretty
pretty
obvious.
Your
chart
should
work
out
the
box.
If
you,
if
you
have
a
wordpress
chart,
it
should
have
everything
it
needs
to
go
into
poi
a
working
version
of
WordPress.
A
A
chart
should
only
be
responsible
for
deploying
a
single
component.
If
you
find
yourself
building
a
chart,
that
is,
the
port
has
manifest
for
a
database
as
well
as
the
application
itself.
You
might
want
to
spit
that
out
into
a
sub
chart,
because
that
sub
chart
can
also
be
used
reused,
and
it
goes
to
my
next
point.
Don't
repeat
yourself
can
be
reused
in
other
charts,
for
example,
to
Mary
DB
chart
is
reused
in
group.
Our
redmine
wordpress
and
all
those
chosen
home
also
provides
other
ways
to
stop
repeating
yourself.
A
A
Your
chart
should
also
be
reproducible
when
you,
when
you
package
and
share
the
chart
it
should.
The
deployment
should
work
as
it
did
on
your
cluster,
and
there
are
two
general
ways
that
you
can
do
this.
You
want
to
make
sure
that
your
template
is
as
declarative
as
possible
and
reduce
any
scripting,
and
also
you
should
make
sure
that
you're
pointing
to
immutable
image,
tags
or
content
shots.
C
So
we
started
off
by
looking
at
what
helm
was
right
when
I
came
out
here,
I
tried
to
give
a
good
brief
explanation.
Then
we
went
from
that
from
that
furniture
metaphor
into
seeing
how
Michelle
used
helm
to
install
and
then
manage
a
couple
of
charts
right.
We
looked
at
the
WordPress
installation
and
then
anon
walked
you
through
the
process
of
creating
a
chart
and
and
then
showed
some
of
the
best
practices
and
now
I
want
to
kind
of
bring
it
all
back
together
by
explaining
why
we
built
this
tool.
C
The
way
we
did
and
why
it's
designed
to
help
teams
and
I
thought
I'd
highlight
five
different
ways.
So
I
know
that
for
some
of
us
in
here
went
you
know
going
back
to
that
furniture
metaphor
right.
We
liked
the
idea
of
being
in
the
role
of
just
picking
our
furniture
and
assembling
it
not.
You
know,
handcrafting
it
lovingly
from
scratch.
That
was
an
intentional
design
goal
for
us.
C
We
really
really
wanted
to
make
it
easy
for
the
teams
that
are
new
to
kubernetes
to
get
started
quickly,
so
you
can
find
some
actually
usable
stuff
out
there
in
that
stable
charts,
repository
or
experiment
with
some
of
the
cutting-edge
stuff
in
the
incubator
repository
and
have
something
up
and
working
quickly,
and
then
you
can
go
back
and
look
at
what
it
is
that
you
created
and
get
kind
of
that
sort
of
view
of
kubernetes.
Yes,
I
installed
it.
Yes,
I
see
that
it's
WordPress.
How
does
it
work?
C
Oh,
it's
got
this
service,
so
it's
got
this
deployment
in
this
database.
They
connect
this
way
and
it's
a
great
way
for
many
of
us
to
kind
of
learn.
The
internals
of
kubernetes
now
I
know
that
some
of
you
in
here
are
not
IKEA
shoppers,
your
furniture
makers
right
and
so
when
we
went
to
build
the
the
chart,
format,
the
chart
language
and
the
template
language,
we
intentionally
tried
to
design
something
that
would
allow
you
the
the
ability
to
dive
all
the
way
in
to
the
kubernetes
resource
types
to
change
all
the
different
stuff.
C
In
there
we
don't
layer
on
constraints.
We
don't
restrict
you
to
particular
resource
types.
We
try
and
give
you
all
those
furniture
building
tools,
and
then
we
tried
to
build
a
system
that
made
it
easy
for
those
of
you
who
are
at
domain
experts
in
these
fields
to
share
these
charts
with
other
people.
C
Now
it
might
be
that
you're
just
sharing
them
internally
with
your
team
right,
the
application
developers
throw
their
app
over
the
wall,
you
build
them
a
chart
and
then
you
can
reliably
and
reproducibly
deploy
this
chart,
but
it
might
be
that
you
want
to
contribute
back
upstream
into
the
stable
repo
or
your
organization
wants
to
start
its
own
repo
and
we
wanted
to
make
that
easy
for
you
to
do
as
well.
So
that's
that's
the
second
one.
The
third
one
was
where
things
got
tricky
for
us
right.
C
It's
not
just
when
you
look
at
a
package
manager
and
we've
all
looked
at
them
right.
You
do
your
Brio,
install
or
apt-get
or
yum,
or
whatever,
usually
we're
only
installing
one
instance
of
something,
but
in
a
cluster
you
ought
to
be
able
to
take
the
same
chart
and
install
it
as
many
times
as
you
want
there.
You
want
to
five.
Whatever
eight
Moorea
databases,
you
should
be
able
to
install
them,
but
then
we
ended
up
in
the
application,
lifecycle
management
and
that's
where
tools
like
helm,
install
and
then
update
rollback
history.
C
D
C
Whenever
there's
a
paradigm
shift,
which
is
basically
I,
think
what
we're
seeing
right
kubernetes
is
very
different
from
from
the
kinds
of
architectures
I
worked
on,
but
we
have
a
bunch
of
existing
tooling
and
whenever
there's
a
shift
like
this,
we
need
to
figure
out
bridges
right.
We
need
to
figure
out
how
Jenkins
is
going
to
work
in
the
kubernetes
world
when
it
was
a
tool
that
was
essentially
built
for
running
on
bare
running
bare
metal
stuff.
C
You
know
10
15
years
ago,
so
one
of
our
design
goals
was
to
borrow
metaphors
that
people
and
that
people
are
already
comfortable
with
that
package
management.
Metaphor
is
good,
that
command
line
metaphor
with
configuration
files
that
stuff
works
well
and
we
designed
helm
to
be
able
to
work
in
existing
sea
icd
systems
and
with
existing
shell
scripting
tools
and
like
that
and
tried
to
expose
things
so
that
it
made
sense
that
way,
because
it's
not
merely
the
case
that
we
as
humans
are
comfortable
with
repeating
design
patterns
like
a
package
manager
right.
C
The
thing
is
we
built
tools
that
expect
package
managers
to
behave
a
particular
way
and
we've
tried
to
carry
those
assumptions
in
to
helm
so
that
helm
really
feels
to
your
tool
chain
like
a
package
management
system
now.
Finally,
the
fifth
point
is
that
the
kubernetes
cluster
should
be-
and
we
feel
very
strongly
about
this-
the
collaborative
Center
for
your
team
for
your
releases.
C
C
That's
the
way
we
built
this
tool
so,
except
for
the
chewing
out
part,
you
have
to
do
that
on
your
own,
but
no.
The
idea
is
that
the
the
cluster
itself
kubernetes,
is
a
great
way
to
gain
visibility,
cluster
wide
into
all
the
different
things
that
are
running,
and
we
wanted
to
take
that
design
philosophy
and
make
sure
that
it
carried
all
the
way
over
into
this
package
management
system.
So
those
are
five
ways
that
helm
helps.
You
helps
your
team
manage
releases
and
applications
inside
of
a
kubernetes
context.
C
All
right
now,
I
would
be
remiss
if
I
didn't
talk
about
the
community
that
has
done
is
we
have
over
65
contributors
have
done
at
least
one
PR.
Lots
of
contributors
have
done
dozens
of
PRS.
We
introduced
helm
at
point
zero,
one
at
last,
coop
con
we're
about
to
release
version
2.0,
so
we're
one
year
old
and
we
have
experienced
tremendous
growth
and
we're
really
excited
because
the
2.0
release
really
is
the
concrete
implementation
of
what
we
had
envisioned
when
we
set
out
for
this.
We're
really
really
pleased
and
excited
about
it.
C
C
One
of
the
things
that
we
do
is
we
hold
a
public
developer,
stand
up
on
Thursdays
and
the
idea
is
all
of
the
core
developers
that
can
make
it
will
sign
in
on
a
Thursday
morning
and
will
give
their
regular
stand-up.
This
is
what
I've
been
working
on
in
the
last
week.
This
is
what
I
plan
to
work
on.
This
is
what's
what
I'm
struggling
with
and
the
community
anybody
who
feels
like
it
can
show
up
to
these
meetings
and
there's
time
to
ask
questions.
C
We've
even
have
had
people
show
up
in
the
community
and
say:
hey
I
did
something
really
cool
you
mind
if
I
show
we've
had
that
happen
a
few
times
and
we'll
often
just
do
sort
of
spur
the
moment.
Demos
if
you
just
want
to
come
and
watch
and
be
quiet,
that's
fine,
too,
but
it's
a
great
opportunity
to
sort
of
see
under
the
hood.
As
you
probably
know,
most
kubernetes
projects
are
under
at
least
one
special
interest
group,
one
sig
and
our
parents
IgG,
is
the
sig
app
sig
and
that
meets
on
Monday
mornings.
C
That
is
another
awesome
place
to
go
to
just
kind
of
it's.
It's
very
demo.
Driven
Michelle
and
Matt
Farina
run
the
meeting.
So
it's
very
demo
driven
very
it's
one
week.
You
may
see
an
alpha
a
feature.
That's
on
its
way
into
kubernetes
the
next
week
you
may
see
you
know
somebody's
project
where
they
used
kubernetes
in
an
interesting
and
novel
way.
C
Most
of
the
projects
in
cig
apps,
including
helm,
we
give
our
weekly
update
on
our
status
and
then
there's
a
great
time
near
the
end
where
you
can
just
drop
in
ask
some
questions.
Toss
out.
Some
ideas
get
yourself
scheduled
to
give
a
demo
and
stuff
like
that.
So
we've
worked
really
hard
to
try
and
you
know
give
back
to
the
community.
That's
been
awesome
to
us,
give
back
a
voice
so
that
we
can
keep
moving
collectively,
because
this
tool
is
only
going
to
be
a
successful
tool.
C
If
it's
meeting
the
needs
a
very
broad
swath
of
needs
for
all
of
us
that
are
in
here.
Ok!
So
what's
next,
so
we
are
really
really
close
to
the
2.0
release.
We
released
our
c2
on
probably
Friday
450,
knowing
my
previous
and
then
I
came
here.
So
nobody
could
chew
me
out.
If
I
broke
the
build,
so
we
will
be
out
probably
within
the
next
seven
days.
I,
don't
think
there
are
any
show
stopper
bugs
in
there
right
now,
and
so
the
2.0
release
will
come
out.
C
That's
already
we're
at
API
stability,
API
frozenness,
then
we're
going
to
transition
after
the
2.0
release,
we'll
keep
a
2.0
point
1.2
patch
releases,
but
the
2.1
branch
will
begin
our
next
round
of
feature
development.
So
we've
been
talking
a
lot
about
stability
stories.
How
do
we
help
people
increase
the
stability
of
of
their
their
helmets
ecosystem
right?
C
How
do
we
make
things
more
and
more
secure
and
we've
already
put
down
some
foundations,
we're
just
trying
to
figure
out
how
to
solidify
those,
and
there
are
a
lot
of
feature
requests
in
there
that
we
will
do.
We
are
working
hard
at
a
feature.
We're
really
excited
about
that,
would
allow
chart
developers
to
declare
tests
for
their
charts
and
then,
when
you
push
in
your
chart
on
an
install,
you
can
pass
in
a
test
flag
and
it'll
be
able
to
run
some
tests
to
verify
it.
C
So
you
can
do
in
cluster
test
Michell
and
on
on
are
both
working
hard
and
Adam
are
all
working
hard
on
figuring
out
the
nuts
and
bolts
of
that,
but
we're
really
excited
to
be
able
to
introduce
sort
of
a
paradigm
way
to
do
this.
It
won't
require
you
to
stand
up
an
additional
system
outside
of
helm
just
to
test
and
see
if
your
helmet
charts
are
in
fact
doing
what
you
want.
You
already
saw
the
the
monocular
UI
that
team
is
working
hard
on
bringing
a
unified
UI.
Where
you
can.
C
That'll
make
their
way
in,
but
I
know
some
of
you
in
here
saw
something
up
there
and
you
know
what
I
could
do
this
and
I
could
contribute
it.
We
would
love
to
see
you
guys
jump
in
there
and
help
us
out,
because
we
are
not
domain
experts
in
everything.
In
fact,
I
think
we
would
like
to
set
up
a
sprint
on
these,
maybe
tomorrow
yeah
so
Adnan
and
Vic
Vic.
You
want
to
raise
your
hand.
These
two
guys
are
the
the
owners
of
the
kubernetes
charts
repository
and
they
are.
C
C
Finally,
I
do
want
to
call
out
the
rest
of
the
core
contributors
and
I
actually
wrote
them
down,
because
I'm
scared
to
death
I'm
going
to
forget
somebody
but
Brian's
back
there.
Jack
is
up
here.
Adam
is
up
here
Miguel
my
it
was
way
back
there
in
the
back.
Yeah
Vic
is
right
up
there
in
Vejle.
I.
Think
it's
in
another
session
right
now
and
Sebastian
is
right.
C
There,
who's,
Sebastian
and
and
lucky
I
know
is
also
in
another
session
right
now,
but
these
guys
together,
these
people
have
really
formed
sort
of
the
core
of
the
contributions,
this
some
of
them
by
doing
massive
amounts
of
coding,
some
by
shepherding
through
charts
and
LG,
teaming
other
people's
work.
I
just
wanted
to
give
them
a
public
acknowledgement.
Thank
everybody
so
much
for
it.
Thank
you
guys
for
coming
today.
I
hope,
I
see
you
guys
all
in
the
slack
channel.
C
E
B
C
Far
as
the
client
side
only
version
went,
we
built
that
first,
so
the
home
classic
project,
which
you
can
still
find
out
there,
we
initially
our
first
version-
was
inspired
mainly
by
homebrew.
So
in
the
homebrew
model
you
know
you
pull
all
the
data
down
locally
and
then
you
run
your
install
that
so
the
original
version
of
helm
was
a
client
only
one.
C
We
switched
to
the
server
one
primarily
to
allow
teams
to
sort
of
collaborate
because
the
client-side
one,
then
the
client
became
the
the
absolute
source
for
all
the
data,
and
you
know
the
the
breaking
things
on
Friday.
Then
nobody
can
address
the
problem
until
I
come
back
on
Monday,
so
we
helm
to
really.
Our
shift
was
to
build
the
tiller
part
that
sat
in
the
cluster,
so
that
teams
could
collaborate
better.
Many
people
do
like
the
original
model
and
so
helm
classic
is
still
out
there
and
will
always
be
out
there
and
is
in
maintenance.
F
C
It
okay,
so
so
the
question
was
about
the
the
way
you
change
cluster
context.
I
assume
by
that
you
mean
you've,
got
one
kubernetes
cluster
running
here
another
over
there.
So
basically
we
use
the
coop
CTL
configuration
files
as
our
first
as
our
preferred
source
of
reference
information.
So
if
you're
running
in
cluster
it'll
drop
down
to
the
environment
variables,
so
whatever
you're
pointing
to
in
your
coop
config
file
is
what
helm
will
pick
up,
but
there
are
then
parameters
where
you
can
override
it
and
say
you
know.
C
D
C
Yeah,
so
the
question
is
about
what
kind
of
really
how
how
scriptable
is.
This
thing
would
be
a
good
way
of
capturing
it
right.
So
the
helm,
template
language
supports
a
pretty
broad
number
of
control
structures
and
things
like
that.
But
of
course
that
rendering
is
all
going
to
happen.
You
push
the
chart
from
the
client
up
to
tiller.
Tiller
will
render
everything
and
then
push
it
into
the
cluster.
C
So
now
what
about
those
cases
where
you
push
something
into
the
cluster
and
the
pod
stands
up
and
that's
when
it
needs
to
find
out
some
information
right.
So
the
way
we've
been
approaching,
that
is
to
rely
on
some
of
the
things
kubernetes
has
already
given
us
init
containers,
and
some
of
that
we
also
have
a
hook
system
that
we
actually
did
add
where
you
can
say:
I
want
to
run
these
jobs
or
these
pods
beforehand
and
generate
some
data
and
put
them
in
a
config
map,
for
example.
C
G
B
That's
that's
can
tell
or
creates
a
config
map
every
time
you
install
a
chart,
and
so
the
config
map
is
the
actual
state
of
your
release
and
it
holds
all
the
information.
So
if
your
tiller
pod
goes
away
and
it
spins
back
up
for
some
reason,
it'll
still
have
all
the
state
because
it
will
reference
the
config
Maps
that
it
owns
in
the
cube
system.
Namespace.
C
C
I'm
just
going
to
keep
the
microphone
I'm
going
to
start
answering,
asking
and
answering
the
questions.
So
the
question
is
you
know?
How
do
you
mess
this
with
things
that
are
already
in
production?
There
I
have
only
bad
news.
We
have
not
solved
the
problem
where
you
can
say:
hey
here's,
my
environment
extract
a
chart
from
it
and
then
let's
track
it
from
here
on
I
would
love
to
see
that
tool,
because
I
think
it
would
be
very
powerful
because
you've
got
most
of
the
core
information
already.