►
From YouTube: Intro: Helm - Michelle Noorali & Matt Fisher, Microsoft
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
Intro: Helm - Michelle Noorali & Matt Fisher, Microsoft
In this session, we will introduce the basics of the CNCF Helm project. Helm is a Kubernetes package manager and it allows you to install and manages packages of Kubernetes configuration called Charts. Charts provide a way to deploy configurable, out-of-the-box applications and even package your own applications for Kubernetes. We will walk through how to get started with Helm and how to package your own applications as Charts. Helm was first introduced in 2015 and has since grown to meet the needs of its own rich ecosystem. We'll also discuss how Helm has evolved, why, and lessons we've learned along the way.
https://sched.co/N4ke
A
B
B
B
B
So
I
was
part
of
a
company
called
op
demand
and
when
we
were
eventually
acquired
by
Engine
Yard,
we
had
a
first
off-site
in
Florida
was
the
first
one
and
we
were
both
realizing
that
both
of
us
were
the
youngest
engineers
of
each
of
our
companies
were
trying
to
like
compare
who's,
the
youngest
between
the
two
of
us,
because
it's
like
a
little
bit
of
competition
and
she
was
a
little
peeved
because
I
eked
her
out
by
just
a
few
months
at
that
time.
So
I
became
the
youngest
engineer
at
the
engine
yard,
so
yeah.
B
A
A
Okay,
so
when
we
were
doing
when
we
were
first
starting
out
with
kubernetes
and
containers
were
like
we're,
gonna
build
a
container
pass
and
we
were
reap
lat
forming
it
on
top
of
kubernetes
and
that's
how
we
learned
about
kubernetes
and
that's
actually
how
helm
came
to
be,
and
Matt
was
one
of
the
original
authors.
He
also
brings
all
of
the
personality
basically
to
our
team.
So
all
the
Taylor
Swift
stuff
that
we
do
in
our
release
notes
is
from
Matt
and
I'm
the
holiday
beverage
stuff.
B
Thanks
to
my
fiance
YUM,
due
to
close
proximity,
but
yes
so
we're
here
to
talk
mostly
about
helm,
though
we're
not
about
to
talk
about
the
Matt
Michele
show
so
we'd
love
to
talk
about
ourselves.
But
let's
talk
about
helm
so
helm
is
a
package
manager
for
kubernetes.
So
let's
try
and
break
down
what
exactly
that
means
in
terms
of
like,
rather
than
the
buzzwords.
Let's
actually
talk
about
the
concepts
behind
what
it
means
to
be
a
package
manager
for
kubernetes.
B
So
essentially,
what
a
package
manager
is
trying
to
do
is
to
make
a
set
of
objects
or
a
set
of
things
that
all
co-locate
or
make
sense
together
as
one
unit.
So
you
can
ship
that
eventually
to
customers
and
you
can
make
that
available
for
them.
So,
for
example
like
WordPress
or
for
when
we
were
first
working
on
Deus
Deus
workflow
was
platform-as-a-service
and
we
were
trying
to
make
that
available
to
customers,
so
they
can
install
it
on
their
clusters
and
make
that
as
a
product.
B
A
So
there
are
three
core
concepts
to
helm
so
know
about
the
chart,
the
values
and
the
release,
so
the
chart
is
actually
the
package
that
we
install.
The
bulk
of
the
chart
is
so
this
is
a
directory
structure.
The
bulk
of
it
is
your
kubernetes
manifests,
and
so
these
resource
definitions
they
can
be
template
adorned
on
templated.
We
support
bloat,
go
templating,
there's
also
configuration
in
your
chart.
So
if
you
want
to
like
override
parameters
in
your
in
your
templates,
you
can
specify
those
in
this
file.
A
We
call
values
mo
file
and
then
the
rest
of
your
chart
is
just
metadata
and
documentation
to
explain
what
your
chart
dies,
what
its
name
inversion
is
and
who
maintains
it
and
all
of
that
information.
So
this
is
what
a
chart
that
yellow
file
looks
like
and,
as
you
can
see,
you
have
the
name
and
version
info.
You
have
some
keywords
in
a
description.
This
simple
manifest
file
and
then
the
values
that
you
know
file
is
like
I
said
before
the
configuration
for
your
chart.
A
This
is
expressed
as
yellow
values
are
higher
goal,
as
you
can
see,
so
you
can
nest
related
values
together
and
a
release
is
what
you
get
when
you
install
a
chart
into
your
cluster.
So
an
instance
of
an
installation
of
a
chart
in
your
cluster
is
called
a
release
and
a
release
is
a
record
of
what
you
actually
installed.
So
this
can
manifest
itself
as
a
config
map
by
default
in
your
cluster,
and
so
the
config
map
will
have
all
this
information
about
what
you
just
installed
and
like
Matt
was
mentioning
earlier.
A
That
might
be
a
lot
of
different
components,
a
lot
of
different
resource
types
that
work
together
to
actually
make
your
application
work.
So
you
can
have
a
nice
list
of
that
in
your
config
map
or
if
you
have
sensitive
information,
you
might
want
to
store
those
releases
as
secrets
and
as
of
2.14,
you
can
also
store
your
release,
information
in
Postgres,
so
we
have
support
for
that.
A
You
use
a
release
or
that's
like
the
thing
that
you
point
to
when
you
want
to
manage
the
lifecycle
of
your
application
in
kubernetes,
so
you
can
do
like
a
home.
Upgrade
you
can
do
a
home,
install
roll
back
delete
all
by
specifying
which
release
you
want
to
like
modify
so
chart
and
values.
You
install
that
and
you
get
a
release
so
to
get
started
with
home.
For
those
of
you
who
are
new,
you
can
download
home
off
the
github
releases
page.
You
can
either
create
a
chart
using
the
helm,
create
command.
A
It's
like
a
shortcut
for
creating
a
simple
chart.
You
can
test
out
or
you
can
grab
an
example
chart
from
hub
columns
on
a
sage.
You
can
download
that
you
can
check
out
what
files
are
in
there.
You
probably
don't
want
to
just
install
something
from
the
internet
without
looking
at
it
and
see
your
clusters,
so
you
might
want
to
inspect
that
a
little
bit
and
then
you
can
install
your
application
or
your
chart
and
get
a
release
and
then
like
play
with
that
release.
A
B
A
B
A
B
B
3
I
should
have
to
14
0,
but
the
demo
will
still
work
with
2
12
3,
so
I
will
show
so
what
I've
done
prior
to
actually
installing
all
this
as
I
did
a
helm
in
it
and
what
helman
it
does
is
it
will
install
tiller
on
to
your
cluster,
make
that
available.
So
then,
you
can
actually
get
that
component.
That
will
track
your
releases
and
when
you
can
do
the
installs
so
on
for
this
demonstration,
I
have
a
jacuz,
brunetti
service
or
aks
and
I
have
helm
installed
on
there.
B
So
to
get
started
using
helm,
we
will
do
let's
try
and
actually
create
a
chart
for
the
very
first
time.
Let's
take
a
look
at
that
a
little
bit
and
then
I'll
actually
pull
down
a
chart.
Repository
chart
from
the
stable
chart
repository
just
play
with
WordPress,
maybe
and
just
kind
of
show,
the
difference
between
what
it
looks
like
from
the
first
try,
and
it
will
actually
see
how
it
looks
like
when
you
get
an
actual
package
installed
on
there.
So
to
start
playing
with
helm,
let's
remove
the
demo,
it
was
my
chart.
B
I
think
it
was
so
we'll
do
a
helm,
create
so
helm
create
basically
just
scaffolds
a
brand
new
chart
for
you,
and
it
gives
you
some
good
best
practices
out
of
the
gate
to
start
playing
with
making
your
own
chart.
So
we'll
do
helmet,
create
my
chart
and
then
we'll
take
a
look
at
that
in
vs
code.
Just
to
see
how
that
actually
looks
so
we
can
see
in
here.
We've
got
my
chart
and
we'll
that
a
little
bit
bigger
for
everyone.
B
So
like
Michelle
mentioned
before
we
have
the
chart
gamal,
we
have
the
values
we
have
a
Helmick
nor
for
ignoring
files
that
they
get
included
into
the
chart.
So
they
can
just
not
be
packaged
with
your
applications.
So
a
couple
of
little
nice
things
here
and
there
and
there,
and
then
we
have
the
templates
themselves
that
we're
interested
mostly
so
we'll
take
a
look
at
the
chart
quickly
that
was
created
here.
So
we
get.
B
This
is
my
chart
version
1.0
film
chart
for
kubernetes,
so
we're
already
good
or
good
to
go,
and
then
we
actually
have
the
templates
that
Nick
generated
for
us-
and
this
is
the
core
of
what
helm
is
actually
installing.
So
again,
the
concept
of
helm
is
to
take
these
resources
or
these
templates
and
to
realize
what
an
application
will
look
like
in
the
real
world.
So
we
have
here.
In
this
example,
we
have
a
deployment,
we
have
an
ingress.
We
have
some
helper
functions
to
help
us
out
with
the
with
the
actual
templating.
B
If
we
need
to
have
some
convenience
functions
and
then
there's
some
notes.
So
if
we
want
to
template
out
information
that
we
want
to
provide
to
the
end-user
when
we're
done
packaging
this
up,
so
when
they
install
this
package,
they
actually
get
some
information
to
say.
Here's!
Your
next
steps
so
really
helpful
information
here.
So
this
is
just
the
basic
one,
but
let's
actually
take
a
look
at
the
WordPress
one,
so
we'll
go
and
pull
out
WordPress
and
it'll
just
on
target.
B
So
we
can
make
a
dependency
on
another
person's
chart
if
we
need
to,
for
example,
someone
else
has
created
something
that
is
useful
for
our
package
and
we
want
to
separate
the
business
logic
between
how
you'd
want
to
set
up
your
database
versus
how
you
want
to
set
up
your
application.
So
here
we
want
to
take
a
include
Maria
DB
inside
our
application
and
then
in
the
WordPress
chart
we
set
it
up.
B
B
B
B
But
again,
the
whole
key
point
here
is:
if
I'm,
a
consumer
of
this
application,
all
I
had
to
do
is
helm,
install
WordPress
and
I.
Have
this
application
up
and
running
on
kubernetes
and
I
didn't
have
to
understand
the
underlying
resources
or
anything
like
that
all
I
just
had
to
do.
Was
here's
WordPress
give
it
some
configuration
if
I
want
to
send
it
in
some
way
and
I'm
off
to
the
races
so
and
then
here's
the
notes
at
the
end
of
it?
So
we
got
here's
a
wordpress
URL.
If
you
want
to
get
the.
B
B
So,
let's
talk
a
little
bit
about
how
helm
overall
has
helped
the
community
succeed
in
some
of
these
ways.
So
now
with
the
helm
community,
it's
not
just
the
two
of
us
just
working
on
this
project
and
there's
actually
a
massive
community
around
us
that
has
been
supporting
and
working
on
this
providing
feedback
and
doing
this
so
the
CNC
F.
We
have
now
been
inducted
into
the
CNC
F
as
a
last
year.
I
think
it
was
as
an
incubator
project
and
there
has
been
a
ton
of
contributions
from
the
entire
community
on
helm.
B
So
there's
the
helm
CLI
itself,
which
is
github,
helm,
helm
that
one
has
just
only
488
contributors,
which
is
massive
number
for
a
small
team
working
on
this,
but
there's
also
the
helm,
charts
community.
That's
another
sub
project.
There's
chart
museum,
there's
the
chart
testing
project.
They
all
have
a
huge
amount
of
contributors
that
are
helping
out
to
the
community,
so
over
2000
contribution
or
contributors,
uniquely
to
the
helm,
charts
repository,
providing
and
maintaining
those
charts
and
working
on
those
as
well.
Just
some
metrics
and
numbers
we've
got
collectively
between
all
the
slack
channels.
B
We've
got
about
12,000
members,
8000
of
them
alone
in
the
helm,
users,
and
then
the
others
are
collectively
between
like
chart
museum,
the
helm,
dev
channel
for
specifically
around
the
helm,
development
and
project
planning
and
those
kind
of
things,
and
then
we
have
public
dev
calls
we'd
love
to
see
new
faces
come
along
to
the
dev
or
development
calls.
Those
are
just
simply.
We
come
together
every
week
at
9:30,
locals
/,
9:30
a.m.
B
Pacific
time,
not
local
time
here
in
Spain,
but
what
we
talk
about
are
just
like
some
things
will
be
going
around
in
the
last
week
any
discussion
items
that
we
bring
on
the
agenda
of
talking
about
like,
for
example,
the
helm
summit
has
been
going
on.
So
we've
been
talking
about
logistics
recently
talking
about
helm,
3
talking
about
ongoing
development
or
bugs
in
helm,
2,
so
a
great
place.
If
you're
interested
in
hearing
what
the
core
contributors
are
working
on
during
the
week,
that's
a
great
place
to
go
and
talk
and
get
involved.
B
The
other
thing
as
well
is
the
governance
of
the
helm
project.
It's
not
just
the
CLI.
It's
a
huge
group
of
a
ton
of
people,
so
we
want
to
make
sure
that
the
projects
will
be
stable
and
we'll
work
together
and
we'll
be
able
to
sustain
itself
and
the
way
that
we're
trying
to
do
this
is
we
have
a
governance
model
that
is
split
into
two
different
levels.
B
We
have
the
org
maintainer
z--,
which
oversees
the
entire
helm
organization
and
all
the
projects
and
they're
just
doing
high-level
responsibilities
and
then
there's
the
project
maintainer
z--,
which
are
focused
on
doing
the
day-to-day
work,
getting
the
releases
outgoing
and
do
the
project
planning
and
all
that
kind
of
stuff.
So,
for
example,
the
org
maintainer
z--
will
typically
do
code
of
conduct
violations
in
the
helm
or
so
we're
making
sure
that
were
an
inclusive
community.
B
Any
security
embargoes
for
the
projects
I
think
we
recently
had
a
security
embargo
that
happened
a
month
or
two
ago,
and
sometimes
those
security
embargoes
will
go
across
products
on
the
helm
project
so
or
just
the
helm,
CLI
chart
museum
and
a
couple
of
other
ones.
So
the
org
maintainer
is
kind
of
keep
that
conversation
across
the
different
projects
and
then
financial
decisions
around
like
what
do
we
want
to
use
for
CI?
If,
if
the
charts
testing
project
is
interested
in
hosting
their
stuff
somewhere,
then
we
can
talk
about
those
conversations.
B
A
Just
wanted
to
add
here,
like
home,
is
a
great
example,
I
think
of
a
small
project
that
started
off,
and
then
people
were
like,
oh
like
we
want
to
help
solve
this
problem
too,
and
then,
like
a
bunch
of
companies,
a
bunch
of
people
from
different
places,
individual
contributors
came
and
contributed
to
this
project,
and
it
just
like
through
I,
think
CN
CF
now
provides
a
lot
of
really
good
best
practices.
There's
a
template
for
how
you
can
get
started,
how
you
can
structure
your
repository.
A
If
you
have
a
cloud
native
project,
if
you're
you
know
in
your
individual
companies
and
you're
thinking.
Oh
like
this
is
something
I
want
to
collaborate
with
the
community
on
CN
CF
is
a
great
place
to
to
look
for
that
vendor-neutral
home,
and
you
can
definitely
find
like
these.
This
governance
requirement
and
kind
of
like
the
code
of
conduct
stuff,
there's
like
a
template,
a
layout
for
for
open
source
projects
and
and
best
practices
in
this
OSS
project.
A
B
So,
let's
talk
a
little
bit.
I
want
to
talk
just
a
little
bit
on
some
of
the
things
that
have
changed
over
time
as
we're
talking
about
as
this
transition
from
helm,
one
to
helm
to
helm.
Three
I
just
want
to
talk
about
some
of
the
background
context
of
some
things
that
we've
changed
over
time
and
as
well.
Just
give
some
like
introduction
on
like
the
development
of
what
helm
goes
on
day-to-day.
So
one
of
the
things
I
would
love
to
talk
about
and
I'm
happy
to
talk
about
this
any
time
is
helm
classic.
B
B
B
And
it
actually
never
reached
1.0
when
I
was
looking
at
their
releases,
but
it
was.
It
was
a
whirlwind
going
through
there
and
playing
with
helm
one
so
version
zero,
zero
one
of
helm.
The
very
first
release
was
released
on
November,
2nd
2015.
That
was
timed
with
the
first
cube
Connor.
Was
it
just
prior
I'm
assuming
just
prior
okay?
B
Some
of
the
concepts
around
here
are
very
different
from
what
it
is
from
modern
or
helm
or
even
helm.
3.
One
of
the
things
that
was
originally
introduced
for
the
concepts
were
all
the
same,
like
we
wanted
to
solve
the
same
problem
of
packaging,
an
application
making
consumable
for
users.
The
approach
that
we
took
was
much
different
than
what
it
looks
like
today.
B
Originally
it
used
like
a
Ruby
like
generator
pattern
for
generating
those
resources,
as
opposed
to
today's
thing,
which
was
go
templates
or
the
text
template
language
so
essentially
we'll
go
through
quickly
show
what
that
looks
like
we
eventually
removed
that,
and
we
went
from
a
client,
only
architecture
to
a
client-server
architecture
in
helm,
2
and
now
in
helm,
3
we're
going
back
to
a
client
architecture.
It's
a
little
bit
ironic,
don't
you
think,
but
helm
classic.
So
this
is
what
an
original
resource
looked
like.
B
It
doesn't
look
that
different
from
what
today
would
be,
but
you'll
notice
at
the
very
top.
Here
there
are
a
couple
of
top
level
or
frontmatter
gamal.
These
are
basically
like
generate
commands.
You
know
if
you've
ever
looked
at
like
go
generate
or
like
ruby
generators.
This
might
look
a
little
bit
familiar
to
you.
Basically,
what
it's
taking
is
the
input
of
this
file,
providing
some
values
that
you've
provided
in
another
file
and
then
it's
dumping
it
to
a
manifest
directory,
and
that's
your
final,
full
gamal
that
you'll
be
providing
as
a
manifest
to
kubernetes.
B
Instead
of
now,
which
is
like
all-in-one
the
go
template
the
rendering
engine
happens
on
tiller
and
then
it
gets
supplied
right
up
to
kubernetes.
So
it
was
all
done
client
side
a
little
bit,
janky
too,
because
you'll
notice,
this
said
command
was
the
second
one.
This
is
actually
pretty
common
in
a
lot
of
early
chart.
Well,
we
would
do
set
commenced
and
obviously
that
wouldn't
work
on
windows
or
different
platforms.
That
use
different
said
arguments.
B
So
it
worked,
but
there
were
some
limitations
with
the
project,
and
this
is
what
the
command
looked
like
when
you
were
first
doing
it.
So
you
would
do
you
would
fetch
your
resource
for
your
application
that
you
wanted
to
do,
which
was
just
creating
the
namespace
here
and
you
would
run
helm
generate
and
that
would
generate
those
manifests
or
resources,
and
you
do
it
install.
So
you
had
to
do
the
rendering
yourself
and
then
actually
install
what
the
results
were
into
your
cluster.
B
So
now
we
come
in
to
helm
two,
and
this
is
when
we
started
introducing.
We
were
working
with
Google
and
I.
Think
it
was
skip.
Box
was
another
project
which
was
they
got
eventually
acquired
by
bit
Nami,
and
we
were
working
together
on
introducing
some
of
the
projects
that
were
out
in
there
like.
There
was
Google's
deployment
manager
and
we
were
kind
of
working
and
merging
the
two
projects
into
one
to
try
and
solve
this
problem
for
everyone,
and
tiller
was
one
of
the
components
that
came
out
of
it
in
this
home
to
world.
B
It
allowed
us
to
live
his
life
inside
of
kubernetes
and
to
allow
this
rendering
to
happen
on
the
server
side
and
the
early
design
goals.
Helped
us
realize
some
use
cases
that
we're
really
interested
in
doing
one
of
them
could
have
been
like
web
hook,
a
vase
or
web
book
based
poles
or
web
hook
based
rendering
and
doing
it
install
so
it
could
have
been
like
a
very
early
version
of
an
operator,
perhaps
so
yeah
it
could
install
charts
from
a
web
hooker
kubernetes
event.
That
was
something
that
we
had
conceptualized
the
trade-off.
B
Talking
to
a
service
that
is
installing
something
on
your
behalf,
and
so
you
have
to
kind
of
finagle
that
service
in
order
to
figure
out.
Does
that?
Do
you
actually
want
to
be
installing
here
or
not
and
those
kind
of
things?
So
it
was
a
little
bit
problematic
for
security
engineers
to
lock
it
down
and
to
provide
the
right
access
controls
for
people
who
wanted
to
do
the
right
thing,
those
so
lm3.
B
This
is
the
introduction
and
we
removed
hit
tiller
and
when
we
were
doing
this
at
the
helm
summit,
I
believe
is
when
we
were
starting
to
hear
these
use
cases
and
examples
of
people
in
the
community
that
were
running,
helm
and
embedded
inside
of
tiller
and
I.
Think
actually
Nicole
was
one
of
the
first
people
who
were
showing
that
with
lost
remotes
and
she
was
showing
like
we
were
embedding
tiller
inside
of
our
engine
and
just
running
that
as
a
service.
B
So
you
didn't
actually
have
an
API
on
there,
but
you
were
running
as
your
local
user
and
being
able
to
do
audits
and
all
that
kind
of
stuff.
So
now,
with
the
removal
of
tiller,
tiller
acts
or
helm,
the
client
now
talks
directly
to
the
kubernetes
api.
It
does
the
rendering
locally
and
all
that
kind
of
like
how
helm
classic
is
to
do
right
a
little
bit
ironic
again,
but
it
radically
simplifies
the
security
model.
B
So
now,
when
you're
doing
an
install
you're
installing
as
you
you're,
not
installing
as
a
service
running
inside
of
the
cluster,
so
it
allows
security
engineers
to
go
to
you
and
say
we'll
walk
down
this
particular
user
and
can
only
install
in
certain
namespaces
are
installed
with
certain
parameters.
And
the
nice
thing
with
this
change
is
that
there
was
no
real
changes
required
to
decided
the
charts,
because
it
was
just
we're
all
doing
all
the
rendering
and
everything
else
and
providing
that
information
from
kubernetes.
B
A
So
package
repositories
are
where
charts
are
stored
and
I
really
wanted
to
talk
about
this,
because
I
helped
a
lot
with
the
home
to
package
repository
and
that's
like
grown
a
lot
since
then
sewing
home
classic
charts
were
stored
in
git
repositories,
so
you
just
have
like
a
git
repo
with
like
directories
and
each
directory
was
a
chart,
and
so
what
happened
was
we
were
changing
like
different?
We
were
bumping
versions
of
charts
and
the
chart.
A
We
saw
the
chart
demo
file,
we
saw
the
version
metadata
and
when
we
were
bumping
the
versions
it
was
really
hard
to
like
pull
down
the
correct
version
that
we
wanted.
We
could
only
really
pull
latest
if
we
wanted
to
pull
up
a
specific
version.
There
was
a
lot
of
magic
we
had
to
do.
It
was
really
difficult,
so
we
evolved
that
we
wanted
a
repository
model
that
was
distributed.
A
We
wanted
for
people
to
be
able
to
run
their
own
repositories
behind
some
security
mechanisms
so
that
enterprises
could
adopt
this,
but
we
also
wanted
a
simple
model
for
hosting
chart
repositories.
So
while
we
came
up
with
after
doing
a
lot
of
research,
specifically
I
did
a
lot
of
research
on
the
WN
repository
model.
We
came
up
with
this
idea
of
hey
a
chart.
Repository
can
be
this
basic
HTTP
web
server
with
an
index
Yemma
file
and
that
index
dot.
A
Llamó
file
will
contain
all
the
information
that
that
you
need
to
know
about
all
the
charts
that
are
inside
of
that
chart
repository,
including
all
the
keywords,
the
metadata,
the
versions
and
the
path
to
the
actual
tarball
itself,
which
was
the
chart
so
a
chart
when
you
hosted
in
the
package
repository
or
a
chart.
Repository
is
just
a
tarball
of
your
of
your
a
chart.
Directory
and
Fisher
is
actually
I
call
Matt
Fisher,
because
there's
like
a
million
Matt's,
but
Fisher
has
been
working
a
lot
on
our
experimental,
OCI
integration.
A
A
B
It's
also
now
owned
by
the
OCI
or
the
open
container
initiative,
and
what
they're
trying
to
solve,
along
with
the
the
actual
specification
of
a
docker
image,
is
a
distribution
specification
and
that
distribution
specification
is
about
distributing
artifacts
over
an
API
that
turns
into
the
docker
registry
project,
but
it
also
can
handle
more
than
just
the
actual
docker
images
themselves.
So
we've
been
playing
around
with
some
of
the
concepts
and
the
specification
itself
and
seeing
how
that
will
work.
B
So
we
have
some
experimental
work
inside
of
helm
3
to
play
around
with
it,
we're
still
supporting
chart
repositories
because
we
definitely
don't
want
to
migrate
the
entire
community
over
to
this
new
fandangled
thing
as
we're
trying
to
experiment
and
iterate
on
this.
So
we're
trying
to
run
these
two
experiments
in
parallel
and
see
how
it
goes.
So,
if
you
want
to
play
around
with
this
in
helm,
3
there
is
helm,
help,
chart
and
that'll
show
the
information
there
and
Jos
trellis
keys
done
fantastic
work
on
all
this
kind
of
stuff.
B
The
one
thing
I'll
point
out
is
that
it
currently
only
works
with
Azure
container
registry
and
docker
distribution,
simply
because
docker
hub
quai
and
all
the
other
registries
they
work
on
a
whitelist.
So
they
don't
want
you
hosting
artifacts
that
they
don't
necessarily
know
about,
because
they
want
to
provide
good
security
stories
that
want
to
provide
a
good
authentication
story.
B
If
you're
interested
in
applying
with
helm,
first
I
would
suggest
playing
with
helm
because
it's
recommended
in
ready
for
production
use
if
you're
interested
in
playing
with
some
of
the
new
fandangled
things
that
are
inside
of
helm,
3
like
OC,
I
registries,
some
of
the
other
stuff
that
is
available
in
the
blog
post,
there's
four
early
adopters
but
again
helm,
true
helm,
charts
we're
trying
to
support
them
in
helm,
3
and
we're
working
on
that
transition
story
over
from
the.
So,
if
you
want
to
get
involved,
there's
the
documentation,
there's
a
mailing
list.
B
You
can
go
on
to
the
kubernetes
slack
and
there's
the
helm
users,
those
the
helm,
dev
shark
museum
charts,
all
those
different
slack
channels
or
you
can
become
a
maintainer
yourself,
so
feel
free
to
come
and
talk
to
myself.
Michelle
there's
a
couple
of
core
maintained
errs
as
well
all
across
here
and
then
as
well.
We've
got
the
helm
summit.
Eu!
That's
coming
up
in
September
and
that's
gonna
be
hosted
in
Amsterdam,
and
currently
we
have
CFPs
they're
open,
like
Brian
had
mentioned
in
the
keynote
it's
May
31st
is
the
deadline.
B
A
You
want
to
learn
more.
There
are
lots
of
other
helm
talks,
just
some
search
for
helm
on
your
schedule
and
you'll
see
them.
Matt
and
Adam
are
gonna,
do
a
deep
dive
on
home
3
on
Thursday.
So
that's
also
one
to
see
Bridgette.
When
is
your
talk
Thursday
at
2
she's
also
gonna
go
into
home
3.
So
if
you're
interested
in
that
check
that
out.
Thank
you
so
much.
If
you
have
any
questions
we'll
just
be
hanging
out
around
here,
we
might
have
to
move
outside
because
we're
a
little
late.