CASCL-1077 v1alpha2 datadog pod autoscaler profile CRD

[ADKosm]

What does this PR do?

Introduces DatadogPodAutoscalerProfile CRD in v1alpha2 to enable GitOps batch onboarding for workload autoscaling. The Profile contains a template with autoscaling behavior configuration that can be applied to multiple DatadogPodAutoscaler (DPA) objects at once.
Please check this and this document to learn more about this project.

Motivation

Enable users to manage autoscaling configurations centrally via Profiles instead of creating individual DPA objects for each workload. This simplifies GitOps workflows where multiple workloads need the same autoscaling behavior.

Mental model here can be similar to how Kubernetes ReplicaSet manages Pods => DatadogPodAutoscalerProfile will manage DPAs.

Additional Notes

API Design:

• Profile lives in v1alpha2 package
• DatadogPodAutoscalerTemplate contains shareable autoscaling config: ApplyPolicy, Objectives, Fallback, Constraints, Options. In the future it can be embedded into DatadogPodAutoscalerSpec. For that a construction function is provided - we first will need to update all instantiations in all other repos to use this build method and after this we are free to do embedding in the code.
• Workload-specific fields (TargetRef, Owner, RemoteVersion) remain in DPA spec
• For now Template fields use existing v1alpha2 and common types directly. So no ability to make computable fields for now.

Status fields:

• ControlledAutoscalers - count of managed DPAs
• Strategy - derived strategy: "vertical", "horizontal", or "multi-dimension". Only for illustrative purposes
• Conditions - standard K8s condition object with one state Ready. This state indicates whether the profile is ready and all managed autoscalers are up to date.

Printcolumns:

• Display Name and Description from annotations (autoscaling.datadoghq.com/profile-name, autoscaling.datadoghq.com/profile-description)
• Strategy, Ready status, Controlled Autoscalers count, Apply Mode, Min/Max Replicas, Age

Minimum Agent Versions

Are there minimum versions of the Datadog Agent and/or Cluster Agent required?

• Agent: vX.Y.Z
• Cluster Agent: vX.Y.Z

Describe your test plan

Check that other repos are still compiling after that change.
Trying to create this object in local k8s cluster.

Checklist

• PR has at least one valid label: bug, enhancement, refactoring, documentation, tooling, and/or dependencies
• PR has a milestone or the qa/skip-qa label
• All commits are signed (see: signing commits)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5ca062e899

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Include new profile CRD in kustomize resources

This new CRD manifest is generated, but config/crd/kustomization.yaml is unchanged and does not list datadoghq.com_datadogpodautoscalerprofiles.yaml, so kustomize build config/crd (used by make install/make deploy in Makefile) will not ship this resource at all; in clusters installed from these manifests, DatadogPodAutoscalerProfile will be unavailable despite the API type existing in code.

Useful? React with 👍 / 👎.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 38.69%. Comparing base (6fbf327) to head (aad2314).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2718      +/-   ##
==========================================
- Coverage   38.80%   38.69%   -0.11%     
==========================================
  Files         308      309       +1     
  Lines       26703    26900     +197     
==========================================
+ Hits        10363    10410      +47     
- Misses      15561    15711     +150     
  Partials      779      779              

Flag	Coverage Δ
unittests	38.69% <ø> (-0.11%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 3 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6fbf327...aad2314. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[vboulineau]

I still don't understand the purpose of this condition. Seems to me like you need more things like Valid, Error and then fields to represent aggregated state and observed object. (managedAutoscalers, updatedAutoscalers, observedGeneration).

[vboulineau]

Did we get a decision on including this?

[ADKosm]

Well, I personally see benefits in both scenarios - when we have it only on DPA and when we have it on Profile level as well.
I think it can be useful to be able to disable all managed autoscalers with one change in profile.
For disabling one specific autoscaler - I remember some idea from the past discussions what we should be able to use some cluster-local way to disable autoscaling immediately. If we still want to implement this I think in that case having ApplyPolicy in Profile and be able to put a label/config/annotation on DPA locally to disable this specific one - is a good complimentary pack of features.
@vboulineau what do you think?

[ADKosm]

And one more argument is that controlling the final mode = horizontal, vertical or multidimensional - is done through ApplyPolicy. If I want VPA-only I will need to setup this structure.
So I am more convinced now that we need this property on profile side that the other way around.