Skip to content

feat(autoscaler): compute GOMEMLIMIT per node group#370

Merged
matthyx merged 5 commits intomainfrom
feature/gomemlimit-autoscaler
Apr 29, 2026
Merged

feat(autoscaler): compute GOMEMLIMIT per node group#370
matthyx merged 5 commits intomainfrom
feature/gomemlimit-autoscaler

Conversation

@slashben
Copy link
Copy Markdown
Contributor

@slashben slashben commented Apr 28, 2026

Summary

  • Add GoMemLimitPercentage field to NodeAgentAutoscalerConfig (default 0.8 = 80%)
  • Compute GOMEMLIMIT per node group in TemplateRenderer as a percentage of the memory limit, and inject it as GoMemLimit into the DaemonSet template
  • Validate that goMemLimitPercentage is in the valid range (0, 1.0] at construction time

Motivation

In autoscaler mode the operator creates per-node-group DaemonSets with dynamically sized resource requests/limits. Previously the DaemonSet template had a static GOMEMLIMIT set at Helm install time. This PR makes the operator compute GOMEMLIMIT at reconcile time from the actual computed memory limit, so it always stays at the configured percentage (default 80%) of whatever the operator decided the limit should be for that node group.

Design note: main container vs. sidecar

The operator computes GOMEMLIMIT only for the main node-agent container, whose resources scale per node group. When the SBOM scanner sidecar is enabled, its resources are static (configured via Helm values, uniform across node groups) and its GOMEMLIMIT is computed once by Helm at install time — the operator passes the sidecar definition through unchanged. Sidecar resource limits can still be adjusted via helm upgrade --set nodeAgent.sbomScanner.resources.limits.memory=....

Changes

File Change
config/config.go Add GoMemLimitPercentage float64 to NodeAgentAutoscalerConfig; set viper default to 0.8
nodeagentautoscaler/templaterenderer.go Add goMemLimitPercentage field; compute GoMemLimit in RenderDaemonSet; validate percentage in constructor
nodeagentautoscaler/autoscaler.go Pass cfg.GoMemLimitPercentage to NewTemplateRenderer
nodeagentautoscaler/templaterenderer_test.go Test GOMEMLIMIT computation for multiple memory/percentage combos; test invalid percentage rejection

Test plan

  • Unit tests: TestTemplateRenderer_RenderDaemonSet_GoMemLimit covers 450Mi→360MiB, 1Gi→819MiB, 1800Mi→1440MiB, 900Mi→720MiB at 80%
  • Unit tests: TestTemplateRenderer_NewTemplateRenderer_InvalidPercentage verifies rejection of 0, negative, >1.0 and acceptance of 1.0
  • All existing tests pass (go test ./...)
  • Local kind cluster verification: computed GOMEMLIMIT matched expected 80% of memory limit in both with-sidecar and without-sidecar scenarios

Summary by CodeRabbit

Release Notes

  • New Features

    • Added nodeAgentAutoscaler.goMemLimitPercentage configuration option (defaults to 0.8) with validation for values between 0 and 1.0
    • Autoscaler now populates Go memory limit environment variables on DaemonSets based on memory limits and the configured percentage
  • Tests

    • Added integration test job to CI/CD pipeline for build verification

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 28, 2026

📝 Walkthrough

Walkthrough

The pull request adds a new GoMemLimitPercentage configuration parameter to the node agent autoscaler that calculates a Go memory limit from the daemonset memory limit. This value threads through the configuration system to the template renderer, which validates the percentage and computes a formatted memory limit for use in rendered templates. Integration tests are enabled in the workflow.

Changes

Cohort / File(s) Summary
Configuration
config/config.go, config/config_test.go
Introduces new GoMemLimitPercentage float64 field to NodeAgentAutoscalerConfig with Viper default of 0.8, updated in test expectations.
Workflow
.github/workflows/pr-created.yaml
Adds integration-build job that removes *.yaml from paths-ignore and runs Go integration tests with build tag (-run=^$).
Autoscaler
nodeagentautoscaler/autoscaler.go, nodeagentautoscaler/autoscaler_test.go
Passes GoMemLimitPercentage from config to TemplateRenderer constructor; test config updated with field value.
Template Renderer
nodeagentautoscaler/templaterenderer.go
Constructor now accepts goMemLimitPercentage parameter with validation for range (0, 1.0]; RenderDaemonSet computes GoMemLimit string from memory limits and percentage, adds to template data.
Template Renderer Tests
nodeagentautoscaler/templaterenderer_test.go
Updates existing tests to pass percentage argument; adds validation tests for percentage bounds and new rendering test for GoMemLimit computation from memory limits.
Integration Test
nodeagentautoscaler/integration_test.go
Reformats documentation comment; updates TemplateRenderer instantiation to pass 0.8 percentage parameter.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A percentage flows through config's winding path,
From memory limits, Go learns its math,
The renderer validates with care so keen,
Computing limits—a calculated dream,
Templates bloom with values anew! 🌱✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 27.27% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'feat(autoscaler): compute GOMEMLIMIT per node group' clearly and specifically summarizes the main change: adding dynamic GOMEMLIMIT computation for node-agent DaemonSets, which is the primary objective of this PR.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feature/gomemlimit-autoscaler

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
Review rate limit: 0/1 reviews remaining, refill in 60 minutes.

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions
Copy link
Copy Markdown

Summary:

  • License scan: success
  • Credentials scan: failure
  • Vulnerabilities scan: failure
  • Unit test: success
  • Go linting: failure

@slashben slashben added the release Create release label Apr 29, 2026
…ateRenderer

Signed-off-by: Ben <ben@armosec.io>
Signed-off-by: Ben <ben@armosec.io>
@github-actions
Copy link
Copy Markdown

Summary:

  • License scan: success
  • Credentials scan: failure
  • Vulnerabilities scan: failure
  • Unit test: success
  • Go linting: failure

Signed-off-by: Ben <ben@armosec.io>
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

🧹 Nitpick comments (2)
nodeagentautoscaler/templaterenderer.go (1)

211-213: Consider clamping very small positive results to at least 1MiB.

For very small memory limits, flooring may produce 0MiB; a minimum floor can avoid pathological output while preserving intent.

Proposed tweak
 limitBytes := resources.Limits.Memory.Value()
 goMemLimitMiB := int64(float64(limitBytes) * tr.goMemLimitPercentage / (1024 * 1024))
+if limitBytes > 0 && goMemLimitMiB == 0 {
+	goMemLimitMiB = 1
+}

Also applies to: 227-227

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@nodeagentautoscaler/templaterenderer.go` around lines 211 - 213, The
computation of goMemLimitMiB can yield 0 for very small memory limits; clamp the
result to at least 1MiB by taking the max between the computed value and 1.
Locate the calculation that reads limitBytes := resources.Limits.Memory.Value()
and goMemLimitMiB := int64(float64(limitBytes) * tr.goMemLimitPercentage / (1024
* 1024)), then replace the direct assignment with logic that ensures
goMemLimitMiB = max(computedValue, 1) so tiny positive limits floor to 1MiB
(apply the same clamp where the same pattern occurs around the other instance at
the referenced location).
config/config.go (1)

320-320: Consider fail-fast range validation at config-validation stage.

Right now invalid percentages are rejected later in renderer construction; validating in config validation would centralize and surface misconfiguration earlier.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@config/config.go` at line 320, Add fail-fast range validation for the
nodeAgentAutoscaler.goMemLimitPercentage config key during the central config
validation step: after loading defaults (where
viper.SetDefault("nodeAgentAutoscaler.goMemLimitPercentage", 0.8) is set) read
the configured value
(viper.GetFloat64("nodeAgentAutoscaler.goMemLimitPercentage")) in the config
validation function (e.g., ValidateConfig/Validate) and return an error if the
value is outside the valid range (0.0 <= value <= 1.0), so misconfiguration is
caught early rather than later in renderer construction.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@config/config.go`:
- Line 320: Add fail-fast range validation for the
nodeAgentAutoscaler.goMemLimitPercentage config key during the central config
validation step: after loading defaults (where
viper.SetDefault("nodeAgentAutoscaler.goMemLimitPercentage", 0.8) is set) read
the configured value
(viper.GetFloat64("nodeAgentAutoscaler.goMemLimitPercentage")) in the config
validation function (e.g., ValidateConfig/Validate) and return an error if the
value is outside the valid range (0.0 <= value <= 1.0), so misconfiguration is
caught early rather than later in renderer construction.

In `@nodeagentautoscaler/templaterenderer.go`:
- Around line 211-213: The computation of goMemLimitMiB can yield 0 for very
small memory limits; clamp the result to at least 1MiB by taking the max between
the computed value and 1. Locate the calculation that reads limitBytes :=
resources.Limits.Memory.Value() and goMemLimitMiB := int64(float64(limitBytes) *
tr.goMemLimitPercentage / (1024 * 1024)), then replace the direct assignment
with logic that ensures goMemLimitMiB = max(computedValue, 1) so tiny positive
limits floor to 1MiB (apply the same clamp where the same pattern occurs around
the other instance at the referenced location).

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: ffa5a517-5be0-444b-946d-15b32cff0f4c

📥 Commits

Reviewing files that changed from the base of the PR and between 3fcf262 and 57b3b9d.

📒 Files selected for processing (8)
  • .github/workflows/pr-created.yaml
  • config/config.go
  • config/config_test.go
  • nodeagentautoscaler/autoscaler.go
  • nodeagentautoscaler/autoscaler_test.go
  • nodeagentautoscaler/integration_test.go
  • nodeagentautoscaler/templaterenderer.go
  • nodeagentautoscaler/templaterenderer_test.go

@github-actions
Copy link
Copy Markdown

Summary:

  • License scan: success
  • Credentials scan: failure
  • Vulnerabilities scan: failure
  • Unit test: success
  • Go linting: failure

@matthyx matthyx merged commit 3c5208d into main Apr 29, 2026
11 checks passed
@matthyx matthyx deleted the feature/gomemlimit-autoscaler branch April 29, 2026 07:22
@matthyx matthyx moved this to To Archive in KS PRs tracking Apr 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

release Create release

Projects

Status: To Archive

Development

Successfully merging this pull request may close these issues.

2 participants