windowns上的DockerDesktop 和 Linux下docker的差别

最近要上云，所以在自己的机器上自己先用一下；估计步骤是使用 docker -- > k8s ；

虽然在windwos机器上也装了 Docker Desktop，总觉得和安装在linux下的docker有所差异，但不知道是哪里差异，直到看了一篇文章才清楚：

Docker使用： Namespace、Cgroups、以及 rootfs 三大技术构建出来的隔离环境，在linux环境上，docker其实是起到了一个启动代理，通过设置一大堆启动参数，给应用进程配置好运行环境；其实docker本身并没有一个独立的运行环境。

Namespace：作用是“隔离”，让应用进程只看到该Namespace内的“世界”；
- 实现方式：
  在创建进程时（clone），增加Namespace参数
  查看进程的namespace： /proc/pid/ns/*
  目前linux实现了六种namespace（https://blog.csdn/shichaog/article/details/41378145）：
  - mount命名空间（CLONE_NEWS, Linux2.4.19）：
    用于隔离一组进程看到的文件系统挂载点集合，即处于不同mount 命名空间的进程看到的文件系统层次很可能是不一样的。mount()和umount()系统调用的影响不再是全局的而只影响其调用进程指向的命名空间。mount命名空间的一个应用类似chroot，然而和chroot()系统调用相比，mount 命名空间在安全性和扩展性上更好
  - UTS命名空间（CLONE_NEWUTS， Linux2.6.19）：
    隔离了两个系统变量，系统节点名和域名；UTS赋予了每个容器各自的主机名和网络信息服务名(NIS) (Network Information Service)，这使得初始化和配置脚本能够根据不同的名字进行裁剪。
  - IPC namespaces (CLONE_NEWIPC, Linux 2.6.19)：
    隔离进程间通信资源，具体来说就是System V IPC objects and (since Linux2.6.30) POSIX message queues；这些机制的共同特点是由其特点而非文件系统路径名标识。每一个IPC命名空间尤其自己的System V IPC标识符和POSIX 消息队列文件系统。
  - PID namespaces (CLONE_NEWPID, Linux 2.6.24)：
    隔离进程ID号命名空间，话句话说就是位于不同进程ID命名空间的进程可以有相同的进程ID号，PID命名空间的最大的好处是在主机之间移植container时，可以保留container内的ID号，PID命名空间允许每个container拥有自己的init进程（ID=1），init进程是所有进程的祖先，负责系统启动时的初始化和作为孤儿进程的父进程
    从特殊的角度来看PID命名空间，就是一个进程有两个ID，一个ID号属于PID命名空间，一个ID号属于PID命名空间之外的主机系统，此外，PID命名空间能够被嵌套
  - Network namespaces (CLONE_NEWNET, Linux2.6.24开始结束于 Linux 2.6.29)
    用于隔离和网络有关的资源，这就使得每个网络命名空间有其自己的网络设备、IP地址、IP路由表、/proc/net目录、端口号等等。
    从网络命名空间的角度看，每个container拥有其自己的网络设备（虚拟的）和用于绑定自己网络端口号的应用程序。主机上合适的路由规则可以将网络数据包和特定container相关的网络设备关联。例如，可以有多个web 服务器，分别存在不同的container中，这就使得这些web 服务器可以在其命名空间中绑定80端口号。
  - User namespaces (CLONE_NEWUSER, 起始于 Linux2.6.23 完成于 Linux 3.8) ：
    隔离用户和组ID空间，换句话说，一个进程的用户和组ID在用户命名空间之外可以不同于命名空间之内的ID，最有趣的是一个用户ID在命名空间之外非特权，而在命名空间内却可以是具有特权的。这就意味着在命名空间内拥有全部的特权权限，在命名空间之外则不是这样。
    自Linux3.8开始，非特权进程可以创建用户命名空间，由于非特权进程在user命名空间内具有root权限，命名空间内非特权应用程序可以使用以前只有root能够使用的一些功能。
Cgroups：作用是“限制”，限制应用进程可以使用到的资源；
- 实现方式：
  /sys/fs/cgroup 中配置对应用进程的限制，目前常用的是cpu和内存，对磁盘的限制比较麻烦不常用；
- 问题：给系统监控带来的问题：
  系统监控，是从/proc/中获取资源数据的，应用程序缺省是从/proc下读取数据的，而不是限制后的资源配置；
  所以要把/var/lib/lxcfs/proc/* 挂接到容器中的 /proc/* 下，这样容器内才会看到的是实际限制后的资源配置；
  ---- 譬如没有对java启动参数做限制，让java根据系统资源自动设置，如果看到的是宿主机的资源，java使用的资源就会大大超过docker的限制；
rootfs：为应用进程创建一个独立的文件系统；
- 实现
  通过pivot_root/chroot来实现；
  在切换前，可以mount本地目录进来，这样这些目录的读写，其实是在宿主机的目录中进行读写，容器中生成的数据，在宿主机上能直接看到；
- 问题：
  由于mount本地目录，是在docker里进行mount的，因此在宿主机上是看不到这个mount的；
  如果采用 docker commit进行打包，在宿主机上看到的还是原来的这些目录，打包的还是mount之前的目录，而不是mount以后的内容；