►
From YouTube: Creating a Micro Open-Source Community with Helm - Katie Gamanji, Condé Nast International
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
Creating a Micro Open-Source Community with Helm - Katie Gamanji, Condé Nast International
For over a century Condé Nast International has set the benchmark for print and digital publishing. Our portfolio is composed of luxury and fashion-oriented brands, like Vogue, GQ, Wired, Glamour and many more. Condé Nast International is a digital-first company, targeting to migrate 34 out of 62 existing websites to the Kubernetes clusters across the globe. Kubernetes underpins Condé Nast International's entire infrastructure, and Helm is used as the de facto deployment package manager. These two components were critical for the delivery of the highest developer experience. In time, the development teams became self-sufficient and started to contribute to the base Helm charts instead of going the feature requests route. This created a substantial and agile environment for developers, being able to instigate changes and contribute to the internal developer community.
https://sched.co/UaXL
A
Hello,
thank
you
for
being
here,
especially.
This
is
one
of
the
last
sessions
and
I'm
very
happy
to
see
so
many
people
here.
So
many
people
here
my
voice
is
slightly
strained
because
I've
done
a
lot
of
networking
on
the
first
day,
it's
mostly
recovering
and
I'll
try
my
best
to
to
make
myself
heard
everywhere.
A
So
I
would
like
to
start
by
giving
an
introduction
of
condé.
Nast
and
I
would
like
to
start
a
giving
of
introduction
of
whole
platform
as
well.
This
is
going
to
be
followed
by
how
our
developers
interact
with
our
platform
and
then
it
will
transition
of
our
support
apology
of
how
exactly
collaborate
with
our
application
teams.
Lastly,
I'm
gonna
finish
with
hell
micro,
open
source
community
or
pretty
much.
What
was
the
result
of
our
collaboration,
so
without
any
further
ado,
I
would
like
to
start
by
saying
what
kundan
has
does
and
delivers.
A
His
product
containers
has
at
the
benchmark
for
print
and
digital
publishing
for
more
than
110
years.
We
operate
brands
that
are
fashion
and
luxury
oriented,
and
you
might
be
familiar
with
some
of
the
brands
like
vogue,
GQ,
Wired,
Vanity,
Fair,
ATM
anymore.
These
are
just
a
few
of
the
brands
that
we
have
in
our
portfolio.
Currently
we
have
38
brands
and
we
distribute
them
in
26
languages.
So
it's
quite
a
wide
and
inclusive
range
of
brands.
A
We
have
out
there
with
headquarters
in
London
in
New
York
we
operate
on
an
international
scale
in
more
than
12
countries.
We
have
86
websites
overall
and
the
jury
more
than
350
million
three
hundred
and
thirty
million
unique
users
every
single
month.
So
far
we
reach
a
total
of
1.6
billion
page
views.
This
means
that
every
single
minute
we're
gonna,
deliver
37,000
articles
to
our
users.
So
it's
quite
a
considerable
customer
base.
We
have
out
there
now
I've
mentioned
that
we
operate
in
twelve
markets.
A
However,
if
you
look
at
the
map,
we
can
see
that
this
area's
a
quite
graphic,
a
dispersed.
Historically,
all
the
markets
had
quite
an
individualized
and
tailored
texture,
with
very
little
shared
components
in
between
them.
So
two
years
ago
we
kicked
off
a
digital
transformation
project
that
aims
aim
to
create
this
one
global
platform
and,
more
importantly,
we
wanted
to
distribute
it
globally.
So
currently
we
have
a
our
platform
replicated
in
five
different
regions,
making
a
total
of
nine
clusters.
A
We
have
free
clusters
in
Europe
and
F
staging
and
production
to
deliver
the
content
for
all
European
markets.
The
cluster
in
Tokyo
is
going
to
deliver
the
content
for
our
Taiwanese
Japanese
and
Indian
customers.
While
the
cluster
is
a
nerve,
Virginia
is
going
to
focus
on
our
Mexican
market.
In
China
alone,
we
have
two
dedicated
clusters
as
staging
and
a
production
one.
While
we
have
two
more
clusters
in
Dublin
to
host
our
internal
tools.
Now,
if
you
look
at
the
map,
you
can
see
that
we
don't
have
a
replica
of
our
tech
stack
in
Russia.
A
This
is
because
the
current
strategy
is
to
deliver
the
content
from
our
European
servers
while
having
a
CDN
which
is
Russian
oriented.
This
will
allow
a
service
availability
in
Russia,
while
investing
minimal
engineering
effort.
I
would
like
to
focus
a
bit
more
on
Russia
and
China.
Now
from
this,
the
countries
along
have
60
million
accusers
every
single
month
and
they
represent
20%
of
our
entire
digital
readership.
It
is
quite
a
considerable
customer
base
in
Canada
should
be
prepared
technically
to
meet
the
demand
in
this
areas
now
deploying
infrastructure
to
countries
like
Russia
in
China.
A
It
can
be
quite
challenging
from
an
infrastructure
standpoint.
When
we
kicked
off
the
project
for
a
global
platform,
we
did
not
have
a
clear
vision
of
one
cloud
provider:
that's
going
to
be
used
for
all
platforms
and
all
regions
as
such
this.
It
was
our
decision
to
use
a
self
hosted
solution
for
communities,
meaning
that
we're
not
going
to
outsource
it
for
anyone
else.
So
we're
going
to
take
it,
manage
it
ourselves
now,
there's
another
reason:
I
mention
Russia
in
China.
A
Yes,
it
is
challenging
to
deploy
infrastructure
into
it,
but
what
we
wanted
is
to
use
the
set
at
the
same
set
of
tooling
for
developers
to
interact
with
these
regions.
We
wanted
to
make
it
less
Optive
or
actually
make
it
very,
very
consistent
in
terms
of
the
set
of
two
links
and
I
would
like
to
give
a
bit
more
about
Cabrini
to
set
up
now.
Cabrini
tees
underpins
the
entire
infrastructure
of
containers.
A
We
are
occurring
as
house,
meaning
that
we
use
in
tectonic
installer
for
our
cluster
deployment
and
we're
using
EDD
for
the
surge
of
our
cluster
data
now
using
tectonic
allows
us
to
plug
it
into
different
cloud
providers,
while
using
computer
networking
resources.
This
allow
allows
us
to
be
vendor
agnostic,
while
deploying
100
open-source
communities
in
a
multi
master,
multi,
node
fashion.
Again
this
kind
of
allows
our
capability
to
lift
and
shift
our
infrastructure
even
to
countries
like
Russia
and
China.
A
If
need
be
our
part
from
his
life
since
October
last
year,
when
we
first
launched
in
Chico
France
since
then,
we
migrated
two-thirds
of
our
intended
state,
a
state
which
is
35
web
sites
and
so
far
we
serve
more
than
260
million
pageviews
every
single
mom
from
our
back-end
systems.
So
we
accumulated
quite
a
considerable
amount
of
requests
to
serve
now
I've.
Given
you
an
overview
of
how
we
actually
distribute
our
infrastructure
of
how
we
manage
infrastructure,
I
would
like
to
focus
on
our
developer.
A
A
Supposedly,
we
have
a
developer
that
would
like
to
deploy
new
application
to
a
cluster
or
even
if
they
would
like
to
change
any
settings
to
the
application.
The
way
to
go
for
that
they'll
require
two
dependencies
thirst:
the
older
characterized
version
of
the
application
which
is
going
to
be
stored
in
ki
raat
IO,
which
is
our
docker
image
registry
choice.
Secondly,
they
require
a
configuration
template
configuration
file
for
our
helm,
charts
templates.
A
Now,
once
two
dependences
are
available,
the
teams
will
be
able
to
interact
with
the
circle
sight
pipeline,
which
is
going
to
deploy
their
application
to
communities.
One
application
is
live,
they
will
be
able
to
login
into
the
cluster
and
interact
with
it
now.
What's
worth
to
mention
here
is
that
we
have
five
different
people,
actually
they're
going
to
deploy
to
four
different
clusters
with
different
regions,
and
they
will
have
the
ability
to
tailor
every
single
application
to
every
single
region.
This
is
actually
quite
important.
A
Talk
she'll,
make
sure
that
you
have
the
right
size
of
your
clusters
and
to
actually
have
the
content
or
the
infrastructure
right
size
to
the
region.
I
would
like
to
put
a
bit
more
focus
on
helm
now.
Helm
is
our
two
factor:
de-facto
deployed
deployment
package,
reticular
annuities.
Historically,
we
developed
around
ten
home
charts
which
are
maintained
in
building
house,
and
this
are
allowing
our
developers
to
deploy
their
application
to
actually
do
that.
We
have
a
base
hull
chart.
Now
the
base
home
chart
will
deploy
a
fundamental
deployment
and
service
account
associated
with
it.
A
At
this
stage,
the
application
is
not
going
to
be
available
to
the
traffic
or
internal
or
external
users.
To
do
so,
they'll
have
to
enable
ingress
or
in-service
resources.
To
do
so
with
home,
we
have
dependent
sub
charts
where
they
can
be
enabled
based
on
the
flags.
So
we
have
ingress
service
and
HPA,
and
this
is
pretty
much
the
entire
suit
of
configuration
the
developers
will
have
available
for
the
application
as
well.
A
We
have
in-house
built
on
charts
for
network
policies,
resource
requests,
cron
jobs
and
jobs,
and
we
actually
use
a
different
flavor
of
flinty
we're
actually
thinking
to
move
upstream
in
the
future
as
well.
In
terms
of
the
settings,
this
is
pretty
much
where
the
developers
have
to
configure
the
application.
Now
this
is
quite
a
nice
abstract
Larry
they
have,
they
don't
need
to
care
about
the
infrastructure.
A
They
just
need
to
provide
values
for
these
settings,
such
as
the
image
which
is
going
to
be
usually
Kyodai,
Oh
amount
of
replicas
and
annotations
liveness
and
readiness,
probes,
HPA
objects
and
so
forth.
So
a
typical
configuration
file
is
going
to
be
looking
something
like
that.
I
hope
this
is
visible
from
the
back,
so
we
have
a
name
for
our
application:
she's
going
to
be
asthma
and
the
image
is
going
to
be
stored
in
kilo
kayo,
and
we
want
free
replicas
for
this
application
as
well.
A
We
enable
a
surveys
and
we
want
to
expose
our
application
on
port
80
and
in
terms
of
ingress,
we
say
that
we
want
to
use
a
traffic
restricted
load
balancer
for
as
I
move
to
divided
C
and
I
post.
Now,
it's
automation
at
this
moment
that
we
have
to
advancers
available
for
every
single
namespace
or
every
single
application.
One
of
the
load
balancer
is
going
to
be
public
and
one
is
going
to
be
restricted
with
the
public
one
they'll
have
equitable.
A
Now
we've
talked
about
how
a
developer's
interact
deployed
to
a
platform.
I
would
like
to
focus
on
the
support
apology.
Now
this
is
gonna
be
from
the
cloud
platform
perspective
and,
more
importantly,
how
we
cooperated
and
change
our
identity
route
to
actually
empower
our
developers,
their
application
historically
and
when
I
say
that
it's
around
two
years
ago
we
had
one
cloud
platform
team
which
was
responsible
to
deliver
the
main
components
for
infrastructure.
At
the
time
we
had
a
bi-weekly
rotor
just
to
actually
support
our
engineering
queries.
A
This
was
great,
however,
for
our
time
the
morgue
mature
was
our
infrastructure,
the
more
complex
query
we
had
from
our
developers
and
the
amount
of
noise
was
actually
quite
overwhelming.
So
it
was,
we
had
a
transition
which
divided
our
team
into
functions.
We
had
the
call
platform,
and
we
had
the
cloud
management
in
the
cloud
pod
for
must
still
focus
on
delivering
the
main
infrastructure
bits.
However,
the
cloud
management
will
focus
on
upscaling
the
developers
and
advocating
for
the
best
ownership
practices
for
the
application,
and
recently
it
is
happening
for
I.
A
Think
five
months
now
we
have
a
new
function,
which
is
the
SRA,
and
this
is
the
target's
of
support
apology
model
actually
aimed
for
with
the
SRA.
We
have
the
size,
reliability
being
an
area
of
ownership
in
its
own
and
we
have
actual
developers
thinking
about
this
and
actually
pushing
for
the
best
practices.
A
So
this
is
our
transition
that
happened
throughout
two
years,
so
we
actually
changed
our
identity
and
Trust
modified
to
support
how
developers
in
the
best
case,
if
we're
thinking
about
this
transition
and
delp's
topologies,
this
is
pretty
much
power
transition.
We
use
the
b-type
free
of
DevOps
topology,
which
is
infrastructure
service.
We
do
pretty
much.
We
deliver
our
infrastructure
on
demand.
A
So
let's
talk
about
the
results
of
all
this
collaboration
and
extended
and
proximal
collaboration
between
the
infrastructure
and
developer
teams.
We've
actually
before
I.
Do
that
I
would
like
to
focus
a
bit
more
of
what
open
source
is
to
be
honest.
Officers
is
a
method
to
for
a
software
development
which
is
decentralized,
but
at
the
same
time
it
encourages
collaboration
and
contribution
from
from
the
users.
We
had
a
very
similar
use
case
with
health,
where
we
have
our
home
charts
and
building
house,
but
we
have
our
developers
contributing
for
them.
A
They
didn't
go
the
original
way
to
actually
create
a
ticket
which,
for
us
to
prioritize
they'd,
pull
it
back,
pull
into
the
sprint
and
then
work
on
it.
They
actually
did
themselves
with
with
us
helping
them
as
home
and
I
would
like
to
present
to
you
some
of
the
use
cases
of
what
these
contributions
were
to
our
home
church.
A
So
the
first
one
was
to
actually
add
graceful
termination
to
to
our
pots
by
using
the
priests
help
handlers.
Now,
to
give
you
a
bit
of
the
context
why
this
was
required
at
the
time
we
had
a
lot
of
500
502.
So
if
I
were
first
looking
more
specifically
from
our
application,
so
one
actually
terminated
a
pot
all
the
requests
with
well.
There
will
be
a
latency
to
actual
wait
for
the
new
end
points.
A
Now
all
the
new
requests
will
still
go
to
the
kind
of
terminated
parts
which
created
fire
500s
and
the
ongoing
requests
as
well.
They
will
go
500,
we've,
the
priests
up
handler.
We
would
have
a
command
which
will
wait
for
10
seconds
before
the
poll
be
terminated
completely
now.
This
will
actually
subdued
500
errors.
Making
a
cleaner
and
nicer
graph
for
us
to
look
at
a
different
contribution
was
to
add
target
average
value
for
help
charts.
Now
our
developers
are
able
to
scale
the
application
horizontally
by
using
CPU
memory
as
well.
A
They
actually
can
do
that
with
external
metrics
and
what
the
actual
wanted
is
to
use
a
target
average
value
for
the
HPA
which
allow
them
to
keep
the
ratio
between
the
amount
of
pods
and
the
amount
of
workloads.
This
is
quite
a
nice
addition
and
quite
a
fine
one
as
well.
A
different
one
was
third
pod
annotations
to
our
current
jobs
crunch
pods.
Now
this
was
required
to
actually
propagate
the
AWS
permissions
to
the
pod.
The
developers
wanted
to
create
a
more
controlled
environment
for
the
container
to
interactive
database
API.
A
So
again,
this
is
quite
a
important
thing
to
have
in
mind
and
the
last
one
was
from
our
developers.
They
actually
wanted
to
store
credentials
or
more
sensitive
data
to
mount
actually
more
sensitive
data
to
their
containers.
This
was
possible
to
by
using
the
secret
volumes
and
again
this
was
added
to
hell
charts.
So
in
total
it
was
quite
a
nice
addition
of
features.
It
was
very
kind
of
tailored,
with
application
record
by
the
application
things
we
actually
have
a
very
similar
nursers
practice
with
Tier
four
modules
for
out.
We
have
developers.
A
A
So,
overall
we
talked
about
our
developer
experience
and
how
we
try
to
enhance
the
way
our
developers
interact
with
our
platform
and
deploy
to
the
platform.
Secondly,
we
we
actually
focus
on
support
apology,
and
this
is
how
the
Cal
platform
team
actually
metamorphosize
for
out
two
years
to
best
deliver
support
our
application
teams.
And,
lastly,
we
talked
about
our
results,
which
is
to
create
micro,
open
source
communities
of
health,
but
being
cut
with
hedge
without
her
from
modules
as
well,
so
I
think
in
conclusion.
A
Overall,
it
is
quite
a
challenging
task
to
to
make
our
developers
happy.
However,
we
managed
to
create
this
kind
of
cohesive
environment,
which
doesn't
only
enable
our
developers
and
their
product,
but
it
actually
creates
initiatives
for
micro
concerns,
communities
or
interspersing.
I
have
recently
summarized
all
of
this
into
a
blog.
A
B
A
We
actually
say:
well
now
we
have
four
developers
in
cloud
infrastructure
team.
We
have
three
developers
for
our
cloud
management,
so
they
are
going
to
be
interacting
with
our
developers
and
we
have
free
for
our
sorry,
so
in
total,
in
ten
ten
developers-
and
this
excludes
the
team
leads
and
the
managers
yeah.
Thank
you
so
much.
C
A
Absolutely
I
think
for
us.
It
was
always
a
motivation
to
make
it
as
easy
as
possible
for
our
developers
to
deliver
their
application
to
the
cluster.
Now
we
try
to
abstract
as
much
as
possible,
so
what
they
have
to
do
usually
is
just
that
configuration
file
is
like
a
couple
of
lines
and
that's
it
and
they
quite
happy
now
the
the
reason
for
us
to
have
the
bi-weekly
rota
to
interact
with
our
developers
and
have
time
specifically
for
them
and
then
transitioning
to
the
cloud
management
team
as
well,
which
it
was
all
about
upscaling
developers.
A
Now
they
to
be
honest,
they
were
actually
quite
proactive
and
it
helped
us
a
lot
and
at
the
same
time
they
were
proactive,
were
very
pretty
to
help
them
and
it
was
quite
kind
of
a
nice
collaboration
between.
So
it
was
definitely
based
on.
You
know,
proactiveness
from
both
sides,
but
I
would
say
we
I
know
it's
difficult
in
some
other
environments
for
us
I
think
we
had.
We
have
great
developers
with
a
very
open
mind.
They
would
just
help
happy
to
you
like
contribute
and
like
learn.
Something
I
would
say
what
crab
Mikey
yeah.
D
So
you
talked
about
the
transition
from
was
a
type
three
to
six
to
seven,
so
just
curious.
What
was
what
were
some
of
the
things?
Where
were
some
of
the
motivations
that
caused
you
to
go
from
one
to
the
other
or
were
some
of
the
other
things
you
tried
that
may
not
have
worked
and
where
those
changes
kind
of
bottom-up
you
know,
were
they
well
the
developers
asking
for
them
in
just
talk
about
your
journey
right.
A
So
that's
a
very
good
question.
Actually
there
is
a
lot
of
background
and
context
of
how
we
actually
cooperated.
We
follow
dev
teams,
but
I
think
from
one.
So
at
the
beginning,
we
just
like
one
call
platform
team
and
we
would
deliver
everything
and
we
had
like
hold
occurs
and
we're
working
in
a
campaign
style
as
well,
which
I
think
I.
Would
it
kind
of
made
it
more
difficult
for
us
to
have
a
higher
velocity
on
providing
our
infrastructure
features
so
the
time
we're
like
okay,
so
we
still
need
to
deliver
the
global
platform.
A
We
still
have
to
have
the
migration
of
the
markets
gel
platform.
We
need
to
focus
a
bit
more
on
our
infrastructure,
but
at
the
same
time
our
developers
are
quite
important,
like
we
can't
just
like
leave
their
queries
in
the
air
like
their
demands.
So
I
think
this
kind
of
transition
was
anyway
natural,
but
in
a
way
our
our
team
lead
and
management
team
they're
actually
working
quite
hard
to
understand
the
needs
of
the
developers.
A
So
I
wouldn't
say
it
was
necessarily
top-down
because
it's
just
like
two
layers,
which
you
know
collaborate
all
the
time
and
they
always
kind
of
know
their
situation.
It's
a
small
team
and
kind
of
makes
it
easier
for
us
to
gather
a
feedback,
so
I'd
say
the
dev,
the
management
team.
They
were
actually
doing
a
great
job
of
identifying
that
we
actually
need
these
cloud
management
team
but
and
then
transition
tree.
A
They
need
to,
for
us,
have
this
rating,
because
our
set
of
monitoring,
for
example,
was
absolutely
horrendous,
but
now
it's
not
because
we
have
this
SRA
team,
which
is
actually
focusing
on
delivering
this
monitoring
alerts
on
based
on
KPIs,
and
they
will
have
this
holistic
vision
of
micro
services
in
between
so
I
think.
This
is
kind
of
the
more
mature
er
is
more
kind
of
requirements.
We
we
see
like
areas
we
need
to
be
involved
in
or
the
contribute
to,
we
identify
them,
and
by
than
that,
we
actually
changed
the
shape
of
our
team.