Skip to content

Prototype prepared Agent surge with capacity fallback - #3298

Draft
AliDatadog wants to merge 15 commits into
mainfrom
ali.b/agent-surge-resource-fallback
Draft

Prototype prepared Agent surge with capacity fallback#3298
AliDatadog wants to merge 15 commits into
mainfrom
ali.b/agent-surge-resource-fallback

Conversation

@AliDatadog

@AliDatadog AliDatadog commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

What does this PR do?

Prototypes a default-off prepared Agent rollout using native DaemonSet maxSurge.

The Operator renders a compatible Pod, injects its Pod UID, mounts private rollout state, treats prepared as Ready, and sets surge from the existing maxUnavailable budget while forcing rollout maxUnavailable to zero. Kubernetes performs the normal handoff by deleting the old Pod after the replacement is Ready; the Operator does not orchestrate that handoff.

For profile-managed DaemonSets, the Operator first performs a conventional rollout that narrows the existing broad required anti-affinity, waits for it to become fully Available, and only then enables surge.

If a surged replacement is Pending solely because of node CPU or memory, the Operator can fall back to delete-before-create for that node. It revalidates scheduling, affinity, taints, resource fit, Pod and DaemonSet identities, and consumes the existing maxUnavailable budget before deleting the old Pod with a UID precondition.

flowchart LR
  A[Old Agent active] --> B[Native maxSurge creates replacement]
  B --> C[Replacement pulls, initializes, constructs, reports prepared]
  C --> D[Kubernetes deletes old Pod]
  D --> E[Replacement observes no older sibling and activates]
  B -->|CPU or memory cannot fit both| F[Operator validates budget and fit]
  F --> D
Loading

Motivation

Slow image pulls and process construction should not force collection downtime. Native surge already supplies the create-before-delete lifecycle; this PoC removes the scheduling and process-start conflicts that prevent two Agent Pods from overlapping on one node.

Compatibility boundary

  • hostNetwork: true: declared ports are removed; Agent processes still bind after activation. Admission must not add ports back.
  • Pod networking without nonzero hostPort: supported for direct Pod-IP and UDS traffic. Node-local Services can select the sleeping Ready Pod and are excluded from the pilot.
  • Pod networking with nonzero hostPort: rejected.
  • APM and DogStatsD hostPath UDS remain untouched while the replacement sleeps.
  • Exactly agent, direct trace-agent, init-volume, and init-config are supported initially.
  • ExtendedDaemonSet must be disabled for this native DaemonSet experiment.

Describe how you validated your changes

  • Focused controller and renderer packages passed
  • Full make lint reported 0 issues
  • Generated rollout state uses a private EmptyDir and probes validate PID plus /proc start time
  • Skeptical review found no remaining PoC correctness blockers

Coordinated branches:

Checklist

  • Commits are signed
  • Enhancement and QA labels applied

@datadog-official

This comment has been minimized.

@AliDatadog AliDatadog changed the title Prototype prepared host-network Agent rollouts Prototype prepared Agent surge with capacity fallback Jul 24, 2026
@datadog-official

datadog-official Bot commented Jul 28, 2026

Copy link
Copy Markdown

Bits found no code fix to apply

Warning

This comment is related to an earlier commit.

🟢 Investigated · ⚪ No code fix needed

No failing CI job or test is currently reported for the PR head 315585d4, so no code change was made.


View in Datadog | Reviewed commit 6f8af44 · Any feedback? Reach out in #deveng-pr-agent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant