Guidance on structure for deprecated API use metric

Matt Young

Hello folks!

TLDR: this is something to watch.  I'll be attending SIG Architecture meeting today to determine if there are any next steps, and to get a feeling for the timeline(s) involved.  There is an opportunity to blog about this, and to provide the community we serve visibility and a concrete working example.  I would suggest this makes sense to park in the observe-k8s WG's purview.


There's some work out of SIG-Architecture that adds a new observable point that folks should be aware of...stemming from the SIG's 2021 report here:

The KEP is around warnings for deprecated api's:

SIG Instrumentation picked this an aspect of this (see email below, Damien is chair of SIG Instrumentation, cc'd).



---------- Forwarded message ---------
From: fbra...@... <Unknown>
Date: Tuesday, May 5, 2020 at 11:13:27 AM UTC-4
Subject: Re: Guidance on structure for deprecated API use metric
To: Jordan Liggitt <Unknown>
Cc: kubernetes-sig-instrumentation <Unknown>

Sounds perfect. Happy with that strategy.

On Tue, May 5, 2020 at 4:46 PM 'Jordan Liggitt' via kubernetes-sig-instrumentation <kubernetes-sig-...@...> wrote:

I agree the metrics by themselves are not sufficient, which is why the KEP also adds kubectl warnings (for user visibility) and audit annotations (to let admins identify specific problematic clients).

> What would an administrator do about that if they get an alert for it?

I envision several ways admins could use this or respond to the metric:
  • Requiring the metric to be clean after a CI run to ensure nothing is making use of deprecated APIs
  • Adding a warning before upgrading to version X if requests to deprecated APIs removed in version X were made recently
  • Using a cheap metric check to trigger a more expensive audit log sweep to identify/notify problematic clients
> Just looking at the metrics, I think I like the balance of 2 the most as well (not extending the existing request metrics, and not adding a whole lot of new series)

Sounds good.

> At the very least we should document how to go from the metric to the audit log entry

Definitely, I plan to add documentation for the following:
  • Detecting if deprecated requests have been made to an API server
  • Joining the deprecated request metric to the count metric to get more details about volume, read/write nature, scope, etc
  • Filtering audit events to requests for deprecated APIs to locate clients

You received this message because you are subscribed to a topic in the Google Groups "kubernetes-sig-instrumentation" group.
To unsubscribe from this topic, visit
To unsubscribe from this group and all its topics, send an email to kubernetes-sig-instru...@....
To view this discussion on the web visit

Red Hat GmbH,, Registered seat: Grasbrunn, 
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander

Join { to automatically receive all group messages.