Update Kind for Kubernetes 1.37 (#1308)

## Type of change

- CI

## Description

The Kubernetes v1.37 CI job fails while creating the Kind cluster
because Kind v0.19.0 uses an unsupported kubeadm configuration.

This updates Kind to v0.32.0 in the CI workflow and local test helper.

## Testing

- Verified the workflow changes
- Ran `bash -n test/helpers.bash`
- Downloaded and verified the Kind v0.32.0 binary

Signed-off-by: Sachith Reddy <sachith.24bcs10403@sst.scaler.com>

Scrape metrics between incremental steps (#1292)

## Type of change

- New feature

## Description

When using incrementalLoad, scrape prometheus metrics between each
incremental step.

This allows us to capture all the data to analyze an environment when we
do not know the actual maximum it can support. In the event that the
load breaks the cluster in some way, then we have still indexed all
measurements from the previous increment.


## Related Tickets & Documents

- Related Issue #
- Closes #1244

Signed-off-by: Andrew Collins <ancollin@redhat.com>

Pprof replicas (#1285)

This pull request introduces a new `replicas` field for pprof target
configuration, allowing users to limit the number of pod instances from
which profiling data is collected. T

**Key changes:**

#### Feature: Limit pprof collection with `replicas`

* Added an optional `replicas` field to the `PProftarget` struct in
`types.go`, allowing users to specify how many matching pods to collect
profiling data from; `0` (default) means all pods are included.
* Updated the logic in `pprof.go` to sort matching pods by name and
select only the first N pods according to the `replicas` value, logging
when limiting is applied.
[[1]](diffhunk://#diff-8f29187dcd65305ccf3c06a9baaa4aa9635fa84b159631ea17c7052b73f1dd74R160)
[[2]](diffhunk://#diff-8f29187dcd65305ccf3c06a9baaa4aa9635fa84b159631ea17c7052b73f1dd74L168-R186)
* Updated documentation in `docs/measurements/index.md` to describe the
new `replicas` field, including usage notes and configuration examples
for different components.
[[1]](diffhunk://#diff-2253f73e9477212fbf76e586b07956f9e70b15c804dca04c0014dff104f1e8e6R1023-R1024)
[[2]](diffhunk://#diff-2253f73e9477212fbf76e586b07956f9e70b15c804dca04c0014dff104f1e8e6R1047-R1054)
[[3]](diffhunk://#diff-2253f73e9477212fbf76e586b07956f9e70b15c804dca04c0014dff104f1e8e6R1079)
* Added `replicas` to example measurement configurations, including
`kube-burner-measure.yml`, to demonstrate limiting collection to a
subset of pods.

---------

Signed-off-by: Raul Sevilla <rsevilla@redhat.com>

Adding global hooks support from PR#1193 (#1304)

Allow running hooks that are not tied to any specific job. Global hooks
are configured in the 'global' section and execute before any job starts
or after all jobs complete.

This helps networking workloads to setup test envrionment (like external
server, port forwarding, frr) before running the jobs and avoid over
dependency on measurement code to acheieve the same

Pair programmed looking at:
#1193

Signed-off-by: Vishnu Challa <vchalla@redhat.com>

Add KEDA ScaledObject Performance Testing (#1234)

## Type of change

<!-- Choose a type of change -->

- New feature
- Optimization

## Description

<!--- Describe your changes in detail -->
This PR introduces comprehensive performance testing and observability
capabilities for [KEDA](https://keda.sh/) (Kubernetes Event-driven
Autoscaling) within kube-burner.

- New measurement `scaledObjectLatency` been added , tracks KEDA's
`ScaledObject` resources , Captures granular timestamps for critical
conditions: `ScaledObjectActive` -> `HPACreated` -> `DeploymentReady`.
- It adds a new RabbitMQ-based scale workload and a dedicated
measurement (`scaledObjectLatency`) to deeply track the latency of
KEDA's auto-scaling control plane (from triggering to deployment
readiness).

New workload at `examples/workloads/keda-rabbitmq`
- Job 1: Creates RabbitMQ queues.
- Job 2: Deploys producers to flood the queues with messages.
- Job 3: Deploys consumers attached to ScaledObject resources to trigger
dynamic scaling.
- Job 4: Cleanup jobs.


```mermaid

flowchart LR
    %% Main execution flow
    Start([🚀 kube-burner init]) --> J1
    J1["Job 1: create-queue<br/>(Creates RabbitMQ Queues)"] --> J2
    J2["Job 2: rabbitmq-producers<br/>(Deploys K8s Producer Jobs)"] --> J3
    
    %% Infrastructure state
    subgraph RabbitMQ Broker
        Q[("RabbitMQ Queues<br/>(Message Backlog Builds Up)")]
    end
    
    %% Producer Action
    J2 == "(1) Produces Messages<br/>into respective queues" ===> Q
    
    subgraph Job 3: rabbitmq-consumers & Autoscaling
        J3["Deploy Consumers<br/>& ScaledObjects"]
        KEDA{{"KEDA Operator<br/>Monitors Queue Depth"}}
        HPA[["HPA Updates<br/>Replica Count"]]
        Consumers["K8s Consumer Pods"]
        
        J3 --> KEDA
        J3 --> Consumers
        
        KEDA -- "(3) Triggers Scale Events" --> HPA
        HPA -- "(4) Scales up (0 to N)" --> Consumers
    end
    
    %% Scaling logic
    Q -. "(2) Reads Queue Metrics" .-> KEDA
    Consumers == "(5) Consumes Messages<br/>(Burns down queues)" ===> Q
    
    %% Profiling and waiting
    J3 --> PPROF[("Collect pprof Profiles<br/>(Targeting pods via labels<br/>using localhost proxy)")]
    PPROF --> Wait(("Wait 30m<br/>(Observe metrics & scale behavior)"))
    Consumers -. "Running during jobPause" .-> Wait
    
    %% Teardown
    Wait --> J4
    J4["Job 4: rabbitmq-delete<br/>(Deletes ScaledObjects)"] --> J5
    J5["Job 5: delete-queues<br/>(Deletes RabbitMQ queues)"] --> Metrics
    
    %% Finalization
    Metrics[("Compile & Index Metrics<br/>(Pod, Node, SVC,<br/>ScaledObject Latencies)")] --> Finish([🏁 End Test])

    %% Styling
    classDef startend fill:#eceff1,stroke:#607d8b,stroke-width:2px,color:#000;
    classDef jobNode fill:#e1f5fe,stroke:#0288d1,stroke-width:2px,color:#000;
    classDef rmqNode fill:#ffebee,stroke:#c62828,stroke-width:2px,color:#000;
    classDef kedaNode fill:#fff3e0,stroke:#f57c00,stroke-width:2px,color:#000;
    classDef k8sNode fill:#f3e5f5,stroke:#6a1b9a,stroke-width:2px,color:#000;
    classDef metricNode fill:#e8f5e9,stroke:#388e3c,stroke-width:2px,color:#000;
    
    class Start,Finish,Wait startend;
    class J1,J2,J3,J4,J5 jobNode;
    class Q rmqNode;
    class KEDA kedaNode;
    class HPA,Consumers k8sNode;
    class PPROF,Metrics metricNode;

``` 

## Related Tickets & Documents

- Related Issue #
- Closes #1158 

## Testing

KEDA Installation via Helm 
```bash
helm repo add kedacore https://kedacore.github.io/charts
helm repo update
helm install keda kedacore/keda \
  --namespace keda \
  --create-namespace \
  --version 2.16.0 \
  --set prometheus.metricServer.enabled=true \
  --set prometheus.operator.enabled=true \
  --set profiling.operator.enabled=true \
  --set profiling.operator.port=8082 \
  --set profiling.metricsServer.enabled=true \
  --set profiling.metricsServer.port=8083 \
  --set profiling.webhooks.enabled=true \
  --set profiling.webhooks.port=8084
```
Use  prometheus operator or promethus stack from community 
```bash
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace \
  --set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValues=false
```
Verify
```bash
kubectl get pods -n keda
# Expected: keda-operator, keda-operator-metrics-apiserver, keda-admission-webhooks

kubectl get crd | grep keda
# scaledobjects.keda.sh
	# scaledjobs.keda.sh
# triggerauthentications.keda.sh
# clustertriggerauthentications.keda.sh
```

Run the workload:
```bash
export KEDA_TEST_NAMESPACE=keda-perf-test
kube-burner init -c examples/workloads/keda-rabbitmq/kube-burner.yaml --log-level=debug
```

---------

Signed-off-by: Sai Sanjay <saisanjay7660@gmail.com>
Signed-off-by: sanjay7178 <saisanjay7660@gmail.com>

Add embedded filesystem support for hook scripts (#1203)

Hooks can now reference scripts stored in the embedded config/scripts
directory when using kube-burner-ocp or any application with an embedded
filesystem.

When a hook command invokes bash or sh with a script file, kube-burner
will:
1. Execute directly if the script path is absolute
2. Execute directly if the script exists in the current directory
3. Fall back to reading from embedded filesystem if not found locally

This enables workload authors to bundle scripts with their
configurations without requiring users to manually extract them.

The implementation reuses the existing GetScriptsReader() function that
beforeCleanup and healthCheckScript already use.

---------

Signed-off-by: venkataanil <vkommadi@redhat.com>
Signed-off-by: Raul Sevilla <rsevilla@redhat.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Raul Sevilla <rsevilla@redhat.com>

Fix undefined variables in mainstream (#1259)

## Type of change

- Refactor
- Bug fix

## Description

Fix undefined variables in the upstream main branch.

Signed-off-by: Vishnu Challa <vchalla@redhat.com>

Fix UUID template substitution for TSDB indexer (#1246)

## Type of change

<!-- Choose a type of change -->


- Bug fix
- Optimization


## Description

<!--- Describe your changes in detail -->

The {{.UUID}} placeholder in the metrics directory path was only being
substituted for the LocalIndexer type. When using --indexer-type tsdb,
the directory was created with the literal name
"collected-metrics-{{.UUID}}" instead of
"collected-metrics-<actual-uuid>".

Extend the condition in ProcessMetricsScraperConfig to also match
TSDBIndexer so both indexer types get the UUID properly substituted.

## Related Tickets & Documents

- Related Issue #
- Closes #1245

---------

Signed-off-by: sanjay7178 <saisanjay7660@gmail.com>

Fix pre-load falsely reporting images as pulled (#1243)

## Type of change

- Bug fix

## Description

The pre-load check used status.Image to determine whether a container
image had been pulled. This field is populated by the kubelet as soon as
the container status entry is created, even while the image is still
being pulled (Waiting/ContainerCreating), causing pre-load to declare
success within seconds for multi-GB images.

Replace the check with isImagePulled(), which inspects container state
instead: Running, Terminated, or RestartCount > 0 means the image was
pulled. For KubeVirt container disk images where the container command
fails at create time (CreateContainerError), the Waiting reason itself
proves the pull succeeded, distinguishing it from image-pull-related
reasons (ContainerCreating, ErrImagePull, ImagePullBackOff).

Signed-off-by: Marius Cornea <mcornea@redhat.com>

CI Bug Fix (#1208)

## Type of change
- Bug fix:
https://github.com/kube-burner/kube-burner/actions/runs/24233431210/job/70750400487

## Description
CI Bug Fix.

---------

Signed-off-by: Vishnu Challa <vchalla@redhat.com>
Co-authored-by: Andrew Collins <ancollin@redhat.com>