Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

✨ (WIP) feat: initialize kube-state-metrics plugin #3076

Closed

Conversation

Kavinjsir
Copy link
Contributor

@Kavinjsir Kavinjsir commented Nov 16, 2022

2022-11-17 Updates

Hold, we may consider the monitoring plugin for integrating this feature, OR phase 2 approach as making this an external plugin.

Motivation

This is a starting PR to resolve #2286

Description

Introduce a new optional plugin kube-state-metrics.
This metrics aims to provide configuration file loaded by KSM to populate state metrics of custom resources.
The state metrics should be generated based on user-defined subresource status.

This PR initializes the plugin to provide the very basic _info metric of the CRs.
A common usage:
"count custom resources by namespace, cluster, etc"

Usage

The plugin is temporary designed to be triggered by edit subcommand:

# Execute the command after APIs are generated
kubebuilder edit --plugins=kube-state-metrics.kubebuilder.io/v1-alpha

Once executed, the plugin will look for the apis recorded in PROJECT. Then, it will generate a config yaml at:
kube-state-metrics/cr-config.yaml

The file can be loaded by kube-state-metrics through --custom-resource-state-config-file /path/to/kube-state-metrics/cr-config.yaml.
The content refers to https://github.com/kubernetes/kube-state-metrics/blob/v2.6.0/docs/customresourcestate-metrics.md

TODO:

  • initialize the plugin
  • documentation
  • testdata
  • e2e tests

Example

Below is a practice over memcached-operator:

case-1

case-2

@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Nov 16, 2022
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Kavinjsir
Once this PR has been reviewed and has the lgtm label, please assign varshaprasad96 for approval by writing /assign @varshaprasad96 in a comment. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Nov 16, 2022
@k8s-ci-robot k8s-ci-robot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 16, 2022
@Kavinjsir
Copy link
Contributor Author

At this very beginning, I'm also wondering how we would like such plugin to move on?


Rich content for the config file

Fundamentally, guess the plugin is expected to extend the config file.
Metrics might be flexibly brought in based on the status defined by the apis.

We may need to figure out:

  • general label values to be added to all metrics from a resource?
  • ideal naming convention OR if it is good to left by default?
  • metric types to be used for different fields from status

Whether it is necessary to install kube-state-metrics

In case the user does not have ksm running in the cluster, is it necessary for us to provide an option to install ksm? (Then the config can be loaded automatically in that case)


Does it necessary to work with prometheus-operator/kube-prometheus

Only in case if we have many users using prometheus-operator, does it necessary to look for config auto-installation assuming there is the running monitoring stacks?

spec:
resources:{{ range $i, $e := . }}
- groupVersionKind:
group: "{{.Group}}.{{.Domain}}"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have to scaffold config file for all GVKs in the project, or can we allow users to select the GVK they would like to?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think it a good idea to give config entry for users to decide which ones to be intrumented. 👍🏼

metrics:
- name: "info"
each:
type: Info
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we allow this to be user-configurable? I'm fine with the first phase being templated scaffolding, but we should probably think more about how to make this customizable in case we want to?

Copy link
Contributor Author

@Kavinjsir Kavinjsir Nov 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I guess the target is to make the metrics array 'configurable'.

The _info here is like a sample and practices.
It might can become a default one if considered common. (Well, the content/labels might need improvement)

@varshaprasad96
Copy link
Member

@Kavinjsir adding some thoughts for the questions above:

Whether it is necessary to install kube-state-metrics
There are a bunch of opinions for this, and we may have to look into various factors before coming to a decision. Should the KSM necessarily run on cluster. For example, in case of Prometheus we can allow users to run an off-cluster instance and just scrape the metrics through a service-monitor. Is a configuration similar to that possible. If so, we could have a plugin generate kustomize files, that scaffold out the necessary manifests (KSM deployment, service role-binding etc) like we do for Prometheus.

Does KSM expose some generic metrics (https://github.com/kubernetes/kube-state-metrics/tree/master/docs#default-resources) that are relevant for the user to know? For example, controller-runtime or even client-go by default exposes certain metrics which are useful from an operator authors perspective. Are there any specific metrics out of the lot, which we can create wrappers around and utilize for our benefits?

Does it necessary to work with prometheus-operator/kube-prometheus

IMO though kube-prometheus is used widely we should not assume our configurations or scaffoldings to be only based on the same. There are many production use cases wherein the entire monitoring stack can be off-cluster. Also, is there any generic workaround to identify any prometheus on-cluster instance and have an option to allow users to auto-load the configuration if they like to do so?

@@ -118,6 +118,11 @@ function scaffold_test_project {
$kb edit --plugins=grafana.kubebuilder.io/v1-alpha
fi

if [[ $project == "project-v3" || $project == "project-v4" || $project =~ multigroup ]]; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WDYT about:
change this sample project-v3-addon-and-grafana name for project-v3-declarative-v1
then, we have a new one as project-v3-metrics were we will add grafana and this one.

Same for v4.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think maybe we can deal with this in a separate PR? Since this one maybe hold.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@camilamacedo86 Here is the PR to refact testdata: #3086

@Kavinjsir
Copy link
Contributor Author

@camilamacedo86 @varshaprasad96 As discussed in the meeting, it seems like monitoring plugin can be a good idea to integrate both kube-state-metrics and grafana plugin, I am going to hold this PR for now.

@Kavinjsir
Copy link
Contributor Author

/hold

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 17, 2022
@Kavinjsir Kavinjsir changed the title ✨ feat: initialize kube-state-metrics plugin ✨ (WIP) feat: initialize kube-state-metrics plugin Nov 17, 2022
@Kavinjsir
Copy link
Contributor Author

Hi @varshaprasad96 glad to have your ideas with considerations on different perspectives! 👍🏼
While not have much exploration on kube-state-metrics, I feel like it is generally providing metrics based on k8s apis' status.
A common case can be the conditions array in objects' status field.
Regardless of the customized subresource status, it instruments the native apis (deploment, pod, job, ...).

The reason why I was wondering if necessary to provide approaches deploying ksm is because our feature is based on that...

And about what you've mentioned of the monitoring stacks running outside cluster, which pretty makes sense, and so I can understand maybe it is not necessary for kubebuilder to deal with kube-prometheus...

Actually, I'm interested in the monitoring plugin we've been discussed in the weekly. It feels like, we may handle monitoring stacks over there..

Comment on lines +78 to +80
namespace:
- metadata
- namespace

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't this cause issues with cluster-scoped resources?

@Kavinjsir Kavinjsir force-pushed the feat/ksm-cr-metrics branch from 98f9c0f to 0621d60 Compare January 26, 2023 00:03
@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 8, 2023
@k8s-ci-robot
Copy link
Contributor

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

  • Mark this PR as fresh with /remove-lifecycle stale
  • Close this PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 21, 2024
@Kavinjsir
Copy link
Contributor Author

@camilamacedo86 Since the origin issue is closed by the author where kube-state-metrics provides native support for custom resources, I guess we may close this PR at this moment?

@k8s-ci-robot
Copy link
Contributor

@Kavinjsir: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
pull-kubebuilder-e2e-k8s-1-25-0 98f9c0f link false /test pull-kubebuilder-e2e-k8s-1-25-0
pull-kubebuilder-e2e-k8s-1-23-3 98f9c0f link false /test pull-kubebuilder-e2e-k8s-1-23-3
pull-kubebuilder-e2e-k8s-1-26-0 0621d60 link true /test pull-kubebuilder-e2e-k8s-1-26-0
pull-kubebuilder-e2e-k8s-1-27-1 0621d60 link true /test pull-kubebuilder-e2e-k8s-1-27-1
pull-kubebuilder-e2e-k8s-1-27-10 0621d60 link true /test pull-kubebuilder-e2e-k8s-1-27-10
pull-kubebuilder-e2e-k8s-1-28-6 0621d60 link true /test pull-kubebuilder-e2e-k8s-1-28-6
pull-kubebuilder-e2e-k8s-1-27-3 0621d60 link true /test pull-kubebuilder-e2e-k8s-1-27-3
pull-kubebuilder-e2e-k8s-1-26-6 0621d60 link true /test pull-kubebuilder-e2e-k8s-1-26-6
pull-kubebuilder-e2e-k8s-1-28-0 0621d60 link true /test pull-kubebuilder-e2e-k8s-1-28-0
pull-kubebuilder-e2e-k8s-1-29-0 0621d60 link true /test pull-kubebuilder-e2e-k8s-1-29-0

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@k8s-triage-robot
Copy link

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

  • Mark this PR as fresh with /remove-lifecycle rotten
  • Close this PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Mar 2, 2024
@Kavinjsir Kavinjsir closed this Mar 3, 2024
@Kavinjsir
Copy link
Contributor Author

Close this PR as the origin issue was closed by the author. Feel free to open new issue or leave comment here for relative discussions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Custom resource metrics
6 participants