{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/pair-kubernetes-tolerations-with-an-actual-placement-rule/", "item": { "id": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/", "slug": "pair-kubernetes-tolerations-with-an-actual-placement-rule", "url": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule.md", "json": "https://update.dsesecurity.com/api/v1/posts/pair-kubernetes-tolerations-with-an-actual-placement-rule/" }, "title": "Pair Kubernetes tolerations with an actual placement rule", "summary": "A toleration removes a scheduling obstacle; it does not select the intended node.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:14:45+00:00", "modified_at": "2026-10-20T18:34:31+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 254, "potentially_affected": "Review node admission and eviction through taints, tolerations and a separate affinity requirement.", "dse_recommendation": "DSE recommends documenting both sides of dedicated-node placement: which workloads may enter and which workloads must use those nodes.", "primary_source": { "name": "Kubernetes documentation — Taints and Tolerations", "url": "https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/", "published_on": null, "authority": "kubernetes.io" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

A toleration removes a scheduling obstacle; it does not select the intended node.

\n

Source facts

\n

Kubernetes taints repel Pods, while tolerations allow matching Pods past that restriction. A matching toleration does not guarantee placement because the scheduler evaluates other constraints. NoSchedule prevents new unmatched placement, while NoExecute can also remove already running Pods that lack a suitable toleration. Node affinity is a separate mechanism that attracts or requires placement on selected nodes.

\n

Source: Kubernetes documentation — Taints and Tolerations.

\n

Applicability

\n

Review node admission and eviction through taints, tolerations and a separate affinity requirement.

\n

DSE recommendation

\n

DSE recommends documenting both sides of dedicated-node placement: which workloads may enter and which workloads must use those nodes. Review the exact taint effect rather than copying a toleration solely by key. Broad tolerations deserve particular scrutiny because they can bypass more exclusions than the application needs. Plan how existing Pods will behave before applying a NoExecute change. Keep infrastructure-maintenance tolerations separate from application-specific placement choices so an operational exception does not silently become permanent access to a node pool.

\n

Verification

\n

In a controlled node pool, test matching and nonmatching Pods against the chosen effect. Check placement events and, where approved, the behavior of an already running Pod. Confirm the separate affinity requirement selects the intended pool. Retain the exact toleration operator, value and effect beside the node’s taint. Ask a second reviewer to explain why the allowed Pod qualifies and why the rejected Pod does not, using the effective manifest.

\n

Official reference

\n

Kubernetes documentation — Taints and Tolerations. Reviewed October 20, 2026.

", "content_text": "A toleration removes a scheduling obstacle; it does not select the intended node.\nSource facts\nKubernetes taints repel Pods, while tolerations allow matching Pods past that restriction. A matching toleration does not guarantee placement because the scheduler evaluates other constraints. NoSchedule prevents new unmatched placement, while NoExecute can also remove already running Pods that lack a suitable toleration. Node affinity is a separate mechanism that attracts or requires placement on selected nodes.\nSource: Kubernetes documentation — Taints and Tolerations.\nApplicability\nReview node admission and eviction through taints, tolerations and a separate affinity requirement.\nDSE recommendation\nDSE recommends documenting both sides of dedicated-node placement: which workloads may enter and which workloads must use those nodes. Review the exact taint effect rather than copying a toleration solely by key. Broad tolerations deserve particular scrutiny because they can bypass more exclusions than the application needs. Plan how existing Pods will behave before applying a NoExecute change. Keep infrastructure-maintenance tolerations separate from application-specific placement choices so an operational exception does not silently become permanent access to a node pool.\nVerification\nIn a controlled node pool, test matching and nonmatching Pods against the chosen effect. Check placement events and, where approved, the behavior of an already running Pod. Confirm the separate affinity requirement selects the intended pool. Retain the exact toleration operator, value and effect beside the node’s taint. Ask a second reviewer to explain why the allowed Pod qualifies and why the rejected Pod does not, using the effective manifest.\nOfficial reference\nKubernetes documentation — Taints and Tolerations. Reviewed October 20, 2026.", "content_markdown": "A toleration removes a scheduling obstacle; it does not select the intended node.\n\n## Source facts\n\nKubernetes taints repel Pods, while tolerations allow matching Pods past that restriction. A matching toleration does not guarantee placement because the scheduler evaluates other constraints. NoSchedule prevents new unmatched placement, while NoExecute can also remove already running Pods that lack a suitable toleration. Node affinity is a separate mechanism that attracts or requires placement on selected nodes.\n\nSource: [Kubernetes documentation — Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).\n\n## Applicability\n\nReview node admission and eviction through taints, tolerations and a separate affinity requirement.\n\n## DSE recommendation\n\nDSE recommends documenting both sides of dedicated-node placement: which workloads may enter and which workloads must use those nodes. Review the exact taint effect rather than copying a toleration solely by key. Broad tolerations deserve particular scrutiny because they can bypass more exclusions than the application needs. Plan how existing Pods will behave before applying a NoExecute change. Keep infrastructure-maintenance tolerations separate from application-specific placement choices so an operational exception does not silently become permanent access to a node pool.\n\n## Verification\n\nIn a controlled node pool, test matching and nonmatching Pods against the chosen effect. Check placement events and, where approved, the behavior of an already running Pod. Confirm the separate affinity requirement selects the intended pool. Retain the exact toleration operator, value and effect beside the node’s taint. Ask a second reviewer to explain why the allowed Pod qualifies and why the rejected Pod does not, using the effective manifest.\n\n## Official reference\n\n[Kubernetes documentation — Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/). Reviewed October 20, 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/pair-kubernetes-tolerations-with-an-actual-placement-rule/", "url": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Pair Kubernetes tolerations with an actual placement rule", "item": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/#article", "identifier": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/", "url": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/", "headline": "Pair Kubernetes tolerations with an actual placement rule", "description": "A toleration removes a scheduling obstacle; it does not select the intended node.", "abstract": "A toleration removes a scheduling obstacle; it does not select the intended node.", "articleBody": "A toleration removes a scheduling obstacle; it does not select the intended node.\nSource facts\nKubernetes taints repel Pods, while tolerations allow matching Pods past that restriction. A matching toleration does not guarantee placement because the scheduler evaluates other constraints. NoSchedule prevents new unmatched placement, while NoExecute can also remove already running Pods that lack a suitable toleration. Node affinity is a separate mechanism that attracts or requires placement on selected nodes.\nSource: Kubernetes documentation — Taints and Tolerations.\nApplicability\nReview node admission and eviction through taints, tolerations and a separate affinity requirement.\nDSE recommendation\nDSE recommends documenting both sides of dedicated-node placement: which workloads may enter and which workloads must use those nodes. Review the exact taint effect rather than copying a toleration solely by key. Broad tolerations deserve particular scrutiny because they can bypass more exclusions than the application needs. Plan how existing Pods will behave before applying a NoExecute change. Keep infrastructure-maintenance tolerations separate from application-specific placement choices so an operational exception does not silently become permanent access to a node pool.\nVerification\nIn a controlled node pool, test matching and nonmatching Pods against the chosen effect. Check placement events and, where approved, the behavior of an already running Pod. Confirm the separate affinity requirement selects the intended pool. Retain the exact toleration operator, value and effect beside the node’s taint. Ask a second reviewer to explain why the allowed Pod qualifies and why the rejected Pod does not, using the effective manifest.\nOfficial reference\nKubernetes documentation — Taints and Tolerations. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:14:45+00:00", "dateModified": "2026-10-20T18:34:31+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/pair-kubernetes-tolerations-with-an-actual-placement-rule/" }, "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/pair-kubernetes-tolerations-with-an-actual-placement-rule/#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": "Pair Kubernetes tolerations with an actual placement rule" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "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": 254, "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": "Kubernetes documentation — Taints and Tolerations", "url": "https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/" } } ] } }