原文位于 https://github.com/huazhihao/kubespy/blob/master/implement-a-k8s-debug-plugin-in-bash.md
## 背景
Kubernetes调试的最大痛点是精简过的容器镜像里没有日常的调试工具。背后的原因是精简容器镜像本身就是容器技术的最佳实践之一。nginx的容器镜像甚至不包含ps和curl这种最基础的工具。这种完全服务于生产环境的策略无异于过早优化,但受制于immutable infrastructure的基本思想和CI/CD实际操作的双重制约,你无法在生产环境发布一个和开发环境不同的容器镜像。这使得这一过早优化的结果更加灾难化。解决这个问题的关键在于,能否在不侵入式的修改容器镜像的情况下,向目标容器里加载需要的调试工具。例如,类似于istio之类的解决方案可以向目标pod插入一个sidecar容器。当然这里的权限要求是高于sidecar容器的,因为pod中的各个容器虽然共享network,但pid和ipc是不共享的。此外,sidecar容器是无法被加入一个已经创建出来的pod,而我们希望工具容器可以在运行时被动态插入,因为问题的产生是随机的,你不能完全预测需要加载哪些工具。
Kubernetes社区很早有相关的[issue](https://github.com/kubernetes/kubernetes/issues/27140)和[proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/troubleshoot-running-pods.md)但并没有最后最终被upstream接受。
目前官方给出最接近的方案是[Ephemeral Containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/)和[shareProcessNamespace](https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/)。前者允许你在运行时在一个pod里插入一个短生命周期的容器(无法拥有livenessProbe, readinessProbe),而后者允许你共享目标pod内容器的network,pid,ipc等cgroups namespace(注意,此namespace非Kubernetes的namespace)甚至修改其中的环境。目前`Ephemeral Containers`还在v1.17 al