📖 Add new documentation explaining the usage of Pprof

[TAM360]

Description

This PR introduces a new documentation file explaining the purpose, and usage of pprof library within the Kubebuilder project.

Motivation

Pprof is a profiling library designed for retrieving and visualization profiling statistics such as CPU, and Memory usage of Go application. With Pprof, you can identify, and fix the bottlenecks that are hampering the performance of your Controller.
Pprof comes as part of controller-runtime package since v0.15.x which is used by Kubebuilder under the hood.

Having an introductory tutorial will help any existing or future user of Kubebuilder in about analyzing their own codebase's behavior, without relying on any external resources.

Issues fixed

3338

[k8s-ci-robot]

Hi @TAM360. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[camilamacedo86]

Great work 🥇 Well done 🚀

I added some comments /suggestions in my review !!!

PS.: See that in this case we do not use in the title go/v4 because the change is not in the source code of the plugin. It is only for docs. The title is what we use to generate the release notes, in case of doc changes it will not end up in the summary, just in all changes done in the release, see for example: https://github.com/kubernetes-sigs/kubebuilder/releases/tag/v4.2.0

[camilamacedo86]

/ok-to-test
/approved

[camilamacedo86]

Hi @zqzten

You asked for this one and is the author of the implementation in C+R.
You can check the final result in : https://deploy-preview-4160--kubebuilder.netlify.app/reference/pprof-tutorial
WDYT?

[camilamacedo86]

/approved

[zqzten]

Thanks for the work!

I have some opinions on the Pprof Not Recommended for Production section, as pprof would only introduce overhead on actual CPU sampling (by calling the API) and can be useful for debugging performance issues in production (sometimes performance issue cannot be easily reproduced in test env or after restarting process to enable pprof in production), so the tip might be Use Pprof in Production with Caution to instruct that:

• Pprof endpoint should be protected in production for security reasons.
• Pprof would introduce overhead on CPU sampling (when calling the API).

[TAM360]

Thanks for the work!

I have some opinions on the Pprof Not Recommended for Production section, as pprof would only introduce overhead on actual CPU sampling (by calling the API) and can be useful for debugging performance issues in production (sometimes performance issue cannot be easily reproduced in test env or after restarting process to enable pprof in production), so the tip might be Use Pprof in Production with Caution to instruct that:

• Pprof endpoint should be protected in production for security reasons.
• Pprof would introduce overhead on CPU sampling (when calling the API).

@camilamacedo86 WDYT?

[camilamacedo86]

Hi @zqzten,

Regarding: PR Review 4160

be useful for debugging performance issues in production (sometimes performance issue cannot be easily reproduced in test env or after restarting process to enable pprof in production),

I believe we should be clear in our messaging here. If we say "not recommended" (as we use it in other places like for metrics) and provide clear reasoning, users will understand that this feature should not be enabled by default. However, if we use language like "use with caution," it could lead to confusion and encourage users to deliver solutions with it enabled by default, which could lead to unintended consequences.

It’s analogous to troubleshooting in an environment. If a scenario cannot be reproduced in one environment, you naturally move to an environment where it can be reproduced, ensuring that you’re working under the right conditions. In other words, not matter we say that is NOT recommended for Prod, if the person need to test things out in Prod for any reason this person will do that.

as pprof would only introduce overhead on actual CPU sampling (by calling the API)

I think we can rewording it to clarify that is mainly CPU . I will add a suggestion and ping you.

Is that make sense ?
However, if you have other suggestions to rewording please feel free.

[zqzten]

/lgtm
Thanks!

[camilamacedo86]

All conveyed suggestions with the author of the issue are addressed
So, it seems that all is done and we can get this one merged !!!

/lgtm
/approved
/ok-to-test

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: camilamacedo86, TAM360, zqzten

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [camilamacedo86]

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