►
From YouTube: More Charts, More Problems Lets Talk Bringing Sanity Shikha Srivastava & Kirti Apte, IBM
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
More Charts, More Problems Lets Talk Bringing Sanity Shikha Srivastava & Kirti Apte, IBM
A
Quick
introduction,
my
name
is
Shekhar
Srivastava
and
with
me
is
my
colleague
cutie
we
are
from
IBM
and
what
we
wanted
to
discuss
was
how
we
handled
100,
plus,
more
charts,
probably
200
or
500,
charts
how
we
managed
to
bring
that
in
a
single
catalogue
for
an
easy
consumable
way
for
our
end
users
for
in
our
in
clients.
So
that's
the
problem.
We
wanted
to
discuss
it's
more
about
how
you
present
it
in
the
right
way
for
the
customers.
So
they
understand
what
charts
are
those?
What
categories
are
those
how
which
ones
they
need
etc.
A
A
Setting
the
stage
and
I
know
I
need
to
stay
here.
So
container
adoption
is
going.
As
you
all
know,
we
are
all
into
it.
That's
why
we
are
here,
and
there
are
several
benefits
of
it,
which
we
don't
have
to
go
in
this
talk,
but
that
actually
led
to
us
using
deciding
what
we
want
to
use
for
packaging
those
containers,
those
kubernetes
artifacts-
that
we
want
to
bring
to
the
customers
and
we
go.
We
went
with
him
to
give
the
context.
A
We
thought
that
will
be
best
to
give
start
from
what
drove
us
we
are
at
IBM.
We
have
a
solution
which
is
a
kubernetes
based
solution,
IBM
cloud
private,
as
you
know,
Red,
Hat
and
IBM
is
one
now
and
we're
using
OCP
and
under
the
covers.
But
this
is
one
solution
we
wanted
to
discuss,
which,
where
kubernetes
is
OCP,
kubernetes
and
rest
is
all
same
as
what?
What
what
was
with
the
IBM
cloud
private.
A
A
It
was
kubernetes
provided
by
ICP.
Now,
though
CP
it
can
be
any
other
kubernetes,
but
the
way
we
the
way
we
went
about
was
to
use
helm,
and
that
was
the
right
decision
from
our
part,
because
that
actually
helped
simplify
quite
a
bit
for
us
and
that's
this
chart
so
I'm,
probably
reading
ahead
of
my
charts,
so
standardization
was
based
on
helm
its
manages
a
lot
of
complexities
and
you'll
see
besides
values.
A
Dhamma,
we
introduced
our
own
some
of
our
own
Yama
files
for
to
make
sure
that
charts
are
easily
consumable,
easy
updates,
simple,
sharing,
rollbacks
able
to
manage
the
helm
releases
so
and
so
forth,
and
we
have
a
demo
if
we
get
time
to
show
that
as
well.
This
is
kind
of
the
scale
that
we
were
dealing
with.
It
was
not
only
charts
from
IBM.
It
was
more
about
our
business
partners,
our
ecosystem,
that
we
wanted
to
standardize
and
make
it
one
almost
one
single
UX
possible
for
them.
A
A
Having
all
these
charts
making
it
consumable
for
customers
so
that
they
don't
need
to
struggle
by
struggle
with
what
are
the
charts
available
that
are
storage
related
or
networking
related
or
application
related?
We
came
up
with
some
of
the
guidance
or
the
checkpoint,
but
guidance
and
certification
criteria
or
governance
criteria
that
we
put
together
to
make
sure
that
all
the
charts
follow
very
specific
criterias
or
guidelines
and
make
it,
and
that
made
it
very
useful
for
our
customers.
A
First
was
organization
of
the
charts.
We
wanted
our
charts
to
be
organized
really
well.
So
if
you
are
really
using
amd64
architecture,
then
you
can
go
and
filter
what's
available
for
amd64
from
our
cat
clock,
which
looks
very
similar
to
the
operator
IO
hub,
similar
installing
and
upgrading
spirits.
Anybody
who
actually
has
tried
installing
the
hunk
charts,
which
I'm
sure
all
of
you
there
are
certain
key
parameters
required
by
mq
versus
Cockrell,
CB
versus
some
other
database
or
some
other
objects.
So
those
are
those
are
the
things
we
wanted
to
make
standard
s
2.
A
These
are
the
parameters
you
specify
and
you
deploy
it
operational
experience.
We
once
you
deployed
the
hand,
charts
it
created
other
releases.
The
kubernetes
artifacts
were
created.
What
we,
what
we
went
further
ahead,
was
to
make
sure
that
the
chair,
when
you
deploy
the
charts,
you'd,
get
the
simple
operational
services
out
of
the
box,
for
example
monitoring,
so
you
deploy
the
services
your
pods
are
registered
and
your
metrics
are
flowing
into
Prometheus
and
into
the
definer.
A
You
have
metering
usage
data,
it
flows
into
the
usage
service
that
we
have
and
you
can
see
the
uses
so
one-stop
shop
deployment
and
you
get
access
to
all
the
operational
services
as
well
CI
CD
pipeline.
Of
course,
this
is
the
most
important
where
we
had
linting
enabled
we
had.
We
had
to
make
sure
there
are
certain
criterias
for
the
test.
Automation
enabled
to
make
sure
our
charts
were
well
qualified
for
production
and
then,
of
course,
there
was
governance,
which
was
checkpoints
and
making
sure
that
the
charts
were
really
good
quality
production
quality.
A
B
And
good
morning,
everyone
so,
as
a
word
chart
ecosystem
grew.
The
first
area
that
we
focused
on
is
organization
with
growing
number
of
charts.
A
quick
search,
discovery
and
filtering
of
the
charts
is
highly
critical
and
the
way
we
are
trusted
in
our
organization
is
effective
ways
to
organize
charts.
These
are
some
practices
that
we
came
up
with
to
add
on
on
top
of
helm
best
practices,
so
the
first
one
is
by
categories.
So
each
enterprise
can
have
come
up
with
the
master
list
of
categories
that
they
want
to
maintain.
B
For
example,
in
IBM
we
did
lot
of
research
and
we
came
up
with
the
standard
categories
and
we
kept
a
master
table
of
that
and
that
are
categories
like
DevOps
integration
data
analytics
and
then
there
may
be
blockchain
AI.
So
these
are
emerging
categories
and
you
can
tag
your
helm,
sharts
and
keyboard
is
the
specification
that
we
use
to
tag
this
hem
hem
charts,
second,
buy
helm
repositories,
so
each
business
unit
in
the
enterprise
can
have
their
own
repository.
So
that
way,
it's
easy
to
organize
the
charts.
We
started
with
that
in
IBM.
B
We
have
six
standard
repositories
based
on
the
cloud
provider,
so,
for
example,
public
chart
repository
private
chart
repositories.
Then
we
have
paid
contents
which
is
paid
charts
or
the
entitle
charts
repository.
So
that's
another
way
to
organize
it
by
supported
architecture.
As
sheikah
pointed
out.
You
know
there
are
your
chart,
which
architecture
does
it
support,
so
it's
very
critical
for
the
end-user
to
understand
your
chart,
suppose
Intel
power
Z
and
in
IBM
we
support
mighty
arch
images.
So
basically,
but
this
was
important
as
well
by
charts
maturity,
level,
better
tech
preview
limited
use
commercial
use.
B
B
Next
thing
we
focused
on
is
install
and
upgrade
experience,
so
we
found
gaps.
We
started
our
helm
journey
with
helm,
1.0
version
and
we
focused
on
install
and
upgrade
experience
where
we
found
gaps,
so
we
developed
our
own
specifications,
which
is
values
metadata
file
and
as
well
as
release,
notes
dot
MD
file.
So
we
have
values,
dot
Yambol
file
in
hell,
but
what
we
found
is
we
do
not
have
a
way
to
store
metadata
for
values
and
helm.
B
3
actually
is
coming
up
values
bit
value
schema
and
will
converge
to
that,
but
we
started
with
helm
1.0,
and
there
was
no
way
to
for
us
to
do
that
and
we
developed
our
own
specification
that
metadata
actually
is
in
the
form
of
type
label,
description
required
value,
then
maybe
for
the
validation.
You
need
regular
expression
validation.
So
these
kinds
of
support,
which
was
required
to
enhance
our
UI
experience
as
well,
once
M
user,
wants
to
upgrade
one
from
one
version
of
chart
to
the
other
version
of
chart.
B
There
was
no
way
in
the
help
specification
to
specify
what
are
the
breaking
changes
for
this
next
version.
What
are
the
fixes?
What
are
the
prerequisites?
What
are
the
version?
What
is
the
version
history
of
the
previous
chart?
So
the
way
we
addressed
it,
we
developed
our
own
specification
called
release,
notes
dot,
MD
file,
as
shown
in
the
screenshot
there,
and
this
specification
worked
really
well
for
us
operational
experience.
You
know,
standing
up
a
container
is
not
enough
so
day
2
operation
of
the
container,
which
is
logging
monitoring
metering.
B
All
this
service,
which
are
provided
by
the
cloud
providers.
How
can
my
help
chart
consume
those
services?
So
what
we
came
up
with
is
adding
annotations
in
the
helm
chart.
So,
for
example,
here
the
Prometheus
annotation
is
added,
so
if
Prometheus
is
installed
by
the
cloud
provider,
then
Prometheus
collector
actually
will
collect
the
metrics
which
are
generated
by
the
workload
which
is
installed
by
this
help
chart.
So
this
way
we
have
developed
it.
B
You
know
that
this
is
the
standard
practice
that
we
have
come
up
with,
and
other
enterprises
can
also
adopt
the
same
practice
where
different
annotations
to
consume
this
different
services,
where
your
workload
can
be
managed
and
your
help
chart
can
consume
this
day
to
operation
kind
of
thing
by
logging.
Monitoring
metering
services
are
available.
You
can
consume
those,
as
our
help
chart
ecosystem
grew.
B
The
most
critical
part
that
we
wanted
to
and
force
cover
governance
on
is
the
CI
CD
continuous
integration.
Each
business
unit
was
developing
their
own
chart.
So
this
is
our
CI
CD
pipeline
that
we
have
come
up
with
and
that
we
have
developed
and
other
enterprises
can
also
follow
the
same
practice
as
well.
So
here
the
product
team
develops
its
business
unit,
specific
charts.
So
let's
say,
for
example,
db2
MQ
data
analytics
all
these
business
units
in
IBM
they
were
developing
their
own
charts.
B
Then
the
build
team
used
to
pick
it
up,
build
team
or
ads
there.
No
tooling
automation
on
top
of
it.
So
tooling,
automation
like
image
scanning
is
one
of
them.
We
have
our
vulnerability
advisor
as
an
image
scanning
scanning
tool
that
we
use.
It
may
add
some
test
frameworks
there,
as
well
as
linking
tools
or
to
make
it
robust.
They
push
it
to
the
organizational
specific
or
the
business
unit,
specific
github
repo
it
gets
tested
on
the
preferred
cloud
provider
and
it's
a
continuous
cycle.
B
So
if
they
found
defects,
product
team
fixes
it
it's
a
continuous
integration.
Product
team
goes
in
and
once
it
is
satisfied,
it
just
makes
a
PR
or
the
pull
request
to
the
github
repository,
which
is
the
mastery
positive.
Now
here
we
have
one
governance.
Where
the
content
team.
There
is
a
separate
team
which
manages
the
governance
and
certification
process
of
all
the
charts
which
will
be
pushed
to
the
master
git
repository
of
the
organization
and
from
there
it
can
go
and
consume
to
the
various
helm
repositories
of
the
cloud
provider.
B
B
B
So,
as
I
told
you
earlier,
there
is
a
central
governance
that
we
have
adopted
to
certify
all
the
contents
of
the
helm
chart
that
we
are
producing
and
that
central
governance
in
our
case
is
the
content
team
and
the
content
team
actually
goes
in
and
certifies
all
the
content
which
are
getting
published
or
in
the
IBM
github
repository
and
other
enterprises
I
would
recommend.
You
also
follow
that
practice
where
the
number
of
chart
grows
and
ecosystem
grows.
That
is
highly
critical.
So
how
do
you
so?
B
The
criteria
that
for
the
certification
are
listed
here,
and
this
is
the
checklist
that
we
follow,
and
sometimes
you
know
it's
a
overhead
for
the
development
or
the
test
teams,
but
it
is
required
and
believe
me
or
not
this
system
books
if
the
number
of
child
grows
security
and
compliance
in
the
case
where
you
know
the
image
scanning
tool,
you
know,
make
sure
your
helm
chart
images
are
scan.
There
are
no
vulnerability
a
little
bit,
it
is
there
in
the
security
scanning.
That's
one
of
the
criteria.
Workload
availability
is
your
workload.
B
Self-Healing
is
their
automatic
failover
possible
for
your
workload.
Lifecycle
management
is
a
great
ability
followed
for
your
workload
or
the
lifecycle.
Management
is
one
of
the
aspect
of
it:
management
and
operations,
so
login
monitoring
metering
is
it
consumable.
Is
your
help
chart
making
sure
that
all
these
services
are
consumable
with
this
workflow
and
workload?
Is
getting
all
this
services
out
of
the
box
quality
and
support
as
well
as
this
is?
This
is
important
as
well
and
based
on
that.
B
Our
content
team
goes
in
and
certifies
the
chart
as
level
1
level,
2
or
level
3
level.
1
certification
is
the
basic
right
Iria
to
be
unbolted
in
IBM,
catalog
or
any
catalog,
and
that
needs
to
happen,
and
if
that
is
not
there,
then
your
chart
is
not
promoted
to
the
IBM
catalog.
So
these
are
some
of
the
practices
that
we
have
come
up
with
and
that
work
for
us
and
hopefully
for
your
enterprise
and
your
organization.
This
practices
will
work
as
well.
A
Okay,
so
that's
we
call
it
multi-cloud
manager,
it's
a
it's
a
one
of
IBM's
offering
for
managing
multiple
clouds.
We
have
the
catalog
as
QP
was
describing.
This
catalog
runs
on
the
ANA
cabinet
kubernetes
cluster.
This
is
the
catalog.
This
particular
instance
of
multi
cloud
manager
is
running
on
OCP
of
four
one.
Nine
and
the
catalog
is
is
here
so
we
discuss
classification,
making
sure
they
are
charts
are
classified
as
beta
or
limited
use.
So
it's
it
gives
a
clear
idea.
When
you
have
this
repository
log.
A
Good,
you
know
which
wants
to
be
used
in
production,
which
ones
is
for
dev
innovation.
That's
clearly
hauled
out
from
our
certification
and
the
government
process.
What
cloud
platforms
you
are
using
and
which
months
is
the
right
one
for
you
for
you
to
use
which
charts
are
certified
for
which
kubernetes
platform
architecture?
If
you
are,
if
you
are
as
eShop,
you
just
probably
need
to
go
here
and
filter
all
the
charts
that
RZ
supported.
A
This
is
again
about
what
kind
of
chart
this
is
it's.
Some
of
them
are
IBM
terminology,
which
makes
a
lot
of
sense
to
us
where
you
can
filter
the
set
of
charts
that
are
that
provide
that
are
part
of
a
cloud
pack,
the
repositories
they
are,
the
helm
repo.
We
have
multiple
home
repos
available
and
they
come
from
the
products
or
they
come
from
external
sources.
A
You
we
also
have
a
way
in
the
catalog
to
add
external
repositories
as
well
and
then
read
also
really
daal
is
everything
one
more
thing
that
we
did
not
focus
much
on
the
much
in
the
talk
was
the
are
back.
We
have
this
catalog
is
fully,
are
back
enabled.
So
you
can
create
your
teams,
you
can
assign
repositories
to
the
team
or
charts
the
team,
and
only
those
charts
are
available
to
your
teams.
You
can
imagine
shop
with
organization
with
dev
dev,
quality
and
production.
A
You
can
have
those
three
teams
they
can
define
which
which
arts
or
which
people
can
be
assigned
to
any
any
of
those
three
different
teams.
In
addition
to
these,
these
are
the
different
categories.
We
have
the
charts
related
to
all
the
security,
so
you
can
filter
by
those
or
data.
So
real,
quick,
let
me
show
you
the
deployment
experience
as
well.
All
categories
and
I
can
see
some
of
the
mq
related
rap.
Let
me
pick
up.
A
Rabbitmq
QT
described
some
of
the
release
management
or
the
read
Me's,
and
what
what
we,
what
we
added
to
the
chart
definition
itself,
that's
what
you
can
see
here.
This
has
description
about
how
to
install
how
to
uninstall
various
configurations
it's
all
available.
What
really
this
helps
with
is
a
new
user
getting
started
with
the
helm
new
users
getting
started
with
kubernetes
easy
to
understand?
What's
in,
what's
part
of
this
chart?
What
how
to
define
different
values
and
start
installing
it,
so
you
can
go,
configure
configure.
A
Let's
you
describe
what
will
be
the
name
of
your
release,
so
I
can
say
and
target
namespace.
Where
do
you
want
this
to
be
installed?
So
I'll
just
pick
default
for
now
what
I
mentioned
in
the
big
name
before
starting
the
demo
is.
This
is
actually
a
multi
cloud
manager
so
from
this
catalog
you
can
deploy
it
in
the
local
cluster
or
any
other
clusters
that
are
managed
by
this
hub.
A
I'll
put
local
for
now,
of
course,
accepting
the
license
and
there's
a
pod
security
policy.
You
might
notice,
there's
a
pod
security
warning
here
that
the
pod
security
policy
is
not
completely
aligned
with
the
charts.
Every
chart
comes
with
what
level
of
pod
security
policies
are
good
for
this
chart,
and
there
are
other
parameters
that
you
can
define
here
as
well,
debug
and
other
things.
So
let
me
click
on
install
the
install
basically
goes
and
installs
the
chart.
The
regular
hem
CLI
install
once
installed.
You
can
see
the
helm
releases
associated
with
it.
A
One
other
thing
that
I
want
to
point
out
real
quick
here
is
when
you're
looking
at
these
home
releases.
These
are
all
the
home
releases
from
all
different
clusters
that
are
registered
here,
but
this
is
the
one
that
I
just
installed
and
you
can
see
it's
running.
Maybe
I
can
demo
real
quick.
We
have
this
handy
dandy,
visual
web
terminal
that
we
have
experimented
with
so
cube.
Ctl
get.
A
Here
is
so
that's
the
one
I
just
deployed
and
it's
up
and
running
so
a
consumable
really
well
consumable
catalog
of
home
charts
that
handles
governance,
certification,
400-plus,
charts
from
IBM
different
products
inside
IBM
and
business
partners
in
the
ecosystem
that
we
go
through.
So
that's
what
we
wanted
is
show
any
questions.
I,
don't
know
if
we
have
time
for
questions,
but
any
questions
that
Kathy
and
I
can
address.
A
A
A
A
It's
it's
the
chart,
so
the
chart
is
IBM
chart.
Then
it's
the
license
from
maybe
IBM.
If
the
chart
is
coming
from
a
third
party
or
from
at
some
other
business
partner,
it's
their
license.
So
there's
a
whole
ecosystem
that
we
have
where
business
we
do.
Collaborate
with
the
business
partners
and
third
parties
we're
reaping
their
charts
as
repositories
and
ham
charge
that
you
can
use
from
the
catalog.
A
Some
of
the
linting
rules
as
well,
but
not
yet,
and
these
linters
are
some
of
the
linting
rules-
are
very
specific
to
yeah.
For
example,
you
know
you
have
to
have
the
pod
security
policies
defined.
You
have
to
have
the
all
the
security
vulnerabilities
that
we
use
when
we
have
a
VA
tool,
vulnerability
advisor
tool.