Bottom line: State whether a list change should add, remove or replace entries before choosing the patch. Review the specific field and operation rather than treating a short patch file as evidence that unrelated entries will remain.
\nThe Update API Objects in Place Using kubectl patch documentation is the primary reference.
\nThe strategic patch example merges containers using name, while its tolerations example replaces that list because it lacks a merge strategy. A JSON merge patch replaces an existing list with the complete new list supplied in the patch. The tutorial says strategic merge patch is not supported for custom resources.
This article covers the documented built-in Deployment examples. It does not approve a production mutation, select a scheduling policy or establish application availability after a change. Review those consequences separately. Keep the source object, proposed patch and intended final list together before authorizing execution.
\nDSE recommends writing the complete expected list before constructing a patch. Identify every existing entry that should remain and the one change being requested. This makes an omitted entry visible during review rather than after an application or scheduling change.
\nRead the relevant field strategy for the actual API type. For the tutorial’s two examples, review containers and tolerations independently even though they sit in the same Pod specification. Keep the selected --type value with the patch file so a reviewer does not infer the operation from its contents alone.
Use the documented --patch-file approach for a reproducible lab exercise when appropriate. Preserve the exact file and target identity. Review any shell quoting separately if the same change is later written inline; keep one clearly identified authoritative representation instead of several almost identical command fragments.
Compare the entire affected list after the exercise. Check the retained entries as deliberately as the new entry. If the actual result differs from the expected after-list, resolve the operation or expectation before repeating it against a wider population. Keep the application rollout check separate from the evidence that the API object contains the intended fields.
\nProposed verification, not performed: prepare a disposable Deployment with two harmless named container entries and a separately recorded toleration list. Rehearse a strategic patch that adds a container, then a separate strategic toleration-list change. Compare each result with its written expected list rather than assuming both fields use the same behavior.
\nIn another isolated case, supply a complete replacement list through the documented JSON merge type. Retain the original object, patch type, patch file and full resulting list for every case. Have a second operator identify which entries should survive before viewing the result. Record actual workload observations separately, and do not treat a correctly changed list as proof that the application rollout was accepted.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: State whether a list change should add, remove or replace entries before choosing the patch. Review the specific field and operation rather than treating a short patch file as evidence that unrelated entries will remain.\nSource fact: documented behavior\nThe Update API Objects in Place Using kubectl patch documentation is the primary reference.\nThe strategic patch example merges containers using name, while its tolerations example replaces that list because it lacks a merge strategy. A JSON merge patch replaces an existing list with the complete new list supplied in the patch. The tutorial says strategic merge patch is not supported for custom resources.\nWhat the source does not establish\nThis article covers the documented built-in Deployment examples. It does not approve a production mutation, select a scheduling policy or establish application availability after a change. Review those consequences separately. Keep the source object, proposed patch and intended final list together before authorizing execution.\nApplicability questions\n\nIs the intended change an addition, removal or complete replacement?\nWhich field and API resource are being changed?\nWhich patch type and field strategy apply?\nWhat unrelated entries must remain in the accepted after-state?\n\nDSE recommendation: write the intended after-list first\nDSE recommends writing the complete expected list before constructing a patch. Identify every existing entry that should remain and the one change being requested. This makes an omitted entry visible during review rather than after an application or scheduling change.\nRead the relevant field strategy for the actual API type. For the tutorial’s two examples, review containers and tolerations independently even though they sit in the same Pod specification. Keep the selected --type value with the patch file so a reviewer does not infer the operation from its contents alone.\nUse the documented --patch-file approach for a reproducible lab exercise when appropriate. Preserve the exact file and target identity. Review any shell quoting separately if the same change is later written inline; keep one clearly identified authoritative representation instead of several almost identical command fragments.\nCompare the entire affected list after the exercise. Check the retained entries as deliberately as the new entry. If the actual result differs from the expected after-list, resolve the operation or expectation before repeating it against a wider population. Keep the application rollout check separate from the evidence that the API object contains the intended fields.\nVerification and evidence\nProposed verification, not performed: prepare a disposable Deployment with two harmless named container entries and a separately recorded toleration list. Rehearse a strategic patch that adds a container, then a separate strategic toleration-list change. Compare each result with its written expected list rather than assuming both fields use the same behavior.\nIn another isolated case, supply a complete replacement list through the documented JSON merge type. Retain the original object, patch type, patch file and full resulting list for every case. Have a second operator identify which entries should survive before viewing the result. Record actual workload observations separately, and do not treat a correctly changed list as proof that the application rollout was accepted.\nOfficial references\n\nUpdate API Objects in Place Using kubectl patch — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: State whether a list change should add, remove or replace entries before choosing the patch. Review the specific field and operation rather than treating a short patch file as evidence that unrelated entries will remain.\n\n## Source fact: documented behavior\n\nThe [Update API Objects in Place Using kubectl patch](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) documentation is the primary reference.\n\nThe strategic patch example merges containers using name, while its tolerations example replaces that list because it lacks a merge strategy. A JSON merge patch replaces an existing list with the complete new list supplied in the patch. The tutorial says strategic merge patch is not supported for custom resources.\n\n## What the source does not establish\n\nThis article covers the documented built-in Deployment examples. It does not approve a production mutation, select a scheduling policy or establish application availability after a change. Review those consequences separately. Keep the source object, proposed patch and intended final list together before authorizing execution.\n\n## Applicability questions\n\n- Is the intended change an addition, removal or complete replacement?\n\n- Which field and API resource are being changed?\n\n- Which patch type and field strategy apply?\n\n- What unrelated entries must remain in the accepted after-state?\n\n## DSE recommendation: write the intended after-list first\n\nDSE recommends writing the complete expected list before constructing a patch. Identify every existing entry that should remain and the one change being requested. This makes an omitted entry visible during review rather than after an application or scheduling change.\n\nRead the relevant field strategy for the actual API type. For the tutorial’s two examples, review containers and tolerations independently even though they sit in the same Pod specification. Keep the selected --type value with the patch file so a reviewer does not infer the operation from its contents alone.\n\nUse the documented --patch-file approach for a reproducible lab exercise when appropriate. Preserve the exact file and target identity. Review any shell quoting separately if the same change is later written inline; keep one clearly identified authoritative representation instead of several almost identical command fragments.\n\nCompare the entire affected list after the exercise. Check the retained entries as deliberately as the new entry. If the actual result differs from the expected after-list, resolve the operation or expectation before repeating it against a wider population. Keep the application rollout check separate from the evidence that the API object contains the intended fields.\n\n## Verification and evidence\n\nProposed verification, not performed: prepare a disposable Deployment with two harmless named container entries and a separately recorded toleration list. Rehearse a strategic patch that adds a container, then a separate strategic toleration-list change. Compare each result with its written expected list rather than assuming both fields use the same behavior.\n\nIn another isolated case, supply a complete replacement list through the documented JSON merge type. Retain the original object, patch type, patch file and full resulting list for every case. Have a second operator identify which entries should survive before viewing the result. Record actual workload observations separately, and do not treat a correctly changed list as proof that the application rollout was accepted.\n\n## Official references\n\n- [Update API Objects in Place Using kubectl patch](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "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/check-kubernetes-list-semantics-before-using-kubectl-patch/", "url": "https://update.dsesecurity.com/updates/check-kubernetes-list-semantics-before-using-kubectl-patch/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-kubernetes-list-semantics-before-using-kubectl-patch/#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": "Check Kubernetes list semantics before using kubectl patch", "item": "https://update.dsesecurity.com/updates/check-kubernetes-list-semantics-before-using-kubectl-patch/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-kubernetes-list-semantics-before-using-kubectl-patch/#article", "identifier": "https://update.dsesecurity.com/updates/check-kubernetes-list-semantics-before-using-kubectl-patch/", "url": "https://update.dsesecurity.com/updates/check-kubernetes-list-semantics-before-using-kubectl-patch/", "headline": "Check Kubernetes list semantics before using kubectl patch", "description": "A strategic patch can merge one list and replace another. Review the field strategy and patch type before expecting existing entries to survive.", "abstract": "A strategic patch can merge one list and replace another. Review the field strategy and patch type before expecting existing entries to survive.", "articleBody": "Bottom line: State whether a list change should add, remove or replace entries before choosing the patch. Review the specific field and operation rather than treating a short patch file as evidence that unrelated entries will remain.\nSource fact: documented behavior\nThe Update API Objects in Place Using kubectl patch documentation is the primary reference.\nThe strategic patch example merges containers using name, while its tolerations example replaces that list because it lacks a merge strategy. A JSON merge patch replaces an existing list with the complete new list supplied in the patch. The tutorial says strategic merge patch is not supported for custom resources.\nWhat the source does not establish\nThis article covers the documented built-in Deployment examples. It does not approve a production mutation, select a scheduling policy or establish application availability after a change. Review those consequences separately. Keep the source object, proposed patch and intended final list together before authorizing execution.\nApplicability questions\n\nIs the intended change an addition, removal or complete replacement?\nWhich field and API resource are being changed?\nWhich patch type and field strategy apply?\nWhat unrelated entries must remain in the accepted after-state?\n\nDSE recommendation: write the intended after-list first\nDSE recommends writing the complete expected list before constructing a patch. Identify every existing entry that should remain and the one change being requested. This makes an omitted entry visible during review rather than after an application or scheduling change.\nRead the relevant field strategy for the actual API type. For the tutorial’s two examples, review containers and tolerations independently even though they sit in the same Pod specification. Keep the selected --type value with the patch file so a reviewer does not infer the operation from its contents alone.\nUse the documented --patch-file approach for a reproducible lab exercise when appropriate. Preserve the exact file and target identity. Review any shell quoting separately if the same change is later written inline; keep one clearly identified authoritative representation instead of several almost identical command fragments.\nCompare the entire affected list after the exercise. Check the retained entries as deliberately as the new entry. If the actual result differs from the expected after-list, resolve the operation or expectation before repeating it against a wider population. Keep the application rollout check separate from the evidence that the API object contains the intended fields.\nVerification and evidence\nProposed verification, not performed: prepare a disposable Deployment with two harmless named container entries and a separately recorded toleration list. Rehearse a strategic patch that adds a container, then a separate strategic toleration-list change. Compare each result with its written expected list rather than assuming both fields use the same behavior.\nIn another isolated case, supply a complete replacement list through the documented JSON merge type. Retain the original object, patch type, patch file and full resulting list for every case. Have a second operator identify which entries should survive before viewing the result. Record actual workload observations separately, and do not treat a correctly changed list as proof that the application rollout was accepted.\nOfficial references\n\nUpdate API Objects in Place Using kubectl patch — Kubernetes.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:09:48+00:00", "dateModified": "2026-10-29T00:10:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-kubernetes-list-semantics-before-using-kubectl-patch/" }, "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/check-kubernetes-list-semantics-before-using-kubectl-patch/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check Kubernetes list semantics before using kubectl patch" }, "articleSection": [ "IT" ], "keywords": [ "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 533, "timeRequired": "PT3M", "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 — Update API Objects in Place Using kubectl patch", "url": "https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/" } } ] } }