►
From YouTube: SIG Instrumentation 20201112
Description
SIG Instrumentation November 12th 2020
A
B
One
of
those
apis
is
the
node
proxy
api,
and
what
the
conformance
folks
would
like
to
do
is
either
be
able
to
test
all
of
the
apis
or
start
removing
ones
that
are
not
going
to
be
included
in
conformance
and
during
the
meeting.
Most
of
the
node
folks
didn't
have
any
use
cases
that
were
node
related
for
the
proxy
api,
but
I
believe
the
prometheus
server
makes
fairly.
B
So
the
first
question
is:
do
we
want
to
keep
this
api
around
and
I
suspect,
unless
I'm
mistaken,
I
suspect
the
answer
is
yes,
because
a
lot
of
folks
depend
on
it,
but
we
could
also
explore
like
what
it
would
mean
if
we
didn't
have
that
api
and
what
we'd
have
to
do
instead
and
then.
The
second
question
is
okay:
how
do
we
actually
conformance
test
this
endpoint,
and
the
issue
is
that
kubernetes
conformance
considers
almost
all
of
the
node
the
stuff
that
we
run
on
nodes
to
be
in
implementation
detail.
B
A
Yeah,
so
I
I
am
fairly
certain
that
a
lot
of
people
in
the
prometheus
ecosystem
do
make
use
of
this.
For
exactly
what
you
just
said.
I
think
basically,
people
use
it
so
that
they
don't
have
to
discover
nodes
in
some
way
or
something
or
maybe
it
has
to
do
with
our
back
or
something
so
that
essentially,
what
they
do
is
they
use
this
api
to
query
every
single
node
in
the
cluster
for
their
metrics.
A
C
C
You
have
one
like
you
have
easy
way
to
do:
one
liner
to
always
get
to
the
like
from
any
point
to
to
check
if
the
metrics
exposed
by
coupe
that
are
correct
and
if
kubelet
is
doing
the
correct
things
like
we've.
I
know
I
think
it
also
applies.
Checking
version
checking
like
if
you
do
any
debugging
from
outside
of
cluster
like
and
one
node
is
not
working
like
checking
if
summer
api.
What
version
this
cube
that
is
running?
D
A
B
E
F
A
I
tend
to
agree,
as
I
said,
I've
always
discouraged
this
for
the
prometheus
use
case.
People
as
I
said,
people
still
make
use
of
this
widely
anyways,
even
though
it's
it
is
discouraged
in
various
places,
but
yeah,
I
don't
know
if
we
would
potentially
be
like.
I
don't
think
we
should
remove
it,
but
I
don't
think
we
should
necessarily
add
it
to
conformance
either.
But
I
guess
that
was
kind
of
the
point
of
all
of
this
right.
D
C
So
proxy
endpoints
are
like
compared
to
normal,
like
cubelet
like
I
know,
accessing
metrics
those
are
like
truck.
Sync
is
considered
an
admin
on
the
activity,
and
basically
you
can
it's
attack
surface.
That
gives
you
can
you
can
easily
jump
to
group
from
it?
So
any
like.
So
usually
those
kind
of
this
kind
of
api
should
be
only
used
for
debugging
by
administrator.
If
and
everything
else
fails
or
like
administrators
cannot
access
the
node
directly.
C
Of
so
possibly
it's
expected
behavior.
That
administrator
can
use
that,
but
it's
that's
the
the
sketchy
thing
that
this
is
like.
If
you
we
consider
what
are
the
administrator
use
cases
then?
Yes,
if
we
are
not
considering
like
as
a
standard
debugging
tools
like
ap
api,
that
are
needed
for
debugging
as
part
of
standard
conformance,
then
I
agree
with
with
those
use
cases
not
being
really.
D
B
Okay,
so
the
second
question,
then,
is
that
if
signate
is
interested
in
deprecating,
these
endpoints
are
there
use
cases
we
still
want
to
support
through
them?
Are
we
okay,
deprecating
and
removing
them?
Should
we
reach
out
to
any
of
the
like?
If
there's
any
representative
groups
that
are
making
heavy
use
of
them,.
D
B
A
A
It
it
could
be,
it
could
be
pretty
much
exactly
this
except
for
yeah.
I
guess
it
would
be
a
new
sub
resource
of
nodes
which
would
be
metrics
and
it
just
proxies
through
to
the
metrics
endpoint.
I
believe
that
is
exactly
what
people
use
it
for,
not
that
I
think
again
not
that.
I
think
that
this
is
a
good
idea,
but
if
there
are
too
many
people
using
this,
it
could
be
a
middle
ground.
A
E
Yeah,
so
I
got
a
ping
from,
I
think,
contrib
about
developer
documentation
updates.
So
that's
the
linked
issue.
Initially,
I
sort
of
misunderstood
the
request.
Basically
they
are
going
through
all
of
the
developer
documentation.
So
this
is
not
tied
to
a
release.
This
is
general
kubernetes
development,
documentation
and
they're,
asking
basically
that
every
sig
owns
their
documentation
and
trying
to
get
it
updated
so
like
we
don't
necessarily
have
to
go
and
update
it.
E
But
if
there's
anything
that
is
like
obviously
terribly
wrong
and
out
of
date
like
docker
from
the
stone
age
or
something
like
that,
they
have
requested
that
we
try
to
update
that
so
that
it's
not
like
totally
wrong.
So
I
think
for
the
most
part
like
I,
I
took
a
look
through
things
and
I
think
it's
mostly
up
to
date.
E
We
probably
want
to
add-
and
this
is
maybe
going
to
be
a
question
for
david,
so
we
currently
have
some
documentation
for
metrics
or
instrumentation
for
like
logging
for
like
how
to
write
events,
and
then,
I
think,
also
the
structured
logging
migration.
So
that's
all
great,
but
we
might
also
want
to
add
some
for
traces
and
we
might
also
want
to
ensure
that,
like
somebody's
assigned
to
review
all
of
these,
so
they
are
up
to
date.
So
this
is.
F
E
Not
urgent
or
anything
like
that,
but
it
would
be
good
so
that
people
we
definitely
have
gotten
a
lot
of
questions
about
like
is
this
the
only
documentation
there
is
for
this
style
guide
and
like
what
do
we
do
about
this
metric
stuff?
And
I
know
with
some
of
the
current
caps
for
like
adding
more
metrics
to
various
components.
E
We've
had
some
discussions
by
naming
policies
and
whatnot,
so
it
might
be
also
that
it's
not
just
a
matter
of
documenting
things
that
there's
also
some
decisions
that
we
need
to
make
as
a
sig
and
then
write
documentation
for
them.
But
I
just
wanted
to
you
know
sort
of
bring
this
up
as
a
general
topic
and
see
what
people
had
to
say
and
if
anybody
wanted
to
like
jump
in
on
specific
talks,.
E
D
A
It's
here-
oh
actually,
yeah
lily
also
mentioned
something
in
the
in
the
chat
about
global
metrics
registry.
I
think
this
has
been
something
that
we've
wanted
to
add
for
a
long
time.
The
I
think
the
biggest
problem
about
adding
docs
about
global
metrics
registry
right
now
is
that
everything's
still
using
the
global
metrics
registry.
So
we
would
be
recommending
something
that
nobody's
doing
right
now
in
kubernetes.
Well,
no.
E
So
do
we,
I
guess:
how
do
we
make
this
actionable?
We've
talked
about
a
bunch
of
possible
different
things
that
we
could
be
doing
here.
Is
there
specific
things
that
people
want
to
like
volunteer
for?
Do
you
want
to
like
document
that,
against
that
larger
tracking
issue,
to
say
that
you're
doing
that?
How
do
we
want
to
proceed
with
this,
because
at
least
the
ask
initially
that
came
in
like
definitely,
we
need
to
do
all
this
other
stuff,
and
this
is
great,
but
the
ass
that
initially
came
in
was
just
like.
D
E
On
those
things
I
mean,
I
think,
you're
an
approver,
so
you
don't
need
anybody
to
approve
for
you,
but
and
then,
if
anybody
else
wants
to
pick
up
any
of
those
other
things,
I
tried
to
take
a
list
in
the
doc
or
in
the
notes
in
the
agenda,
so
you
can
feel
free
to
like
stick
your
name
beside
it
file
an
issue
or
something
work
on
it:
poke
people
for
reviews.
That's
totally.
A
C
Yeah
so
elena
suggested
to
bring
cover
like
this
more
discussion
to
some
recent
doc
that
I
wrote
regarding
matrix
server.
So
overall
I
wanted
to
collect
my.
I
created
the
document
that
collects
all
my
thoughts
about
why
matrix
server
like
there
are
some
problems
with
metric
server,
how
it
compares
to
other
solutions
like
premises,
adapter
or
overall
output,
as
per
metric
servers
used
mainly
for
auto
scaling,
how
it
compares
to
custom
metrics
out
to
scaling
so
at
the
end
at
least
some
ideas.
What
should
be
improved?
C
C
A
A
C
So
yeah,
maybe
that
I
think
that
two
goals
like
for
first
bring
this
document
to
over
elected
to
them
to
to
wider
audience
us
both
maintainers
of
metric
server
agree
that
this
looks
like
a
over
a
good
direction,
and
I
I
think
we
agree,
so
that's
done
and
second,
I
think
we
agreed
that
we
will
reach
out
to
contributex.
I
don't
know
alana
would
be.
How
would
be,
would
you
be
able
to
help
with
that.
E
E
E
D
B
E
B
Okay,
so
the
scheduler
one
is
based
on
the
cap.
That
clayton
wrote
that
I
think
a
lot
of
you
already
reviewed.
It
adds
a
metric
to
the
scheduler
to
describe
the
requests
of
pods
that
the
scheduler
is
aware
of
and
it
in
the
kep
proposed
a
naming
convention,
starting
with
cube,
underscore
pod
underscore
resource
underscore
requests,
I
think,
basically
to
mimic
what
the
cube
state
metrics
pod,
metrics
look
like
and
as
well.
It
proposed
a
re-labeling,
no,
not
relabeling.
It
proposed
adding
rules
to
the
example.
B
B
At
the
same
time,
there's
been
some
interest
in
the
sig
node
community
to
adding
direct
pod
level
metrics,
because,
if
you're
running
with
a
sandbox
like
kata
containers
or
something
then
you'll
have
significant
overhead
for
your
pod.
That
isn't
captured
as
part
of
the
containers,
and
so
signate
has
been
talking
about
that
and
agreed
that
it
was
a
good
idea
to
add
a
metric
for
that
as
well.
So
the
question
is
one:
are
we
okay
with
the
cube
underscore
pod
name
for
the
scheduler
metrics
and
two
for
the
cubelet's
endpoint?
B
A
This
is
something
within
kubernetes,
but
not
necessarily
about
this
component
right
now,
so
that
that's
at
least
how
I've
always
viewed
all
of
these
metrics
I
mean
I
primarily
only
interacted
with
them
from
from
kubesave
metrics,
because
there
we
actually
totally
consistently
apply
this
pattern,
but
I
think
it
would
be
useful
to
have
this
everywhere,
which
brings
me
to
the
like
one
of
the
previous
points.
If
we
decide
we
want
to
do
this,
this
should
probably
be
in
the
instrumentation
guidelines.
E
Yeah,
so
I
was
the
I
guess,
the
possibly
the
lone
dissenter,
I'm
not
really
sure.
So.
My
concern
with
this
was
well.
There
were
two
things,
so
I
come
at
these
metrics
from
an
operator's
perspective
and
like
when
I'm
using
metrics
like
I
need
to
be
able
to
understand
certain
things
very
very
quickly
about
those
metrics
where
the
metric
is
from,
because
if
the
metric
is
misbehaving,
like
I'm
very
worried
that
you
know
like
well,
what
component
is
misbehaving?
E
So
if
that's
not
clear
from
the
metric
name,
that
was
a
concern
for
me,
and
so
there
was,
you
know,
a
proposal
to
say
like
use
cube
pod
for
these
metrics
coming
out
of
the
scheduler.
But
the
other
problem
is:
is
that
like,
when
I
see
a
cube
under
score
metric
traditionally,
those
all
come
from
cube
state
metrics?
So
as
a
cluster
operator,
if
I
see
a
cube
underscore
pod
metric,
I'm
going
to
go.
Look
at
the
documentation
in
cube
state
metrics
to
see
about
that
metric.
E
I'm
not
going
to
find
it
there
because
it's
not
actually
coming
from
cube
state
metrics.
So
I
was
just
I'm
confused
about
or
I'm
concerned
that,
like
you
know,
this
might
cause
confusion
that
this
stuff
is
not
really
inherent
to
the
name
anymore,
and
I
think
that
you
know
a
lot
of
these
things
in
terms
of
like
making
like
sort
of
global
naming
like,
as
you
know,
these
global
concepts
and
whatnot
like
they.
E
D
A
Right,
like
I'm,
not
sure
that
necessarily
solves
the
problem
at
hand.
I
think
the
the
endpoint
could
make
sense,
although,
as
we
discussed
yesterday,
I'm
not
a
hundred
percent
convinced
that
it's
actually
that
much
better
than
the
metrics
great,
but,
like
I'm,
I'm
happy
to
be
proven
wrong
based
on
data,
but
the
the
point
of
like
I
I
feel
like.
We
should
be
consistent
in
one
way
or
another
right
and
right
now.
D
E
A
pause
y'all
because
we're
we're
at
time
and
we've
had
at
least
one
person
drop.
I
think
that
we
should
continue
this
conversation
in
our
next
meeting
and
I
just
if
it's
okay,
I
really
want
to
quickly
make
some
announcements
before
people
drop,
because
we've
got
dates
and
meeting
cancellations
and
stuff
upcoming.
Is
that
cool,
okay,
cool,
so
dates
and
stuff?
Today
is
code
freeze,
as
mentioned
at
the
beginning
of
the
meeting,
so
anything
we
want
to
get
in
for
120.
We
got
to
do
it
now.
Doc.
E
Freeze
is
upcoming
on
november
30th
and
I
think
people
mostly
have
placeholder
doc
pr's
open,
but
make
sure
you
know
to
get
that
stuff
done
and
the
other
announcement
I
wanted
to
make
is.
It
is
the
end
of
the
year
season
where
we
cancel
a
lot
of
meetings.
So
I'm
trying
to
make
sure
that
everything
is
reflected
on
like
the
agenda
doc,
so
you
can
see
which
meetings
have
been
cancelled
and
the
calendar
has
also
been
updated,
but
next
week,
kubecon
no
triage
week
after
us
thanksgiving
no
meeting.
E
E
A
In
regards
to
code,
freeze
I'll,
like
I
guess,
clayton
is
gonna-
try
want
to
try
to
get
this
in
right.
So
are
we
okay
with
saying
just
to
get
this
into
into
the
release?
He
can
keep
the
name
he
wants
to
for
now,
and
there
needs
to.
There
will
still
be
a
decision
made
on
a
more
general
basis,
or
how
do
you
feel
about
that.
F
Personally,
I
commented,
and
I
I
from
at
least
cube
state
metrics
and
from
a
operator
perspective,
I
don't
see
a
problem
with
using
the
cube
pod.
There's
always
the
target
labels
like
job
label,
which
describes
where
the
metric
originates.
So
that's
how
I
differentiate
between
them.
So
I
really
don't
see
a
problem
with
that.
F
And
from
keepsake
metrics
perspective,
we
were
thinking
at
some
point
of
renaming
them
all
with
ksm
in
the
beginning,
with
a
prefix
instead
of
cube.
I
think
we
then
at
some
point
dropped
that,
because
we
already
have
that
convention
and
yeah
people
are
used
to
them,
and
these
metrics
are
supposed
to
be
a
drop-in
replacement
for
the
ones
we
already
have.
So
I
think
it's
a
good
one.