►
From YouTube: Introducing Flux Helm Operator, a GitOps Approach to Helm Operations Stefan Prodan, DX Engineer
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
Introducing Flux Helm Operator, a GitOps Approach to Helm Operations, Stefan Prodan, DX Engineer, Weaveworks
A
Or
we
works
I'm
a
flux,
city,
maintainer
and
today
I
want
to
give
you
an
introduction
to
get
ops
flux
and
the
helm
operator,
which
is
a
sub
project
of
the
flux,
CD
adventure
that
we
now
have
brought
from
weworks
and
now
it's
into
the
CNC
F
sandbox,
and
we
planning
to
give
it
even
further
away.
So
what's
key
tops
in
my
opinion,
so
in
one
opinion
you'll
be,
you
are
probably
using
all
these
tools
right
all
these
commands
to
change
things
in
your
cluster
to
deployments
to
to
roll
bags,
and
so
on.
A
That
means
you
have
to
share
your
cluster
credentials
to
everybody
that
has
must
have
access
to
the
git
repo.
It
also
means
that
your
CI
pipelines
will
probably
shell
out
to
DC
Allies
right.
This
is
how
most
people
do
deployments
on
kubernetes
with
the
get-ups
model.
We
just
you
know,
ignore
all
these
tools
and
we
only
use
git
push
to
interact
with
your
with
our
clusters.
A
What
that
means
is
that
someone
else
is
running
all
these
commands
for
us.
What
we
do
is
just
we
describe
our
desired
state.
We
say
we
have
a
git
repo
and
we
say
this
is
how
I
want
my
cluster
to
look
like
and
it's
up
to
the
tools,
some
automation,
the
runs
inside
your
cluster,
to
make
sure
that
what
you
have
described
in
your
git
repo.
It's
apply
these
reconcile
on
your
cluster,
so
white.
A
What
gift
Ops
brings
to
the
table?
Some
an
obvious
advantages
are
that,
from
a
devil's
perspective,
both
engineers,
both
developers
and
operations,
people
can
work
together
on
how
the
infrastructure
looks
and
how
the
applications
are
deployed
on
it.
So
if
you
have
a
git
repository
that
shared
between
your
teams,
then
you
can
work
with
to
request
reviews.
A
You
can
sign
your
commits,
so
you
know
who
did
what
and
you
can
also
get
these
audit
log
for
free,
like
many
companies
out,
there
must
be
soaked
to
compliant
or
other
compliances
and
get
gives
you
that
without
any
kind
of
effort,
if
you
switch
from
a
CI
model
to
a
detox
model,
then
every
single
change-
it's
you
know,
get
blog
and
if
you'd
sign
with
GPG,
let's
say
then
you
can
ensure
that
whatever
happens
is
there
and
you
can
trace
it
very
easily.
This
is
one
of
the
advantages.
A
Another
advantage
is
recovery
time.
So
let's
say
your
cluster
happens.
Something
happens
really
bad
in
your
infrastructure
that
you
don't
control
yards
on
some
cloud.
Something
really
happens
with.
Let's
say
your
etcd
cluster,
that
everything
is
in
there
all
your
configuration
and
you
want
to
start
new
and
a
new
cluster
right
with
the
same
stuff
that
was
running
on
the
previous
one.
A
If
you
use
CI
pipelines-
and
this
is
how
you
drive
deployments,
what
that
means
is
you
have
to
go
into
a
system
and
trigger
all
the
jobs
that
are
making
up
your
cluster?
You
have
to
redeploy
all
your
applications
and
so
on
right.
So
this
is
our
problem,
because
you
don't
really
know
what's
running
right
now
on
your
cluster.
You
know
that
okay,
there
are
some
have
to
look
on
on
your
ta
system.
Get
all
those
logs
out
of
there
see
what
was
last
applied
and
rerun
every
single
job.
A
A
So,
in
in.we
words,
we've
had
a
major
incident
some
years
ago,
and
this
is
how
we
we
managed
to
recover
the
whole
thing
in
15
minutes,
and
this
is
when
we
realized
that
okay,
maybe
detox,
is
not
something
that
we
should
keep
only
for
ourselves,
and
you
should
make
this
public
and
try
to
advocate
for
this
kind
of
driving
operations
of
our
kubernetes.
And
how
do
you
implement
detox?
There
are
some
things
here.
Of
course
you
need
a
get
request
arrived,
so
you
need
a
a
get
provider.
A
Now,
choosing
a
good
provider
means
that
you
have
to
trust
that
provider
for
uptime
right.
If
your
question
goes
down
and
the
good
provider
goes
down,
we're
surprised
there
is
nothing.
How
can
you
restore
something
when
your
source
of
truth
is
gone,
so
be
careful
when
you
choose
this
one,
because
it's
a
single
point
of
failure
right
for
the
get
up
stoney?
Of
course
you
have
to
have
a
container
registry
and
what
I
specified
here.
You
should
push
only
immutable
images
and
I
will
get
back
to
that.
A
But
the
idea
is
don't
use
latest
I
mean
latest
is
not
something
that
you
can
describe
as
the
state
of
your
app
its
latest
of
what
right
so
don't
do
it
and
the
same
thing
can
be
applied
to
two
hand:
charts
you
can
use
a
hen
repository
if
you
don't
want
to
keep
your
charts
on.
Indeed,
I
will
show
you
both
options.
Of
course,
hermits
is
way
better
than
a
container
registry,
because
heme
enforces
semantic
versions
for
your
hand,
chart
so
use
semantic
versions
and
don't
push
the
same
version
twice
right.
A
A
What
you
need
next
is
a
you
need
to
build
a
continuous
deployment
process
that
has
some
properties.
It
can
watch
for
changes
in
it,
so
it
doesn't
only
rely
on
the
get
provider
calling
that
operator
right.
So
it
can
do
this
kind
of
watching
on
its
own.
So
let's
say
if
a
get
hook
is
not
succeeded,
that
doesn't
mean
you
shouldn't
change
the
cluster
state,
because
if
it's
changing,
if
he's
changed,
indeed,
the
operator
should
react
to
it.
So
that's
why
here
we
rely
on
watches
and
not
only
get
web
hooks.
A
It
also
can
watch
your
container
registry
and
detect
if
there
are
new
images
and
take
decisions
based
on
that,
for
example,
flux
can
upgrade
your
containers
based
on
some
expressions.
Some
rules
that
you
can
define
for
upgrading
the
in
cluster
workloads
and
another
thing
you
should
be
able
to
detect
drift
like
drift,
is
something
that
happens
right.
Even
if,
let's
say
your
SR
18
says:
okay,
we
only
use
the
git
repo
to
drive
changes.
Maybe
someone
has
access.
A
Someone
definitely
has
access
to
that
question
and
can
do
some
modifications
inside
the
cluster
without
going
through
the
get
process
right.
So
your
CI
CD
system
should
detect
that
the
desired
state
is
no
longer
there,
because
someone
changed
something
inside
the
cluster
and
also
the
continuous
deployment
system
should
try
to
correct
the
drift
and,
of
course,
should
alert
on
Miss
configurations
and
Miss
configuration.
For
me,
here
is,
let's
say:
multimode
yellow.
A
Maybe
if
you
don't
have
something
like
on
each
pull
request
on
your
git
repo,
maybe
you
don't
have
something
like
cube,
eval
or
other
tools
that
are
validating
your
mo
and
then
the
continuous
deployment
system
should
say:
I
cannot
accept
this
model
for
demo
and
it
shouldn't
apply
anything
else
so
for
detox
to
work.
Everything
must
be
all
or
nothing
if
you
are
doing
a
commit
in
your
Guidry
point.
You
are
changing
like
a
dozen
Yama
files
and
the
single
Yama
file
is
malformed
at
it.
Then
nothing
else
should
be
applied.
A
We
works
has
started
the
flux
project
some
years
ago,
and
this
is
how
we
we
implemented
key
tops
for
ourselves
and
afterwards
make
it
open
source
and
now
a
lot
of
companies
and
freelancers
and
other
people
are
using
it
for
business
needs,
or
you
know,
just
at
home.
Maintaining
the
cluster
to
play
with
the
whole
idea
is
very
simple.
You
put
all
these
Yama
files
in
a
git
repo
flux
is
the
flux.
A
Watch
is
the
git
repo
and
how
it
does
that,
for
example,
on
github
or
github
you
when
flux
starts
up,
it
generates,
deploy
key,
it's
an
SSH
key.
You
give
the
public
key
to
github
or
github,
and
afterwards
flux
is
able
to
connect
to
the
cluster
to
the
git
repo
clone
the
git
repo
and
apply
the
changes
to
the
cluster.
So
this
is
how
how
it
works
is
not
not
magical
at
all.
A
What
flux
does
it
monitors
whatever
runs
in
your
cluster,
and
it
it
uses,
add
notations
to
keep
track
of
what
what
objects
are
indeed
and
what
objects
got
applied
on
the
cluster.
So
this
makes
flux
ideal
for
also
doing
garbage
collection.
What
that
means?
Is
you
add
a
deployment
or
cluster
that
deployment
gets
materialized
in
the
you?
Are
the
deployment
Herget
repo
that
one
gets
deployed
on
a
cluster
then
with
another
commit
you
remove
that
deployment
from
git
and
flux
will
will
detect
that
ok
on
the
previous
commit
a
heavy
subject?
A
Now
it's
gone,
so
it
will
do
a
cube.
Cut'
will
delete
on
that
object,
so
you
don't
have
to
clean
up
things
in
the
cluster
ending
it,
and
this
is
like
this
was
a
future
request
for
about
one
year
and
a
half
and
we
managed
to
pull
it
off
this
year.
So
we
are
very
happy
about
garbage
collection
in
flux.
This
is
why
I
mention
here.
A
Let's
go
on
to
the
helm
operator,
hands
on
it
right,
so
what
the
helm
operator
does
hem
operator
exposes
a
custom
resource
of
type
release.
You
can
keep
these
home
release
these
Hamleys
definitions
inside
your
git,
repo
flux
will
synchronize
them,
so
those
home
release
files
will
get
applied.
The
objects
will
be
created.
Hello
operator
detects
that
and
transforms
the
hem
release,
object
into
an
actual
hand,
release
simple
and
also
does
install
update
and
delete
using
the
flux,
garbage
collector
collection.
A
You
can
also
run
hello
operator
on
its
own.
We
made
big
efforts
to
so
hello
operator,
was
developed
inside
the
flux
repository
and
was
part
of
flux
itself,
the
source
code.
Now,
if
we
pulled
hello
operator
into
its
own
dedicated
git
repository,
it
has
its
own
dedicated
help
chart.
So
you
can,
if
you
don't
use
flux,
you
just
want
to
play
with
helm
operator.
We
can
deploy
it
like
any
other
operators
and
when
you
create
hem
release
easy
to
just
work
but
I'm.
A
What
I'm
showcasing
here
is
the
full
ETOPS
pipeline
that
I'll
try
to
demo
if
I
have
time
some
features
that
Homo
Prater
has
so
it
makes
all
the
helm,
operations
Beggs
and
declarative.
It
can
pull
charts
from
home
repositories
like
the
stable
hand
chart.
It
also
can
pull
charge
from
private
home
repositories
if
you
have
basic,
auth
or
other
things,
and
you
can
also
pull
charge
from
git
repositories.
A
So
you,
if
you
don't,
want
helm
repository
server
and
maintain
that
you
can
just
keep
your
charts
in
give
and
point
helm
operator
to
those
git
repo
stories.
What
I
mean
here?
What
are
those
raposo
is
usually
those
are
app
deploy
systems
where
you
have
your
source
code,
and
you
also
have
your
chart.
Source
code
can
tell
ahem
operator.
A
There
is
my
chart
definition,
and
here
is
the
helm
release
and
with
the
two
files
with
the
two
specifications,
it
will
create
the
install
also
for
the
values
how
we
can
provide
values
to
the
tool
release
the
couple
of
options.
Here
you
can
point
to
secrets
in
your
cluster
config
maps
or
even
external
URLs,
like
an
s3
bucket
or
something.
Maybe
you
want
to
keep
their
your
value
files
and
the
helm
operator
will
pull
them
off.
A
If
you
use
hello
operator
together
with
flux,
you
can
do
automatic
upgrades
of
hand,
charts
based
on
image
tag
policies
when
let's
say
this
is
more
of
a
hand,
two
features
so
helm
operator
works
with
hand.
Two
and
three
since
today,
for
him
to
there
was
a
problem.
If
you
first
install
a
chart
and
that
install
fails,
you
cannot
install
it
again
because
tiller
will,
just
you
know,
reserve
that
name
as
a
fail
chart.
What
helm
operator
does
when
it
sees
the
first
time
he'll
release.
It
will
try
to
install
it.
A
If
that
fails,
it
does
a
delete
and
purge
so
at
the
next
iteration
at
the
next
time.
It
does
a
reconciliation,
it
will
not
air
out,
and
if
you
fix
your
chart
in
the
meantime,
it
will
just
get
installed.
So
this
is
something
that
we
did
to
make
this
easier
with
him
to
until
our,
and
it
also
does
automaker
rollback
on
chart
upgrade
failures.
So
let's
say
you
describe
something
your
git
repo.
A
You
want
to
upgrade
something
your
chart
that
fails,
and
maybe
you
don't
want
to
leave
it
in
a
failed
state,
but
you
want
to
know
that
that
one
fails
old
home
operator
will
of
will
some
events
that
okayed
the
rollback
failed
by
the
upgrade
failed
and
it
does
a
rollback
fall.
So
your
stake
is
no
always
the
last
good
version
of
your
chart
installed.
A
This
is
how
ahem
release
looks
like
nothing
complicated.
We
have
this
chart
section
here
where
we
say.
Okay,
my
chart
comes
from
the
stable
repository
and
this
is
the
URL
for
the
repository.
That's
the
name
of
the
chart
and
that's
the
version
of
the
chart.
I
want
to
stop
here.
What,
if
you
apply
this
thing
on
your
cluster,
it
will
install
shield
secrets
in
the
default
namespace,
because
we
didn't
specify
the
any
namespace
here
on
that
Virgie
with
the
values
document
from
the
chart
right.
This
is
the
equivalent
of
helm,
install
shield
secret.
A
A
Those
are
encrypted
with
the
public
key,
so
anyone
from
your
team
can
encrypt
that
those
secrets
put
them
in
a
git
repository
and
no
one
can
decrypt
them,
except
for
the
silly
secrets,
controller
which
runs
in
your
cluster,
and
this
is
how
you
can
build
get-ups
pipelines
without
sharing
your
API
keys,
database,
passwords
and
so
on.
You
cannot
you'll,
not
just
put
them
in
clear
in
in
the
git
repo
you'll
put
them
encrypted
and
they
only
get
decrypted
on
the
on
the
cluster
side.
A
So
here
we've
seen
how
you
can
get
a
can
tell
her
my
operator
to
install
a
chart
from
from
helm
repository,
and
here
is
how
you
can
tell
it
to
install
a
chart
from
a
git
repository.
So
that's
it
github
URL.
It's
is
not
it's
not
the
highway,
so
it's
actually
the
git
repo
and
you
can
use
the
ref
key
to
point
to
a
release
in
give
up
or
to
a
branch.
A
So
instead
of
ref
2.1,
you
can
do
laughs,
master
wrench,
and
what,
whenever
you
you
put
a
change
in
in
master,
then
he'll
know
crate,
will
detect
it
and
will
upgrade
your
chart.
So
while
you
are
doing
development
for
your
deaf
cluster
is
very
easy
to
just
tell
her
my
operator,
please
synchronize
every
time
with
this
branch,
but
when
you
are
doing
production
releases,
then
you
should
point
to
get
release
assembler
that
doesn't
change,
and
it's.
A
Yes,
yes,
it's
branch
attack
and
the
various
part
down
below
its,
so
you
can
override
the
default
values
from
valve
is
jamming
in
here
in
line
in
the
Hurley's.
So
this
is
how,
instead
of
modifying
charts
all
the
time
to
fine-tune
them
for
I,
don't
know
different
clusters,
different
namespaces,
different
environments.
You
can
specify
your
values
inside
the
custom
resource
definition,
ham
release,
so
instead
of
copy
pasting,
charts
and
stuff
like
that,
we'll
just
create
more
ham.
A
Release
is
based
on
plain
space,
environment
and
so
on,
and
so
you
can
specify
values
in
line,
but
you
can
also
specify
values
from
config,
Maps,
secret
and
also
files
that
are
inside
your
charts,
like
it's
very
common.
If
you
look
at
the
stable
chart
repo,
there
are
values,
URL
and
production
values,
for
example
right.
So
if
you
decide
to
not
put
all
your
settings
inside
the
helm
release-
and
you
want
to
keep
your
settings
like
you
used
to
do,
for
example,
in
your
actual
chart,
you
can
reference
here
a
path
inside
your
chart
directory.
A
A
Yes,
yes,
so
we
use
with,
we
don't
use
the
helm
common
line
in
hello
operator,
hello
operator
uses
the
helm
go
packages,
but
we
try
really
hard
to
be
compliant.
Everything
Han
does
and
if
we
do
it
differently,
we'll
get
like
an
issue
instant
someone
will
notice.
So
this
actually
works
pretty
well
and
we
have
it
for
sometime,
I.
A
Think
more
than
half
a
year
like
hello
operator
started
like
one
year
ago,
or
maybe
more
than
one
year
he
didn't
know
about
the
year,
so
we
launched
helm
operator
alpha
one
at
the
first
hands
on
it,
and
hopefully
today
we
can
launch
1.0.0
the
first
release
candidate
with
mp3
support.
Okay.
So
this
is
how
you
can
provide
values
from
all
kinds
of
sources
and
from
here
is
missing
the
example
because
I
spaced
missing
the
example
and
can
reference
a
various
file
from
something
like
an
s3
bucket.
And
why
would
you
do
that?
A
A
One
feature
that
works
together:
reflux,
so
do
this,
you
have
to
have
flux
on
your
cluster,
not
only
the
hem
operator,
so
flux
has
using
annotations.
You
have
a
way
to
define
how
you
want
to
upgrade
your
values
spec.
So
here
in
in
my
values,
I
have
an
imagery
poison
attack
and
I'm.
Telling
flux.
Please
upgrade
my
hell.
Release
for
a
new
3.0
version
is
published.
So
what
I'm
doing
here?
What
I'm
saying
I'm
not
going
to
change
my
chart
for
patch
releases
of
my
application
right?
A
These
are,
let's
say
small
bug,
fixes
that
don't
require
infrastructure
change
in
any
way.
So,
instead
of
going
in
to
get
every
time
when
I
do
a
3.0
point,
well
release
4.2,
4.3
or
whatever
I'm,
trusting
myself,
that
I
will
respect
somewhere
and
I
will
not
do
breaking
changes
in
patch
releases
and
I
can
tell
flux
automate
this
stuff
for
me.
So
every
time
I
am
pushing
to
the
docker
registry.
In
my
case
a
new
version
flux
will
apply.
The
same
work
filter
will
detect
okay
30.1
it's
there
on
the
docker
hub.
A
It
will
modify
the
hell
release
file.
It
will
commit
the
ham
release
file
to
my
git
repository
and
afterwards
it
will
apply
it.
So,
even
if
I'm
doing
the
modifications
manually
with
git
commit
and
git
push
flux
does
the
same
thing.
So
every
everything
that
flux
changes
in
your
cluster
is
not
directly
in
your
class
and
it
changes
it
first
in
the
kit
and
afterwards
it
applies
it.
So
it
doesn't
break
the
the
get
ops
pattern
in
any
way
and
also
flux
can
deal
with
GPG
signing
and
stuff
like
that.
A
So
if
you
can
issue
encryption
key
for
class,
if
you
are
using
the
signing
for
git
repos-
and
this
is
how
it
looks
like
so,
what
flux
does
it
scans
your
cluster
for
all
containers
that
are
running
in
your
cluster,
then
it
uses
the
container
pool
secrets
from
from
the
kubernetes
api.
It
gets
that
secret
and
connects
to
the
docker
registry.
It
works
with
with
the
docker
hub,
with
quai,
with
all
sorts
of
registries
out
there
so
because
it
uses
the
double
secret
from
community.
So
it
connects
there
and
it
doesn't
pull
the
image
itself.
A
A
Yes,
yes,
so
we
we
use
the
AWS
and
aja
SDK
inside
flux,
so
we
refresh
the
keys
and
so
on.
So
don't
lose
your
credentials
and
use
this
memcache
here
just
to
store
these
images
metadata
like
the
container
name
and
all
the
tags
that
are
in
the
registry.
So
we
don't
store
here
like
real
images.
It's
this
memcache
is
very
light.
A
So
in
the
specification
next
to
the
release
name,
you
can
specify
a
target
instance.
If
you
don't
specify,
then
it's
the
same
namespace
as
the
hammerless.
Why
is
this
useful?
Maybe
you
don't
want
to
allow
your
dev
teams
to
install
hammer
releases.
Maybe
you
want
to
control
the
ham
release
process
only
from
an
admin
perspective.
So
if
you
put
the
ham
release
file
inside,
let's
say
the
deafness
place,
then
someone
could
get
to
this
ham
release
file
and
modify
it
right
or
delete
it
or
whatever.
A
Also,
if
you
use
something
like
this
like
multi-tenancy,
then
you
can
delegate
things
from
the
cluster
level
to
the
namespace
level.
How
we
do
multi-tenancy
with
flux
and
helm
operator
is
like
this.
We
have
a
cluster
git,
repo,
that's
controlled
by
the
cluster
admins
and
what's
there
in
the
cluster
git
repo
is
the
definitions
of
global
cluster
resources,
stuff,
like
main
species
stuff
like
clustering
or
bindings,
custom
resource
definitions
right
and
then
we
can
say
from
the
cluster
git
repository.
A
We
can
provision
a
flux
instance
and
ham
operator
instance
per
namespace,
and
we
can
connect
this
instance
to
the
team
git
repository.
So
each
of
your
dev
team
can
have
its
own
get
report
you
don't
have
to.
If
you
don't
want
to
merge
everything
under
a
single
git
repo
and
all
your
teams
have
to
share
this
one,
you
can
still
use
git
ops
and
have
a
dedicated
get
per
team.
A
With,
with
this
kind
of
setup
and
I've
made
the
inside
the
flux,
CD
organization
on
github,
there
is
a
special
repository
where
I
showcase
how
I
can
bootstrap
all
these
things
up
with
customizing
its
give
it
a
try,
is
very
easy:
it's
not
complicated
what
what
this
means
is.
The
cluster
admin
could
have
could
use
the
namespace
delegation
to
install
help
charts
in
the
team
one
in
space
without
putting
those
hand,
charts
those
hand,
release
definitions
inside
team,
one
get
people
that
that's
why
we
did
it.
A
So
how
pipeline
looks
very
easy
if
you
keep
in
your
git
repo
in
a
space,
because
helm
v3
will
not
create
a
namespace
for
you
anymore.
So
this
was
a
requirement
before,
even
if
helm
v2,
because
we
want
to
have
all
our
objects
in
it.
So
you
put
a
namespace
there.
You'll
not
just
use
helm.
Install
namespace
like
hello
operator,
is
not
able
to
create
namespaces.
It
will
not
do
help
install
namespace.
It
expects
for
the
namespace
to
be
their
pre
provision
and
how
we
do
that
flux
when
it
detects
your
git
repo.
A
It
will
order
all
the
objects
inside
your
git
repo,
in
a
certain
order,
for
example,
to
create
a
namespace
before,
let's
say,
custom
resource
definition
before
a
custom
resource,
so
a
namespace
before
the
deployment
and
so
on.
So
it
does
apply
in
a
certain
order.
So
all
these
things
can
work
together.
A
A
If
you
can
come
tomorrow,
we'll
see
first
and
how
we
can
build
key
tops
pipelines
with
flux,
ham
operator
and
tomorrow,
we'll
also
use
flagger
and
linker
D
to
do
the
ham
release
while
measuring
things
like
error
rates,
latency
and
so
on.
If
something
fails,
we'll
roll
back
the
ham
release
based
on
other
stuff
than
just
health
checks
and
lift
nurse
checks.
A
A
We
have
here
the
install
command
from
the
v3
support,
so
you
install
the
custom
resource
you
deploy
hello
operator
will
healthy
three,
and
if
you
set
this
environment,
variable
hello
operator
will
only
transform
he'll
releases
into
v3
ham
releases.
If
you
don't
set
this
environment
very
well,
then
you
have
to
specify
what
helm
version
you
want
inside
the
custom
result
definition.
So
ham
operator
is
able
right
now
to
manage
both
tiller
deployments
and
on
tiller
deployments,
with
Han
v3
and
in
our
roadmap.
Hopefully
soon
we'll
have
a
way
for
you
to
upgrade.