►
From YouTube: Why Kubernetes Can't Get Around FinOps – Cost Management Best Pra... Vanessa Kantner & Manuela Latz
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Why Kubernetes Can't Get Around FinOps – Cost Management Best Practice - Vanessa Kantner & Manuela Latz, Liquid Reply
Anyone with the right permissions on a cloud provider can acquire resources or spin up Kubernetes Clusters. While developers can joyfully make cloud spending explode, traditional finance and procurement departments look around in wonder. The FinOps approach and the Foundation, which coined the word, dedicate itself to continuously enhancing best practices around cloud financial management. Managing Kubernetes resources is the masterclass of it. Having cost transparency and control over many dynamically scaling containers across many server instances can be difficult. Vanessa and Manuela share the experience in monitoring Kubernetes costs and planning budgets accordingly. This session covers how engineers – responsible for incurring costs – can support cloud cost management to prevent overspending and how this approach enables and empowers colleagues from finance, procurement and business in their daily doing. This, in turn, gives the engineer more freedom to explore new solutions.
A
My
name
is
manuela,
I'm
working
for
liquid
reply
as
a
consultant
and
I'm
the
number
crunching
person
doing,
monitoring,
kpi
and
so
on,
and
so
on.
This
lovely
person
next
to
me,
is
my
colleague,
vanessa
and
she's
also
consultant
at
liquid
reply
and
our
evangelist
about
phenoms.
But
what
we
actually
love
about
doing
phenoms
every
day
is
that
we
have
the
ability
to
build
and
orchestrate
high-performing,
fin-ups
teams
and
bringing
devops
people
from
about
cost
management
to
pretty
excitement.
A
A
B
B
But
still
at
the
same
time
you
have
the
old
traditional
processes
that
apply.
You
have
the
same.
People
like
before
managers
finance,
whatever
roles
they're
called,
and
they
still
have
to
somehow
manage
the
budget
and
they
still
kind
of
want
to
approve
the
costs
and
the
budget
to
being
able
to
govern
them
and
manage
it.
B
But
so
I
mean
it
would
be
easy
to
just
update
these
processes
and
based
on
the
variable
cloud
cost
model.
But
I
mean
to
be
honest,
the
business
and
the
finance
people.
They
don't
really
understand
how
the
cloud
works.
Most
of
the
time
and
now
kubernetes
comes
in
and
that's
a
whole
new
abstraction
layer
on
top
of
the
cloud
and
that
creates
that
huge
knowledge
gap
between
the
technical
and
the
non-technical
people,
because
how
should
they
ever
comprehend?
B
How
kubernetes
and
kubernetes
costs
work
when
they
can't
even
comprehend
the
variable
cost
model
of
the
cloud?
And
so
that's
exactly
what
finnops
addresses,
because
at
the
end
of
the
day
we
need
the
buy-in
of
those
non-technical
people
because
well
they
have
to
plan
a
budget
somehow,
and
we
engineers
don't
want
to
do
that.
B
At
least
I
don't
so
finnops
or
you
might
remember
the
devops
movement
or
like
pre-devops.
There
were
like
developers
and
operations,
people
and
they
didn't
talk
to
each
other
and
it
was
a
huge
mess.
So,
like
every
team
was
annoyed
by
the
other
team
and
it
wasn't
fun,
then
devops
came
brought
these
two
teams
together.
Suddenly
you
had
one
team
and
it
worked
pretty
well
and
now
today
you
have
a
similar
situation.
B
You
have
devops
teams
and
you
have
the
finance
and
business
people,
and
now
you
have
to
bring
them
again
together
to
have
a
phenoms
team
and
finnops.
Does
that
and
at
the
end
of
the
day,
it
enables
all
of
these
people
when
they
begin
to
talk
to
each
other
again
to
make
these
spending
decisions
the
decisions
the
company
needs
you
as
an
engineer,
need
to
being
finally
able
to
work
on
some
cool
features
and
at
the
end
of
the
day,
it
increases
the
business
value
of
the
cloud
of
kubernetes
for
the
whole
company.
A
A
The
trick
here
is
this
is
solely
focusing
on
performance
when
it
comes
to
fin-ups,
every
monitoring
you
have
to
do
has
to
have
the
ability
to
link
this
to
cost
metrics.
So,
first
of
all,
this
is
a
different
data
source.
So
usually
it's
your
cloud
provider's
bill.
It's
the
agreed
discounts.
It's
the
reservations!
You
made
it's
about
scenario,
building.
How
much
would
something
cost
when
I
do
it
on
demand?
A
A
I
could
totally
say
how
much
I
spent
for
an
s3
bucket
based
on
that
list,
and
I
totally
could
tell
you
how
much
I
would
have
to
pay
for
an
ec2
instance,
but
that
still
doesn't
give
me
the
ability
to
tell
or
to
answer
the
questions
vanessa
just
introduced.
I
can't
tell
how
much
the
project
spent.
I
can't
tell
how
much
an
environment
spends.
I
can't
compare
them
to
each
other.
So
labeling
is
the
key
to
this.
A
These
three
things
you
can
see
on
the
screen
right
now
are
basically
not
new
to
you,
but
in
the
context
of
our
daily
work,
I
want
to
outline
them
why?
The
first
thing
about
the
pod
template:
I
had
to
learn
by
heart:
if
you
don't
label
at
the
right
spot
in
your
configuration
template,
you
cannot
monitor
costs.
A
A
The
second
thing
is
when
it
comes
to
labeling,
your
key
value
pairs
have
to
be
targeting
cost
management
so
about
your
keys.
What
you
can
see
at
the
slide
right
now
these
are
the
ones
the
community
of
phenoms
has
come
up
with
as
being
the
most
common
ones.
Obviously
you
can
individualize
them
for
your
organization,
but
to
answer
the
questions
we
we
saw
in
the
beginning.
It's
application
business
unit,
company,
cost
center
environment
and
project
that
should
be
outlined
when
it
comes
to
cost
transparency
and
one
last
important
thing
about
the
value
description.
A
Cost
monitoring
and
cost
reporting
that
comes
out
of
the
cost
monitoring
is
for
non-technical
people.
So
you
have
to
keep
in
mind
when
writing
your
values,
that
they
are
understandable,
comprehensible
for
non-technical
people,
because
even
if
you
set
up
the
perfect
labeling
and
you
have
it
with
policies
and
everything
running,
if
no
one
else,
despite
you
understands
it,
then
you
have
the
same
issue
with
you're
the
only
one
knowing
what
runs
on
your
clusters.
A
B
Optimizing,
that's
the
purple
question
the
one
from
before,
and
it
starts
by
right
sizing.
So
right,
sizing
is
all
about
setting
the
right
amount
or
of
cpu
or
memory
or
the
right
amount
of
resources
of
your
cluster,
of
your
nodes
of
your
workloads
and
it
starts,
and
that's
actually
that's
the
essential
part
of
right
sizing.
B
B
So
that
means
that
it's
our
tasks
task
to
set
the
resource,
requests
and
limits
to
our
pots
and
to
all
of
them.
It's
not
enough
to
just
put
it
on
one
of
the
parts
and
then
we
can
automate
the
whole
auto
scaling
magic
and
we
have
three
autoscalers
that
I'm
going
to
talk
about
and
the
first
one
is
in
a
for
a
stateful
workload.
B
B
B
B
That
was
it
on
a
port
on
a
workload
level.
Then
we
have
the
other
level
of
the
infrastructure
level.
So
that
means
notes
the
cluster
autoscaler.
Does
a
similar
thing
to
the
horizontal
part
of
the
scalar
before
to
be
honest,
because
it
just
adds
notes
or
removes
them,
but
this
one
it's
not
based
on
the
actual
usage
it
just
it's
based
on
the
scheduling
stages
of
your
parts.
So
if
the
cluster
autoscaler
sees
okay,
it's
not
possible
to
schedule
a
part
due
to
resource
constraints
on
your
node,
then
it
brings
up
a
new
note.
B
B
B
A
Yes,
thank
you
so
how
to
implement
finnops
practice
in
your
daily
work.
I
went
to
refer
to
the
last
slide.
First,
you
saw
those
bars,
so
I
think
the
first
thing
you
should
know
about
finnops
is
it's
getting
out
of
the
bubble
and
seeing
the
big
picture,
because
in
fact,
when
you're
working
for
for
an
organization
when
you're
working
for
a
company
you're,
not
the
only
account
you're,
not
the
only
developer,
you're,
not
the
only
project?
A
And
yes,
if
you
have
resources
over
provisioned
or
if
you
have
systems
running
on
the
weekends,
your
single
account
doesn't
do
any
harm
but
make
the
math
like
do
this
with
200
accounts.
Do
this
four
weekends
per
month
do
this
12
months
a
year?
This
is
like
a
lot
of
money,
you're
wasting
without
any
necessity.
A
I
want
to
highlight
this
one
because
again,
if
you
create
labels
in
your
bubble
and
maybe
across
your
team,
that
still
doesn't
make
sure
that
a
business
and
finance
can
use
these
labels
for
reports
and
stuff
and
b
that
another
team
is
doing
the
exact
same
thing
so
like
with
everything
on
the
technical
side.
You're
doing
it's
the
same
with
those
things
you
have
to
agree
and
collaborate
working
together
on
a
standardized
list,
and
then
you
have
to
make
it
part
of
your
processes
and
documentation.
A
The
second
thing-
and
this
is
an
a
nice
example
when
it
comes
to
naming
conventions-
and
I
know
I
root
some
of
you
now
when
it
comes
to
naming
conventions.
There
are
two
important
things
to
know
about
clusters,
whatever
monitoring
tool
you're
you're
using
since
they
are
also
for
non-technical
people,
they
are
using
names.
A
So
whenever
you
are
using
the
same
name
for
two
different
things,
this
can
create
confusion.
As
you
can
see
in
this
enzyme
example
behind
me
that
happened
when
we
were
monitoring
what
we
thought
was
one
cluster,
but
by
the
end
of
the
month,
surprise
doubled.
The
cost
were
actually
two
clusters
again.
This
is
not
only
your
team
or
your
project.
This
is
across
organization
and
project
standards.
A
I
know
it's
a
very
tiring
topic,
but
it's
very
important
to
to
have
a
standardized
spelling,
how
you
do
things
when
I
first
started
with
my
actual,
like
recent
client
project,
we
had
money,
training
based
on
tags,
and
I
have,
I
think,
seven
or
eight
different
spells
for
environment
just
for
the
key,
not
not
the
value,
just
for
the
key.
So
here
it's
very
important
again
that
you
manage
to
come
up
with
a
standard
agree
on
it,
put
it
in
your
documentation.
A
The
second
thing-
and
this
is
something
again-
someone
from
finance
and
management
can't
do-
is
ensure
functional
monitoring
and
labeling.
What
does
that
mean?
It's
a
procedural
change,
so
whenever
you
create
something
new,
you
have
to
make
sure
that
it's
part
of
the
monitoring-
and
this
is
your
job.
No
one
can
take
this
away,
and
the
second
thing
comes
with
the
labels
as
well.
Whenever
you're
doing
something
new,
you
have
to
make
sure
that
it's
part
of
the
monitoring
and
labeling
thing.
A
B
Few
tips
for
right
sizing,
so
yesterday
at
our
booth
we
had
a
visitor
and
we
were
discussing
autoscalers
and
he
was
like:
okay,
that's
kindergarten,
autoscalers.
Everyone
knows
that.
Then
we
were
talking
about
okay.
How
do
you
set
your
resource
requests?
Do
you
even
do
that?
Yeah?
Of
course
I
do
and
no
autoscaling,
and
then
we
were
like
okay,
but
how
what's
the
metric?
How
how
much
cpu
or
memory
do
you
set?
B
It's
like?
Okay,
I
do
it
to
be
honest,
gut
feeling:
okay,
yeah
fine,
I
mean
you're
the
engineer.
Maybe
you
have
a
good
gut
feeling,
but
then
he
was
like
okay,
but
usually,
I
just
add,
like
10
percent,
to
my
gut
feeling
just
to
be
safe
and
now
imagine
you
add
10
percent
to
everything
to
each
and
every
single
one
of
your
pots,
and
suddenly
you
have
a
huge
overhead
again
and
that's
just
a
waste
of
resources.
B
So
when
setting
resource
requests
initially,
please
do
load
tests
or
some
kind
of
similar
thing
to
low
tests
and
over
time
you
can
of
course
improve
those
limits.
Of
course,
you
can
always
start
by
doing
that
plus
10
percent,
but
pre,
please
improve
it
over
time
and
monitoring
helps
you
doing
that
and
you
can
just
iterate
over
the
resource
requests
and
it
will
get
better
talking
about
outer
scalers.
It's
a
really
cool
thing
and
you
can
even
combine
the
horizontal
and
the
vertical
pot
autoscalers.
B
B
The
clusters
went
down,
the
outer
scalers
bend
them
back
up,
the
integrated
monitoring
systems
were
blinking
and
the
operations
team
was
awake,
and
that
happened
a
few
times
during
the
night,
and
it
wasn't
a
very
good
night,
at
least
for
the
operations
team,
and
so
when
using
policies
and
outer
scalers
make
sure
they
work
together.
They
are
integrated
well
into
each
other
and
make
sure
that
the
surrounding
systems
don't
blink
and
alert.
Everyone
involved.
A
A
Monitoring,
labeling
right-sizing
waste
management.
These
are
the
key
things
to
get
there.
Obviously
we
have
so
many
more
things
to
do,
but
the
key
things
are
this
and
what
the
best
takeaway
I
would
invite
you
all
to
to
to
take
with
you
today
is
that
the
first
step
for
the
daily
practice
is
acknowledgement,
basically,
knowing
that
this
is
a
necessity
with
every
abstraction
level
we
are
creating
from
a
technical
side
and
then
to
make
sure
from
a
technical
setup
that
you
help
the
people
who
needs
to
understand
them
on
a
second
place.
A
A
C
B
Yes,
definitely
that's
actually
one
of
my
passion
topics
right
now.
Thanks
for
the
question.
Yes,
there
is
a
correlation,
but
of
course,
if
you
reduce
costs,
if
you,
for
example,
right
size
your
instances,
then
of
course
you
save
co2,
but
it's
not
like
finnops.
All
of
fin.
Ups
is
greenups
because
you
have
things
like
discounts,
for
example,
pricing
discounts
and
you
get
them
without
right,
sizing
anything
so
that
doesn't
have
a
impact
on
the
co2.
As
far
as
I
know,
but
of
course
yes,
there
are
a
lot
of.
D
D
I
appreciate
there's
probably
quite
a
few
tools
out
there,
but
how
you
get
to
a
position
where
you
can
actually
create
these
reports
that
go
out
to
your
finance
teams
in
a
format,
that's
actually
consumable
by
them
and
then
a
second
question
which
is
around
the
budgeting
and
the
operationalization,
because
we
work
in
an
environment
where
our
finance
team
are
quite
a
long
way
from
us
and
how
we
go
about
doing
things
like
budgeting
and
financial
preparation,
because
we
work
on
an
annual
cycle
anyway.
Just
those
two
questions,
thank
you.
A
Thank
you
very
much
for
the
question,
and
I
have
so
many
answers
to
that,
but
I
try
to
summarize
them
to
two
main
things.
So
the
very
first
thing
is
that
every
monitoring
tool,
you're
you're,
choosing
whatever
it
is,
has
different
functions
based
on
your
environment.
We
are,
for
example,
working
with
tools
like
loadability.
We
are
working
with
tools
like
cubecost
and
cloud
health
and
you
name
them.
We
met
a
few
here.
A
The
tricky
part-
and
this
is
where,
where
it's
getting
interesting,
is
to
understand
how
your
operation
works
with
the
client
right
now,
I'm
working,
we
implemented
the
tool,
but
we
came
up
with
a
with
certain
individual
thresholds
to
define
okay
when
get
projects
alerted.
When
are
they
getting
recommendations?
What's
the
amount
of
money
where
it's
worth
it
to
actually
get
to
people,
and
then
we
started
creating
reports
first
manually,
then
optimized
them
now
they
get
the
frequent.
A
You
know
feedback
automated
by
the
tool
and
we
have
work
groups
that
come
together
and
now
working
through
those
recommendations.
So
this
was
a
procedural
change
management
coming
with
the
tool,
and
the
second
thing,
as
I
initially
as
you
said,
our
main
job
is
bringing
exactly
those
departments
together.
So
the
projects
we
are
working
in,
we
always
have
the
setup
finance.
Is
there
business?
Is
there
it's
somewhere
everywhere
and
the
main
thing
is
you
have
to
find
allies?
E
A
I
don't
know
if
you're
talking
about
a
basic
example
online
shop,
you
have
to
be
scalable
and
you
have
to
test
that
what
happens
with
your
with
your
workload
when
you
put
traffic
on
it
a
lot,
and
the
second
thing
is
that
you
should
use
the
same
test
parameters
across
the
team.
I
think
that's
that's
the
advice.
I
could
give
you
like
from
scratch,
without
knowing
anything
about
your
project.
F
A
Thanks,
thank
you
for
this
question.
Finnops
is
based
on
a
community
work.
The
phenoms
foundation
is
part
of
the
cmcf,
so
everything
we
do.
We
do
in
kind
of
a
collaboration
in
in
exchange
and
what
we
presented
to
you
are
the
results
of
like
a
lot
of
people
around
the
globe,
talking
about
and
figuring
out
what
there
is
no
standard
yet
in
certain
things,
because
we're
doing
like
we're
still
exploring
this
fairly
new
topic,
but
these
are
the
ones
that
are
like
overlapping
with
whomever
you're
talking.
G
Hi,
thank
you.
I
wanted
to
ask
you
mainly
regarding
labeling,
if
you
had
any
issue
with
partners,
especially
with
fast-changing
teams,
something
if
you
had
any
experience
with
fast-changing
teams
and
labeling
in
the
part
where
I
don't
know,
a
team
changes,
the
name:
how
do
people
set
them
their
labels?
Perhaps
one
uses
an
underscore?
Perhaps
one
uses
a
different
convention.
So
how
do
you
get
around?
Perhaps
that
issue.
A
I'm
three
things
about
that.
The
first
thing
is,
as
I
said,
the
agreed
standard.
So
when
we
did
this
in
my
recent
client
project,
we
sat
together
and
we
had
a
look
of
how
they
the
projects
do
that
in
general
like
do
they,
pascal
or
whatever
kind
of
label
usage
and
based
on
that,
we
developed
the
labels.
We
agreed
on
them
and
we
sent
them
out
to
all
the
projects
and
we
said
like:
okay,
listen,
you
have
like
a
saying
you
have
like.
A
A
So
it's
it's
a
great
standard
and
what
we
are
working
on
right
now
is
policies
that
enforce
that
with
every
resource
deploy
so
basically
using
the
same
labels
we
defined
manually
and
then
put
them
into
policies,
but
there
are
also
tools
that
can
add
virtual
tags,
they're
like
different
ones.
It's
always
a
bit
depends
on
how
how
big
your
environments
and
how
many
projects
you
have
plus
how
much
money
you
want
to
spend.