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.
\nInspect 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.
\nCompare 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.
\nAfter 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.
\nMicrosoft Learn: Azure Monitor pipeline pod placement. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAzure 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.\nApplicability\nInspect 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.\nDSE recommendation\nCompare 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.\nVerification\nAfter 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.\nOfficial references\nMicrosoft Learn: Azure Monitor pipeline pod placement. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAzure 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).\n\n## Applicability\n\nInspect 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.\n\n## DSE recommendation\n\nCompare 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.\n\n## Verification\n\nAfter 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.\n\n## Official references\n\n[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." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/", "url": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Do not mistake a pipeline group's one-instance limit for a dedicated Kubernetes node", "item": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/#article", "identifier": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/", "url": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/", "headline": "Do not mistake a pipeline group's one-instance limit for a dedicated Kubernetes node", "description": "Why can two Azure Monitor pipeline pods share a node despite a one-instance-per-host setting?", "abstract": "Why can two Azure Monitor pipeline pods share a node despite a one-instance-per-host setting?", "articleBody": "Source facts\nAzure 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.\nApplicability\nInspect 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.\nDSE recommendation\nCompare 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.\nVerification\nAfter 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.\nOfficial references\nMicrosoft Learn: Azure Monitor pipeline pod placement. Source reviewed September 9, 2026.", "datePublished": "2026-09-10T00:24:54+00:00", "dateModified": "2026-09-10T02:04:57+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-422-do-not-mistake-a-pipeline-group-s-one-instance-limit-for-a-dedicated-kubernetes/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Do not mistake a pipeline group's one-instance limit for a dedicated Kubernetes node" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Explainer", "Information priority" ], "genre": "Explainer", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 265, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Azure Monitor pipeline pod placement - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/data-collection/pipeline-pod-placement" } } ] } }