docker依赖的linux内核特性,docker镜像能跨平台运行吗？不一定

首先有一个前提:

docker在各平台上的运行机制
LINUX：docker在linux上共享内核，无需虚拟化，完全支持native功能。所以只能创建linux类docker。

Windows：docker在windows上，启用Hyper-V或者虚拟化技术（通过虚拟机来实现，不共享windows内核）。可以创建linux类docker和Windows类docker。

Mac：docker在mac os上，同样用虚拟化技术xhyve或者virtualbox来实现，不共享mac os内核。只能创建linux类docker，不能创建Mac OSX的docker。

只要系统架构一样，是可以使用相同的镜像的 ，比如x86的镜像只能x86的系统使用，arm的镜像只能arm系统使用。docker镜像对容器而言只是模拟了一个环境，跟宿主机没多大关系
有些程序依赖于系统内核,比如说sh,这就会导致依赖系统内核的程序在不同的linux环境中可能运行不起来
常考一下网友的观点:
https://www.nuomiphp.com/t/61b9600957f4a154cc7bebea.html
https://www.cnblogs.com/kumata/p/14108646.html
centos6.0的sh没法在centos7.0运行,这就会导致在6.0打的镜像在7.0运行时启动不起来

docker依赖的内核特性
docker依赖于Linux的四个内核特性：

Namespaces：命名空间
Control groups（cgroups）：控制组
unionFS：联合文件系统
rootfs：系统根目录文件

Namespaces

命名空间提供了一种系统资源的隔离，包括了文件系统、网络、进程等。docker有5种命名空间：

PID：进程隔离
NET：网络管理接口
IPC：管理跨进程通信访问
MNT：管理挂载点
UTS：隔离内核和版本标识

Control groups

这是Linux内核提供的一种可以限制，记录，隔离物理进程组的机制。他提供了以下功能：

资源限制
优先级设定
资源计量
资源控制
docker容器能力
Namespaces和Control groups带给了容器下面的能力：

文件系统的隔离：每个容器都有自己的root文件系统
进程隔离：每个容器都运行在自己的进程环境中
网络隔离：每个容器间虚拟网络接口和ip地址都是分开的
资源隔离和分组：Control groups可以将CPU和内存之类的资源独立分配给每个docker容器

Union File System

2004年由纽约州立大学石溪分校开发，它可以把多个目录(也叫分支)内容联合挂载到同一个目录下，而目录的物理位置是分开的

rootfs

rootfs 是Docker 容器在启动时内部进程可见的文件系统，即Docker容器的根目录。rootfs通常包含一个操作系统运行所需的文件系统，例如可能包含经典的类Unix操作系统中的目录系统，如/dev、/proc、/bin、/etc、/lib、/usr、/tmp及运行Docker容器所需的配置文件、工具等。
在传统的linux操作系统内核启动时，首先挂载一个只读（read-only）的rootfs，当系统检测器完整性之后，再将其切换为读写（read-write）模式。而在Docker架构中，当Docker daemon 为Docker容器挂载rootfs时，沿用的Linux内核启动时的方法，即将rootfs设为只读模式。在挂载完毕之后，利用联合挂载（union mount）技术在已有的只读rootfs上再挂载一个读写层。这样，可读写层处于Docker容器文件系统的最顶层，其下可能联合挂载了多个只读层，只有在Docker容器运行过程中文件系统发生变化是，才会把变化的文件内容写到可读写层，并且隐藏只读层中的老版本文件。
rootfs只是一个操作系统所包含的文件、配置和目录，并不包括操作系统内核。在Linux操作系统中，这两部分是分开存放的，操作系统只有在开机启动时才会加载指定版本的内核镜像。正是由于rootfs的存在，容器才有了一个被反复宣传至今的重要特性：一致性。由于rootfs里打包的不只是应用，而是整个操作系统的文件和目录，也就意味着，应用以及它运行所需要的所有依赖，都被封装在了一起。
有了容器镜像“打包操作系统”的能力，这个最基础的依赖环境也终于变成了应用沙盒的一部分。这就赋予了容器所谓的一致性：无论在本地、云端，还是在一台任何地方的机器上，用户只需要解压打包好的容器镜像，那么这个应用运行所需要的完整的执行环境就被重现出来了