简介
昨天参加了一趟PouchContainer GA 的分享,刷新了很多思维观念,趁热打铁记录一下。
PouchContainer 的亮点
- 更充分的隔离性,docker容器因为共享内核的缘故,类似
/proc
及其依赖的相关的组件无法 正常使用 - 守护进程,一则为了一些依赖系统服务的组件可以正常使用;再则,使得容器 更像一点虚拟机
-
容器与虚拟机混合部署。
- 以前认为的混合部署是 vm 搞vm、container 搞container,彼此互通就行了,且实施方式是由vm 环境 兼容容器。
- PouchContainer 先支持container 后支持runv, 是从容器环境 兼容vm。PouchContainer 兼容vm 的一个重大区别是 都支持镜像发布,这样的混合发布才更有意义。
补充:Pouch 可能借鉴了kata的一些实现。Kata containers跟RunC类似,也是一个符合OCI运行时规范的一种 实现,不同之处是, kata containers整合了Intel的 Clear Containers 和 Hyper.sh 的 runV,给每个容器增加了一个独立的linux内核(不共享宿主机的内核),使容器有更好 的隔离性,安全性。
关于docker的使用
第一个新知道:远程镜像,镜像分发的一个重要问题是大镜像分发比较耗时,解决起来有几个办法
- 缩减镜像,比如提高复用率、压缩镜像等
- 提高速度,比如p2p分发
- 干脆不移动镜像,
docker run
的时候直接读取远程镜像,就像在本地一样。
再一个很好奇的事情,mysql、es、hadoop 都docker 化,为什么要将这些服务docker化?
- 分享者多来自云计算或 系统部门,支持很多的业务线,有一键交付一个hadoop 集群的需求
- 业务集群和数据集群混合调度,提高资源利用率(这是个长远目标,都还在实践中)
- mysql 服务可以拆分为三个部分:对外接口;计算服务;存储。三个部分独立后,计算服务可以自由升级,对外接口可以保持不变,存储部分使用CSI。没有体验过msyql 宕机(集群太小) 或者复杂的业务(需要各种版本的mysql)的我,对这个需求挺难理解的。
- hadoop/es 等很多大公司都有自己的维护小组,小公司hadoop 集群一般不怎么变,自然无法理解 一个月一个小迭代升级的运维需求。
P2P下载镜像,一个文件假设100m,按4m一块切分,客户端按块下载。局域网多个主机不一定都需要从第0块开始下载,假设4台主机在一个局域网内,分别下载25块,然后局域网内互传就行,比大家彼此都从第0块下载到100 要快很多。
容器生态
OCI(Open Container Initiative) 致力于建立一个容器运行时和镜像格式的规范,其核心目的在于避免容器生态的分化,确保在不同容器引擎上构建的容器可以相互兼容,runc 是其一个参考实现。包括:runtime spec 和 image spec
容器引擎,或者说容器平台,不仅包含对于容器的生命周期的管理,还包括了对于容器生态的管理,比如docker images、docker volumes、 docker network 等指令。
此处提一下, 容器运行时在不同的角度指向不同,很多地方也都有混用。比如对k8s来说,docker算是container runtime,对docker来说,runc是 container runtime ,不用纠结这些称呼。
为隔离各个容器引擎(比如docker、rkt等)之间的差异,通过统一的接口与各个容器引擎之间进行互动。kubernetes推出 CRI(container runtime interface)。与oci不同,cri不仅定义了容器的生命周期的管理,还引入了k8s中pod的概念,并定义了管理pod的生命周期。cri与kubernetes的概念更加贴合,紧密绑定。
为了进一步与oci进行兼容,kubernetes还孵化了cri-o,成为了架设在cri和oci之间的一座桥梁。看来kubernetes是想直接 抛开docker、rkt 等容器引擎。
paas/cloud native
在与一位大牛的讨论中,笔者听到,k8s 集群管理的服务 基本不访问本地磁盘,此时的存储不再是物理机的存储,而是一个“超级计算机”的存储。程序(对应镜像 + yml)、进程、存储、网络在“超级计算机” 的范畴里都变了形态。
PaaS/cloud native 之后,我们向用户交付的,不再是一个个物理机,而是直接的运行一个服务的能力,就好像物理机提供进程的运行能力一样。服务运行时包含:对外接口;计算;存储,三者独立变化和升级、调度、移动,互不干扰。物理机 从小型机 到大型机, 单机的能力达到瓶颈之后,人们开始采用集群方式来提高能力,最终将集群又抽象为了一个超级计算机。
以前只有一个模糊的感觉,通过这次分享,笔者感受到在内部实践上,一直面临着传统运维和paas/cloud native 的博弈
- 笔者的公司基本就两种服务,web服务(前面接nginx)和微服务(前面接服务注册中心)。服务发现、负载均衡等事情有微服务框架去做。所以笔者在16年调研调度框架时,觉得k8s的pod、service 等概念基本用不上,进而选择了marathon + mesos。很多概念很超前,cloud native 还没推动,service mesh 就来了, 但公司层面的实践演变却很慢(与公司的发展阶段相适应就好)。
- 人员的接受成本,运维、开发还是物理机时代,光一个项目重新部署后服务ip 会改变就引起了很多同事的不理解。不适应他们就推不动,适应了他们就不符合新理念,很多问题也不只是技术问题。
需求驱动
为什么要用docker? 笔者曾依次想了几个理由
- 项目发布,因为公司全是java 项目,因此已有的发布系统基本够用,docker 的优势体现不出来
- 自动扩容缩容,这类业务(比如音视频编解码)可以直接使用云服务。
- 提高资源利用率,快速发展的公司,资源按峰值压力分配就可以了,业务发展会很快跟上来。
docker 为什么要这么用?这么改?
- 比如因为我司都是java项目,没考虑过一些项目依赖基础组件,自然对富容器的好处只有模糊而没有深刻的体会。
因此,一切还是跟需求有关系,有时候推动实践,不如推动需求。