►
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
Cluster performance impacts not only the performance of your workloads, but the bottom line of your business as a whole. Inefficient Kubernetes cluster performance can quickly lead to resource wastage, poor utilization, and higher cloud costs.
This session will take a comprehensive look at Kubernetes cluster performance considerations and resource management best practices. We will walk through core concepts such as resource pressure, pod eviction, OOM and cgroups, and demonstrate how the Kubernetes scheduler behaves as a result. Learn how to identify the metrics that are most important for understanding cluster performance and the queries you should use to monitor these metrics with Prometheus and Grafana. We’ll visualize these performance metrics using a pre-built Grafana dashboard as individual graphs, and explore the ways in which these metrics affect not just workload performance but the overall impact to cluster cost of ownership.
A
Who's
joining
us
today
welcome
to
today's
CN
CF,
webinar,
kubernetes
cluster
performance,
resource
management
and
cost
impacts
on
Jorge
Castro
community
manager,
VMware
in
a
cloud
native
ambassador
I'll
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenters
today.
Elijah
a
young
kool-aid
platform,
engineer
reflux
and
Hassan
Haider
developer
marketing
at
reflux
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
talk
as
an
attendee
there's
a
Q&A
box
at
the
bottom
of
your
screen.
A
Please
feel
free
to
drop
in
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
CN
CF
and
is
such
a
subject
to
the
CN
CF
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
of
all
your
fellow
participants
and
presenters.
With
that
I'll
hand
it
over
to
Elijah
and
Hassan
to
kick
off
today's
presentation.
B
Hello:
everyone
thanks
about
for
joining
us
and
welcome
to
the
webinar.
So
the
topic
that
we
are
going
to
talk
about
today
is
kubernetes
cluster
performance,
resource
management
and
costs
impact.
My
name
is
Hasan
and
I'm.
The
developer
advocate
of
free
blacks,
so
I'll
be
going
through
some
of
the
slides,
just
kind
of
putting
the
entire
topic
into
context
and
explaining
the
context
of
cluster
performance.
B
You
know
what
you
mean
when
we
say
faster
performance
and
then
kind
of
identifying
the
metrics
that
are
important
in
the
context
of
class
of
performance,
and
then
we
also
have
Elijah
with
us
on
the
call
who
is
platform
engineer
at
reflex
and
he'll
be
digging
into
a
lot
of
the
technical
stuff.
You
know
they
begin
to
Prometheus
the
queries
that
I
used
to
monitor
cluster
performance,
metrics
and
yeah
also
gave
us
giving
us
a
walkthrough
of
a
pre-built
graph
on
a
dashboard
to
monitor
cluster
performance.
B
He'll
also
be
giving
us
an
overview
of
the
entire
metrics
flow
from
kubernetes,
Prometheus,
crow
fauna
and
yeah
everything
everything
in
between
all
right.
So
just
a
couple
of
words
about
free
Plex
before
we
get
started.
So
a
reflex
is
the
governance
and
cost
management
platform
was
built
for
modern
cloud
native
infrastructure,
so
I
mean
essentially,
it
gives
finance
and
cloud
managers
a
comprehensive
look
or
visibility
into
total
spend
across
across
infrastructure
and
along
with
granular
insights,
into
the
cost
of
individual
applications
and
teams.
B
You
know
at
the
same
time
it
empowers
developers
and
operators
to
right-size
resources
for
for
optimal
spend
without
sacrificing
performance,
alright
cool,
so
yeah,
let's
get
started.
You
know
just
to
give
some
context
to
what
we're
going
to
be
talking
about
here
today.
So
we
have
a
couple
of
statistics
in
terms
of
performance
in
utilization
that
shouldn't
nicely
frame
the
topic.
So
one
is
that
40%
of
instances
are
one
to
two
sizes,
bigger
than
needed
for
the
workloads.
B
So
when
we
say
that
these
instances
are
too
big
for
the
workloads,
we're
essentially
talking
about
the
fact
that
you
know
these
instances
are
not
being
utilized
efficiently.
I
mean
the
utilization
is
low,
so
essentially
low
utilization
translates
into
into
resource
wastage,
which
in
turn
means
where
sits
and
as
you
can
see
in
the
second
statistic
that
you
know
we
have
50
to
75%
of
the
money
being
spent
on.
These
instances
is
being
wasted.
B
So
yeah
right
now,
I
guess
you
probably
thinking
you
know.
This
is
a
verb.
You
know
about
kubernetes
and
containers
so
I'm,
you
know.
Why
are
we
talking
about
cloud
provider
instances?
So
why
should
we
be
worried
about
instances?
And
you
know
workload?
Size
is
a
neutralization,
so
in
fact
I
mean
everyone
can
agree
that
kubernetes,
you
know
kind
of
makes
it
easier
for
devops
to
do
their
jobs.
You
know
it
essentially
abstracts
a
lot
of
the
heavy
lifting
the
DevOps
teams
usually
do
and
makes
it
easier
to
provision
and
manage
infrastructure.
B
B
So
when
we
talk
about
you
know
kind
of
complexity
and-
and
you
know
the
the
the
complexity
that
communities
introduces
on
the
operational
side
of
things
so
I
mean
in
the
context
of
performance
and
cause.
Not
only
do
we
have
to
kind
of
consider
the
extent
which
the
underlying
infrastructure
or
the
other
cloud
instances
that
the
communities
is
essentially
running
on.
B
You
know
we
don't
only
have
to
look
at
the
utilization
of
their
infrastructure,
but
we
also
have
to
think
about
the
utilization
of
you
know,
pods
or
workloads,
and
how
well
they
are
performing
in
terms
of
utilization
and
performance.
So
one
reason
for
this
is
that
kubernetes
introduces
the
concept
of
resource
requests
and
limits.
B
All
right
so
now
that
we've
looked
at,
you
know
why
it
is
important
to
monitor
the
utilization
of
Cobre,
discusses,
we'll
take
a
look
at
a
couple
of
other
numbers.
You
know
in
the
context
of
performance
and
cost,
so
fourteen
billion
is
essentially
being
wasted.
Yearly
in
public
cloud
spend
on
idle
or
unused
resources.
You
know
all
provision
instances.
B
5.3
billion
of
this
is
versat
on
oversized
resources
alone,
so
I
mean
we
see
this
as
a
huge
problem.
Where
I
mean
more
these
workloads-
and
you
know
most
of
the
infrastructure
that
is,
there-
is
provision
to
run
these
workloads
are
not
being
utilized
efficiently,
which
is
you
know,
essentially
driving
up
the
costs
without
really
adding
anything
to
the
to
the
bottom
line.
B
So
yeah
I
mean
in
today's
webinar.
What
do
you
want
to
discuss?
Is
cluster
performance
and
you're
going
to
frame
this
concept
of
cluster
performance
in
terms
of
you
know
three
distinct
aspects:
the
first
one
is
cluster
utilization
for
cluster
utilization.
We
will
explore
kind
of
how
efficiently
the
underlying
infrastructure
is
being
used.
You
know
what
what
what
is
the
utilization
of
the
individual
cloud
instances
as
well
as
of
the
cluster
as
a
whole?
B
Then
we
look
into
workload,
efficient
efficiency
and
so
by
workloads.
You
know
we
mean
containers
on
ports
and
you
know,
as
we
discussed
earlier
communities
kind
of,
introduces,
this
concept
of
resource
requests
and
limits,
so
we'll
be
looking
at
the
efficiency
of
containers
and
ports
and
whether
they
being
you
know
whether
they're
using
the
requested
resources
efficiently.
You
know,
and
if
they're
not
you
know
what,
what
what
is
what
can
be
done
to
ensure
that
they're
being
used
efficiently?
You
know
which,
which
can
potentially
give
us
a
better
utilization.
B
The
third
aspect
that
we
want
to
talk
about
would
be
I.
Do
resources
and
I
mean
this
would
be
more
in
the
context
of
developer
environments,
so
develop
environments.
Often
you
know
only
needed
during
the
week
week
days.
They
don't
need
to
run.
You
know
over
the
weekend,
maybe
or
they
do
not
need
to
run
the
evening
of
hours
so
kind
of
looking
at.
You
know
how
we
could
reduce
the
number
of
these
idle
resources.
B
B
You
know
how
we
can
more
it
using
open-source
tools
like
Prometheus
and
Ravana
and
yeah
I
mean
don't
kind
of
walk
through
pre-built
crap
on
a
dashboard,
so
yeah
cool.
Let's
jump
now
to
the
cluster
utilization
aspect
of
cluster
performance,
so
I
mean
let's,
let's
take
the
example
of
a
kubernetes
cluster
with
a
wall
cannot,
you
know
like
and
I'm
5
X
large
AWS
instance,
so
we've
got
four
pods
running
on
this
instance,
and
every
port
is
requesting
one
CPU.
B
The
limits
are
two
CPUs,
so
I
mean
essentially
what
kubernetes
is
going
to
do
in
in
this
case.
Is
it's
going
to
set
aside?
You
know
it's
going
to
guarantee
you
one
CPU
for
each
port,
and
this
cannot
I
mean
this
once.
If
you
cannot
be
then
once
it's
reserved,
it
cannot
use
by
any
other
port
or
container
and
I
mean
so
we
also
have
limits
of
two
CPUs.
B
So
if,
if
a
container
you
know
starts
to
exceed
the
limits,
it
could
be
total
by
Cuban
leaders
or
it
could
move
it
to
an
even
node
you
know,
which
has
which
has
enough
resources
to
fulfill.
You
know
the
requirements
of
this
board,
so
yeah
I
mean
what
happens
if
our
application
starts.
We
exceed
the
maximum
CPU
location,
so
kubernetes
will
essentially
move
this
port
to
another
node
and
now
I
mean
the
new
node
has
only
has
support
for
running.
B
So,
for
example,
you
could
replace
this
with
a
t-to
medium
in
OBS
inserts,
which
has
two
CP
and
hg
of
memory,
and
I
mean
essentially
resizing
no
to
will
will
give
us
a
much
better
utilization
of
50%
and
then
I
mean
the
smaller.
You
know:
AWS
t2
instance.
It
also
costs
less
so
I
mean
this
essentially
means
that
you
know
we're
reducing
the
sauce
message.
Are
we
improving
utilization
and
we
are
cutting
down
on
costs.
B
All
right
that
was
cluster
utilization.
Next,
we'll
look
at
a
mix
of
customer
utilization,
so
I
mean
yeah.
We
again
we
take
the
example
of
a
node
which
has
six
pods
running
on
top
of
it,
and
each
of
these
nodes
is
requesting
one
CPU
and
they
have
a
little
bit
of
two
CPUs
but
the
real
resource
usage.
Your
consumption
of
these
costs
is,
you
know,
point
to
CPU.
So
essentially,
the
pods
are
only
utilizing
20%
of
the
allocated.
Cpu
resources
and
I
mean
as
we've
mentioned
she's.
B
You
know
these
Ross's
resources
are
reserved
by
Cuban
leaders.
They
cannot
be
used
by
any
other
parts
and
are
therefore
being
wasted.
You
know,
and
you
know
kind
of
getting
to
the
costs
and
I
mean
what
what
we
want
to
bring
forth
in
this
is
I
mean.
Essentially,
this
is
not
very
efficient,
because
looking
at
the
actual
resource
usage
of
the
core
of
the
parts
we
could,
you
could
have
much
lower
resource
footprint
for
these
pods
and
I
mean.
If
we
do
that,
we
reduce.
We
reduce
the
requested
resources
to
two
point
three.
B
B
But
what
does
this
mean
for
the
node
I
mean
we
do
get
a
much
better
CPU
utilization
for
the
port's,
but
the
north
still
has
the
same
CPU
footprint,
and
so
it
also
makes
sense.
You
know
in
this
case
to
look
at
node
utilization
and,
as
you
can
see,
I
mean
you
only
get
a
not
getting
a
node
utilization
of
15%,
so
I
mean
essentially.
The
reason
for
this
is
that
the
actual
usage
of
four
pods
is
still
you
know
same,
which
is
point
to
CPU
and
where's.
B
You
know
our
nods
less
the
larger
resource
footprint,
so
that
I
mean
we
could
also
reduce
the
size
of
the
node.
You
know,
and
if
we
can
use
resize
the
node
to
two
CPUs.
You
know
something
like
a
tea
to
medium
LDS
instance,
so
we
get
also
a
much
better
or
a
much
higher
CPU
utilization
of
60%
for
the
for
the
node.
B
All
right
so
now
I
mean
putting
all
of
this
in
context
and
kind
of
thinking
of
this
in
terms
of
Public
Health,
where
reading
instances,
so
you
know
I
mean
since
most
kubernetes
workloads
are
running
on
public
cloud
providers.
You
know
looking
at
the
size
of
the
cluster,
you
know
and
the
instance
is
in
the
utilization
and
kind
of
making
informed
decisions
to
right-size
clusters
based
on
based
on
actual
utilization,
has
huge
implications
for
the
kubernetes
costs,
so
I
mean,
as
you
can
see,
we've
got
three
instances.
You
know
that
they
have
different
resource
footprints.
B
They
also
have
different
price
tags.
So
essentially
matching
you
know
the
size
and
usage
of
workloads
with
with
the
actual
footprint
or
for
instances,
and
then
you
know
kind
of
choosing
the
one
which
gives
us
a
much
better
utilization.
You
know
it's
a
great
way
to
kind
of
reduce
wastage,
improve
utilization
and
also
reduce
public
cloud
provider.
Spin,
but
yeah
I
mean,
as
you
know,
I
guess
in
real
life.
It's
not
it's
not
always
as
easy.
As
that,
you
know
actual
production
clusters
or
on
multiple
instances.
B
You
know
and
organizations
you
know,
have
multiple
clusters,
so
I
mean.
Essentially
what
makes
sense
in
that
case
is
to
kind
of
look
at
this
in
terms
of
overall
cluster
utilization.
You
know
and
then
taking
proactive
steps
to
reduce
you
know
or
maybe
increase
the
size
of
the
cluster
based
on
actual
utilization
and
the
actual
resource
consumption.
You
know
and
then
making
kind
of
informed
decisions
based
from
that
real
time,
data
that
is
coming
in.
B
Moving
on
to
the
next
aspect
of
cluster
performance,
you
know
where
we
talk
about
development
environments
and
I
mean
to
kind
of
put
this
in
context.
You
know
development
environments
account
for
44%
of
compute
spend
and
I
mean
essentially
these
development
environments
that
they
do
not
need
to
run
24/7.
You
know
that
they're,
not
production
workloads,
most
of
them
do
not
need
to
run
on
the
weekends.
You
know
they
do
not
need
to
be
up
and
running
during
off
hours.
B
So
I
mean
in
this
section,
if
you're
going
to
look
at
some
Native
communities
abstractions
that
we
can
use
to
try
actively
monitor
the
the
resource,
consumption
of
development
environments-
and
you
know,
and
also
to
control
it
and
to
ensure
that
these
workloads
are
not
up
and
running
24/7.
You
know
we
can
shut
them
off
during
off-hours
and
in
in
the
process
we
see
reduce
resource
wastage
and
spend
so
the
first
thing
to
do
in
this
regard
is
to
kind
of
isolate,
developing
environments
and
kubernetes.
Has
this
really
nice
abstraction
to
do
that?
B
So
kubernetes
has
this
concept
called
namespaces,
which
we
can
use
to
isolate
all
the
resources?
You
know
there
are
spannabis
part
of
the
development
environment,
so
we
can
create
a
namespace,
a
monolithic,
namespace
namespace
for
the
entire
development
environment,
or
you
know,
depending
on
the
scope
of
development
activities.
You
know
we
can
also
isolate
developer
teams.
So
if
you've
got
multiple
teams,
we
can
create
a
separate
namespace
for
each
of
those
individual
development
teams.
You
know
it
kind
of
isolate
the
resources
that
I
used
by
the
by
those
teams
using
namespaces
and
adding.
B
Since
we
are
isolating
the
resources,
we
can
then
control
the
consumption
of
of
the
namespace.
The
resource
comes
on
corruption
of
the
namespace
using
other
native
kubernetes.
You
know
tools
and
in
the
process
also
control.
You
know,
I'm
control,
the
resource,
consumption
of
the
develop
environments
or
the
developer
teams
is
all
so
yeah.
We
will
take
a
look
at
some
of
these
abstractions
in
the
next
couple
of
slides,
so
once
you've
isolated
the
resources
of
the
development
teams
by
creating
separate
namespaces.
What
we
can
then
do
is
to
kind
of
create.
B
You
know
default
CPU
request
limits,
so
I
mean
we
can
define
these
as
part
of
a
limit
range
object,
and
once
we
have
this
limit
range
object
created,
you
know,
kubernetes
will
ensure.
You
know
that
if
any
developer
spins
up
a
portal
container
and
their
namespace
without
defining
the
requests
and
limits,
so
it
will
automatically
attach
those
default
values
to
those
containers.
B
We
can
do
the
same
for
memory
requesting
limits.
You
know
as
part
of
a
limited
range
object,
and
you
know
kubernetes
will
ensure
that
you
know
these
default
values
that
I
defined
in
in
the
in
the
limit
and
in
the
limit
range
object
automatically
applied
to
any
containers
that
do
not
have
these
limits
or
requests
defined.
B
So
with
the
limit
range
object,
I
mean
we
can
also
control
or
control
the
minimum
and
maximum
CPU
constraints
for
individual
containers.
So
we
define
a
limit
range
object
for
the
for
the
developer
namespace.
You
know
we
define
the
minimum
either
the
maximum
or
the
higher
limit
for
the
amount
of
CPU
that
can
be
allocated
to
individual
containers,
and
then
we
also
define
the
minimum
amount
of
CPU
that
can
be
allocated
to
those
containers
and
yeah
I
mean
once
we
create
this
limit
range
object.
B
You
know,
kubernetes
is
going
to
ensure
that
you
know
if
any
container
that
is
spawn
up.
You
know
the
resource
frequency
limits
of
that
container,
you
know,
is
it
falls
within
within
it's
this
specific
range
that
we
really
find
so
yeah
I
mean.
Essentially,
we
are
controlling
the
resource,
consumption
of
of
individual
containers
and
then
I
mean
since
we
we've
isolated
these
resources,
and
we
are
talking
about
the
developing
environment,
so
yeah
I
mean
essentially
be
controlling
the
resource.
Consumption
of
of
the
entire
development
environment.
B
B
And
as
part
of
the
resource
core
object,
I
mean
we
can
also
control
the
number
of
pods
that
are
allowed
to
run
in
the
developer.
Developer,
namespace
and
I
mean
in
the
same
way
we
can.
We
can
if
we
can
control
the
number
of
services,
we
can
control
the
number
of
persistent
persistent
volumes,
load,
balancers,
not
pods,
and-
and
you
know,
replication
controllers
and
I
mean
you
know.
B
Essentially,
since
this
most
of
these
objects
you
know,
are
consuming
CPU
and
memory
resources
from
public
cloud
for
instances
or
you
know
there
may
be
abstractions
on
public
cloud
provider
services
so,
for
example,
not
not
ports
or
load
balances,
which
I
essentially
I
mean
abstractions
on
the
public
cloud
provider
services,
so
I
mean
they're,
essentially
adding
costs
on
the
public
cloud
provider
side,
so
I
mean
since
kubernetes
allows
us
to.
You
know,
control
the
number
of
these
objects
that
can
run
in
the
developer.
B
We
can
quickly
spin
them
down
based
on
need,
so
I
mean,
let's
say
on
the
weekends
or
you
know
in
off
hours.
We
don't
need
those
resources,
so
we
can
quickly
spin
them
down.
You
know,
since
they've
already
been
I
mean
isolated,
alright,
yeah
cool,
so
now,
I'll
Alaska
lies
you
take
off
from
here
and
and
we'll
be
doing
technical,
deep
dive.
C
C
Hi
everyone
I'm
Elijah,
and
now
we
are
going
to
be
examining
the
metrics,
the
metrics,
that
you
can
use
to
so
evaluate
the
performance
of
your
kubernetes
cluster.
So
first
we're
going
to
be
looking
at
we're
going
to
be
examining
weird
the
kubernetes
metrics
come
from
and
we
are
going
to
be
running.
Some
parameters
queries
to
run
some
analysis
and
then
we
are
going
to
be
going
going
through
a
graph
on
a
dashboard
that
we
have
prepared
for
this
presentation.
So
I
have
a
ravaged
communities.
C
C
Is
the
Nordics
pata
neurons
on
Darwin's
on
every
node
in
the
cluster
and
gets
gets
low
level
metrics
about
each
each
each
node
in
the
cluster,
such
as
the
available
memory
network
devices
and
the
love
with
our
information
that
are
provided
by
the
kind
of
running
on
each
node,
then
we
are
also
going
to
be
examining
the
container
specific
metrics
that
I
exposed
with
C
advisor.
So,
first
we
are
going
to
see
some
of
the
metrics
that
are
exposed
by
the
Nordics
water.
C
C
So
when
you,
when
you're,
going
through
your
parameters,
metrics
when
you
see
a
new
metric,
but
this
perfect
star
is
coming
from
so
we
can
see
a
lot
of
metrics
around
about
the
total
nodes
in
your
file
system.
You
can
see
metrics
about
IP,
V
connections,
packets,
then,
here
we
come
to
some
metrics
that
we
that
we
would
find
interesting.
For
example,
we
have
memory.
C
B
C
On
the
node
exporter
and
all
these
metrics
are
going
to
be
available
to
query
upon
next,
we
are
going
to
look
at
some
of
the
metrics
that
are
exposed
by
the
tablet,
so
the
not
expert
exports
metrics
about
the
about
the
low-level
information
for
each
node,
while
the
tablet
so
I
have
I
have
three
nodes
running
across
town
of
forwarded,
one
of
the
a
port
on
one
of
my
notes
to
my
local
port.
So
the
cubelet
runs
on
this
pot.
C
So
this
c
advisor
is
a
component
of
the
cubelet
that
forgets
that
we
getting
these
useful
metrics
doors.
For
example,
we
can
see
metrics
around
the
container
ship,
you
load
average
over
the
last
10
seconds.
We
can
also
see
metrics
around
the
total
time
that
data
point
entire
container
spent
spent
executing
system
applications
we
so
this
is.
This
is
one
of
the
main.
This
is
the
main
metric
that
is
like
that
is
that
is
exported
by
the
sea,
advise
of
the
container
CPU
usage
seconds,
and
with
this
we
can,
we
can
get.
C
We
can
get
the
metrics
that
are.
We
can
get
the
philosophy
use
accounts
that
are
used
by
each
container
in
our
metric.
We
can
see
some
of
the
livers
for
each
for
this
metrics
that
has
a
namespace,
the
port
that
the
arm
that
the
container
is
running
as
a
part
of
we
can
see
the
container
name.
The
intent
there's
also
the
histones
that
the
Taconic
on
tonight
running
on
so
this.
C
So
this
metrics
are
exposed
by
cubelets
running
on
national
and
then
our
parameters,
cluster,
our
punctures
in
installation,
has
been
configured
to
scrape
so
to
scrape
the
cubelets
that
we
have,
as
well
as
the
advisor
endpoint
and
also
the
node
exporter.
So
when
you
install
parameters
into
your
community,
some
of
these
are
automatically
their
service
discovery.
So
you
can
see
it's
it.
Scripts
love
what
that
targets
such
as
code,
Ian,
Ayres,
the
API
server,
and
so
some
of
the
metrics
that
we've
I
will
just
looked
at
over
HTTP
we're.
C
We
don't
try
to
exit
to
run
some
queries
on
them
now
in
the
parameters
auto.
So
one
of
the
one
of
the
metrics
one
of
the
queries
that
were
going
to
run
in
now
is
to
calculate
the
severe
time
consumed
our
CPU
in
nanoseconds.
So
this
so
this
metric
that
we're
gonna
be
using
is
one
of
them.
We
just
saw
that
was
exposed
by
the
advisor.
C
So
what
is
Clara
does.
Is
it
advocates
this
on
the
overall
of
our
rows?
We
use
speed
usage,
one
as
five
minutes
by
name
space,
port
and
container.
So
when
we
execute
this
query,
we
can
see
you
can
see.
So
we
get
we
get
our
results,
so
we
can
see
the
font
anomaly
the
name
space
and
then
the
port
one
in
this
particular
point
you
know-
and
we
can
say
for
all
the
continents
in
our
cluster.
So
this
is
the
the
this
is
the
total
seconds
that
the
continent
spent
executing
over
the
past
five
minutes.
C
So
next
we
don't
we
don't
you
look
at
and
out
metric
weather
coverage.
You
find
to
calculate
total
memory
available
in
our
cross
up
and
then
we
are
going
to
be
aggregating
by
node,
so
so
run
in
discovery.
Now
we
can
see
that
we
in
our
communities
cluster.
We
have
about
72%,
available
memory
in
our
communities
cluster
next
weekend,
we're
looking
at
so
we
can.
We
can
go
to
the
craft
section
to
see
to
see
the
trend
in
this
particular
query
over
the
past
one.
C
C
C
Of
for
the
nodes
of
other
modes,
also
that
that
the
CPU
has
paint
some
shiny,
so
the
idle
mode
is
so
this
for
this
other
modes,
the
speed
is
actually
do,
is
actually
being
active,
but
when
it's
high
that's
time
that
disappear
isn't
doing
anything
at
all.
So
you
would
want
to
ensure
that
you
are
getting
the
USB
you
I
do
a
lot
of
the
time.
C
So
this
query
is
going
to
tell
us
how
much
time
the
how
much
time
our
superior
spent
in
the
so
we
because
we're
subtracting
it
will
inform
what
the
what
this
is
going
to
return
is
the
time
that
you
spent
not
idle.
So
we
can
see
that
that's
about
eleven
percent,
so
this
cluster
has
really
no
Sabine
utilization,
eleven
percent.
C
So
so
yes,
so
this
so
we've
looked
at
three
color
is
now
that
you
can
use
to
to
get
some
of
to
get
some
overview
but
into
the
current
utilization
of
yet
roster.
But
this
so
with
this
queries,
you
can
be
able
to
build
a
natural
dashboard
that
you're
going
to
be
using
to
monitory
T.
The
current
performance
of
your
but
I
hope
you
lost
at
a
particular
time,
so
one
of
a
very
useful
tool
to
do
that
is
graph
a
now
and
graph
a
now,
our
buting
support
for
Prometheus.
C
C
So
this
dashboard
Arriaga
is
the
body
into
four
sections.
We
have
a
clustered
general
overview
of
the
utilization
in
Kosta
and
we
have
we
have
a
breakdown
by
pod,
wherever
breakdown
by
namespace,
then
we
have
a
breakdown
by
note,
so
I'm,
taking
a
look
at
our
club
style
overview.
The
superior
utilization
childish
only
knows
how
much
how
much
of
us
you'll
spend
utilize.
That
is
back
my
time.
My
utilization
is
doing
the
same
for
memory
while
to
disk
utilization
is
telling
us
how
much
free
disk
we
have
on
each
of
our
nodes.
C
The
superior
requests
commitment
is,
is
so
one
of
the
ways
to
to
manage
to
manage
to
manage
cluster
resources,
as
a
shaman
pointed
out
is
through,
is
by
specifying
CP
requests
on
memory
requests
for
each
chord
in
your
for
yo
for
your
pods.
So
this
is
telling
us
how
much
superior
and
requested
by
the
pods
on
our
cluster,
as
as
a
percentage
of
the
overall
CPI
that
we
have-
and
this
is
doing
the
same
for
for
memory.
So
the
query
behind
this
CPU
utilization,
who
graph
is
this-
is.
A
C
C
Just
again,
just
again
just
dividing
the
free
bytes
right
now
bytes
is
not
going
to
account
for
some
for
some
other
kinds
of
memory
that
it
kind
of
is
B
is
using
for
cash
offense
at
that
time.
So
we're
gonna,
add
up
everything,
so
this
presents
a
realistic
figure
for
how
much
of
our
memories
may
just
at
the
moment
and
divided
by
the
total
memory
for
our
notes
and
then
remove
that
from
one.
So
that's
how
we
get
the
power
equation
at
this
particular
time
next,
the
disk
utilization.
C
C
C
C
C
C
Then
we
do
the
same
for
memory
usage,
Sapiro
quests
under
my
request,
then
in
our
notes
section
we
also
have
similar
charts
here
and
the-
and
here
you
can
see
it's
it's
advocated
by
note.
Then
we
we
now
have
an
extra
three
sections
for
severe
tonight
shown
you
get
that
by
note.
So
this
is
just
a
fairly
complex
curry.
What's
the
main,
the
main
query
we,
the
main
metric
by
destiny,
is
the
notice
appears
a
constitute
all
so
it's
and
then
we.
So
we
are
also
Stratton
from
one.
C
So
the
total
time,
that's
the
spirit,
I
do
and
then
we
are
running
a
joint
to
to
an
existing,
so
an
existent
from
it
just
rule.
So
what
this
so
combining
this?
What
this
gives
us
is.
It
also
be
super
utilization
for
each
node
in
the
cluster,
and
then
we
also
have
memory
utilization
graph
here
and
then
we
have
this
kitten
ization,
oh,
so
this.
What
is
but
can
give
you
are
they
good
clearance,
is
insight
into
the
current
utilization
and
performance
of
of
your
cluster
at
over
the
past
fifteen
minutes.
C
So
this
so
this
is
provided
by
graph
and
you
can
you
can
you
can
increase
the
the
invisible
you
can
increase
the
range?
That's
that
is
split
by
each
graph
here.
You
can
also
increase
or
reduce
the
refresh
rate
of
the
graphs
that
I
displayed
here
so
to
sort
wound
up
at
this.
This
section,
you
can
we've
taken
a
look
at
some
of
the
parameters
that
gets
that
expose
useful
metrics
in
our
cluster.
C
That's
the
cubelet,
the
node
exporter
and
the
shed
myself
and
we've
taken
a
look
at
the
parameters
for
tau
and,
lastly,
we've
we've
seen
out
this
come
together
to
give
a
really
good
overview
of
the
community's
growth.
Our
aim
a
dashboard.
So
with
this
you
can
have
a
lot
more
insight
into
the
behavior
of
your
communities
cluster,
so
that
does
it
and
I
will
be
handing
over
to
the
Russian.
To
conclude
the
webinar.
B
Thanks
Elijah
for
taking
us
through
Prometheus
and
and
the
graph
on
our
dashboards,
so
to
wrap
up
here
a
couple
of
dashboards
from
the
reflex
platform.
This
this
first
screenshot
is,
you
know
it's
a
community's
optimization
report
from
reflex,
which
you
have
gives
us
an
overview
of
the
total
kubernetes
costs.
You
know
and
the
potential
savings
we
can
make
by
optimizing
our
clusters,
because
you
know
also
broken
down
my
cloud
they're
broken
down
by
cluster
and
for
every
cluster.
We
get
real-time
alerts
and
notifications
word
with
a
set
of
actions.
B
B
The
second
dashboard
is
a
finance
dashboard
which
breaks
down
communities
caused
by
teams
and
by
the
cloud
providers.
So
I
mean
one
major
concern
that
we
come
across
in
conversations
with
customers.
Is
you
know
the
inherent
weakness
of
kubernetes?
You
know
users
don't
have
visibility
into
it.
Who
is
using
what
one
company
does
you
know
there's
no
way
to
allocate
costs,
because,
because
of
the
shared
resources
model
of
kubernetes,
so
I
mean
essentially,
this
keyboard
breaks
down
communities
caused
by
team.
We
can
also
do
this
for
other
customer
sections.
B
You
know
we
can
break
them
down
by
projects.
We
can
do
that
for
environments,
you
know,
departments
or
applications.
Oh
I
mean
we
can
do
that
on
any
other
custom
lables.
You
know
there
are
useful
for
organizations,
say,
I
mean
just
kind
of
breaking
down
communities
cause
and
getting
more
visibility
you
know
into
in
who
is
using
water
in
communities
all
right,
cool
yeah,
so
I
mean
this.
Brings
us
to
the
end
of
the
webinar
and
now
I'm
going
to
hand
it
back
over
to
George.
B
A
B
Yeah
I'll
take
that
once
so
I
mean.
Essentially,
there
are
ways
that
you
can
do
cost
estimations
of
completeness,
but
I
mean
you
would
have
to
kind
of
hard
code.
The
numbers
in
to
kind
of
you
know
get
get
correct
numbers
you
would
also
need
to
maybe
plug
in
into
cloud
provider.
Billing
api's
I
mean
and
yeah
I
mean
I.
Guess
there
is
only
way
to
kind
of
come
up
with.
You
know
with
accurate
numbers,
for
you
know,
community's
costs,
yeah
I
mean.
If
you
look
on
graph
ona
you
can.
B
B
You
know
because
I
mean
with
public
cloud
providers.
You
know
you
have
a
huge
range
of
let's
say
instances
you
know
and
when
you
think
about
storage
and
so
on
so
kind
of
getting
all
of
that
information
hard-coded
in
is
not
really
I.
Guess
it's
not
really
practical,
so
yeah
I
mean
to
do
really
kind
of
accurate
cost
estimation
you
would
I
guess
need
to
plug
in
into
into
cloud
provider
api's
and
yeah
with
reflux.
You
can
do
that.
Yeah.
A
C
Okay,
so
I'm
going
said
that
so
secrets.
C
groups
are
a
line
of
scanner
feature,
so
they
allow
processes
to
be
so
you
can
you
can
you
can
control
the
amount
of
memory
and
CPU
that
that
process
is
using
so
basically
ugz
to
modify
the
quantum
environmental
processes
in
of
of
the
runtime
environments
of
your
processes?
So
de
tocar
engine
relies
on
this
on
this
in
groups
feature,
and
it
provides
some
flags
that,
for
example,
CPU
sets.
C
So
this
is
our
design
part
of
the
see
groups,
controller
space,
so
CPU
set,
for
example,
is
used
to
assign
individual
CPUs
to
tasks
in
AC
group.
So
when
the
cubelet
starts
to
execute
your
starts
to
execute
your
containers,
it's
going
to
specify
disappear,
set
and
memory.
So
this
are
different.
Parts
of
the
C
groups
fill
one
controller
space,
so
the
memory
feature,
for
example,
limits
memory
used
by
the
past
in
the
sync
group
and
then
also
provides
reports
on
the
usage
of
each
task.
C
A
All
right,
great
thanks,
Elijah
and
Hassan
for
a
great
presentation.
That's
all
the
questions.
We
have
time
for.
Oh
wait!
There's
one
question:
I'm
gonna,
Nikhil,
I'm
gonna
give
you
time
to
type
it.
There
looks
like
you're
typing,
typing,
Israel
doing
okay.
He
says
they're
planning
on
doing
an
on-premise
VM.
How
shall
I
do
the
estimation.
B
B
Yeah
but
I
mean,
since
you
know
most
public
most
most
kubernetes
workloads
are
running
on
public
cloud
providers,
so
we
kind
of
targeted
this
way
better,
mostly
towards
public
cloud
providers,
but
yeah
I
mean,
of
course,
it's
definitely
possible
to
do
that.
On
you
know,
on
on
from
infrastructure,
yeah
I
mean
if,
if
Nikhil
requires
any
more
information,
I
mean
we
can
definitely
get
back
to
him
about
that.
Okay,.