这更多的是Json6902修补程序的限制，以及在K8s pod中将容器定义为数组而不是哈希的事实，在哈希中，类似于以下内容：

path: /spec/containers/${NAME_OF_CONTAINER}/command

您可以尝试StrategicMergePatch，这基本上就是kubectl apply的功能。
x一个一个一个一个x一个一个二个一个x一个一个三个一个
✌️

对于未来的读者：您可能已经在互联网上看到过类似这样的 * JSONPath * 语法，并希望可以选择一个列表项并使用Kustomize对其进行修补。

/spec/containers[name=my-app]/command

正如his answer中提到的@Rico：这是JSON6902的一个限制-它只接受使用 * JSONPointer * 语法的路径，由JSON6901定义。

因此，不可以，在使用kustomize的patchesJson6902时，您当前无法使用[key=value]语法来寻址列表项。

但是，原始问题强调的有关列表项可能重新排序的问题的解决方案确实存在，而无需转移到策略合并补丁（这可能取决于CRD作者正确注解应如何应用列表项合并）。
只需将另一个JSON6902操作添加到test的补丁中，使该项保留在您指定的索引中。

# 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 it's command
- op: replace
  path: /spec/containers/0/command
  value: ["sh", "-c", "tail -f /dev/null"]

如果指定路径中的值与提供的值不匹配，test操作将使您的修补失败。这样，您可以确保其他修补操作对项目索引的依赖仍然有效!
我特别在处理自定义资源时使用此技巧，因为我：

• A）不必给用户一个全新的openAPI规范，并且
• B）不必依赖于CRD作者添加了正确的扩展注解（例如："x-kubernetes-patch-merge-key": "name"），以确保我对列表项的策略合并补丁按照我需要的方式工作。