►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Deep Dive into Helm - Scott Rigby, Codeacademy & Paul Czarkowski, Pivotal
Helm v3 went GA in 2019 and the community was abuzz with excitement over the removal of Tiller. There’s more to Helm v3 than just the removal of Tiller though! In this session we’ll learn about the new features of Helm v3 and the changes and new architectures to support them. We’ll discuss the changes to the CLI and the underlying library and the subsequent improvements to usability. We’ll look at library charts and the new client/server security models. We’ll finish with a discussion on migrating charts from v2 to v3.
https://sched.co/Zx4K
A
B
A
B
B
Helm3,
we'll
give
you
a
few
notable
announcements,
we'll
be
talking
about
important
things
that
you
probably
want
to
know
that
helm
does
functionality
wise
and
the
tools
in
the
community
with
the
wider
ecosystem,
we're
going
to
cover
helm
security
and
finally,
ways
that
you
can
get
involved
with
the
home
community.
So
in
case
you
missed
it,
the
current
version
of
helm
is
helm3.
B
A
You're
on
helm2,
it
is
way
past
time
to
upgrade
helm.
3
is
nearly
a
year
old
and
has
made
some
major
changes.
Things
we'll
be
talking
about
will
be
focused
on
home
3..
It
is
easy
to
upgrade
from
helm2
to
helm3,
both
on
your
laptop,
but
also
in
your
kubernetes
cluster
helm2
charts
will
continue
to
work
in
helm3.
We
are
backwards
compatible
there,
so
all
of
your
existing
charts
will
continue
to
function.
A
Most
of
the
differences
are
architectural
and
in
the
software
itself
the
big
difference,
of
course,
that
everyone
likes
to
applaud
at
is.
There
is
no
more
tiller,
so
we
have
a
helm23
plug-in
which
is
provided
by
the
helm
community,
which
does
most
of
the
work.
You
just
need
to
make
a
choice
if
you
want
to
follow
the
strangler
pattern
and
slowly
replace
releases
or
if
you
want
to
do
like
a
full
in-place,
one-shot
upgrade.
So
this
is
the
helm,
2-3
plug-in.
It's
really
simple.
A
You
can
see
from
this
screen
home
two
to
three
convert.
Postgres
will
upgrade
your
postgres
release
to
helm3,
but
rather
than
just
showing
you
this,
why
don't
we
actually
kick
off
and
give
you
a
demonstration
to
show
you
just
how
easy
it
is
to
upgrade
a
cluster
that
has
a
bunch
of
home
releases
installed
on
it,
so
helm,
3
or
just
helm
has
been
out
for
at
least
a
year
now,
and
so
it's
time
we
just
let
go
of
helm
2
right.
A
I
don't
want
to
even
talk
about
helm2
and
so
the
way
we
do
that
is
we
get
everyone
to
migrate
from
helm
to
up
to
helm3.
So
as
a
community,
we
have
put
together
documentation,
blog
posts
and
tooling
to
help
you
migrate
from
helm,
v2
to
v3
and
get
tiller
out
of
your
life.
I'm
going
to
take
you
straight
to
a
command
prompt
and
demonstrate
just
how
easy
it
is.
I
have
helm,
2
and
helm
3
as
separate
binary,
so
we're
going
to
run
home
to
a
version.
A
A
So,
let's
do
a
dry-run
conversion
of
one
of
our
releases
and
we
do
that
by
doing
helm,
2,
2,
3,
convert
we'll
choose
discourse
and
we'll
do
a
dry
run,
and
you
can
see
that
happen
really
quick.
I
feel
confident
now
that
I
can
run
this
across
my
cluster
across
all
of
my
releases,
so
we're
getting
the
helm2
output
and
we're
passing
that
through
to
helm23,
convert.
A
A
B
We'd
like
to
thank
everyone
who
got
us
here,
specifically
the
helmcore
maintainers
maintainers
of
helm,
charts,
many
of
whom
have
worked
tirelessly
to
support
the
community
charts
for
so
long.
Also,
the
helm,
various
helm
project
maintainers.
There
are
projects
within
the
helm
organization,
including
chart
museum,
the
helm
hub,
which
is
based
on
monocular,
also
maintained
by
the
helm,
team,
helm,
plugins
and
also
the
helm,
org
maintainers,
who
help
with
governance
and
things
like
that
and,
finally,
the
rest
of
the
community.
B
A
Due
to
unprecedented
events,
this
year
we
have
extended
the
deprecation
timeline
for
helm2
and
also
for
the
stable
and
incubator
charts.
Repo
bug
fixes
were
extended
until
august
13th
this
year
and
will
be
officially
deprecated
on
november
30
this
year.
So
those
are
important
dates
to
remember
and
we'll
help
you
plan,
for
when
you
do
your
helm
to
the
helm3
upgrade.
B
And
you
might
be
asking
yourself:
where
are
the
stable
and
incubator
community
charts
going
to
be
hosted
now,
if
they're,
if
they're
to
be
deprecated?
How
are
your
projects
going
to
continue
to
function
if
you
require
those
community
charts
are
now
moving
from
the
previous,
stable
and
incubator
repos
to
a
more
distributed
model.
Those
distributed
chart
repos
are
all
aggregated
in
the
same
way.
So,
if
you're
worried
about
how
am
I
going
to
find
my
charts,
it's
easy.
B
You
can
find
them
now,
aggregated
at
helmhub
and
artifact
hub,
artifact
hub
is
likely
the
successor
to
helmhub,
and
so
many
helm.
Repos
are
publishing
to
both.
At
the
moment
the
actual
source
code
for
the
charts
primarily
is
being
adopted
by
the
maintainers
of
the
software.
That's
installed
by
those
charts.
B
This
issue
here
on
the
screen
and
you'll
see
a
link
later
at
the
end
of
this
talk
can
help
you
keep
track
of
the
progress
of
moving
those
charts
from
these
repos
to
their
eventual
homes,
and
if
there
are
charts
that
haven't
been
moved-
and
you
really
care
about
this-
you
work
for
an
organization
or
you're
an
individual
and
want
to
group
together
with
others
who
want
to
help,
take
ownership
of
that
chart.
Then
please
do
so
open
an
issue
and
we
can
work
through
that
process
together.
B
Additionally,
there's
an
excellent
collection
of
curated
charts
by
friends
of
helm,
bitnami,
who
have
worked
also
tirelessly
on
the
community
charts
in
the
past.
Those
charts
have
been
in
the
bitnami
repo
for
quite
a
while.
They
were
just
mirrored
in
the
community
charts,
and
now
they
are
the
source
themselves,
so
you
can
still
see
those
where
they
were
and
now
you
can
make
prs
directly
against
those
repos.
B
This
is
helping
the
charts
maintainers
to
spend
more
of
their
time
working
on
the
tooling
around
helm,
the
best
practices
guides,
and
so
on
that
we've
been
doing
such
as
charts,
testing
and
charts
releaser.
Tooling,
this
can
be
used
for
community
members
who
want
to
host
your
own
distributed,
helm
repos
that
are
aggregated
by
the
helm
hub.
We
just
mentioned.
A
So
chart
testing
is
a
tool
that
automates
the
testing
of
your
helm,
charts
inside
of
git
repositories.
So
when
you
push
a
change
to
a
helm,
chart
up
to
get
it
will
detect,
which
charts
have
changed
inside
of
your
repo
and
then
it
will
perform
linting
and
test.
Just
those
charts
chart
releaser
will
release
charts
to
a
self-hosted
helm
chart
repository.
A
B
Chart
testing
is
what
we
use
in
community
charts
today.
Chart
releaser
is
not
being
used
in
community
charts,
primarily
for
legacy
reasons,
but
many
chart
repos
are
using
it
today
and
it's
recommended
to
use.
We
also
have
github
actions
for
helm
charts.
These
actions
essentially
wrap
what
paul
was
just
describing
so
that
if
you
are
using
github
for
you,
the
source
code
for
your
charts,
pretty
much
all
of
this
is
automated
for
you.
You
just
have
to
do
the
configuration
and
then
they
have
very
same
defaults
as
well.
A
All
right-
and
we
can
grab
this
url
here
and
open
up
our
favorite
web
browser,
so
we've
created
the
pull
request
and
you
can
see
we
now
have
an
actions,
kicked
off
lint
and
test
charts.
So
all
you
need
to
do
in
order
to
enable
this
in
your
charts.
Repo
is
copy,
this
github
workflows,
so
we
have
one
workflow
for
lint
and
test
and
you
can
see
it's
pulling
our
chart
testing
action
and
it
will
actually
create
a
kind
cluster
and
install
your
chart.
A
And
then
we
have
our
release
and
this
will
happen
when
we're
merged
into
our
main
branch
and
that
will
run
our
chart
releaser
action.
It
will
actually
create
the
package.
It
will
create
a
release
in
github
and
upload
that
package
to
that
release.
It
will
then
update
the
index.yaml
file
in
your
gh
pages
branch.
A
A
And
we'll
see
the
second
action
kicking
off
and
this
is
the
release
action
and
so
it's
going
ahead.
It's
saying:
there's
a
new
chart,
it's
packaging
up
and
it's
uploading
it,
and
it
is
done
so
now
here
under
releases,
you
can
see
we
have
a
new
release
and
this
is
named
for
the
chart
and
it
has
our
chart
package.
A
A
A
B
B
B
The
new
yeah
paul,
so
this
is
one
of
the
exciting
features
that
helm3
provides
as
well.
Many
people
have
asked:
is
there
a
way
to
validate
values
and
there
have
been
various
hacks
and
tools
to
help
make
that
happen,
at
least
within
an
individual
organization,
so
that
developers
can
have
consistency
and
minimize
errors?
The
helm
team
introduced
the
ability
to
validate
values
passed
to
a
chart
built
into
helm
itself
now,
so
you
can
use
json
schema
to
help
make
sure
that
happens.
A
B
A
A
We
are
waiting
for
the
upstream
oci
community
to
stabilize
the
apis
before
we
move
on
from
calling
it
experimental
in
helm,
so
it
is
disabled
by
default
and
you
can
enable
it
by
setting
the
environment
variable
helm,
experimental
oci
if
you're
interested
in
oci,
you
can
run
helmhelp,
chart
and
helm
help
registry
and
find
out
details
on
how
to
use
it,
and
you
can
read
josh's
proposal
on
how
we
support
oci
from
the
above
link
scott.
Now
that
there's
no
more
tiller,
how
do
we
actually
store?
What
releases
are
installed
on
a
cluster.
B
A
We've
also
made
changes
to
how
we
deal
with
crd,
think
of
them
as
kernel
level
things
as
opposed
to
most
applications
that
charts
install,
which
are
user
space
so
because
crds
are
so
crucial
and
so
critical
to
the
kubernetes
cluster.
While
we
will
install
crds,
we
don't
want
to
upgrade
or
delete
them
by
default
because
that
can
really
mess
with
your
cluster.
If
you
don't
want
to
install
crds
at
all,
you
can
skip
them
with
skipped
crds.
A
B
A
If
you
do
really
want
to
install
crds
with
helm,
you
can
template
those
crds
and
put
them
in
the
helm
templates
directory,
and
you
can
even
do
that
in
a
dependency
chart
and
pull
it
in
as
a
dependency.
Our
best
practice
is
to
not
install
crds
as
part
of
the
installation
of
an
applicant
scott.
Tell
us
what's
changed
in
the
osdk.
B
All
of
the
code
has
been
restructured
for
a
much
better
developer
experience
before.
If
you
had
ever
tried
to
write
your
own
code
that
leveraged
helm
under
the
hood,
you
may
have
noticed
that
you
had
to
rewrite
a
lot
of
what
the
cli
did
now.
The
helm
cli
consumes
the
exact
same
sdk
that
your
application
would
consume.
B
If
you
create
one
up
from
scratch
yourself
and
the
packages
that
you
can
look
at
is
make
sure
to
look
at
the
action
package,
there's
the
chart
and
chart
util
package
and
finally,
the
wrapping
cli
and
all
of
the
sub
packages
around
that
just
digging
through
the
code.
I
think
it's
very
readable
and
you'll
have
a
pleasant
experience.
A
And
a
perfect
example
of
where
we
can
see
improvements
with
that
is
the
chart
releaser
currently
execs
out
to
helm
package,
whereas
now
we
can
actually
call
the
package
chart
library
within
helm
through
the
sdk
and
do
it
directly
inside
of
our
application
instead
of
shelling
out,
and
so
here's
an
example
of
how
easy
it
is
to
use.
This
is
a
really
simple
go
application
that
is
going
to
list
the
helm
releases
in
a
particular
namespace.
Now
this
is
one
of
my
favorite
new
features,
the
post
renderer.
A
For
example,
if
you
just
want
to
add
labels
or
annotations,
you
could
call
out
to
hashicorp
vault
to
fill
out
secrets
or
collect
keys.
You
could
even
perform
a
security
audit
before
you
ever
hit
the
cluster,
so
we
have
plenty
of
documentation
on
how
to
do
it,
but
rather
than
boring
with
more
details,
why
don't
we
just
show
you
a
demo?
A
So
let's
take
a
look
at
the
post
renderer
I've
already
created
some
assets
to
make
things
quick.
So
let's
have
a
look.
What
we
have?
We
have
our
post
renderer
script
and
then
we're
using
ytt.
So
we
have
some
ytt
files.
So
quick,
look
at
the
post
renderer,
it's
pretty
simple:
it's
a
bash
script!
It
takes
in
standard
in
from
helm,
which
will
be
the
rendered
templates.
A
It
will
pass
them
through
ytt
and
then
it
will
output
standard
out,
which
will
then
go
back
into
helm
and
that
will
become
what
is
sent
to
kubernetes
on
a
say,
a
helm,
install.
Let's
take
a
look
at
our
ytt
files,
so
we
have
a
wordpress
password.
This
is
a
ytt
file
that
is
going
to
look
for
the
secret
that
contains
the
wordpress
password
and
it's
going
to
overlay
a
different
password
on
top
of
it
that
maybe
we're
fetching
from
hashicorp
vault.
A
A
A
B
Yeah,
I'd
love
to
mention
one
thing:
one
of
the
big
benefits
that
I
see
for
the
future
of
distributed
helm
charts
is
that
they
can
stay
simpler
now
and
still
allow
people
to
fulfill
their
edge
cases
without
having
to
have
pull
requests
that
create,
if
else,
trees
for
every
single
use
case
under
the
sun.
That
increases
complexity
and
I
think,
as
many
people
have
seen
in
community
charts,
it
can
lead
to
spaghetti
code.
This
helps
to
keep
them
cleaner,
potentially.
B
So
I'm
looking
forward
to
seeing
that
in
the
future,
so
now
we'd
like
to
introduce
you
to
a
few
tools
that
extend
helm.
There
are
a
lot
more
than
this.
This
is
just
a
short
list,
but
this
gives
you
an
idea
of
some
of
the
common
tools
and
also
what's
possible.
One
of
the
from
my
point
of
view.
Indispensable
plugins
is
the
helm,
diff
plugin.
B
This
works
for
any
client,
both
for
the
end
user,
when
you're
imperatively,
running
helm
commands
and
for
let's
say
even
during
the
cicd
process,
where
you
want
to
look
back
and
see.
Oh,
what
actually
changed
when
I
did
an
application
of
a
new
release.
Helmdiff
can
automatically
spit
out
that
diff
for
you
and
show
you.
This
is
exactly
what
changed
between
releases.
You
can
also
use
it
to
debug.
A
B
A
A
Your
own
and
then
there's
conf
test,
which
is
a
great
way
to
test
your
helm,
charts
against
opa
rules
to
make
sure
that
your
helm
charts
are
going
to
follow
your
best
practices,
as
described
in
tools
like
open
policy
agent
before
they're
ever
installed
to
your
class
c.
So
you
can
have
that
at
the
ci
stage
of
your
ci
cd
of
your
home
charts
themselves.
A
So
if
you
want
to
solve
a
particular
edge
case
that
you
have,
you
should
write
your
own
tool,
open
source
it,
and
maybe
next
year,
up
on
stage
we'll
be
talking
about
it
and
now
for
everyone's
favorite
topic:
security
with
tiller
removed.
The
main
thing
you
need
to
be
concerned
about
the
provenance
of
your
charts.
B
B
B
B
B
A
B
There
is
an
ongoing
effort,
as
I
mentioned
earlier,
to
migrate
or
move
or
adopt
the
community
charts
into
their
eventual
forever
home.
I
had
posted
the
link.
We
had
posted
the
link
earlier
and
please
see
it
here
again.
Please
get
involved
in
this
effort.
This
is
very
important
because
the
helm
charts
are
what
make
helm
so
valuable.
A
You
can
also
use
the
chart,
testing
and
chart
release
of
tools
and
github
actions
to
host
your
own
charts,
so
that
makes
it
incredibly
easy
to
adopt
community
charts,
whether
it's
you
as
a
person
who
cares
about
a
particular
application
or
you
as
someone
who
works
for
a
company
that
writes
a
particular
piece
of
software.
We
make
it
very
easy
for
you.
B
A
Have
to
be
a
hardcore,
helm,
chart
maintainer
or
a
hardcore
go
programmer
to
be
a
valuable
member
of
the
helm
community,
we're
always
looking
for
help
with
the
documentation,
with
writing
blog
posts.
Basically,
whatever
you're
passionate
about
we
want
to
have
you
come
and
help
us
make
helm
better
in
whatever
way,
you
feel
comfortable
scott.
How
about
you
summarize
what
we've
just
talked
about.
B
B
It
did
that
sound
convincing
I
mean
it
sure,
did
okay
and,
as
promised
here
is
the
list
of
helpful
links.
Here
is
a
link
to
the
slide
deck.
So
if
you
are
seeing
this
in
some
channel
that
doesn't
give
you
that
link
that
should
help
you
get
to
the
deck
itself,
where
you
can
follow
our
links
that
we've
peppered
throughout
the
presentation
and
gain
further
information,
there's
a
link
to
the
helm
docs.