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
回答评论中的问题：
谢谢@david。这必须在部署之前完成。我想知道是否可以将一个早已部署（正在运行）的pod连接到一个附加的sidecar容器上。
您无法将附加容器连接到正在运行的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 upgrade在这两种情况下，我鼓励您检查Kubernetes如何处理其资源的更新。您可以按照以下链接阅读更多相关信息：
$ kubectl patch完全避免编辑Helm图表的方法是使用：
$ kubectl patch这种方法将会“修补”现有的Deployment/StatefulSet/Daemonset并添加Sidecar。这种方法的缺点是它不像Helm那样自动化，您需要为每个资源（每个Deployment/Statefulset/Daemonset等）创建一个“patch”。“Patch”会在其他来源（如Helm）的任何更新时被覆盖。
有关原地更新API对象的文档:
Helm Chart并使用$ helm upgrade此方法需要编辑Helm chart。所做的更改（如添加Sidecar）将通过更新持续存在。更改后，您需要使用命令$ helm upgrade RELEASE_NAME CHART进行更新。
您可以在此处阅读更多信息:
Kubernetes资源是不可变的，正如dawid-kruk所述。因此，修改Pod描述将导致容器重新启动。
您可以使用kubectl patch命令修改Pod，并根据需要重新应用补丁。
或者，以下两个选项将在无需修改/分叉上游图表或损坏部署的资源的情况下注入sidecar。
基因突变审批控制器（Webhook）可以修改资源，请参见https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
您可以使用通用框架，例如opa， 或特定的Webhook，例如fluentd-sidecar-injector（未经测试）
您可以向图表维护人员提交功能请求，以支持任意位置的sidecar注入，就像在Prometheus中一样，参见https://stackoverflow.com/a/62910122/1260896
Deployment的YAML定义中附加额外的容器。这份文档可能对此有所帮助：来自 Kubernetes.io 的多容器示例。请告诉我这是否是你要找的内容。 - undefined