►
From YouTube: Keynote: How to Love K8s and Not Wreck the Planet - Holly Cummins, Worldwide IBM Garage Dev Lead
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Keynote: How to Love K8s and Not Wreck the Planet - Holly Cummins, Worldwide IBM Garage Developer Lead, IBM
The past five years have been the warmest since records began. Human activity, including the IT industry, is driving worrying climate change. Data centres alone consume 3% of the world's energy, and more and more of that energy is being used by Kubernetes and workloads running on Kubernetes. Is k8s helping, or making things worse? The beauty of the cloud is that it makes it easy to run code, virtualised and scheduled for efficiency... but it doesn't provide any guarantee that what's running is useful. Even when the workload is high-value and efficient, Kube sprawl can lead to low utilisation, unsatisfactory elasticity, and high costs - but mega-mono-clusters have their own problems around isolation, security, and management. How should these competing requirements be balanced? This talk discusses some of the trade-offs and provides a roadmap to figuring out the right thing.
https://sched.co/ZfGQ
A
Hi,
I'm
holly
cummins,
I'm
a
developer
in
the
ibm
garage.
We
build
awesome
applications
for
clients
and
share
cloud
native
development,
best
practices
to
really
help
businesses
get
the
most
out
of
the
cloud.
What
I'm
going
to
talk
about
today
is
the
ecosystem
implications
of
our
favorite
platform
and
by
ecosystem.
I
don't
just
mean
community,
I
mean
the
broader
ecosystem,
the
the
planet
and
the
reason
this
matters
is.
We
have
a
climate
problem.
A
The
earth
is
getting
warmer,
it's
about
one
degree
warmer
than
it
was
in
the
pre-industrial
era,
and
it
seems
like
it's
going
to
go
up
at
least
another
degree
and
that
doesn't
sound
too
bad.
Just
a
couple
of
degrees.
You
think
well
I'll,
eat
more
ice
cream,
but
that
that
few
degrees
matters
it's
it's
not
just
warmer.
A
It's
uncomfortably
warmer,
it's
dangerously
warmer.
It
means
things
like
where
we
grow.
Our
food
is
going
to
become
affected.
It
means
that
we're
going
to
start
seeing
more
droughts
we're
going
to
see
more
floods,
particularly
in
coastal
regions
in
some
coastal
regions.
It's
not
going
to
be
a
question
of
floods.
It's
going
to
be
a
question
of
submersion
they're,
going
to
be
underwater,
we're
going
to
see
more
extreme
weather
events,
more
hurricanes,
more
fires,
so
that's
bad
and
and
but
it
still
seems
kind
of
abstract.
A
A
A
If
we
sort
of
step
back
and
say
well,
what
problem
are
we
even
trying
to
solve
with
kubernetes?
I
think
where
most
of
us
started
on
our
kubernetes
journey.
Is
we
just
wanted
to
run
a
container?
We
had
a
beautiful
container,
we
wanted
to
run
it,
but
then
we
discovered
the
power
of
microservices,
and
so
we
said
instead
of
having
one
container
that's
good,
but
let's
have
lots
of
containers,
let's
connect
them
together.
Once
we
start
doing
that,
then
you
need
an
orchestrator.
A
Kubernetes
is
a
really
awesome
container
orchestrator,
but
then
we
got
more
excited
still
and
we
said
if
one
cluster
is
good,
I
could
have
my
one
cluster
and
then
I
could
have
two
clusters,
three
clusters
and
these
clusters
they
just
they
proliferate,
and
then
we
end
up
with
a
situation.
That's
called
cube,
sprawl
cube
sprawl,
as
the
name
implies,
is
not
so
good
and
it's
really
a
symptom
of
the
fact
that
instead
of
the
container
being
the
unit
of
deployment,
the
cluster
is
the
unit
of
deployment.
A
It's
hard
again,
it's
hard
to
find
good
metrics
for
cube
sprawl,
but
I
looked
at
the
ibm
cloud.
We
have
a
managed
kubernetes
service
and
a
managed
openshift
service,
and
I
thought
I'd
see
maybe
two
clusters
per
account,
maybe
three,
maybe
four-
that
is
21
clusters
per
account
and
I
suspect
those
numbers
are
distorted
by
the
fact
that
probably
some
customers
are
doing
something
else
completely
and
they're,
not
even
even
using
kubernetes,
and
yet
we
still
have
21
clusters
per
account.
A
So
that's
like
it's
a
lot
of
clusters
and
in
order
to
figure
out
whether
this
is
okay
or
not,
we
need
to
look
at
the
energy
characteristics
of
kubernetes
and
there's
two
important
concepts
here.
One
is
utilization,
the
other
is
elasticity,
so
utilization
is
how
much
of
a
computer
we're
using.
So
if
we
have
a
huge
64
core
computer
and
we've
just
got
one
tiny
little
enginex
server
running
on
it,
that's
not
so
good.
One
of
the
reasons
mainframes
actually
have
really
really
good.
Energy
efficiency
is
because
they
have
phenomenally
high
and
utilization.
A
A
A
We
can
just
change
the
replica
account,
we
can
do
it
manually
or
we
can
have
something
like
horizontal,
auto
scaling.
So
we
can
scale
up.
We
can
skip
it's
all
good,
but
the
cluster
is
much
less
elastic
than
the
application.
I
think
for
a
while.
I've
been
kind
of
troubled
by
the
elasticity
characteristics
of
kubernetes
clusters.
You
can
turn
on
the
cluster
auto
scaling,
but
it
it's
sort
of
it.
A
It's
a
bit,
maybe
not
doing
what
you
always
wanted.
It
tends
to
scale
up
a
lot
more
aggressively
than
it
scales
down
and
if
your
aim
is
to
increase
utilization,
that's
not
necessarily
what
you
want.
There
is
a
lag,
so
it's
maybe
it
doesn't
solve
everything
and
the
other.
The
other
issue
is
that,
even
if
we
have
really
good
scaling
on
our
cluster
either
we
do
it
manually
or
with
auto
scaling,
and
we
get
that
high
utilization.
A
Well,
the
control
plane
itself
has
an
overhead,
so
that
means
more
proportionately.
More
of
our
cluster
is
used
for
the
control
plane.
So
that's
not
that's
not
great
in
terms
of
efficiency
and
it
matters
because
the
things
running
our
cluster
are
real
computers
they're.
They
may
be
virtual
computers,
but
there's
actual
hardware
there.
It's
not
just
an
abstract
thing
in
the
cloud.
A
We
hear
a
lot
of
talk
about
serverless
and
it
how
it's
it's
so
great
for
energy
efficiency
and
it's
so
elastic
and
in
a
kubernetes
context,
that's
k-native
and
it
really
does
have
great
elasticity.
You
can
scale
it
down
to
zero,
but
it's
still
running
in
that
cluster.
So
unless
we
fix
the
elasticity
of
the
cluster
k
native,
isn't
going
to
help
us
that
much
and
so
then
the
question
is
well.
Why
does
this
happen?
Why
do
we
have
all
these
underutilized
clusters?
And
it's
not
that
any
of
us
are
malicious?
A
You
know
that
we're
doctor
malice
going.
I'm
gonna
burn
all
my
company's
money
and
I'm
gonna
destroy
the
planet
as
a
bonus.
You
know
these
things
don't
happen
on
purpose.
They
just
happen
kind
of
by
accident
for
a
lot
of
small
good
reasons
and
with
kubernetes
it.
We
hoped
that
we'd
be
able
to
use
namespaces
to
support
really
good
multi-tenancy,
but
we
all
know
namespace
isolation.
It's
not
enough.
There's
reasons
where
you
just
need
your
own
cluster.
A
A
Earlier
in
the
year
I
had
a
tecton
build
and
I
had
prometheus
monitoring
and
there
was
some
horrible
interaction
between
the
two
and
so,
whenever
we
ran
a
build,
the
performance
of
the
whole
cluster
ground
to
a
halt
that
was
kind
of
okay
for
our
team,
because
our
team
was
the
only
one
using
the
cluster.
But
if
someone
else
had
been
using
the
cluster,
I
would
have
been
really
mad
at
them.
Taking
all
my
resources
and
because
I
wanted
them,
we
see
other
problems
with
things
like
name
collisions
some
artifacts
like
crds.
A
A
We
also
see
that
you
know,
even
if
someone,
even
if
finer
grained
scoping,
is
available,
people
don't
necessarily
remember
to
use
it
and
of
course
all
of
that
is
assuming
that
we
trust
the
other
users
in
the
cluster
and
that
we
trust
the
security
and,
if
you've
been
paying
any
attention,
t
and
cold
water.
You
know
kubernetes
is
not
secured
by
default.
We
need
to
take
some
action
to
protect
ourselves
and
the
most
sensible
action
as
a
basic
action
is
to
isolate
prod.
A
A
So
let's
say
we
do
that
and
we've
got
a
cluster
and
it's
got
really
high
utilization.
So
are
we
winning
in
climate
terms,
not
necessarily
because
it
depends
what
the
workload
is?
Our
industry
has
a
really
horrible
problem
with
zombie
workloads,
so
this
is
stuff,
that's
running,
but
it
doesn't
have
any
value.
I
saw
one
survey,
they
they
looked
at
16
000
servers
and
they
found
that
a
quarter
of
them
were
doing
no
useful
work
and
what
they
speculated
had
happened
was.
Perhaps
someone
forgot
to
turn
them
off.
So
again
it
wasn't
malice.
A
A
So
it
was
about
a
thousand
pounds
a
month
and
it
just
been
sat
there
burning
electricity
and
not
actually
doing
anything
useful
for
for
two
months,
so
slightly
awkward
conversation,
because
the
thing
is
even
if
we
don't
care
about
the
money,
it's
still.
It's
still
pollution,
it's
still
fossil
fuels,
80
of
data
center
energy
is
fossil
fuel.
So
it's
pollution,
it's
climate
change.
A
So
what
do
we
do
about
it?
Well,
there
are:
there
are
solutions
to
zombie
workloads,
some
of
them
are
manual.
I
spent
a
fairly
boring
three
hours
in
a
meeting
with
a
uk
bank
and
the
cio
was
trying
to
figure
out
where
his
cloud
spend
was
going,
and
so
we
all
just
sat
there
going
through
everything
trying
to
figure
out
what
it
was
for.
I
don't
recommend
that
as
an
approach,
one
thing
that
we
try
and
do
instead
a
lot
of
teams
mandate
that
everyone
adds
tags
to
a
cluster
when
they
create
it.
A
So
we
can
try
and
have
some
traceability,
that's
still
pretty
manual.
It
still
relies
on
someone
tracking
down
what
the
tags
mean.
It
still
relies
on
people
remembering
to
put
the
tags
in
and
with
all
of
these
solutions,
because
they're
so
manual,
they
they
take
the
cloud
and
the
thing
that
we
really
love
about
the
cloud
is
it's
so
frictionless,
and
then
you
put
this
sort
of
cage
of
governance
on
it
to
try
and
avoid
this
wild
west
scenario
of
clusters
being
created
and
not
de-provisioned,
and
it
takes
away
the
joy
of
the
cloud.
A
So
I
think
the
best
solution
really
is
one
where
it's
easier
to
do
the
right
thing
than
not
one
easy.
Surprisingly
effective
solution.
A
colleague
told
me
about
it.
He
was
working
with
a
bank
and
they
had
a
really
big
zombie
server
problem.
So
what
they
did
is
they
implemented
a
system
where,
when
you
provisioned
something
you
had
to
set
an
expiry
date,
you
could
extend
it,
but
it
would
get
auto
deleted
that
reduced
their
usage
by
half.
A
Just
that
really
simple
thing
of
auto
deleting
and
we
can
do
more
sophisticated
things
as
well,
so
we
can
start
using
ai
and
that
kind
of
thing
so
we're
seeing
a
lot
of
innovation
in
the
area
of
multi-cloud
management,
we're
seeing
cool
things
with
traffic
monitoring
just
to
look
and
detect
those
servers
that
don't
have
anybody
talking
to
them
for
kubernetes.
I
think
we
sometimes
imagine
that,
because
it's
so
easy
to
provision
clusters.
It
doesn't
have
that
zombie
problem,
but
of
course
I
I
think
it's
the
opposite.
It
makes
it
easy
to
provision
the
clusters.
A
A
Get
ops
helps
a
lot
with
this,
and
what
I
mean
by
git
ops
is
not
argo
or
flux,
but
just
that
more
general
thing
of
infrastructure
as
code,
because
what
that
gives
us
is
disposable
infrastructure.
We
have
a
cluster,
we
can
throw
it
out.
If
we
want
it
back,
we
can
get
it
back
from
source
control.
If
we
change
our
mind,
we
can
spin
it
down
again.
We
can
get
it
back
up
again.
This
is
also
great
for
disaster
recovery.
A
That's
the
data
centers
contributing
what
we
can
do
about
it
if
you're
a
tool
creator,
just
adjusting
how
you
think
about
your
tool
to
really
support
that
high
utilization
to
support
the
multi-tendency
to
support
the
elasticity.
That
makes
a
difference
and
if
you
can
have
innovations
around
de-zombification,
that's
awesome
as
well,
and
then,
if
you're,
a
user,
you
need
to
take
advantage
of
what
the
tool
creators
are
providing.
So
you
need
to
be
driving
that
utilization
up.