在评论中回答这个问题：
谢谢大卫。这必须在部署之前完成。我想知道我是否可以将sidecar容器附加到已经部署（运行）的pod。

无法将附加容器附加到正在运行的Pod。您可以更新（修补）资源定义。这将强制使用新规范重新创建资源。

有一个关于此功能的github问题，已通过以下评论关闭：
在讨论了SIG Node的目标之后，明确的共识是pod规范中的容器列表应该保持不变。#27140将通过kubernetes/community#649更好地解决，这允许在现有pod中运行短暂的调试容器。这将不会得到执行。
-- Github.com: Kubernetes: Issues: Allow containers to be added to a running pod
这篇文章的一部分：
现在要定义这个sidecar容器，我想避免更改供应商定义的部署脚本。相反，我想要一些替代的方式来附加sidecar容器到运行的pod。
下面我介绍了两种向Deployment添加sidecar的方法。**这两种方法都将重新加载Pods**以匹配新规范：

• 使用$ kubectl patch
• 编辑Helm图表并使用$ helm upgrade

在这两种情况下，我建议您检查Kubernetes如何处理其资源的更新。您可以通过以下链接阅读更多内容：

• Kubernetes.io: Docs: Tutorials: Kubernetes Basics: Update: Update
• Medium.com: Platformer blog: Enable rolling updates in Kubernetes with zero downtime

使用$ kubectl patch

完全避免编辑Helm图表的方法是用途：

• $ kubectl patch

此方法将“修补”现有的Deployment/StatefulSet/Daemonset并添加sidecar。这种方法的缺点是它不像Helm那样自动化，你需要为每个资源（每个Deployment/Statefulset/Daemonset等）创建一个“补丁”。如果有来自其他来源的更新，如Helm，这个“补丁”将被覆盖。
有关就地更新API对象的文档：

• Kubernetes.io: Docs: Tasks: Manage Kubernetes objects: Update api object kubectl patch

编辑Helm图表，使用$ helm upgrade

此方法需要编辑Helm图表。所做的更改（如添加Sidecar）将在更新过程中持续存在。在进行更改后，您将需要使用$ helm upgrade RELEASE_NAME CHART。
你可以在这里阅读更多关于它：

• Helm.sh: Docs: Helm: Helm upgrade

对于像我这样的人来说，登陆这里搜索问题的标题是什么，一种临时添加sidecar容器的方法，自Kubernetes 1.25以来，调试功能已经变得稳定了！

注意：如果您的用例与问题描述中的用例相同，请阅读其他答案！

https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container
你可以直接跑：

kubectl debug -it your-pod-with --image=busybox:1.28 --target=ephemeral-demo

当然，这不适合OP，因为这是用于短期调试，而不是运行进程。

Kubernetes资源是不可变的，正如dawid-kruk所提到的。因此，修改pod描述将导致容器重新启动。
您可以使用kubectl patch命令修改pod，不要忘记重新应用。必要时进行修补。
或者，以下两个选项将注入sidecar，而不必修改/fork上游图表或修改部署的资源。

#1变更准入控制器

可变准入控制器（webhook）可以修改资源请参阅https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
你可以使用像opa这样的通用框架。或者像fluentd-sidecar-injector这样的特定webhook（未测试）

#2 helm支持任意sidecar

您可以向图表维护器提交一个特性请求，以支持任意sidecar注入，就像Prometheus中一样，请参阅https://stackoverflow.com/a/62910122/1260896