KEP-5905: Migrate kubernetes-mixin from kubernetes-monitoring to kubernetes-sigs organization

Implementation History
ALPHA Implementable
Created 2026-02-09
Latest v1.37
Milestones
Alpha v1.37
Beta v1.38
Stable v1.39
Related Enhancements
Ownership
Owning SIG
SIG Instrumentation
Primary Authors
@rexagod

KEP-5905: Migrate kubernetes-mixin from kubernetes-monitoring to kubernetes-sigs organization

Please note that quite a few sections from the template were dropped in this KEP, as they are not applicable to the nature of the proposal.

Release Signoff Checklist

Items marked with (R) are required prior to targeting to a milestone / release.

  • (R) Enhancement issue in release milestone, which links to KEP dir in kubernetes/enhancements (not the initial KEP PR)
  • (R) KEP approvers have approved the KEP status as implementable
  • (R) Graduation criteria is in place
  • (R) Production readiness review completed
  • (R) Production readiness review approved
  • “Implementation History” section is up-to-date for milestone
  • User-facing documentation has been created in kubernetes/website , for publication to kubernetes.io
  • Supporting documentation—e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes

Summary

This KEP aims to migrate the kubernetes-monitoring/kubernetes-mixin repository under the kubernetes-sigs organization, to better reflect its Kubernetes-specific nature and to align with the organizational structure of Kubernetes-related projects. The mixins provided by the repository are a set of monitoring rules and dashboards that are fulfilled by CNCF graduated projects, but do not, and will not, engage any in-tree Kubernetes components directly, in any way.

This migration will help clarify the purpose and scope of the repository, and facilitate better collaboration and maintenance within the Kubernetes community.

Motivation

kubernetes-monitoring/kubernetes-mixin has provided the de-facto set of monitoring mixins tailered for the Kubernetes ecosystem for a long time, and has been widely adopted by users and vendors alike. The migration not only reflects the Kubernetes-specific nature of the repository, but also aims to foster better collaboration and maintenance within the Kubernetes community.

Goals

  • Migrate kubernetes-monitoring/kubernetes-mixin repository to kubernetes-sigs/kubernetes-mixin.
  • Continue operations with the same expectations as they were with kubernetes-monitoring/kubernetes-mixin.

Non-Goals

  • Any changes to the mixins themselves (as a part of the migration), or to the way they are maintained.

Proposal

There isn’t much to say here, as the proposal is straightforward: we want to migrate the kubernetes-monitoring/kubernetes-mixin repository to kubernetes-sigs/kubernetes-mixin via a GitHub repository transfer , and continue operations as they were before, with the same expectations. Users should be able to reference the new repository without any issues, and the mixins should continue to work as they did before, as the migration is mostly a change in ownership and location, rather than in functionality. The migration should be seamless for users, and the mixins should continue to be maintained and updated as they were before, with the same level of quality and reliability. Since GitHub’s repository transfer mechanism automatically redirects all existing git operations (clone, fetch, push) and web links to the new location, existing references will continue to work without any additional CI automations or mirroring setups.

Also, as mentioned earlier, and most importantly, the migration should also help clarify the purpose and scope of the repository, and facilitate better collaboration and maintenance within the Kubernetes community.

Risks and Mitigations

The mixins build over signals exposed by the involved metric sources. False postives are absolutely possible, however, vulnerabilities in the mixins themselves are unlikely, as they are mostly static definitions of monitoring rules and dashboards. The mixins are also not directly involved in any critical path of Kubernetes components, so their failure should not impact the cluster’s stability or security.

Design Details

N/A

Test Plan

Prerequisite testing updates
Unit tests

Unit tests for the mixins live under the tests directory .

Integration tests

Integration tests for the mixins live under the tests directory .

e2e tests

While no end-to-end tests exist currently, they may be bootstrapped over the already available local development functionality, building over ContainerSolutions/prom-metrics-check in the future, to establish greater confidence between the dependency versions mentioned in the compatibility matrix.

Graduation Criteria

ALPHA

  • Fulfill all pre-requisites based on the feedback received on this Slack thread regarding the migration effort discussed in this KEP, which essentially points to the rules for donated repositories .
    • Do note that even though this repository is housed under an organization that is owned by the Kubernetes Enterprise account, we’ll still treat the repository in question as a donated repository, as indicated in the thread above. Hence, the aforementioned rules apply.
  • KEP merged to indicate SIG acceptance of the proposal.
  • kubernetes-mixin repository transferred from kubernetes-monitoring to kubernetes-sigs organization via GitHub repository transfer .

BETA

  • Verify that the GitHub repository transfer redirects resolve correctly for git operations (clone, fetch, push) and web links pointing to the previous kubernetes-monitoring/kubernetes-mixin location.
  • Any additional changes necessary to ensure the migration is smooth, that surface during ALPHA and BETA reviews, are implemented.

STABLE

  • Announce migration in SIG Instrumentation mailing list and #sig-instrumentation Slack channel.
  • Update the repository’s README to document the transfer and recommend that users reference kubernetes-sigs/kubernetes-mixin in their mixins going forward. This is encouraged, but not doing this will never break any functionality whatsoever, as the transfer redirects will continue to work.

Upgrade / Downgrade Strategy

While the repository tries its best to maintain backward compatibility and keep up with the latest versions of the metric sources, upgrading or downgrading should ideally be preceded by a review of the compatibility matrix to ensure that the mixins being used (from the set of releases) are compatible with the versions of the metric sources in use.

Version Skew Strategy

The version skews of the repository, in general, are dictated by the metric sources (see below) that the mixins rely on. The compatibility matrix documents the relationship between the mixins and the metric sources.

Dependencies

Does this feature depend on any specific services running in the cluster?

  • Prometheus

    • Usage description: Kubernetes-specific monitoring rules and alerts, defined in PrometheusRules provided by the mixins repository, rely on the presence of Prometheus for their enforcement and application.
      • Impact of its outage on the feature: PrometheusRules no longer work, although alternatives such as VictoriaMetrics exist.
      • Impact of its degraded performance or high-error rates on the feature: PrometheusRules may no longer work.

  • Alertmanager

    • Usage description: Kubernetes-specific monitoring alerts, defined in PrometheusRules provided by the mixins repository, rely on the presence of Alertmanager for their notification and alerting capabilities.
      • Impact of its outage on the feature: Alerts no longer get delivered.
      • Impact of its degraded performance or high-error rates on the feature: Alerts may not get delivered.

  • Grafana

    • Usage description: Kubernetes-specific monitoring dashboards, defined using the [grafonnet] Jsonnet library, rely on the presence of Grafana for their visualization.
      • Impact of its outage on the feature: Dashboards no longer work, although alternatives such as Perses exist.
      • Impact of its degraded performance or high-error rates on the feature: Dashboards may no longer work.

Additionally, the mixins themselves are sourced from metrics exposed by components within the CNCF landscape, which may or may not be in-tree to Kubernetes. These include:

  • [kubernetes/kube-state-metrics]
  • [prometheus/node_exporter]
  • [kubernetes/kubernetes] (kube-scheduler, kube-controller-manager, kube-apiserver, kube-proxy, kubelet)

Implementation History

TBD

Drawbacks

Maintenance efforts will require bandwidth allocations from the SIG from time to time.

Alternatives

The only other alternative is to not migrate the repository. This directly works against the proposal and isn’t ideal for the reasons discussed above.

Infrastructure Needed (Optional)

SIG Instrumentation requests a kubernetes-mixin repository under the kubernetes-sigs organization.