请假一下大佬， docker 容器里运行的程序是否相当于内核管理一个普通的程序，不影响效率？

docker 在 Linux 下的实现只是利用了内核的命名空间技术，将 pid 、network 、user 、uts 、mount 资源隔离了，所以没有什么额外开销。
你所说的“隔离出单独的虚拟存储空间”的说法很模糊而且有歧义。这里我将你所谓“虚拟存储空间”理解为虚拟地址空间来说，默认情况下，所有进程的虚拟地址空间都是相互独立的，一个进程不可能访问到其他进程的虚拟地址空间，因此才有了进程间通信机制。
“虚拟的系统进程树”，其实就是 pid namespace 。举例来说，新建一个 pid namespace，然后在其中创建一个进程，其 pid 为 1，而在其 parent namespace 中的 pid 是其他数值，但肯定不是 1 。总之，进程的 pid 在不同的 namespace 中的值是不一样的。
vmware 这种是硬件虚拟化，和 Linux 上的原生 docker 是两回事。
macOS 和 Windows 上的 docker，其实是先起一个 Linux 虚拟机，然后在其中跑 docker 。

如果我没有理解错误的话，这是否意味着 docker 上运行一个进程，在 cpu 执行效率上与系统中一个普通进程没有区别？
——还是有区别的，会比原生低一些。
https://www.cnblogs.com/idbeta/p/4982173.html

就 app 的效率而言，原生>wine>沙箱>=容器>hyperv>=kvm>虚拟机；
app 的兼容性来看，虚拟机>容器>原生；

一度觉得，容器就是打包了所有程序资源的沙箱，sandboxie+app 的赶脚。十几年前有个叫“云端”的程序，大意是，主控程序从它的网站下载绿色版 exe 、运行必须的文件等，并下载用户的配置文件等，然后 exe 就可以顺利的在任何 windows 电脑上跑起来了。还可以把用户的配置文件同步到各客户端。理念很先进，法务很悲伤，所以没几天就完了。


值得一提的是，hyperv 号称把当前 win 作为 guest os，听起来有点牛逼。配合 3389 的 remote fx，3d 游戏、1080p 都不是问题，挺厉害的。

默认配置下，磁盘 I/O 影响比较大，其它不明显

容器实质上就是宿主系统里的一组进程
如果说损耗的话，至少 cpu 、内存性能几乎不会有损耗，因为就是当作原生进程处理的
但是磁盘性能就不一定了，docker 的虚拟文件系统并不跟原生的一致

你的理解一部分是对的。
首先确定一点，进程运行要依赖操作系统。如果你用虚拟机隔离进程的话，不同虚拟机之间操作系统这部分资源是没法共享的。所以你运行多个虚拟机的话，实际上相当于多个被虚拟的操作系统同时在运行。按照虚拟机类型的不同，这部分虚拟化的操作系统有可能直接运行在硬件上（比如于 Hyper V 或者 KVM ），也有可能下面还有一层宿主机的操作系统（很多虚拟机可以切换到这种模式）。
而对于 Docker 来说，在多个 Docker 中的操作系统这部分资源是复用操作系统的。多个 Docker 之间是通过虚拟化逻辑进行隔离而不是像虚拟机那样更类似于物理隔离的。
另外 @Nitroethane 说的不对，Windows 支持两种类型的 Docker 运行方式。一种是开个虚拟机运行的 Hyper-V-isolated container，另一种是和 Linux 一样直接进行内核共享的 Process-isolated container 。在 Windows 上使用 Linux Docker 只能用第一种方式，使用 Windows docker 镜像的话内核是可以共享的。
但不管是 Docker 还是虚拟机，如果你一台机器只虚拟化一个程序的话，实际上效率差不了多少，都是你的程序下面是层操作系统，再下面就是硬件资源。Docker 不过是在你的宿主操作系统上运行了这个进程，而 Type 1 的虚拟机也是一样的，虚拟化的操作系统是直接访问硬件资源的，宿主系统如果没啥功能或者压根就没装的话其实差不了多少。

如果没区别，k8s 就不会抛弃 docker 了

@m4d3bug k8s 放弃 docker 不是因为性能原因好吗？