►
Description
OpenShift Commons Briefing
Helm Operators Deep Dive
OLM for Helm People
Rob Szumski
Diane Mueller
Evan Cordell
A
A
Hello,
everybody
and
welcome
again
to
another
open
ship
Commons
briefing
this
time
again,
surprise,
surprise,
we're
talking
about
operators
and
this
time
we're
going
to
talk
a
little
bit
about
helm
and
helm
operators
and
Rob
some
skis
here
and
and
Andrew,
not
Andrew
Kevin
in
Cordele
as
well
as
has
joined
us
to
really
see
what
we
can
do
to
help.
People
who
are
working
in
helm,
understand,
operators
and
everything
they
need
to
know
so.
Rob.
Take
it
away.
B
Everyone
thanks
for
joining
as
Diane
said
I'm
joined
here
with
one
of
my
colleagues
Evan,
and
so
we're
gonna
talk
to
you
about
helm
operators
kind
of
when
you
should
use
one
why
you
should
use
one
other
things
you
need
to
know,
and
hopefully
you'll
find
that
really
interesting
I've
got
some
slides.
We
can
talk
about.
Don't
we
take
some
live
questions
for
folks
that
are
on
the
call
today,
maybe
board
us
have
some
general
discussions
dig
into
some
of
Evans
thoughts
on
this,
but
for
now
I'll
just
walk
through
some
of
these
slides.
B
B
It's
important
before
we
begin
just
to
talk
about
kind
of
adoption,
phases
of
applications
and
kubernetes,
and
it
kind
of
roughly
follows
when
some
of
these
features
were
put
into
kubernetes.
So
first,
you
know:
you've
got
your
stateless,
apps
super-easy
to
run
these
with
replica
sets
and
deployments,
and
you
know,
then
the
cube
community
rapidly
progresses
running
staple
apps.
This
is
where
we
have
staple
sets
for
running.
B
You
know
simple,
post
rest
deployments
and
things
like
that
and
under
the
hood
we
got
the
container
storage
interface
and
some
of
the
storage
mechanisms
that
you
know,
map
disks
around
as
pods
are
moving
around
the
cluster
and
then
finally,
we
got
to
running
full
distributed
systems
on
kubernetes,
and
this
involves
things
that
actually,
you
know,
aren't
abstractions
in
kubernetes
itself.
There's
no
object
for
data
rebalancing,
but
that's
super
important
for
running
these
distributed
databases.
B
Cube
has
some
primitives
for
auto
scaling
horizontally
and
vertically,
but
having
your
application
be
aware
of
that
when
to
do
that,
how
to
trigger
it
same
with
CMS
upgrades,
we've
got
some
things
in
deployments
and
staple
sets
for
doing
these.
You
know
rolling
updates.
But
how
do
you
make
the
application
aware?
How
do
you
do
health
checking
while
that's
happening
things
like
that
are
where
operators
come
in?
You
need
this
higher
level
primitive,
that's
kind
of
using
all
these
tools
that
we
have
to
run
these
systems.
B
B
This
auto-tuning,
auto
scaling
just
works,
the
way
that
it
should
has
all
the
logic
for
how
to
run
this
application
baked
into
it,
and
so
this
kind
of
there's
a
gammak
here
where
you
don't
have
to
kind
of
meet
every
single
need
based
on
what
your
application
is
doing
and
this
maturity
model
does
map
pretty
directly
to
some
of
the
SDK
flavors
that
we
have
today
in
our
operator
framework.
So
the
helm
SDK
is
towards
the
beginning
of
this
phase,
which
is
getting
install
and
upgrade
going.
B
This
is
you
know
where
helm
is
stamping
out
your
deployments
and
staple
sets,
and
your
config
Maps
and
secrets
and
services,
and
all
that
and
you
can
do
some
relatively
simple
upgrades.
If
you've
got
a
stateless
web,
app
going
from
version
native
version,
B
helm
can
get
you
there
pretty
easily
if
you've
got
deeper
needs.
If
you
need
to
do
some
of
the
things
like
I
was
talking
about.
B
Do
data
rebalancing
or
upgrade
one
tier
of
your
application
before
the
other
tier
of
the
application
of
wait
for
that
to
return
healthy,
you
knew
a
little
bit
of
a
higher
level
kind
of
language
there
to
do
that,
and
so
this
is
where
ansible
and
go
come
in
and
those
can
kind
of
address
this
entire
maturity
model.
You
can
read
more
about
this.
We've
got
some
blog
posts
on
it
and
I'm
happy
to
take
any
questions
on
it.
B
So
this
gets
us
to
Hell
itself,
not
even
talking
about
the
operator
for
a
second,
let's
just
break
down
what
helm
does
for
you,
so
helm
is
kind
of
two
main
parts.
There's
the
templating
part.
You
know
I've
got
a
this
high
level
configuration
that
I
want
to
give
you
and
then
I
want
to
go
through
and
play
all
my
kubernetes
objects,
the
create
the
services
create
the
deployments
if
I
say
replicas
equals
two.
B
Then
you
know
set
that
in
a
deployment,
but
maybe
you
need
to
generate
a
secret
so
that
these
things
can
talk
to
each
other
securely
whatever
it
is.
You
know
this
gets
templated
out
and
you
know
out
pops,
maybe
30
different
objects
that
are
representing
your
application,
and
so
you
interact
with
that
via
the
helm
CLI
to
kick
that
off
once
that
templating
has
happened.
There's
this
whole,
you
know
starting
all
of
those
things
on
the
cluster
itself,
so
there's
communication
with
your
kubernetes
cluster
and
that's
just
things
like
read
from
your
coop
configure.
B
If
you've
got
a
cluster
already
installed,
if
you
haven't
installed
tiller
on
it's,
the
CLI
can
do
that
for
you.
If
you've
already
got
tiller
running
its
talk
to
tiller
tiller.
Is
this
component
by
the
way
that
sits
in
your
cluster
that's
kind
of
route
on
the
cluster
and
it's
what
talks
to
all
of
your
namespaces
and
trades
all
of
these
objects?
B
And
then
every
time
you
do
a
new
release
of
helm.
You
know
it'll
run
through
those
templates
and
then
either
submit
those
objects
or
apply
changes
to
those
running
objects
and
that's
kind
of
how
the
ecosystem
works.
I
think
it's
useful
to
compare
and
contrast
this
with
how
the
helm
operator
and
the
SDK
works.
Basically,
we
get
a
kind
of
sense
of
when
you
can
use
this
and
how
it's
useful.
B
So
these
red
bits
are
some
of
the
changes
that
happen
when
you
use
the
helm
SDK
that
we
have
and
basically
we're
using
all
the
same
templating.
So
you
can
reuse
a
chart
if
you
give
it
the
same
inputs,
you'll
get
the
same
outputs.
We
actually
import
the
helm,
libraries
under
the
hood,
so
you're
getting
the
exact.
You
know
bit
for
bit
code
that
runs
home,
but
what
we
do
is,
instead
of
using
a
helm
CLI,
you
actually
map
your
template,
your
charge
to
a
custom
resource
definition.
B
This
is
the
extension
mechanism
in
kubernetes
so
that
you're
extending
kubernetes,
just
like
you,
have
your
built-in
deployments
replica
sets.
Now
you
can
have
a
new
MongoDB
object
or
a
fubar
web
app
object
and
that
is
managed
by
an
operator
and
what
the
operators
doing
is
actually
doing
this
templating
logic
for
you
just
like
you
would
use
the
helm
CLI
for
it,
but
you
can
just
use
the
kubernetes
CLI
once
you
have
your
operator
installed
on
the
cluster
once
it's
installed
on
a
cluster.
B
This
is
where
a
lot
of
the
changes
happen,
and
this
is
kind
of
where
we
see
like
the
tiller
model
and
helm
is
kind
of
insecure.
You
know
this
thing,
it's
a
listening
outside
of
the
cluster,
so
you
know
you're.
You
have
an
API
that
you're
exposing
and
then
this
demon
that's
running
on
the
cluster,
runs
as
root.
It's
got
access
to
all
your
namespaces,
all
your
secrets.
It
can
modify
your
nodes,
everything
cluster
and
we
don't
love
that.
B
So
what
we
do
is
this
operator
first
runs
into
cluster,
so
it
doesn't
have
to
be
exposed
outside.
So
any
mechanism
that
you
use
to
communicate
with
the
kubernetes
api
today,
how
its
secured
all
that
you
know
you're
just
using
that
standard
interface
and
you
can
lock
down
this
operator,
so
you
can
say
that
this
operator
is
only
you
know,
running
in
a
specific
name,
space
or
namespaces,
and
so
what
this
helm
template
can
do
is
kind
of
limited
to
that
namespace.
B
Then,
of
course,
it's
always
watching
for
changes.
So,
instead
of
having
to
manually,
invoke
the
helm,
CLI
and
do
a
rollouts
of
your
application,
what
you
do
is
just
edit
your
custom
resource,
edits
your
MongoDB
deployment
or
your
fubar
web
app
object,
and
if
you
change
config,
the
helm
operator
will
immediately
read
template
all
of
your
values
and
then
apply
those
onto
the
cluster.
So
you
get
this
very
cube
native
experience,
but
you're
reusing
your
st.
Helen
carts,
so
it's
kind
of
the
best
of
both
worlds.
B
Another
nice
benefit
of
this
is
because
the
operator
and
the
charge
are
baked
together.
You
actually
have
this
immutable
outcome
where
you
can
given
the
same
set
of
values
and
the
same
version
of
the
operator
installed.
You
know
you
always
received
the
same
output,
so
this
is
really
great
for
integrating
into
CI
systems
and
other
workflows
where
you
don't
want
to.
You
know,
have
this
kind
of
snowflake
thing
pop
out.
B
You
want
to
test
something
and
then
distribute
it
to
your
customers
or
your
different
environments
and
know
that
it's
going
to
bring
up
the
same
application
every
time.
So
that's
kind
of
a
little
overview
of
how
Elm
Operator
SDK
works
in
kind
of
under
the
hood.
If
you
will,
your
experience
is
very
not
much,
not
change.
You're
using
your
same
chart,
you
are
getting
a
more
secure
and
cube
native
way
to
interact
with
it,
though,
if
you're
good
in
what
this
looks
like
now,
that
we've
talked
about
kind
of
the
outcome
side
of
it.
B
So,
on
the
input
side,
if
you
were
gonna,
make
a
tomcat
operator
and
have
a
tomcat
chart,
this
is
all
you
have
to
do.
You
say
that
you're
gonna
build
a
an
operator
of
type
helm,
give
it
your
charts.
You
can
also
give
this.
You
know
a
file
location
and
things
like
that,
if
you
have
local
charts
and
what
this
will
do
is
top
out
both
that's
CRD,
the
object
that
represents
this
tomcat
installation
and
then
a
container
of
the
operator.
This
is
you
know
that
actual
code,
that's
going
to
run
in
your
cluster.
B
So
this
is
how
you
would
have
a
different
set
of
config
and
production
and
staging
or
a
different
set
of
versions
in
production
and
staging,
as
you
can
see
in
that
get
Tomcats
output
from
the
bottom.
As
you
can
see,
this
is
very
Kubb.
Native
feels
really
great
has
a
really
great
kind
of
reconfiguration
experience
and
you
can
always
go
and
instantiate
new
objects
at
your
leisure.
B
This
is
very
self-service
which
is
great
and
where
that
really
matters
is,
if
you
have
this
operator
running
on
the
cluster,
but
you
have
several
different
teams
that
all
you
know
consume
your
app
or
your
kind
of
micro
service
as
a
dependency.
They
can
easily
spin
up
a
copy
of
your
production
config,
which
is
really
great
for
running
in
there
CI
testing
and
that
type
of
thing
I
mean
feel
free
to
jump
in
here.
If
you've
got
any
comments
on
the
neatest
stuff
by
the
way.
C
Sure
there's
one
thing
I
would
add
to
this,
which
is
just
that
the
helm
operator
is
not
necessarily
a
tool
designed
to
take
any
home
chart
and
turn
it
into
an
operator,
but
rather
to
take
applications.
That
can
be
that
have
simple
life
cycles
and
can
be
represented
as
simple
home
charts
and
make
those
give
you
like
an
easy
way
to
make
an
operator
for
those
types
of
applications.
B
Yeah,
that's
a
really
great
point,
and
then
you
know
if
you
start
out
with
a
simple
application
and
you're
using
our
helm
operator,
and
then
you
want
kind
of
progress
of
that
maturity
curve.
There's
no
reason
that
you
can't
you
know
using
the
same
type
of
objects,
then
swap
out
the
technology
or
build
upon
it
slowly
over
time
to
make
it
smarter
and
smarter.
B
So
this
gets
into
the
meat
of
when
to
use
a
hella,
mock
writer
and
I
want
to
go
back
to
the
chart
that
we
looked
at
at
the
beginning
kind
of
the
types
of
applications
that
you
can
run
up
kubernetes,
and
it's
we're
talking
about
just
kind
of
how
Elm
works.
You
know
it
directly
uses
kubernetes
objects,
so
these
first
two
groups
of
applications,
stateless
and
staple
apps.
Using
you
know,
these
cube
objects
directly.
B
No
surprise
there
works
really
really
great
all
you're
doing
there
is,
you
know,
doing
the
effectively
a
coop
cuddle
apply
or
create
on
those
objects,
and
you
know
obviously
templating
the
mouth
so
doing
upgrades
of
these.
If
those
applications
are
resilient
to
just
you
know,
a
rolling
update
or
whatever
the
kubernetes
primitives
are
for
ruling
is
out.
Gonna
work
really
really
great
as
a
helm
operator
and
as
I've
been
mentioned.
These
are
you
know,
applications
that
have
fairly
simple
life
cycles.
B
Now,
where
you
run
into
trouble
with
this,
is
in
the
distributed
systems,
because
these
capabilities
aren't
built
into
Kubb.
But
there
isn't
a.
You
know
a
cube
object
that
helm
can
instantiate
to
do
data
rebalancing,
that's
something
that
needs
to
kind
of
live
it
a
little
bit
of
a
higher
level
abstraction
at
your
application
tier
and
that's
where
these
things
are
just
not
possible
to
put
into
a
helm
operator.
B
So
if
that
describes
you
our
application
or
where
you
think
you're
gonna
be
in
the
very
near
future,
you
know,
starting
with
a
helmet
writer,
it's
probably
not
the
best
choice
but
for
most
applications
or
if
you
can
decompose
your
application
into
a
tier
that
works
well
for
a
helm
operator.
You
know
you
can
always
have
these
operators
work
together.
I
think
that's
a
pretty
common
pattern
that
we'll
start
seeing,
especially
as
the
lifecycle
manager
knows
about
dependencies
between
operators.
So
you
can
represent.
B
B
Right
I
think
this
is
the
last
one
we
kind
of
bring
this
all
together
and
talk
about
what
this
actually
gets.
You
as
an
outcome
for,
if
you're,
an
enterprise
or
a
small
software
company
or
somebody
that
ship
software
out
to
other
consumers,
is
that
you
have
this
really
simple:
get
ops
workflow,
where
you've
got
all
of
your.
B
You
know
your
complex
logic
about
how
to
run
your
app
whatever
the
business
logic
is
for
that
all
representativeness
operator
such
that
when
you
were
testing
any
of
your
dependencies
and
revving
those
independently
you're,
really
only
interacting
with
these
high-level
objects.
So
imagine
a
CI
and
CT
workflow.
B
If
you're
distributing
this
software
out
to
another
team
or
to
a
customer
of
yours,
they
don't
need
to
know
about
any
of
this
stuff.
They
just
need
to
have
the
operator
installed
and
then
give
this
really
high
level
config.
So
this
is
easier
to
reason
about
in
a
pull
request.
If
you're
changing
some
of
these
values,
if
you're
pumping
different
versions
making
sure
everything
gets
tested,
it's
a
really
really
great
experience
for
doing
that.
Gaddafi,
workflow
I,
think
that's
all
I
have
other
than
some
of
these
links.