container内核原理浅谈.ppt

memory.usage_in_bytes memory.max_usage_in_bytes memory.limit_in_bytes memory.soft_limit_in_bytes memory.failcnt memory.stat memory.force_empty memory.use_hierarchy memory.swappiness memory.move_charge_at_immigrate memory.oom_control memory.numa_stat (only if CONFIG_NUMA is set) memory.kmem.limit_in_bytes (only if CONFIG_MEMCG_KMEM is set) memory.kmem.usage_in_bytes (only if CONFIG_MEMCG_KMEM is set) memory.kmem.failcnt (only if CONFIG_MEMCG_KMEM is set) memory.kmem.max_usage_in_bytes (only if CONFIG_MEMCG_KMEM is set) memory.kmem.tcp.limit_in_bytes (only if CONFIG_MEMCG_KMEM is set) memory.kmem.tcp.usage_in_bytes (only if CONFIG_MEMCG_KMEM is set) memory.kmem.tcp.failcnt (only if CONFIG_MEMCG_KMEM is set) memory.kmem.tcp.max_usage_in_bytes (only if CONFIG_MEMCG_KMEM is set) memory.kmem.slabinfo (only if CONFIG_SLABINFO is set) memory.memsw.usage_in_bytes (only if CONFIG_MEMCG_SWAP is set) memory.memsw.max_usage_in_bytes (only if CONFIG_MEMCG_SWAP is set) memory.memsw.limit_in_bytes (only if CONFIG_MEMCG_SWAP is set) memory.memsw.failcnt * cpu.share默认1024 * 这是近似做法。实际上调度的设计更加通用，是一种层次化允许嵌套的模式。每个调度实体可以是进程，也可以是一个组。如果是组，则继续CFS，直到找出进程 * * 如果一个container的rootfs大小是100M，1000个container要100G？而且传输起来费事 * 原理和目标均相同，不同的是代码实现。均未进upstream aufs约20K行有效代码 用途：livecd, 嵌入式设备的factory reset 节省空间，节省pagecache，体积小 * AUFS是个中转器 从图上可以看出： 1）aufs支持联合多种格式的文件系统 2）共用page cache，省内存 * /union打开fileA，这时/new加入，那么后面的read返回谁的fileA？ 文件系统有大量的细节 各种网络文件系统、内存文件系统 软链、硬链 xattr属性 aufs on NFS server umount再remount * Container要处理更为复杂的运行环境兼容性。几个例子： 1）一个container在RHEL host运行良好，若部署在Debian可能会有问题。（docker base image能解决之） 2）内核版本对部分用户态库和工具有要求，如libc, perf系统工具等 3）磁盘设备名甚至影响到程序（vda - sda） 4）系统配置文件不能修改 5）内核版本有要求，如果要userns，需3.8+ 除了内核裁剪和容器内调用库的权限限制，另外很多c++程序还需要带着系统库打包，docker跟host共享内核，那意味着还是host决定了程序运行环境而不是docker虚拟出的container。coreos的超精简Linux host自然满足不了很多软件的要求。多个container如果有不同版本的库需求也会是有问题的，就像不同系统软件可能对Linux内核都有不同版本的要求 * 适用场景（大公司内部，PaaS云，IaaS云，测试部署） 参考观点： 1）docker帮助加速应用部署和扩容，方便devops 2）container无法迁移 3）公有云卖资源不合适，而公司内部使用合适。想想安全性，软件bu