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

> Why can two Azure Monitor pipeline pods share a node despite a one-instance-per-host setting?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:24:54+00:00
- Modified: 2026-09-10T02:04:57+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Explainer
- DSE priority: Information
- Topics: IT, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

Why can two Azure Monitor pipeline pods share a node despite a one-instance-per-host setting?

## Potentially affected

Azure Monitor pipeline groups using executionPlacement on Kubernetes.

## DSE recommendation

Compare pipeline-group identities before diagnosing a shared node as an anti-affinity failure.

## Article

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/pipeline-pod-placement).

## 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](https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/pipeline-pod-placement). Source reviewed September 9, 2026.

## Primary reference

- Name: Azure Monitor pipeline pod placement - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/pipeline-pod-placement
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Do not mistake a pipeline group's one-instance limit for a dedicated Kubernetes node,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.