►
From YouTube: Helm Chart Patterns [I] - Vic Iglesias, Google
Description
Helm Chart Patterns [I] - Vic Iglesias, Google
You will learn about the patterns and best practices we have learned from reviewing and maintaining the charts in the public Helm Charts repo. You will learn how to make your charts reproducible, scalable, flexible, configurable, and composable.
About Vic Iglesias
Vic Iglesias is a Staff Solutions Architect at Google with years of experience in both on-premise and in-cloud workload deployment, orchestration and management. He is a maintainer of the Kubernetes Charts repo and focuses on helping customers adopt Container Engine reliably, securely, and at scale.
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
A
Yes,
that
is
good.
That
is
good.
Now
you
can
all
sit
down
and
promptly
fall
asleep
howdy.
My
name
is
Vic
I'm,
a
cloud
solutions
architect
with
Google
I
live
out
of
Santa
Barbara
California.
Some
contact
info
for
me
it'll,
be
on
the
last
slide.
If
you
need
it
we're
here
to
talk
about,
you
know
what
we've
learned
from
the
helm,
charts,
repo
and
things
that
you
can
use
in
your
own
home
charts
to
make
them
more
flexible,
more
scalable,
just
better
for
your
users
in
general.
So
how
many
people
have
used
helm?
A
It's
a
lot,
how
many
people
use
helm
in
production?
How
many
people
have
used
helm,
charts
from
the
charts,
repo
wow,
that's
amazing,
and
how
many
people
write
their
own
charts?
Yes,
sweet?
Okay,
you
guys
are
committed,
I
like
it
so
I
got
this
like
kubernetes
problem
I'm
like
into
it
I
get
into
kubernetes
mode,
and
it
just
makes
me
go
all
crazy.
A
A
Then
we're
gonna
go
through
what
the
charts
repo
is,
why
we
started
it
and
that
kind
of
thing
and
then
talk
a
little
bit
about
the
important
pieces
of
charts
and
then
a
couple
tips
and
tricks
that
we've
seen
in
some
of
the
the
charts
that
we
have
in
the
chart,
repo
some
of
the
patterns
that
we've
seen
emerge
for
making
them
better
charts
for
your
users.
So
how
am
101
helm
is
a
tool
for
installing
and
managing
your
kubernetes
applications.
A
So
it
helps
you
with
the
lifecycle
management
of
an
application
within
kubernetes
and
we'll
talk
about
what
that
is.
It
has
two
parts
you
install
a
client
on
your
laptop
and
then
inside
your
kubernetes
cluster.
You
have
a
server
called
the
tiller
and
that
manages
kind
of
receiving
the
commands
and
doing
the
actual
work
of
deploying
manifests
into
kubernetes.
So
how?
A
So
what
is
a
kubernetes
application?
This
is
something
that's
kind
of
been
tough
to
figure
out
over
time
like
what
is
an
application,
and
generally
it's
gonna
be
a
set
of
things
that
you
install
into
kubernetes.
They
may
relate
to
each
other.
You
may
have
a
config
map
that
needs
to
be
attached
to
a
pod
may
have
a
volume
that
needs
to
be
attached
to
a
pod
and
then
a
pod
that
needs
to
be
let
balanced
by
a
service.
So
these
things
are
kind
of
all
interrelated.
A
A
They
don't
have
to
worry
about
the
internals
of
how
your
services
are
mapped
to
each
other
or
how
your
deployments
work
or
what
M
variables
you're
using
you
can
provide
them
kind
of
a
higher
level,
abstraction
API
via
the
values
file
or
the
configuration
of
your
home
chart.
So
you
deploy
your
helm
charts
and
then
you
deploy
a
new
version
and
that's
awesome
and
you're
stoked
on
your
new
version.
And
then
you
hit
a
problem
and
you're
like
wait.
A
We
need
to
rollback
so
in
this
case
home
helps
you
because
it
can
roll
back
everything
as
a
whole.
Right,
you
don't
just
roll
back
the
config
map,
you
don't
just
roll
back
the
deployment
you
roll
everything
back
together
and
get
back
to
the
original
state
you
had
before,
and
then
you
can
roll
out
version
3
and
keep
going
along
the
way.
So
I've
talked
about
templating,
it's
a
templating,
probably
50
times
already
in
helm.
A
You
use
go
templates
and
those
are
passed
into
your
your
values
passed
into
your
templates
that
you
can
kind
of
parse
out
some
some
values
there.
So,
for
example,
here
I
have
this
replicas
that
I've
provided
to
my
users,
where
they
can
change
the
number
of
replicas
by
using
the
values
file.
You
can
also
use
similar
names
for
things.
So
if
your
service
is
called,
you
know
Vicks
or
if
your
application
was
called
Vicks
app
I
can
call
my
service
Vicks
app
and
my
deployment
Vicks
app
with
just
these.
A
A
Maybe
you
need
to
base64
encode
a
config
file
for
some
reason
or
another,
so
this
gives
you
a
lot
of
flexibility
as
far
as
how
you're
writing
your
your
configs
and
your
services
stuff,
like
that,
so
the
charts
repo
kubernetes
slash,
charts
on
github,
it's
the
centralized
repository
where
we're
hosting
and
maintaining
the
charts
that
you
as
a
community
have
provided
how
many
people
have
interacted
with
the
charts
repo
in
here
awesome.
We
love
you!
A
Thank
you
and
it's
basically
just
a
place
where
we
can
get
together
and
take
our
knowledge
of
applications
and
how
you
configure
them
and
how
you
use
them,
and
so
that
everybody
has
at
least
a
starting
point.
I,
don't
necessarily
expect
that
you're
gonna
have
you
know,
production
workload
running
off
of
one
of
our
helm
charts,
but
maybe
it's
the
first
step
T
for
you
to
get
there.
A
We
provide
continuous
integration,
so
we
have
a
testing
subsystem
that
will
run
your
chart
and
make
sure
that
it
passes
the
linter
make
sure
it
actually
installs
properly
make
sure
that
pods
go
running.
And
then
we
have
code
review
provided
by
some
of
our
maintainer
x'.
But
do
we
have
any
maintainer
x'
in
here
right
now
other
than
my?
A
We
have
one
right
here:
that's
it
he
what
in
the
back
too,
so
that
they
caused
all
the
problems
and
it's
the
default
repository
when
you
install
help
so
the
stable
repository
when
you
install
the
helm,
client
or
you
do
a
home
search.
Those
are
the
charts
that
we
have
there.
So
why
did
we
do
this?
I?
A
We
wanted
a
place
where
we
could
just
all
work
together
on
the
same
thing
and
make
it
as
easy
as
possible
to
have
a
starting
point
for
those
common
apps.
So
there
was
a
bunch
of
things.
Then
we
added
one
more
thing:
creating
a
new
standard,
but
this
time
I
think
it's
it's
stuck
around.
We
have
a
hundred
and
thirty
charts
now,
a
year
ago,
I
think
we
had
nine
or
something
like
that.
So
it's
it's
grown,
pretty
pretty
fast.
We've
merged
2000
PRS
over
that
period.
A
So
that's
it
improvements
to
charts
and
new
charts
and
we
have
over
100
contributors,
which
are
you
know
the
folks
that
you
saw
raise
their
hands,
which
is
super
awesome.
It's
not
slowing
down
in
any
way
shape
or
form
we're
still
kind
of
hammering
through
lots
of
PRS.
About
six
months
ago
we
had
like
this
high
watermark
of
about
a
hundred
PRS
being
like.
We
need
to
drop
everything
and
figure
out
what's
going
on
here
now.
The
high
watermark
is
two
hundred
I
expect
another
three
months.
A
It's
going
to
be
three
hundred
we'd
love
to
have
more
maintainer.
So,
if
you're
interested
to
keep
those
watermarks
down,
but
it's
it's
growing
really
fast
and
it's
awesome.
We
have
ten
thousand
unique
visitors
every
week
to
the
charts,
github
repository
just
a
lot
of
people
and
the
number
of
Forks.
A
We
can
no
longer
see
our
fork
graph,
which
is
a
really
great
display,
but
we
do
have
the
number-
and
this
is
cool
for
me-
not
not
like
it's
a
vanity
metric,
but
this
means
that
people
are
actually
taking
the
code
and
doing
something
with
it.
Maybe
they're
changing
it,
maybe
they're
contributing
back,
but
at
least
they
have
that
starting
point
and
we're
kind
of
the
known
place
to
go
for
those
starting
points
for
these
applications
go.
So
next.
A
We'll
move
on
to
kind
of
the
chart
structure
and
things
that
are
important
with
the
files
in
charts,
so
the
chart
structure
there's
a
certain
set
of
files
that
make
up
a
chart.
One
of
the
most
important
ones
is
the
chart
yamo,
and
this
is
the
metadata
about
what
your
application
is.
What
thing
is
this
installing?
So
here's
the
example
from
the
spinnaker
chart.
You
have
an
API
version,
that's
the
API
version
of
the
chart
right
now
we're
only
at
v1.
A
You
have
the
description,
which
is
a
human
readable
way
to
describe
what
you're
actually
installing
this
shows
up
in
the
helm,
search
output,
for
example.
You
have
the
name
of
your
chart,
then
you
have
two
version
strings
here.
So
version
is
the
version
of
the
chart
and
app
version
is
what
the
application
version
is.
So,
for
example,
here
I
have
version
1,
1,
0
of
spinnaker
and
the
chart
version.
The
iteration
of
this
deployment
mechanism
is
0
3.8.
A
This
is
important.
We've
had
some
chart,
maintainer
x',
try
to
pin
these
things
and
what
you
find
is
over
time.
Your
application
doesn't
change
as
much
as
your
chart
you're,
adding
things
that
make
your
chart
more
flexible
or
a
bug
fix
in
just
your
chart
and
then
you're,
adding
you
know,
bumping
versions.
My
goodness
here
was
one
of
our
first
ones
to
try
that
with
the
Prometheus
chart,
I
think
he
went
about
three
months
with
that
methodology
and
then
we
just
decided
to
break
from
it.
A
You
have
a
website
here,
which
is
just
a
URL
to
point
people
to
but
I
think.
The
more
important
thing
to
have
in
your
chart,
yamo
is
the
sources.
Where
can
people
go
to
rebuild
the
pieces
of
this?
So,
for
example,
usually
people
put
the
github
of
the
actual
project
itself
a
lot
of
the
the
charts
that
we
have
our
open
source.
So
where
is
the
github
for
that
thing?
And
then
did
you
build
like
a
custom
image?
A
We
have
a
custom
image
point
people
to
that
docker
file,
so
they
can
maybe
customize
it
and
move
on
from
there.
You
have
an
icon,
which
is
mostly
just
a
visualization
tool.
We
have
cube
apps
calm,
which
uses
this
to
show
your
your
chart
icon,
and
then
we
have
the
maintainer
so
it
the
name
here
is
actually
the
github
ID
of
that
user
and
their
email.
So
as
maintainer
as
we
look
at
this,
and
if
there's
something
that's
a
little
bit
over
something,
that's
not
just
a
trivial
bug-fix,
we
try
to
ping.
A
Those
maintained
errs
to
make
sure
that
this
is
a
good
change
that
they
want
in
their
chart.
Now
this
is
the
values
file.
The
values
file
is
basically
the
API
that
you're
providing
to
your
users
of
your
chart.
That's
the
the
way
to
look
at
it.
Changes
to
this
that
are
backwards
incompatible.
You
should
probably
bump
the
major
version
of
your
chart
to
show
people
that
you
are
breaking
the
API.
A
Here's
where
you
can
abstract
away
some
of
the
complexity
of
what
you've
done
in
the
kubernetes
deployment
methodology
and
and
make
it
simpler
for
your
users
to
configure
things.
You
can
add
comments.
Generally
people
comment
in
how
to
do
certain
things.
For
example,
here
this
is
again
the
spinnaker
chart
I
allow
people
to
change
the
images
that
are
deployed
for
each
component
and
also,
for
example,
allow
them
to
configure
how
mail
works
it's
disabled
by
default,
but
I
have
just
the
the
parameters
that
they
need
and
they
don't
have
to
go.
A
Look
in
the
spinnaker
configuration
to
figure
out
what
things
to
configure
there
so
with
the
the
values
file
generally,
what
you'll
find
is
you're
on
this
spectrum
or
it
just
charts
in
general,
your
start
out
kind
of
relatively
reproducible.
There's
not
that
much
that
can
change,
but
as
people
use
your
chart
and
your
application
they'll
find
that
you're
going
more
and
more
to
be
more
flexible,
which
means
that
you're
opening
up
some
trap
doors
for
people
to
change
things
that
maybe
you
can.
A
Another
thing
that
we
have
in
in
a
chart
is
the
requirements
Yamma,
and
this
is
what
defines
what
other
charts
you
may
want
to
deploy
alongside
your
chart.
So
in
general,
what
we've
seen
is.
This
is
used
for
data
stores,
you
have
a
Postgres
dependency
of
a
Redis
dependency
or
anything
like
that,
and
the
version
here
can
also
be
a
cember.
So
I
can
say
you
know,
give
me
anything
in
the
0
for
X
series
of
the
Redis
chart
and
you'll
update
to
those
things.
A
Next,
you
have
the
notes
file,
and
this
is
one
of
my
favorite
kind
of
experiences
in
helm
or
using
helm.
Is
that
the
notes
you
can
as
a
chart
maintainer
chart
creator?
You
can
provide
to
your
users
a
getting
started
experience
via
the
notes
file
and
the
notes
file
is
again
a
templated
file
that
is
template
it
out
and
spit
out
after
your
chart
is
installed.
A
So
when
you
do
how
I'm
install
chart
they'll
spit
out
this
template
a
thing
that
can
maybe
tell
your
users
what
to
do
next
right,
instead
of
just
saying
yes,
it's
installed
tell
them
pay
here's
how
you
connect
to
it.
Here's
how
you
get
to
the
web
UI!
Here's
if
you're
going
to
use
it
inside
of
your
cluster!
Here's
the
service
name,
that's
currently
configured!
So
it's
it's
just
getting
people
that
much
closer
to
being
kind
of
interacting
with
your
application.
A
So
now
we're
gonna
go
look
at
some
tricks
that
you
can
use
inside
of
your
charts
and
things
that
you
can
look
at
to
kind
of
make
your
charts
a
little
bit
more
flexible
or
a
bit
a
little
bit
more
useful.
I
think
the
first
thing
that
most
people
should
be
using
is
when
they're
first
gonna
create
their
charts
to
use
the
helm,
create
command.
How
many
people
have
used
home,
create
or
use
it
regularly?
A
Yeah,
that's
good,
so
home
create
scaffolds
out
a
chart,
an
example
chart
for
you,
so
you
can
start
with
this
and
then
tweak
it
from
there.
The
actual
application
that
it
deploys
is
just
an
engine
X
web
server
with
no
config,
but
it
just
shows
you
the
things,
the
element
that
you're
gonna
have
to
have
and
we
try
to
keep
that
up
to
date
with
our
best
practices.
So
if
you're
gonna
get
something
into
the
charts
repo,
it's
best
to
start
with
this
and
then
you
know,
you've
got
something
that's
going
to
match
our
expectations.
A
Another
thing
you
can
do
is
to
add
starters.
So,
let's
say
in
your
organization,
you
have
certain
patterns
or
certain
things
that
you
want
to
have
in
each
Hjelm
chart.
You
can
create
your
own
starter
templates
and
then
pass
them
to
the
helm,
create
command
with
the
dash
dash
starter
flag
and
have
that
be
the
scaffolded
thing
that
gets
put
out
there
for
users
of
your
charts
so
super
useful.
One
example
is
you
know
you
have
a
certain
paradigm
for
how
you
do
stateful
sets
or
for
your
services.
A
You
have
a
certain
way
that
you
want
to
do
your
deployment
rollouts
or
your
deployment
strategy
right.
You
want
to
do
max
unavailable,
always
so
just
set
that
for
folks,
so
that
they
have
it
by
default.
Maybe
you
have
a
certain
way
that
your
values
files
are
laid
out.
This
is
where
you
can
put
all
of
those
semantics
in
place.
A
This
is
a
trick
that
I
really
like
I've
used
it
in
a
couple.
Charts
and
I
know
that
some
charts
use
it
as
well,
and
it's
slightly
complicated,
but
it's
a
very
useful
tool.
So
what
I
want
to
do
here
is
I
want
to
be
able
to
change
a
config
map
in
my
application
in
my
chart
and
have
it
automatically
update
my
deployment.
So
what
I'm
gonna
do
here
is
add
an
annotation
to
the
deployment
and
I'm
gonna
use
sprig
functions
to
put
in
a
checksum
of
my
configuration.
A
So
here
you
can
see
I
have
they
I'm
printing,
a
full
templated
config
file
that
spinnaker
dash
config
yamo
and
then
getting
the
checksum
of
that
that
contents,
when
I
get
that
I'm
putting
that
into
an
annotation.
So
every
time
the
config
file
changes,
it's
gonna
roll
out
a
new
deployment
because
that
annotation
change,
so
it's
kind
of
a
little
trick
to
get
config
maps
to
automatically
update
some
applications
will
just
detect
that
the
config
map
has
changed
and
reload
themselves.
But
some
aren't
that
smart.
A
Another
super
useful
tool
that
I've
used
in
some
of
the
less
than
cloud
native
kind
of
applications
that
I've
had
to
install
is
the
helm
hooks
so
home.
Let's
you
do
some
things
as
it
releases
or
as
it
installs
or
deletes
your
your
application.
So
here
I'm
doing
a
post
install
step.
So
let's
say
you
deploy
an
application
and
you
just
need
to
like
run
one
command
at
the
end
like,
for
example,
and
this
one.
A
So
as
menials
coming
up,
this
thing
is
gonna
fail
and
kubernetes
gonna
keep
restarting
it
until
it
just
succeeds
once
and
then
it's
done
so
now,
I've
gotten
those
kind
of
posts
in
it
kind
of
steps
automated
through
my
chart.
The
types
of
hooks
that
you
have
available
are
pre
and
post,
install
pre
and
post
delete
and
pre
and
post
upgrade
and
pre
and
post
rollback.
So
you
have
a
lot
of
control
over
your
application
lifecycle.
A
This
one
is
pretty
useful.
Something
we
saw
I.
Think
first,
in
the
the
prometheus
chart
is
to
allow
people
to
basically
provide
you
with
a
volume
for
data,
and
so
you
let
them
provide
you
with
the
name
of
an
existing
persistent
volume
claim
and
if
they
provide
that
to
you,
you
use
that,
rather
than
one
that
you
would
have
originally
provisioned
in
the
chart.
So
you
might
have
the
the
need
to
decouple
your
chart
lifecycle
from
your
data
lifecycle.
A
A
Another
thing
that
we've
seen
often
is
web.
Apps,
being
you
know,
submit
it
to
the
charts
repo
and
with
those
web
apps.
We
generally
ask
that
they
allow
someone
to
add
an
ingress
really
easily
like
pre-configure
this
ingress,
you
wire
up
the
service
import
already
for
them.
You
can
have
you
know
the
ability
for
them
to
list
house
names,
or
maybe
a
TLS
secret-
to
include
in
there,
but
try
to
have
that
as
part
of
your
API.
A
If
you
are
a
web
app
because
most
things
will
want
to
do
an
ingress
another
side
of
configuring,
an
ingress
for
four
people
is
to
have
the
annotations
be
available
as
a
thing
that
you
pass
in
to
to
those
ingress
'as
so
annotations
on
ingress
--is
that
are
really
common
are,
for
example,
like
which
type
of
ingress
controller
to
use.
You
might
use
the
nginx
ingress
controller.
You
might
use
like
the
cloud
default
one,
but
you
as
a
chart
maintainer
should
not
dictate
that
necessarily
another
one.
That's
seen
commonly
is
like
cube.
A
Lego
they'll
get
my
TLS
certs.
You
don't
want
to
necessarily
manage
that.
You
don't
want
to
over.
You
know
abstract
that
just
let
them
add
their
own
annotations.
Annotations
are
kind
of
like
Pandora's
box.
Anyway,
all
kinds
of
crazy
stuff
gets
done
with
them,
so
I
tend
to
just
let
people
add
those
crazy
annotations
there.
A
This
one
is
near
and
dear
to
my
heart:
Michele
Nirali
wrote
this
home
testing
and
we
like
we're
like
please.
We
need
helm
tests
because,
as
maintain
errs,
we
want
to
have
the
ability
for
the
chart
maintainer
to
send
us
a
test
that
says
this
thing
actually
works.
So
now
you
can
do
home
tests
from
the
the
home
client
after
a
release
has
been
installed
and
it
will
run
us
step,
and
so
here
I
add
an
annotation
saying
that
I
want
this
test
to
run
and
I
expect
it
to
succeed
here.
A
I'm
running
a
pod
and
it's
just
gonna
run
a
bash
script
like
like
most
things.
The
world
is
tied
together
via
bash
scripts,
so
here
this
is
the
actual
test.
That's
in
the
Jenkins
chart,
not
the
craziest
thing
in
the
world,
but
it
lets
us
know
that,
like
we
can
at
least
get
a
two
hundred
from
the
login
page
right.
It's
something
simple
like
this:
that
as
chart
maintainer,
is
we
can
bank
on
to
think
that
you
know
your
charts
actually
doing
something
useful
in
your
in
your
organization.
A
You
may
have
much
more
in-depth
testing
and
you
can
run
this
at
any
time.
So
maybe
you
just
run
this
periodically.
You
have
some
checks
that
you
want
to
run
as
part
of
automation
that
runs
every
two
hours
or
something
like
that,
and
it
just
spot
checks
things
it's
also
templated,
so
it's
gonna
be
able
to
use
all
those
values
that
you've
passed
around
as
well.
So
it's
it's
a
useful
hook
to
have.
A
We
hope
to
have
more
tests
in
in
the
chart
Street,
but
I.
Think
right
now,
out
of
the
130
less
than
10%
have
tests,
which
is
pretty
painful.
That
means
we
have
to
go
and
launch
it
and
make
sure
that
it
actually
does
anything
useful
and
that
the
PR
that
we're
accepting
doesn't
actually
break
core
functionality.
For
that.
For
that
chart,
this
is
one
that
I
think
is
really
useful,
but
is
also
one
of
these
trapdoors
that
people
kind
of
once
they
go
down
this
route.
You
kind
of
have
they're
on
their
own.
A
Some
people
will
want
to
if
you
have
a
config
file
for
your
application,
rather
than
have
you
template
it
out,
for
example,
for
an
engine
X
config
or
something
like
that
they
want
to
just
provide
their
own,
so
some
charts
have
done.
You
know,
custom
config
map
parameter
that
allows
you
to
overwrite
or
provide
your
own
config
map.
This
is
like
on
the
opposite
side
of
the
reproducibility
spectrum.
A
I
mean
you're
not
really
going
to
be
able
to
reproduce
what
they
did
basically
ever,
but
it
does
open
up
more
use
cases
for
your
chart,
which
I
think
is
useful.
Another
thing
we've
seen
in
the
engine,
X
controller
chart
is
not
just
having
them
overwrite
the
config
map,
but
to
provide
the
name
of
a
config
map
so
can
be,
can
be
done
a
few
different
ways.
A
One
thing
we've
done
recently
is
to
have
all
of
the
helper
templates
in
home:
charts
be
named
spaced,
so
a
helper
template.
If
you
look
at
a
chart,
you'll
probably
have
underscore
helpers
file
in
there,
and
this
is
where
you
can
define
little
chunks
of
snippets
of
code
that
you
want
to
actually
inject
in
different
places
in
your
in
your
chart.
But
you
don't
want
to
have
a
big
stack
of
code
sitting
there,
and
so
these
templates
can
be
generally
for,
like
names
of
things
in
kubernetes,
you
have
to
have
things
be
a
certain
length.
A
So
if
people
name
things
in
a
strange
way,
you
want
to
truncate
that
to
something
that's
supported
within
kubernetes.
So
that's
what
we
do
with
names
and
full
names
name
spacing
it
allows
us.
If
you
have
this
chart
as
a
sub
chart.
For
example,
you
can
always
reference
the
Jenkins
name
by
Jenkins
name
across
the
board.
You
don't
have
to
think
about
how
it's
actually
nested
or
anything
like
this.
One
is
also
really
useful,
and
so
conditional
dependencies
is
a
feature
of
the
requirements
file.
A
lot
of
charts.
A
We
expect
charts
to
actually
provide
something
useful
out
of
the
box
with
without
any
changes
to
the
values,
but
you
may
have
some
data
stores,
for
example,
that
we
deploy
for
you
as
the
chart
that
you
already
have
somewhere
else.
So
one
example
is
the
spinnaker
chart
actually
does
needs
object,
storage,
so
we
use
Mineo
by
default,
because
we
can
prevent
a
vision
that
within
anybodies
cluster
and
we
get
out
of
the
box
experience
that's
good
within
cloud
providers,
though
you
want
to
use
their
object
storage.
A
So
in
Google
cloud
we
have
Google
Cloud
storage
and
in
Amazon
you
might
have
s3,
so
you
want
might
want
to
disable
the
menial
deployment
and
you
can
do
that
with
a
value
called
Mineo
dot
enabled.
So
if
you
set
that
to
false,
we
will
no
longer
deploy
the
Mineo
chart
for
you,
and
you
are
on
your
own
to
configure
the
s3
configuration.
A
Again,
on
the
kind
of
opposite
end
of
the
spectrum,
these
are
some
where
the
trap
doors
that
that
we've
seen
I
mean
chart
maintainer
is
provide
to
their
users,
is
the
using
the
yeah
malfunction
in
sprig,
which
will
basically
take
a
chunk
of
the
values
file
and
just
inject
it
as
yamo
into
some
other
template
that
you
have
so
we're.
This
is
extremely
useful
and
kind
of
necessary
is
with
like
node,
selectors
and
Toleration,
specifically,
because
these
are
gonna
be
practically
bespoke.
A
Cross
everybody's
deployment,
you're,
not
gonna,
know
how
they
label
their
deployment
or
their
nodes,
or
anything
like
that.
So
just
give
them
the
ability
to
add
node
selectors
on
their
own
in
the
values
file
and
then
propagate
those
through
to
the
deployments
you
have.
Similarly,
with
toleration
x',
we
also
have
seen
this
relatively
often
with
resources.
Some
people
want
to
have
requests
and
limits.
Some
people
only
want
limits.
You
know
just
give
them
the
ability
to
set
those.
However,
they
want
through
the
values
file
and
pass
that
directly
into
your
pod,
your
pod
specs.
A
So
those
are
some
of
the
tips
and
tricks
we
have
a
hundred
and
thirty
charts
out
there.
So
if
you
have
an
location
that
you
want
to
deploy,
go
look
at
the
chart.
Sweet
bun,
see
if
there's
something
that's
similar
to
it
from
a
kind
of
deployment
mechanism
standpoint
and
try
to
figure
out
if
you
can
kind
of
take
some
tips
from
some
of
the
charts
that
already
exist
for
us
in
the
charts
repo.
A
The
next
thing
we're
gonna
try
to
do
is:
give
the
chart
maintainer
x'
more
power
over
their
actual
chart
and
merging
their
own
PRS.
That's
gonna
help
us
with
our
velocity,
so
we
don't
hit
that
300
PR
mark.
That
is
almost
inevitable
at
this
point,
and
also
to
delegate
the
responsibility
to
maybe
even
a
different
get
repo.
So
if
you
want
to
host
your
your
git
repo
or
your
chart
somewhere
else,
but
still
get
it
into
the
stable
chart
repository,
we
want
to
be
able
to
facilitate
that
as
well.
A
Now
that
we're
at
a
hundred
and
thirty
charts
it's
time
to
look
at
how
many
of
those
are
actually
updated
or
useful
and
are
still
maintained.
I
think
we'll
get
at
least
a
fifteen
percent
attrition
rate
on
those
once
we
really
start
looking
at
it
and
just
remove
those
from
the
tree
or
put
them
in
a
folder
somewhere
like
deprecated
or
something
like
that,
and
if
someone
wants
to
bring
them
back
to
life,
that's
great,
maybe
we'll
call
it
zombie
and
and
then
you
know
we
can.
We
can
go
forward
with
it.
A
The
other
thing
is
more
functional
tests
for
charts.
There's
an
idea
being
thrown
around
that
will
require
a
functional
test,
or
else
we
won't
merge
anymore
PRS
in
that
I.
Don't
know
if
that
makes
you
scared
or
not,
but
it
should
be
scary
for
any
maintainer
x',
but
it
the
the
functional
test,
is
really
important
to
us.
It's
something
that
gives
us
more
comfort
in
merging
things
and
will
give
us
better
velocity
as
charming
tenors.