{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/plan-kubernetes-limitrange-changes-as-new-admission-changes/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/",
        "slug": "plan-kubernetes-limitrange-changes-as-new-admission-changes",
        "url": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/plan-kubernetes-limitrange-changes-as-new-admission-changes/"
        },
        "title": "Plan Kubernetes LimitRange changes as new-admission changes",
        "summary": "Adding a namespace limit policy does not retrofit the resources of running Pods.",
        "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:47+00:00",
        "modified_at": "2026-10-20T18:34:31+00:00",
        "reviewed_on": "2026-10-20",
        "reading_minutes": 2,
        "word_count": 250,
        "potentially_affected": "Review LimitRange defaults and admission constraints before changing a namespace policy.",
        "dse_recommendation": "DSE recommends inventorying the existing namespace defaults before introducing a new policy.",
        "primary_source": {
            "name": "Kubernetes documentation — Limit Ranges",
            "url": "https://kubernetes.io/docs/concepts/policy/limit-range/",
            "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": "<p>Adding a namespace limit policy does not retrofit the resources of running Pods.</p>\n<h2>Source facts</h2>\n<p>A Kubernetes LimitRange can apply default requests and limits and reject resource specifications outside its constraints. Validation happens during Pod admission. Existing Pods continue unchanged when a LimitRange is added or modified. When multiple LimitRange objects provide defaults in the same namespace, Kubernetes documents that the selected default is not deterministic.</p>\n<p>Source: <a href=\"https://kubernetes.io/docs/concepts/policy/limit-range/\">Kubernetes documentation — Limit Ranges</a>.</p>\n<h2>Applicability</h2>\n<p>Review LimitRange defaults and admission constraints before changing a namespace policy.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends inventorying the existing namespace defaults before introducing a new policy. Resolve competing defaults instead of relying on their creation order. Compare the resulting request and limit values with the application’s explicit declarations, then plan any necessary workload replacement separately. Tell service owners which newly created Pods will receive a changed configuration and which running instances will retain the old values. Keep the rollout and rollback steps visible so a policy update does not produce an unexplained mix of resource settings during normal replacement activity.</p>\n<h2>Verification</h2>\n<p>Create a disposable Pod without explicit resource values and inspect its admitted specification. Compare it with a Pod admitted before the policy change. Test a deliberately invalid request and confirm that the rejection explains the expected constraint. Retain both admitted specifications in the change record, with their creation times. Ask the owner to identify the deliberate replacement step that will make the application&#8217;s instances converge on the intended values.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://kubernetes.io/docs/concepts/policy/limit-range/\">Kubernetes documentation — Limit Ranges</a>. Reviewed October 20, 2026.</p>",
        "content_text": "Adding a namespace limit policy does not retrofit the resources of running Pods.\nSource facts\nA Kubernetes LimitRange can apply default requests and limits and reject resource specifications outside its constraints. Validation happens during Pod admission. Existing Pods continue unchanged when a LimitRange is added or modified. When multiple LimitRange objects provide defaults in the same namespace, Kubernetes documents that the selected default is not deterministic.\nSource: Kubernetes documentation — Limit Ranges.\nApplicability\nReview LimitRange defaults and admission constraints before changing a namespace policy.\nDSE recommendation\nDSE recommends inventorying the existing namespace defaults before introducing a new policy. Resolve competing defaults instead of relying on their creation order. Compare the resulting request and limit values with the application’s explicit declarations, then plan any necessary workload replacement separately. Tell service owners which newly created Pods will receive a changed configuration and which running instances will retain the old values. Keep the rollout and rollback steps visible so a policy update does not produce an unexplained mix of resource settings during normal replacement activity.\nVerification\nCreate a disposable Pod without explicit resource values and inspect its admitted specification. Compare it with a Pod admitted before the policy change. Test a deliberately invalid request and confirm that the rejection explains the expected constraint. Retain both admitted specifications in the change record, with their creation times. Ask the owner to identify the deliberate replacement step that will make the application’s instances converge on the intended values.\nOfficial reference\nKubernetes documentation — Limit Ranges. Reviewed October 20, 2026.",
        "content_markdown": "Adding a namespace limit policy does not retrofit the resources of running Pods.\n\n## Source facts\n\nA Kubernetes LimitRange can apply default requests and limits and reject resource specifications outside its constraints. Validation happens during Pod admission. Existing Pods continue unchanged when a LimitRange is added or modified. When multiple LimitRange objects provide defaults in the same namespace, Kubernetes documents that the selected default is not deterministic.\n\nSource: [Kubernetes documentation — Limit Ranges](https://kubernetes.io/docs/concepts/policy/limit-range/).\n\n## Applicability\n\nReview LimitRange defaults and admission constraints before changing a namespace policy.\n\n## DSE recommendation\n\nDSE recommends inventorying the existing namespace defaults before introducing a new policy. Resolve competing defaults instead of relying on their creation order. Compare the resulting request and limit values with the application’s explicit declarations, then plan any necessary workload replacement separately. Tell service owners which newly created Pods will receive a changed configuration and which running instances will retain the old values. Keep the rollout and rollback steps visible so a policy update does not produce an unexplained mix of resource settings during normal replacement activity.\n\n## Verification\n\nCreate a disposable Pod without explicit resource values and inspect its admitted specification. Compare it with a Pod admitted before the policy change. Test a deliberately invalid request and confirm that the rejection explains the expected constraint. Retain both admitted specifications in the change record, with their creation times. Ask the owner to identify the deliberate replacement step that will make the application’s instances converge on the intended values.\n\n## Official reference\n\n[Kubernetes documentation — Limit Ranges](https://kubernetes.io/docs/concepts/policy/limit-range/). 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/plan-kubernetes-limitrange-changes-as-new-admission-changes/",
                "url": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-20"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/#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": "Plan Kubernetes LimitRange changes as new-admission changes",
                        "item": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/#article",
                "identifier": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/",
                "url": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/",
                "headline": "Plan Kubernetes LimitRange changes as new-admission changes",
                "description": "Adding a namespace limit policy does not retrofit the resources of running Pods.",
                "abstract": "Adding a namespace limit policy does not retrofit the resources of running Pods.",
                "articleBody": "Adding a namespace limit policy does not retrofit the resources of running Pods.\nSource facts\nA Kubernetes LimitRange can apply default requests and limits and reject resource specifications outside its constraints. Validation happens during Pod admission. Existing Pods continue unchanged when a LimitRange is added or modified. When multiple LimitRange objects provide defaults in the same namespace, Kubernetes documents that the selected default is not deterministic.\nSource: Kubernetes documentation — Limit Ranges.\nApplicability\nReview LimitRange defaults and admission constraints before changing a namespace policy.\nDSE recommendation\nDSE recommends inventorying the existing namespace defaults before introducing a new policy. Resolve competing defaults instead of relying on their creation order. Compare the resulting request and limit values with the application’s explicit declarations, then plan any necessary workload replacement separately. Tell service owners which newly created Pods will receive a changed configuration and which running instances will retain the old values. Keep the rollout and rollback steps visible so a policy update does not produce an unexplained mix of resource settings during normal replacement activity.\nVerification\nCreate a disposable Pod without explicit resource values and inspect its admitted specification. Compare it with a Pod admitted before the policy change. Test a deliberately invalid request and confirm that the rejection explains the expected constraint. Retain both admitted specifications in the change record, with their creation times. Ask the owner to identify the deliberate replacement step that will make the application’s instances converge on the intended values.\nOfficial reference\nKubernetes documentation — Limit Ranges. Reviewed October 20, 2026.",
                "datePublished": "2026-10-20T18:14:47+00:00",
                "dateModified": "2026-10-20T18:34:31+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/plan-kubernetes-limitrange-changes-as-new-admission-changes/"
                },
                "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/plan-kubernetes-limitrange-changes-as-new-admission-changes/#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": "Plan Kubernetes LimitRange changes as new-admission changes"
                },
                "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": 250,
                "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 — Limit Ranges",
                    "url": "https://kubernetes.io/docs/concepts/policy/limit-range/"
                }
            }
        ]
    }
}