<p>I'm trying to see if there's a way to apply a kustomize patchTransformer to a specific container in a pod other than using its array index.  For example, if I have 3 containers in a pod, (0, 1, 2) and I want to patch container &quot;1&quot; I would normally do something like this:</p>
<pre class="lang-yaml prettyprint-override"><code>patch: |-
  - op: add
    path: /spec/containers/1/command
    value:  [&quot;sh&quot;, &quot;-c&quot;, &quot;tail -f /dev/null&quot;]
</code></pre>
<p>That is heavily dependent on that container order remaining static.  If container &quot;1&quot; is removed for whatever reason, the array is reshuffled and container &quot;2&quot; suddenly becomes container &quot;1&quot;, making my patch no longer applicable.</p>
<p>Is there a way to patch by name, or target a label/annotation, or some other mechanism?</p>
<pre><code>path: /spec/containers/${NAME_OF_CONTAINER}/command
</code></pre>
<p>Any insight is greatly appreciated.</p>

<p>You may have seen <em>JSONPath</em> syntax like this floating around the internet and hoped that you could select a list item and patch it using Kustomize.</p>
<pre><code>/spec/containers[name=my-app]/command
</code></pre>
<p>As @Rico mentioned in <a href="https://stackoverflow.com/a/63928566/4785629">his answer</a>: This is a limitation with <a href="https://www.rfc-editor.org/rfc/rfc6902.html" rel="nofollow noreferrer">JSON6902</a> - it only accepts paths using <em>JSONPointer</em> syntax, defined by <a href="https://www.rfc-editor.org/rfc/rfc6901.html" rel="nofollow noreferrer">JSON6901</a>.</p>
<p><em><strong>So, no, you cannot currently address a list item using <code>[key=value]</code> syntax when using kustomize's <code>patchesJson6902</code>.</strong></em></p>
<p>However, the problem presented in the original question around dealing with changes to the order of list items does have a solution using <em>JSONPointer</em> syntax (JSON6901) without moving to Strategic Merge Patch (which can depend on CRD authors correctly annotating how list-item merges should be applied).</p>
<p>Simply add another JSON6902 operation to your patches to <code>test</code> that the item remains at the index you specified.</p>
<pre><code># First, test that the item is still at the list index you expect
- op: test
  path: /spec/containers/0/name
  value: my-app

# Now that you know your item is still at index-0, it's safe to patch its command
- op: replace
  path: /spec/containers/0/command
  value: [&quot;sh&quot;, &quot;-c&quot;, &quot;tail -f /dev/null&quot;]
</code></pre>
<p>The <code>test</code> operation will fail your patch if the value at the specified path does not match what is provided. This way, you can be sure that your other patch operation's dependency on the item's index is still valid!</p>
<p>I use this trick especially when dealing with custom resources, since I:</p>
<ul>
<li>A) Don't have to give kustomize a whole new openAPI spec, and</li>
<li>B) Don't have to depend on the CRD authors having added the correct extension annotation (like: <code>&quot;x-kubernetes-patch-merge-key&quot;: &quot;name&quot;</code>) to make sure my strategic merge patches on list items work the way I need them to.</li>
</ul>
