Do not mistake a pipeline group's one-instance limit for a dedicated Kubernetes node

Source facts

Azure Monitor pipeline’s maxInstancesPerHost limit applies to replicas within one pipeline group, not every pipeline group on the node. Its only supported explicit value is 1; leaving it unspecified imposes no per-host limit. Separate groups can therefore share a host. Node eligibility must satisfy every configured constraint. Placement changes redeploy instances, and unsatisfied placement leaves them pending. Microsoft exposes this configuration through ARM or Bicep templates. Microsoft Learn.

Applicability

Inspect the pipeline-group resource, its executionPlacement configuration and the actual pods sharing a node. The service automatically labels pods with their pipeline-group name. Distinguish separating replicas of one group from dedicating nodes to a team or workload; they are different requirements.

DSE recommendation

Compare pipeline-group identities before diagnosing a shared node as an anti-affinity failure. If the requirement is broader isolation, have the Kubernetes owner design node-label constraints and review what other workloads can use those nodes. Count nodes meeting the complete constraint set against the intended replica count. Schedule placement edits as a redeployment rather than treating them as an annotation-only change. Avoid changing unrelated workload rules simply because two differently named groups share a host.

Verification

After an approved update, inspect group labels, node assignments and scheduling events. For pending pods, identify the specific unmet label or capacity requirement before weakening constraints. Confirm that replicas of the same group follow the intended limit while documenting any other group sharing those nodes. Accept the result against the written isolation requirement, not merely against a count of all pipeline pods on each host.

Official references

Microsoft Learn: Azure Monitor pipeline pod placement. Source reviewed September 9, 2026.